以太坊核心開發者會議筆記：上海昇級的最新進展
原文標題：《原文標題：《》
原文標題：《
原文標題：《
#152 以太坊核心開發者會議筆記
原文編輯：Stephanie, ECN
編輯的話
有看ECN 每週更新的“以太七日談” 的朋友可能會發現，“七日談” 已經停更了將近一個月。除了由於前段時間編輯感染Covid 無法保持更新外，ECN 也在思考是否應該繼續“七日談” 的編輯。在新的一年，ECN 計劃做一些內容運營上的調整，其中就包括“七日談”。
以下為詳細筆記👇
一級標題
一級標題
(https://t.co/HBkcidHvMq)
一級標題
EOF 相關EIP 被移除出上海昇級
EOF 相關EIP 被移除出上海昇級
EOF 相關EIP 被移除出上海昇級
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 中的代碼自省。
那上海昇級是否需要補充其他的EIP 呢？經過討論，開發者們決定不再添加其他EIP，免得延遲上海昇級。
一級標題
一級標題
一級標題
其他EIP 的討論
編譯來源為@TimBeiko和@christine_dkim和
