Paradigm:以太坊坎昆硬分叉之後會發生什麼?

博主:NaiveNaive 2024-01-23 246
Paradigm:以太坊坎昆硬分叉之後會發生什麼?

  TL;DR

  這篇文章的目的是概述 Paradigm Reth 團隊對哪些 EIP 應該包含在 Prague、坎昆升級之後的下一個 EL 硬分叉以及關於 2024 年「EL Core Dev」總體計劃的看法。以下觀點是不斷變化的,僅代表 Reth 團隊當前的觀點,不一定代表更廣泛的 Paradigm 團隊。

  我們認為Prague硬分叉有可能於 2024 年第三季度在以太坊測試網上進行,並於年底在主網上進行。它應該包括:

  任何與質押相關的 EIP,如 EIP-7002,它可以實現重新質押和無信任質押池;

  孤立的 EVM 變化。

  我們願意與任何希望進一步研究Prague或其他未來 EL 硬分叉問題的團隊合作,並歡迎指導或提供有關修改 Reth 代碼庫的指導。

  支持:

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

  我們支持規範中描述的 EOF,但希望盡快確定其範圍,並創建一個該範圍的元 EIP。

  我們對增加 EIP-4844 Max Blob Gas 持開放態度。我們對合適的數字還沒有定論,但我們邀請數據人員與我們一起研究該問題。

  我們願意提供 EIP-7547 版本:納入列表,以幫助抵制基礎層審查。

  不支持:

  我們不支持在Prague中的 Verkle Tries,但支持客戶團隊在 2024 年第 2 季度開始努力,並承諾在 2025 年中/末在 Osaka 中交付。

  我們認為不應增加 L1 執行Gas限額或合約規模,但我們邀請數據人員與我們合作,共同調查對網絡的影響。由於過去的測試表明 Reth 節點可以順利處理增加的負載,因此我們願意修改我們的觀點。

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

  如果社區對傳言中的NSA後門沒有意見,我們可能會在 EIP-7212 (secp256r1) 中取得突破。

  其他路線圖主題: 我們對 CL EIP 或 CL/EL 分叉的耦合沒有實際看法,但 EIP 7549 和 7251 似乎很有前途。我們還希望在可能的情況下,從 EL 方面為 PeerDAS 的工作做出貢獻。目前,我們希望避免引入 SSZ 根(EIP 6404、6465、6466)。最後,我們註意到,EIP-4844 和 EIP-4444 均未指定過期 blob、歷史和狀態的長期數據存檔解決方案,而以太坊是否願意提供這樣的解決方案尚待確定。

  支持

  摘要:我們支持 1) 進一步縮小 CL 和 EL 之間的差距;2) EVM 修改可作為單人工作執行,並可進行隔離和並行測試。

  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

  簡而言之:支持 Solidity 和 Vyper 將采用的範圍明確的版本。代碼格式和驗證調整可使分析更容易,這一點毋庸置疑。我們建議仔細考慮除此之外的任何內容。我們在下面推薦了一些 EIP,但我們願意進一步調整。

  優勢:

  僅對 EVM 進行更改,可通過以太坊/測試進行測試,並由一人實施。

  Vyper 和 Solidity 想要的 EVM 更改!

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

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

  啟用部分代碼加載,有助於執行大型智能合約。

  Devex: 將允許使用 dupN/swapN 修復 solidity 中的 “堆棧過深”問題,並改進其他工具。

  面向未來:可以安全地跨 L2 引入新功能,並且工具會知道什麼是兼容的。。

  劣勢:

  範圍和移動目標。

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

  遺留代碼仍需支持。

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

  我們認為應在 2024 年部署以下 EOF 功能。我們建議盡快確定範圍,並做出承諾。其他內容應考慮後續部署。我們的建議:EIP-3540: EOF - EVM 對象格式 v1:引入代碼和數據容器,並為以太坊字節碼添加結構和版本控制。EIP-3670: EOF - 代碼驗證: 在部署時拒絕任何不遵循 EOF 格式的合約。強化代碼結構,禁用無效和未定義的指令。EIP-663: 無限制 SWAP 和 DUP 指令: 這解決了 solidity 中的 “堆棧過深 ”問題,並通過 JUMPDEST 分析,因為即時值可能會產生副作用。evm langs 非常需要。EIP-4200:EOF - 靜態相對跳變: 更好的靜態分析,沒有不確定的跳轉。相對跳轉更有利於代碼重用。EIP-4750: EOF - 函數: 需要解決可使用動態跳轉但不能使用靜態跳轉的子程序問題。它還允許部分代碼加載,這與 Verkle 和增加合約大小限制很好地配合。EIP-5450: EOF - 堆棧驗證: 驗證代碼和堆棧要求。除 CALLF 指令外,刪除所有指令的運行時堆棧下溢和溢出檢查 (EIP-4750)EIP-7480: EOF - 數據部分訪問指令: 允許訪問字節碼的數據部分。EIP-7069: 改造後的 CALL 指令:可移除 CALL 中的Gas可觀察性,從而在未來更容易進行Gas重新定價。雖然與 EOF 無關,但我們認為這是引入 EOF 的好機會。我們對 EIP-6206 不太確定: EOF - JUMPF 和非返回函數。雖然它允許對 EOF 函數中的尾部調用進行優化,但我們仍需要看到語言對其有用性的分析。如果沒有,我們認為可以將其從範圍中刪除,並納入後續的 EOF 更新中。

  我們將上述工作預算為 1-2 個月,由 1 名全職人員完成。如果能保持勢頭,我們願意進一步縮減上述範圍。

  關於遺留字節碼的說明:

  雖然我們可以禁止新的遺留/非 EOF 字節碼,但無法廢除現有的遺留字節碼,因為它們實際上是 EOF "v0"。遺留字節碼在 EOF 後仍需要 JUMPDEST 分析,在 Verkle Tries 中仍需要特殊代碼處理來將其分割成塊。

  據我們所知,在無法訪問源工件的情況下,沒有可驗證的方法將非 EOF 字節代碼轉換為 EOF,但我們願意研究促進這種轉換的機制。

  另外,我們也願意探索強制將狀態遷移到 EOF 的老方法。

  增加 EIP-4844 Blob 數量

  我們對這一更改持開放態度,這相當於增加 EIP-4844 的 MAX_BLOB_GAS_PER_BLOCK 和 TARGET_BLOB_GAS_PER_BLOCK:

  > 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 嘗試

  TL;DR:我們認為 Verkle tries 無法在 2024 年底/2025 年初部署。我們建議團隊在 2024 年第二季度為此分配資源,並承諾在 2025 年第二季度至第三季度的Osaka硬分叉中進行部署。

  優勢:通過更小的存儲證明,使輕量級客戶端更便宜。通過在代碼區塊的頭中包含讀取預狀態來實現無狀態執行,這也可能通過靜態狀態訪問來提高性能。通過分塊字節碼和啟用部分代碼加載,提高合約大小限制。由於 “恢復”狀態的成本較低,狀態過期變得更容易接受。

  劣勢:變化的影響以及實施和測試的整合工作。Gas核算更改: Verkle 嘗試將證人的大小引入Gas計算功能。我們擔心尚未對存儲定價的變化進行探討(例如,Verkle 推出後,頂級Gas消耗者的成本會是多少)?應用集成: 在疊加過渡運行期間,使用 Merkle Patricia Trie 校驗器的應用程序應該做些什麼?eth_getProof 應該如何運行?

  雖然我們理解 Verkle Tries 的好處,但我們認為需要更多考慮第三方工具/合約需要如何調整,以及過渡對第 2 層解決方案等的影響。起初,我們對遷移策略存有疑慮,因為該策略規定,當從先前存在的 MPT 中讀取狀態時,Verkle trie 應進行更新,但現在似乎不再是這樣了。因此,我們支持將覆蓋樹方法作為一種可行的遷移路徑。

  一般來說,Verkle 遷移策略的文檔似乎已經過時,因為大多數資源仍然指出,當從 MPT 中讀取狀態時,Verkle 三元組應該更新,盡管事實並非如此。我們希望看到用最新方法更新關鍵轉換文檔,比如這份出色的文檔。我們還希望看到關於過渡策略的 EIP 草案。

  因此,我們仍然支持在 2025 年推出,但看不到在Prague部署的路徑。

  L1 Gas限制

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

  我們邀請大家與我們合作,共同開展這方面的研究,以及圍繞打破 EVM 中資源計量的總體研究。Broken Metre論文是這一研究方向的良好起點。

  賬戶抽象

  我們對納入其中一個或多個 EIP(或將 ERC 納入其中)持開放態度,但我們更希望看到每個提案之間更多的用戶體驗和 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,而其他建議則分為兩類,即Gas贊助和批量操作。

分享到:
The End

发布于:2024-01-23,除非注明,否则均为G2頭條原创文章,转载请注明出处。