買以太坊 買以太坊
Ctrl+D 買以太坊
ads

以太坊:以太坊核心開發者會議更新:上海升級、提款機制、坎昆升級_ETH

Author:

Time:1900/1/1 0:00:00

原文來源:AllCoreDevs Update

原文作者:Tim Beiko

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

盡管這些更新最初是每月系列,但節奏逐漸趨于每季度一更。讀者可以把這些更新視為圍繞 AllCoreDevs 發生的重大事件摘要。如果你想要了解更多細節,我推薦閱讀 Christine Kim 的記錄、 Ben Edginton 的共識層會議記錄和我的 ACD 長推文,這些更新更頻繁。

話不多說,讓我們開始吧!

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

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

在技術方面使得執行層和共識層的升級流程能互相協調的努力正在進行中。我們還看到關于在這個過程中更好地融入社區意見的積極討論

Protocol Guild (協議公會) 發布了一份中期試點報告,以及一份在 2023 年擴大一層維護者的規模并更好地給他們提供支持的大概計劃

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

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

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

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

EIP-3670: EOF - 代碼驗證

EIP-3855: 新增操作碼 PUSH0

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

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

EIP-4750: EOF - 引入函數

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

EIP-5450: EOF - 堆棧驗證

盡管列表很長,它可以被分成三個不同部分:小型改良、EVM 對象格式和提款。接下來將逐一介紹:

數據:以太坊網絡當前已銷毀370937.65枚ETH:金色財經報道,據Ultrasound數據顯示,截止目前,以太坊網絡總共銷毀370937.65枚ETH。其中以OpenSea開頭地址銷毀892.05枚ETH,ETHtransfers銷毀422.26枚ETH,UniswapV2銷毀282.85枚。注:自以太坊倫敦升級引入EIP-1559后,以太坊網絡會根據交易需求和區塊大小動態調整每筆交易的BaseFee,而這部分的費用將直接燃燒銷毀。[2021/9/27 17:08:34]

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

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

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

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

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

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

這個 EIP 添加了 initcode 的大小上限,并基于其長度引入 gas 計量。其大小上限為 EVM 添加了一個不變量,這使得它更易于理解和提議修改。

為 initcode 引入每 32 字節 2 gas 的開銷,這是用于支付客戶端在執行前必須進行的 jumpdest 分析,jumpdest 分析之前沒有列入 gas 收費表。

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

數據:以太坊NVT比率創19個月以來新高:9月19日消息,Glassnode數據顯示,以太坊的NVT比率(7日MA)剛剛達到19個月高點2396.150,此前高點為2020年6月10日的2392.743。[2021/9/20 23:37:30]

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

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

值得注意的是,EOF 的第一步是發生在倫敦升級的 EIP-3541,它為 EOF 合約保留了 0xEF00 的前綴。在過去的幾個月里,上海升級的 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」,并最終納入到了上海升級。

也就是說,更大型的功能顯然更難以實現和測試,且團隊也不希望看到 EOF 嚴重延遲信標鏈提款。因此,如果到 1 月,EOF 的實現還沒完成,且彼此間無法快速互操作,客戶端團隊同意把 EOF 移出上海升級。

有了這些脈絡后,現在讓我們簡要介紹各個 EOF EIP:

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

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

以太坊未確認交易為178,569筆:金色財經消息,據OKLink數據顯示,以太坊未確認交易178,569筆,當前全網算力為526.60TH/s,全網難度為7.22P,當前持幣地址為62,027,173個,同比增加54,645個,24h鏈上交易量為1,780,376.03ETH,當前平均出塊時間為13s。[2021/8/2 1:29:54]

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

在由 3540 引入的 container-jozw 基礎上,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-堆棧驗證)

最后,EIP-5450 為 EOF 合約添加了另一個驗證檢查,這次是圍繞堆棧的。這個 EIP 防止 EOF 合約部署可能導致堆棧下溢,以及某些情況上溢的代碼。有了這個 EIP,客戶端可以減少在執行 EOF 合約時驗證檢查的次數,因為它們有了圍繞堆棧相關異常的更好保證。

V神:多年來做了大量努力來解決以太坊費用高問題:V神在推特上表示:“我看到的最奇怪的反以太坊言論之一是‘Vitalik表示高費用是不好的,但看看2020年以太坊費用有多高’。就像我們經過多年的大量努力來解決這個確切的問題,其中一個的第一階段就要在下周啟動了。”[2020/11/25 22:04:43]

作為一個非常關注 EIP 本身的非 EVM 專家,我可以介紹的就這么多了!如果讀者想要更加深入了解 EOF,我推薦 Geth 團隊的 lightclients 和 Solidity 團隊的 Leo 發的相關推文。

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

從高層級來看,提款的機制如下:

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

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 地址,即提款應該發送到的地方

動態 | 聯合國機構推出比特幣以太坊加密基金UNICEF:據Forbes消息,聯合國兒童基金會創新辦公室創始人Chris Fabian、區塊鏈創始人Christina Lomazzo和她的國際團隊今天宣布了UNICEF加密基金,該機構可以接受比特幣和以太幣捐贈并直接投資于區塊鏈初創企業。除了將加密貨幣投資于與兒童合作的早期開放源代碼公司之外,該基金還代表聯合國任何機構,無論是去年獲得了67億美元收入的聯合國機構,還是第一次能夠接受比特幣和以太坊捐款的加密基金。[2019/10/9]

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

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

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

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

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

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

