原文標題：《Possible futures of the Ethereum protocol, part 4: The Verge》

原文作者：Vitalik Buterin

原文編譯：Mensh，ChainCatcher

特別感謝 Justin Drake、Hsia-wei Wanp、Guillaume Ballet、Icinacio、Rosh Rudolf、Lev Soukhanoy Ryan Sean Adams 和 Uma Roy 的反饋和審閱。

區塊鏈最強大的功能之一就是任何人都可以在自己的電腦上運行一個節點，並驗證區塊鏈的正確性。即使 9596 個運行鏈共識（PoW、PoS）的節點都立即同意更改規則，並開始根據新規則生產區塊，每個運行完全驗證節點的人都會拒絕接受鏈。不屬於這種陰謀集團的造幣者會自動匯聚到一條繼續遵循舊規則的鏈上，並繼續構建這條鏈，而完全通過驗證的用戶將遵循這條鏈。

這是區塊鏈與中心化系統的關鍵區別。然而，要使這一特性成立，運行一個完全驗證的節點需要對足夠多的人來說確實可行。這既適用於造勢者（因為如果造勢者不驗證鏈，他們就沒有為執行協議規則做出貢獻），也適用於普通用戶。如今，在消費類筆記本電腦（包括寫這篇文章時使用的筆記本電腦）上運行節點是可能的，但要做到這一點卻很困難。The Verge 就是要改變這種狀況，讓完全驗證鏈的計算成本變得低廉，讓每個手機錢包、瀏覽器錢包甚至智能手錶都會默認進行驗證。

The Verge 2023 路線圖

最初，"Verge"指的是將以太坊狀態存儲轉移到 Verkle 樹——一種允許更緊湊證明的樹形結構，可實現以太坊區塊的無狀態驗證。節點可以驗證一個以太坊區塊，而無需在其硬盤上存儲任何以太坊狀態（賬戶餘額、合約代碼、存儲空間......），代價是花費幾百 KB 的證明數據和幾百毫秒的額外時間來驗證一個證明。如今，Verge 代表了一個更大的願景，專注於實現以太坊鏈的最大資源效率驗證，其中不僅包括無狀態驗證技術，還包括使用 SNARK 驗證所有以太坊執行。

除了對 SNARK 驗證整條鏈的長期關注之外，另一個新問題與 Verkle 樹是否是最佳技術有關。Verkle 樹容易受到量子計算機的攻擊，因此，如果我們將目前的 KECCAK Merkle Patricia 樹中的 Verkle 樹，我們以後還得再次替換樹。Merkle 樹的自替代方法是直接跳過使用 Merkle 分支的 STARK，將其放入二叉樹。從歷史上看，由於開銷和技術複雜性，這種方法一直被認為是不可行的。不過最近，我們看到 Starkware 在一臺筆記本電腦上使用 ckcle STARKs 每秒證明了 170 萬個 Poseidon 哈希，而且由於 GKB 等技術的出現，更多 "傳統 "哈希值的證明時間也在迅速縮短。因此，在過去的一年裡，"Verge"變得更加開放，它有幾種可能性。

The Verge：關鍵目標

