The Verge:讓以太坊可驗證和可持續

進階12/23/2024, 11:49:20 AM
本文探討了《The Verge》,旨在通過 Verkle 樹、STARK 證明、zk 友好的共識機制、Beam 鏈等技術,提升以太坊的可驗證性、可擴展性和可持續性。

可驗證性的路徑

Web3 的核心優勢是可驗證性——用戶可以驗證系統的實際運行方式。這一特性解釋了為什麼許多人在加密行業內外都將 Web3 視為邁向更加透明和可驗證互聯網的一步。

與 Web2 平臺(如 Facebook 或 Instagram)不同,後者的算法和規則即使經過記錄,也依然保持不透明;而加密協議則設計為具備完全的可審計性。即便它們被分享,用戶也缺乏驗證平臺是否按預期運行的能力。這與加密完全相反,加密協議的每一項設計都儘可能確保可審計——至少在理論上是如此。

今天,我們將探討《The Verge》這一部分內容,分析以太坊在實現未來可驗證性、可持續性和可擴展性方面所採取的步驟。本文將討論如何通過區塊鏈架構使其更加可驗證,這些變化在協議層面帶來了哪些創新,以及它們如何為用戶提供更加安全的生態系統。讓我們開始吧!

什麼是“可驗證性”?

Web2 應用通常作為“黑箱”運作——用戶只能看到輸入和輸出,而無法瞭解應用如何實際運作。相比之下,加密貨幣協議通常會公開其源代碼,或者至少有計劃這樣做。這種透明性有兩個目的:首先,它允許用戶在選擇時直接與協議的代碼進行互動;其次,它幫助用戶準確理解系統如何運作以及哪些規則在其中發揮作用。

“去中心化你能去的部分,其餘部分確保可驗證。”

可驗證性確保系統能夠承擔責任,並且在許多情況下,保證協議按預期運行。這個原則強調最小化中心化的重要性,因為中心化往往導致不透明和無法追責的結構,用戶無法驗證操作的真實性。相反,我們應當儘可能地實現去中心化,而對於無法去中心化的部分,則應確保其可驗證且可追責。

以太坊社區似乎與這種觀點一致,因為其路線圖中包含了一個名為“Verge”的里程碑,旨在讓以太坊變得更加可驗證。然而,在深入探討《The Verge》之前,我們需要了解區塊鏈的哪些方面應該被驗證,以及從用戶的角度來看,哪些部分是至關重要的。

區塊鏈本質上充當了全球時鐘的角色。在一個由大約 10,000 臺計算機組成的分佈式網絡中,交易從源節點傳播到所有其他節點可能需要相當長的時間。因此,網絡中的節點無法確定交易的確切順序——即無法判斷某筆交易是先到達還是後到達,因為它們只能從自身的主觀視角進行觀察。

由於交易順序非常重要,區塊鏈網絡使用稱為“共識算法”的專門方法,確保節點保持同步並按照相同的順序處理交易序列。儘管節點無法在全球範圍內確定交易的順序,但共識機制使得所有節點能夠達成一致,確認相同的交易序列,從而使整個網絡像一個單一且協調的計算機一樣運作。

除了共識層之外,每個區塊鏈中還有一個執行層。執行層由用戶想要執行的交易所決定。 \
一旦交易通過共識成功排序,每筆交易就必須應用於執行層的當前狀態。如果你在想,“什麼是狀態?”那麼你可能已經看到區塊鏈被比作數據庫——或者更具體地說,是銀行的數據庫,因為區塊鏈與銀行一樣,會記錄每個人的賬戶餘額。

如果你在狀態“S”中有 $100,並且想要向其他人發送 $10,那麼在下一個狀態“S+1”中,你的餘額將變為 $90。這一過程,即通過應用交易從一個狀態過渡到另一個狀態的過程,我們稱之為 STF(狀態轉換函數)。

在比特幣中,STF 主要限於餘額變化,因此相對簡單。然而,與比特幣不同,Ethereum 的 STF 要複雜得多,因為以太坊是一個完全可編程的區塊鏈,具有執行層,能夠運行代碼。

在區塊鏈中,有三個基本組件是你需要或能夠驗證的:

  • 狀態:你可能想讀取區塊鏈上的某一數據,但由於你沒有運行完整節點,因此無法直接訪問該狀態。因此,你通過像 Alchemy 或 Infura 這樣的 RPC(遠程過程調用)提供者請求數據。然而,你必須驗證這些數據在 RPC 提供者處未被篡改。
  • 執行:如前所述,區塊鏈利用 STF。你必須驗證狀態轉換是否正確執行——這不是逐筆交易地驗證,而是逐塊地驗證。
  • 共識:像 RPC 這樣的第三方實體可以提供你尚未被包含在區塊鏈中的有效區塊。因此,你必須驗證這些區塊已經通過共識被接受,並且被添加到區塊鏈中。

如果這些內容聽起來令人困惑或不清楚,不用擔心,我們將詳細解釋每個方面。首先,讓我們從如何驗證區塊鏈狀態開始!

如何驗證區塊鏈狀態?

以太坊的“狀態”指的是區塊鏈在任何特定時間點存儲的數據集合。這些數據包括賬戶餘額(包括合約賬戶和外部擁有賬戶,簡稱 EOA)、智能合約代碼、合約存儲等。以太坊是一個基於狀態的機器,因為在以太坊虛擬機(EVM)中處理的每一筆交易都會改變先前的狀態,併產生一個新的狀態。

每個以太坊區塊都包含一個值,用於總結該區塊之後網絡的當前狀態,這個值稱為 stateRoot。這個值是對整個以太坊狀態的緊湊表示,通常是一個 64 字符的哈希值。

隨著每一筆新交易修改狀態,後續區塊中記錄的 stateRoot 會相應更新。為了計算這個值,以太坊的驗證者使用了 Keccak 哈希函數和一種稱為 Merkle Tree(默克爾樹)的數據結構來組織和總結狀態的不同部分。

哈希函數是單向函數,它將輸入轉化為固定長度的輸出。在以太坊中,像 Keccak 這樣的哈希函數被用來生成數據的摘要,充當輸入數據的指紋。哈希函數有四個基本特性:

確定性:相同的輸入總是會生成相同的輸出。

固定輸出長度:無論輸入的長度如何,輸出的長度總是固定的。

單向性:從輸出推導出原始輸入幾乎是不可能的。

唯一性:即使輸入發生微小變化,輸出也會完全不同。因此,特定的輸入會映射到一個幾乎唯一的輸出。

正因為這些特性,以太坊驗證者能夠執行每個區塊的 STF(狀態轉換函數)——執行區塊中的所有交易並將其應用到狀態中,然後驗證區塊中指示的狀態是否與通過 STF 得到的狀態匹配。這個過程確保了區塊提議者的誠實行為,使其成為驗證者的核心職責之一。

然而,以太坊驗證者並不會直接對整個狀態進行哈希操作來找到其摘要。由於哈希函數的單向特性,直接對狀態進行哈希會消除可驗證性,因為重現該哈希的唯一方法是擁有整個狀態。

由於以太坊的狀態數據量達到數 TB,因此將整個狀態存儲在手機或個人計算機等日常設備上是不切實際的。為了解決這個問題,以太坊使用 Merkle 樹 結構來計算 stateRoot,儘可能保留狀態的可驗證性。

Merkle 樹是一種加密數據結構,用於安全且高效地驗證數據的完整性和正確性。Merkle 樹基於哈希函數構建,將數據集的哈希值按照層級結構組織,從而使得能夠驗證數據的完整性和正確性。該樹結構由三種類型的節點組成:

  • 葉子節點:這些節點包含單個數據片段的哈希值,位於樹的最底層。每個葉子節點代表 Merkle 樹中某一特定數據片段的哈希值。
  • 分支節點:這些節點包含其子節點的組合哈希值。例如,在一個二叉 Merkle 樹中(N=2),兩個子節點的哈希值會被連接起來,再次進行哈希運算,生成一個分支節點的哈希值,位於更高的層級。
  • 根節點:根節點位於 Merkle 樹的最頂層,代表整個樹的加密摘要。這個節點用於驗證樹中所有數據的完整性和正確性。

如果你想知道如何構建這樣的樹,實際上它只需要兩個簡單的步驟:

  • 葉子節點創建:每個數據片段通過哈希函數進行處理,得到的哈希值形成葉子節點。這些節點位於樹的最底層,代表數據的加密摘要。

  • 葉子節點的哈希值會按一定方式(例如按對組)進行分組和合並,隨後進行哈希運算。這個過程會在樹的下一層生成分支節點。對於每個分支節點,重複相同的過程,直到只剩下一個哈希值。

最終,在樹頂端獲得的哈希值被稱為 Merkle 根。Merkle 根代表整個樹的加密摘要,並允許安全地驗證數據的完整性。

我們如何使用 Merkle 根來驗證以太坊的狀態?

Merkle 證明 使得驗證者能夠高效地驗證特定數據片段的有效性,通過提供一系列哈希值,形成從目標數據(即葉子節點)到區塊頭中存儲的 Merkle 根的路徑。這個中間哈希鏈使得驗證者能夠確認數據的真實性,而無需對整個狀態進行哈希計算。

驗證者從特定的數據點開始,將其與 Merkle 證明中提供的每個“兄弟”哈希值逐步合併,並進行哈希運算。這一過程會一直持續,直到產生一個單一的哈希值。如果計算出的哈希值與存儲的 Merkle 根匹配,則數據被視為有效;否則,驗證者可以確定該數據與所聲明的狀態不符。

示例:使用 Merkle 證明驗證數據點

假設我們從 RPC 接收到數據 #4,並希望使用 Merkle 證明驗證其真實性。為此,RPC 會提供一組哈希值,這些哈希值形成一條路徑,能夠達到 Merkle 根。對於數據 #4,兄弟哈希值將包括 Hash #3、Hash #12 和 Hash #5678。

  1. 從數據 4 開始:首先,我們對數據 #4 進行哈希,得到 Hash #4。
  2. 與兄弟節點合併:然後,我們將 Hash #4 與 Hash #3(它在葉子層級的兄弟節點)合併,並進行哈希運算,得到 Hash #34。
  3. 向上移動樹:接下來,我們將 Hash #34 與 Hash #12(它在下一層的兄弟節點)合併,並哈希得到 Hash #1234。
  4. 最後一步:最後,我們將 Hash #1234 與 Hash #5678(提供的最後一個兄弟哈希)合併,並進行哈希運算。結果哈希應該與存儲在區塊頭中的 Merkle 根(Hash #12345678)匹配。

如果計算出的 Merkle 根與區塊中的狀態根匹配,那麼我們確認數據 #4 在該狀態下是有效的。如果不匹配,則說明數據不屬於所聲明的狀態,表明可能存在篡改。正如你所看到的,驗證者無需提供所有數據的哈希值,也不需要從頭開始重建整個 Merkle 樹,僅通過提供三個哈希值,證明者就能證明數據 #4 在該狀態中存在且未被篡改。這就是為什麼 Merkle 證明被認為是高效的主要原因。

Merkle 樹的效率是否足夠高?

雖然 Merkle 樹無疑在像以太坊這樣的大型區塊鏈系統中提供了安全且高效的數據驗證,但它們是否真的足夠高效呢?為了回答這個問題,我們必須分析 Merkle 樹的性能和大小如何影響證明者與驗證者之間的關係。

影響 Merkle 樹性能的兩個關鍵因素 ⌛

  • 分支因子:每個分支節點的子節點數量。
  • 數據總大小:樹中表示的數據集的大小。

分支因子的影響

為了更好地理解分支因子的影響,我們來舉一個例子。分支因子決定了每個節點會從多少個分支延伸出去。

小的分支因子(例如,二叉 Merkle 樹)

如果使用的是二叉 Merkle 樹(分支因子為 2),那麼證明的大小非常小,使得驗證過程對驗證者來說更加高效。在每個節點只有兩個分支的情況下,驗證者只需要處理每一層的一個兄弟哈希。這加快了驗證速度,並減少了計算負擔。然而,較小的分支因子增加了樹的高度,在構建樹時需要更多的哈希操作,這對驗證者來說可能是一個負擔。

較大的分支因子(例如,4)

較大的分支因子(例如,4)降低了樹的高度,形成了一個更短、更寬的結構。由於需要的哈希操作較少,完整節點(Full Nodes)能夠更快地構建樹。然而,對於驗證者來說,這會增加他們在每一層需要處理的兄弟哈希數量,導致證明的大小變大。每次驗證步驟中需要更多的哈希值,也意味著驗證者的計算和帶寬成本更高,實際上將負擔從驗證者轉移到了驗證者身上。

總結來說,較大的分支因子通過降低樹的高度和構建時間來提高了驗證速度,但同時也增加了驗證時的工作量和資源消耗。因此,在設計 Merkle 樹時,需要平衡分支因子的大小,以實現驗證效率和構建效率之間的最佳折衷。

第二章:以太坊可驗證性革命——The Verge

The Verge 是以太坊路線圖中的一個里程碑,旨在提高可驗證性,強化區塊鏈的去中心化結構,並增強網絡安全性。以太坊網絡的一個主要目標是使任何人都能輕鬆運行驗證節點來驗證區塊鏈,創建一個沒有中心化的開放參與結構。這一驗證過程的可達性是區塊鏈區別於中心化系統的關鍵特徵之一。雖然中心化系統不提供驗證功能,但區塊鏈的正確性完全掌握在其用戶手中。然而,為了保持這一保證,運行一個驗證節點必須對所有人都能訪問——這是當前系統下的一個挑戰,因為驗證節點需要大量的存儲和計算資源。

自從通過 The Merge 轉向 權益證明(Proof-of-Stake,PoS) 共識模型以來,以太坊驗證者有兩個主要責任:

確保共識:支持概率性和確定性共識協議的正常運行,並應用分叉選擇算法。

檢查區塊準確性:在執行區塊中的交易後,驗證結果狀態樹的根是否與提議者聲明的狀態根匹配。

為了履行第二項責任,驗證者必須能夠訪問區塊之前的狀態。這使得他們能夠執行區塊中的交易,並推導出後續狀態。然而,這一要求給驗證者帶來了沉重的負擔,因為他們需要處理大量的存儲要求。雖然以太坊的設計目標是使其可行,並且全球存儲成本正在逐漸降低,但問題的關鍵不在於成本,而在於驗證者需要依賴專用硬件。The Verge 旨在通過創建一個基礎設施來克服這一挑戰,使得即使在存儲有限的設備上(如手機、瀏覽器錢包,甚至智能手錶)也能進行完整的驗證,允許驗證節點在這些設備上運行。

可驗證性的第一步:狀態

過渡到 Verkle 樹 是這個過程的關鍵部分。最初,The Verge 的重點是將以太坊的 Merkle 樹結構替換為 Verkle 樹。採用 Verkle 樹的主要原因是,Merkle 樹對以太坊可驗證性構成了重大障礙。雖然在正常情況下,Merkle 樹及其證明能夠高效地工作,但在最壞的情況下,它們的性能會急劇下降。

根據 Vitalik 的計算,平均證明大小約為 4 KB,這聽起來是可以管理的。然而,在最壞的情況下,證明的大小可能會膨脹到 330 MB。是的,你沒看錯——330 MB。

以太坊的 Merkle 樹在最壞情況下的極端低效,主要源於兩個原因:

  1. 使用十叉樹(Hexary Trees)

目前,以太坊使用的 Merkle 樹的分支因子是 16。這意味著,驗證一個單獨的節點時,需要提供該分支中的其他 15 個哈希。考慮到以太坊狀態的大小和分支數量,在最壞的情況下,這會造成相當大的負擔。

  1. 非 Merkle 化的代碼:以太坊並沒有將合約代碼納入樹結構,而是將代碼進行哈希處理,並使用生成的哈希值作為節點。考慮到合約的最大大小為 24 KB,這種方法在實現完全可驗證性時會帶來顯著的負擔。

證明大小與分支因子成正比。減少分支因子可以減小證明大小。為了解決這些問題並改善最壞情況下的表現,以太坊可以將十叉樹(Hexary Trees)轉換為二叉 Merkle 樹(Binary Merkle Trees),並開始將合約代碼進行 Merkle 化。如果以太坊的分支因子從 16 降到 2,並且將合約代碼也進行 Merkle 化,那麼最大證明大小可能縮小至 10 MB。雖然這是一個顯著的改進,但值得注意的是,這個成本僅適用於驗證單個數據。即便是一個簡單的交易,訪問多個數據項時,也需要更大的證明。考慮到每個區塊的交易數量以及以太坊狀態的持續增長,儘管這種方案更好,但仍然不完全可行。

因此,以太坊社區提出了兩種不同的解決方案來應對這一問題:

  1. Verkle 樹
  2. STARK 證明 + 二叉 Merkle 樹

Verkle 樹與向量承諾(Vector Commitments)

顧名思義,Verkle 樹 是類似於 Merkle 樹 的樹結構。然而,它們在驗證過程中的效率方面存在顯著差異。在 Merkle 樹 中,如果一個分支包含 16 個數據項,且我們只想驗證其中的一個數據項,則必須提供覆蓋其他 15 個數據項的哈希鏈。這大大增加了驗證的計算負擔,並導致了較大的證明大小。

相比之下,Verkle 樹 使用了一種名為“基於橢圓曲線的向量承諾(Elliptic Curve-based Vector Commitments)”的專門結構,具體來說,是 基於內積論證(IPA) 的向量承諾。向量本質上是按特定順序組織的數據元素列表。以太坊的狀態可以被視為一個向量:這是一個存儲著多個數據項並按特定順序排列的結構,其中每個元素都至關重要。該狀態包含了各種數據組件,例如地址、合約代碼和存儲信息,而這些元素的順序在訪問和驗證過程中起著至關重要的作用。

向量承諾是用於證明和驗證數據集內數據元素的密碼學方法。這些方法能夠同時驗證數據集內每個元素的存在性和順序。例如,Merkle Proofs(用於 Merkle 樹)也可以視為一種向量承諾形式。雖然 Merkle 樹需要驗證元素時提供所有相關的哈希鏈,但其結構本質上證明了向量中的所有元素是按特定順序相連接的。

與 Merkle 樹不同,Verkle 樹採用了基於橢圓曲線的向量承諾,這為其提供了兩個主要優勢:

基於橢圓曲線的向量承諾 消除了驗證數據時需要提供與被驗證數據無關的其他元素的細節。在 Merkle 樹 中,若採用 16 分支因子,驗證單一分支時需要提供其他 15 個哈希值。考慮到以太坊的狀態龐大且包含多個分支,這種做法會造成極大的低效性。而 基於橢圓曲線的向量承諾 則消除了這種複雜性,它允許通過較少的數據和計算工作量完成驗證。

通過 多重證明(multi-proofs),基於橢圓曲線的向量承諾所生成的證明可以被壓縮成一個恆定大小的證明。由於以太坊的狀態不僅龐大,而且持續增長,隨著時間的推移,需要驗證的分支數量也在增加。然而,使用 Verkle 樹 後,我們可以利用 Dankrad Feist 文章中詳細描述的方法,將每個分支的證明“壓縮”成一個單一的恆定大小的證明。這樣,驗證者只需要使用一個小的證明來驗證整個樹,而不必單獨驗證每一個分支。這也意味著,Verkle 樹不會受到以太坊狀態增長的影響。

基於橢圓曲線的向量承諾的這些特點大大減少了驗證所需的數據量,使 Verkle 樹即使在最壞的情況下也能產生小而恆定大小的證明,從而最小化了數據開銷和驗證時間,提高了像以太坊這樣的龐大網絡的效率。因此,Verkle 樹中的橢圓曲線向量承諾使得以太坊日益增長的狀態能夠更有效地管理和處理。

Verkle 樹的侷限性

然而,像所有創新一樣,Verkle 樹也有其侷限性。其中一個主要缺點是它依賴於 橢圓曲線加密,這使其面臨量子計算機的潛在威脅。量子計算機比經典計算方法擁有更強大的計算能力,這對橢圓曲線加密協議構成了顯著威脅。量子算法可能會打破或削弱這些加密系統,引發對 Verkle 樹長期安全性的擔憂。

因此,儘管 Verkle 樹為實現無狀態性(statelessness)提供了有前景的解決方案,但它們並不是最終的解決辦法。然而,像 Dankrad Feist 這樣的專家強調,雖然在將量子抗性加密技術整合到以太坊中時需要謹慎考慮,但值得注意的是,目前以太坊中用於 blob 的 KZG 承諾同樣並不具備量子抗性。因此,Verkle 樹可以作為一個過渡性解決方案,為以太坊網絡提供更多時間來開發更強大的替代方案。

STARK 證明 + 二叉 Merkle 樹

Verkle 樹通過提供更小的證明大小和更高效的驗證過程,相較於傳統的 Merkle 樹,更容易管理以太坊不斷增長的狀態。得益於 基於橢圓曲線的向量承諾,Verkle 樹可以用顯著更少的數據生成大規模的證明。然而,儘管 Verkle 樹在效率上有諸多優勢,其對量子計算機的脆弱性使得它們只能作為暫時的解決方案。雖然以太坊社區將 Verkle 樹視為短期工具,以買時間應對長期解決方案的到來,但長遠目標是向抗量子計算的解決方案過渡。在這一背景下,STARK 證明 和 二叉 Merkle 樹 提供了一個強有力的替代方案,旨在為未來構建更強大的可驗證性基礎設施。

在以太坊的狀態驗證過程中,通過使用 二叉 Merkle 樹,可以將 Merkle 樹的分支因子從 16 減少到 2。這個改變對於減少證明大小並提高驗證效率至關重要。然而,即便是在最壞的情況下,證明大小仍然可能達到 10 MB,這依然是相當龐大的。此時,STARK 證明 就發揮了作用,它能夠將這些大型的二叉 Merkle 證明壓縮到僅 100-300 KB。

這種優化對於在輕客戶端或硬件受限的設備上操作驗證者尤其重要,尤其是在考慮到全球平均的移動下載和上傳速度大約分別為 7.625 MB/s 和 1.5 MB/s 的情況下。用戶可以通過小巧且便於攜帶的證明驗證交易,而無需訪問完整的狀態;驗證者則可以在不存儲整個狀態的情況下執行區塊驗證任務。

這種雙重優化方案同時減少了驗證者的帶寬和存儲需求,加速了驗證過程,帶來了三個關鍵的改進,直接支持了以太坊對於 可擴展性 的願景:

  1. 減少帶寬需求:STARK 證明壓縮了證明大小,降低了網絡傳輸的帶寬需求,使得驗證者和用戶能夠更高效地進行數據傳輸和驗證。
  2. 減少存儲需求:驗證者無需存儲整個狀態,而是通過小型的證明來驗證區塊和交易的有效性,從而減少了存儲壓力。
  3. 加速驗證過程:較小的證明使得驗證過程更加高效,尤其是對於輕客戶端而言,可以大大提升用戶體驗並減少計算負擔。

這種組合方案不僅提升了驗證的效率,還為以太坊的 可擴展性 提供了強有力的支持,特別是在面對大量交易和不斷擴展的區塊鏈狀態時。通過使用 STARK 證明 和 二叉 Merkle 樹,以太坊能夠實現更高效、更經濟的狀態驗證,同時為將來抗量子計算的加密技術鋪平道路。

STARK 證明的主要挑戰:

  1. 證明方的高計算負載:

    生成 STARK 證明的過程在計算上非常密集,特別是在證明方這一側,這可能導致操作成本的增加。

  2. 小數據證明的低效率:

    雖然 STARK 證明在處理大規模數據集時表現出色,但在證明少量數據時卻較為低效,這可能會限制其在某些場景中的應用。當處理涉及較小步驟或數據集的程序時,STARK 證明的相對較大證明大小可能使其在這些情況下不夠實用或成本效益低。

量子安全帶來的代價:證明方的計算負載

一個區塊的 Merkle 證明可能包含大約 330,000 個哈希值,在最壞的情況下,這個數字可能增加到 660,000。在這種情況下,STARK 證明需要每秒處理約 200,000 個哈希值。

在這裡,像 Poseidon 這樣的 zk 友好哈希函數發揮了作用,它們專門優化了 STARK 證明的計算負載。Poseidon 被設計為比傳統哈希算法(如 SHA256 和 Keccak)更適合與 ZK 證明配合使用。其主要原因在於傳統哈希算法的工作方式:它們將輸入處理為二進制數據(0 和 1)。而 ZK 證明則使用素數域,這是一種在數學上根本不同的結構。這種情況類似於計算機在二進制系統中運行,而人類在日常生活中使用十進制系統。將基於位的數據轉換為 ZK 兼容的格式會涉及大量的計算開銷。Poseidon 通過本地在素數域內操作,極大地加速了與 ZK 證明的集成。

然而,由於 Poseidon 是一種相對較新的哈希函數,它需要更廣泛的安全性分析,以建立與傳統哈希函數(如 SHA256 和 Keccak)相同的信任度。為此,以太坊基金會發起了 Poseidon 密碼分析計劃,邀請專家們對 Poseidon 的安全性進行嚴格測試和分析,確保其能夠經受住敵對審查,併成為加密應用的強健標準。另一方面,像 SHA256 和 Keccak 這樣的老舊函數已經經過了廣泛的測試,擁有經過驗證的安全性記錄,但它們並不適合 ZK 使用,這導致在與 STARK 證明配合使用時性能下降。

例如,使用傳統哈希函數的 STARK 證明目前只能處理 10,000 到 30,000 個哈希值。幸運的是,STARK 技術的進展表明,這一吞吐量很快可能會增加到 100,000 到 200,000 個哈希值,從而顯著提高其效率。

STARK 在小數據證明中的低效性

儘管 STARK 證明在大規模數據集的可擴展性和透明性方面表現出色,但在處理小規模且眾多的數據元素時,它們顯示出了局限性。在這些場景中,證明的數據通常較小,但需要多個證明。以下是一些例子:

  1. 賬戶抽象(AA)交易驗證: 使用賬戶抽象(AA)時,錢包可以指向合約代碼,繞過或定製當前以太坊中強制執行的步驟,如非序號和簽名驗證。然而,這種驗證靈活性要求檢查合約代碼或與交易有效性相關的其他數據。
  2. 輕客戶端 RPC 調用: 輕客戶端從網絡查詢狀態數據(例如,在進行 eth_call 請求時),而無需運行完整節點。為了確保這些狀態的正確性,必須支持查詢的數據並確認其與網絡當前狀態相匹配。
  3. 包含列表: 較小的驗證者可以使用包含列表機制來確保交易包含在下一個區塊中,從而限制強大區塊生產者的影響。然而,驗證這些交易的包含性需要確保它們的正確性。

在這些使用場景中,STARK 證明的優勢較小。STARK 強調可擴展性(正如它名字中的 “S” 所表明的那樣),適用於大規模數據集,但在小數據場景中卻表現不佳。相比之下,SNARK 證明設計強調簡潔性(同樣是名字中的 “S” 所表示),專注於最小化證明大小,在帶寬或存儲受限的環境中具有明顯的優勢。

STARK 證明的大小與 SNARK 證明的對比