像往常一樣,在主網上線前,會有幾個開發者測試網和測試網 (甚至可能有一些新的測試網!) 給驗證者運行整個過程,并解決所有問題。

上海/Capella 并不是唯一取得進展的升級!開發者團隊還在展望下一個升級。

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

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

按照升級使用舉辦過 Devcon 城市名稱的慣例,cancun.md 已經被創建,其中 EIP-4844 被正式納入升級。

這個決定發生在 2022 年最后一次 AllCoreDevs 會議的最后一分鐘,所以沒有時間處理其他提案。進入上海升級 CFI 但最終沒有被納入的 EIP 被移到坎昆升級的 CFI 清單,在 Ethereum Magicians 論壇也開了一個帖子用來討論坎昆的候選 EIP。明年年初,坎昆升級范圍的討論工作應該會開始正式進行。

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

這個儀式將生成驗證 blob 數據有效性所需的隨機性。要使得它被認為是安全的,只需要有一個參與者是誠實的。換句話說,如果除了一個參與者外其他所有參與者都合謀了,這樣整個過程在密碼學上都是安全的。

這個儀式從 1 月開始,它將向所有人開放幾個月。我們的目標是有 10,000 個參與者,計劃會是這類儀式迄今為止規模最大的!如果你想要確保不錯過,請在推特關注 Trent Van Epps!

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

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

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

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

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

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

幸運的是,我們不需要從頭開始。Ethereum Magicians 已經存在多年了,它的線下聚會、專門的小組會議或社區會議可能是很好的擴展起點。

期待在 2023 年初在這方面有更多進展!

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

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

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

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

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

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

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

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

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

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

為了支持這一點,以及其他許多捐獻類型,PG 將需要進行一次技術革新。下一個版本將支持 L1 和 L2,并進一步減少其鏈上治理的足跡。

如果你是希望給協議公會捐款的項目,請聯系我——我的 DM 是開放的 !

這就是 2022 年的最后總結了...... 多么不平凡的一年!三個月前,我們甚至還沒合并!現在,以太坊已經在后臺默默運行著權益證明,焦點已經轉移到未來的事務。

隨著大家在 1 月份回歸,大家可以預期:

上海/Capella 升級的開發者測試網和影子分叉

KZG 儀式上線

圍繞 Cancun 的討論,以及網絡升級流程應如果發展,以更好地捕捉社區的偏好

協議公會的試點將結束,我們將公布試點后的架構

感謝你們的閱讀!以及感謝在過去一年中花時間努力改善以太坊的每一位——我們實現了很多。

2023 年見!

區塊律動BlockBeats

媒體專欄

閱讀更多

金色財經

金色財經 子木

金色早8點

去中心化金融社區

虎嗅科技

CertiK中文社區

深潮TechFlow

念青

Odaily星球日報

Tags:NBSBSP以太坊ETHNBS價格BSP價格以太坊硬幣模版Tether EUR

火幣下載
DAP:DApp年度報告:4464個活躍DApp 以太坊年活躍地址數跌至第三_white幣挖礦app下載

隨著DeFi和NFT的發展,DApp在區塊鏈成功落地C端的道路上已經走出了一大步,Web3.0的輪廓隱約可見.

1900/1/1 0:00:00
SYNC:zkSync發行Token:給生態的可能比其他Layer2都多_SYN

原文來源:加密 KOL wagame.eth原文編譯:0x711、0x214,BlockBeats昨晚,zkSync 開發公司 Matter Labs 宣布完成 2 億美元 C 輪融資.

1900/1/1 0:00:00
WEB:Coinbase董事會:要用更長遠的眼光看待Web3_COI

撰寫:Katie Haun、Fred Wilson編譯:深潮 TechFlow圍繞 FTX 發生的事件動搖了許多人的信心.

1900/1/1 0:00:00
ERK:V神:如何打造更安全中心化交易所?_MER

原文:《Having a safe CEX: proof of solvency and beyond》編譯:雙花 (@doublespending)特別感謝 Balaji Srinivasan.

1900/1/1 0:00:00
FTX:FTX用3年半的生命期 給加密用戶帶來3條血淋淋的教訓_KONGZ Vault (NFTX)

作者:比推 Jonathan Smith2022年11月11日,FTX官方發布公告稱,已經在美國申請破產重組,SBF個人宣布辭職。持續近半個月的大戲,以這種令人遺憾的方式收場.

1900/1/1 0:00:00
GEM:Gemini 創始人炮轟 DCG 17 億美元資金問題成謎_gemini斗魚直播回放

撰文:Mary Liu 2023 年剛開年,幣圈「互撕」大戲又迎來新劇情。1 月 2 日,美國加密交易所 Gemini 聯合創始人 Cameron Winklevoss 拋出一份公開信,指責 D.

1900/1/1 0:00:00
ads