編者按：今日下午，在曼谷Devcon 活動主會場，以太坊核心開發者Justin Drake 公佈了以太坊過去數年來“最具野心”的共識層變提案——Beam Chain，引入了一系列ZK科技以取代「老舊」的以太坊Beacon Cahin。會中 Justin 表示，新的共識層開發或許將持續到 2030 年。然而，市場似乎不買賬，在發表會進行的同時，以太坊價格急速下跌。大家似乎都在想：基金會是不是又多了一個賣幣的藉口？

以下為演講全文：

今年我投入大量時間的專案叫做「Beam Chain 」。 Beam Chain 是一個共識層的重新設計方案，結合了研究路線圖中最新、最先進的想法，目標是以安全且快速的方式從當前的Beacon Chain 過渡到這一設計，而這將更接近以太坊的最終形態。

在我分享更多內容之前，有兩個免責聲明：第一，這是一個提案，僅是我的提議，只有在大家達成共識的情況下才會推進。第二，沒有新的代幣，沒有新的網絡，我們會繼續使用相同的 ticker，Vitalik 對此非常明確。

接下來的演講中，我將嘗試將一個看似瘋狂的想法解釋為一個合理的提案——即徹底重新設計共識層。

首先，我想先講一講 Beam Chain 的大框架願景。 Beam Chain 的範圍專注於共識層，不包括資料層中的 blobs 和執行層中的 EVM，因為 blobs 和 EVM 被應用程式直接使用，需要保持前向相容性，因此更改這兩層的機會相對有限。而共識層不直接被應用程式消費，這使得我們可以在這方面有更大的調整空間。

為什麼要做 Beam Chain？

那麼，為什麼我現在要提出這個共識層的大規模重構呢？

原因主要在於 Beacon Chain 已經有些「老舊」了。

五年前「規格」已經凍結，而在這五年裡發生了很多變化，特別是我們對新視角的理解比五年前更加深入。五年前我們在 PoW 議題上相對幼稚，但從那時起，市場快速發展壯大，我們也更了解了可以幫助減輕 MEV 負外部性的機制。

其次，從工程角度來看，我們現在擁有一種非常強大的技術，叫做 SNARKs。在過去的五年裡，SNARKs 技術取得了大量突破，速度提升了數個量級。同時，我們也看到了 zkVMs 的誕生，zkVMs 是一項了不起的技術，它允許全球任何程式設計師在不需要精通密碼學或深入理解 SNARKs 的情況下，利用這項強大技術。

此外，隨著時間推移，我們現在也清楚知道在 Beacon Chain 上所犯的錯誤，以及累積起來的技術債。這些債務非常頑固，並且會隨時間增加。

現在，或許我們有機會清除這些技術債。因此，我建議將共識層路線圖中最先進的技術整合到 Beam Chain 中。

Beam Chain 包含哪些改變？

接下來，我會花點時間介紹共識層路線圖中具體包含的內容。基本上有九個不同的項目，我將它們分為三個類別：區塊生產、質押和密碼學。

首先是區塊生產，這涉及MEV。目前在區塊建構者和中繼者層級存在大量中心化問題。我們希望引入「包含清單」（inclusion list），以顯著提升抗審查能力。一旦包含清單具備抗審查性，我們就能夠將驗證者與區塊生產流程明確分開。這被稱為提議者-建構者分離（PBS），並包括一些執行函數（execution functions）等想法。

區塊生產類別中的最後一個項目是更快的時隙，也許我們可以在保持當前12 秒時隙不變的情況下進一步縮短時隙，並確保即使是透過家庭網路連接，即便在網路延遲較高的澳大利亞，用戶仍然可以作為驗證者參與其中，享受一流的權益。

第二類是質押。研究人員基本上已經達成共識，認為目前的發行曲線有缺陷，有機會透過調整來改善以太坊的健康狀況和長期發展。質押類別中的第二個項目是將成為驗證者所需的 ETH 從目前的 32 ETH 大幅降低至僅需 1 ETH。

最近出現了一些關於「Orbit」的想法。此外，還有一個被討論多年的想法是單一時隙最終性，這可以顯著加速以太坊的最終性過程。

最後一類是密碼學，包含兩個重要項目。第一個項目是即時對整個共識層進行 SNARK 驗證，並使用合理的硬體支援。

最後，我們能否讓保障以太坊的密碼學在未來幾十年甚至幾百年內都可持續發展，並實現抗量子攻擊呢？

