以太坊的坎昆硬分叉后下一個升級應該是怎樣的

時間：2024-01-20 11:46:13

來源：hao86下載

區(qū)塊鏈

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

我們認為布拉格硬分叉可能在 2024 年第三季度在以太坊測試網上實現(xiàn)，年底在主網上實現(xiàn)。

它應該包括：

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

獨立的 EVM 更改。

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

支持:

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

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

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

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

不支持:

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

我們不認為應該增加 L1 執(zhí)行 Gas 限制或合約大小，但我們邀請數(shù)據人員與我們合作調查對網絡的影響。我們愿意修改我們的看法，因為過去的測試表明 Reth 節(jié)點可以處理增加的負載而沒有問題。

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

如果社區(qū)對傳聞中^[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、歷史和狀態(tài)提供長期數(shù)據存檔解決方案的機會，因為 EIP-4844^[17] 和EIP-4444^[18]都沒有指定這一點，以及以太坊是否愿意提供這樣的解決方案。

以下是推理。

支持

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

EIP-7002^[19]

這個 EIP 通過使 EL 側的智能合約控制 CL 側的一個或多個驗證者，解鎖了無信任的重新質押和質押池。從我們的角度來看，這是一個不需要思考的 EIP，因為至少它將使現(xiàn)有的質押池能夠從實施其提款的智能合約中去除一層中心化。

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

EIP-6110^[20]

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

EIP-2537^[21]

現(xiàn)在外面有多個 BLS12-381 的實現(xiàn)，它是許多 SNARKs、BLS 簽名算法和 EIP-4844 中經常使用的曲線。我們認為實現(xiàn)復雜性低，因為它只是通過預編譯接口公開了曲線的驗證算法。可能我們還想要一個 Hash 到 BLS12-381 曲線的預編譯。

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

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

好處：

只有 EVM 的更改，可以通過以太坊/tests 進行測試，并由一人實施。

做 Vyper 和 Solidity 想要的 EVM 更改！

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

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

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

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

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

不足：

變化了目標。

沒有支持者極力推動它的加入。

仍然需要支持舊代碼

直到被采用之前，以太坊主網和其他 EVM 鏈之間會有暫時的分歧。

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

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

EIP-3670: EOF - 代碼驗證^[24]：在部署時拒絕任何不遵循 EOF 格式的合約。強制更結構化的代碼，并禁用無效和未定義的指令。

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

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

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

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

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

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

我們對 EIP-6206: EOF - JUMPF and non-returning functions^[31] 的確定性較低。雖然它允許在 EOF 函數(shù)中進行尾調用優(yōu)化，但我們仍需要看到語言分析其有用性。如果我們沒有這個，我們認為可以將其從范圍中剔除，并包含在后續(xù) EOF 更新中。

我們將以上工作預算為 1-2 個月，由 1 人全職完成。如果這意味著保持動力，我們愿意進一步削減上述提到的范圍。

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

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

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

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

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

我們愿意接受這一變化，這將對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 對網絡造成的壓力，并且預計將在未來的升級中增加，以便網絡在更大的塊下表現(xiàn)出可靠性。*

實際上，這是一個小的代碼更改，我們需要調查它在 txpool 中的實際影響，但我們認為我們可以重用 EIP-4844 的壓力測試基礎設施。共識層可能在傳播更多 blob 時遇到困難；我們聽取 CL 團隊的意見。

不支持

Verkle Tries^[33]

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

好處：

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

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

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

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

不足：

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

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

應用集成：當 Overlay 過渡運行時，具有 Merkle Patricia Trie 驗證器的應用程序應該怎么做？eth_getProof行為應該怎樣的？

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

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

因此，我們仍然支持在 2025 年推出 Verkle，但在布拉格升級沒有看到部署路徑。