• 無狀態客戶機：完全驗證客戶機和標記節點所需的存儲空間不應超過幾 GB。
• (長期）在智能手錶上完全驗證鏈（共識和執行）。下載一些數據，驗證 SNARK，完成。

在本章中

• 無狀態客戶機：Verkle 還是 STARKs
• EVM 執行的有效性證明
• 共識的有效性證明

無狀態驗證：Verkle 還是 STARKs

我們要解決什麼問題？

如今，以太坊客戶端需要存儲數百千兆字節的狀態數據來驗證區塊，而且這一數量每年都在增加。原始狀態數據每年增加約 30 GB，單個客戶端必須在上面存儲一些額外的數據，才能有效地更新三元組。

這就減少了能夠運行完全驗證以太坊節點的用戶數量：儘管足以存儲所有以太坊狀態甚至多年曆史的大硬盤隨處可見，但人們默認購買的電腦往往只有幾百千兆字節的存儲空間。狀態大小也給首次建立節點的過程帶來了巨大的摩擦：節點需要下載整個狀態，這可能需要數小時或數天的時間。這會產生各種連鎖反應。例如，它大大增加了節點製作者升級其節點設置的難度。從技術上講，可以在不停機的情況下完成升級——啟動一個新客戶端，等待它同步，後關閉舊客戶端並傳輸密鑰——但在實際操作中，這在技術上非常複雜。

它如何工作？

無狀態驗證是一種允許節點在不掌握整個狀態的情況下驗證區塊的技術。取而代之的是，每個區塊都附帶一個見證，其中包括：(i) 該區塊將訪問的狀態中特定位置的值、代碼、餘額、存儲； (ii) 證明這些值正確的加密證明。

實際上，實現無狀態驗證需要改變以太坊的狀態樹結構。這是因為當前的 Merkle Patricia 樹對於實施任何加密證明方案都是極端不友好的，尤其是在最壞的情況下。無論是 "原始 "Merblk 分枝，還是"包裝"成 STARK 的可能性，都是如此。主要困難源於 MPT 的一些弱點：

1.這是一棵六叉樹（即每個節點有 16 個子節點）。這意味著，在大小為 N 的樹中，一個證明平均需要 32*( 16-1)*log 16(N) = 120* log 2(N)字節，或者在 2 ^ 32 項的樹中大約需要 3840 字節。對於二叉樹，只需要 32*( 2-1)*log 2(N) = 32* log 2(N)字節，或大約 1024 字節。

2.代碼未被 Merkle 化。這意味著要證明賬戶代碼的任何訪問權限，都需要提供整個代碼，最多為 24000 字節。

我們可以計算出最壞的情況如下：

30000000 gas / 2400 (冷賬戶閱讀成本) * （5 * 488 + 24000) = 330000000 字節

分支成本略有降低（用 5* 480 代替 8* 480），因為當分支較多時，其頂端部分會重複出現。但即便如此，在一個時隙內要下載的數據量也是完全不現實的。如果我們嘗試用 STARK 來封裝它，就會遇到兩個問題：(i) KECCAK 對 STARK 相對不友好；(ii) 330 MB 的數據意味著我們必須證明對 KECCAK round 函數的 500 萬次調用，這對於除了最強大的消費級硬件之外的所有硬件來說，都可能證明不了，即使我們能讓 STARK 證明 KECCAK 的效率更高。

如果我們直接用二叉樹代替十六進制樹，並對代碼進行額外的 Merkle 化處理，那麼最壞的情況大致會變成 30000000/2400* 32*( 32-14+ 8) = 10400000 字節（14 是對 2 ^ 14 分支的冗餘位進行的減法，而 8 則是進入代碼塊中葉的證明的長度）。需要注意的是，這需要改變 gas 成本，對訪問每個單獨的代碼塊收費；EIP-4762 就是這麼做的。10.4 MB 的容量要好得多，但對於許多節點來說，在一個時隙內下載的數據還是太多了 。因此，我們需要引入更強大的技術。在這方面，有兩種領先的解決方案：Verkle 樹和 STARKed 二進制哈希樹。

Verkle 樹

Verkle 樹使用基於橢圓曲線的矢量承諾來進行更短的證明。解鎖的關鍵在於，無論樹的寬度如何，每個父子關係對應的證明部分都只有 32 字節。證明樹寬度的唯一限制是，如果證明樹過寬 ，證明的計算效率就會降低。為以太坊提出的實現方案寬度為 256 。

因此，證明中單個分支的大小變為 32 - 1 og 256(N) = 4* log 2(N)字節。因此，理論上的最大證明大小大致為 30000000 / 2400 * 32* ( 32 -14 + 8) / 8 = 130000 字節（由於狀態塊的分佈不均勻，實際計算結果略有不同， 但作為第一近似值是可以的）。

