Paradigm CTO：以太坊坎昆升級後，下一次布拉格升級會有哪些動作？

吳說區塊鏈

2024-01-21 10:14:17

這篇文章的目的是概述 Paradigm Reth 團隊對於哪些 EIP（以太坊改進提案）應該被包含在布拉格（Prague）中的觀點。

分享至

微信掃碼

原文標題：What comes after Ethereum's Cancun hard fork?

原文作者：Georgios Konstantopoulos，Paradigm Research Partner \& CTO

原文編譯：defioasis，吳說區塊鏈

摘要

這篇文章的目的是概述 Paradigm Reth 團隊對於哪些 EIP（以太坊改進提案）應該被包含在布拉格（Prague）中的觀點，布拉格是繼坎昆之後的下一個 EL（以太坊執行層）硬分叉，以及我們 2024 年的"EL 核心開發者"計劃概況。以下觀點仍在不斷發展中，僅代表 Reth 團隊當前的看法，不一定代表更廣泛的 Paradigm 團隊的觀點。

我們認為，在 2024 年第三季度，布拉格硬分叉在以太坊測試網上是可行的，並且在年底之前可以在主網實施。它應該包括：

（1）與質押相關的 EIPs，例如 EIP-7002，它使得再質押（re-staking）和無需信任的質押池成為可能。

（2）獨立的 EVM 變更。

（3）我們願意與任何想要進一步探究布拉格或其他未來 EL 硬分叉的困難問題的團隊合作，樂於提供指導或接收對 Reth 代碼庫進行修改的建議。

建議事項：

（1）我們認為以下 EIP 應優先考慮：7002、6110、2537。

（2）我們支持 EOF 如規範中所描述，但希望儘快確定範圍並創建一個 meta-EIP 來承諾這一範圍。（注：EOF 代表 EVM 對象格式，其對以太坊的代碼執行環境進行了一些更改。有開發者提議將 EOF 納入下次執行層升級 Prague 中，但目前觀點不一，有些認為其規範尚未最終確定，有些認為 Verkle Tries 才是下次升級的重點）

（3）我們對增加 EIP-4844 最大 Blob Gas 持開放態度。我們對正確數字沒有具體看法，但邀請數據領域的專家與我們合作調查這個主題。（注：Blob 是一種用於存儲 L2 向 L1 提交交易數據的存儲結構，並擁有自己的定價系統 Blob Gas）

（4）我們對推出 EIP-7547: 包含列表（Inclusion lists）持開放態度，以幫助提高基層審查抵抗力。

不建議事項：

（1）我們不支持在布拉格中引入 Verkle Tries，但支持客戶端團隊從 2024 年第二季度開始朝這個方向努力，並承諾在 2025 年中/晚期的大阪（Osaka）中實施它。（注：未來以太坊將轉向的一種數據結構，相比當前的 Merkle Trie 結構，Verkle 有證明大小和驗證效率等方面優勢，是未來以太坊實現無狀態不可缺少的一環）

（2）我們認為不應該增加 L1 執行 Gas 限制或合約大小，但我們邀請數據專家與我們合作研究這對網絡的影響。我們對此持開放態度，因為過去的測試顯示 Reth 節點可以在不出問題的情況下處理增加的負載。

（3）我們認為錢包/賬戶抽象的 EIP 需要更多相互間的實戰測試，以更好地了解它們之間的權衡空間。如果它們不是相互排斥的，那麼我們未來願意部署多個與 AA（賬戶抽象）相關的 EIP。

（4）對於 EIP-7212（secp256r1），如果社區對傳聞中的 NSA（美國國家安全局）後門沒有意見，我們可能會支持它。

（5）其他路線圖主題：我們對 CL（共識層）EIP 或 CL/EL（執行層）分叉的耦合沒有直接的看法，但 EIP-7549 和 EIP-7251 看起來很有前景。我們也願意在可能的情況下，從 EL 方面貢獻於 PeerDAS 的工作。我們目前希望避免引入 SSZ 根（EIP-6404、6465、6466）。最後，我們注意到，對於過期的 blobs、歷史和狀態，有一個長期的數據存檔解決方案的機會，因為 EIP-4844 和 EIP-4444 都沒有指定這一點，而以太坊是否想提供這樣的解決方案還有待確定。

具體理由如下

建議事項

我們支持1）進一步縮小共識層（CL）和執行層（EL）之間的差距；2）EVM 的修改，這些修改可以作為單人工作執行，並且可以隔離和並行地進行測試。

EIP-7002

這個 EIP 通過允許執行層（EL）的智能合約控制共識層（CL）的一个或多個驗證器，解鎖了無需信任的再質押和質押池。從我們的角度來看，這是一個不費思考的 EIP，因為它至少可以使現有的質押池從實施其提款的智能合約中去除一個集中化層。