在這裡我使用不同的顏色來區分路線圖中的項目是否可以輕鬆或逐步完成，或者是否很難實現。左上角的四個綠色項目是我認為可以並且應該在Beacon Chain 上逐步實現的項目，而當這些較小的項目完成後，剩下的就是一些重大項目（紅色部分），我認為這些項目最好透過一個更全面的方式來處理。

以「更改通知」為例，為了在合理的硬體上實現對Beacon Chain 的即時證明，我們需要更改雜湊函數、簽章方式，以及狀態序列化和默克爾化的方式。這將是對 Beacon Chain 的一個重大改變，因此也許我們有機會在做出這些調整時，同時進行其他改進。

類似的情況也適用於底部兩個紅色框的「更快的時隙」和「更快的最終性」。五年前設計 Beacon Chain 時，我們的重點是安全性，而不是效能。然而現在我們發現有一些設計既能保持我們所需的安全性，同時也能改善性能，抓住一些容易實現的性能改進。

這張 PPT 展示了從我剛才提到的共識層路線圖到 Vitalik 更廣泛路線圖之間的映射關係。我們的部分專案屬於 Merge 階段，有些屬於 Scourge 階段，還有一部分屬於 Verge 和 Scourge 階段。

這張PPT 的核心目的是傳達Beam Chain 並不是改變整個路線圖，而是識別其中的一個特定子集，加速推進它，並賦予它一個獨特的意義。

共識層路線圖中的「更快的時隙」是新的，因為關於更快時隙的討論是在2024 年開始的，而Vitalik 的路線圖最後一次更新是在2023 年。

除了能夠加速這些重要項目外，我們還可以清理一些先前提到的技術債。如果我們實現單一來源的最終性，就不再需要 epochs，可以直接使用 slots。此外，目前的押金合約有點複雜，是合併時遺留下來的產物；而像同步委員會這樣的基礎設施，在實現對 Beacon Chain 的即時 SNARK 化後將不再需要。這是一個能夠一次清理的機會。

如果你對Beacon Chain 設計中的某些問題感興趣，去年我做了一個完整的演講，討論了我們在設計Beacon Chain 時犯的20 多個錯誤。

這張圖展示了我們自創世以來對共識層的升級全貌。在左下角可以看到，創世發生在 2020 年，從那時起我們每年都進行了新的分叉，每次分叉我們都會對共識層進行逐步的改進。

2021 年我們增加了同步委員會，2022 年進行了合併，2023 年增加了提款功能和原生動態分片，2025 年我們將增加最大有效餘額。

預計未來幾年我們會繼續進行這些逐步的分叉，抓住路線圖左上角標記為綠色的低難度項目。

逐漸我們會遇到瓶頸，一旦所有低難度項目都完成，剩下的都是難以逐步實現的重大項目，這時就需要進行“ Beam Fork」。 Beam Fork 提供了一個透過一次性升級實現共識層大躍進的機會。可以將 Beam Fork 視為一個批次機會，多個升級合併到一個分叉中，既有技術上的優勢，也有治理上的好處。

可以把這種批次的機會稱為「固化加速主義」。這聽起來像個矛盾，但基本的想法是希望以太坊盡快進入維護模式，目前存在這樣的緊張關係。我們知道有一些重要的項目需要對以太坊進行根本性的重構，而拖延這些變革越久，以太坊進入穩定狀態的時間就越遠。

Beam Chain 使用了哪些技術？

接下來是第二部分，我會介紹一些將在 Beam Chain 中使用的技術。可以把這看作是以太坊共識機制的不同時代：最初是工作量證明（POW）時代，然後進入權益證明（POS）時代，現在我們可能進入一個零知識證明（ZK）時代。

在 ZK 時代，我們將大量使用 SNARKs 技術。一個我們已經在使用 SNARKs 的地方就是為整個 Beam Chain——整個共識層——提供零知識驗證，這時 zkVMs（零知識虛擬機）變得非常有用。

想像一下，我們可以在不同的高階程式語言中實作Beam Chain，例如用Rust 和Go，然後將這些高階語言編譯成zkVMs 可以理解的字節碼，從而實現SNARK 驗證，而無需擔心底層細節。