另外需要注意的是，在上述所有示例中，這種 "最壞情況 "並不是最壞情況：更壞的情況是攻擊者故意"挖掘"兩個地址，使其在樹中具有較長的共同前綴，並從其中一個地址讀取數據，這可能會將最壞情況下的分支長度再延長 2 倍。但即使有這樣的情況，Verkle 樹的最壞證明長度為 2.6 MB，與目前最壞情況下的校驗數據基本吻合。

我們還利用這一注意事項做了另一件事：我們讓訪問 "相鄰 "存儲空間的成本變得非常低廉：要麼是相同合同的許多代碼塊，要麼是相鄰的存儲槽。EIP - 4762 提供了鄰接的定義，對鄰接訪問只收取 200 gas 費。在相鄰訪問的情況下，最壞情況下的證明大小變為 30000000 / 200* 32 - 4800800 字節，這仍大致在公差範圍內。如果為了安全起見，我們希望減少這個值，可以稍微增加相鄰訪問的費用。

STARKed 二進制哈希樹

這項技術的原理不言自明：你只需做一棵二叉樹，獲取最大 10.4 MB 的證明，證明塊中的值，後用證明的 STARK 代替證明。這樣，證明本身就只包含被證明的數據，再加上來自實際 STARK 的 100-300 kB 固定開銷。

這裡的主要挑戰是驗證時間。我們可以進行與上述基本相同的計算，只不過我們計算的不是字節數，而是哈希值。一個 10.4 MB 的區塊意味著 330000 個哈希值。如果再加上攻擊者 "挖掘 "地址樹中具有較長公共前綴的可能性，那麼最壞情況下的哈希值將達到約 660000 哈希值。因此，如果我們能證明每秒的哈希值為 200, 000 ，那就沒問題了。

在使用 Poseidon 哈希函數的消費類筆記本電腦上，這些數字已經達到，而 Poseidon 哈希函數是專門為 STARK 友好性而設計的。但是，Poseidon 系統還相對不成熟，因此很多人還不信任它的安全性。因此，有兩條現實的前進道路：

1. 快速對 Poseidon 進行大量安全分析，並對其足夠熟悉，以便在L1進行部署
2. 使用更 "保守 "的哈希函數，如 SHA 256 或 BLAKE

如果要證明保守的哈希函數，Starkware 的 STARK 圈在撰寫本文時只能在消費類筆記本電腦上每秒證明 10-30 k 哈希值。不過，STARK 技術正在迅速改進。即使在今天，基於 GKR 的技術也顯示出將這一速度提高到 100-2 O 0 k 範圍。

除驗證區塊外的見證使用案例

除了驗證區塊外，還有其他三個關鍵用例需要更高效的無狀態驗證：

• 內存池：當交易被廣播時，P2P網絡中的節點需要在重新廣播之前驗證交易是否有效。如今驗證包括驗證簽名，還包括檢查餘額是否充足和前綴是否正確。在未來（例如，使用原生賬戶抽象，如 EIP-7701 ，這可能會涉及運行一些 EVM 代碼，這些代碼會進行一些狀態訪問。如果節點是無狀態的，則交易需要附帶證明狀態對象的證明。
• 包含列表：這是一個提議的功能，允許（可能規模較小且不復雜的）權益證明驗證者強制下一個區塊包含交易，而不管（可能規模較大且複雜的）區塊構建者的意願。這將削弱有權勢者通過延遲交易來操縱區塊鏈的能力。不過，這需要驗證者有辦法驗證包含列表中交易的有效性。
• 輕客戶端：如果我們希望用戶通過錢包訪問鏈（如 Metamask、Rainbow、Rabby 等），要做到這一點，他們需要運行輕型客戶端（如 Helios).Helios 核心模塊為用戶提供經過驗證的狀態根。而為了獲得完全無信任的體驗，用戶需要為他們所做的每個 RPC 調用提供證明（例如，對於以太網調用請求（用戶需要證明在調用過程中訪問的所有狀態）。

所有這些用例都有一個共同點，那就是它們需要相當多的證明，但每個證明都很小。因此，STARK 證明對它們並沒有實際意義；相反，最現實的做法是直接使用 Merkle 分支。Merkle 分支的另一個優點是可更新：給定一個以區塊 B 為根的狀態對象 X 的證明，如果收到一個子區塊 B 2 及其見證，就可以更新證明，使其以區塊 B 2 為根。Verkle 證明也是原生可更新的。

