本文的目標(biāo)是概述 Paradigm Reth 團(tuán)隊(duì)^[4]對于布拉格硬分叉的看法，布拉格（Prague）是坎昆之后的下一個(gè) EL 硬分叉，以及我們 2024 年“EL 核心開發(fā)”計(jì)劃的概況。以下觀點(diǎn)正在發(fā)展中，僅代表 Reth 團(tuán)隊(duì)當(dāng)前的觀點(diǎn)，不一定代表更廣泛的 Paradigm 團(tuán)隊(duì)。

它應(yīng)該包括：

任何與質(zhì)押相關(guān)的 EIP，比如 EIP-7002，它使重質(zhì)押(re-staking)和無信任質(zhì)押池成為可能。

獨(dú)立的 EVM 更改。

我們愿意與任何希望進(jìn)一步研究布拉格或其他未來 EL 硬分叉的團(tuán)隊(duì)合作，樂意指導(dǎo)或提供指導(dǎo)以修改 Reth 代碼庫的位置。

支持:

我們認(rèn)為以下 EIP 必須優(yōu)先考慮：7002^[5], 6110^[6], 2537^[7]。

我們支持 EOF，如規(guī)范^[8]中所述，但希望盡快確定范圍，并創(chuàng)建一個(gè)元 EIP，承諾遵守該范圍。

我們愿意增加 EIP-4844 最大 Blob Gas^[9] 的版本。我們對正確的數(shù)字沒有看法，但我們邀請數(shù)據(jù)人員與我們合作調(diào)查這個(gè)問題。

我們愿意發(fā)布 EIP-7547：包含列表^[10]的版本，以幫助基礎(chǔ)層抗審查。

不支持:

我們不支持在布拉格中使用 Verkle Tries^[11]，但我們支持客戶端團(tuán)隊(duì)從 2024 年第二季度開始努力實(shí)現(xiàn)它，并承諾在 2025 年中期/晚期在大阪發(fā)布。

我們不認(rèn)為應(yīng)該增加 L1 執(zhí)行 Gas 限制或合約大小，但我們邀請數(shù)據(jù)人員與我們合作調(diào)查對網(wǎng)絡(luò)的影響。我們愿意修改我們的看法，因?yàn)檫^去的測試表明 Reth 節(jié)點(diǎn)可以處理增加的負(fù)載而沒有問題。

我們認(rèn)為錢包/賬戶抽象 EIP 需要更多相互對抗的測試，以更好地理解權(quán)衡空間。如果它們不是相互排斥的，那么我們愿意在未來部署多個(gè) AA 相關(guān)的 EIP。

如果社區(qū)對傳聞中^[12]的NSA^[13]后門^[14] OK ，我們可以接受 EIP-7212（secp256r1）。

其他路線圖主題：我們對 CL EIP 或 CL/EL 分叉的耦合沒有具體看法，但 EIP 7549^[15]和 7251^[16] 似乎很有前景。我們還希望在 EL 方面盡可能地為 PeerDAS 的工作做出貢獻(xiàn)。我們希望暫時(shí)避免引入 SSZ 根（EIP 6404, 6465, 6466）。最后，我們注意到為過期的 Blob、歷史和狀態(tài)提供長期數(shù)據(jù)存檔解決方案的機(jī)會(huì)，因?yàn)?EIP-4844^[17] 和EIP-4444^[18]都沒有指定這一點(diǎn)，以及以太坊是否愿意提供這樣的解決方案。

以下是推理。

支持

抽象地說，我們支持 1)進(jìn)一步彌合 CL 和 EL 之間的差距，2) EVM 修改可以作為單人工作執(zhí)行，并且可以在隔離和并行測試。

EIP-7002^[19]

這個(gè) EIP 通過使 EL 側(cè)的智能合約控制 CL 側(cè)的一個(gè)或多個(gè)驗(yàn)證者，解鎖了無信任的重新質(zhì)押和質(zhì)押池。從我們的角度來看，這是一個(gè)不需要思考的 EIP，因?yàn)橹辽偎鼘⑹宫F(xiàn)有的質(zhì)押池能夠從實(shí)施其提款的智能合約中去除一層中心化。

