Paradigm CTO：以太坊坎昆升級之後會發生什麼事？

作者：Georgios Konstantopoulos，Paradigm；編譯：松雪，金色財經

TL;DR

這篇文章的目的是概述Paradigm Reth 團隊對哪些EIP 應該包含在布拉格、坎昆之後的下一個EL 硬分叉以及我們2024 年「EL Core Dev」總體計劃的看法。以下觀點不斷發展，僅代表Reth 團隊目前的觀點，不一定代表Paradigm 團隊。

我們認為布拉格硬分叉可能會在2024 年第三季在以太坊測試網路上實現，並在年底在主網上實現。它應該包括：

• 任何與質押相關的EIP，例如EIP-7002，它支持重新質押和無需信任的質押池。

• 孤立的EVM 變化。

• 我們願意與任何想要進一步調查布拉格或其他未來EL 硬分叉的難題的團隊合作，並樂意指導或提供修改Reth 程式碼庫的指導。

做什麼：

• 我們認為以下EIP必須優先考慮：7002、6110、2537。

• 我們支援規範中所述的EOF，但希望盡快確定範圍，並創建一個致力於該範圍的元EIP。

• 我們願意增加EIP-4844 Max Blob Gas。我們對正確的數字沒有看法，但我們邀請數據人員與我們合作調查這個主題。

• 我們願意發布EIP-7547 的版本：包含列表，以幫助抵抗基礎層審查。

不做什麼：

• 我們不支持布拉格的Verkle Tries，但支援客戶團隊在2024 年第二季開始為此努力，並承諾於2025 年中/下旬在大阪升級發布。

• 我們認為不應該增加L1 執行Gas 限製或合約規模，但我們邀請資料人員與我們合作調查對網路的影響。我們願意修改我們的看法，因為過去的測試表明Reth 節點可以毫無問題地處理增加的負載。

• 我們認為錢包/帳戶抽象化EIP 需要進行更多的相互對抗測試，以便更好地了解權衡空間。如果它們不相互排斥，那麼我們將願意在未來部署多個與AA 相關的EIP。

• 如果社群同意傳聞中的NSA 後門，我們就可以越過EIP-7212 (secp256r1) 的線路。

• 其他路線圖主題：我們對CL EIP 或CL/EL 分叉的耦合沒有實際的看法，但EIP 7549 和7251 似乎很有前途。我們也希望盡可能從EL 方面為PeerDAS 的工作做出貢獻。目前我們希望避免引入SSZ 根（EIP 6404、6465、6466）。最後，我們觀察到，有機會為過期的blob、歷史記錄和狀態提供長期資料歸檔解決方案，因為EIP-4844 和EIP-4444 都沒有指定這一點，而且以太坊是否願意提供這樣的解決方案還有待確定。

以下是內容詳述。

要做什麼：

抽像地說，我們支持1) 進一步縮小CL 和EL 之間的差距，2) EVM 修改可以作為1 人作業執行，並且可以單獨和並行測試。

EIP-7002

此EIP 透過使EL 側的智能合約能夠控制CL 側的1 個或多個驗證器來解鎖無需信任的重新質押和質押池。從我們的角度來看，EIP 是理所當然的，至少它將使現有的質押池能夠從實現提款的智能合約中消除一層中心化。

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

EIP-6110

這引入了EL 狀態中的存款，簡化了需要在CL 上完成的狀態管理。在實施方面，這類似於追蹤CL 提款，因此總的來說，我們認為這也是一個易於實施且隔離的EIP。

EIP-2537

目前BLS12-381 有多種實現，它是許多SNARK、BLS 簽章演算法和EIP-4844 中經常使用的曲線。我們認為實現複雜度較低，因為它只是透過預編譯介面公開曲線的驗證演算法。我們可能還需要BLS12-381 曲線預編譯的雜湊值。

EOF

TL;DR：支援Solidity 和Vyper 將採用的廣泛的版本。讓分析變得更容易的程式碼格式和驗證調整是理所當然的，我們建議仔細考慮除此之外的任何內容。我們在下面推薦了一些EIP，但我們願意進一步調整。

