Vitalik關(guān)于以太坊可能的未來（四）：The Verge

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

原文作者：Vitalik Buterin

原文編譯：Mensh，ChainCatcher

前文閱讀：《Vitalik 關(guān)于以太坊可能的未來（一）：The Merge》、《Vitalik 關(guān)于以太坊可能的未來（二）：The Surge》、《Vitalik 關(guān)于以太坊可能的未來（三）：The Scourge》

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

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

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

The Verge 2023 路線圖

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

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

The Verge：關(guān)鍵目標

· 無狀態(tài)客戶機：完全驗證客戶機和標記節(jié)點所需的存儲空間不應(yīng)超過幾 GB。

· (長期）在智能手表上完全驗證鏈（共識和執(zhí)行）。下載一些數(shù)據(jù)，驗證 SNARK，完成。

在本章中

· 無狀態(tài)客戶機：Verkle 還是 STARKs

· EVM 執(zhí)行的有效性證明

· 共識的有效性證明

無狀態(tài)驗證：Verkle 還是 STARKs

我們要解決什么問題？

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

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

它如何工作？

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

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

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

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

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

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

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

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

Verkle 樹

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

因此，證明中單個分支的大小變?yōu)?32 - 1og256(N) = ?4* log2(N) 字節(jié)。因此，理論上的最大證明大小大致為 30000000 / 2400 *32* (32 -14 + 8) / 8 = 130000 字節(jié)（由于狀態(tài)塊的分布不均勻，實際計算結(jié)果略有不同，但作為第一近似值是可以的）。

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

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

STARKed 二進制哈希樹

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

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

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

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

2. 使用更 "保守 "的哈希函數(shù)，如 SHA256 或 BLAKE

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

除驗證區(qū)塊外的見證使用案例

除了驗證區(qū)塊外，還有其他三個關(guān)鍵用例需要更高效的無狀態(tài)驗證：

· 內(nèi)存池：當交易被廣播時，P2P 網(wǎng)絡(luò)中的節(jié)點需要在重新廣播之前驗證交易是否有效。如今驗證包括驗證簽名，還包括檢查余額是否充足和前綴是否正確。在未來（例如，使用原生賬戶抽象，如 EIP-7701，這可能會涉及運行一些 EVM 代碼，這些代碼會進行一些狀態(tài)訪問。如果節(jié)點是無狀態(tài)的，則交易需要附帶證明狀態(tài)對象的證明。

· 包含列表：這是一個提議的功能，允許（可能規(guī)模較小且不復(fù)雜的）權(quán)益證明驗證者強制下一個區(qū)塊包含交易，而不管（可能規(guī)模較大且復(fù)雜的）區(qū)塊構(gòu)建者的意愿。這將削弱有權(quán)勢者通過延遲交易來操縱區(qū)塊鏈的能力。不過，這需要驗證者有辦法驗證包含列表中交易的有效性。

· 輕客戶端：如果我們希望用戶通過錢包訪問鏈（如 Metamask、Rainbow、Rabby 等），要做到這一點，他們需要運行輕型客戶端（如 Helios).Helios 核心模塊為用戶提供經(jīng)過驗證的狀態(tài)根。而為了獲得完全無信任的體驗，用戶需要為他們所做的每個 RPC ?調(diào)用提供證明（例如，對于以太網(wǎng)調(diào)用請求（用戶需要證明在調(diào)用過程中訪問的所有狀態(tài)）。

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

與現(xiàn)有研究有哪些聯(lián)系：

· Verkle trees

· John Kuszmaul 關(guān)于 Verkle tree 的原始論文

· Starkware

· Poseidon2 paper

· Ajtai (基于晶格硬度的替代快速哈希函數(shù))

· Verkle.info

還能做些什么？

剩下的主要工作是

1. 關(guān)于 EIP-4762 后果的更多分析（無狀態(tài) gas 成本變化）

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

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

4. 為 "保守"（或 "傳統(tǒng)"）哈希進一步開發(fā)超高效 STARK 協(xié)議功能，例如基于 Binius 或 GKR 的觀點。

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

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

· 如今，Verkle 樹代碼已經(jīng)相當成熟。除了 Verkle 之外，使用其他任何代碼都會推遲部署，很可能會推遲一個硬分叉。這也沒有關(guān)系，尤其是如果我們需要額外的時間來進行哈希函數(shù)分析或驗證器實現(xiàn)，或者我們有其他重要的功能想要更早地納入以太坊。

· 使用哈希值更新狀態(tài)根比使用 Verkle 樹更快。這意味著基于哈希值的方法可以降低全節(jié)點的同步時間。