我們需要在 EVM 實現中捕獲到引入狀態預編譯的新抽象，但除此之外，我們認為這是一個可以直接執行的 EIP。

EIP-6110

這個 EIP 在執行層（EL）狀態中引入了存款，簡化了在共識層（CL）上需要進行的狀態管理。從實現的角度來看，這類似於追蹤共識層的提款，所以總的來說，我們認為這也是一個容易實施且獨立的 EIP。

EIP-2537

目前市面上已經有多種 BLS12-381 的實現，它是在許多 SNARKs（零知識證明技術）、BLS 簽名算法和 EIP-4844 中頻繁使用的曲線。我們認為實現複雜度較低，因為它只是在預編譯接口上公開了曲線的驗證算法。我們可能還需要 BLS12-381 曲線預編譯的哈希算法。

EOF

簡要總結：支持 Solidity 和 Vyper 會採用的明確範圍版本。代碼格式和驗證調整使分析變得更容易，這是毋庸置疑的選擇，我們建議對此之外的任何內容進行仔細考慮。我們在下面推薦了一些 EIP，但我們也願意進一步精簡。

好處：

（1）僅限 EVM 的變更，可以通過 ethereum/tests 進行測試，並由一個人實施。

（2）Vyper 和 Solidity 想要的 EVM 變更。

（3）有助於提高性能和增加合約大小限制。

（4）無需 EVM 在運行時進行字節碼分析，在不涉及緩存的情況下，這種分析可能需要多達 50% 的時間，並隨著合約大小的增加而增加。

（5）支持部分代碼加載，有助於執行大型智能合約。

（6）開發者體驗：將允許在 solidity 中使用 dupN/swapN 修復 "堆棧過深 "問題，並改進其他工具。

（7）未來驗證：可以在 L2s 中安全地引入新功能，並且工具知道哪些是兼容的。

不足之處：

（1）範圍和移動目標。

（2）沒有支持者大力推動將其納入。

（3）仍需支持遺留代碼。

（4）在被採用之前，以太坊主網與其他 EVM 鏈之間暫時存在分歧。

我們認為以下 EOF 功能應該在 2024 年部署。我們建議儘快確定範圍並承諾堅持。其他內容應考慮用於後續部署。我們的建議：

（1）EIP-3540：EOF - EVM 對象格式 v1：引入代碼和數據容器，並為以太坊字節碼添加結構和版本控制。

（https://eips.ethereum.org/EIPS/eip-3540）

（2）EIP-3670：EOF - 代碼驗證：拒絕部署時不遵循 EOF 格式的合約。強制實施更加結構化的代碼，並禁用無效和未定義的指令。

（https://eips.ethereum.org/EIPS/eip-3670）

（3）EIP-663：無限制的 SWAP 和 DUP 指令：這解決了 Solidity 中的"堆棧過深"問題，因為 JUMPDEST 分析作為立即值可能會產生副作用。這對 EVM 語言非常有益。

（https://eips.ethereum.org/EIPS/eip-663）

（4）EIP-4200：EOF - 靜態相對跳轉：更好的靜態分析，沒有不確定的跳轉。更好的 AOT 編譯。相對跳轉更有利於代碼重用。

（https://eips.ethereum.org/EIPS/eip-4200）

（5）EIP-4750：EOF - 函數：需要解決可使用動態跳轉但不能使用靜態跳轉的子程序問題。它還允許部分代碼加載，這與 Verkle 和增加合約大小限制的功能配合得很好。

（https://eips.ethereum.org/EIPS/eip-4750）

（6）EIP-5450：EOF - 堆棧驗證：驗證代碼和堆棧要求。除了 CALLF（EIP-4750）指令外，移除所有指令的運行時堆棧下溢和上溢檢查。

（https://eips.ethereum.org/EIPS/eip-5450）

（7）EIP-7480：EOF - 數據段訪問指令：允許訪問字節碼的數據段。

（https://eips.ethereum.org/EIPS/eip-7480）

（8）EIP-7069：改進的 CALL 指令：使得從 CALLs 中移除 Gas 可觀測性成為可能，這有助於未來更容易地對 Gas 進行重新定價。雖然與 EOF 無關，但我們認為這是引入它的好機會。

（https://eips.ethereum.org/EIPS/eip-7069）

關於 EIP-6206：EOF - JUMPF 和非返回函數，我們的看法不那麼確定。雖然它允許在 EOF 函數中進行尾部調用優化，但我們仍需要看到語言分析其有效性。如果沒有這種分析，我們認為從範圍中剔除它，並在後續的 EOF 更新中包含它是可行的。

我們預計上述工作由一人全職進行，需要 1-2 個月的時間。如果縮減上述提到的範圍意味著保持進展，我們願意進一步縮減。

關於遺留字節碼的說明：