在 EVM 實(shí)現(xiàn)中引入有狀態(tài)的預(yù)編譯是我們需要在 EVM 實(shí)現(xiàn)中捕獲的新抽象，但除此之外，我們認(rèn)為這是一個(gè)可以直接執(zhí)行的 EIP。

EIP-6110^[20]

這個(gè) EIP 在 EL 狀態(tài)中引入了存款，簡化了 CL 上需要進(jìn)行的狀態(tài)管理。在實(shí)施上，這類似于跟蹤 CL 提款，因此總體上我們認(rèn)為這也是一個(gè)容易實(shí)現(xiàn)且獨(dú)立的 EIP 。

EIP-2537^[21]

現(xiàn)在外面有多個(gè) BLS12-381 的實(shí)現(xiàn)，它是許多 SNARKs、BLS 簽名算法和 EIP-4844 中經(jīng)常使用的曲線。我們認(rèn)為實(shí)現(xiàn)復(fù)雜性低，因?yàn)樗皇峭ㄟ^預(yù)編譯接口公開了曲線的驗(yàn)證算法。可能我們還想要一個(gè) Hash 到 BLS12-381 曲線的預(yù)編譯。

EOF^[22] 以太坊對象格式

TL;DR：支持一個(gè) Solidity 和 Vyper 將采用的范圍明確的版本。使分析更容易的代碼格式和驗(yàn)證調(diào)整是一個(gè)不需要思考的事情，我們建議進(jìn)一步修剪。

好處：

只有 EVM 的更改，可以通過以太坊/tests 進(jìn)行測試，并由一人實(shí)施。

做 Vyper 和 Solidity 想要的 EVM 更改！

有助于性能和提高合約限制大小。

通過 EVM 在運(yùn)行時(shí)消除了對字節(jié)碼的分析的需要，當(dāng)沒有緩存時(shí)，這可能占用時(shí)間的 50%，隨著合約大小的增加而增加。

可以部分加載代碼，有助于執(zhí)行大型合約。

Devex：將允許在 Solidity 中使用 dupN/swapN 修復(fù)“Stack Too deep”，以及其他工具改進(jìn)。

未來驗(yàn)證：可以安全地引入新功能到 L2，并且工具將知道什么是兼容的。

不足：

變化了目標(biāo)。

沒有支持者極力推動(dòng)它的加入。

仍然需要支持舊代碼

直到被采用之前，以太坊主網(wǎng)和其他 EVM 鏈之間會(huì)有暫時(shí)的分歧。

我們認(rèn)為以下 EOF 功能應(yīng)該在 2024 年部署。我們建議盡快確定范圍并承諾遵守。其他任何事情應(yīng)該考慮后續(xù)部署。我們的建議：

EIP-3540: EOF - EVM 對象格式 v1^[23]：引入代碼和數(shù)據(jù)容器，并為以太坊字節(jié)碼添加結(jié)構(gòu)和版本。

EIP-3670: EOF - 代碼驗(yàn)證^[24]：在部署時(shí)拒絕任何不遵循 EOF 格式的合約。強(qiáng)制更結(jié)構(gòu)化的代碼，并禁用無效和未定義的指令。

EIP-663: 無限的 SWAP 和 DUP 指令^[25]：這解決了 Solidity 中的“Stack Too Deep”問題，通過 JUMPDEST 分析作為即刻值可能會(huì)產(chǎn)生副作用。EVM 語言非常希望有這樣的功能。

EIP-4200: EOF - 靜態(tài)相對跳轉(zhuǎn)^[26]：更好的靜態(tài)分析，沒有不確定的跳轉(zhuǎn)。更好的 aot 編譯。相對跳轉(zhuǎn)對代碼的可重用性更好。

EIP-4750: EOF - 函數(shù)^[27]：需要處理可能具有動(dòng)態(tài)跳轉(zhuǎn)但不具有靜態(tài)跳轉(zhuǎn)的子例程。它還允許部分代碼加載，這與 Verkle 很好地配合使用，并增加了合約大小限制。

EIP-5450: EOF - 棧驗(yàn)證^[28]：驗(yàn)證代碼和棧要求。除了 CALLF（EIP-4750）之外的所有指令都刪除了運(yùn)行時(shí)棧下溢和上溢檢查。

