本文中提到的這些技術改進為以太坊的去中心化和輕量化驗證奠定了基礎，逐步實現低資源設備也能運行完全驗證節點的目標，使得網路更安全、易於存取。
原文：Possible futures of the Ethereum protocol, part 4: The Verge（vitalik.eth）
作者： vitalik.eth
編譯： lllu_23，LXDAO
封面： Photo by Shubham Dhage on Unsplash
譯者前言
為了實現更廣泛的去中心化與可驗證性，以太坊在不同歷史時期提出並嘗試了多種技術路徑，直至 2023 年， The Verge 路線圖逐步明確了無狀態驗證（Stateless verification）、EVM 執行的有效性證明（Validity proofs of EVM execution）和共識的有效性證明（Validity proofs of consensus）等核心技術。無狀態驗證引入了 Verkle 樹以優化資料儲存效率，這使得以太坊客戶端在不儲存完整狀態的情況下也能驗證區塊。 EVM 執行的有效性證明則讓使用者只需下載區塊或部分資料即可驗證執行的正確性，減少了驗證複雜度。共識層的有效性證明則確保在權益證明（PoS）機制下的交易、簽章和驗證器操作的正確性，提升共識驗證的效率並減少完全驗證節點的計算負擔。
本文中提到的這些技術改進為以太坊的去中心化和輕量化驗證奠定了基礎，逐步實現低資源設備也能運行完全驗證節點的目標，使得網路更安全、易於存取。
本文概述
本文共約 10,000 字，分為 3 個部分，閱讀完預計需要 50 分鐘。
- 無狀態驗證：Verkle 或 STARKs
- EVM 執行的有效性證明
- 共識的有效性證明
正文內容
《以太坊協議可能的未來（四）：The Verge》
特別感謝 Justin Drake、Hsia-wei Wang、Guillaume Ballet、Ignacio、Josh Rudolf、Lev Soukhanov、Ryan Sean Adams 和 Uma Roy 的回饋和審查。
區塊鏈最強大的功能之一就是任何人都可以在自己的電腦上運行一個節點，並驗證鏈的正確性。即使 95% 的運行鏈共識（PoW、PoS...）的節點都立即同意更改規則，並開始根據新規則生產區塊，每個運行完全驗證節點的人都可以拒絕接受該鏈。不屬於這些共謀集團的質押者會自動聚集在一起，繼續建立一條繼續遵循舊規則的鏈，而完全驗證的用戶也會遵循這條鏈。
這是區塊鏈與中心化系統的關鍵差異。然而，要使這項特性成立，需要有足夠的人來運作完全的驗證節點。這既適用於質押者（因為如果質押者不驗證鏈，他們實際上就沒有為協議的執行規則做出貢獻），這也適用於普通用戶。如今，在消費級筆記型電腦（包括寫這篇文章時使用的筆記型電腦）上運行節點是可能的，但要做到這一點卻很困難。 The Verge 的目標是改變這種現狀，讓完全驗證鏈的計算成本變得更加低廉，以至於每個手機錢包、瀏覽器錢包甚至智慧手錶都可以預設進行驗證。
最初，"Verge" 指的是將以太坊的狀態儲存轉移到 Verkle 樹上—— Verkle 樹結構允許更緊湊的證明，從而實現以太坊區塊的無狀態驗證。節點可以驗證一個以太坊的區塊，而無需在其硬碟上儲存任何以太坊狀態（帳戶餘額、合約程式碼、儲存空間等...），其代價是花費數百 KB 的證明資料和幾百毫秒的額外時間來驗證一個證明。如今，Verge 代表了一個更大的願景，專注於實現以太坊鏈的最大資源效率驗證，其中不僅包括無狀態驗證技術，還包括使用 SNARK 來驗證所有以太坊執行。
除了增加對 SNARK 驗證整個鏈的長期關注外，另一個新問題與 Verkle 樹是否是最好的技術有關。 Verkle 樹很容易受到量子電腦的攻擊，因此如果我們用 Verkle 樹取代目前的 KECCAK Merkle Patricia 樹，我們以後就必須再次更換樹。梅克爾（Merkle）樹的自然替代方案是直接跳過二元樹，使用梅克爾分支的 STARK。從歷史上看，由於開銷和技術複雜性，這種方法一直被認為是不可行的。但最近，我們看到 Polygon 在一台筆記型電腦上用 circle STARKs 每秒證明了 170 萬個波塞冬（Poseidon）哈希值，而且由於採用了 GKR 等技術，更多 “傳統” 哈希值的證明時間也在迅速縮短。
因此，在過去的一年裡，The Verge 變得更加開放，有了更多的可能性。
The Verge ：關鍵目標
- 無狀態客戶端：完全驗證客戶端和質押節點不需要超過幾 GB 的儲存空間
- (長期目標）在智慧手錶上完全驗證鏈（共識和執行）。載入一些數據，驗證一個 SNARK，即可完成驗證。
本章內容
- 無狀態驗證：Verkle 或 STARKs
- EVM 執行的有效性證明
- 共識的有效性證明
無狀態驗證：Verkle 或 STARKs
我們要解決什麼問題？
如今，以太坊客戶端需要儲存數百 GB 的狀態資料才能驗證區塊，而且這一數量每年都在增加。原始狀態資料每年增加約 30 GB，單一客戶端必須在此基礎上儲存一些額外的數據，才能有效更新 trie。
這減少了能夠運行完全驗證以太坊節點的用戶數量：儘管有足夠大的硬碟來儲存所有以太坊狀態，甚至是多年的歷史數據，但人們預設購買的電腦往往只有幾百 GB 的儲存空間。狀態大小也為首次建立節點的過程帶來了極大的阻力：節點需要下載整個狀態，這可能需要數小時或數天的時間。這會產生各種連鎖反應。例如，它大大增加了質押者升級其節點設定的難度。從技術上講，可以在不停機的情況下做到這一點——啟動一個新客戶端，等待它同步，然後關閉舊客戶端並轉移金鑰——但在實踐中，技術上會很複雜。
無狀態驗證是什麼，它是如何運作的？
無狀態驗證是一種允許節點在沒有整個狀態的情況下驗證區塊的技術。相反，每個區塊都有一個見證者，其中包括（i）區塊將存取的狀態中特定位置的值（例如程式碼、餘額、儲存），以及（ii）這些值的加密證明是正確的。
實際上，要實現無狀態驗證，就需要改變以太坊的狀態樹結構。這是因為目前的 Merkle Patricia 樹對於任何加密證明方案的實現都是極其不友善的，特別是在最壞的情況下。這不僅適用於「原始」梅克爾樹的分支，也適用於將默克爾樹的分支「封裝」在 STARK 中的可能性。關鍵的困難源自於 MPT 的兩個弱點：
這是一個十六叉樹（即每個節點有 16 個子節點）。這意味著，在平均情況下，一個大小為 N 的樹的證明有 32 * (16 - 1) * log16(N) = 120 * log2(N) 字節，在 2 項的樹中約為 3840 字節。對於二元樹，你只需要 32 * (2 - 1) * log2(N) = 32 * log2(N) 位元組，即大約 1024 位元組。
代碼沒有默克爾化。這意味著證明任何帳戶代碼的存取都需要提供整個代碼，最多 24000 位元組。
我們可以計算出最壞的情況，如下：
30,000,000 gas / 2,400（「冷」帳戶讀取成本）* (5 * 480 + 24,000) = 330,000,000 位元組
分支成本略有降低（5 * 480 而不是 8 * 480），因為分支較多時，分支的頂端部分會重複出現。但即便如此，在一個時隙內下載完這些數據，也是完全不切實際的。如果我們嘗試用 STARK 將其封裝起來，就會遇到兩個問題：(i) KECCAK 對 STARK 相對不友善；(ii) 330 MB 的資料意味著我們必須證明對 KECCAK 輪函數的 500 萬次調用，即使我們能大幅提高 STARK 證明 KECCAK 的效率，但對於除最強大的消費級硬體之外的所有硬體來說都是無法證明的。
如果我們用二元樹替換十六叉樹，並對程式碼進行額外的默克爾化處理，那麼最壞的情況大約為 30,000,000 / 2,400 * 32 * (32 - 14 + 8) = 10,400,000 位元組（14 是對大約 2^14 個分支的冗餘位元進行的減法，而 8 則是進入代碼區塊中葉子的證明的長度）。需要注意的是，這需要改變 gas 成本，對存取每個單獨的程式碼區塊收費；EIP-4762 就是這樣做的。 10.4 MB 要好得多，但對於許多節點來說，在一個時隙內下載的資料仍然太多。因此，我們需要引入一些更強大的技術。在這方面，有兩種領先的解決方案：Verkle 樹和 STARKed 二進位哈希樹。
Verkle 樹
Verkle 樹使用基於橢圓曲線的向量承諾來進行更短的證明。關鍵在於，無論樹的寬度如何，每個父子關係對應的證明部分都只有 32 個位元組。證明樹的寬度的唯一限制是，如果證明樹過寬，其證明的計算效率就會降低。針對以太坊提出的實現方案寬度為 256。
因此，證明中一個分支的大小為 32 * log256(N) = 4 * log2(N) 位元組。因此，理論上的最大證明大小約為 30,000,000 / 2,400 * 32 * (32 - 14 + 8) / 8 = 1,300,000 位元組（由於狀態區塊的分佈不均勻，實際計算結果略有不同，但作為初步近似值是可以的）。
另外要注意的是，在上述所有範例中，這種「最壞情況」並不完全是最壞情況：更壞的情況是攻擊者故意「挖掘」兩個位址，使其在樹中具有較長的共同前綴，並從其中一個位址讀取數據，這會將最壞情況下的分支長度再延長約 2 倍。不過，即使考慮到這一點，Verkle 樹也能讓我們在最壞情況下獲得 2.6 MB 的證明，這與目前最壞情況下的 calldata 大小基本上相同。
我們也利用這項注意事項做了另一件事：我們讓存取「相鄰」儲存空間的費用變得非常低廉：無論是相同合約的許多程式碼區塊，還是相鄰的時隙。 EIP-4762 提供了「相鄰」的定義，相鄰訪問只收取 200 gas 的費用。透過相鄰訪問，最壞情況下的證明大小變為 30,000,000 / 200 * 32 = 4,800,800 字節，仍在可以接受的範圍內。如果為了安全起見，我們希望減少這個數值，可以稍微提高相鄰訪問成本。
STARKed 二進位哈希樹
這項技術的原理不言自明：你只需建造一棵二元樹，取出需要證明塊中值最大為 10.4 MB 的證明，並用證明的 STARK 來取代該證明。這使得證明本身僅由被證明的數據和來自實際 STARK 的大約 100-300 kB 的固定開銷組成。
這裡的主要挑戰是驗證時間。我們可以進行與上述基本相同的計算，只不過我們計算的不是位元組數，而是雜湊次數。一個 10.4 MB 的區塊意味著 330,000 次哈希。如果再加上攻擊者「挖掘」位址樹中具有較長公共前綴的可能性，真正的最壞情況將變成約 660,000 次雜湊。因此，如果我們每秒可以證明大約 200,000 次哈希，就沒有問題了。
這些數字在一台使用 Poseidon 雜湊函數的消費性筆記型電腦上已經達成，而 Poseidon 雜湊函數是專門為 STARK 友善性而設計的。然而，Poseidon 還相對不成熟，因此許多人尚不信任它的安全性。因此，目前有兩條現實的前進道路：
- 快速對 Poseidon 進行大量安全分析，並對其安全性感到足夠放心，以便在 L1 進行部署。
- 使用更 “保守” 的雜湊函數，如 SHA256 或 BLAKE。
截至目前，Starkware 的 circle STARK 證明器在消費級筆記型電腦上僅能以每秒 10,000 到 30,000 次哈希的速度進行證明，前提是它們在證明保守哈希函數。然而，STARK 技術正在快速進步。即使在今天，基於 GKR 的技術顯示出在潛在地將這個速度提升到大約 100,000 到 200,000 範圍的潛力。
除驗證區塊外的見證使用案例
除了驗證區塊外，還有其他三個關鍵用例需要更有效率的無狀態驗證：
- 記憶體池：當交易被廣播時，P2P 網路中的節點需要在重新廣播之前驗證交易是否有效。如今，驗證包括驗證簽名，還包括檢查餘額是否足夠和 nonce 是否正確。在未來（例如，使用本機帳戶抽象，如 EIP-7701），這可能涉及運行一些 EVM 程式碼，這些程式碼執行一些狀態存取。如果節點是無狀態的，則事務需要附帶證明狀態物件的證明。如果節點是無狀態的，交易需要附帶證明，證明狀態物件的有效性。
- 包含清單：這是一項建議功能，允許（可能規模較小且不成熟的）權益證明驗證者強制下一個區塊包含交易，而不管（可能規模較大且成熟的）區塊建構者的意願。這將削弱有權勢者透過延遲交易來操縱區塊鏈的能力。不過，這需要驗證者有辦法驗證包含清單中交易的有效性。
- 輕客戶端：如果我們希望用戶透過錢包（如 Metamask、Rainbow、Rabby......）存取鏈而無需信任中心化實體，他們需要運行輕客戶端（如 Helios）。 Helios 的核心模組為使用者提供經過驗證的狀態根。然而，為了獲得完全無信任的體驗，使用者需要為他們所做的每個 RPC 呼叫提供證明（例如，對於 eth_call 請求，使用者需要證明在呼叫過程中存取的所有狀態）。
所有這些用例都有一個共同點，那就是它們需要相當多的證明，但每個證明都很小。因此，STARK 證明對它們並沒有實際意義；相反，最現實的做法是直接使用梅克爾分支。梅克爾分支的另一個優點是可更新：給定一個以區塊 B 為根的狀態物件 X 的證明，如果收到子區塊 B2 及其見證，就可以更新證明，使其以區塊 B2 為根。 Verkle 證明也是原生可更新的。
與現有研究有哪些關聯？
Verkle trees:
John Kuszmaul 的原版 Verkle 樹論文：
Starkware 證明數據：
Poseidon2 論文：
Ajtai（基於點陣難度的替代快速雜湊函數）：
Verkle.info:https://verkle.info/
還有什麼要做，需要權衡什麼
剩下的主要工作是：
- 關於 EIP-4762 後果的更多分析（無狀態 gas 成本變化）
- 完成和測試過渡程序的更多工作，這在任何無狀態 EIP 的複雜性中佔據了很大一部分。
- 對 Poseidon、Ajtai 和其他"STARK-friendly" 雜湊函數的更多安全分析
- 為「保守」（或「傳統」）的雜湊函數開發更多超高效率的 STARK 協議，例如基於 Binius 或 GKR 的想法。
此外，我們很快就會圍繞下面三種選項進行決策：(i) Verkle 樹，(ii) STARK 友善雜湊函數，以及 (iii) 保守雜湊函數。它們的特性可大致歸納在下表中：
除了以上提到的幾點外，還有其他一些重要的考慮因素：
- 如今， Verkle 樹代碼已經相當成熟。除了 Verkle 之外，使用其他任何程式碼都會延遲部署，很可能會推遲到一個硬分叉。這也沒有關係，尤其當如果我們需要額外的時間來進行雜湊函數分析或驗證者的實現，並且還有其他重要的功能想要更早納入以太坊。
- 使用雜湊值更新狀態根比使用 Verkle 樹更快。這意味著基於雜湊值的方法可以降低全節點的同步時間。
- Verkle 樹具有有趣的見證更新屬性-Verkle 樹見證是可更新的。這個屬性對記憶體池、包含清單和其他用例都很有用，而且還有可能有助於提高實現效率：如果更新了狀態對象，就可以更新倒數第二層的見證，而無需讀取最後一層的內容。
- Verkle 樹更難進行 SNARK 證明。如果我們想把證明大小一直減小到幾千字節，Verkle 證明就會帶來一些困難。這是因為 Verkle 證明的驗證引入了大量 256 位元操作，這要求證明系統要么有大量開銷，要么本身有一個包含 256 位元的 Verkle 證明的客製化內部結構。這對無狀態本身不是問題，但會在後續帶來更多困難。
如果我們想要以量子安全且合理高效的方式獲得 Verkle 見證的可更新性，另一個可能的途徑是基於點陣的梅克爾樹。
如果證明系統最終在最壞情況下不夠高效，我們還可以用多維 gas 來彌補這種不足：(i) calldata、(ii) 計算、(iii) 狀態存取以及可能的其他不同資源設定不同的 gas 限制。多維 gas 增加了複雜性，但作為交換，它更嚴格地限制了平均情況與最壞情況之間的比例。有了多維 gas ，理論上需要證明的最大分支數可能會從 30,000,000 / 2400 = 12,500 減少到例如 3000。這樣，即使在今天，BLAKE3 也可以（勉強）滿足要求，而無需進一步改進證明器。
另一個「靈機一動」的提議是將狀態根計算延遲到區塊之後的時隙。這樣，我們就有整整 12 秒的時間來計算狀態根，這意味著即使在最極端的情況下，每秒也有約 60,000 次哈希，證明時間是足夠的，這再次處於 BLAKE3 勉強夠用的範圍。
這種方法的缺點是會增加輕客戶端的延遲一個時隙，不過也有更巧妙的技術，可以將這種延遲減少到僅為證明產生延遲。例如，證明可以在任何節點生成後立即在網路上廣播，而不是等待下一個區塊。
它與路線圖的其他部分如何互動？
解決了無狀態問題之後，就能大幅提升單獨質押（solo staking）的便利性。如果有技術能降低單獨質押的最低平衡，如 Orbit SSF 或小組質押（squad staking）等應用層策略，這將變得更有價值。
如果同時引進 EOF，多維 gas 就會變得更方便。這是因為多維 gas 執行的主要複雜性在於處理不傳遞父調用全部 gas 的子調用，而 EOF 只需將此類子調用設為非法，就能使這一問題變得微不足道（並且本機帳戶抽象將為當前部分 gas 子呼叫的主要用例提供協定內替代方案）。
另一個重要的協同作用是無狀態驗證與歷史過期之間的關係。如今，客戶端必須儲存近 1TB 的歷史資料；這些資料比狀態大幾倍。即使客戶端是無狀態的，除非我們能解除客戶端儲存歷史資料的責任，否則近乎無儲存的客戶端的夢想將無法實現。這方面的第一步是 EIP-4444，它也意味著以 torrent 或 Portal 網路的形式儲存歷史資料。
EVM 執行的有效性證明
我們要解決什麼問題？
以太坊區塊驗證的長期目標很明確：你應該能夠透過以下方式驗證以太坊區塊：(i) 下載區塊，或甚至只下載區塊中資料可用性採樣的一小部分；(ii) 驗證區塊有效的一個小證明。這將是一個資源佔用極低的操作，可以在行動用戶端、瀏覽器錢包，甚至（沒有數據可用性部分）在另一條鏈上完成。
實現這一目標需要對（i）共識層（即權益證明）和（ii）執行層（即 EVM）進行 SNARK 或 STARK 證明。前者本身就是一個挑戰，應該在進一步不斷改進共識層（如最終確定性）的過程中加以解決。後者需要 EVM 執行證明。
EVM 執行的有效性證明是什麼，它是如何運作的？
從形式上看，在以太坊規範中，EVM 被定義為狀態轉換函數：你有一個前狀態 S、一個區塊 B，你正在計算一個後狀態 S' = STF(S，B)。如果用戶使用的是輕客戶端，他們並不完整地擁有 S 和 S'，甚至也不擁有 B；相反，他們擁有一個前狀態根 R、一個後狀態根 R' 和一個區塊哈希值 H ，需要證明的完整聲明大致如下：
- 公共輸入：前狀態根 R、後狀態根 R'、區塊雜湊 H
- 私人輸入：區塊主體 B、區塊存取的狀態中的物件 Q、執行區塊後的相同物件 Q'、狀態證明（如梅克爾分支）P
- 聲明 1 ：P 是一個有效證明，表示 Q 包含由 R 表示的狀態的某些部分。
- 聲明 2 ：如果你對 Q 執行 STF，（i）執行僅訪問 Q 內部的對象，（ii）區塊是有效的，且（iii）結果是 Q'。
- 聲明 3 ：如果利用 Q'和 P 的資訊重新計算新的狀態根，就會得到 R'
如果存在這種情況，您就可以擁有一個完全驗證以太坊 EVM 執行的輕型客戶端。這使得客戶端在資源使用上相對低效。要實現真正完全驗證的以太坊客戶端，還需要在共識方面做同樣的工作。
目前，針對 EVM 計算的有效性證明的實現已經存在，並且被二層網路廣泛使用。然而，要讓 EVM 有效性證明在 L1 上可行，仍需要做很多工作。
與現有研究有哪些關聯？
EF PSE ZK-EVM（現在停用，因為有更好的選擇）：
Zeth，其工作原理是將 EVM 編譯到 RISC-0 ZK-VM 中：https://github.com/risc0/zeth
ZK-EVM 形式化驗證專案：
還有什麼要做，需要權衡什麼？
目前，EVM 的有效性證明在兩個維度上是不足的：安全性和驗證時間。
一個安全的有效性證明涉及確保 SNARK 實際上驗證了 EVM 的計算，並且不存在漏洞。提高安全性的兩種主要技術是多驗證者和形式化驗證。多驗證者意味著有多個獨立編寫的有效性證明實現，類似於存在多個客戶端，如果一個區塊被這些實現的足夠大的子集證明，客戶端就會接受該區塊。形式驗證涉及使用通常用於證明數學定理的工具，如 Lean4，來證明有效性證明只接受正確執行底層 EVM 規範（如 EVM K 語義或用 python 編寫的以太坊執行層規範 (EELS)）的輸入。
足夠快的驗證時間意味著任何以太坊區塊都能在大約 4 秒內得到驗證。如今，我們距離這個目標仍然很遠，儘管我們比兩年前想像的要接近得多。為了實現這個目標，我們需要在三個方向上進行推進：
並行化- 目前最快的 EVM 驗證者可以在約 15 秒內證明一個普通 的以太坊區塊。它透過在數百個 GPU 之間進行並行化，在最後將它們的工作聚合在一起實現的。從理論上講，我們完全知道如何製造一個能在 O(log(N)) 時間內證明計算的 EVM 驗證者：讓一個 GPU 執行每一個不知，然後建立一個「聚合樹」：
在實現這一點上存在挑戰。為了在最壞情況下有效工作，即使一個非常大的交易佔用整個區塊，計算也不能按每個交易（per-tx）進行拆分；它必須按操作碼（per-opcode）進行（無論是 EVM 的操作碼還是底層虛擬機器如 RISC-V 的操作碼）。要確保虛擬機器的「記憶體」在證明的不同部分之間保持一致，是實現過程中的關鍵挑戰。不過，如果我們能夠進行這種遞歸證明，那麼我們就知道，即使在其他方面沒有任何改進，至少證明器的延遲問題已經解決了。
- 證明系統最佳化－像新的證明系統，如 Orion、Binius、GKR 等，很可能會再次大幅縮短通用運算的證明器時間。
- EVM gas 成本的其他變化—— EVM 中的許多東西都可以優化，使其更有利於證明者，尤其是在最壞的情況下。如果攻擊者可以建立一個阻塞證明者十分鐘時間的區塊，那麼僅能在 4 秒內證明一個普通的以太坊區塊是不夠的。所需的 EVM 變更可大致分為兩類：
- gas 成本的變化－如果一個操作需要很長時間才能證明，那麼即使它的計算速度相對較快，也應該有很高的 gas 成本。 EIP-7667 是為處理這方面糟糕問題而提出的一個 EIP：它大大增加了作為相對便宜的操作碼和預編譯的（傳統）雜湊函數的 gas 成本。為了彌補這些 gas 成本的增加，我們可以降低證明成本相對較低的 EVM 操作碼的 gas 成本，從而保持平均吞吐量不變。
- 資料結構替換－除了用對 STARK 更友善的方法替換狀態樹外，我們還需要替換交易清單、收據樹和其他證明成本高昂的結構。 Etan Kissling 提出的將交易和收據結構移至 SSZ 的 EIP（[1] [2] [3]）就是朝著這個方向邁出的一步。
除此之外，上一節提到的兩種更優的解決方案（多維 gas 和延遲狀態根）也能在這方面提供幫助。值得注意的是，與無狀態驗證不同的是，在無狀態驗證中，無論使用哪種更優的技術，都意味著我們已經擁有足夠的技術來完成我們當前所需的工作，而即使採用這些技術，完整的 ZK-EVM 驗證也需要更多的工作——只是需要的工作更少。
上文沒有提到的一點是證明器硬體：使用 GPU、FPGA 和 ASIC 更快產生證明。 Fabric Cryptography、Cysic 和 Accseal 這三家公司在這方面走在了前沿。這對 Layer 2 來說極具價值，但不太可能成為 Layer 1 的決定性考慮因素，因為人們強烈希望 Layer 1 保持高度去中心化，這意味著證明的生成必須在以太坊用戶能力的合理範圍內，而不應受到單一公司硬體的瓶頸限制。 Layer 2 可以做出更積極的權衡。
在這些領域中，還有更多的工作要做：
- 並行化證明要求證明系統的不同部分可以「共享記憶體」（如查找表）。我們知道這樣做的技術，但需要將其付諸實施。
- 我們需要進行更多的分析，以找出理想的 gas 成本變化集，從而最大限度地減少在最壞情況下的驗證時間。
- 我們需要在證明系統方面進行更多工作。
這裡可能需要權衡的因素包括：
安全性與驗證時間：如果選擇更激進的雜湊函數、更複雜的證明系統或更激進的安全假設或其他設計方案，就有可能縮短驗證時間。
去中心化與證明者時間：社區需要就證明者硬體的「規格」達成一致。是否可以要求證明者是大規模實體？我們希望高階消費級筆記型電腦能在 4 秒內證明一個以太坊區塊嗎？介於兩者之間的情況呢？
打破向後相容性的程度：其他方面的不足可以透過更積極的 gas 成本變化來彌補，但這更有可能不成比例地增加某些應用程式的成本，迫使開發人員重寫和重新部署程式碼，以保持經濟可行性。同樣，這兩種更優的解決方案也有其自身的複雜性和弊端。
它與路線圖的其他部分如何互動？
實現 Layer 1 網路 EVM 有效性證明所需的核心技術在很大程度上與其他兩個領域共享：
- Layer 2 的有效性證明（即"ZK Rollup"）
- “STARK 二進位雜湊證明” 方法以實現無狀態性
成功實現 Layer 1 的有效性證明將使簡單的單點質押變得極其容易：即使是最弱的電腦（包括手機或智慧手錶）也能進行質押。這進一步提高了解決單點質押的其他限制（如 32 ETH 最低限額）。
此外，Layer 1 的 EVM 有效性證明可使 Layer 1 gas 限值大幅提高。
共識的有效性證明
我們要解決什麼問題？
如果我們想用 SNARK 完全驗證一個以太坊區塊，那麼 EVM 的執行並不是我們唯一需要證明的部分。我們還需要證明──共識：系統中處理存款、提款、簽名、驗證者餘額更新的部分，以及以太坊權益證明部分的其他元素。
共識比 EVM 簡單得多，但它面臨的挑戰是，我們沒有 Layer 2 EVM Rollup，無論如何大部分工作都必須完成。因此，任何證明以太坊共識的實現都需要 “從頭開始”，儘管證明系統本身是可以在其基礎上建立的共享工作。
共識的有效性證明是什麼，它是如何運作的？
信標鏈被定義為一個狀態轉換函數，就像 EVM 一樣。狀態轉換函數主要由三個部分組成：
- ECADD（用於驗證 BLS 簽章）
- 配對（用於驗證 BLS 簽章）
- SHA256 雜湊（用於讀取和更新狀態）
在每個區塊中，我們都需要為每個驗證者證明 1-16 個 BLS 12-381 ECADD （可能不只一個，因為簽名可能包含在多個集合中）。這可以透過子集預計算技術來彌補，因此我們可以說每個驗證者只需證明一個 BLS 12-381 ECADD。目前，每個時隙有大約 30,000 個驗證者簽署。未來，隨著最終確定性的實現，這種情況可能會向兩個方向發生變化（參見此處的闡述）：如果我們採取「暴力破解」路線，每個時隙的驗證者數量可能會增加到 100 萬。同時，如果採用 Orbit SSF，則會維持在 32,768 個，甚至減少到 8,192 個。
就配對而言，目前每個時隙最多有 128 個驗證，這意味著需要驗證 128 個配對。隨著 EIP-7549 的推出和進一步修改，每個時隙的驗證次數有可能減少到 16 次。配對的數量很少，但成本極高：每個配對的運行（或證明）時間比 ECADD 長數千倍。
證明 BLS12-381 操作的一個主要挑戰是沒有一個方便的曲線，其曲線階等於 BLS12-381 的欄位大小，這給任何證明系統都增加了大量的開銷。另一方面，為以太坊提出的 Verkle 樹是用 Bandersnatch 曲線建構的，這使得 BLS12-381 本身成為 SNARK 系統中用來證明 Verkle 分支的自然曲線。一個比較簡單的實現每秒可以證明大約 100 次 G1 附加價值；要使證明速度足夠快，肯定需要像 GKR 這樣巧妙的技術。
對於 SHA256 雜湊來說，目前最糟糕的情況是紀元（epoch）轉換區塊，整個驗證者短餘額樹（short-balance tree）和大量驗證者的餘額都會被更新。每個驗證者的短餘額樹只有 1 個位元組，因此約有 1 MB 的資料會被重新雜湊。這相當於 32,768 次 SHA256 呼叫。如果有一千個驗證者的餘額高於或低於一個閾值，需要更新驗證者記錄中的有效餘額，這相當於一千個默克爾分支，因此可能需要一萬次哈希。洗牌機制（shuffling mechanism）需要每個驗證者 90 位元（因此需要 11 MB 的資料），但這可以在一個紀元的任何時間計算。在最終確定性的情況下，這些數字可能會根據具體情況而增減。洗牌（Shuffling）變得不必要，儘管 Orbit 可能會重新帶來某種程度的洗牌需求。
另一個挑戰是需要讀取──所有驗證者的狀態，包括公鑰，才能驗證一個區塊。針對 100 萬個驗證者，光是讀取公鑰就需要 4800 萬字節，再加上 Merkle 分支。這就需要每個紀元讀取數百萬個雜湊值。如果我們今天必須證明權益證明的有效性，現實的方法應該是某種形式的增量可驗證計算：在證明系統內存儲一個單獨的數據結構，該結構經過優化，可以高效查找，並證明對該結構的更新。
總之，有很多挑戰。
最有效地解決這些挑戰可能需要對信標鏈進行深入的重新設計，這可以與切換到最終確定性同時進行。這種重新設計的特點可能包括
雜湊函數的變化：現在使用的是「完整」的 SHA256 雜湊函數，因此由於填充的原因，每次呼叫都要對應兩次底層壓縮函數呼叫。如果改用 SHA256 壓縮函數，我們至少可以獲得 2 倍的收益。如果改用 Poseidon，我們就有可能獲得約 100 倍的收益，從而徹底解決我們的所有問題（至少在哈希方面）：以每秒 170 萬次哈希（54 MB）的速度，即使是一百萬筆驗證記錄也能在幾秒鐘內「讀取」到證明中。
如果使用 Orbit，則直接儲存洗牌後的驗證記錄：如果選擇一定數量的驗證者（如 8192 或 32768）作為給定時隙的委員會，將它們直接放入彼此旁邊的狀態中，以便最小化讀取所有驗證者公鑰到證明中時所需的哈希量。這樣還能有效率地完成所有的餘額更新。
簽章聚合：任何高效能簽章聚合方案都會涉及某種遞歸證明，網路中的不同節點都會對簽章子集進行中間證明。這自然而然地將證明工作分擔給了網路中的多個節點，從而大大減少了「最終證明者」的工作量。
其他簽章方案：對於 Lamport + Merkle 簽名，我們需要 256 + 32 個雜湊值來驗證簽章；乘以 32,768 個簽章者，得到 9,437,184 個雜湊值。對簽章方案進行最佳化後，可以將雜湊值進一步提高一個小的常數因子。如果我們使用波塞冬（Poseidon），在單一時隙內就能證明這一點。但實際上，使用遞歸聚合方案會更快。
與現有研究有哪些關聯？
簡潔的以太坊共識證明（僅限同步委員會）：
https://github.com/succinctlabs/eth-proof-of-consensus
SP1 內簡潔的 Helios：
https://github.com/succinctlabs/sp1-helios
簡潔的 BLS12-381 預編譯：
https://blog.succinct.xyz/succinctshipsprecompiles/
基於 Halo2 的 BLS 集合簽章驗證：
https://ethresear.ch/t/zkpos-with-halo2-pairing-for-verifying-aggregate-bls-signatures/14671
還有什麼要做，需要權衡什麼？
實際上，我們需要數年時間才能獲得以太坊共識的有效性證明。這與我們實現最終確定性、Orbit、修改簽名演算法以及安全分析所需的時間大致相同，而安全分析需要足夠的信心才能使用像波塞冬（Poseidon）這樣「激進」的哈希函數。因此，最合理的做法是解決這些其他問題的同時，考慮到 STARK 的友善性。
主要的權衡可能在於操作順序之間的選擇，即是採取漸進式方法改革以太坊共識層，還是採用更激進的「多項變更同時進行」的方法。對於 EVM 來說，漸進式方法是合理的，因為它可以最大限度地減少對向後相容性的干擾。而對於共識層來說，向後相容性的影響較少，採取更全面的重新思考，可能有助於在建立信任證明友善的信標鏈時優化各種細節。
它與路線圖的其他部分如何互動？
在對以太坊權益證明共識進行長期重新設計時，STARK 友善性必須成為首要考慮因素，尤其是在最終確定性、Orbit、簽名方案的更改和簽名聚合的設計中。
免責聲明：作為區塊鏈資訊平台，本站所發布文章僅代表作者及來賓個人觀點，與 Web3Caff 立場無關。文章內的資訊僅供參考，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。
