APP內打開

8月31日乙太坊覈心開發者會議:坎昆陞級、Verkle Trie轉換、SSZ序列化

HelloBtc.pro 2023-09-03 11:30:20
二維碼

掃碼分享

本周,開發人員討論了以下方面的開發和測試進度:1)坎昆/Deneb (Dencun) 升級  2)Verkle Trie 轉換  3)SSZ 序列化更新

作者:Christine Kim / 來源:白話區塊鏈

翻譯:火火/白話區塊鏈

作者:Christine Kim

原文:https://www.galaxy.com/insights/research/ethereum-all-core-developers-execution-call-169/

image.png

8月31日,以太坊開發人員聚集在 Zoom 進行了Core Developers Execution (ACDE) 電話會議。 ACDE 電話會議由以太坊基金會的 Tim Beiko 主持,每兩周舉行一次系列會議,以太坊客戶端團隊在會上討論和協調對以太坊執行層(EL) 的更改。 本周,開發人員討論了以下方面的開發和測試進度:

1)坎昆/Deneb (Dencun) 升級

2)Verkle Trie 轉換

3)SSZ 序列化更新

1、坎昆升級

Devnet #8 於兩周前的8 月 16 日推出。 以太坊基金會的 DevOps 工程師 Barnabas Busa 表示,以開發人員為中心的坎昆升級測試網看起來很運轉良好。 Busa 提到,運行 Nethermind (EL) 客戶端軟體的節點似乎存在一些問題。 Nethermind 用戶端的開發人員 Lukasz Rozmej 解釋說,問題的本質是由於 Blob 事務池實現中的配置錯誤造成的。 (譯者注:Devnet 8 是首個專用的測試網,其中包含了Cancun/Deneb 升級的所有最終確定的EIPs)

關於EIP 4788,開發人員簡要地再次確認了代碼更改的新部署策略。 在 EL 上公開信標鏈數據的合約將像常規智慧合約一樣部署,這需要有人在升級啟動之前為合約位址提供資金。 坎昆升級的下一個測試網 Devnet #9 將採用此工作流程,並確保開發人員熟悉該流程。

開發人員沒有推遲 Devnet #9 的發佈日期,而是同意繼續在 Devnet #8 上進行測試,直到用戶端實現的所有問題都得到解決。 “我寧願對 Devnet #9 充滿信心,而不是說我們希望這些事情能夠發揮作用。 ...... 我寧願解決我們知道的問題。 否則,如果我們在 Devnet #9 中遇到很難的問題,那麼我們肯定又會有 Devnet #10,我並不是說我們不應該有 Devnet #10。 我們應該擁有有意義的開發網路數量。 我認為現在我們可以嘗試讓 Devnet #9 變得真正可靠。 “以太坊基金會研究員兼 ACDC 電話會議主席 Danny Ryan 說道。

電話會議中的其他人,包括 Tim Beiko、Marius Van Der Wijden 和 Justin Florentine,都贊成花更多時間在 Devnet #8 上進行測試,並稍後在 Devnet #9 上測試 EIP 4788 中的更改。 Beiko 建議開發人員在下一次 ACDE 電話會議期間重新召集 Devnet #9 的時間。 關於測試網部署策略,Beiko 建議以下順序:

1)Devnet #9:又一個 Devnet,其 Dencun 規範已凍結。 對網路進行壓力測試並假設開發人員對此感到滿意,然後轉向公共測試網。 否則,啟動Devnet #10。

2)Holesky:分叉新推出的 Holeksy 測試網並在其上部署 Dencun 升級。

3)Goerli:然後在Goerli上部署Dencun。 作為主網之前倒數第二個測試網的啟動,此時的升級規範應該是最終的,併為使用者和應用程式在主網升級啟動之前提供足夠的時間來測試其軟體。 在 Goerli 被棄用並被 Holesky 取代之前,Dencun 很可能是 Goerli 上的最後一個分叉。 (譯者注:Dencun 一詞為 Cancun(坎昆)和 Deneb 所組成的合成詞。 Cancun 為本次以太坊執行層升級的名字,而 Deneb 則為協定層升級的名字。 因此,Cancun 升級與 Deneb 升級被合稱為 Dencun 升級。 )

4)Sepolia:最後,在 Sepolia 上部署 Dencun 以達到良好的效果。

對於 Beiko 在 Devnet #9 後發布測試網的提議,沒有人提出異議。 Beiko 提到,一旦 Holesky 測試網於 9 月 15 日正式啟動,上述時程表將在一篇博客文章中與更廣泛的以太坊社區共用。 此外,Beiko 表示還有一個名為Ephemery的測試網正在開發中。 Ehemery 是一個以太坊測試網,面向驗證節點運營商,一兩周後會重置回創世狀態。 有關 Ephemery 網路的更多資訊,請在此處閱讀該專案的 GitHub 頁面。