EIP-7480: EOF - 數(shù)據(jù)段訪問指令^[29]：允許訪問字節(jié)碼的數(shù)據(jù)段。

EIP-7069: 改進(jìn)的 CALL 指令^[30]：使 CALLs 中的 gas 可觀察性消失，這樣將來更容易進(jìn)行 gas 重新定價(jià)。雖然獨(dú)立于 EOF，但我們認(rèn)為這是一個(gè)引入它的好機(jī)會(huì)。

我們對 EIP-6206: EOF - JUMPF and non-returning functions^[31] 的確定性較低。雖然它允許在 EOF 函數(shù)中進(jìn)行尾調(diào)用優(yōu)化，但我們?nèi)孕枰吹秸Z言分析其有用性。如果我們沒有這個(gè)，我們認(rèn)為可以將其從范圍中剔除，并包含在后續(xù) EOF 更新中。

我們將以上工作預(yù)算為 1-2 個(gè)月，由 1 人全職完成。如果這意味著保持動(dòng)力，我們愿意進(jìn)一步削減上述提到的范圍。

關(guān)于傳統(tǒng)字節(jié)碼的說明：

雖然我們可以禁止新的傳統(tǒng)/非 EOF 字節(jié)碼，但無法廢棄現(xiàn)有的傳統(tǒng)字節(jié)碼，它實(shí)際上充當(dāng) EOF“v0”。傳統(tǒng)字節(jié)碼仍需要在 EOF 后進(jìn)行 JUMPDEST 分析，并且仍需要特殊的代碼處理來將其分段到 Verkle Tries 中。

據(jù)我們所知，在不需要訪問源工件情況下，沒有從非 EOF 字節(jié)碼到 EOF 的可驗(yàn)證轉(zhuǎn)換，但我們愿意調(diào)查促進(jìn)這種轉(zhuǎn)換的機(jī)制。

或者，我們愿意探索強(qiáng)制將狀態(tài)遷移到 EOF 的到期方法。

增加 EIP-4844 Blob 數(shù)量

我們愿意接受這一變化，這將對MAX_BLOB_GAS_PER_BLOCK和TARGET_BLOB_GAS_PER_BLOCK進(jìn)行增加，有關(guān)上下文，請參閱 EIP-4844^[32]：

TARGET_BLOB_GAS_PER_BLOCK 和 MAX_BLOB_GAS_PER_BLOCK 的值被選擇為每個(gè)塊的目標(biāo)為 3 個(gè) blob（0.375 MB），最大為 6 個(gè) blob（0.75 MB）。這些較小的初始限制旨在最大限度地減少此 EIP 對網(wǎng)絡(luò)造成的壓力，并且預(yù)計(jì)將在未來的升級中增加，以便網(wǎng)絡(luò)在更大的塊下表現(xiàn)出可靠性。*

實(shí)際上，這是一個(gè)小的代碼更改，我們需要調(diào)查它在 txpool 中的實(shí)際影響，但我們認(rèn)為我們可以重用 EIP-4844 的壓力測試基礎(chǔ)設(shè)施。共識層可能在傳播更多 blob 時(shí)遇到困難；我們聽取 CL 團(tuán)隊(duì)的意見。

不支持

Verkle Tries^[33]

TL;DR：我們認(rèn)為沒有辦法在 2024 年底/2025 年初部署 Verkle tries。我們建議團(tuán)隊(duì)在 2024 年第二季度分配資源，并承諾在大阪硬分叉中在 2025 年第二季度至第三季度部署。

好處：

通過更小的存儲(chǔ)證明實(shí)現(xiàn)更便宜的輕客戶端。

通過在塊頭中包含讀取的預(yù)狀態(tài)來實(shí)現(xiàn)無狀態(tài)執(zhí)行，這也可能由于靜態(tài)狀態(tài)訪問而導(dǎo)致性能改進(jìn)。

通過對字節(jié)碼進(jìn)行分塊和啟用部分代碼加載來提高合約大小限制。

由于“復(fù)活”狀態(tài)的成本較低，狀態(tài)到期變得更具吸引力。