STARK 證明通常為 40-50 KB,而 SNARK 證明僅為 288 字節,後者約為前者的 175 倍大。這一大小差異增加了驗證時間和網絡成本。STARK 證明較大尺寸的主要原因是其依賴於透明性和多項式承諾來確保可擴展性,這在小數據場景中引入了性能開銷。在這些情況下,像 Merkle Proof 這樣的更快速、更節省空間的方法可能會更加實用。Merkle Proof 提供低計算成本和快速更新,使其在這些場景中更為合適。

然而,儘管 STARK 證明在小數據證明中相對低效,但由於其量子安全性,它們仍然對以太坊的無狀態未來至關重要。
































算法
證明大小
安全性
最壞情況

證明延遲

Verkle 樹
~100 - 2,000 kB
橢圓曲線(不具備抗量子能力)
<1秒
STARK + 保守哈希函數
〜100 - 300

千字節

保守的哈希函數
> 10秒
STARK + 相對較新的哈希函數
〜100 - 300

千字節

相對較新的、未經過充分測試的哈希函數
1-2秒
基於格的 Merkle 樹
Verkle 樹 > x > STARKs
環形短整數解(RSIS)問題
-

如表格所總結的,以太坊有四條潛在的技術路徑可以選擇:

1. Verkle 樹

Verkle 樹得到了以太坊社區的廣泛支持,社區每兩週舉行會議來推動其發展。得益於持續的工作和測試,Verkle 樹在目前的替代方案中,是最成熟且研究最深入的解決方案。此外,Verkle 樹具有加法同態特性,這意味著在更新狀態根時,無需重新計算每個分支,相比 Merkle 樹,Verkle 樹在效率上有所提升。與其他解決方案相比,Verkle 樹強調簡單性,遵循工程原則,例如“保持簡單”或“簡單是最好的”,這種簡單性有助於它們更容易集成到以太坊中,同時也有助於安全性分析。

然而,Verkle 樹並不具備抗量子能力,這使得它們無法作為長期解決方案。如果集成到以太坊中,預計在未來需要被替換,特別是當需要量子抗性解決方案時。即使是 Vitalik 也將 Verkle 樹視為一種臨時措施,用來為 STARKs 和其他技術提供更多時間以成熟。此外,Verkle 樹中使用的基於橢圓曲線的向量承諾,相較於簡單的哈希函數,帶來了更高的計算負載。基於哈希的方法可能會為全節點提供更快的同步時間。此外,Verkle 樹依賴於大量的 256 位運算,這使得它們在現代證明系統中通過 SNARKs 證明變得更加困難,也為未來減少證明大小的工作增添了複雜性。

然而,值得注意的是,Verkle 樹由於不依賴哈希,相較於 Merkle 樹,其可證明性要強得多。

2. STARKs + 保守哈希函數

將 STARKs 與經過充分驗證的保守哈希函數(如 SHA256 或 BLAKE)結合,提供了一個增強以太坊安全性的穩健解決方案。這些哈希函數在學術界和實際應用中得到了廣泛使用,並經過了大量的測試。此外,它們的抗量子能力增強了以太坊對量子計算機威脅的抵禦能力。在對安全性要求高的場景中,這種組合提供了一個可靠的基礎。

然而,使用保守哈希函數的 STARK 系統帶來了顯著的性能限制。由於這些哈希函數的計算需求較高,證明生成的延遲時間超過 10 秒。這在需要低延遲的場景(如區塊驗證)中是一個重大缺點。儘管像多維 Gas 提案這樣的工作嘗試對最壞情況和平均情況的延遲進行對齊,但結果仍然有限。此外,儘管基於哈希的方法可以促進更快的同步時間,但它們的效率可能與 STARKs 的更廣泛可擴展性目標不符。傳統哈希函數的長計算時間降低了實際效率,並限制了它們的適用性。

3. STARKs + 相對較新的哈希函數

將 STARKs 與新一代的 STARK 友好型哈希函數(例如 Poseidon)結合,顯著提高了這種技術的性能。這些哈希函數被設計成能夠無縫集成到 STARK 系統中,並大幅度降低證明者延遲。與傳統哈希函數不同,它們能夠在 1 到 2 秒內生成證明。它們的高效性和低計算開銷增強了 STARKs 的可擴展性,使其在處理大規模數據集時表現得尤為高效。這種能力使它們在需要高性能的應用中非常具有吸引力。

然而,這些哈希函數相對較新,需要進行廣泛的安全分析和測試。由於缺乏全面的測試,引入這些哈希函數可能會帶來風險,尤其是在考慮將其應用於像以太坊這樣的關鍵生態系統時。此外,由於這些哈希函數尚未得到廣泛採用,所需的測試和驗證過程可能會推遲以太坊可驗證性的目標。確保其安全性所需的時間,可能會使這個選項在短期內不那麼具有吸引力,進而推遲以太坊的可擴展性和可驗證性目標的實現。

4. 基於格的 Merkle 樹

基於格的 Merkle 樹提供了一個前瞻性的解決方案,將量子安全性與 Verkle 樹的更新效率相結合。這些結構解決了 Verkle 樹和 STARKs 的弱點,被認為是一個有前景的長期選擇。通過其基於格的設計,它們提供了強大的量子計算威脅抵禦能力,與以太坊未來證明生態系統的長期需求相契合。此外,通過保留 Verkle 樹的更新優勢,它們旨在在不犧牲效率的情況下提供更強的安全性。

然而,基於格的 Merkle 樹的研究仍處於初期階段,主要是理論性的。這給它們的實際實現和性能帶來了很大的不確定性。將這種解決方案集成到以太坊中將需要大量的研究和開發,並且必須經過嚴格的測試以驗證其潛在的好處。由於這些不確定性和基礎設施的複雜性,基於格的 Merkle 樹可能在短期內無法作為一個可行的選擇,可能會延遲以太坊朝著可驗證性目標的進展。

執行:EVM 執行的有效性證明

到目前為止,我們討論的所有內容都集中在去除驗證者需要存儲先前狀態的需求,這些狀態用於從一個狀態過渡到下一個狀態。目標是創建一個更加去中心化的環境,在這個環境中,驗證者可以在不維護數 TB 狀態數據的情況下執行其職責。即便有了我們提到的解決方案,驗證者仍然不需要存儲整個狀態,因為他們將通過區塊中附帶的見證數據接收到執行所需的所有數據。然而,為了過渡到下一個狀態——並由此驗證區塊頂部的 stateRoot——驗證者仍然必須自己執行 STF。這一要求再次對以太坊的許可性和去中心化性提出了挑戰。

最初,The Verge 被設想為一個里程碑,專注於將以太坊的狀態樹從 Merkle 樹過渡到 Verkle 樹,以提高狀態的可驗證性。然而,隨著時間的推移,它已經演變成一個更廣泛的計劃,旨在增強狀態轉換和共識的可驗證性。在一個狀態、執行和共識三者都能完全驗證的世界中,以太坊的驗證者將能夠在幾乎任何具有互聯網連接的設備上運行,並且這些設備可以被歸類為輕客戶端。這將使以太坊更接近實現其“真正去中心化”的願景。

問題定義

正如我們之前提到的,驗證者每 12 秒執行一次名為 STF(狀態轉移函數)的函數。該函數以前一個狀態和一個區塊作為輸入,生成下一個狀態作為輸出。每當一個新區塊被提議時,驗證者必須執行這個函數,並驗證區塊頂部代表狀態的哈希(通常稱為 stateRoot)是否正確。

成為驗證者的高系統要求,主要來自於高效執行這一過程的需求。

讓智能冰箱成為以太坊驗證者:面臨的挑戰與解決方案

如果你想讓一個智能冰箱——沒錯,就是冰箱——變成一個以太坊驗證者,並藉助一些安裝的軟件來實現,你將面臨兩個主要障礙:

  1. 網速問題:你的冰箱很可能沒有足夠快的互聯網連接,這意味著即使有我們前面討論過的狀態可驗證性解決方案,它也無法下載執行所需的數據和證明。
  2. 計算能力不足:即便冰箱能夠訪問 STF 所需的數據,它也缺乏執行從頭到尾的計算能力,或者構建新的狀態樹所需的計算資源。

解決方案:The Verge 提出的方案

為了解決 Light Clients 無法訪問前一個狀態或完整的最新區塊數據的問題,The Verge 提出了一個方案:由提議者執行狀態轉移(STF),然後將證明附加到區塊中。這個證明將包括從前一個狀態根到下一個狀態根的過渡,以及區塊的哈希。通過這種方式,Light Clients 只需使用三個 32 字節的哈希值就能驗證狀態轉移,而不需要 zk-證明。

然而,由於這個證明是通過哈希實現的,不能簡單地說它僅驗證狀態轉移。相反,附加到區塊中的證明必須同時驗證多個方面:

  1. 前一區塊的狀態根 = S,下一區塊的狀態根 = S + 1
  2. 區塊哈希 = H

具體驗證內容

  • 區塊本身的有效性:區塊本身必須是有效的,同時其中的狀態證明——無論是 Verkle 證明還是 STARK 證明——必須準確驗證與區塊相關的數據。
  • 狀態轉移的驗證:當 STF 使用執行所需的數據,並在對應於 H 的區塊中執行時,狀態中應該改變的數據必須正確更新。
  • 樹的構建過程驗證:當用正確更新的數據重建新的狀態樹時,其根值必須與 S + 1 相符。

證明者與驗證者的平衡

在前面提到的 Prover-Verifier 比喻中,通常來說,證明者和驗證者之間會有一定的計算平衡。雖然生成證明所需要的多重驗證機制為驗證者提供了巨大的優勢,但這也意味著生成這些證明以確保執行正確性,對於證明者來說會相對具有挑戰性。目前,以太坊的區塊需要在 4 秒內證明。然而,即使是我們今天最快的 EVM 證明者,也只能在大約 15 秒內證明一個平均區塊【1】。

三種解決路徑

為了克服這一主要挑戰,有三條不同的路徑可以選擇:

  1. 證明並行化與聚合:ZK-證明的一個顯著優勢是它們可以進行聚合。將多個證明合併為一個緊湊的證明,顯著提高了處理效率。這不僅減輕了網絡負載,還加速了去中心化環境下的驗證過程。對於像以太坊這樣的龐大網絡來說,它能夠更高效地為每個區塊生成證明。

在生成證明的過程中,執行過程中的每個小步驟(例如計算步驟或數據訪問)都可以單獨進行證明,這些證明隨後可以聚合成一個單一的結構。通過正確的機制,這種方法使得區塊的證明可以由許多不同的來源(例如數百個 GPU)快速生成並去中心化地處理。這不僅提高了性能,同時也有助於去中心化目標的實現,通過吸引更多的參與者。

使用優化的證明系統

新一代的證明系統有潛力使以太坊的計算過程更快速、更高效。像 Orion、Binius 和 GKR 這樣的先進系統可以顯著減少通用計算的證明時間。這些系統旨在克服當前技術的侷限性,提高處理速度並消耗更少的資源。對於一個以可擴展性和效率為核心的網絡來說,類似的優化提供了巨大的優勢。然而,完全實現這些新系統需要在生態系統內進行廣泛的測試和兼容性努力。

Gas費用的變化

在以太坊虛擬機(EVM)上執行操作時,歷史上Gas費用通常是基於計算成本來決定的。然而,現在,另一個指標開始變得更為重要:證明覆雜性。儘管某些操作相對容易證明,但其他操作則結構更為複雜,需要更長時間才能驗證。根據操作的計算工作量和證明難度來調整Gas費用,對於提高網絡的安全性和效率至關重要。

這種方法能夠最小化最壞情況和平均情況之間的差距,從而實現更加一致的性能。例如,較難證明的操作可能需要更高的Gas費用,而較容易證明的操作則可以降低費用。此外,用適應 STARK 的替代數據結構(如狀態樹或交易列表)替代以太坊現有的數據結構,還可以進一步加速證明過程。這些變化將有助於以太坊實現其可擴展性和安全性目標,同時使其可驗證性的願景更為現實。

以太坊推動執行證明的努力代表了實現其可驗證性目標的重要機會。然而,達成這一目標不僅需要技術創新,還需要增加工程方面的努力,並做出社區內部的關鍵決策。在 Layer 1 上使執行過程可驗證,必須在確保廣泛用戶群體可訪問的同時,保持去中心化並與現有基礎設施保持一致。建立這種平衡增加了在執行過程中證明操作的方式的複雜性,這凸顯了諸如並行證明生成等技術進展的必要性。此外,這些技術的基礎設施要求(例如查找表)必須實現並投入使用,這仍然需要大量的研究和開發工作。

另一方面,專用電路(如 ASIC、FPGA、GPU)專門為某些任務設計,具有顯著加速證明生成過程的潛力。這些解決方案比傳統硬件提供更高的效率,並且能夠加速執行過程。然而,以太坊在 Layer 1 級別的去中心化目標使得這些硬件不應僅僅對少數幾方可用。因此,這些解決方案預計將在 Layer 2 系統中得到更廣泛的應用。然而,社區也需要就證明生成的硬件要求達成共識。一大設計問題是:證明生成是否應該在像高端筆記本電腦這樣的消費級硬件上進行,還是需要工業級基礎設施?這一問題的答案將決定以太坊的整體架構——即在 Layer 2 解決方案上進行激進的優化,同時在 Layer 1 上採取更為保守的方式。

最後,執行證明的實現直接關係到以太坊其他路線圖目標的實現。引入有效性證明不僅支持 無狀態化 等概念,還通過使單獨質押等領域更具可訪問性,增強以太坊的去中心化目標。目標是使得即使是最低規格的設備也能參與質押。此外,基於計算難度和可證明性的重構 EVM 的Gas費用,可以縮小平均情況和最壞情況之間的差距。然而,這種變化可能會打破與當前系統的向後兼容性,並迫使開發者重寫代碼。因此,執行證明的實施不僅是一個技術挑戰——它是一個必須設計來保持以太坊長期價值的過程。