在繼續討論 Verkle Tries 之前,Busa 強調了GitHub 上針對 Holesky 測試網的開放拉取請求 (PR) 。 應 Erigon (EL) 團隊的要求,PR 建議取消 Holesky 上 Dencun 升級的特定激活時間。 開發人員稍後將為 Holesky 上的 Dencun 啟動設置一個值,而不是重寫現有值。 Busa 還提出了關於測試 3/6 blob 目標/最大值(而不是 2/4 限制)的問題。 關於這個話題,Beiko 建議在下周的 ACDC 電話會議上再次提出這個問題,Ryan 提到最近對大區塊大小的實驗將帶來新的見解。

2、Verkle Trie 轉換

接下來,開發人員討論了 Vitalik Buterin 的提議,即結合 Verkle Trie 和 State Expiry 路線圖,以降低 Verkle Trie 實施的複雜性並加快 State Expiry 在以太坊上的優勢。 作為背景,Verkle Trie 或 Verkle Tree 是一種數據結構,允許使用者依靠單個加密證明輕鬆驗證大量數據。 它們與 Merkle Patricia Trie (MPT) 沒有什麼不同,後者是用於存儲以太坊狀態的數據結構。 然而,Verkle 樹的證明效率相對高於 MPT,這就是開發人員一直致力於將 MPT 過渡到 Verkle 的原因。

狀態到期是一項單獨的計劃,旨在解決狀態無限制增長的問題。 狀態過期的目標是刪除使用者在一段時間內(例如365天內)未訪問的部分以太坊狀態,從而將狀態大小從超過100 GB減少到小於50 GB。 Erigon (EL) 客戶團隊的 Andrew Ashikhmin 贊成將這兩個升級捆綁在一起,假設如果與 State Expiry 結合起來,Verkle Trie 轉換將會大大簡化。 來自 Geth (EL) 客戶團隊的 Guillaume Ballet 一直是 Verkle Trie 專案的帶頭人,他擔心耦合會延遲 Verkle Tries,因為狀態到期作為一個研究主題在過去兩年已被“放棄”。

Buterin 附和了更多有關他提案動機的背景資訊,他說:“隨著 [Verkle] 的過渡過程,問題基本上是將50多 GB 的 Merkle Patricia Trie 轉換為...... 實時網路中的 Verkle Trie 只是相當複雜。 這確實是研究團隊苦惱了一整年多的事情。 我記得去年在 Devconnect 上,它基本上是研究活動的主題,基本上與 Verkle 路線圖的整個其餘部分放在一起一樣多的研發工作,只是如何進行最後一次過渡的過程。 在某些方面,它的複雜性確實可以與合併相媲美。 ”

Buterin 繼續說道 State Expiry 如何顯著降低向 Verkle 過渡的複雜性。 不過,他也提到,狀態到期有複雜的先決條件,例如需要添加更多位址空間來支援新的「位址期」「 每年。 因此,儘管實現 Verkle 的複雜性會降低,但開發人員仍然需要解決難題才能同時執行兩者。 此外,如果 Verkle Tries 在 State Expiry 之前實現,State Expiry 的緊迫性就會降低,因此開發人員應該考慮使用 Verkle 進行過渡,或者等待幾年在 Verkle 之後引入 State Expiry。 開發人員不清楚將這兩個升級捆綁在一起會產生的額外價值,並同意繼續在 Discord 和 Verkle Trie Implementors' Call 上異步討論該主題。

3、SSZ 序列化

然後,Nimbus (CL) 客戶端的開發人員 Etan Kissling 介紹了他將以太坊數據結構升級為 SSZ 序列化格式的最新進展。 有關此問題的更多背景資訊,請在此處閱讀之前的以太坊開發人員通話記錄。 Kissling 強調了一種使用基於 SSZ“PartialContainer”的格式來更新以太坊數據序列化的新方法。 Kissling在本周電話會議議程下的評論中寫道,“這種[格式]本質上結合了[先前格式]的所有優點,並且還可以重複用於其他目的,從而淘汰當前未使用的 SSZ Union 和 SSZ 可選類型。” (譯者注:簡單序列化(SSZ) 是信標鏈上使用的序列化方法。 這種方法取代了除對等點發現協定以外的共識層各處執行層上所用的遞歸長度前綴序列化。 簡單序列化設計具有確定性,也可以有效地進行默克爾化。 )

更新后,Beiko 快速赞扬了 Python 中新创建的 EL 参考实现(称为 EELS)。在以太坊基金会最近的一篇博客文章中,EIP 编辑兼以太坊基金会研究员 Sam Wilson写道:“EELS 是以太坊执行客户端核心组件的 Python 参考实现,专注于可读性和清晰度。EELS 旨在作为黄皮书的精神继承者,对程序员更加友好,并且与合并后分叉保持同步,EELS 可以填写和执行状态测试,遵循主网,并且是构建新 EIP 原型的好地方。”

一些开发人员已经在使用 EELS 来重新实现他们的 EIP,并且以太坊基金会为有兴趣更新黄皮书的任何人提供了一笔赠款,以包括伦敦和巴黎等缺失的预合并网络升级,以补充 EELS。