與現有研究有哪些聯繫：

• Verkle trees
• John Kuszmaul 關於 Verkle tree 的原始論文
• Starkware
• Poseidon 2 paper
• Ajtai (基於晶格硬度的替代快速哈希函數)
• Verkle.info

還能做些什麼？

剩下的主要工作是

1.關於 EIP-4762 後果的更多分析（無狀態 gas 成本變化）

2.完成和測試過渡程序的更多工作，這是任何無國籍環境實施方案複雜性的主要部分

3.對 Poseidon、Ajtai 和其他"STARK-friendly "哈希函數的更多安全分析

4.為 "保守"（或 "傳統"）哈希進一步開發超高效 STARK 協議功能，例如基於 Binius 或 GKR 的觀點。

此外，我們很快就會決定從以下三個選項中選擇一個：(i) Verkle 樹，(ii) STARK 友好哈希函數以及(iii)保守哈希函數。它們的特性可大致歸納在下表中：

除了這些 "標題數字"，還有其他一些重要的考慮因素：

• 如今，Verkle 樹代碼已經相當成熟。除了 Verkle 之外，使用其他任何代碼都會推遲部署，很可能會推遲一個硬分叉。這也沒有關係，尤其是如果我們需要額外的時間來進行哈希函數分析或驗證器實現，或者我們有其他重要的功能想要更早地納入以太坊。
• 使用哈希值更新狀態根比使用 Verkle 樹更快。這意味著基於哈希值的方法可以降低全節點的同步時間。
• Verkle 樹具有有趣的見證更新屬性——Verkle 樹見證是可更新的。這個屬性對 mempool、包含列表和其他用例都很有用，而且還可能有助於提高實現效率：如果更新了狀態對象，就可以更新倒數第二層的見證，而無需讀取最後一層的內容。
• Verkle 樹更難進行 SNARK 證明。如果我們想把證明大小一直減小到幾千字節，Verkle 證明就會帶來一些困難。這是因為 Verkle 證明的驗證引入了大量 256 位操作，這就要求證明系統要麼有大量開銷，要麼本身有一個定製的內部結構，其中包含 256 位的 Verkle 證明部分。這對無狀態本身不是問題，但會帶來更多困難。

如果我們想以量子安全且合理高效的方式獲得 Verkle 見證可更新性，另一種可能的途徑是基於 lattice 的 Merkle 樹。

如果在最壞的情況下，證明系統的效率不夠高，那麼我們還可以利用多維 gas 這意料之外的工具來彌補這種不足：為(i) calldata；(ii)計算；(iii)狀態訪問以及可能的其他不同資源設定單獨的 gas 限制。多維 gas 增加了複雜性，但作為交換，它更嚴格地限制了平均情況和最壞情況之間的比率。有了多維 gas，理論上需要證明的最大分支數可能會從 12500 減少到例如 3000 。這將使 BLAKE 3 即使在今天也（勉強）夠用。

多維 gas 允許區塊的資源限制更接近於底層硬件的資源限制

另一個意料之外的工具是將狀態根計算延遲到區塊之後的時隙。這樣，我們就有整整 12 秒的時間來計算狀態根，這意味著即使在最極端的情況下，每秒也只有 60000 哈希數的證明時間是足夠的，這再次讓我們認為 BLAKE 3 只能勉強滿足要求。

這種方法的缺點是會增加一個時隙的輕客戶端延遲，不過也有更巧妙的技術可以將這種延遲減少到僅為證明生成延遲。例如，證明可以在任何節點生成後立即在網絡上廣播，而不 是等待下一個區塊。

它與路線圖的其他部分如何互動？

解決無狀態問題大大提高了單人定點的難度。如果有技術能降低單人定點的最低平衡，如 Orbit SSF 或應用層策略，如小隊定點，這將變得更可行。

