原文：《#152 以太坊核心開發者會議筆記》
編輯：Stephanie, ECN
一文了解上海昇級的最新進展。
編輯的話
有看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 提出，旨在在以太坊網絡上提高運行零知識證明的效率。但這可能給以太坊的安全性帶來未知後果。
編譯來源為@TimBeiko 和@christine_dkim 的筆記
We had our first 2023 @ethereum ACD(E) today 😄
Covered Shanghai scope, EOF, (maybe) SSZfying some EL bits, and potential new EIPs!
Agenda: https://t.co/8JFMaDCc1l
Recording: https://t.co/Qr9c9O14NvRecap below 👇 https://t.co/vyfGbaCveM
— timbeiko.eth (@TimBeiko) January 5, 2023
https://www.galaxy.com/research/insights/ethereum-all-core-developers-execution-call-152/
會議視頻：
會議議程：
https://github.com/ethereum/pm/issues/700