最後一步:實現完全可驗證性的共識機制

以太坊的共識機制致力於在保持去中心化和可訪問性的同時,實現可驗證性的目標。在這個框架下,概率共識和確定性共識方法各有不同的優勢和挑戰。

概率共識

概率共識基於一種傳播式的通信模型。在這種模型中,節點並不會直接與代表網絡的所有節點通信,而是與隨機選擇的一組64或128個節點共享信息。節點的鏈選擇基於這些有限的信息,這就引入了錯誤的可能性。然而,隨著區塊鏈的推進,這些選擇預計會逐漸收斂到正確的鏈上,錯誤率最終接近0%。

概率共識結構的一個優勢是,每個節點並不會將自己的鏈視圖作為單獨的信息進行廣播,從而減少了通信開銷。因此,這種結構能夠支持更多的、權限開放的去中心化節點,並且系統要求較低。

確定性共識

與概率共識不同,確定性共識通過“一對多”的通信模型來運作。在這種模型中,節點將其鏈視圖作為投票發送給其他所有節點。這種方法會產生更高的消息密度,隨著節點數量的增長,系統可能最終達到其限制。然而,確定性共識的最大優勢在於具體的投票機制,使得可以準確知道哪些節點投票支持了哪個分叉。這確保了鏈的快速和確定性最終性,保證了區塊的順序無法改變,並使其可驗證。

以太坊的共識機制平衡

為了在保持去中心化和開放結構的同時提供可驗證的共識機制,以太坊在 插槽紀元(Epochs)之間達成了一種平衡。

  1. 插槽(Slot):插槽是每12秒一個時間間隔,在該時間間隔內,驗證者負責生成一個區塊。儘管在插槽級別使用的概率共識讓區塊鏈能夠更靈活、去中心化地運行,但在確定順序和可驗證性方面仍然存在一些侷限性。
  2. 紀元(Epoch):一個紀元由32個插槽組成,在這個層次上,驗證者投票決定最終區塊鏈的順序,確保了鏈的確定性並使其可驗證。然而,儘管這個確定性結構在紀元級別通過具體的投票提供了可驗證性,它由於概率結構的存在,無法在紀元內部提供完全的可驗證性。
Sync Committee:加強紀元內的可驗證性

為了彌補這一差距並增強紀元內的概率結構,以太坊開發瞭解決方案——同步委員會(Sync Committee)。同步委員會旨在提高概率共識在紀元內的可驗證性,確保區塊的最終確定性和順序不受影響,同時維持去中心化和開放性。

通過將概率共識和確定性共識相結合,並通過同步委員會來進一步增強紀元內的驗證能力,以太坊在實現去中心化的同時,確保了其可擴展性和可驗證性的目標。這種混合共識機制為以太坊的長期可持續性和去中心化打下了堅實的基礎,併為網絡上的參與者提供了更高的安全性和靈活性。

共識的零知識證明化

The Verge旨在通過採用零知識證明技術(zk-proof)增強以太坊當前和未來的共識機制,而不是完全替代它們。此舉旨在在保留去中心化和安全性核心原則的同時,現代化以太坊的共識流程。通過零知識技術優化以太坊鏈的所有歷史和當前共識過程,對實現以太坊長期可擴展性和效率目標至關重要。以太坊共識層使用的基本操作在這一技術轉型中發揮著重要作用。接下來,讓我們更深入地探討這些操作及其所面臨的挑戰。

ECADD 操作:

  • 目的:該操作用於聚合驗證者的公鑰,對於確保鏈的準確性和高效性至關重要。得益於BLS簽名的可聚合特性,多個簽名可以合併為一個結構,這減少了通信開銷,使鏈上的驗證過程更加高效。有效地確保大型驗證者群體的同步,使得這一操作顯得尤為關鍵。
  • 挑戰:如前所述,以太坊的驗證者在紀元期間對鏈的順序進行投票。如今,以太坊網絡大約有110萬個驗證者。如果所有驗證者試圖同時傳播他們的投票,將會對網絡造成極大壓力。為了避免這種情況,以太坊允許驗證者在每個紀元內按槽位投票,每個槽位僅有1/32的驗證者進行投票。儘管這種機制減少了網絡通信的開銷,並提高了共識效率,但鑑於目前的驗證者數量,每個槽位大約有34,000個驗證者進行投票,這意味著每個槽位大約需要進行34,000次ECADD操作。

配對操作(Pairings):

  • 目的:配對操作用於驗證BLS簽名,確保鏈上紀元的有效性。該操作允許批量驗證簽名,但它不支持zk-friendly(零知識證明友好),使得使用zk-proof技術進行證明時非常昂貴。這在創建集成的零知識驗證流程時構成了一個主要挑戰。
  • 挑戰:以太坊中的配對操作每個槽位最多限於128個認證(聚合簽名),因此相較於ECADD操作,配對操作的數量較少。然而,這些操作不支持zk-proof,導致它們在zk-proof系統中的成本極高。證明一個配對操作的零知識證明比證明一個ECADD操作的成本要高出數千倍。這使得配對操作在零知識技術中的適配成為以太坊共識驗證流程中最大的障礙之一。

SHA256 哈希函數:

  • 目的:SHA256哈希函數用於讀取和更新鏈的狀態,確保鏈數據的完整性。然而,它們不支持zk-proof,這導致在基於零知識證明的驗證過程中效率低下,成為以太坊未來可驗證性目標的主要障礙。
  • 挑戰:SHA256哈希函數經常用於讀取和更新鏈的狀態。然而,它們的zk-unfriendliness(不支持零知識證明)與以太坊基於zk-proof的驗證目標相沖突。例如,在兩個紀元之間,每個驗證者都需要運行以太坊共識層的狀態轉換函數(STF)來更新狀態,計算獎勵和懲罰,這基於驗證者在該紀元內的表現。此過程嚴重依賴SHA256哈希函數,極大地增加了基於zk-proof系統的成本。這為將以太坊的共識機制與zk技術對接,提供了巨大的挑戰。

當前共識層使用的ECADD、配對和SHA256操作在以太坊的可驗證性目標中扮演著關鍵角色。然而,它們的zk-unfriendliness(不支持零知識證明)在實現這些目標的過程中帶來了顯著挑戰。ECADD操作由於驗證者投票量龐大,給網絡帶來了昂貴的負擔,而配對操作雖然數量較少,但使用zk-proof證明時卻比ECADD操作貴數千倍。此外,SHA256哈希函數的不支持zk-proof使得證明信標鏈的狀態轉換變得異常困難。這些問題凸顯了以太坊需要進行全面轉型,以將現有基礎設施與零知識技術對接。

解決方案“Beam Chain”:重新構想以太坊的共識層

2024年11月12日,Justin Drake在Devcon的演講中提出了一個名為“Beam Chain”的提案,旨在從根本上和全面地改造以太坊的共識層。信標鏈(Beacon Chain)已經在以太坊網絡的核心運行近五年。然而,在此期間,信標鏈沒有經歷任何重大的結構性變化。與此相對的是,技術進展迅速,遠遠超過了信標鏈的靜態特性。

在演講中,Justin Drake強調,以太坊在過去五年中在多個關鍵領域獲得了重要的經驗教訓,包括MEV(最大化可提取價值)理解、SNARK(簡潔非交互式論證)技術的突破以及對過去技術錯誤的回顧性認知。基於這些新收穫的知識,設計方案被歸納為三個主要支柱:區塊生產、質押和加密學。以下圖表總結了這些設計和提案的路線圖:

綠色和灰色框表示逐步實施的漸進性發展,可以每年逐一實現。這些改進類似於之前的升級,可以逐步集成而不干擾以太坊現有的架構。

另一方面,紅色框表示高協同效應、大規模和基礎性的變革,必須一起實施。根據Drake的說法,這些變化旨在通過一次重大的飛躍提升以太坊的能力和可驗證性。

在本節中,我們詳細討論了The Verge的共識、狀態和執行步驟,其中一個突出的問題是以太坊信標鏈中使用的SHA256哈希函數。雖然SHA256在確保網絡安全和處理交易方面發揮著核心作用,但其缺乏對zk技術友好的特性,成為實現以太坊可驗證性目標的重大障礙。其高計算成本和與zk技術的不兼容性,使其成為必須在未來以太坊發展中解決的關鍵問題。

Justin Drake在Devcon演講中提出的路線圖設想用zk友好的哈希函數(如Poseidon)取代信標鏈中的SHA256。該提案旨在使以太坊的共識層現代化,使其更具可驗證性、更高效,並與zk-proof技術對接。

在這種背景下,我們看到以太坊不僅面臨著與zk不友好哈希函數相關的挑戰,還需要重新評估其共識層中使用的數字簽名,以確保長期的安全性。隨著量子計算的發展,目前使用的數字簽名算法(如ECDSA)可能面臨重大威脅。正如NIST發佈的指南所指出,具有112位安全級別的ECDSA變種將在2030年逐步淘汰,並於2035年完全禁用。這迫使以太坊和類似網絡必須朝著更加具有抗量子能力的替代方案過渡,例如量子安全的簽名。

此時,基於哈希的簽名作為抗量子解決方案浮現,它們將在支持網絡的安全性和可驗證性目標方面發揮關鍵作用。解決這一問題還消除了使信標鏈可驗證的第二大障礙:BLS簽名。以太坊在確保量子安全方面可以採取的最重要步驟之一是採用後量子解決方案,如基於哈希的簽名和基於哈希的SNARKs。

正如Justin Drake在Devcon演講中強調的,哈希函數由於依賴於預像抗性,本質上是抗量子計算的,使它們成為現代密碼學的基礎構件之一。這一特性確保即使是量子計算機也無法有效地從給定的哈希值反推原始輸入,從而保持其安全性。基於哈希的簽名系統允許驗證者和見證者僅基於哈希函數生成簽名,確保後量子安全性,同時提供更高的網絡可驗證性——尤其是在使用SNARK友好的哈希函數時。這種方法不僅提升了網絡的安全性,還使以太坊的長期安全基礎設施變得更加穩健,具備未來-proof能力。

這個系統依賴於將基於哈希的簽名和基於哈希的SNARK(類似STARK的證明)結合,創建可聚合的簽名方案。可聚合簽名將成千上萬的簽名壓縮為一個結構,將其減少到僅幾百千字節的證明。這種壓縮顯著減少了網絡上的數據負載,同時大大加速了驗證過程。例如,以太坊中為一個單一槽產生的成千上萬的驗證者簽名可以通過一個聚合簽名來表示,從而節省存儲空間和計算能力。

然而,這個方案最顯著的特點是它的無限遞歸聚合。也就是說,一組簽名可以在另一組簽名下進一步結合,並且這一過程可以在鏈上繼續進行。藉助這一機制,並考慮到未來的技術進展,可以公平地說,這為目前BLS無法實現的可能性打開了大門。

最終思考與結論

以太坊的可驗證性之路代表了區塊鏈技術的根本轉變。The Verge倡議通過使用Verkle樹進行狀態驗證以及使用STARK證明進行可擴展過渡,解決了核心的低效問題。

其中最雄心勃勃的提案之一是Beam Chain,這是一項對以太坊共識層的全面重設計。通過解決信標鏈的侷限性,並引入zk友好的替代方案,這一方法旨在提升以太坊的可擴展性,同時保持其去中心化和可訪問性的核心原則。然而,這一過渡也凸顯了以太坊在平衡計算需求與保持一個無需許可、包容性網絡的目標時所面臨的挑戰。

隨著NIST計劃到2035年淘汰當前的橢圓曲線加密算法,以太坊必須採納像基於哈希的簽名和Poseidon這樣的抗量子解決方案。這些解決方案也有其效率上的權衡。

STARKs在以太坊路線圖中的使用進一步強調了可擴展性和可驗證性。雖然它們在提供透明且抗量子的證明方面表現出色,但它們的整合帶來了與證明方計算成本和小數據效率相關的挑戰。必須解決這些難題,才能充分實現以太坊的無狀態化和高效塊驗證願景,確保網絡在需求日益增長的情況下依然保持穩健。

儘管有這些進展,仍然存在一些關鍵挑戰。以太坊必須應對zk友好性、共識可擴展性和整合抗量子加密技術的複雜性問題。此外,現有基礎設施的向後兼容性也提出了實際障礙,這需要精心的工程解決方案,以防止對開發者和用戶造成干擾。

讓以太坊與眾不同的,不僅僅是它的技術創新,還有它解決區塊鏈難題的漸進方法。未來的道路——無論是通過Beam Chain、Verkle樹還是STARK證明——都依賴於開發者、研究人員和更廣泛社區的合作努力。這些進展不是一蹴而就的,而是為創建一個透明、去中心化和可驗證的互聯網奠定基礎。

以太坊的演變凸顯了它在塑造Web3時代中的關鍵角色。通過用實際的解決方案應對當今的挑戰,以太坊正朝著一個可驗證性、抗量子性和可擴展性成為標準而非例外的未來邁進。

免責聲明:

  1. 本文轉載自【2077 Research】,所有版權歸原作者【Koray Akpinarr】所有。如對轉載有異議,請聯繫 Gate Learn 團隊,他們會及時處理。
  2. 免責申明:本文中所表達的觀點和意見僅代表作者本人,並不構成任何投資建議。
  3. 本文的翻譯版本由 Gate Learn 團隊完成。除非特別註明,禁止複製、分發或抄襲翻譯文章。

The Verge:讓以太坊可驗證和可持續

進階12/23/2024, 11:49:20 AM
本文探討了《The Verge》,旨在通過 Verkle 樹、STARK 證明、zk 友好的共識機制、Beam 鏈等技術,提升以太坊的可驗證性、可擴展性和可持續性。