如果同時引入 EOF，多維 gas 分析就會變得更加容易。這是因為多維 gas 最主要的執行復雜度來源於處理不傳遞父調用全部 gas 的子調用，而 EOF 只需將此類子調用設為非法，就可將這一問題變得微不足道（和本機帳戶抽象將為部分 gas 的當前主要使用情況提供一個協議內替代方案。

無狀態驗證和歷史過期之間還有一個重要的協同作用。如今，客戶端必須存儲近 1 TB 的歷史數據；這些數據是狀態數據的數倍。即使客戶機是無狀態的，除非我們能解除客戶機存儲歷史數據的責任，否則幾乎無存儲客戶機的夢想將無法實現。這方面的第一步是 EIP-4444 ，這也意味著將歷史數據存儲在 torrents 或門戶網站 Portal Network 中。

EVM 執行的有效性證明

我們要解決什麼問題？

以太坊區塊驗證的長期目標很明確——應該能夠通過以下方式驗證以太坊區塊：(i)下載區塊，或者甚至只下載區塊中數據可用性採樣的一小部分；(ii)驗證區塊有效的一個小證明。這將是一個資源佔用極低的操作，可以在移動客戶端、瀏覽器錢包中完成，甚至可以在另一個鏈中完成（沒有數據可用性部分）。

要達到這一點，需要對（i）共識層（即股權證明）和（ii）執行層（即 EVM）進行 SNARK 或 STARK 證明。前者本身就是一個挑戰，應該在進一步不斷改進共識層的過程中加以解決（例如，針對單槽終局性）。後者需要 EVM 執行證明。

它是什麼，如何運作？

從形式上看，在以太坊規範中，EVM 被定義為一個狀態轉換函數：你有一些前狀態 S，一個區塊 B，你正在計算一個後狀態 S' = STF(S，B)。如果用戶使用的是輕客戶端，他們並不完整地擁有 S 和 S'，甚至 E；相反，他們擁有一個前狀態根 R，一個後狀態根 R'和一個區塊哈希值 H。

• 公共輸入：前狀態根 R, 後狀態根 R' , 塊哈希 H
• 私人輸入：程序塊主體 B、程序塊 Q 訪問的狀態中的對象、執行程序塊 Q'後的相同對象、狀態證明（如 Merkle 分支）P
• 主張 1 ：P 是一個有效的證明，證明 Q 包含 R 所代表的狀態的某些部分
• 主張 2 ：如果在 Q 上運行 STF，(i) 執行過程只訪問 Q 內部的對象，(ii) 數據塊是有效的，(iii) 結果是 Q'
• 主張 3 ：如果利用 Q' 和 P 的信息重新計算新的狀態根，就會得到 R'

如果存在這種情況，就可以擁有一個完全驗證以太坊 EVM 執行的輕型客戶端。這使得客戶端的資源已經相當低。要實現真正的完全驗證以太坊客戶端，還需要在共識方面做同樣的工作。

用於 EVM 計算的有效性證明的實現已經存在，並被L2大量使用。而要使 EVM 有效性證明在L1中可行，還有很多工作要做。

與現有研究有哪些聯繫？

• EFPSE ZK-EVM（由於存在更好的選擇，現已停用）
• Zeth，其工作原理是將 EVM 編譯到 RISC-0 ZK-VM 中
• ZK-EVM 形式化驗證項目

還能做些什麼？

如今，電子記賬系統的有效性證明在兩個方面存在不足：安全性和驗證時間。

一個安全的有效性證明需要保證 SNARK 確實驗證了 EVM 的計算，並且不存在漏洞。提高安全性的兩種主要技術是多驗證器和形式驗證。多驗證器指的是有多個獨立編寫的有效性證明實現，就像有多個客戶端一樣，如果一個區塊被這些實現中的一個足夠大的子集證明，客戶端就會接受該區塊。形式驗證涉及使用通常用於證明數學定理的工具，如 Lean 4 ，以證明有效性證明只接受正確執行底層 EVM 規範（例如 EVM K 語義或用 python 編寫的以太坊執行層規範 (EELS)）。

