作者：Christine Kim Galaxy研究副總裁；編譯：秦晉 碳鏈價值
2024年1月4日，以太坊開發(fā)人員齊聚Zoom for All Core Developers Execution (ACDE) Call #178 上。ACDE電話會議通常由以太坊基金會協(xié)議負(fù)責(zé)人Tim Beiko主持，是一個開發(fā)人員討論和協(xié)調(diào)以太坊執(zhí)行層（EL）變更的雙周系列會議。本周的會議由一位網(wǎng)名為「Lightclient」的匿名Geth EL開發(fā)人員主持。開發(fā)人員再次確認(rèn)了Cancun/Deneb（Dencun）升級的接下來三個公共測試網(wǎng)激活日期。他們還討論了 Dencun之后的下一個硬分叉升級Prague/Electra中代碼更改（EIPs）的優(yōu)先事項(xiàng)。
假期期間沒有對Dencun升級進(jìn)行具體更新。自12月21日上次ACDE 電話會議以來，客戶端團(tuán)隊(duì)一直在為Goerli 測試網(wǎng)準(zhǔn)備新版本。由于之前因Prysm導(dǎo)致升級測試延遲，Geth開發(fā)者M(jìn)arius van der Wijden 要求Prysm客戶端團(tuán)隊(duì)提供他們切割新版本的最新進(jìn)展。Prysm開發(fā)者Terence Tsao證實(shí)，Prysm團(tuán)隊(duì)將在下周準(zhǔn)備好Goerli 硬分叉的新版本。不過，針對Goerli的版本將是一個「預(yù)發(fā)布」版本，這意味著它不會是推薦在以太坊主網(wǎng)上使用的Prysm版本。在Goerli硬分叉之后，Prysm團(tuán)隊(duì)計劃發(fā)布另一個版本，其中包含某些更改和更新，推薦用戶在主網(wǎng)上運(yùn)行，并在Sepolia或Holesky測試網(wǎng)上進(jìn)行測試。
雖然Tsao表示Prysm團(tuán)隊(duì)對Goerli硬分叉激活日期為1月17日感到滿意，正如ACDE #177上討論的那樣，但他建議在Goerli硬分叉之后再確定Sepolia和Holesky硬分叉激活日期。自ACDE #177以來，以太坊基金會協(xié)議支持負(fù)責(zé)人Tim Beiko已為Goerli、Sepolia和Holesky 這三個以太坊公共測試網(wǎng)提出了公共測試網(wǎng)分叉時間。建議的分叉激活時間如下：
Goerli--2024年1月17日--紀(jì)元231680--時間戳1705473120
Sepolia--2024年1月30日--紀(jì)元132608--時間戳1706655072
Holesky--2024年2月7日--紀(jì)元29696—時間戳1707305664
Lightclient詢問Prysm之外的其他客戶端團(tuán)隊(duì)是否同意Beiko提出的 Goerli硬分叉激活時間。參加電話會議的所有客戶端團(tuán)隊(duì)（包括Geth、Lodestar、Lighthouse、Teku和Besu）都確認(rèn)，他們認(rèn)為時機(jī)不錯，最遲下周就能為Goerli節(jié)點(diǎn)操作員發(fā)布版本。Lighthouse客戶端團(tuán)隊(duì)指出，鑒于他們?nèi)栽跍y試其客戶端的某些網(wǎng)絡(luò)功能，他們發(fā)布的版本可能與Prysm一樣是預(yù)發(fā)布版本。
隨后，Lightclient就Sepolia和Holesky測試網(wǎng)的建議激活時間展開討論。一位網(wǎng)名為「Potuz」的Prysm開發(fā)者（化名）建議暫緩確定主網(wǎng)之前最后兩個測試網(wǎng)的升級日期。「我們應(yīng)該盡量不要現(xiàn)在就承諾日期，因?yàn)镚oerli的事情可能并不順利，從那里返回是個問題。添加一個具有正確紀(jì)元的新版本，不做任何改動是很容易的。刪除一個版本并修復(fù)錯誤則是個問題。這比幾周的時間要長得多，」Potuz表示。
Lightclient強(qiáng)調(diào)說，客戶端團(tuán)隊(duì)在Goerli硬分叉一周后才需要發(fā)布新版本，因此，除非在1月24日或之后在Goerli上發(fā)現(xiàn)升級問題，否則不一定要刪除新版本。Geth開發(fā)者M(jìn)arius van der Wijden表示，他認(rèn)為為Sepolia和Holesky測試網(wǎng)設(shè)定日期并沒有什么壞處，因?yàn)槿绻鸊oerli上出現(xiàn)問題，開發(fā)者可以隨時更改日期。
以太坊基金會DevOps工程師巴納巴斯-布薩（Barnabas Busa）在 Zoom聊天室中寫道，在他看來，只有在確認(rèn)Goerli的版本正常運(yùn)行后，才有必要為Sepolia和Holesky 的升級發(fā)布新版本。一位網(wǎng)名為「Sean」的Lighthouse開發(fā)者同意這一觀點(diǎn)，他說開發(fā)者可以為Sepolia硬分叉設(shè)定一個「暫定」日期，但在1月30日之前應(yīng)該先看看Goerli的進(jìn)展情況。
Potuz建議在Goerli和Sepolia 硬分叉激活之間增加一周的測試時間，基本上用兩周時間進(jìn)行分析，而不是三周。他說，增加一周的測試時間可以讓客戶端發(fā)行版「浸泡」幾天，然后客戶端團(tuán)隊(duì)才需要為下一次測試網(wǎng)升級再次切割新版本。「兩周時間太近了。這就是我要指出的問題。」Potuz補(bǔ)充說，如果Goerli客戶端發(fā)行版得到了充分的分析和測試，那么在Sepolia和Holesky硬分叉激活之間可能不需要三周的周轉(zhuǎn)時間。
Potuz的觀點(diǎn)引發(fā)了爭議。以太坊基金會的安斯加-迪特里希斯（Ansgar Dietrichs）稱，升級的第一個公共測試網(wǎng)激活與升級的主網(wǎng)激活之間的時間通常是開發(fā)者的「截止時間」，不需要延長。不過，Dietrichs也指出，對于延長測試網(wǎng)升級間隔時間的愿望，開發(fā)者應(yīng)該在硬分叉背景下更認(rèn)真地討論，而不僅僅是Dencun升級。Dietrichs說：「如果有人希望有一個更漫長的過程，那么我們應(yīng)該在有時間的時候討論這個問題，而不是在硬分叉之前。」
Lightclient同意Dietrichs的觀點(diǎn)，認(rèn)為如果早在10月份就進(jìn)行討論，開發(fā)者很可能會對延長Dencun的測試網(wǎng)時間表更加寬容。Lightclient說：我認(rèn)為還有一部分原因是，我們想在去年秋天完成升級，所以現(xiàn)在我們真的在努力實(shí)現(xiàn)這一目標(biāo)，我認(rèn)為我們的時間表安排應(yīng)該更積極一些。
根據(jù)開發(fā)者在電話會議上分享的觀點(diǎn)，以太坊基金會DevOps工程師 Parithosh Jayanthi 建議將Sepolia硬分叉升級推遲一周左右，并將 Sepolia硬分叉的日期定在Goerli升級之后的1月25日ACDE電話會議上。Marius van der Wijden反對完全依賴ACDE電話來重新討論測試網(wǎng)升級激活的日期。他說：「我真正希望避免的是，我們不得不再打一次 All Core Devs電話來確認(rèn)日期，」他補(bǔ)充說：我討厭再打一次 All Core Devs電話，只是為了說「好把，Sepolia現(xiàn)在可以開始了。」而現(xiàn)在我們必須等待兩周，才可以真正開始實(shí)現(xiàn)Sepolia。
為了安撫各方的情緒，Geth開發(fā)者Guillaume Ballet建議為Sepolia硬分叉創(chuàng)建兩套暫定日期，如果Goerli硬分叉的結(jié)果是積極的，開發(fā)者可以堅持使用其中一套日期；如果Goerli硬分叉的結(jié)果是消極的，開發(fā)者可以使用另一套日期。然而，Lightclient和Dietrichs都反對這個想法，因?yàn)樵陂_發(fā)者為Sepolia硬分叉設(shè)定新的時間表之前，必須先對Goerli上的錯誤和問題的性質(zhì)進(jìn)行評估。
順便說一句，以太坊基金會測試團(tuán)隊(duì)的一位網(wǎng)名為「Danceratopz」的化名開發(fā)者詢問，開發(fā)者是否想等評估完Goerli測試網(wǎng)絡(luò)上的blob過期問題后再升級Sepolia。作為背景知識，blob過期指的是在大約兩周后從以太坊狀態(tài)中刪除blob數(shù)據(jù)。
來自Lighthouse的Sean和Besu團(tuán)隊(duì)的Justin Florentine都贊成在主網(wǎng)激活Dencun之前，先在三個測試網(wǎng)之一上評估blob到期情況。Florentine強(qiáng)調(diào)說，在測試網(wǎng)上等待blob到期也將有利于第二層Rollup協(xié)議團(tuán)隊(duì)和應(yīng)用開發(fā)人員為Dencun升級做好準(zhǔn)備。來自 Lighthouse的Sean說，雖然在Goerli上觀察blob過期并不是必要的，但這可能是延長Sepolia和Holesky之間測試期的一個原因，這樣開發(fā)人員和第二層團(tuán)隊(duì)就可以在Sepolia上經(jīng)歷整個blob生命周期。電話會議上，其他開發(fā)人員沒有明確同意Sean的建議。
相反，Lightclient在電話會議上詢問開發(fā)人員是否愿意堅持Beiko提出的時間表，即1月30日升級Sepolia，一周后的2月7日升級 Holesky。由于開發(fā)人員沒有更多的不同意見，Lightclient表示開發(fā)人員將堅持原來的時間表。Potuz在Zoom聊天中寫道，他希望在2月7日同時升級Sepolia和Holesky測試網(wǎng)，而不是提前一周升級前者。在通話后的Discord消息中，Lightclient再次確認(rèn)Dencun的測試網(wǎng)時間表暫時保持不變。
接下來，開發(fā)人員討論了Dencun之后的下一次升級（Prague/Electra）應(yīng)優(yōu)先考慮哪些EIP。Marius van der Wijden說，開發(fā)人員應(yīng)集中精力完成Prague/Electra的默克爾樹升級，而不是其他EIP。他對這一觀點(diǎn)補(bǔ)充了兩點(diǎn)注意事項(xiàng)，首先是默克爾樹的準(zhǔn)備情況。正如在 ACDE #177上所討論的，開發(fā)人員正計劃召開一次專門的ACDE電話會議，深入探討默克爾樹的實(shí)施細(xì)節(jié)及其硬分叉升級的準(zhǔn)備情況。
Van der Wijden提到的第二個注意事項(xiàng)是將EL上的升級與共識層（CL）解耦的能力。Van der Wijden 提到，CL上有一些「高優(yōu)先級、超級緊急」的EIP，可能需要比EL上的默克爾樹升級更快地實(shí)施。「我認(rèn)為重要的是，共識層人員要討論他們是否有必要對這些[緊急]變更進(jìn)行硬分叉，是否可以在沒有EL參與的情況下完成，或者是否需要EL 參與，而我們無論如何都需要進(jìn)行聯(lián)合硬分叉，然后我可以接受一個較小的硬分叉」。van der Wijden 說：「所以，默克爾樹絕對是重中之重，我們應(yīng)該在考慮到這兩點(diǎn)的情況下推動它。」
以太坊基金會研究員安斯加-迪特里希斯（Ansgar Dietrichs）在Zoom 聊天室中寫道，他「強(qiáng)烈反對」將Prague/Electra升級重點(diǎn)放在默克爾樹上，因?yàn)榭紤]到默克爾樹所需的代碼更改的復(fù)雜性，這很可能意味著升級要推遲到2025年。Nethermind客戶端開發(fā)人員Lukasz Rozmej也同意Dietrichs的觀點(diǎn)。Rozmej說：「我的經(jīng)驗(yàn)告訴我，狀態(tài)的重新設(shè)計是非常困難的，而且需要非常長的時間，」他補(bǔ)充說，「雖然我認(rèn)為默克爾樹非常好，而且正在取得巨大進(jìn)步，但我認(rèn)為如果我們只關(guān)注默克爾，下一次硬分叉至少需要一年甚至更長的時間。因此，我的建議是，可能會專注于一些較小的硬分叉，同時每個團(tuán)隊(duì)都會致力于默克爾，并為這個主題分配適當(dāng)?shù)馁Y源、工作量、腦力，無論你怎么稱呼它。」
對于Prague/Electra應(yīng)專注于默克爾還是優(yōu)先考慮比默克爾更快發(fā)布的較小代碼變更，開發(fā)人員意見不一。Ballet強(qiáng)調(diào)，在他看來，「不存在小分叉」，開發(fā)者在實(shí)施默克爾之前等待的時間越長，實(shí)施以太坊狀態(tài)更新的難度就越大。Tomasz K. Stańczak也是Nethermind客戶端的開發(fā)者，他建議采取一種雄心勃勃的方法，承諾采用比Prague/Electra可能包含的更多的EIP。[讓我們]利用團(tuán)隊(duì)的能力，在這一年里，我們必須證明我們能夠應(yīng)對最大的挑戰(zhàn)。如果默克爾最終向團(tuán)隊(duì)表明，到3月份有越來越多困難堆積起來，那么人們可能會再次提出疑問，并說「好吧，默克爾下課」。但我們會繼續(xù)使用我們將包括在內(nèi)的一套相當(dāng)不錯的其他EIP，Stańczak說道，他指定除默克爾之外，Prague/Electr還可能包括的其他一些重要EIP，如與質(zhì)押、重新質(zhì)押與賬戶抽象相關(guān)的EIP。
Lightclien在回答Stańczak的問題時說，開發(fā)人員在承諾采用一套EIP之后，可能很難繼續(xù)討論P(yáng)rague/Electra中應(yīng)該包括哪些EIP，而其中一個EIP（指默克爾）是「一個需要18到24個月的項(xiàng)目」。Erigon客戶端的開發(fā)者安德魯-阿西克明（Andrew Ashikhmin）贊成在布Prague/Electra分叉中發(fā)布較小的EIP，并同時開發(fā)默克爾，以便在之后的分叉中使用。Ballet贊成Stańczak的建議，即在Prague/Electra 中重點(diǎn)開發(fā)默克爾，如果發(fā)現(xiàn)其實(shí)施過程中存在重大問題，需要更多時間來解決，則將其從升級中刪除。
關(guān)于將EL(執(zhí)行層)和CL（共識層）升級解耦的問題，Potuz提到，Prague/Electra只有一個EIP提議只需要對CL進(jìn)行更改。「唯一的變化是取消了認(rèn)證索引委員會......以及所有其他變化，即使是那些看起來只涉及CL的變化，如 Max EB，也取決于EL的其他變化。因此，我認(rèn)為純粹的CL分叉是不會發(fā)生的。至少，我認(rèn)為今年不會，明年也不會。我們沒有足夠的純CL提案，」Potuz說。
盡管如此，Ansgar Dietrichs還是說，有些EIP主要是以CL為中心的升級，只需要對EL稍作改動，EL客戶端團(tuán)隊(duì)就可以輕松執(zhí)行。這些 EIP仍需要EL和CL協(xié)調(diào)硬分叉。Dietrichs隨后補(bǔ)充說，他認(rèn)為從CL方面來看，數(shù)據(jù)可用性采樣（DAS）是EIP 4844之后最重要的代碼變更。Dietrichs和Lightclient就DAS是否需要硬分叉來實(shí)現(xiàn)存在一些分歧。
一位網(wǎng)名為「Rodiazet」的化名開發(fā)者在以太坊基金會的Ipsilon團(tuán)隊(duì)工作，該團(tuán)隊(duì)致力于以太坊虛擬機(jī)（EVM）的研究。作為背景，EOF 是EVM Object Format的縮寫，是對EVM的一系列改進(jìn)，最初被考慮納入Cancun/Deneb升級中。
除默克爾外，開發(fā)人員還提出一些其他EIP供考慮，如EIP 5920（PAY 操作碼）和EIP 2537（BLS12-381曲線操作的預(yù)編譯）。Prague/Electra候選EIP的完整列表可以在以太坊魔術(shù)師網(wǎng)站上的升級元線程中找到。雖然大多數(shù)開發(fā)者都贊成在Cancun/Deneb會議之后在某種程度上優(yōu)先考慮默克爾，但目前還不清楚在多大程度上默克爾應(yīng)被優(yōu)先用于Prague/Electra，而不是那些在2024年可以更快、更容易實(shí)現(xiàn)的小型 EIP。Lightclient強(qiáng)調(diào)，開發(fā)者無需在本周的電話會議上就Prague/Electra的內(nèi)容做出最終決定。他建議在即將舉行的ACDE電話會議上繼續(xù)討論該主題。
隨后，開發(fā)人員很快談到了Prague/Electra主題中尚未在通話中討論的EIP，包括但不限于以下EIP：
EIP-7002：執(zhí)行層可觸發(fā)退出
EIP-7549：將委員會索引移至認(rèn)證之外
EIP-3074：AUTH和AUTHCALL操作碼
EIP-6110: 在鏈上提供驗(yàn)證器存款
EIP-6913: SETCODE指令
EIP-7377: 遷移事務(wù)
EIP-4444：執(zhí)行客戶端中的綁定歷史數(shù)據(jù)
EIP-6404：SSZ交易根
EIP-6465：SSZ提取根
EIP-6466：SSZ 收據(jù)根
EIP-7212：預(yù)編譯secp256r1的曲線支持
有關(guān)對上述EIP的看法的詳細(xì)概述，請參閱YouTube上發(fā)布的完整通話錄音。
最后，以太坊基金會研究員Carl Beekhuizen重提了有關(guān)EIP 7587的討論，該討論將保留一組預(yù)編譯地址，供第二層協(xié)議使用。Beekhuizen 詢問開發(fā)人員如何才能最好地將EIP正式化，使其成為一個信息性的 EIP，為今后的以太坊治理流程創(chuàng)建規(guī)范。Nethermind開發(fā)者Ahmad Bitar建議將EIP納入EIP 1文件，該文件概述了EIP流程的指導(dǎo)方針。Lightclient建議在以太坊魔術(shù)師網(wǎng)站上進(jìn)一步討論這個話題，并在下一次ACDE電話會議上根據(jù)需要重新討論這個話題。
喜來順財經(jīng)
