作者：Christine Kim / 來源：https://www.galaxy.com/insights/research/ethereum-all-core-d

翻譯：火火/白話區塊鏈

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。