上海昇級計劃在 2 月上線公共測試網，並不納入 EOF 相關 EIP。
編輯： Stephanie，ECN
封面： Photo by Shubham's Web3 on Unsplash
編輯的話
有看 ECN 每週更新的 “以太七日談” 的朋友可能會發現，“七日談” 已經停更了將近一個月。除了由於前段時間編輯感染 Covid 無法保持更新外，ECN 也在思考是否應該繼續 “七日談” 的編輯。在新的一年，ECN 計劃做一些內容運營上的調整，其中就包括 “七日談”。
以太坊核心開發者會議的筆記編譯一直是 “七日談” 的重要組成部分，我們現在決定將其獨立更新。
如果對以往 “七日談” 中哪些部分的內容特別希望我們保持更新的，歡迎在各個社交媒體上私信我們，我們非常願意聽到大家的反饋，以提升我們的內容質量。
在第 152 次 ACDE 上，開發者們就從上海昇級中移除與 EOF 實現有關的代碼修改達成共識。關於 EOF 的更多信息，可閱讀 《以太坊核心開發者會議更新 014 》。他們還就不再接受任何添加到上海昇級的 EIP 達成共識，這主要是為了確保提款質押的 ETH 的時間表不會被推遲。作為上海昇級唯一的大型代碼修改，提款質押的 ETH 目前正在以開發者為中心的測試網絡上進行測試。開發者的目標是在下個月 (2023 年 2 月) 上線用於上海/Capella 升級的公共測試網，然後在 3 月上線主網。開發者隨後討論了 EVM 升級的更周詳考慮、以太坊執行層/共識層之間不同的序列化方法、以及引入 Poseidon 哈希函數作為 EVM 的預編譯的 EIP。
以下為詳細筆記
上海昇級的進展
在上海昇級方面，在聖誕節前已經上線了第一個開發者測試網，所有客戶端組合都在上面運行，大家可以看看以太坊基金會 devops 的儀錶盤。有些客戶端組合出現了問題，但開發者們將盡快推出一個新的開發者測試網。
(https://t.co/HBkcidHvMq)
此外，Geth 團隊的 Marius@vdWijden 提出對 EIP 3860 (對 initcode 的大小設限並引入 gas 計量) 設計上的小修改—— 糾正該 EIP 中一個令人困惑的錯誤模式，即違反 initcode 限制導致的是零地址錯誤而不是 OOG (gas 不足) 錯誤。這項提議得到開發者們的認同，即將錯誤模式改為 OOG 錯誤，然後終止或中止執行，而不是返回一個零地址，這樣將減少在客戶端實現中的混亂和漏洞。以上是客戶端團隊的意見，如果智能合約開發者強烈反對這個修改，可能就不修改了。
EOF 相關 EIP 被移除出上海昇級
接下來，會議主要討論 EOF 相關話題。
Geth 團隊的開發者 @lightclients 給大家更新了 12 月進行的 EOF 小組會議的情況。(EOF 即 EVM 對象格式，它會為以太坊的代碼環境引入一些變化。與之相關的 EIP 將更明確地區分智能合約的代碼和數據，並使得 EVM 在未來更容易升級。) 簡單來說，規範被敲定，並做了兩個小型修改：刪除 JUMPF 並使得數據 EOF 合約必須包含數據部分。
在測試方面，Geth 團隊的 @mhswende 已經開始對實現做模糊測試，在所有客戶端上都發現了漏洞並修復了。現在的模糊測試主要針對在客戶端上 EOF container/結構的實現，但不包括部署的 EOF 代碼。以太坊基金會測試團隊的 Mario Vega@elbuenmayini 補充道，由於 EOF 的複雜性，可能很難對錯誤情況寫靜態測試用例，因為實現可能會在遇到確切測試用例前先遇到另一個錯誤。
在客戶端團隊方面，Geth 和 Besu 已經有完整實現並通過了大部分的測試。Nethermind 也已經有實現了，但不確定最好使用哪個測試套件。而 Erigon 將使用 Geth 的 EOF 實現。
基於 EOF 的實現和測試情況，Vitalik 也表達了對倉促實現 EOF 的擔憂，並發表了 EOF 提案：禁用 EOF 賬戶的代碼自省 (code introspection)： https://ethereum-magicians.org/t/eof-proposal-ban-code-introspection-of-eof-accounts/12113
Vitalik 在會議上闡述了這個提案背後的思考，以及解釋為什麼修改 EVM 通常比其他協議修改更困難。他指出，從以太坊中刪除工作量證明比棄用操作碼來得更容易。這是因為以太坊應用/合約依賴 EVM 的特定行為，因此修改必須向後兼容，否則將破壞已部署的合約。而協議其他方面的修改只需要每個人在特定時間進行更新，除此之外，不會破壞網絡上的任何東西。
這意味著，當我們改進 EVM，或引入新版本，例如 EOF，我們很可能需要永遠與它們共存，因為我們不能棄用之前版本。理想情況下，我們想讓 EVM 更簡潔/簡單，但如果我們只能在它上面添加東西而從不刪除東西，這就會變得很難。刪除東西最大的挑戰之一是 EVM 中的代碼自省。
因此，Vitalik 的提案是在 EOF v1 中添加更多內容，這將極大地限制 EOF 合約中的代碼自省，從而有可能使其在未來更容易升級。Ipsilon 團隊的 @alexberegszaszi 提到，EOF 提案的作者們其實之前有考慮過類似的功能，決定放棄是想保持 EOF v1 簡單。他還提出一個替代方案，將 Vitalik 的提案納入到 EOF v2：https://ethereum-magicians.org/t/eofv2-aka-what-evm-2-0-could-look-like/12442
但是，對於這份在 EOF v1 基礎上添加內容的提案，客戶端團隊擔心整體的修改規模過大。@lightclients 也表示，基於目前 EOF 測試的進度，把它納入上海昇級可能會延遲大概一個月的時間。如果想要在二月初能上線主網測試網升級，EOF 的部分應該未能準備好。而且，這是一個很重要的決定，因為 EVM 的變更一旦部署了就不能修改。
經過討論，開發者們最後決定要再多花時間考慮 EOF 的問題，因此將其從上海昇級移除，但會保持 EOF 上的工作。他們應該能夠在坎昆升級中部署某個版本的 EOF 與 4844。在這次會議上，開發者們沒有對坎昆升級做出正式決定，並將在下次會議再討論。
那上海昇級是否需要補充其他的 EIP 呢？經過討論，開發者們決定不再添加其他 EIP，免得延遲上海昇級。
其他 EIP 的討論
隨後，開發者們還討論了 Nimbus 團隊的 Etan Kissling 的提案：在 ExecutionPayloadHeader 的交易列表裡添加十六進制樹根。https://github.com/ethereum/consensus-specs/pull/3078
簡單來說，現在執行層區塊頭和共識層執行負載頭 (ExecutionPayloadHeader) 之間使用不同的序列化格式編碼的字段。這兩個字段編碼格式不同給錢包和以太坊輕客戶端構建帶來額外的開銷和復雜性。Kissling 提議向執行層添加 CL 的 SSZ 序列化格式，或共識層客戶端採用多種方式支持執行層的 RLP 序列化格式。這個提案與上海昇級中的提款相關，因此相對緊急。這個問題將在這週的共識層會議 (ACDC) 上再次討論，即 1 月 12 日。
會議最後還討論了 EIP-5843 (EVM 模塊化的算術擴展) 的和 EIP-5988 (添加 Poseidon 哈希函數預編譯)。由於 EIP-5843 的作者未能與會，開發者們同意之後再對此 EIP 進行討論。而 5988 由 StarkWare 提出，旨在在以太坊網絡上提高運行零知識證明的效率。但這可能給以太坊的安全性帶來未知後果。
免責聲明：作為區塊鏈信息平台，本站所發布文章僅代表作者及嘉賓個人觀點，與 Web3Caff 立場無關。文章內的信息僅供參考，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。