足夠快的驗證時間意味著任何以太坊區塊都能在不到 4 秒的時間內得到驗證。今天，我們離這個目標還很遙遠，儘管我們已經比兩年前想象的要接近得多。要實現這一目標，我們需要在三個方向上取得進展：

• 並行化——目前最快的 EVM 校驗器平均可在 15 秒內證明一個以太坊區塊。它是通過在數百個 GPU 之間進行並行化，後在最後將它們的工作彙總在一起來實現這一點的。從理論上講，我們完全知道如何製造一個能在 O(log(N))時間內證明計算的 EVM 驗證器：讓一個 GPU 完成每一步，後做一個 "聚合樹"：

實現這一點存在挑戰。即使是在最壞的情況下，即一個非常大的事務佔用了整個區塊，計算的分割也不能按次進行，而必須按操作碼（EVM 或 RISC-V 等底層虛擬機的操作碼）進行。要確保虛擬機的"內存"在證明的不同部分之間保持一致，是實施過程中的一個關鍵挑戰。不過，如果我們能實現這種遞歸證明，那麼我們知道，即使在其他方面沒有任何改進，至少證明者的延遲問題已經解決了。

• 證明系統優化--新的證明系統，如 Orion、Binius、GRK 以及其他更多信息，很可能會導致又一次大大縮短了通用計算的驗證時間。
• EVM gas 成本的其他變化——EVM 中的許多東西都可以優化，使其更有利於證明者，尤其是在最壞的情況下。如果攻擊者可以構建一個阻塞證明者十分鐘時間的區塊，那麼僅能在 4 秒內證明一個普通的以太坊區塊是不夠的。所需的 EVM 更改可大致分為以下幾類：

• gas 成本的變化——如果一個操作需要很長時間才能證明，那麼即使它的計算速度相對較快，也應該有很高的 gas 成本。EIP-7667 是為處理這方面最嚴重的問題而提出的一個 EIP：它大大增加了（傳統）哈希函數的 gas 成本，因為這些函數的操作碼和預編譯相對便宜。為了彌補這些 gas 成本的增加，我們可以降低證明成本相對較低的 EVM 操作碼的 gas 成本，從而保持平均吞吐量不變。

• 數據結構替換——除了用對 STARK 更友好的方法替換狀態樹外，我們還需要替換事務列表、收據樹和其他證明成本高昂的結構。Etan Kissling 將事務和收據結構移至 SSZ 的 EIP 就是朝著這個方向邁出的一步。

除此之外，上一節提到的兩個工具（多維 gas 和延遲狀態根）也能在這方面提供幫助。不過，值得注意的是，與無狀態驗證不同的是，使用這兩個工具意味著我們已經擁有了足夠的技術來完成我們目前所需的工作，而即使使用了這些技術，完整的 ZK-EVM 驗證也需要更多的工作——只是需要的工作更少而已。

上文沒有提到的一點是證明器硬件：使用 GPU、FPGA 和 ASIC 更快地生成證明。Fabric Cryptography、Cysic 和 Accseal 是三家在這方面取得進展的公司。這對L2來說非常有價值，但不太可能成為L1的決定性考慮因素，因為人們強烈希望L1保持高度去中心化，這意味著證明生成必須在以太坊用戶的合理範圍內，而不應受到單個公司硬件的瓶頸限制。L2可以做出更積極的權衡。

在這些領域中，還有更多的工作要做：

• 並行化證明要求證明系統的不同部分可以 "共享內存"（如查找表）。我們知道這樣做的技術，但需要加以實現。
• 我們需要進行更多的分析，以找出理想的 gas 成本變化集，從而最大限度地減少最壞情況下的驗證時間。
• 我們需要在證明系統方面做更多的工作

可能的代價是：