可驗證性的路徑

Web3 的核心優勢是可驗證性——用戶可以驗證系統的實際運行方式。這一特性解釋了為什麼許多人在加密行業內外都將 Web3 視為邁向更加透明和可驗證互聯網的一步。

與 Web2 平臺(如 Facebook 或 Instagram)不同,後者的算法和規則即使經過記錄,也依然保持不透明;而加密協議則設計為具備完全的可審計性。即便它們被分享,用戶也缺乏驗證平臺是否按預期運行的能力。這與加密完全相反,加密協議的每一項設計都儘可能確保可審計——至少在理論上是如此。

今天,我們將探討《The Verge》這一部分內容,分析以太坊在實現未來可驗證性、可持續性和可擴展性方面所採取的步驟。本文將討論如何通過區塊鏈架構使其更加可驗證,這些變化在協議層面帶來了哪些創新,以及它們如何為用戶提供更加安全的生態系統。讓我們開始吧!

什麼是“可驗證性”?

Web2 應用通常作為“黑箱”運作——用戶只能看到輸入和輸出,而無法瞭解應用如何實際運作。相比之下,加密貨幣協議通常會公開其源代碼,或者至少有計劃這樣做。這種透明性有兩個目的:首先,它允許用戶在選擇時直接與協議的代碼進行互動;其次,它幫助用戶準確理解系統如何運作以及哪些規則在其中發揮作用。

“去中心化你能去的部分,其餘部分確保可驗證。”

可驗證性確保系統能夠承擔責任,並且在許多情況下,保證協議按預期運行。這個原則強調最小化中心化的重要性,因為中心化往往導致不透明和無法追責的結構,用戶無法驗證操作的真實性。相反,我們應當儘可能地實現去中心化,而對於無法去中心化的部分,則應確保其可驗證且可追責。

以太坊社區似乎與這種觀點一致,因為其路線圖中包含了一個名為“Verge”的里程碑,旨在讓以太坊變得更加可驗證。然而,在深入探討《The Verge》之前,我們需要了解區塊鏈的哪些方面應該被驗證,以及從用戶的角度來看,哪些部分是至關重要的。

區塊鏈本質上充當了全球時鐘的角色。在一個由大約 10,000 臺計算機組成的分佈式網絡中,交易從源節點傳播到所有其他節點可能需要相當長的時間。因此,網絡中的節點無法確定交易的確切順序——即無法判斷某筆交易是先到達還是後到達,因為它們只能從自身的主觀視角進行觀察。

由於交易順序非常重要,區塊鏈網絡使用稱為“共識算法”的專門方法,確保節點保持同步並按照相同的順序處理交易序列。儘管節點無法在全球範圍內確定交易的順序,但共識機制使得所有節點能夠達成一致,確認相同的交易序列,從而使整個網絡像一個單一且協調的計算機一樣運作。

除了共識層之外,每個區塊鏈中還有一個執行層。執行層由用戶想要執行的交易所決定。 \
一旦交易通過共識成功排序,每筆交易就必須應用於執行層的當前狀態。如果你在想,“什麼是狀態?”那麼你可能已經看到區塊鏈被比作數據庫——或者更具體地說,是銀行的數據庫,因為區塊鏈與銀行一樣,會記錄每個人的賬戶餘額。

如果你在狀態“S”中有 $100,並且想要向其他人發送 $10,那麼在下一個狀態“S+1”中,你的餘額將變為 $90。這一過程,即通過應用交易從一個狀態過渡到另一個狀態的過程,我們稱之為 STF(狀態轉換函數)。

在比特幣中,STF 主要限於餘額變化,因此相對簡單。然而,與比特幣不同,Ethereum 的 STF 要複雜得多,因為以太坊是一個完全可編程的區塊鏈,具有執行層,能夠運行代碼。

在區塊鏈中,有三個基本組件是你需要或能夠驗證的:

  • 狀態:你可能想讀取區塊鏈上的某一數據,但由於你沒有運行完整節點,因此無法直接訪問該狀態。因此,你通過像 Alchemy 或 Infura 這樣的 RPC(遠程過程調用)提供者請求數據。然而,你必須驗證這些數據在 RPC 提供者處未被篡改。
  • 執行:如前所述,區塊鏈利用 STF。你必須驗證狀態轉換是否正確執行——這不是逐筆交易地驗證,而是逐塊地驗證。
  • 共識:像 RPC 這樣的第三方實體可以提供你尚未被包含在區塊鏈中的有效區塊。因此,你必須驗證這些區塊已經通過共識被接受,並且被添加到區塊鏈中。

如果這些內容聽起來令人困惑或不清楚,不用擔心,我們將詳細解釋每個方面。首先,讓我們從如何驗證區塊鏈狀態開始!

如何驗證區塊鏈狀態?

以太坊的“狀態”指的是區塊鏈在任何特定時間點存儲的數據集合。這些數據包括賬戶餘額(包括合約賬戶和外部擁有賬戶,簡稱 EOA)、智能合約代碼、合約存儲等。以太坊是一個基於狀態的機器,因為在以太坊虛擬機(EVM)中處理的每一筆交易都會改變先前的狀態,併產生一個新的狀態。

每個以太坊區塊都包含一個值,用於總結該區塊之後網絡的當前狀態,這個值稱為 stateRoot。這個值是對整個以太坊狀態的緊湊表示,通常是一個 64 字符的哈希值。

隨著每一筆新交易修改狀態,後續區塊中記錄的 stateRoot 會相應更新。為了計算這個值,以太坊的驗證者使用了 Keccak 哈希函數和一種稱為 Merkle Tree(默克爾樹)的數據結構來組織和總結狀態的不同部分。

哈希函數是單向函數,它將輸入轉化為固定長度的輸出。在以太坊中,像 Keccak 這樣的哈希函數被用來生成數據的摘要,充當輸入數據的指紋。哈希函數有四個基本特性:

確定性:相同的輸入總是會生成相同的輸出。

固定輸出長度:無論輸入的長度如何,輸出的長度總是固定的。

單向性:從輸出推導出原始輸入幾乎是不可能的。

唯一性:即使輸入發生微小變化,輸出也會完全不同。因此,特定的輸入會映射到一個幾乎唯一的輸出。

正因為這些特性,以太坊驗證者能夠執行每個區塊的 STF(狀態轉換函數)——執行區塊中的所有交易並將其應用到狀態中,然後驗證區塊中指示的狀態是否與通過 STF 得到的狀態匹配。這個過程確保了區塊提議者的誠實行為,使其成為驗證者的核心職責之一。

然而,以太坊驗證者並不會直接對整個狀態進行哈希操作來找到其摘要。由於哈希函數的單向特性,直接對狀態進行哈希會消除可驗證性,因為重現該哈希的唯一方法是擁有整個狀態。

由於以太坊的狀態數據量達到數 TB,因此將整個狀態存儲在手機或個人計算機等日常設備上是不切實際的。為了解決這個問題,以太坊使用 Merkle 樹 結構來計算 stateRoot,儘可能保留狀態的可驗證性。

Merkle 樹是一種加密數據結構,用於安全且高效地驗證數據的完整性和正確性。Merkle 樹基於哈希函數構建,將數據集的哈希值按照層級結構組織,從而使得能夠驗證數據的完整性和正確性。該樹結構由三種類型的節點組成:

  • 葉子節點:這些節點包含單個數據片段的哈希值,位於樹的最底層。每個葉子節點代表 Merkle 樹中某一特定數據片段的哈希值。
  • 分支節點:這些節點包含其子節點的組合哈希值。例如,在一個二叉 Merkle 樹中(N=2),兩個子節點的哈希值會被連接起來,再次進行哈希運算,生成一個分支節點的哈希值,位於更高的層級。
  • 根節點:根節點位於 Merkle 樹的最頂層,代表整個樹的加密摘要。這個節點用於驗證樹中所有數據的完整性和正確性。

如果你想知道如何構建這樣的樹,實際上它只需要兩個簡單的步驟:

  • 葉子節點創建:每個數據片段通過哈希函數進行處理,得到的哈希值形成葉子節點。這些節點位於樹的最底層,代表數據的加密摘要。

  • 葉子節點的哈希值會按一定方式(例如按對組)進行分組和合並,隨後進行哈希運算。這個過程會在樹的下一層生成分支節點。對於每個分支節點,重複相同的過程,直到只剩下一個哈希值。

最終,在樹頂端獲得的哈希值被稱為 Merkle 根。Merkle 根代表整個樹的加密摘要,並允許安全地驗證數據的完整性。

我們如何使用 Merkle 根來驗證以太坊的狀態?

Merkle 證明 使得驗證者能夠高效地驗證特定數據片段的有效性,通過提供一系列哈希值,形成從目標數據(即葉子節點)到區塊頭中存儲的 Merkle 根的路徑。這個中間哈希鏈使得驗證者能夠確認數據的真實性,而無需對整個狀態進行哈希計算。

驗證者從特定的數據點開始,將其與 Merkle 證明中提供的每個“兄弟”哈希值逐步合併,並進行哈希運算。這一過程會一直持續,直到產生一個單一的哈希值。如果計算出的哈希值與存儲的 Merkle 根匹配,則數據被視為有效;否則,驗證者可以確定該數據與所聲明的狀態不符。

示例:使用 Merkle 證明驗證數據點

假設我們從 RPC 接收到數據 #4,並希望使用 Merkle 證明驗證其真實性。為此,RPC 會提供一組哈希值,這些哈希值形成一條路徑,能夠達到 Merkle 根。對於數據 #4,兄弟哈希值將包括 Hash #3、Hash #12 和 Hash #5678。

  1. 從數據 4 開始:首先,我們對數據 #4 進行哈希,得到 Hash #4。
  2. 與兄弟節點合併:然後,我們將 Hash #4 與 Hash #3(它在葉子層級的兄弟節點)合併,並進行哈希運算,得到 Hash #34。
  3. 向上移動樹:接下來,我們將 Hash #34 與 Hash #12(它在下一層的兄弟節點)合併,並哈希得到 Hash #1234。
  4. 最後一步:最後,我們將 Hash #1234 與 Hash #5678(提供的最後一個兄弟哈希)合併,並進行哈希運算。結果哈希應該與存儲在區塊頭中的 Merkle 根(Hash #12345678)匹配。

如果計算出的 Merkle 根與區塊中的狀態根匹配,那麼我們確認數據 #4 在該狀態下是有效的。如果不匹配,則說明數據不屬於所聲明的狀態,表明可能存在篡改。正如你所看到的,驗證者無需提供所有數據的哈希值,也不需要從頭開始重建整個 Merkle 樹,僅通過提供三個哈希值,證明者就能證明數據 #4 在該狀態中存在且未被篡改。這就是為什麼 Merkle 證明被認為是高效的主要原因。

Merkle 樹的效率是否足夠高?

雖然 Merkle 樹無疑在像以太坊這樣的大型區塊鏈系統中提供了安全且高效的數據驗證,但它們是否真的足夠高效呢?為了回答這個問題,我們必須分析 Merkle 樹的性能和大小如何影響證明者與驗證者之間的關係。

影響 Merkle 樹性能的兩個關鍵因素 ⌛

  • 分支因子:每個分支節點的子節點數量。
  • 數據總大小:樹中表示的數據集的大小。

分支因子的影響

為了更好地理解分支因子的影響,我們來舉一個例子。分支因子決定了每個節點會從多少個分支延伸出去。

小的分支因子(例如,二叉 Merkle 樹)

如果使用的是二叉 Merkle 樹(分支因子為 2),那麼證明的大小非常小,使得驗證過程對驗證者來說更加高效。在每個節點只有兩個分支的情況下,驗證者只需要處理每一層的一個兄弟哈希。這加快了驗證速度,並減少了計算負擔。然而,較小的分支因子增加了樹的高度,在構建樹時需要更多的哈希操作,這對驗證者來說可能是一個負擔。

較大的分支因子(例如,4)

較大的分支因子(例如,4)降低了樹的高度,形成了一個更短、更寬的結構。由於需要的哈希操作較少,完整節點(Full Nodes)能夠更快地構建樹。然而,對於驗證者來說,這會增加他們在每一層需要處理的兄弟哈希數量,導致證明的大小變大。每次驗證步驟中需要更多的哈希值,也意味著驗證者的計算和帶寬成本更高,實際上將負擔從驗證者轉移到了驗證者身上。

總結來說,較大的分支因子通過降低樹的高度和構建時間來提高了驗證速度,但同時也增加了驗證時的工作量和資源消耗。因此,在設計 Merkle 樹時,需要平衡分支因子的大小,以實現驗證效率和構建效率之間的最佳折衷。

第二章:以太坊可驗證性革命——The Verge

The Verge 是以太坊路線圖中的一個里程碑,旨在提高可驗證性,強化區塊鏈的去中心化結構,並增強網絡安全性。以太坊網絡的一個主要目標是使任何人都能輕鬆運行驗證節點來驗證區塊鏈,創建一個沒有中心化的開放參與結構。這一驗證過程的可達性是區塊鏈區別於中心化系統的關鍵特徵之一。雖然中心化系統不提供驗證功能,但區塊鏈的正確性完全掌握在其用戶手中。然而,為了保持這一保證,運行一個驗證節點必須對所有人都能訪問——這是當前系統下的一個挑戰,因為驗證節點需要大量的存儲和計算資源。

自從通過 The Merge 轉向 權益證明(Proof-of-Stake,PoS) 共識模型以來,以太坊驗證者有兩個主要責任:

確保共識:支持概率性和確定性共識協議的正常運行,並應用分叉選擇算法。

檢查區塊準確性:在執行區塊中的交易後,驗證結果狀態樹的根是否與提議者聲明的狀態根匹配。

