原文：《What comes after Ethereums Cancun hard fork?》
作者：Georgios Konstantopoulos
編譯：Odaily Moni
一、內容概述
本文將分析Paradigm Reth 團隊對Prague（布拉格）硬分叉（Cancun 坎昆升級後的下一個執行層硬分叉）包含的重要EIP（以太坊網絡改進協議）的理解以及對2024 年“EL Core Dev 」計劃的看法。
Prague 硬分叉可能在2024 年第三季在以太坊測試網絡上進行，並在年底前在主網上實現。其升級內容包括：
1.建議囊括與質押相關的EIP，如EIP-7002 ，活化再質押和無需外部信任的質押池；
2、獨立的EVM 變更；
此外，Paradigm 願與所有希望進一步研究Prague 等EL 硬分叉中難題的團隊合作，也很樂意提供修改Reth 代碼庫在內的指導。
Paradigm 認同的方向：
1.Paradigm 認為應優先考慮以下EIP： 7002、 6110、 2537 。
2、Paradigm 支援規範中所述的以太坊物件格式（EOF） ，但希望盡快確定範圍，並創建一個致力於該範圍的meta-EIP。
3.Paradigm 願意增加EIP-4844 Max Blob Gas，對其中正確的數字不做過多評論，但會邀請資料人員合作研究該EIP。
4.對於發布EIP-7547 ：Inclusion Lists 版本，Paradigm 持開放態度，該EIP 可以幫助抵抗基礎層審查。
Paradigm 不認同的方向：
1.Paradigm 不支援Prague 硬分叉所採用的Verkle Tries 資料結構，但支援客戶端團隊在2024 年第二季開始為此努力，同時承諾於2025 年中/下旬在大阪升級發布。
2.Paradigm 認為不應該增加L1 執行Gas 限製或合約規模，但會邀請資料人員合作調查這種做法對以太坊網路的影響。同時Paradigm 願意調整自己的看法，因為過去的測試顯示Reth 節點可以毫無問題地處理增加的負載。
3.Paradigm 認為錢包/帳戶抽象EIP 需要進行更多的相互對抗測試，以便更好地了解權衡網絡空間。如果錢包/帳戶抽像不互相排斥，那麼將願意在未來部署多個與帳戶抽象相關的EIP。
4.如果社區同意傳聞中的NSA 後門，Paradigm 認為可以越過EIP-7212 (secp 256 r 1) 的線路。
5.其他路線圖主題：Paradigm 對共識層EIP 或CL/EL（共識層/執行層）分叉耦合沒有做過實際了解，但EIP 7549 和EIP 7251 兩個提案似乎很有前途。 Paradigm 也希望盡可能從EL 方面為PeerDAS 的工作做出貢獻，目前希望避免引進SSZ 根（EIP 6404、 6465、 6466）。最後，Paradigm 認為應該為過期的blob、歷史記錄和狀態提供長期資料歸檔解決方案，因為EIP-4844 和EIP-4444 都沒有指明這一點，但以太坊是否願意提供這樣的解決方案還有待確定。
以下是詳細內容：
Paradigm 認同的方向
抽像地說，Paradigm 主要支援以下兩個面向：
1) 進一步縮小共識層與執行層的差距；
2) EVM 修改可以作為單人作業執行，並且可以進行獨立測試或平行測試。
EIP-7002
此EIP 透過使執行層側的智慧合約能夠控制共識層側的單一或多個驗證器來解鎖去信任的重新質押和質押池。從Paradigm 的角度來看，這個EIP 有一定道理，至少將使現有質押池能夠從實現提款的智慧合約中消除一層中心化。
此外，將有狀態預編譯引入EVM 也是Paradigm 認同需要在EVM 實作中滿足的功能，但除此之外，Paradigm 認為這是一個可以直接執行的EIP。
EIP-6110
此EIP 引入了執行層狀態中的存款功能，簡化了需要在共識層上完成的狀態管理。在實施方面，這類似於追蹤共識層提款，因此總的來說，Paradigm 認為這也是一個易於實施且獨立的EIP。
EIP-2537
現階段，BLS 12-381 有多種實現，是許多SNARK、BLS 簽章演算法和EIP-4844 中經常使用的曲線。 Paradigm 認為BLS 12-381 實現複雜度較低，因為它只是透過預編譯介面公開曲線的驗證算法，因此可能還需要BLS 12-381 曲線預編譯的哈希值。
以太坊物件格式（EOF）
簡單來說，EOF 將同時支援Solidity 和Vyper 採用更廣泛的版本，使分析變得更容易的程式碼格式和驗證調整也是合理的，Paradigm 建議仔細考慮除此之外的任何內容並在下面推薦了一些EIP，同時也願意做進一步調整。
好的方面：
● 僅限EVM 的更改，可以使用以太坊/測試網絡進行測試並由單人實施。
●Vyper 和Solidity 想要的EVM 變更。
● 有助於提高績效並增加合約規模限制。
● 消除了EVM 在運行時進行字節碼分析需求，在不涉及緩存的情況下，分析的時間可能高達50% ，並且隨著合約大小的增加而增加。
● 啟用部分程式碼加載，浙江有助於執行大型智慧合約。
● Devex：將允許透過 dupN/swapN 和其他工具改進來修復「堆疊太深」的問題。
● 未來可適用的功能：可以引入安全跨L2 新功能，工具會知道哪些功能是相容的。
不好的方面：
● 範圍和移動目標。
● 沒有支持大力推動將其納入其中。
● 遺留代碼仍然需要支援。
● 在採用之前，以太坊主網和其他EVM 鏈之間存在暫時分歧。
Paradigm 認為以下EOF 功能應在2024 年部署，並建議盡快確定範圍並承諾實施。後續部署應該考慮其他問題。因此，Paradigm 建議：
● EIP-3540 （EOF - EVM 物件格式v1）：引入代碼和資料容器，並為以太坊字節碼添加結構和版本控制。
● EIP-3670 （EOF -代碼驗證）：拒絕部署時不遵循EOF 格式的任何合約，只有更具結構化的代碼才能被執行，同時停用無效和未定義的指令。
● EIP-663 （無限SWAP 和DUP 指令）：此EIP 解決了Solidity 中的「堆疊太深」問題，使用JUMPDEST 分析作為即時值可能會產生副作用，但這是EVM 變成語言非常想要的功能。
● EIP-4200 （EOF -靜態相對跳轉）：更好的靜態分析，沒有不確定的跳躍。更好的aot 編譯，相對跳轉更有利於程式碼的可重複使用性。
● EIP-4750 （EOF –函數）：需要解決可以使用動態跳轉但不能使用靜態跳轉的子例程，並且還允許部分代碼加載，可以與Verkle 數據結構進行良好配合並增加了合約大小限制。
● EIP-5450 （EOF -堆疊驗證）：驗證代碼和堆疊要求。刪除CALLF 以外的所有指令的執行時間堆疊下溢和溢位檢查（EIP-4750）。
● EIP-7480 （EOF -資料部分存取指令）：允許存取字節碼的資料部分。
● EIP-7069 （改進的CALL 指令）能夠從CALL 中刪除Gas 可觀測性，未來將更容易重新定價Gas。雖然該EIP 獨立於EOF，但Paradigm 認為本次硬分叉是引進該EIP 的好機會。
Paradigm 對EIP-6206 （EOF-JUMPF 和非回傳函數）不太確定，雖然該EIP 允許在EOF 函數中進行尾部呼叫優化，但Paradigm 仍需要看到語言分析其有用性。如果沒有，Paradigm 認為可以將其從範圍中刪除並包含在後續EOF 更新中。
Paradigm 估計上述工作量約為全職工作1-2 個人月，如果評估的工作量較大，Paradigm 願意進一步縮小上述範圍。
關於遺留字節碼的註解：
● 雖然可以禁止新的遺留/非EOF 字節碼，但無法棄用現有的遺留字節碼，因為它實際上充當EOF“v 0 ”。遺留字節碼仍然需要EOF 後的JUMPDEST 分析，並且仍然需要特殊的代碼處理以將其分段為Verkle Tries 中的區塊。
● 據Paradigm 所知，如果不存取原始程式碼，就無法驗證從非EOF 字節碼到EOF 的轉換，但Paradigm 願意研究促進這種轉換的機制。
● 或者，Paradigm 願意探索強制狀態遷移到EOF 的到期方法。
增加EIP-4844 Blob 數量
Paradigm 對此更改持開放態度，對應地，將增加“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 對網路造成的壓力，隨著網路在較大區塊下展現可靠性，也可以在後續的升級中增加初始限制大小。
實際上，相關代碼變更不會太大，但Paradigm 需要調查這些更高對txpool 的實際影響，因此可以重新使用EIP-4844 壓力測試基礎設施。共識層可能很難傳播更多的blob，所以Paradigm 也尊重共識層隊伍的意見。
Paradigm 不認同的方向
Verkle Tries
簡單來說， 2024 年底/2025 年初完成Verkle 部署的可能似乎不大，Paradigm 建議團隊在2024 年第二季為此分配資源，並承諾在2025 年第二季至第三季在大阪硬分叉中進行部署。
好的方面：
● 透過更小的儲存證明實現成本更低的輕客戶端。
● 通過在區塊標頭中包含讀取預狀態來進行無狀態執行，這也可能由於靜態狀態存取而導致效能改進。
● 通過對字節碼進行分塊並啟用部分代碼載入來提高合約大小限制。
● 由於「恢復」狀態的成本較低，狀態到期變得更容易接受。
不好的方面：
● 實施和測試的變更和整合工作的影響。
● Gas 會計變更：Verkle Tries 將見證人的大小引入到Gas 計算功能中，Paradigm 擔心儲存定價的變化尚未被探索（例如，Verkle 後頭部gas 消耗者的成本是多少）。
● 應用程式整合：當Overlay 轉換運行時，具有Merkle Patricia Trie 驗證器的應用程式應該做什麼？應該如何eth_getProof 表現？
雖然Verkle Tries 有一定優勢，但Paradigm 認為需要更多地考慮第三方工具/合約需要如何適應，以及過渡會對二層解決方案等產生什麼影響。最初Paradigm 對遷移策略心存疑慮，因為它規定當從預先存在的MPT 中讀取狀態時應該更新Verkle Tries，但情況似乎不再如此了。因此，Paradigm 支援覆蓋Overlay 方法作為可行的遷移路徑。
Verkle 遷移策略的文檔通常似乎已經過時，因為大多數資源仍然指出從MPT 讀取狀態時應該更新Verkle trie，即使事實並非如此。 Paradigm 希望看到關鍵的過渡檔案使用最新的方法進行更新，可參考該文件。 Paradigm 也希望看到有關過渡策略的生態投資計畫草案。
因此，Paradigm 仍然支援其在2025 年推出，而不是在本次硬分叉中部署。
L1 Gas 限制
Paradigm 認為，在需求側可能存在某些“誤導”，實際上，提高L1 Gas 限制在實踐中並不會產生太大影響。 Paradigm 也認為大多數客戶端可以應對平均負載增加，但Paradigm 希望對最壞的情況保持警惕，因此目前不建議增加L1 Gas 限制。 Paradigm 認為，短期內增加blob Gas 限制是一個更有希望的解決方案。
Paradigm 希望邀請社群合作進行相關方向的研究，通常圍繞著打破EVM 中的資源計量。 Broken Meter 發佈的這篇論文應該是這個研究領域的一個很好起點。
帳戶抽象
Paradigm 願意在硬分叉中包含1 個或多個EIP（或納入ERC），但理想情況下，更希望看到每個提案之間有更多的用戶體驗和開發者體驗對比，這樣可以更好地了解工具整合的權衡空間和工作量。 Paradigm 正在關注以下EIP/ERC，社群可以隨時向Paradigm 提出建議：
● EIP-3074 ：AUTH 和AUTHCALL 操作碼
● ERC-4337 ：使用Alt Mempool 進行帳戶抽象
● RIP-7560 ：原生帳號抽象- 核心EIP - Fellowship of Ethereum Magicians
最後要提醒的是，「帳戶抽象」僅適用於上述EIP-4337 和EIP-7560 ，而其他提案主要涉及兩個領域，分別是：Gas 贊助和大量操作。 （「帳戶抽象」就像對驗證函數進行抽象，主要目標是啟用密鑰輪換，使多重簽名成為關鍵要素，並為我們提供一條自動實現量子抗性的路徑。）