不足：

工作量大：變更的影響、整合工作實(shí)現(xiàn)以及測試。

Gas 計(jì)費(fèi)變更：Verkle Tries 將見證的大小引入到 gas 計(jì)算函數(shù)中。我們擔(dān)心存儲(chǔ)定價(jià)的變化尚未被探索（例如，Verkle 后的頂級 gas 消耗者的成本將是多少）？

應(yīng)用集成：當(dāng) Overlay 過渡運(yùn)行時(shí)，具有 Merkle Patricia Trie 驗(yàn)證器的應(yīng)用程序應(yīng)該怎么做？eth_getProof行為應(yīng)該怎樣的？

雖然我們理解 Verkle Tries 的好處，但我們認(rèn)為需要更多的思考，以了解第三方工具/合約需要如何適應(yīng)，以及過渡對例如第 2 層解決方案的影響。最初，我們對遷移策略持懷疑態(tài)度，因?yàn)樗?guī)定 Verkle trie 應(yīng)在從現(xiàn)有 MPT 讀取狀態(tài)時(shí)進(jìn)行更新，但現(xiàn)在似乎并非如此。因此，我們支持 Overlay 樹方法作為可行的遷移路徑。

Verkle 遷移策略的文檔似乎普遍過時(shí)，因?yàn)榇蠖鄶?shù)資源仍然指出 Verkle trie 應(yīng)在從 MPT 讀取狀態(tài)時(shí)進(jìn)行更新，盡管情況并非如此。我們希望看到關(guān)鍵的過渡文檔更新為最新的方法，例如這篇優(yōu)秀的文檔^[34] 。我們還希望看到一份關(guān)于過渡策略的草案 EIP。

因此，我們?nèi)匀恢С衷?2025 年推出 Verkle，但在布拉格升級沒有看到部署路徑。

L1 Gas Limit

我們認(rèn)為從引發(fā)需求的角度，提高 L1 gas 限制在實(shí)踐中不會(huì)有太大作用。我們還認(rèn)為大多數(shù)客戶端可以處理平均負(fù)載的增加，但我們希望對最壞情況保持警惕，因此我們暫時(shí)不建議增加 L1 gas 限制。我們認(rèn)為在短期內(nèi)增加 blob gas 限制是更有前途的解決方案。

我們邀請大家與我們合作，進(jìn)行任何關(guān)于這方向的研究，以及圍繞突破 EVM 中的資源計(jì)量方式。Broken Metre paper^[35] 是這一研究方向的一個(gè)很好的起點(diǎn)。

賬戶抽象

我們愿意包含 1 個(gè)或多個(gè)這些 EIP（或協(xié)議實(shí)現(xiàn) ERCs），但我們希望更理想地看到更多的用戶體驗(yàn)和開發(fā)體驗(yàn)比較，以更好地理解各個(gè)提案的權(quán)衡空間和工具集成的工作量。我們正在關(guān)注以下 EIP/ERCs，但請隨時(shí)向我們建議更多：

EIP-3074: AUTH and AUTHCALL opcodes^[36]

ERC-4337: Account Abstraction Using Alt Mempool^[37]

EIP-5806: Delegate transaction^[38]

EIP-5920: PAY opcode^[39]

EIP-6913: SETCODE instruction^[40]

EIP-7377: Migration Transaction^[41]

RIP-7560: Native Account Abstraction - Core EIPs - Fellowship of Ethereum Magicians^[42]

我們想要說明，在上述內(nèi)容中，“賬戶抽象”指的是“抽象驗(yàn)證功能，主要目標(biāo)是啟用密鑰輪換，使多簽名成為一等功能，并為我們提供自動(dòng)的量子抵抗路徑”（h/t VB），只適用于 4337 和 7560，而其他提案則分為兩個(gè)類別，即 gas 贊助和操作批處理。

作者：

Georgios Konstantopoulos^[43]

Georgios Konstantopoulos 是 Paradigm 的首席技術(shù)官和研究合伙人，專注于 Paradigm 的投資組合公司和開源協(xié)議的研究。此前，Georgios 是一名獨(dú)立顧問和研究人員。