（1）雖然我們可以禁止新的遺留/非 EOF 字節碼，但沒有辦法淘汰現有的遺留字節碼，這實際上充當了 EOF 的"v0"版本。遺留字節碼在 EOF 之後仍然需要 JUMPDEST 分析，並且在 Verkle Tries 中將其分段仍然需要特殊的代碼處理。

（2）據我們所知，沒有辦法在沒有源代碼工件的情況下，將非 EOF 字節碼可驗證地轉換為 EOF，但我們願意探索促進此類轉換的機制。

（3）另外，我們也願意探索強制將狀態遷移到 EOF 的失效方法。

增加 EIP-4844 Blob 數量

我們對這一變更持開放態度，這將相應地增加 MAXBLOBGASPERBLOCK（每個區塊的最大 Blob Gas 限制）和 TARGETBLOBGASPERBLOCK（每個區塊的目標 Blob Gas 限制）。

以 EIP-4844 為背景：TARGETBLOBGASPERBLOCK 和 MAXBLOBGASPERBLOCK 的值被選定為對應於每個區塊 3 個 blobs（0.375 MB）的目標和 6 個 blobs（0.75 MB）的最大值。這些小的初始限制旨在最小化這個 EIP 對網絡造成的壓力，並預計將在未來的升級中增加，因為網絡在更大區塊下展示出可靠性。

實際上這是一個小的代碼變更，我們需要調查其在交易池中的實際影響，但我們認為可以重用 EIP-4844 的壓力測試基礎設施來進行這項工作。CL（共識層）可能在傳播更多 blobs 方面有更大的困難；我們聽從 CL 團隊的意見。

不建議事項：

Verkle Tries

我們看不到在 2024 年底到 2025 年初部署 Verkle tries 的路徑。我們建議團隊在 2024 年第二季度為此分配資源，並承諾在 2025 年第二季度至第三季度的大阪硬分叉中進行部署。

好處：

（1）通過更小的存儲證明，實現更便宜的輕客戶端。

（2）通過在區塊頭部包含讀取預狀態實現無狀態執行，這也可能由於靜態狀態訪問而帶來性能提升。

（3）通過分塊字節碼和啟用部分代碼加載，提高合約大小限制。

（4）隨著"revive"狀態的成本降低，狀態過期變得更加可行。

不足之處：

（1）變更的影響以及實施和測試的整合工作量。

（2）Gas 計算更改：Verkle tries 引入了見證大小到 Gas 計算函數中。我們擔心尚未對存儲定價的變化進行探討（例如，Verkle 之後，頂級 Gas 消耗者的成本會是多少）。

（3）應用集成：在 Overlay 轉換運行期間，帶有 Merkle Patricia Trie 驗證器的應用應該做些什麼？eth_getProof 應該如何表現？

儘管我們理解 Verkle tries 的好處，但我們認為需要更多的思考關於第三方工具/合約需要如何適應，以及轉換將對例如 Layer 2 解決方案等產生什麼影響。最初我們對遷移策略表示懷疑，因為它規定當從現有的 MPT（Merkle Patricia Trie）讀取狀態時，應該更新 Verkle tries，但現在似乎不再是這種情況。因此，我們支持 overlay tree 方法作為一種可行的遷移路徑。

有關 Verkle 遷移策略的文檔總體上似乎已經過時，因為大多數資源仍然指出，當從 MPT 中讀取狀態時，Verkle trie 應該更新，儘管事實並非如此。我們希望看到用最新方法更新關鍵轉換文檔（如：https://notes.ethereum.org/@parithosh/verkle-transition）。我們還希望看到關於過渡策略的 EIP 草案。

因此，我們仍然支持在 2025 年推出，但不認為它應該在布拉格分叉中部署。

L1 Gas 限制

我們認為，由於派生需求，提高 L1 Gas 限值在實踐中不會有太大作用。我們還認為，大多數客戶端可以處理平均負載增加，但我們希望對最壞的情況保持警惕，因此我們還不能建議提高 L1 Gas 限制。我們認為，在短期內，增加 Blob Gas 限制是一個更有前途的解決方案。

賬戶抽象

我們對納入其中一個或多個 EIP（或將 ERC 納入其中）持開放態度，但我們更希望看到每個提案之間更多的用戶體驗和開發者體驗比較，以便更好地了解工具集成的權衡空間和工作量。我們關注以下 EIP/ERC，但歡迎向我們提出更多建議：

（1）EIP-3074：AUTH 和 AUTHCALL 操作碼

（https://eips.ethereum.org/EIPS/eip-3074）

（2）ERC-4337：使用 Alt Mempool 的賬戶抽象

（https://eips.ethereum.org/EIPS/eip-4337）

（3）EIP-5806：代理交易

（https://eips.ethereum.org/EIPS/eip-5806）

（4）EIP-5920：PAY 操作碼