8月31日，以太坊開發人員在 ACD E會議上討論了Cancun升級、Verkle Trie 轉換和 SSZ序列化更新等開發和測試進展。本文源自 Christine Kim 所著文章 《Ethereum All Core Developers Execution Call #169 Writeup》，由白話區塊鏈編譯、整理。
（前情提要：以太坊EIP-4844：坎昆升級的核心 ）
（背景補充：ETH Taipei》V神出席以太坊台北聚會：台灣開發者超優秀、坎昆升級重點.. ）
8 月 31 日，以太坊開發人員聚集在 Zoom 進行了 Core Developers Execution (ACDE) 電話會議。ACDE 電話會議由以太坊基金會的 Tim Beiko 主持，每兩週舉行一次系列會議，以太坊客戶端團隊在會上討論和協調對以太坊執行層 (EL) 的更改。本週，開發人員討論了以下方面的開發和測試進度：
- 坎昆 / Deneb (Dencun) 升級
- Verkle Trie 轉換
- 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 建議以下順序：
- Devnet #9 ：又一個 Devnet，其 Dencun 規範已凍結。對網路進行壓力測試並假設開發人員對此感到滿意，然後轉向公共測試網。否則，啟動 Devnet #10。
- Holesky ：分叉新推出的 Holeksy 測試網並在其上部署 Dencun 升級。
- Goerli ：然後在 Goerli 上部署 Dencun。作為主網之前倒數第二個測試網的啟動，此時的升級規範應該是最終的，併為使用者和應用程式在主網升級啟用之前提供足夠的時間來測試其軟體。在 Goerli 被棄用並被 Holesky 取代之前，Dencun 很可能是 Goerli 上的最後一個分叉。（譯者注：Dencun 一詞為 Cancun（坎昆）和 Deneb 所組成的合成詞。 Cancun 為本次以太坊執行層升級的名字，而 Deneb 則為協議層升級的名字。 因此，Cancun 升級與 Deneb 升級被合稱為 Dencun 升級。）
- Sepolia ：最後，在 Sepolia 上部署 Dencun 以達到良好的效果。
對於 Beiko 在 Devnet #9 後釋出測試網的提議，沒有人提出異議。Beiko 提到，一旦 Holesky 測試網於 9 月 15 日正式啟動，上述時間表將在一篇部落格文章中與更廣泛的以太坊社群共享。此外，Beiko 表示還有一個名為 Ephemery 的測試網正在開發中。Ehemery 是一個以太坊測試網，面向驗證節點運營商，一兩週後會重置回創世狀態。
在繼續討論 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。
📍相關報導📍
坎昆升級預備》以太坊核心開發者：EIP-4844專用測試網Devnet #7即將上線
