作者：Christine Kim，galaxy；翻譯：火火/白話區塊鏈
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。
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。