原文來自：以太坊核心開發者Tim Beiko
編譯：DeFi 之道
歡迎閱讀有關AllCoreDevs 在2022 年的最後一次更新。
長話短說：
-
上海/ Capella 升級的內容已經敲定：提款，EOF，還有一些小改動……只要不耽誤提款即可
-
Blobspace 即將到來: EIP-4844 將成為以太坊下一次升級的中心，其召喚儀式即將開始
-
開發者們正在努力協調執行客戶端和共識客戶端升級過程的技術方面。我們還看到了關於更好地將社區的意見納入流程的積極討論
上海/ Capella 升級
在最近一次AllCoreDevs 電話會議上，客戶端團隊就上海/ Capella 升級的最終範圍達成了共識。雖然升級的名稱可能仍有爭議，但團隊們已經清楚了升級的範圍，這次升級的主要任務是為質押者引入信標鏈提款。盡快解決這個問題是客戶端團隊的目標，因此升級中的其他功能需要同時準備好，或者有可能會被移除。
上海EL 規範列出了所有包含的EIP：
-
EIP-3540：EVM 對象格式(EOF) v1
-
EIP-3651：Warm COINBASE
-
EIP-3670：EOF – 代碼驗證
-
EIP-3855：PUSH0 指令
-
EIP-3860：限制和計量initcode
-
EIP-4200：EOF – 靜態相對jumps
-
EIP-4750：EOF – 函數
-
EIP-4895：信標鏈推送提款操作
-
EIP-5450: EOF -堆棧驗證
雖然列表很長，但我們可以將它們分為三個不同的部分：小改進、EVM 對象格式以及提款。讓我們來逐一分析：
小改進
EIP-3651：Warm COINBASE
該EIP 修復了EIP-2929 中的一個疏忽，該疏忽根據客戶端是否已將數據字段存儲在內存中（WARM）或需要從磁盤中檢索它們（COLD）來更改訪問某些數據字段的gas 成本。
EIP-2929 在每個事務開始時，將客戶端內存中的兩段數據設置為WARM：發送地址和接收地址。 EIP-3651 在這個列表中添加了第三個地址，即COINBASE 地址（又名feeRecipient），因為它也是客戶端在處理區塊交易時在內存中的地址。
EIP-3855：PUSH0 指令
顧名思義，EIP-3855 引入了一個將值0 推入堆棧的操作碼。 Pushing 0 經常用於填充EVM 中的值，此操作碼將提供一種更有效、更便宜的方法來實現這一點。
EIP-3860：限制和計量initcode
該EIP 增加了initcode的最大大小，並引入了基於其長度的gas 計量。大小限制為EVM 添加了一個不變量，這將使推理和提出更改變得更容易。
引入了一個2 gas/32 字節的initcode 開銷，以說明客戶端在執行之前必須執行的jumpdest 分析，這在以前的gas 計劃中並沒有被考慮到。
EVM 對象格式
上海昇級包括的大多數EIP 都是單一功能的一部分: EVM 對象格式(EOF)。這項升級工作被分解為5 個不同的EIP，以幫助客戶端開發人員單獨地解釋每個更改，但為了提供更高層次的概述，本週發布了一個統一的規範。這5個EOF EIP 分別是:
1、EIP-3540: EVM 對象格式(EOF) v1
2、EIP-3670: EOF -代碼驗證
3、EIP-4200: EOF -靜態相對跳轉
4、EIP-4750: EOF -函數
5、EIP-5450: EOF -堆棧驗證
值得注意的是，EOF 的第一步是在倫敦升級中使用EIP-3541，它為EOF 合約保留了0xEF00 前綴。在過去的幾個月裡，上海EOF 升級的範圍也發生了變化。
2 月份，客戶端團隊同意為上海昇級考慮兩個最小的EOF EIP：EIP 3540 和EIP 3670。它們將充當構建塊，但如果不引入EIP 4200、EIP 4750 以及EIP 5450 將無法提供全部功能。雖然有可能擴展EOF，但向後不兼容的擴展可能需要一次版本升級。由於具有特定版本的前EOF 或EOF 合約必須始終可執行，因此每個新的EOF 版本都意味著客戶端開發人員必須維護一組與舊規則並行的新EVM 執行規則。
在EOF 之前，客戶端一次只維護一組EVM 規則。代碼庫還支持歷史EVM 規則，這些規則可以改變每次網絡升級，但一旦它們到達鏈的頂端，就只能應用最新的規則。而使用EOF，客戶端將維護兩個並行的EVM 規則集，因此它們可以在EOF 和非EOF 合約中執行代碼。換句話說，EOF 版本bumps 增加了並行的數量，而不是順序的，必須維護的EVM 規則集。
出於這個原因，在過去的幾個月裡，客戶端團隊開始更喜歡一種“大EOF” 方法。這樣，雖然他們必須實施更大的變更集，但EOF 版本將保持更長時間，從而減少要維護的“並行EVM”的數量。因此，“大EOF”被考慮並最終納入到接下來的上海昇級中。
也就是說，更大的功能顯然更難以實施和測試，而客戶端團隊們並不希望看到EOF 顯著延遲信標鏈提款。因此，客戶端團隊們同意，如果到明年1 月， EOF 實施不完整且相互之間無法快速互操作，則將EOF 從上海移除。
在這個背景下，現在讓我們簡單地介紹一下各種EOF EIP：
EIP-3540：EVM 對象格式(EOF) v1
該EIP 為EOF 合約引入了“容器”。它在合約中添加了區分代碼和數據部分的標記，並防止部署不符合格式的EOF 合約。這保證了任何鏈上EOF 合約都將遵循有效的佈局，從而簡化了與這些合約的交互以及對它們的靜態分析。
EIP-3670：EOF – 代碼驗證
EIP-3670 建立在EIP-3540 引入的容器之上，確保合約EOF 中的代碼有效，或阻止其部署。
這意味著未定義的操作碼無法在EOF 合約中部署，這具有減少所需的EOF 版本更新數量的額外好處。如果添加了新的操作碼，只需更改驗證規則即可啟用它，並且可以保證沒有EOF 部署的合約在其代碼部分引用它。
EIP-4200：EOF – 靜態相對JUMPs
EIP-4200 引入了第一個EOF 專用操作碼：RJUMP、RJUMPI 和RJUMPV，它們將目標編碼為帶符號的即時值。編譯器可以使用這些新的JUMP 操作碼來優化gas 成本，因為它們消除了對現有JUMP 和JUMPI 操作碼所需的運行時jumpdest 分析的需要。
EIP-4750：EOF – 函數
EIP-4750 比EIP-4200 的功能更進一步：它不允許JUMP 和JUMPI 操作碼，並為RJUMP、RJUMPI 和RJUMPV 無法複製的函數添加了替代方案。它通過在EOF 字節碼中引入特定的函數部分來實現這一點，這些函數部分可以分別使用新的JUMPF、CALLF 和RETF 操作碼跳轉到、調用以及返回。
EIP-5450：EOF – 堆棧驗證
最後，EIP-5450 為EOF 合約添加了另一個驗證檢查，這次是圍繞堆棧進行的。該EIP 可防止EOF 合約部署可能導致堆棧下溢，以及某些溢出情況的代碼。有了這個，客戶端可以減少它們在執行EOF 合約期間進行的驗證檢查的數量，因為它們可以更好地保證與堆棧相關的異常。
作為一名非EVM 專家，以上就是我能帶你走的最遠的地方！如果你想深入了解EOF，我推薦你們閱讀Geth 的lightclients 或Solidity 的Leo 的帖子。
信標鏈提款 ?
最後但同樣重要的是，“Shapella”的主要組成部分是信標鏈提款。這一變化在共識層規範以及EIP-4895 中都有規定。現在稍微有點過時的元規範將這些聯繫在了一起。
下面簡單說說提款的工作原理:
當提出一個區塊時，驗證器通過驗證器索引線性掃描，找到前16 個具有0x01 憑據的驗證器，這些驗證器要么:
-
餘額超過32 ETH（即已累積驗證者獎勵）
-
可提款（即已完全退出驗證者集）
根據這些，驗證器將創建一個提款列表，以包含在他們的ExecutionPayload 中。該列表中的每一項都包含以下內容：
-
WithdrawalIndex：所有提款中的索引——這有助於區分從同一驗證器到同一地址的相同金額的提款；
-
ValidatorIndex：餘額被提取的驗證器的索引；
-
ExecutionAddress: 需要發送提款的執行層ETH 地址；
-
Amount: 要發送到ExecutionAddress 的金額，以gwei（不是wei）為單位；
在構建或處理區塊時，EL 客戶端將在交易執行後應用這些提款。換句話說，處理提款類似於工作量證明獎勵的記入方式，並且不會與用戶交易爭奪區塊空間。
還有一些值得注意的細節：
在處理提款時，“全部”和“部分”提款在優先級/順序方面沒有區別。一旦驗證器離開退出隊列，就會發生完全提款，當對驗證器集的線性掃描到達驗證器的索引時，部分提款會定期發生。
為了處理提款，驗證器必須使用0x01 憑證，它代表一個ETH 地址。在信標鏈啟動時，只允許使用BLS 密鑰對的0x00 憑據。為了啟用提款，具有0x00 憑證的驗證器將需要簽署BLSToExecutionChange 消息。這些將作為Capella 升級的一部分啟用。驗證者可以期待多種工具的支持和教程來簽署此消息。
對驗證器集的掃描以每個區塊為界。如果在掃描驗證器集的一個子集後，沒有16 個提款需要處理，驗證器將停止掃描，下一個將從上次掃描的驗證器索引中提取。
與往常一樣，將有幾個開發者測試網（devnet）和測試網（甚至可能是一些新的！）供驗證者運行整個過程，並在主網上線之前解決所有問題。
不過，上海/Capella 升級並不是唯一取得進展的升級！開發團隊們也一直在期待下一個升級。
Cancun 升級?️
上海昇級的內容已定，但很多CFI 的EIP 沒有被納入，客戶端團隊開始討論下一次Cancun 升級應該考慮納入什麼?️
在CL 方面，EIP-4844 已被指定為capella 後的第一個升級。 EL 尚未支持這種佈局規範，但EL 團隊同意遵循類似的路徑，並將下一次升級圍繞EIP-4844 進行。
按照使用devcon 城市名稱進行升級的慣例，開發者創建了cancun.md，並正式將EIP-4844 包含在這次升級當中。
這個決定是在2022 AllCoreDevs 電話會議的最後幾分鐘做出的，所以沒有時間討論其他提案。那些在上海昇級獲得CFI ，但沒有入選的EIP，已被轉移到Cancun 的CFI 名單上，以太坊魔術師論壇已創建了帖子來討論Cancun 候選EIP。明年初，關於Cancun 範圍的討論將正式開始。
KZG 儀式
另一件與Cancun 升級相關的事情是KZG 儀式?️，這是EIP-4844 的一項要求。
儀式將生成驗證blob 數據有效性所需的隨機性。要使它被認為是安全的，必須只有一個參與者誠實地參與。
從明年1 月開始，這個儀式將向所有人開放幾個月。目標是獲得10,000 名貢獻者，這計劃成為迄今為止規模最大的此類儀式！如果你想確保自己不錯過它，請關注Trent Van Epps！
合併後升級過程
正如之前的更新中提到的，合併後的一個大的待辦事項是在EL 和CL 中協調以太坊的升級過程。 EL 使用黃皮書和EIP 來指定更改，而CL 使用可執行的Python 規範。
EL 流程的優勢在於EIP 被社區所熟知，並且其格式能夠清楚地呈現提案背後的原因。大量數學的黃皮書與EIP 相結合，並且需要將規範置於EIP 的上下文中，這使得執行層規範既難以理解又難以擴展。
CL 方面有相反的問題：它有一個清晰易懂的規範，存在於一個單一的存儲庫中，但是更改不能明確地識別，並且提案被隱藏在存儲庫中的其他開放PR 中。
隨著以太坊執行層規範的引入，我們有望彌合EL 方面的差距。而且，通過一些流程爭論，我們也許能夠將EIP 作為CL 流程的一部分引入……！
也就是說，隨著上海昇級範圍的討論和最終確定，很明顯這個過程中可能會缺少另一個“部分”：讓社區表達他們對更改的相對偏好，參與關於升級整體範圍的討論(而不是單個EIP)，並將其納入AllCoreDevs 和CL 電話會議的決策中。
目前還不太清楚這是什麼樣子的——我很樂意提供建議！ – 但隨著積極參與協議更改的利益相關者數量以及L1 變更對兩者影響的領域數量的增長，顯然需要一些東西。
幸運的是，我們並不是從頭開始：以太坊魔術師論壇已經存在多年，其IRL 聚會以及臨時分組討論室或社區電話會議可能是擴展的良好起點。
期待2023 年初，有關於這方面的更多更新！
下一步
2022 年就這樣結束了，多棒的一年啊!三個月前，我們甚至還沒有合併! 而現在，以太坊正在後台默默地運行權益證明（PoS），重點已經轉移到即將發生的事情上。
隨著一月份假期的結束，你可以期待:
-
上海/Capella 開發者測試網（devnets）和影子分叉（shadow fork）
-
KZG 儀式正在進行
-
圍繞Cancun 升級的討論，以及網絡升級過程應該如何演進以更好地捕捉社區的偏好
謝謝閱讀！感謝在過去一年中花時間努力改進以太坊的每個人-我們做了很多工作。希望你們都有一個應得的假期。
2023 年見