好的方面：

• 僅限EVM 的更改，可以使用以太坊進行測試並由1 人實施。

• Vyper 和Solidity 想要的EVM 改變！

• 有助於提高績效並增加合約規模限制。

• 消除了EVM 在運行時進行字節碼分析的需要，在不涉及快取的情況下，分析的時間可能高達50%，並且隨著合約大小的增加而增加。

• 啟用部分程式碼加載，有助於執行大型智能合約。

• Devex：將允許透過dupN/swapN 和其他工具改進來修復「堆疊太深」的問題。

• 面向未來：可以安全地在L2 中引入新功能，並且工具會知道什麼是相容的。

壞的方面：

• 範圍和動態目標。

• 沒有支持者大力推動將其納入其中。

• 遺留程式碼仍然需要支援。

• 在採用之前，以太坊主網和其他EVM 鏈之間存在暫時分歧。

我們認為以下EOF 功能應在2024 年部署。我們建議盡快確定範圍並承諾實施。後續部署應該考慮其他任何事情。我們的建議：

• EIP-3540：EOF – EVM 物件格式v1：引入程式碼和資料容器，並為以太坊字節碼添加結構和版本控制。

• EIP-3670：EOF – 代碼驗證：拒絕部署時不遵循EOF 格式的任何合約。實施更結構化的程式碼並停用無效和未定義的指令。

• EIP-663：無限的SWAP 和DUP 指令：這解決了可靠性中的「堆疊太深」問題，JUMPDEST 分析作為即時值可能會產生副作用。 evm langs 非常想實現的功能。

• EIP-4200：EOF – 靜態相對跳轉：更好的靜態分析，沒有不確定的跳轉。更好的aot 編譯。相對跳轉更有利於程式碼的可重用性。

• EIP-4750：EOF – 功能：需要解決可以使用動態跳轉但不能使用靜態跳轉的子程式。它還允許部分程式碼加載，這與Verkle 配合良好並增加了合約大小限制。

• EIP-5450：EOF – 堆疊驗證：驗證程式碼和堆疊要求。刪除CALLF 以外的所有指令的執行時間堆疊下溢和溢位檢查(EIP-4750)。

• EIP-7480：EOF – 資料部分存取指令：允許存取字節碼的資料部分。

• EIP-7069：改進的CALL 指令：能夠從CALL 中刪除Gas 可觀察性，從而使未來更容易重新定價Gas。雖然獨立於EOF，但我們認為這是引入它的好機會。

我們對EIP-6206 不太確定：EOF – JUMPF 和非返回函數。雖然它允許在EOF 函數中進行尾部呼叫優化，但我們仍然需要看到語言分析其有用性。如果我們沒有，我們認為可以將其從範圍中刪除並包含在後續EOF 更新中。

我們將上述工作強度為1 人全職工作1-2 個月。如果這意味著保持勢頭，我們願意進一步縮小上述範圍。

關於遺留字節碼的註解：

• 雖然我們可以禁止新的遺留/非EOF 字節碼，但無法棄用現有的遺留字節碼，它實際上充當EOF“v0”。遺留字節碼仍然需要EOF 後的JUMPDEST 分析，並且仍然需要特殊的程式碼處理以將其分段為Verkle Tries 中的區塊。

• 據我們所知，如果不存取原始程式碼，就無法驗證從非EOF 位元組到EOF 的轉換，但我們願意研究促進這種轉換的機制。

• 或者，我們願意探索強制狀態遷移到EOF 的到期方法。

增加EIP-4844 Blob 計數

我們對此更改持開放態度，這對應於MAX_BLOB_GAS_PER_BLOCK 和TARGET_BLOB_GAS_PER_BLOCK 的增加，適用於EIP-4844 的上下文：