• 安全性與驗證器時間：如果選擇更激進的哈希函數、更復雜的證明系統或更激進的安全假設或其他設計方案，就有可能縮短驗證器時間。
• 去中心化與證明器時間：社區需要就所針對的證明器硬件的 “規格 ”達成一致。要求證明者是大規模實體可以嗎？我們希望高端消費筆記本電腦能在 4 秒內證明一個以太坊區塊嗎？介於兩者之間？
• 打破向後兼容性的程度：其他方面的不足可以通過更積極的 gas 成本變化來彌補，但這更有可能不成比例地增加某些應用程序的成本，迫使開發人員重寫和重新部署代碼，以保持經濟可行性。同樣，這兩個工具也有其自身的複雜性和弊端。

它與路線圖的其他部分如何互動？

實現L1 EVM 有效性證明所需的核心技術在很大程度上與其他兩個領域共享：

• L2的有效性證明（即 "ZK rollup"）
• 無狀態的 "STARK 二進制哈希證明 "方法

在L1成功實現有效性證明，就能最終實現輕鬆的單人質押：即使是最弱的計算機（包括手 機或智能手錶）也能質押。這進一步提高了解決單人質押的其他限制（如 32 ETH 最低限額）的價值。

此外，L1的 EVM 有效性證明可以大大提高L1的 gas 限值。

共識的有效性證明

我們要解決什麼問題？

如果我們想用 SNARK 完全驗證一個以太坊區塊，那麼 EVM 的執行並不是我們需要證明的唯一部分。我們還需要證明共識，即系統中處理存款、取款、簽名、驗證器餘額更新以及以太坊權益證明部分其他元素的部分。

共識比 EVM 簡單得多，但它面臨的挑戰是，我們沒有L2 EVM 卷積，因此無論如何，大部分工作都要完成。因此，任何證明以太坊共識的實現都需要 "從頭開始"，儘管證明系統本身是可以在其基礎上構建的共享工作。

它是什麼，如何工作？

信標鏈被定義為狀態轉換函數,就像 EVM 一樣。狀態轉換函數主要由三部分組成：

• ECADD（用於驗證 BLS 簽名）
• 配對（用於驗證 BLS 簽名）
• SHA 256 哈希值（用於讀取和更新狀態）

在每個區塊中，我們需要為每個驗證器證明 1-16 個 BLS 12-381 ECADD（可能不止一個，因為簽名可能包含在多個集合中）。這可以通過子集預計算技術來彌補，因此我們可以說每個驗證者只需證明一個 BLS 12-381 ECADD。目前，每個插槽有 30000 個驗證器簽名。未來，隨著單時隙終局性的實現，這種情況可能會向兩個方向發生變化：如果我們採取 "蠻力"路線，每個時隙的驗證者數量可能會增加到 100 萬。與此同時，如果採用 Orbit SSF，驗證器數量將保持在 32768 個，甚至減少到 8192 個。

BLS 聚合如何工作：驗證總簽名只需要每個參與者一個 ECADD，而不是一個 ECMUL。但是 30000 個 ECADD 仍然是一個很大的證明量。

就配對而言，目前每個插槽最多有 128 個證明，這意味著需要驗證 128 個配對。通過 ElP-7549 和進一步的修改，每個插槽可以減少到 16 個。配對的數量很少，但成本極高：每個配對的運行（或證明）時間比 ECADD 長數千倍。

證明 BLS 12-381 運算的一個主要挑戰是，沒有曲線階數等於 BLS 12-381 字段大小的便捷曲線，這給任何證明系統都增加了相當大的開銷。另一方面，為以太坊提出的 Verkle 樹是用 Bandersnatch 曲線構建的，這使得 BLS 12-381 本身成為 SNARK 系統中用於證明 Verkle 分支的自曲線。一個比較簡單的實現每秒可以證明 100 G 1 的加法；要使證明速度足夠快，幾乎肯定需要像 GKR 這樣的巧妙技術。

對於 SHA 256 哈希值來說，目前最糟糕的情況是紀元轉換塊，整個驗證器短平衡樹和大量驗證器平衡都會被更新。每個驗證器的短平衡樹只有一個字節，因此有 1 MB 的數據會被重新取哈希。這相當於 32768 次 SHA 256 調用。如果有一千個驗證者的餘額高於或低於一個閾值，需要更新驗證者記錄中的有效餘額，這相當於一千個 Merkle 分支，因此可能需要一萬次哈希值。洗牌機制需要每個驗證器 90 比特（因此需要 11 MB 的數據），但這可以在一個紀元的任何時間計算。在單槽終結的情況下，這些數字可能會根據具體情況有所增減。洗牌變得沒有必要，儘管 Orbit 可能會在一定程度上恢復這種需要。