為了履行第二項責任,驗證者必須能夠訪問區塊之前的狀態。這使得他們能夠執行區塊中的交易,並推導出後續狀態。然而,這一要求給驗證者帶來了沉重的負擔,因為他們需要處理大量的存儲要求。雖然以太坊的設計目標是使其可行,並且全球存儲成本正在逐漸降低,但問題的關鍵不在於成本,而在於驗證者需要依賴專用硬件。The Verge 旨在通過創建一個基礎設施來克服這一挑戰,使得即使在存儲有限的設備上(如手機、瀏覽器錢包,甚至智能手錶)也能進行完整的驗證,允許驗證節點在這些設備上運行。

可驗證性的第一步:狀態

過渡到 Verkle 樹 是這個過程的關鍵部分。最初,The Verge 的重點是將以太坊的 Merkle 樹結構替換為 Verkle 樹。採用 Verkle 樹的主要原因是,Merkle 樹對以太坊可驗證性構成了重大障礙。雖然在正常情況下,Merkle 樹及其證明能夠高效地工作,但在最壞的情況下,它們的性能會急劇下降。

根據 Vitalik 的計算,平均證明大小約為 4 KB,這聽起來是可以管理的。然而,在最壞的情況下,證明的大小可能會膨脹到 330 MB。是的,你沒看錯——330 MB。

以太坊的 Merkle 樹在最壞情況下的極端低效,主要源於兩個原因:

  1. 使用十叉樹(Hexary Trees)

目前,以太坊使用的 Merkle 樹的分支因子是 16。這意味著,驗證一個單獨的節點時,需要提供該分支中的其他 15 個哈希。考慮到以太坊狀態的大小和分支數量,在最壞的情況下,這會造成相當大的負擔。

  1. 非 Merkle 化的代碼:以太坊並沒有將合約代碼納入樹結構,而是將代碼進行哈希處理,並使用生成的哈希值作為節點。考慮到合約的最大大小為 24 KB,這種方法在實現完全可驗證性時會帶來顯著的負擔。

證明大小與分支因子成正比。減少分支因子可以減小證明大小。為了解決這些問題並改善最壞情況下的表現,以太坊可以將十叉樹(Hexary Trees)轉換為二叉 Merkle 樹(Binary Merkle Trees),並開始將合約代碼進行 Merkle 化。如果以太坊的分支因子從 16 降到 2,並且將合約代碼也進行 Merkle 化,那麼最大證明大小可能縮小至 10 MB。雖然這是一個顯著的改進,但值得注意的是,這個成本僅適用於驗證單個數據。即便是一個簡單的交易,訪問多個數據項時,也需要更大的證明。考慮到每個區塊的交易數量以及以太坊狀態的持續增長,儘管這種方案更好,但仍然不完全可行。

因此,以太坊社區提出了兩種不同的解決方案來應對這一問題:

  1. Verkle 樹
  2. STARK 證明 + 二叉 Merkle 樹

Verkle 樹與向量承諾(Vector Commitments)

顧名思義,Verkle 樹 是類似於 Merkle 樹 的樹結構。然而,它們在驗證過程中的效率方面存在顯著差異。在 Merkle 樹 中,如果一個分支包含 16 個數據項,且我們只想驗證其中的一個數據項,則必須提供覆蓋其他 15 個數據項的哈希鏈。這大大增加了驗證的計算負擔,並導致了較大的證明大小。

相比之下,Verkle 樹 使用了一種名為“基於橢圓曲線的向量承諾(Elliptic Curve-based Vector Commitments)”的專門結構,具體來說,是 基於內積論證(IPA) 的向量承諾。向量本質上是按特定順序組織的數據元素列表。以太坊的狀態可以被視為一個向量:這是一個存儲著多個數據項並按特定順序排列的結構,其中每個元素都至關重要。該狀態包含了各種數據組件,例如地址、合約代碼和存儲信息,而這些元素的順序在訪問和驗證過程中起著至關重要的作用。

向量承諾是用於證明和驗證數據集內數據元素的密碼學方法。這些方法能夠同時驗證數據集內每個元素的存在性和順序。例如,Merkle Proofs(用於 Merkle 樹)也可以視為一種向量承諾形式。雖然 Merkle 樹需要驗證元素時提供所有相關的哈希鏈,但其結構本質上證明了向量中的所有元素是按特定順序相連接的。

與 Merkle 樹不同,Verkle 樹採用了基於橢圓曲線的向量承諾,這為其提供了兩個主要優勢:

基於橢圓曲線的向量承諾 消除了驗證數據時需要提供與被驗證數據無關的其他元素的細節。在 Merkle 樹 中,若採用 16 分支因子,驗證單一分支時需要提供其他 15 個哈希值。考慮到以太坊的狀態龐大且包含多個分支,這種做法會造成極大的低效性。而 基於橢圓曲線的向量承諾 則消除了這種複雜性,它允許通過較少的數據和計算工作量完成驗證。

通過 多重證明(multi-proofs),基於橢圓曲線的向量承諾所生成的證明可以被壓縮成一個恆定大小的證明。由於以太坊的狀態不僅龐大,而且持續增長,隨著時間的推移,需要驗證的分支數量也在增加。然而,使用 Verkle 樹 後,我們可以利用 Dankrad Feist 文章中詳細描述的方法,將每個分支的證明“壓縮”成一個單一的恆定大小的證明。這樣,驗證者只需要使用一個小的證明來驗證整個樹,而不必單獨驗證每一個分支。這也意味著,Verkle 樹不會受到以太坊狀態增長的影響。

基於橢圓曲線的向量承諾的這些特點大大減少了驗證所需的數據量,使 Verkle 樹即使在最壞的情況下也能產生小而恆定大小的證明,從而最小化了數據開銷和驗證時間,提高了像以太坊這樣的龐大網絡的效率。因此,Verkle 樹中的橢圓曲線向量承諾使得以太坊日益增長的狀態能夠更有效地管理和處理。

Verkle 樹的侷限性

然而,像所有創新一樣,Verkle 樹也有其侷限性。其中一個主要缺點是它依賴於 橢圓曲線加密,這使其面臨量子計算機的潛在威脅。量子計算機比經典計算方法擁有更強大的計算能力,這對橢圓曲線加密協議構成了顯著威脅。量子算法可能會打破或削弱這些加密系統,引發對 Verkle 樹長期安全性的擔憂。

因此,儘管 Verkle 樹為實現無狀態性(statelessness)提供了有前景的解決方案,但它們並不是最終的解決辦法。然而,像 Dankrad Feist 這樣的專家強調,雖然在將量子抗性加密技術整合到以太坊中時需要謹慎考慮,但值得注意的是,目前以太坊中用於 blob 的 KZG 承諾同樣並不具備量子抗性。因此,Verkle 樹可以作為一個過渡性解決方案,為以太坊網絡提供更多時間來開發更強大的替代方案。

STARK 證明 + 二叉 Merkle 樹

Verkle 樹通過提供更小的證明大小和更高效的驗證過程,相較於傳統的 Merkle 樹,更容易管理以太坊不斷增長的狀態。得益於 基於橢圓曲線的向量承諾,Verkle 樹可以用顯著更少的數據生成大規模的證明。然而,儘管 Verkle 樹在效率上有諸多優勢,其對量子計算機的脆弱性使得它們只能作為暫時的解決方案。雖然以太坊社區將 Verkle 樹視為短期工具,以買時間應對長期解決方案的到來,但長遠目標是向抗量子計算的解決方案過渡。在這一背景下,STARK 證明 和 二叉 Merkle 樹 提供了一個強有力的替代方案,旨在為未來構建更強大的可驗證性基礎設施。

在以太坊的狀態驗證過程中,通過使用 二叉 Merkle 樹,可以將 Merkle 樹的分支因子從 16 減少到 2。這個改變對於減少證明大小並提高驗證效率至關重要。然而,即便是在最壞的情況下,證明大小仍然可能達到 10 MB,這依然是相當龐大的。此時,STARK 證明 就發揮了作用,它能夠將這些大型的二叉 Merkle 證明壓縮到僅 100-300 KB。

這種優化對於在輕客戶端或硬件受限的設備上操作驗證者尤其重要,尤其是在考慮到全球平均的移動下載和上傳速度大約分別為 7.625 MB/s 和 1.5 MB/s 的情況下。用戶可以通過小巧且便於攜帶的證明驗證交易,而無需訪問完整的狀態;驗證者則可以在不存儲整個狀態的情況下執行區塊驗證任務。

這種雙重優化方案同時減少了驗證者的帶寬和存儲需求,加速了驗證過程,帶來了三個關鍵的改進,直接支持了以太坊對於 可擴展性 的願景:

  1. 減少帶寬需求:STARK 證明壓縮了證明大小,降低了網絡傳輸的帶寬需求,使得驗證者和用戶能夠更高效地進行數據傳輸和驗證。
  2. 減少存儲需求:驗證者無需存儲整個狀態,而是通過小型的證明來驗證區塊和交易的有效性,從而減少了存儲壓力。
  3. 加速驗證過程:較小的證明使得驗證過程更加高效,尤其是對於輕客戶端而言,可以大大提升用戶體驗並減少計算負擔。

這種組合方案不僅提升了驗證的效率,還為以太坊的 可擴展性 提供了強有力的支持,特別是在面對大量交易和不斷擴展的區塊鏈狀態時。通過使用 STARK 證明 和 二叉 Merkle 樹,以太坊能夠實現更高效、更經濟的狀態驗證,同時為將來抗量子計算的加密技術鋪平道路。

STARK 證明的主要挑戰:

  1. 證明方的高計算負載:

    生成 STARK 證明的過程在計算上非常密集,特別是在證明方這一側,這可能導致操作成本的增加。

  2. 小數據證明的低效率:

    雖然 STARK 證明在處理大規模數據集時表現出色,但在證明少量數據時卻較為低效,這可能會限制其在某些場景中的應用。當處理涉及較小步驟或數據集的程序時,STARK 證明的相對較大證明大小可能使其在這些情況下不夠實用或成本效益低。

量子安全帶來的代價:證明方的計算負載

一個區塊的 Merkle 證明可能包含大約 330,000 個哈希值,在最壞的情況下,這個數字可能增加到 660,000。在這種情況下,STARK 證明需要每秒處理約 200,000 個哈希值。

在這裡,像 Poseidon 這樣的 zk 友好哈希函數發揮了作用,它們專門優化了 STARK 證明的計算負載。Poseidon 被設計為比傳統哈希算法(如 SHA256 和 Keccak)更適合與 ZK 證明配合使用。其主要原因在於傳統哈希算法的工作方式:它們將輸入處理為二進制數據(0 和 1)。而 ZK 證明則使用素數域,這是一種在數學上根本不同的結構。這種情況類似於計算機在二進制系統中運行,而人類在日常生活中使用十進制系統。將基於位的數據轉換為 ZK 兼容的格式會涉及大量的計算開銷。Poseidon 通過本地在素數域內操作,極大地加速了與 ZK 證明的集成。

然而,由於 Poseidon 是一種相對較新的哈希函數,它需要更廣泛的安全性分析,以建立與傳統哈希函數(如 SHA256 和 Keccak)相同的信任度。為此,以太坊基金會發起了 Poseidon 密碼分析計劃,邀請專家們對 Poseidon 的安全性進行嚴格測試和分析,確保其能夠經受住敵對審查,併成為加密應用的強健標準。另一方面,像 SHA256 和 Keccak 這樣的老舊函數已經經過了廣泛的測試,擁有經過驗證的安全性記錄,但它們並不適合 ZK 使用,這導致在與 STARK 證明配合使用時性能下降。

例如,使用傳統哈希函數的 STARK 證明目前只能處理 10,000 到 30,000 個哈希值。幸運的是,STARK 技術的進展表明,這一吞吐量很快可能會增加到 100,000 到 200,000 個哈希值,從而顯著提高其效率。

STARK 在小數據證明中的低效性

儘管 STARK 證明在大規模數據集的可擴展性和透明性方面表現出色,但在處理小規模且眾多的數據元素時,它們顯示出了局限性。在這些場景中,證明的數據通常較小,但需要多個證明。以下是一些例子:

  1. 賬戶抽象(AA)交易驗證: 使用賬戶抽象(AA)時,錢包可以指向合約代碼,繞過或定製當前以太坊中強制執行的步驟,如非序號和簽名驗證。然而,這種驗證靈活性要求檢查合約代碼或與交易有效性相關的其他數據。
  2. 輕客戶端 RPC 調用: 輕客戶端從網絡查詢狀態數據(例如,在進行 eth_call 請求時),而無需運行完整節點。為了確保這些狀態的正確性,必須支持查詢的數據並確認其與網絡當前狀態相匹配。
  3. 包含列表: 較小的驗證者可以使用包含列表機制來確保交易包含在下一個區塊中,從而限制強大區塊生產者的影響。然而,驗證這些交易的包含性需要確保它們的正確性。

在這些使用場景中,STARK 證明的優勢較小。STARK 強調可擴展性(正如它名字中的 “S” 所表明的那樣),適用於大規模數據集,但在小數據場景中卻表現不佳。相比之下,SNARK 證明設計強調簡潔性(同樣是名字中的 “S” 所表示),專注於最小化證明大小,在帶寬或存儲受限的環境中具有明顯的優勢。

STARK 證明的大小與 SNARK 證明的對比

STARK 證明通常為 40-50 KB,而 SNARK 證明僅為 288 字節,後者約為前者的 175 倍大。這一大小差異增加了驗證時間和網絡成本。STARK 證明較大尺寸的主要原因是其依賴於透明性和多項式承諾來確保可擴展性,這在小數據場景中引入了性能開銷。在這些情況下,像 Merkle Proof 這樣的更快速、更節省空間的方法可能會更加實用。Merkle Proof 提供低計算成本和快速更新,使其在這些場景中更為合適。