· Verkle 樹具有有趣的見證更新屬性——Verkle 樹見證是可更新的。這個屬性對 mempool、包含列表和其他用例都很有用，而且還可能有助于提高實現(xiàn)效率：如果更新了狀態(tài)對象，就可以更新倒數(shù)第二層的見證，而無需讀取最后一層的內(nèi)容。

· Verkle 樹更難進行 SNARK 證明。如果我們想把證明大小一直減小到幾千字節(jié)，Verkle 證明就會帶來一些困難。這是因為 Verkle 證明的驗證引入了大量 256 位操作，這就要求證明系統(tǒng)要么有大量開銷，要么本身有一個定制的內(nèi)部結(jié)構(gòu)，其中包含 256 位的 Verkle 證明部分。這對無狀態(tài)本身不是問題，但會帶來更多困難。

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

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

多維 gas 允許區(qū)塊的資源限制更接近于底層硬件的資源限制

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

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

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

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

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

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

EVM 執(zhí)行的有效性證明

我們要解決什么問題？

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

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

它是什么，如何運作？

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

· 公共輸入：前狀態(tài)根 R, 后狀態(tài)根 R' , 塊哈希 H

· 私人輸入：程序塊主體 B、程序塊 Q 訪問的狀態(tài)中的對象、執(zhí)行程序塊 Q'后的相同對象、狀態(tài)證明（如 Merkle 分支）P

· 主張 1：P 是一個有效的證明，證明 Q 包含 R 所代表的狀態(tài)的某些部分

· 主張 2：如果在 Q 上運行 STF，(i) 執(zhí)行過程只訪問 Q 內(nèi)部的對象，(ii) 數(shù)據(jù)塊是有效的，(iii) 結(jié)果是 Q'

· 主張 3：如果利用 Q' 和 P 的信息重新計算新的狀態(tài)根，就會得到 R'

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

用于 EVM 計算的有效性證明的實現(xiàn)已經(jīng)存在，并被 L2 大量使用。而要使 EVM 有效性證明在 L1 中可行，還有很多工作要做。

與現(xiàn)有研究有哪些聯(lián)系？

· EFPSE ZK-EVM（由于存在更好的選擇，現(xiàn)已停用）

· Zeth，其工作原理是將 EVM 編譯到 RISC-0 ZK-VM 中

· ZK-EVM 形式化驗證項目

還能做些什么？

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

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

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

· 并行化——目前最快的 EVM 校驗器平均可在 15 秒內(nèi)證明一個以太坊區(qū)塊。它是通過在數(shù)百個 GPU 之間進行并行化，后在最后將它們的工作匯總在一起來實現(xiàn)這一點的。從理論上講，我們完全知道如何制造一個能在 O(log(N)) 時間內(nèi)證明計算的 EVM 驗證器：讓一個 GPU 完成每一步，后做一個「聚合樹」：

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

· 證明系統(tǒng)優(yōu)化--新的證明系統(tǒng)，如 Orion、Binius、GRK 以及其他更多信息，很可能會導致又一次大大縮短了通用計算的驗證時間。

· EVM gas 成本的其他變化——EVM 中的許多東西都可以優(yōu)化，使其更有利于證明者，尤其是在最壞的情況下。如果攻擊者可以構(gòu)建一個阻塞證明者十分鐘時間的區(qū)塊，那么僅能在 4 秒內(nèi)證明一個普通的以太坊區(qū)塊是不夠的。所需的 EVM 更改可大致分為以下幾類：

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

- 數(shù)據(jù)結(jié)構(gòu)替換——除了用對 STARK 更友好的方法替換狀態(tài)樹外，我們還需要替換事務(wù)列表、收據(jù)樹和其他證明成本高昂的結(jié)構(gòu)。Etan Kissling 將事務(wù)和收據(jù)結(jié)構(gòu)移至 SSZ 的 EIP 就是朝著這個方向邁出的一步。

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

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

在這些領(lǐng)域中，還有更多的工作要做：

· 并行化證明要求證明系統(tǒng)的不同部分可以 "共享內(nèi)存"（如查找表）。我們知道這樣做的技術(shù)，但需要加以實現(xiàn)。

· 我們需要進行更多的分析，以找出理想的 gas 成本變化集，從而最大限度地減少最壞情況下的驗證時間。

· 我們需要在證明系統(tǒng)方面做更多的工作

可能的代價是：

· 安全性與驗證器時間：如果選擇更激進的哈希函數(shù)、更復(fù)雜的證明系統(tǒng)或更激進的安全假設(shè)或其他設(shè)計方案，就有可能縮短驗證器時間。

