一文了解以太坊上海昇級潛在的更新內容
原文作者：Christine Kim（Galaxy Digital）
編譯：DeFi 之道
2022 年11 月10 日，以太坊開發人員齊聚第149 次全體核心開發者(ACD) 電話會議，這次ACD 電話會議由以太坊基金會的Tim Beiko 主持，本週，開發人員討論了與EVM 對象格式(EOF) 以及proto-danksharding 相關的代碼更改進展，以實現合併後以太坊網絡的首次重大升級（稱為上海）。在這次電話會議期間，開發者們還討論了其他四項可能納入上海昇級的EIP。雖然每個提案確實為以太坊帶來了一些獨特的優點及好處，但開發者們對優先考慮納入哪些EIP 的問題，仍存在較大的爭議。除了上海昇級的討論之外，開發人員還簡要談到了抗審查性的話題，以及為了網絡可擴展性而對以太坊的抗審查特性進行的潛在權衡。
上海昇級計劃
在之前的ACD 電話會議中，以太坊開發人員同意將EIP 的核心列表納入上海昇級。來自ACD Call #148 的完整通話記錄在這裡。值得注意的是，從這份核心EIP 列表中，開發人員同意將質押ETH 提款提案納入到上海昇級之內，但並沒有承諾在同一升級中納入EOF 或proto-danksharding，直到後兩個提案的代碼更改得到進一步充實。特別是關於EOF 的話題，開發人員一直在猶豫是通過上海昇級的一小部分EIP 部分實現EOF，還是嘗試將EOF 的全部願景捆綁在上海之後的以太坊升級中。
EOF 實施
Hedera 首席軟件工程師Danno Ferrin 就本週關於上海EOF 實施進展的電話會議進行了更新。他解釋說，開發人員傾向於儘早將與EOF 實現相關的大多數EIP 捆綁到一次大型升級中。開發者考慮在上海昇級中納入與EOF 實施相關的EIP 有EIP 3540、EIP 3670、EIP 4200 以及EIP 4750。對於是否應將EIP 5450 納入與EOF 相關的代碼更改列表，開發者之間仍存在著分歧。
Erigon 執行層(EL) 客戶端團隊的Andrew Ashikhmin 也對Solidity 智能合約語言團隊是否能夠完全支持和實施所有四個（或可能五個）EIP 表示擔憂。 Ashikhmin強調，在承諾在上海昇級激活這些EIP 之前，首先要確認Solidity 團隊已為這些EIP 實現做好了準備。 Ashikhmin 在電話會議上表示，這是“一項必要的健全性檢查”， Geth EL 客戶端團隊的Marius van der Wijden 對此表示贊同。
Proto-danksharding
然後，開發人員繼續討論了proto-danksharding 的最新發展。與EOF 實現不同，只有一個EIP 是與proto-danksharding 代碼更改相關聯的，即EIP 4844。 Diederik Loerakker（通常被稱為“Protolambda”）是OP Labs 的研究員，據他表示，仍有一些與EIP 4844 相關的事項正在討論中。以太坊基金會的Ansgar Dietrichs 補充說，其中一些事項與設置blob 交易的最低價格以及降低上海昇級的blob 交易吞吐量有關。這些待辦事項在Github 上有總結。
禁用Self-Destruct 操作碼，以及其他潛在的EIP
在開發人員為上海昇級準備EOF 以及proto-danksharding 工作的同時，開發人員初步同意繼續研究其他四個EIP，以納入以太坊的下一次升級。
1、EIP 4758，禁用以太坊上的“selfdestruct”操作碼：開發人員重新審視了上次ACD 電話會議中關於禁用操作碼的對話，該操作碼被開發人員廣泛認為是在智能合約以及去中心化應用（dapps）中使用的不良做法。該操作碼是為數不多的遺留操作碼之一，這些操作碼的部署gas 成本固定，但網絡的存儲成本可能不受限制。獨立開發人員Micah Zoltu 重申道，以太坊上的某些活動智能合約仍在使用selfdestruct 操作碼，禁用該操作碼將破壞功能。 Tim Beiko 表示，對於這些特殊的邊緣情況，可能會有一些變通辦法，並且需要以太坊基金會進行更多的社區擴展。
2、EIP 1153，臨時存儲操作碼的添加：Uniswap 和Optimism 團隊的代表提出了一個令人信服的案例來引入臨時存儲操作碼，它的行為與以太坊上的常規存儲操作碼相同，除了這兩個新操作碼TLOAD 和TSTORE 的值將在每次交易後被丟棄。瞬時存儲的動機有很多，正如Optimism 的Mark Tyneway 所解釋的那樣，其中之一是節省gas 成本。僅在Uniswap 上，這個EIP 就有可能為用戶每年節省300 萬美元的gas 成本。此外，使用臨時存儲而不是常規存儲將有助於減少以太坊的技術債務。 Uniswap 和Optimism 團隊做了大量工作來幫助在多個不同的以太坊軟件客戶端中創建此代碼更改的實現，並為EIP 構建了一個全面的測試套件。 Besu (EL) 客戶端團隊的Daniel Lehrner 對外部開發人員為實現EIP 1153 準備工作的呼籲表示感謝。即便如此，並非所有開發人員都認為納入EIP 1153 所帶來的額外測試負載是值得的。 Geth 開發人員Marius van der Wijden 警告說，EIP 1153 可能會干擾正在進行的EOF 相關EIP 的準備工作，並造成複雜性。儘管如此，van der Wijden 表示，他對增加對代碼更改的測試工作仍持“觀望態度”。開發人員同意在Uniswap 和Optimism 團隊的外部開發人員的幫助下繼續測試EIP 1153，以便將其納入上海昇級。
3、EIP 2537，添加BLS 預編譯：以太坊基金會的Alex Stokes 介紹了將BLS 預編譯添加到以太坊的優點。 Stokes 解釋說，這有很多原因，包括創建更安全的密碼學證明的能力、與以太坊信標鏈更好的互操作性以及去中心化質押池增加的功能。 Van der Wijden 同意添加BLS 預編譯是一項重要的代碼更改，甚至可能優先於EOF 實施以及EIP 1153。但是，由於實施EIP 2537 需要進行大量測試，van der Wijden 表示他擔心增加這一代碼更改將推遲上海昇級。以太坊基金會的Jared Wasinger 提到，他正在研究一個並行的EIP，它可以提供比EIP 2537 更簡單的實現路徑。開發人員同意研究EIP 2537 並開始減少不同BLS 預編譯的數量，以便可能納入上海昇級。
4、EIP 2294：最後，Google 的軟件工程師Zainan Victor Zhou 介紹了EIP 2294，其代碼更改比較簡單，只是簡單地限制了以太坊的鏈ID 字段的字節大小，即傳統上用於幫助硬分叉後的節點發現。 Victor Zhou 在電話會議上表示，由於以太坊未來可能會出現分片和多鏈，鏈ID 的用例將變得更大、更重要。為了防止人們試圖在鏈ID 字段中存儲其他類型的數據來利用該字段，Victor Zhou 呼籲對鏈ID 大小進行顯式綁定。所有開發人員都同意這一更改很重要，而且易於實現。 Micah Zoltu 強調稱，這樣的代碼更改只需要軟分叉，這意味著以太坊客戶端團隊可以在各自的時間線上實施更改，而無需為更改協調特定的區塊高度。關於是否在調用結束時將鏈ID 大小限制為64 位或256 位，開發者們也進行了一些討論。 Tim Beiko 鼓勵開發人員離線討論，並在Discord 聊天中異步計算出數字。
基於計劃在上海昇級中納入的EIP 列表在不斷增加，開發人員對於優先考慮納入核心列表之外的哪些EIP 存在著分歧。一位化名為“lightclient”的以太坊基金會開發人員提議堅持開放提款，並僅優先考慮另一個主要的EIP，無論是proto-danksharding、EOF 實施還是電話會議上提出的四個EIP 之一。 Tim Beiko認為，在下一次升級中嘗試捆綁EOF 實現、proto-danksharding、BLS 預編譯以及添加臨時存儲操作碼是不現實的。由於會議時間不足，Beiko 提出了上海昇級規劃的討論，並鼓勵開發人員準備在下一次ACD 電話會議期間討論上海昇級除了質押ETH 提款之外的最高優先事項。
如何降低以太坊節點的運營成本（增加抗審查性）？
在關於上海昇級的談話中，獨立以太坊開發者Micah Zoltu 提出了一個關於以太坊抗審查的重要討論事項。 Zoltu 解釋說，幾乎沒有以太坊用戶會運行自己的節點來執行交易，人們都依賴於Infura 或Alchemy 等中心化服務，而這些服務會積極審查來自特定國家的用戶，並審查以太坊上的去中心化應用（dapps），例如Tornado Cash。儘管開發人員正在努力通過EIP 4844 提高以太坊的可擴展性，但在降低運行以太坊節點成本以及鼓勵更大程度地保證以太坊抗審查方面缺乏努力。以太坊Teku (CL) 客戶端團隊的開發人員Mikhail Kalinin 提議在實施EIP 4844 後專注於降低運行以太坊節點的成本。來自Erigon 的Andrew Ashikhmin 則認為，以太坊開發人員可以同時關注這兩者。而Ansgar Dietrichs 表示，出於務實的原因，以太坊開發者應在短期內為實現可擴展性而犧牲抗審查性，並在長期內專注於抗審查性。
以太坊基金會研究員Dankrad Feist 的觀點則是， EIP 4844 對節點運營商運營成本的邊際增加可以忽略不計，並且不會對以太坊的抗審查特性造成實質性損害。 Feist 還補充說，大多數以太坊用戶不運行自己的節點不是因為成本，而是因為用戶體驗差。 Diederik Loerakker 表示，為了創造更高水平的去中心化，擴容應該是以太坊開發人員的優先事項，因為像EIP 4844 這樣的代碼更改將使以太坊的使用成本更低，並為世界各地更多的人降低進入壁壘。
Nethermind EL 客戶端團隊的Lukasz Rozmej 還質疑EIP 4844 是否會對以太坊的抗審查性產生負面影響，因為理論上許多交易將在L2 rollup 上執行。 Zoltu 解釋說，雖然EIP 4844 可能會讓驗證者在未來更難審查單筆交易，但目前L2 rollup 的操作是中心化的，因此是可審查的。在結束這次討論時，Tim Beiko 表示，改善運行以太坊節點的用戶體驗應該是社區向前發展的重點領域。 Beiko 建議與以太坊核心開發人員相鄰的開發團隊應幫助簡化以太坊節點的運行，並努力讓普通用戶更容易訪問它。
其他雜項
除了以上的內容，以太坊開發人員在這次電話會議上尚未討論到一些事項，它們包括：
- Engine API 規範改進提案：Teku 開發者Mikhail Kalinin 為改進以太坊的Engine API 規範創建了一個提案。作為背景，Engine API 是一種軟件，使以太坊節點的EL 和CL 客戶端之間能夠輕鬆通信。對Engine API 的擬議更改，可能會放到下週四的以太坊CL 會議上進行討論。
- 上海“Core” vs 原型開發者測試網：為上海昇級測試EIP 將需要創建多個專用測試網絡。山東（Shandong）是以太坊基金會JavaScript 團隊推出的一個測試網絡，除了一些與EOF 實現相關的EIP 外，其已實現了EIP 4895、EIP 3860、EIP 3651 以及EIP 3855。在接下來的幾次ACD 電話會議中，開發人員將協調創建更多專用測試網絡，供客戶端團隊測試上海昇級EIP。
- Ropsten 測試網結束日期：Afri Schoeden 是維護以太坊測試網絡Goerli 的開發人員之一，他提出了一個提案，在計劃的時間線上啟動和棄用以太坊測試網絡。這是為了回應應用開發人員和基礎設施提供商對多個以太坊測試網絡被棄用的沮喪情緒。開發人員被鼓勵在這個以太坊魔術師論壇貼中分享他們關於如何負責任地棄用像Ropsten 這樣的公共以太坊測試網絡的想法。
展開全文打開碳鏈價值APP 查看更多精彩資訊