另一個挑戰是需要重新獲取所有驗證器狀態，包括公鑰，才能驗證一個區塊。對於 100 萬個驗證器來說，僅讀取公鑰就需要 4800 萬字節，再加上 Merkle 分支。這就需要每個紀元數以百萬計的哈希值。如果我們必須證明 PoS 的有效性，一種現實的方法是某種形式的增量可驗證計算：在證明系統內存儲一個單獨的數據結構，該數據結構經過優化，可以高效查找，並證明對該結構的更新。

總之，挑戰很多。要最有效地應對這些挑戰，很可能需要對信標鏈進行深入的重新設計，而這可能與轉向單槽終結同時進行。這種重新設計的特點可能包括：

• 哈希函數的變化：現在使用的是 "完整 "的 SHA 256 哈希函數，因此由於填充的原因，每次調用都要對應兩次底層壓縮函數調用。如果改用 SHA 256 壓縮函數，我們至少可以獲得 2 倍的收益。如果改用 Poseidon，我們可能會獲得 100 倍的增益，從而徹底解決我們的所有問題（至少在哈希值方面）：在每秒 170 萬哈希值（54 MB），即使是一百萬條驗證記錄也能在幾秒鐘內 "讀取 "到證明中。
• 如果是 Orbit，則直接存儲洗牌後的驗證器記錄：如果選擇一定數量的驗證器（如 8192 或 32768 個）作為給定插槽的委員會，則將它們直接放入彼此旁邊的狀態中，這樣只需最少的哈希就能將所有驗證器的公鑰讀入證明中。這樣還可以高效地完成所有平衡更新。
• 簽名聚合：任何高性能簽名聚合方案都會涉及某種遞歸證明，網絡中的不同節點會對簽名子集進行中間證明。這就自然而然地將證明工作分擔給了網絡中的多個節點，從而大大減少了 "最終證明者 "的工作量。
• 其他簽名方案：對於 Lamport+ Merkle 簽名 ，我們需要 256 + 32 個哈希值來驗證簽名；乘以 32768 個簽名者，就得到 9437184 個哈希值。對簽名方案進行優化後，可以通過一個很小的常數因子進一步改善這一結果。如果我們使用 Poseidon，這在單個插槽內就能證明。但實際上，使用遞歸聚合方案會更快。

與現有研究有哪些聯繫？

• 簡潔的以太坊共識證明（僅限同步委員會）
• 簡潔 SP 1 內的 Helios
• 簡明 BLS 12-381 預編譯
• 基於 Halo 2 的 BLS 集合簽名驗證

還有哪些工作要做，如何取捨：

實際上，我們需要數年時間才能獲得以太坊共識的有效性證明。這與我們實現單槽終局性、Orbit、修改簽名算法以及安全分析所需的時間大致相同，而安全分析需要足夠的信心才能使用像 Poseidon 這樣 "激進 "的哈希函數。因此，最明智的做法是解決這些其他問題，並在解決這些問題的同時考慮到 STARK 的友好性。

主要的權衡很可能是在操作順序上，在改革以太坊共識層的更漸進的方法和更激進的 "一次改變許多 "的方法之間。對於 EVM 來說，漸進式方法是合理的，因為它能最大限度地減少對向後兼容性的干擾。對共識層來說，向後兼容性的影響較小，而且對信標鏈構建方式的各種細節進行更 "全面 "的重新思考，以最佳方式優化 SNARK 友好性也有好處。

它與路線圖的其他部分如何互動？

在對以太坊 PoS 進行長期重新設計時，STARK 友好性必須成為首要考慮因素，尤其是單槽終局性、Orbit、簽名方案變更和簽名聚合。