> 選擇TARGET_BLOB_GAS_PER_BLOCK 和MAX_BLOB_GAS_PER_BLOCK 的值以對應每個區塊3 個blob (0.375 MB) 的目標和最多6 個blob (0.75 MB)。這些小的初始限制旨在最大限度地減少該EIP 對網路造成的壓力，並且隨著網路在較大區塊下展現可靠性，預計會在未來的升級中增加。

實際上，這是一個小的程式碼更改，我們需要調查它在txpool 中的實際影響，但我們認為我們可以為此重新使用EIP-4844 壓力測試基礎設施。 CL 可能很難傳播更多的blob； 我們尊重CL 隊伍的意見。

不做什麼：

Verkle Tries

TL;DR：我們看不到2024 年底/2025 年初部署Verkle 嘗試的路徑。我們建議團隊在2024 年第二季為此分配資源，並承諾在2025 年第二季至第三季在大阪硬分叉中部署。

好的方面：

• 透過更小的儲存證明實現更便宜的輕客戶端。

• 透過在區塊的標頭中包含讀取預狀態來進行無狀態執行，這也可能由於靜態狀態存取而導致效能提高。

• 透過對字節碼進行分塊並啟用部分程式碼載入來提高合約大小限制。

• 由於「恢復」狀態的成本較低，狀態到期變得更容易接受。

壞的方面：

• 實施和測試的變更和整合工作的影響。

• Gas 會計變化：Verkle 嘗試將見證人的大小引入Gas 計算功能中。我們擔心儲存定價的變化尚未被探索（例如，Verkle 後頂級Gas消耗企業的成本是多少）？

• 應用程式整合：當Overlay 轉換運行時，具有Merkle Patricia Trie 驗證器的應用程式應該做什麼？ eth_getProof 應該如何表現？

雖然我們了解Verkle Tries 的好處，但我們認為需要更多地考慮第3 方工具/合約需要如何適應，以及過渡會對Layer2產生什麼影響。最初我們對遷移策略有疑問，因為它規定當從預先存在的MPT 讀取狀態時應該更新Verkle trie，但情況似乎不再如此了。因此，我們支援Overlay方法作為可行的遷移路徑。

Verkle 遷移策略的文檔通常似乎已經過時，因為大多數資源仍然指出從MPT 讀取狀態時應該更新Verkle trie，即使事實並非如此。我們希望看到關鍵的過渡文件使用最新的方法進行更新，例如這個優秀的文檔。我們也希望看到有關過渡策略的生態投資計畫草案。

因此，我們仍然支援其在2025 年推出，但不是在布拉格硬分叉進行部署。

L1 Gas限制

我們認為，由於誘導需求，提高L1 Gas 限制在實務上不會產生太大作用。我們也認為大多數客戶可以應對平均負載增加，但我們希望對最壞的情況保持警惕，因此我們尚不建議增加L1 Gas 限制。我們認為增加blob Gas 限制是短期內更有希望的解決方案。

我們邀請人們與我們合作進行該方向的任何研究，通常圍繞著打破EVM 中的資源計量進行。 《Broken Metre: Attacking Resource Metering in EVM》論文是這一研究領域的一個很好的起點。

帳戶抽象

我們願意包含1 個或多個EIP（或納入ERC），但我們理想地希望看到每個提案之間有更多的UX 和DevEx 比較，以更好地了解工具整合的權衡空間和工作量。我們正在關注以下EIP/ERC，但請隨時向我們建議更多：

• EIP-3074：AUTH 和AUTHCALL 操作碼；

• ERC-4337：使用Alt Mempool 進行帳戶抽象化；

• EIP-5806：委託交易；

• EIP-5920：PAY 操作碼；

• EIP-6913：SETCODE 指令；

• EIP-7377：遷移事務；

• RIP-7560：本機帳號抽象- 核心EIP – Fellowship of Ethereum Magicians。

我們想在上面警告一下，「帳戶抽象」就像「抽象驗證函數，主要目標是啟用金鑰輪換，使多重簽章成為一流，並為我們提供一條自動實現量子抗性的路徑」 (h/t VB ) 僅適用於上面的4337 和7560。