需要強調的一點是，唯一需要進行 SNARK 驗證的部分是狀態轉換函數（State Transition Function），這是成為共識客戶端的核心。本質上，狀態轉換函數是客戶端建置中很小的一部分，週邊的基礎設施（如網路、同步、快取優化或區塊選擇規則）都不需要進行 SNARK 驗證。

過去幾年，RISC-V 已成為這些 zkVMs 的業界標準。 RISC-V 是一種指令集，基本上可以將高階程式碼編譯為 RISC-V 指令。現在已經有七家公司提供了 RISC-V zkVMs，例如你可能聽說過的 RISC Zero 和 SP1 等。

需要注意的是，這項強大的技術也可以用於執行層，這與Beam Chain 的故事有所不同，但它非常令人興奮，因為它意味著我們可以大幅提高gas 上限，增強以太坊作為L1 的垂直擴展性，不過這是另一個話題。

在 Beam Chain 中另一個大量使用 SNARKs 的地方是可聚合簽章。我們希望擁有抗量子的可聚合簽名，這裡的提案是使用雜湊函數。雜湊函數具備抗量子安全性，可以作為建構密碼學的基本模組。

我們將使用基於哈希的簽名，由驗證者和證明者生成，並且還將引入基於哈希的SNARKs，可以將成千上萬的簽名壓縮為一個證明。透過這兩者結合，我們可以建構一個基於哈希的抗量子、可聚合的方案，可用於以太坊。一個有趣的細節是，這個聚合方案具有無限遞歸聚合的能力，也就是說可以將聚合的結果繼續再聚合，這是目前 BLS 簽章無法實現的，而且彈性更強。

我今天提出這個提案的原因是，最近幾個月裡 SNARK 雜湊函數效能取得了巨大進步。對於了解情況的人來說，我們現在已經能在筆記本上進行驗證。

這項基準測試是在一台MacBook Pro 的CPU 上完成的，現在可以每秒驗證200 萬次哈希，這個速度非常驚人，這意味著這個基於哈希的提案在Beam Chain 上有著極大的性能潛力。

除了我們將使用的 zkVM 和 SNARKs，我還想強調，我們在很大程度上將復用現有的基礎設施。

例如，網路庫 libp2p、序列化函式庫 Simple Serialize 等都可以直接重複使用。 Pyspec 框架也是如此，這是我們用來編寫正式規格和單元測試的 Python 規範框架。

此外，還可以重複使用 Protocol Guild 等基礎設施，這些在 Beacon Chain 初期並不存在，但現在可以免費復用。

同樣地，現在也有了多個團隊支援 Beacon Chain 的開發，當時我們並沒有共識客戶端的團隊。而現在的五個共識客戶端團隊可以直接投入使用，無需重新組成。

此外，我們還有專門的團隊負責合併的維運，例如Panda Ops 團隊提供的DevOps 支援、安全團隊和激勵團隊等應用研究小組，這些都是可以直接利用的資源。

最後一部分，我想談談下一步和未來的展望。一個可能的結果是，從 2025 年開始，我們將進入規範化流程。這將由一小群研究人員進行，可能需要整個一年。 2026 年，開發流程將啟動，客戶端團隊開始編寫生產級程式碼，接著在 2027 年進入非常徹底的測試流程，以確保安全性和生產部署的穩定性。

身為研究人員，我接下來的任務是開始編寫可執行規範，我稱之為「可執行路線圖」。我們的想法是將路線圖中的「像素」、各類研究和學術論文中的數十萬字內容，以及研究人員頭腦中的各種想法結合在一起，提取其核心精華，形成一個可執行的規範文件。最終，這將會是一個非常精簡的文檔，大約是 1000 行 Python 程式碼。

對我來說，令人振奮的一點是，如果大家對Beam Chain 的新方向達成大致共識，這將是一個絕佳的機會，為共識客戶端注入新血。

目前，我們的共識客戶端團隊遍佈北美、歐洲和大洋洲。今天，我很高興地宣布，已經有新的團隊願意開發 Beam 用戶端。其中一個團隊位於印度，叫做 Zine，他們正在使用 Zig 語言編寫一個 Beam 用戶端。還有一個位於南美洲的 Lambda Class 團隊，也表達了開發 Beam 用戶端的興趣。

如果你也有興趣參與，我們需要大量優秀的人才，包括規格和網路專家、協調員、密碼學專家和客戶端開發者。請透過這個信箱聯絡我們，加入我們，共同開啟這場新的冒險。非常感謝！

原文連結