本文的目標是概述 Paradigm Reth 團隊[4]對于布拉格硬分叉的看法，布拉格（Prague）是坎昆之后的下一個 EL 硬分叉，以及我們 2024 年“EL 核心開發”計劃的概況。以下觀點正在發展中，僅代表 Reth 團隊當前的觀點，不一定代表更廣泛的 Paradigm 團隊。
我們認為布拉格硬分叉可能在 2024 年第三季度在以太坊測試網上實現，年底在主網上實現。它應該包括：
任何與質押相關的 EIP，比如 EIP-7002，它使重質押(re-staking)和無信任質押池成為可能。
獨立的 EVM 更改。
我們愿意與任何希望進一步研究布拉格或其他未來 EL 硬分叉的團隊合作，樂意指導或提供指導以修改 Reth 代碼庫的位置。
支持:
我們認為以下 EIP 必須優先考慮：7002[5], 6110[6], 2537[7]。
我們支持 EOF，如規范[8]中所述，但希望盡快確定范圍，并創建一個元 EIP，承諾遵守該范圍。
我們愿意增加 EIP-4844 最大 Blob Gas[9] 的版本。我們對正確的數字沒有看法，但我們邀請數據人員與我們合作調查這個問題。
我們愿意發布 EIP-7547：包含列表[10]的版本，以幫助基礎層抗審查。
不支持:
我們不支持在布拉格中使用 Verkle Tries[11]，但我們支持客戶端團隊從 2024 年第二季度開始努力實現它，并承諾在 2025 年中期/晚期在大阪發布。
我們不認為應該增加 L1 執行 Gas 限制或合約大小，但我們邀請數據人員與我們合作調查對網絡的影響。我們愿意修改我們的看法，因為過去的測試表明 Reth 節點可以處理增加的負載而沒有問題。
我們認為錢包/賬戶抽象 EIP 需要更多相互對抗的測試，以更好地理解權衡空間。如果它們不是相互排斥的，那么我們愿意在未來部署多個 AA 相關的 EIP。
如果社區對傳聞中[12]的NSA[13]后門[14] OK ，我們可以接受 EIP-7212（secp256r1）。
其他路線圖主題：我們對 CL EIP 或 CL/EL 分叉的耦合沒有具體看法，但 EIP 7549[15]和 7251[16] 似乎很有前景。我們還希望在 EL 方面盡可能地為 PeerDAS 的工作做出貢獻。我們希望暫時避免引入 SSZ 根（EIP 6404, 6465, 6466）。最后，我們注意到為過期的 Blob、歷史和狀態提供長期數據存檔解決方案的機會，因為 EIP-4844[17] 和EIP-4444[18]都沒有指定這一點，以及以太坊是否愿意提供這樣的解決方案。
以下是推理。
抽象地說，我們支持 1)進一步彌合 CL 和 EL 之間的差距，2) EVM 修改可以作為單人工作執行，并且可以在隔離和并行測試。
這個 EIP 通過使 EL 側的智能合約控制 CL 側的一個或多個驗證者，解鎖了無信任的重新質押和質押池。從我們的角度來看，這是一個不需要思考的 EIP，因為至少它將使現有的質押池能夠從實施其提款的智能合約中去除一層中心化。
在 EVM 實現中引入有狀態的預編譯是我們需要在 EVM 實現中捕獲的新抽象，但除此之外，我們認為這是一個可以直接執行的 EIP。
這個 EIP 在 EL 狀態中引入了存款，簡化了 CL 上需要進行的狀態管理。在實施上，這類似于跟蹤 CL 提款，因此總體上我們認為這也是一個容易實現且獨立的 EIP 。
現在外面有多個 BLS12-381 的實現，它是許多 SNARKs、BLS 簽名算法和 EIP-4844 中經常使用的曲線。我們認為實現復雜性低，因為它只是通過預編譯接口公開了曲線的驗證算法。可能我們還想要一個 Hash 到 BLS12-381 曲線的預編譯。
TL;DR：支持一個 Solidity 和 Vyper 將采用的范圍明確的版本。使分析更容易的代碼格式和驗證調整是一個不需要思考的事情，我們建議進一步修剪。
好處：
只有 EVM 的更改，可以通過以太坊/tests 進行測試，并由一人實施。
做 Vyper 和 Solidity 想要的 EVM 更改！
有助于性能和提高合約限制大小。
通過 EVM 在運行時消除了對字節碼的分析的需要，當沒有緩存時，這可能占用時間的 50%，隨著合約大小的增加而增加。
可以部分加載代碼，有助于執行大型合約。
Devex：將允許在 Solidity 中使用 dupN/swapN 修復“Stack Too deep”，以及其他工具改進。
未來驗證：可以安全地引入新功能到 L2，并且工具將知道什么是兼容的。
不足：
變化了目標。
沒有支持者極力推動它的加入。
仍然需要支持舊代碼
直到被采用之前，以太坊主網和其他 EVM 鏈之間會有暫時的分歧。
我們認為以下 EOF 功能應該在 2024 年部署。我們建議盡快確定范圍并承諾遵守。其他任何事情應該考慮后續部署。我們的建議：
EIP-3540: EOF - EVM 對象格式 v1[23]：引入代碼和數據容器，并為以太坊字節碼添加結構和版本。
EIP-3670: EOF - 代碼驗證[24]：在部署時拒絕任何不遵循 EOF 格式的合約。強制更結構化的代碼，并禁用無效和未定義的指令。
EIP-663: 無限的 SWAP 和 DUP 指令[25]：這解決了 Solidity 中的“Stack Too Deep”問題，通過 JUMPDEST 分析作為即刻值可能會產生副作用。EVM 語言非常希望有這樣的功能。
EIP-4200: EOF - 靜態相對跳轉[26]：更好的靜態分析，沒有不確定的跳轉。更好的 aot 編譯。相對跳轉對代碼的可重用性更好。
EIP-4750: EOF - 函數[27]：需要處理可能具有動態跳轉但不具有靜態跳轉的子例程。它還允許部分代碼加載，這與 Verkle 很好地配合使用，并增加了合約大小限制。
EIP-5450: EOF - 棧驗證[28]：驗證代碼和棧要求。除了 CALLF（EIP-4750）之外的所有指令都刪除了運行時棧下溢和上溢檢查。
EIP-7480: EOF - 數據段訪問指令[29]：允許訪問字節碼的數據段。
EIP-7069: 改進的 CALL 指令[30]：使 CALLs 中的 gas 可觀察性消失，這樣將來更容易進行 gas 重新定價。雖然獨立于 EOF，但我們認為這是一個引入它的好機會。
我們對 EIP-6206: EOF - JUMPF and non-returning functions[31] 的確定性較低。雖然它允許在 EOF 函數中進行尾調用優化，但我們仍需要看到語言分析其有用性。如果我們沒有這個，我們認為可以將其從范圍中剔除，并包含在后續 EOF 更新中。
我們將以上工作預算為 1-2 個月，由 1 人全職完成。如果這意味著保持動力，我們愿意進一步削減上述提到的范圍。
關于傳統字節碼的說明：
雖然我們可以禁止新的傳統/非 EOF 字節碼，但無法廢棄現有的傳統字節碼，它實際上充當 EOF“v0”。傳統字節碼仍需要在 EOF 后進行 JUMPDEST 分析，并且仍需要特殊的代碼處理來將其分段到 Verkle Tries 中。
據我們所知，在不需要訪問源工件情況下，沒有從非 EOF 字節碼到 EOF 的可驗證轉換，但我們愿意調查促進這種轉換的機制。
或者，我們愿意探索強制將狀態遷移到 EOF 的到期方法。
我們愿意接受這一變化，這將對MAX_BLOB_GAS_PER_BLOCK和TARGET_BLOB_GAS_PER_BLOCK進行增加，有關上下文，請參閱 EIP-4844[32]：
TARGET_BLOB_GAS_PER_BLOCK 和 MAX_BLOB_GAS_PER_BLOCK 的值被選擇為每個塊的目標為 3 個 blob（0.375 MB），最大為 6 個 blob（0.75 MB）。這些較小的初始限制旨在最大限度地減少此 EIP 對網絡造成的壓力，并且預計將在未來的升級中增加，以便網絡在更大的塊下表現出可靠性。*
實際上，這是一個小的代碼更改，我們需要調查它在 txpool 中的實際影響，但我們認為我們可以重用 EIP-4844 的壓力測試基礎設施。共識層可能在傳播更多 blob 時遇到困難；我們聽取 CL 團隊的意見。
TL;DR：我們認為沒有辦法在 2024 年底/2025 年初部署 Verkle tries。我們建議團隊在 2024 年第二季度分配資源，并承諾在大阪硬分叉中在 2025 年第二季度至第三季度部署。
好處：
通過更小的存儲證明實現更便宜的輕客戶端。
通過在塊頭中包含讀取的預狀態來實現無狀態執行，這也可能由于靜態狀態訪問而導致性能改進。
通過對字節碼進行分塊和啟用部分代碼加載來提高合約大小限制。
由于“復活”狀態的成本較低，狀態到期變得更具吸引力。
不足：
工作量大：變更的影響、整合工作實現以及測試。
Gas 計費變更：Verkle Tries 將見證的大小引入到 gas 計算函數中。我們擔心存儲定價的變化尚未被探索（例如，Verkle 后的頂級 gas 消耗者的成本將是多少）？
應用集成：當 Overlay 過渡運行時，具有 Merkle Patricia Trie 驗證器的應用程序應該怎么做？eth_getProof行為應該怎樣的？
雖然我們理解 Verkle Tries 的好處，但我們認為需要更多的思考，以了解第三方工具/合約需要如何適應，以及過渡對例如第 2 層解決方案的影響。最初，我們對遷移策略持懷疑態度，因為它規定 Verkle trie 應在從現有 MPT 讀取狀態時進行更新，但現在似乎并非如此。因此，我們支持 Overlay 樹方法作為可行的遷移路徑。
Verkle 遷移策略的文檔似乎普遍過時，因為大多數資源仍然指出 Verkle trie 應在從 MPT 讀取狀態時進行更新，盡管情況并非如此。我們希望看到關鍵的過渡文檔更新為最新的方法，例如這篇優秀的文檔[34] 。我們還希望看到一份關于過渡策略的草案 EIP。
因此，我們仍然支持在 2025 年推出 Verkle，但在布拉格升級沒有看到部署路徑。
我們認為從引發需求的角度，提高 L1 gas 限制在實踐中不會有太大作用。我們還認為大多數客戶端可以處理平均負載的增加，但我們希望對最壞情況保持警惕，因此我們暫時不建議增加 L1 gas 限制。我們認為在短期內增加 blob gas 限制是更有前途的解決方案。
我們邀請大家與我們合作，進行任何關于這方向的研究，以及圍繞突破 EVM 中的資源計量方式。Broken Metre paper[35] 是這一研究方向的一個很好的起點。
我們愿意包含 1 個或多個這些 EIP（或協議實現 ERCs），但我們希望更理想地看到更多的用戶體驗和開發體驗比較，以更好地理解各個提案的權衡空間和工具集成的工作量。我們正在關注以下 EIP/ERCs，但請隨時向我們建議更多：
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]
我們想要說明，在上述內容中，“賬戶抽象”指的是“抽象驗證功能，主要目標是啟用密鑰輪換，使多簽名成為一等功能，并為我們提供自動的量子抵抗路徑”（h/t VB），只適用于 4337 和 7560，而其他提案則分為兩個類別，即 gas 贊助和操作批處理。
作者：
Georgios Konstantopoulos[43]
Georgios Konstantopoulos 是 Paradigm 的首席技術官和研究合伙人，專注于 Paradigm 的投資組合公司和開源協議的研究。此前，Georgios 是一名獨立顧問和研究人員。
喜來順財經
