一文梳理以太坊核心開發者會議最新更新

ECN以太坊中国

特邀专栏作者

2023-01-04 12:00

本文約6976字，閱讀全文需要約10分鐘

上海昇級、提款機制、坎昆升級......

原文來源：AllCoreDevs Update

原文作者：Tim Beiko

原文編譯： Ethereum.cn

歡迎閱讀新一期的AllCoreDevs (以太坊核心開發者會議) 更新—— 2022 年的最後一期。

概要

上海/Capella 升級的內容已經敲定了：提款、EOF 和一些小型修改...... 前提是它們不延遲提款

Blob 空間要來了：EIP-4844 將成為以太坊下一次升級的中心，它的召喚儀式很快就要開始

一級標題

上海/Capella 升級

在最近的一次AllCoreDevs 上，客戶端團隊就上海/ Capella 升級的最終範圍達成了共識。儘管升級的名字可能還有待商榷，但團隊對它的範圍已經明晰了。升級的主要功能是為質押者引入信標鏈提款。盡快推出這個功能是客戶端團隊不想妥協的事情，所以升級中的其他功能需要同時準備好，否則可能會被放棄。

上海執行層規範列出了所有被納入的EIP：

EIP-3540: EVM 對象格式(EOF) v1

EIP-3651: 降低訪問COINBASE 地址的gas 開銷

EIP-3670: EOF - 代碼驗證

EIP-3855: 新增操作碼PUSH 0

EIP-3860: 對initcode 的大小設限並引入gas 計量

EIP-4200: EOF - 靜態的相對跳轉

EIP-4750: EOF - 引入函數

EIP-4895: 信標鏈推式提款作為系統操作

二級標題

小型改良

EIP-3651: Warm COINBASE (降低訪問COINBASE 地址的gas 開銷)

這個EIP 修復了在EIP-2929 裡的一個疏忽，即對某些數據字段訪問的gas 開銷修改是根據這些數據是已在客戶端內存中(WARM) 還是需要從磁盤中檢索它們(COLD) 來判斷。

EIP-2929 在每筆交易開始時將客戶端內存中的兩個數據設為WARM ：發送地址和接收地址。 EIP-3651 給這個列表添加第三個地址，COINBASE 地址(即feeRecipient)，因為它也是客戶端在處理區塊交易時在內存中的地址。