· 去中心化與證明器時間：社區(qū)需要就所針對的證明器硬件的「規(guī)格」達成一致。要求證明者是大規(guī)模實體可以嗎？我們希望高端消費筆記本電腦能在 4 秒內(nèi)證明一個以太坊區(qū)塊嗎？介于兩者之間？

· 打破向后兼容性的程度：其他方面的不足可以通過更積極的 gas 成本變化來彌補，但這更有可能不成比例地增加某些應(yīng)用程序的成本，迫使開發(fā)人員重寫和重新部署代碼，以保持經(jīng)濟可行性。同樣，這兩個工具也有其自身的復(fù)雜性和弊端。

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

實現(xiàn) L1 EVM 有效性證明所需的核心技術(shù)在很大程度上與其他兩個領(lǐng)域共享：

· L2 的有效性證明（即「ZK rollup」）

· 無狀態(tài)的「STARK 二進制哈希證明」方法

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

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

共識的有效性證明

我們要解決什么問題？

如果我們想用 SNARK 完全驗證一個以太坊區(qū)塊，那么 EVM 的執(zhí)行并不是我們需要證明的唯一部分。我們還需要證明共識，即系統(tǒng)中處理存款、取款、簽名、驗證器余額更新以及以太坊權(quán)益證明部分其他元素的部分。

共識比 EVM 簡單得多，但它面臨的挑戰(zhàn)是，我們沒有 L2 EVM 卷積，因此無論如何，大部分工作都要完成。因此，任何證明以太坊共識的實現(xiàn)都需要「從頭開始」，盡管證明系統(tǒng)本身是可以在其基礎(chǔ)上構(gòu)建的共享工作。

它是什么，如何工作？

信標鏈被定義為狀態(tài)轉(zhuǎn)換函數(shù), 就像 EVM 一樣。狀態(tài)轉(zhuǎn)換函數(shù)主要由三部分組成：

· ECADD（用于驗證 BLS 簽名）

· 配對（用于驗證 BLS 簽名）

· SHA256 哈希值（用于讀取和更新狀態(tài)）

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

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

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

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

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

另一個挑戰(zhàn)是需要重新獲取所有驗證器狀態(tài)，包括公鑰，才能驗證一個區(qū)塊。對于 100 萬個驗證器來說，僅讀取公鑰就需要 4800 萬字節(jié)，再加上 Merkle 分支。這就需要每個紀元數(shù)以百萬計的哈希值。如果我們必須證明 PoS 的有效性，一種現(xiàn)實的方法是某種形式的增量可驗證計算：在證明系統(tǒng)內(nèi)存儲一個單獨的數(shù)據(jù)結(jié)構(gòu)，該數(shù)據(jù)結(jié)構(gòu)經(jīng)過優(yōu)化，可以高效查找，并證明對該結(jié)構(gòu)的更新。

總之，挑戰(zhàn)很多。要最有效地應(yīng)對這些挑戰(zhàn)，很可能需要對信標鏈進行深入的重新設(shè)計，而這可能與轉(zhuǎn)向單槽終結(jié)同時進行。這種重新設(shè)計的特點可能包括：

· 哈希函數(shù)的變化：現(xiàn)在使用的是 "完整 "的 SHA256 哈希函數(shù)，因此由于填充的原因，每次調(diào)用都要對應(yīng)兩次底層壓縮函數(shù)調(diào)用。如果改用 SHA256 壓縮函數(shù)，我們至少可以獲得 2 倍的收益。如果改用 Poseidon，我們可能會獲得 100 倍的增益，從而徹底解決我們的所有問題（至少在哈希值方面）：在每秒 170 萬哈希值（54MB），即使是一百萬條驗證記錄也能在幾秒鐘內(nèi)「讀取」到證明中。

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

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

· 其他簽名方案：對于 Lamport+ Merkle 簽名，我們需要 256 + 32 個哈希值來驗證簽名；乘以 32768 個簽名者，就得到 9437184 個哈希值。對簽名方案進行優(yōu)化后，可以通過一個很小的常數(shù)因子進一步改善這一結(jié)果。如果我們使用 Poseidon，這在單個插槽內(nèi)就能證明。但實際上，使用遞歸聚合方案會更快。

與現(xiàn)有研究有哪些聯(lián)系？

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

· 簡潔 SP1 內(nèi)的 Helios

· 簡明 BLS12-381 預(yù)編譯

· 基于 Halo2 的 BLS 集合簽名驗證

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

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

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

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

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

原文鏈接

歡迎加入律動 BlockBeats 官方社群：

Telegram 訂閱群：https://t.me/theblockbeats

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

Twitter 官方賬號：https://twitter.com/BlockBeatsAsia