然而,儘管 STARK 證明在小數據證明中相對低效,但由於其量子安全性,它們仍然對以太坊的無狀態未來至關重要。
































算法
證明大小
安全性
最壞情況

證明延遲

Verkle 樹
~100 - 2,000 kB
橢圓曲線(不具備抗量子能力)
<1秒
STARK + 保守哈希函數
〜100 - 300

千字節

保守的哈希函數
> 10秒
STARK + 相對較新的哈希函數
〜100 - 300

千字節

相對較新的、未經過充分測試的哈希函數
1-2秒
基於格的 Merkle 樹
Verkle 樹 > x > STARKs
環形短整數解(RSIS)問題
-

如表格所總結的,以太坊有四條潛在的技術路徑可以選擇:

1. Verkle 樹

Verkle 樹得到了以太坊社區的廣泛支持,社區每兩週舉行會議來推動其發展。得益於持續的工作和測試,Verkle 樹在目前的替代方案中,是最成熟且研究最深入的解決方案。此外,Verkle 樹具有加法同態特性,這意味著在更新狀態根時,無需重新計算每個分支,相比 Merkle 樹,Verkle 樹在效率上有所提升。與其他解決方案相比,Verkle 樹強調簡單性,遵循工程原則,例如“保持簡單”或“簡單是最好的”,這種簡單性有助於它們更容易集成到以太坊中,同時也有助於安全性分析。

然而,Verkle 樹並不具備抗量子能力,這使得它們無法作為長期解決方案。如果集成到以太坊中,預計在未來需要被替換,特別是當需要量子抗性解決方案時。即使是 Vitalik 也將 Verkle 樹視為一種臨時措施,用來為 STARKs 和其他技術提供更多時間以成熟。此外,Verkle 樹中使用的基於橢圓曲線的向量承諾,相較於簡單的哈希函數,帶來了更高的計算負載。基於哈希的方法可能會為全節點提供更快的同步時間。此外,Verkle 樹依賴於大量的 256 位運算,這使得它們在現代證明系統中通過 SNARKs 證明變得更加困難,也為未來減少證明大小的工作增添了複雜性。

然而,值得注意的是,Verkle 樹由於不依賴哈希,相較於 Merkle 樹,其可證明性要強得多。

2. STARKs + 保守哈希函數

將 STARKs 與經過充分驗證的保守哈希函數(如 SHA256 或 BLAKE)結合,提供了一個增強以太坊安全性的穩健解決方案。這些哈希函數在學術界和實際應用中得到了廣泛使用,並經過了大量的測試。此外,它們的抗量子能力增強了以太坊對量子計算機威脅的抵禦能力。在對安全性要求高的場景中,這種組合提供了一個可靠的基礎。

然而,使用保守哈希函數的 STARK 系統帶來了顯著的性能限制。由於這些哈希函數的計算需求較高,證明生成的延遲時間超過 10 秒。這在需要低延遲的場景(如區塊驗證)中是一個重大缺點。儘管像多維 Gas 提案這樣的工作嘗試對最壞情況和平均情況的延遲進行對齊,但結果仍然有限。此外,儘管基於哈希的方法可以促進更快的同步時間,但它們的效率可能與 STARKs 的更廣泛可擴展性目標不符。傳統哈希函數的長計算時間降低了實際效率,並限制了它們的適用性。

3. STARKs + 相對較新的哈希函數

將 STARKs 與新一代的 STARK 友好型哈希函數(例如 Poseidon)結合,顯著提高了這種技術的性能。這些哈希函數被設計成能夠無縫集成到 STARK 系統中,並大幅度降低證明者延遲。與傳統哈希函數不同,它們能夠在 1 到 2 秒內生成證明。它們的高效性和低計算開銷增強了 STARKs 的可擴展性,使其在處理大規模數據集時表現得尤為高效。這種能力使它們在需要高性能的應用中非常具有吸引力。

然而,這些哈希函數相對較新,需要進行廣泛的安全分析和測試。由於缺乏全面的測試,引入這些哈希函數可能會帶來風險,尤其是在考慮將其應用於像以太坊這樣的關鍵生態系統時。此外,由於這些哈希函數尚未得到廣泛採用,所需的測試和驗證過程可能會推遲以太坊可驗證性的目標。確保其安全性所需的時間,可能會使這個選項在短期內不那麼具有吸引力,進而推遲以太坊的可擴展性和可驗證性目標的實現。

4. 基於格的 Merkle 樹

基於格的 Merkle 樹提供了一個前瞻性的解決方案,將量子安全性與 Verkle 樹的更新效率相結合。這些結構解決了 Verkle 樹和 STARKs 的弱點,被認為是一個有前景的長期選擇。通過其基於格的設計,它們提供了強大的量子計算威脅抵禦能力,與以太坊未來證明生態系統的長期需求相契合。此外,通過保留 Verkle 樹的更新優勢,它們旨在在不犧牲效率的情況下提供更強的安全性。

然而,基於格的 Merkle 樹的研究仍處於初期階段,主要是理論性的。這給它們的實際實現和性能帶來了很大的不確定性。將這種解決方案集成到以太坊中將需要大量的研究和開發,並且必須經過嚴格的測試以驗證其潛在的好處。由於這些不確定性和基礎設施的複雜性,基於格的 Merkle 樹可能在短期內無法作為一個可行的選擇,可能會延遲以太坊朝著可驗證性目標的進展。

執行:EVM 執行的有效性證明

到目前為止,我們討論的所有內容都集中在去除驗證者需要存儲先前狀態的需求,這些狀態用於從一個狀態過渡到下一個狀態。目標是創建一個更加去中心化的環境,在這個環境中,驗證者可以在不維護數 TB 狀態數據的情況下執行其職責。即便有了我們提到的解決方案,驗證者仍然不需要存儲整個狀態,因為他們將通過區塊中附帶的見證數據接收到執行所需的所有數據。然而,為了過渡到下一個狀態——並由此驗證區塊頂部的 stateRoot——驗證者仍然必須自己執行 STF。這一要求再次對以太坊的許可性和去中心化性提出了挑戰。

最初,The Verge 被設想為一個里程碑,專注於將以太坊的狀態樹從 Merkle 樹過渡到 Verkle 樹,以提高狀態的可驗證性。然而,隨著時間的推移,它已經演變成一個更廣泛的計劃,旨在增強狀態轉換和共識的可驗證性。在一個狀態、執行和共識三者都能完全驗證的世界中,以太坊的驗證者將能夠在幾乎任何具有互聯網連接的設備上運行,並且這些設備可以被歸類為輕客戶端。這將使以太坊更接近實現其“真正去中心化”的願景。

問題定義

正如我們之前提到的,驗證者每 12 秒執行一次名為 STF(狀態轉移函數)的函數。該函數以前一個狀態和一個區塊作為輸入,生成下一個狀態作為輸出。每當一個新區塊被提議時,驗證者必須執行這個函數,並驗證區塊頂部代表狀態的哈希(通常稱為 stateRoot)是否正確。

成為驗證者的高系統要求,主要來自於高效執行這一過程的需求。

讓智能冰箱成為以太坊驗證者:面臨的挑戰與解決方案

如果你想讓一個智能冰箱——沒錯,就是冰箱——變成一個以太坊驗證者,並藉助一些安裝的軟件來實現,你將面臨兩個主要障礙:

  1. 網速問題:你的冰箱很可能沒有足夠快的互聯網連接,這意味著即使有我們前面討論過的狀態可驗證性解決方案,它也無法下載執行所需的數據和證明。
  2. 計算能力不足:即便冰箱能夠訪問 STF 所需的數據,它也缺乏執行從頭到尾的計算能力,或者構建新的狀態樹所需的計算資源。

解決方案:The Verge 提出的方案

為了解決 Light Clients 無法訪問前一個狀態或完整的最新區塊數據的問題,The Verge 提出了一個方案:由提議者執行狀態轉移(STF),然後將證明附加到區塊中。這個證明將包括從前一個狀態根到下一個狀態根的過渡,以及區塊的哈希。通過這種方式,Light Clients 只需使用三個 32 字節的哈希值就能驗證狀態轉移,而不需要 zk-證明。

然而,由於這個證明是通過哈希實現的,不能簡單地說它僅驗證狀態轉移。相反,附加到區塊中的證明必須同時驗證多個方面:

  1. 前一區塊的狀態根 = S,下一區塊的狀態根 = S + 1
  2. 區塊哈希 = H

具體驗證內容

  • 區塊本身的有效性:區塊本身必須是有效的,同時其中的狀態證明——無論是 Verkle 證明還是 STARK 證明——必須準確驗證與區塊相關的數據。
  • 狀態轉移的驗證:當 STF 使用執行所需的數據,並在對應於 H 的區塊中執行時,狀態中應該改變的數據必須正確更新。
  • 樹的構建過程驗證:當用正確更新的數據重建新的狀態樹時,其根值必須與 S + 1 相符。

證明者與驗證者的平衡

在前面提到的 Prover-Verifier 比喻中,通常來說,證明者和驗證者之間會有一定的計算平衡。雖然生成證明所需要的多重驗證機制為驗證者提供了巨大的優勢,但這也意味著生成這些證明以確保執行正確性,對於證明者來說會相對具有挑戰性。目前,以太坊的區塊需要在 4 秒內證明。然而,即使是我們今天最快的 EVM 證明者,也只能在大約 15 秒內證明一個平均區塊【1】。

三種解決路徑

為了克服這一主要挑戰,有三條不同的路徑可以選擇:

  1. 證明並行化與聚合:ZK-證明的一個顯著優勢是它們可以進行聚合。將多個證明合併為一個緊湊的證明,顯著提高了處理效率。這不僅減輕了網絡負載,還加速了去中心化環境下的驗證過程。對於像以太坊這樣的龐大網絡來說,它能夠更高效地為每個區塊生成證明。

在生成證明的過程中,執行過程中的每個小步驟(例如計算步驟或數據訪問)都可以單獨進行證明,這些證明隨後可以聚合成一個單一的結構。通過正確的機制,這種方法使得區塊的證明可以由許多不同的來源(例如數百個 GPU)快速生成並去中心化地處理。這不僅提高了性能,同時也有助於去中心化目標的實現,通過吸引更多的參與者。

使用優化的證明系統

新一代的證明系統有潛力使以太坊的計算過程更快速、更高效。像 Orion、Binius 和 GKR 這樣的先進系統可以顯著減少通用計算的證明時間。這些系統旨在克服當前技術的侷限性,提高處理速度並消耗更少的資源。對於一個以可擴展性和效率為核心的網絡來說,類似的優化提供了巨大的優勢。然而,完全實現這些新系統需要在生態系統內進行廣泛的測試和兼容性努力。

Gas費用的變化

在以太坊虛擬機(EVM)上執行操作時,歷史上Gas費用通常是基於計算成本來決定的。然而,現在,另一個指標開始變得更為重要:證明覆雜性。儘管某些操作相對容易證明,但其他操作則結構更為複雜,需要更長時間才能驗證。根據操作的計算工作量和證明難度來調整Gas費用,對於提高網絡的安全性和效率至關重要。

這種方法能夠最小化最壞情況和平均情況之間的差距,從而實現更加一致的性能。例如,較難證明的操作可能需要更高的Gas費用,而較容易證明的操作則可以降低費用。此外,用適應 STARK 的替代數據結構(如狀態樹或交易列表)替代以太坊現有的數據結構,還可以進一步加速證明過程。這些變化將有助於以太坊實現其可擴展性和安全性目標,同時使其可驗證性的願景更為現實。

以太坊推動執行證明的努力代表了實現其可驗證性目標的重要機會。然而,達成這一目標不僅需要技術創新,還需要增加工程方面的努力,並做出社區內部的關鍵決策。在 Layer 1 上使執行過程可驗證,必須在確保廣泛用戶群體可訪問的同時,保持去中心化並與現有基礎設施保持一致。建立這種平衡增加了在執行過程中證明操作的方式的複雜性,這凸顯了諸如並行證明生成等技術進展的必要性。此外,這些技術的基礎設施要求(例如查找表)必須實現並投入使用,這仍然需要大量的研究和開發工作。

另一方面,專用電路(如 ASIC、FPGA、GPU)專門為某些任務設計,具有顯著加速證明生成過程的潛力。這些解決方案比傳統硬件提供更高的效率,並且能夠加速執行過程。然而,以太坊在 Layer 1 級別的去中心化目標使得這些硬件不應僅僅對少數幾方可用。因此,這些解決方案預計將在 Layer 2 系統中得到更廣泛的應用。然而,社區也需要就證明生成的硬件要求達成共識。一大設計問題是:證明生成是否應該在像高端筆記本電腦這樣的消費級硬件上進行,還是需要工業級基礎設施?這一問題的答案將決定以太坊的整體架構——即在 Layer 2 解決方案上進行激進的優化,同時在 Layer 1 上採取更為保守的方式。

最後,執行證明的實現直接關係到以太坊其他路線圖目標的實現。引入有效性證明不僅支持 無狀態化 等概念,還通過使單獨質押等領域更具可訪問性,增強以太坊的去中心化目標。目標是使得即使是最低規格的設備也能參與質押。此外,基於計算難度和可證明性的重構 EVM 的Gas費用,可以縮小平均情況和最壞情況之間的差距。然而,這種變化可能會打破與當前系統的向後兼容性,並迫使開發者重寫代碼。因此,執行證明的實施不僅是一個技術挑戰——它是一個必須設計來保持以太坊長期價值的過程。

最後一步:實現完全可驗證性的共識機制