EIP-3855: PUSH 0 instruction (新增操作碼`PUSH 0)

顧名思義，EIP-3855 引入了一個把0 值壓入堆棧的操作碼。壓入0 通常用於填充EVM 中的值，此操作碼將提供一種更高效、更便宜的方法來執行此操作。

EIP-3860: Limit and meter initcode (對initcode 的大小設限並引入gas 計量)

二級標題

對象格式

上海昇級納入的大多數EIP 其實都是這單一功能的一部分：EVM 對象格式(EVM Object Format, EOF)。這項工作被分解為5 個不同的EIP，以幫助客戶端開發者理解每個單獨的修改，但為了提供一個更高層級的概述，開發者發布了一份統合的規範。這5 個EOF 的EIP 分別是：

EIP-3540: EVM 對象格式版本1

EIP-3670: EOF - 代碼驗證

EIP-4200: EOF - 靜態相對跳轉

EIP-4750: EOF - 引入函數

EIP-5450: EOF - 堆棧驗證

值得注意的是，EOF 的第一步是發生在倫敦升級的EIP-3541 ，它為EOF 合約保留了0 xEF 00 的前綴。在過去的幾個月裡，上海昇級的EOF 範圍也發生了變化。

在二月，客戶端團隊同意考慮在上海昇級納入兩個最小的EOF EIP：EIPs 3540 & 3670 。它們都將作為構件，但在不引入EIP 4200、 4750 和5450 的前提下，不會提供全部功能。儘管有可能延展EOF，但向後不兼容可能需要新增一個版本。因為EOF 前的或有一個特定版本的EOF 合約必須一直可執行，因此每個新的EOF 版本都意味著客戶端開發者必須維護一組與舊規則並行的新EVM 執行規則。

在EOF 之前，客戶端一次只維護一組EVM 規則。代碼庫也支持之前的EVM 規則，這些規則在每次網絡升級裡都會修改，但一旦它們到了區塊鏈的鏈頭，就必須只應用最新的規則。部署了EOF 後，客戶端將維護兩套平行的EVM 規則，因此它們可以執行在EOF 和非EOF 合約裡的代碼。換句話說，EOF 的版本增加所增加的是必須維護的平行的而不是連續的EVM 規則集數。

為此，在過去幾個月，客戶端團隊開始偏向於「大EOF"的方法。這樣，儘管他們必須實現更大型的修改集，但EOF 版本將維持更長時間，並減少需要維護的「平行EVM"數。因此，開發者們考慮的是「大EOF」，並最終納入到了上海昇級。

EIP-3540: EVM Object Format (EOF) v1 (EVM 對象格式版本1)

EIP-3540: EVM Object Format (EOF) v1 (EVM 對象格式版本1)

這個EIP 為EOF 合約引入了「container」。它增加了區分合約裡的代碼和數據部分的標記，並防止不符合格式的EOF 合約被部署。這就保證了任何鏈上的EOF 合約都會遵循有效的格式，這就簡化了與這些合約的交互，以及對它們的靜態分析。

EIP-3670: EOF - Code Validation (EOF - 代碼驗證)

在由3540 引入的container 基礎上，EIP-3670 確保EOF 合約中的代碼是有效的，或者防止它被部署。

這意味著未定義的操作碼不能被部署在EOF 合約中，這有一個額外的好處，即減少所需增加的EOF 版本數量。如果添加了一個新的操作碼，可以簡單地改變驗證規則來啟用它，並且保證沒有已部署的EOF 合約在其代碼部分引用它。

EIP-4200: EOF - Static relative jumps (EOF - 靜態相對跳轉)

EIP-4200 引入了首批EOF 專用的操作碼：RJUMP、 RJUMPI 和RJUMPV，它們將目的地編碼為有符號的即時值。這些新的JUMP 操作碼可以被編譯器用來優化gas 開銷，因為它們免去了運行時jumpdest 分析的需要，而現有的JUMP & JUMPI 操作碼都是需要的。

EIP-4750: EOF - Functions (EOF-引入函數)

EIP-4750 在4200 的基礎上再進一步：它不允許使用JUMP & JUMPI 操作碼，並為不能複制RJUMP、RJUMPI 和RJUMPV 功能添加替代方案。它通過在EOF 字節碼裡引入特定函數section 來實現，這些函數可以分別從新的JUMPF、CALLF 和RETF 操作碼跳轉到，並使用它們來調用和返回。

EIP-5450: EOF - Stack Validation (EOF-堆棧驗證)

二級標題

信標鏈提款

最後但同樣重要的是，「Shapella」 (譯者註：Shanghai/Capella 的合稱) 的主要部分是信標鏈提款。這部分變更在共識層規範和EIP-4895 都有說明。現在有一份稍微過時的元規範把這些變更聯繫在一起。

從高層級來看，提款的機制如下：

當提議區塊時，驗證者線性掃描驗證者索引，找出前16 個有0 x 01 憑證的驗證者，它們需要符合以下其中一個條件：

Have a balance above 32 ETH (i.e. have accrued validator rewards)

Are withdrawable (i.e. have fully exited the validator set)

餘額大於32 個ETH (即已經獲得驗證者獎勵)

是withdrawable 的（可提款的，即已經完全退出驗證者集)

From these, the validator will create a list of withdrawals to be included in their ExecutionPayload. Each item in that list contains the following:

驗證者將從這些驗證者裡創建一個提款列表打包進他們的ExecutionPayload。列表裡的每一項都包含以下內容：

WithdrawalIndex：所有進行過的提款交易索引——這有助於區分來自相同地址、相同驗證者的相同數額提款

ValidatorIndex：餘額被提出的驗證者索引

ExecutionAddress：執行層的ETH 地址，即提款應該發送到的地方

Amount：被發送到ExecutionAddress 的數量，這個數量以gwei (而不是wei) 計量

在構建或處理區塊時，執行層客戶端將在交易執行後進行這些提款操作。換句話說，處理提款與工作量證明獎勵的入賬方式相似，它並不與用戶交易競爭區塊空間。

還有一些值得注意的細節：

在處理提款時，提出「全款」對比「部分資金」在優先級/排序上並沒有區別。當驗證者離開退出隊伍時即提出全款，而部分提款是周期性發生的，即當對驗證者集進行線性掃描並掃到某個驗證者的索引號時。

為了提款得以被處理，驗證者必須使用0 x 01 憑證，它用ETH 地址表示。信標鏈上線時只允許使用BLS 密鑰對0 x 00 憑證。為了啟動提款，有0 x 00 憑證的驗證者將需要對一條BLSToExecutionChange 消息簽名。這些將在Capella 升級中被激活。會有多種工具用以簽署這條消息，驗證者可以期待對這些工具的支持和教程。

對驗證者的掃描是以每個區塊為界限的。如果在掃描完一個驗證者集的子集後沒有16 筆提款需要處理，驗證者將停止掃描，而下一個驗證者將從最後一個被掃描的驗證者索引開始。

一級標題

坎昆升級

由於上海昇級的內容已經滿了，但很多納入考慮升級的EIP (CFI) 都沒能進入上海昇級。客戶端團隊開始討論哪些EIP 應該考慮進入下一次升級：坎昆升級(共識層名稱有待確定)

在共識層方面，EIP-4844 已經成為Capella 升級後第一個寫進規範的的EIP。執行層(還) 沒有一個可以實現這種佈局的規範，但執行層團隊同意遵循相似的路徑，並在下一個升級里以EIP-4844 為中心。

二級標題

KZG 儀式

另一件與坎昆升級相關且可以期待的事情是KZG 儀式，這是EIP-4844 的要求。

一級標題

合併後升級流程

正如在之前的更新里提到的，合併後，在執行層和共識層協調以太坊的升級流程是一個重要的待辦事項。從高層級來看，執行層使用黃皮書& EIP 來說明修改，而共識層使用可執行的Python 規範。

執行層流程的好處是EIP 被社區所熟知，並且其格式化的方式可以清楚地展示提案背後的原因。有大量數學內容的黃皮書搭配EIP，以及需要把規範放回各個EIP 的脈絡裡使得執行層規範難以理解和擴展。

共識層方面的問題則相反：它有一個清晰易懂的規範，在一個單一的倉庫裡，但修改並不具體可辨，而且提案淹沒在倉庫裡的其他公開PR 裡。

隨著以太坊執行層規範的引入，我們有希望從執行層方面縮短這一差距。而且，通過一些流程爭論，我們可能能夠讓EIP 引入到共識層流程！

也就是說，隨著上海昇級的範圍被討論和最終敲定，很明顯，這個過程可能缺乏另一部分：讓社區去表達他們對變更的相對偏好，並參與到關於整個升級範圍(而不是個別EIP)討論裡的地方，並將其作為AllCoreDevs 和共識層會議決策的一部分。

現在還不清楚它會是什麼樣的——我很樂意收到建議！ ——但隨著積極參與協議變更的利益相關者的數量以及一層變更影響的領域數量都在增加，我們顯然需要某些東西。

一級標題

協議公會更新

隨著協議公會(Protocol Guild, PG) 試點已經完成了一半，他們發布了一份報告，檢視事情的進展情況，以及思考項目的下一步計劃是什麼。

提醒一下，PG 是針對以太坊Layer 1 客戶端開發者、協議研究員和支持貢獻者(如你們）的一個無需許可的資助機制。

這個機制以個人為中心，而不是組織。簡而言之，每個成員都有資格獲得公會的Token 份額，根據他們對以太坊的貢獻時長來進行加權計算。成員的增刪是以真正以太坊的方式來進行——基於一套標準，在PG 內部達成大致的共識。這個列表隨後會被放到鏈上，使用0 xSplit 的分割合約。然後，捐獻者可以將資金直接發送到接收者的地址，或發送到給接收者地址發放資金的鎖倉合約(vesting contract)。

試點中期報告在這篇推文裡有總結。以下是一些重點

這次試點籌得了970 萬美元，這些款項來自很多的組織，例如Lido、Uniswap、ENS、NounsDAO 和MolochDAO，以及一些經常進行捐助的個人(感謝Tetranode！)——感謝大家使這項計劃成為可能！

PG 在發佈時有90 名成員，到現在有128 名，在他們之間已經分發了500 萬美元

平均來說，每個成員收到39, 000 美元，其中最低的是1.3 萬美元，最高的達到7.9 萬美元

PG 的架構正在變化，將會支持L2，並刪除對多籤的需求，以更新權重

這些早期的結果顯示PG 正在按計劃運作：一個將一籃子Token 分配給一組自我孵化、不斷增長的協議貢獻者的機制。如果沒有試點捐贈者的慷慨支持，這個項目不會有今天的成果。

展望未來，現在是時候擴大PG 的影響範圍，充分發揮它的潛能：為以太坊的維護者提供有競爭力的、具有風險調節能力的補償。這裡最簡單的做法是項目從一開始就給PG 捐款，就像Danny Ryan 在啟動PG 的推文裡所說的。

試點裡的捐款大多來自擁有大量資金的大型項目。如果協議公會可以說服這些項目從第一天就給PG 捐款，即他們的Token 仍然是真正「不值錢」的時候，之後，以太坊的維護者就可以從這些成功項目的整個上升軌跡中獲益。

當有足夠多的項目參與時，激勵可以讓最優秀的人才保持維護協議，而不是把他們拉走。

一級標題