Vitalik關於以太坊可能的未來（四）：The Verge

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

原文作者：Vitalik Buterin

原文編譯：Mensh，ChainCatcher

前文閱讀：《Vitalik 關於以太坊可能的未來（一）： The Merge》、《Vitalik 關於以太坊可能的未來（二）：The Surge》、《Vitalik 關於以太坊可能的未來（三）：The Scourge》

特別感謝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

我們要解決什麼問題？

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

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

它如何運作？

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

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

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

2. 程式碼未被 Merkle 化。這意味著要證明帳戶代碼的任何存取權限，都需要提供整個代碼，最多為 24000 位元組。

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

30000000 gas / 2400 (冷帳戶閱讀成本) *（5 * 488 + 24000) = 330000000 位元組

分支成本略有降低（用5*480 代替8*480），因為當分支較多時，其頂端部分會重複出現。但即便如此，在一個時隙內要下載的資料量也是完全不切實際的。如果我們嘗試用STARK 來封裝它，就會遇到兩個問題：(i) KECCAK 對STARK 相對不友善；(ii) 330MB 的資料意味著我們必須證明對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 - 1og256(N ) =  4* log2(N) 位元組。因此，理論上的最大證明大小大致為30000000 / 2400 *32* (32 -14 + 8) / 8 = 130000 位元組（由於狀態區塊的分佈不均勻，實際計算結果略有不同，但作為第一近似值是可以的）。

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

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

STARKed 二進位哈希樹

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

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

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

1. 快速對Poseidon 進行大量安全分析，並對其足夠熟悉，以便在L1 進行部署

2. 使用更"保守"的雜湊函數，如SHA256 或BLAKE

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

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

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

· 記憶體池：當交易被廣播時，P2P 網路中的節點需要在重新廣播之前驗證交易是否有效。如今驗證包括驗證簽名，還包括檢查餘額是否足夠和前綴是否正確。在未來（例如，使用原生帳戶抽象，如EIP-7701，這可能涉及運行一些EVM 程式碼，這些程式碼會進行一些狀態存取。如果節點是無狀態的，則交易需要附帶證明狀態物件的證明。

· 包含清單：這是一個提議的功能，允許（可能規模較小且不復雜的）權益證明驗證者強制下一個區塊包含交易，而不管（可能規模較大且複雜的）區塊建構者的意願。性。運行輕型客戶端（如Helios).Helios 核心模組為用戶提供經過驗證的狀態根。網呼叫請求（使用者需要證明在呼叫過程中存取的所有狀態）。證明，但每個證明都很小 因此，STARK 證明對它們並沒有實際意義；相反，最現實的做法是直接使用Merkle 分支。為根的狀態物件X 的證明，如果收到一個子區塊B2 及其見證，就可以更新證明，使其以區塊B2 為根。

與現有研究有哪些關聯：

· Verkle trees

· John Kuszmaul 關於Verkle tree 的原始論文

· Starkware

· Poseidon2 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。這將使 BLAKE3 即使在今天也（勉強）夠用。

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

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

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

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

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

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

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 的計算，並且不存在漏洞。提高安全性的兩種主要技術是多驗證器和形式驗證。多驗證器指的是有多個獨立編寫的有效性證明實現，就像有多個客戶端一樣，如果一個區塊被這些實現中的一個足夠大的子集證明，客戶端就會接受該區塊。形式驗證涉及使用通常用於證明數學定理的工具，如 Lean4，以證明有效性證明只接受正確執行底層 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 成功實現有效性證明，就能最終實現輕鬆的單人質押：即使是最弱的電腦（包括手機或智慧型手錶）也能質押。這進一步提高了解決單人質押的其他限制（如 32ETH 最低限額）的價值。

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

共識的有效性證明

我們要解決什麼問題？

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

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

它是什麼，如何運作？

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

· ECADD（用於驗證BLS 簽名）

· 配對（用於驗證BLS 簽名)

· SHA256 雜湊值（用於讀取和更新狀態）

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

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

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

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

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

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

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

· 雜湊函數的變化：現在使用的是"完整"的SHA256 雜湊函數，因此由於填充的原因，每次呼叫都要對應兩次底層壓縮函數呼叫。如果改用 SHA256 壓縮函數，我們至少可以獲得 2 倍的收益。如果改用Poseidon，我們可能會獲得100 倍的增益，從而徹底解決我們的所有問題（至少在雜湊值方面）：在每秒170 萬雜湊值（54MB），即使是一百萬個驗證記錄也能在幾秒鐘內「讀取」到證明中。

· 如果是Orbit，則直接儲存洗牌後的驗證器記錄：如果選擇一定數量的驗證器（如8192 或32768 個）作為給定插槽的委員會，則將它們直接放入彼此旁邊的狀態中，這樣只需最少的哈希就能將所有驗證器的公鑰讀入證明中。這樣還可以有效率地完成所有平衡更新。

· 簽章聚合：任何高效能簽章聚合方案都會涉及某種遞歸證明，網路中的不同節點都會對簽章子集進行中間證明。這就自然而然地將證明工作分擔給了網路中的多個節點，從而大大減少了「最終證明者」的工作量。

· 其他簽名方案：對於Lamport+ Merkle 簽名，我們需要256 + 32 個哈希值來驗證簽名；乘以32768 個簽署者，就得到9437184個哈希值。對簽名方案進行最佳化後，可以透過一個很小的常數因子進一步改善這個結果。如果我們使用 Poseidon，這在單一插槽內就能證明。但實際上，使用遞歸聚合方案會更快。

與現有研究有哪些關聯？

· 簡潔的以太坊共識證明（僅限同步委員會）

· 簡潔SP1 內的Helios

· 簡明BLS12-381 預編譯

· 基於Halo2 的BLS 集合簽章驗證

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

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

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

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

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

原文連結

欢迎加入律动 BlockBeats 官方社群：

Telegram 订阅群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方账号：https://twitter.com/BlockBeatsAsia