以太坊的共識機制致力於在保持去中心化和可訪問性的同時,實現可驗證性的目標。在這個框架下,概率共識和確定性共識方法各有不同的優勢和挑戰。

概率共識

概率共識基於一種傳播式的通信模型。在這種模型中,節點並不會直接與代表網絡的所有節點通信,而是與隨機選擇的一組64或128個節點共享信息。節點的鏈選擇基於這些有限的信息,這就引入了錯誤的可能性。然而,隨著區塊鏈的推進,這些選擇預計會逐漸收斂到正確的鏈上,錯誤率最終接近0%。

概率共識結構的一個優勢是,每個節點並不會將自己的鏈視圖作為單獨的信息進行廣播,從而減少了通信開銷。因此,這種結構能夠支持更多的、權限開放的去中心化節點,並且系統要求較低。

確定性共識

與概率共識不同,確定性共識通過“一對多”的通信模型來運作。在這種模型中,節點將其鏈視圖作為投票發送給其他所有節點。這種方法會產生更高的消息密度,隨著節點數量的增長,系統可能最終達到其限制。然而,確定性共識的最大優勢在於具體的投票機制,使得可以準確知道哪些節點投票支持了哪個分叉。這確保了鏈的快速和確定性最終性,保證了區塊的順序無法改變,並使其可驗證。

以太坊的共識機制平衡

為了在保持去中心化和開放結構的同時提供可驗證的共識機制,以太坊在 插槽紀元(Epochs)之間達成了一種平衡。

  1. 插槽(Slot):插槽是每12秒一個時間間隔,在該時間間隔內,驗證者負責生成一個區塊。儘管在插槽級別使用的概率共識讓區塊鏈能夠更靈活、去中心化地運行,但在確定順序和可驗證性方面仍然存在一些侷限性。
  2. 紀元(Epoch):一個紀元由32個插槽組成,在這個層次上,驗證者投票決定最終區塊鏈的順序,確保了鏈的確定性並使其可驗證。然而,儘管這個確定性結構在紀元級別通過具體的投票提供了可驗證性,它由於概率結構的存在,無法在紀元內部提供完全的可驗證性。
Sync Committee:加強紀元內的可驗證性

為了彌補這一差距並增強紀元內的概率結構,以太坊開發瞭解決方案——同步委員會(Sync Committee)。同步委員會旨在提高概率共識在紀元內的可驗證性,確保區塊的最終確定性和順序不受影響,同時維持去中心化和開放性。

通過將概率共識和確定性共識相結合,並通過同步委員會來進一步增強紀元內的驗證能力,以太坊在實現去中心化的同時,確保了其可擴展性和可驗證性的目標。這種混合共識機制為以太坊的長期可持續性和去中心化打下了堅實的基礎,併為網絡上的參與者提供了更高的安全性和靈活性。

共識的零知識證明化

The Verge旨在通過採用零知識證明技術(zk-proof)增強以太坊當前和未來的共識機制,而不是完全替代它們。此舉旨在在保留去中心化和安全性核心原則的同時,現代化以太坊的共識流程。通過零知識技術優化以太坊鏈的所有歷史和當前共識過程,對實現以太坊長期可擴展性和效率目標至關重要。以太坊共識層使用的基本操作在這一技術轉型中發揮著重要作用。接下來,讓我們更深入地探討這些操作及其所面臨的挑戰。

ECADD 操作:

  • 目的:該操作用於聚合驗證者的公鑰,對於確保鏈的準確性和高效性至關重要。得益於BLS簽名的可聚合特性,多個簽名可以合併為一個結構,這減少了通信開銷,使鏈上的驗證過程更加高效。有效地確保大型驗證者群體的同步,使得這一操作顯得尤為關鍵。
  • 挑戰:如前所述,以太坊的驗證者在紀元期間對鏈的順序進行投票。如今,以太坊網絡大約有110萬個驗證者。如果所有驗證者試圖同時傳播他們的投票,將會對網絡造成極大壓力。為了避免這種情況,以太坊允許驗證者在每個紀元內按槽位投票,每個槽位僅有1/32的驗證者進行投票。儘管這種機制減少了網絡通信的開銷,並提高了共識效率,但鑑於目前的驗證者數量,每個槽位大約有34,000個驗證者進行投票,這意味著每個槽位大約需要進行34,000次ECADD操作。

配對操作(Pairings):

  • 目的:配對操作用於驗證BLS簽名,確保鏈上紀元的有效性。該操作允許批量驗證簽名,但它不支持zk-friendly(零知識證明友好),使得使用zk-proof技術進行證明時非常昂貴。這在創建集成的零知識驗證流程時構成了一個主要挑戰。
  • 挑戰:以太坊中的配對操作每個槽位最多限於128個認證(聚合簽名),因此相較於ECADD操作,配對操作的數量較少。然而,這些操作不支持zk-proof,導致它們在zk-proof系統中的成本極高。證明一個配對操作的零知識證明比證明一個ECADD操作的成本要高出數千倍。這使得配對操作在零知識技術中的適配成為以太坊共識驗證流程中最大的障礙之一。

SHA256 哈希函數:

  • 目的:SHA256哈希函數用於讀取和更新鏈的狀態,確保鏈數據的完整性。然而,它們不支持zk-proof,這導致在基於零知識證明的驗證過程中效率低下,成為以太坊未來可驗證性目標的主要障礙。
  • 挑戰:SHA256哈希函數經常用於讀取和更新鏈的狀態。然而,它們的zk-unfriendliness(不支持零知識證明)與以太坊基於zk-proof的驗證目標相沖突。例如,在兩個紀元之間,每個驗證者都需要運行以太坊共識層的狀態轉換函數(STF)來更新狀態,計算獎勵和懲罰,這基於驗證者在該紀元內的表現。此過程嚴重依賴SHA256哈希函數,極大地增加了基於zk-proof系統的成本。這為將以太坊的共識機制與zk技術對接,提供了巨大的挑戰。

當前共識層使用的ECADD、配對和SHA256操作在以太坊的可驗證性目標中扮演著關鍵角色。然而,它們的zk-unfriendliness(不支持零知識證明)在實現這些目標的過程中帶來了顯著挑戰。ECADD操作由於驗證者投票量龐大,給網絡帶來了昂貴的負擔,而配對操作雖然數量較少,但使用zk-proof證明時卻比ECADD操作貴數千倍。此外,SHA256哈希函數的不支持zk-proof使得證明信標鏈的狀態轉換變得異常困難。這些問題凸顯了以太坊需要進行全面轉型,以將現有基礎設施與零知識技術對接。

解決方案“Beam Chain”:重新構想以太坊的共識層

2024年11月12日,Justin Drake在Devcon的演講中提出了一個名為“Beam Chain”的提案,旨在從根本上和全面地改造以太坊的共識層。信標鏈(Beacon Chain)已經在以太坊網絡的核心運行近五年。然而,在此期間,信標鏈沒有經歷任何重大的結構性變化。與此相對的是,技術進展迅速,遠遠超過了信標鏈的靜態特性。

在演講中,Justin Drake強調,以太坊在過去五年中在多個關鍵領域獲得了重要的經驗教訓,包括MEV(最大化可提取價值)理解、SNARK(簡潔非交互式論證)技術的突破以及對過去技術錯誤的回顧性認知。基於這些新收穫的知識,設計方案被歸納為三個主要支柱:區塊生產、質押和加密學。以下圖表總結了這些設計和提案的路線圖:

綠色和灰色框表示逐步實施的漸進性發展,可以每年逐一實現。這些改進類似於之前的升級,可以逐步集成而不干擾以太坊現有的架構。

另一方面,紅色框表示高協同效應、大規模和基礎性的變革,必須一起實施。根據Drake的說法,這些變化旨在通過一次重大的飛躍提升以太坊的能力和可驗證性。

在本節中,我們詳細討論了The Verge的共識、狀態和執行步驟,其中一個突出的問題是以太坊信標鏈中使用的SHA256哈希函數。雖然SHA256在確保網絡安全和處理交易方面發揮著核心作用,但其缺乏對zk技術友好的特性,成為實現以太坊可驗證性目標的重大障礙。其高計算成本和與zk技術的不兼容性,使其成為必須在未來以太坊發展中解決的關鍵問題。

Justin Drake在Devcon演講中提出的路線圖設想用zk友好的哈希函數(如Poseidon)取代信標鏈中的SHA256。該提案旨在使以太坊的共識層現代化,使其更具可驗證性、更高效,並與zk-proof技術對接。

在這種背景下,我們看到以太坊不僅面臨著與zk不友好哈希函數相關的挑戰,還需要重新評估其共識層中使用的數字簽名,以確保長期的安全性。隨著量子計算的發展,目前使用的數字簽名算法(如ECDSA)可能面臨重大威脅。正如NIST發佈的指南所指出,具有112位安全級別的ECDSA變種將在2030年逐步淘汰,並於2035年完全禁用。這迫使以太坊和類似網絡必須朝著更加具有抗量子能力的替代方案過渡,例如量子安全的簽名。

此時,基於哈希的簽名作為抗量子解決方案浮現,它們將在支持網絡的安全性和可驗證性目標方面發揮關鍵作用。解決這一問題還消除了使信標鏈可驗證的第二大障礙:BLS簽名。以太坊在確保量子安全方面可以採取的最重要步驟之一是採用後量子解決方案,如基於哈希的簽名和基於哈希的SNARKs。

正如Justin Drake在Devcon演講中強調的,哈希函數由於依賴於預像抗性,本質上是抗量子計算的,使它們成為現代密碼學的基礎構件之一。這一特性確保即使是量子計算機也無法有效地從給定的哈希值反推原始輸入,從而保持其安全性。基於哈希的簽名系統允許驗證者和見證者僅基於哈希函數生成簽名,確保後量子安全性,同時提供更高的網絡可驗證性——尤其是在使用SNARK友好的哈希函數時。這種方法不僅提升了網絡的安全性,還使以太坊的長期安全基礎設施變得更加穩健,具備未來-proof能力。

這個系統依賴於將基於哈希的簽名和基於哈希的SNARK(類似STARK的證明)結合,創建可聚合的簽名方案。可聚合簽名將成千上萬的簽名壓縮為一個結構,將其減少到僅幾百千字節的證明。這種壓縮顯著減少了網絡上的數據負載,同時大大加速了驗證過程。例如,以太坊中為一個單一槽產生的成千上萬的驗證者簽名可以通過一個聚合簽名來表示,從而節省存儲空間和計算能力。

然而,這個方案最顯著的特點是它的無限遞歸聚合。也就是說,一組簽名可以在另一組簽名下進一步結合,並且這一過程可以在鏈上繼續進行。藉助這一機制,並考慮到未來的技術進展,可以公平地說,這為目前BLS無法實現的可能性打開了大門。

最終思考與結論

以太坊的可驗證性之路代表了區塊鏈技術的根本轉變。The Verge倡議通過使用Verkle樹進行狀態驗證以及使用STARK證明進行可擴展過渡,解決了核心的低效問題。

其中最雄心勃勃的提案之一是Beam Chain,這是一項對以太坊共識層的全面重設計。通過解決信標鏈的侷限性,並引入zk友好的替代方案,這一方法旨在提升以太坊的可擴展性,同時保持其去中心化和可訪問性的核心原則。然而,這一過渡也凸顯了以太坊在平衡計算需求與保持一個無需許可、包容性網絡的目標時所面臨的挑戰。

隨著NIST計劃到2035年淘汰當前的橢圓曲線加密算法,以太坊必須採納像基於哈希的簽名和Poseidon這樣的抗量子解決方案。這些解決方案也有其效率上的權衡。

STARKs在以太坊路線圖中的使用進一步強調了可擴展性和可驗證性。雖然它們在提供透明且抗量子的證明方面表現出色,但它們的整合帶來了與證明方計算成本和小數據效率相關的挑戰。必須解決這些難題,才能充分實現以太坊的無狀態化和高效塊驗證願景,確保網絡在需求日益增長的情況下依然保持穩健。

儘管有這些進展,仍然存在一些關鍵挑戰。以太坊必須應對zk友好性、共識可擴展性和整合抗量子加密技術的複雜性問題。此外,現有基礎設施的向後兼容性也提出了實際障礙,這需要精心的工程解決方案,以防止對開發者和用戶造成干擾。

讓以太坊與眾不同的,不僅僅是它的技術創新,還有它解決區塊鏈難題的漸進方法。未來的道路——無論是通過Beam Chain、Verkle樹還是STARK證明——都依賴於開發者、研究人員和更廣泛社區的合作努力。這些進展不是一蹴而就的,而是為創建一個透明、去中心化和可驗證的互聯網奠定基礎。

以太坊的演變凸顯了它在塑造Web3時代中的關鍵角色。通過用實際的解決方案應對當今的挑戰,以太坊正朝著一個可驗證性、抗量子性和可擴展性成為標準而非例外的未來邁進。

免責聲明:

  1. 本文轉載自【2077 Research】,所有版權歸原作者【Koray Akpinarr】所有。如對轉載有異議,請聯繫 Gate Learn 團隊,他們會及時處理。
  2. 免責申明:本文中所表達的觀點和意見僅代表作者本人,並不構成任何投資建議。
  3. 本文的翻譯版本由 Gate Learn 團隊完成。除非特別註明,禁止複製、分發或抄襲翻譯文章。
即刻開始交易
註冊並交易即可獲得
$100
和價值
$5500
理財體驗金獎勵!
It seems that you are attempting to access our services from a Restricted Location where Gate.io is unable to provide services. We apologize for any inconvenience this may cause. Currently, the Restricted Locations include but not limited to: the United States of America, Canada, Cambodia, Cuba, Iran, North Korea and so on. For more information regarding the Restricted Locations, please refer to the User Agreement. Should you have any other questions, please contact our Customer Support Team.