原文標題:《Possible futures of the Ethereum protocol, part 6: The Splurge》
原文作者:@VitalikButerin
原文編譯:zhouzhou,BlockBeats
以下為原文內容(為便於閱讀理解,原內容有所整編):
有些事物很難歸入單一類別,在以太坊協議設計中,有許多「細節」對以太坊的成功非常重要。實際上,約一半的內容涉及不同類型的 EVM 改進,其餘部分則由各種小眾主題構成,這就是「繁榮」的意義所在。
2023 年路線圖:繁榮
繁榮:關鍵目標
將EVM 變成高性能和穩定的「最終狀態」 p>
將帳戶抽象化引入協議,讓所有用戶享受更安全和便捷的帳戶
優化交易費用經濟,提高可擴展性同時降低風險
探索先進的密碼學,使以太坊在長期內顯著改善
本章內容
解決了什麼問題?
目前的 EVM 難以進行靜態分析,這使得建立高效實作、正式驗證程式碼和進行進一步擴展變得困難。此外,EVM 的效率較低,難以實現許多形式的高階密碼學,除非透過預編譯明確支援。
它是什麼,如何運作?
目前 EVM 改進路線圖的第一步是 EVM 物件格式(EOF),計劃在下一個硬分叉中納入。 EOF 是一系列EIP,指定了一個新的EVM 程式碼版本,具有許多獨特的特徵,最顯著的是:
·程式碼(可執行,但無法從EVM 讀取)與資料(可讀取,但無法執行)之間的分離
·禁止動態跳轉,僅允許靜態跳轉
·EVM 程式碼無法再觀察與燃料相關的資訊
·新增了一個新的顯式子程式機制
EOF 程式碼的結構
舊式合約將繼續存在並可創建,儘管最終可能會逐步棄用舊式合約(甚至可能強制轉換為EOF代碼)。新式合約將受益於 EOF 帶來的效率提升——首先是透過子程式特性稍微縮小的字節碼,隨後則是 EOF 特定的新功能或減少的 gas 成本。
在引入EOF 後,進一步的升級變得更加容易,目前發展最完善的是EVM 模組算術擴充(EVM-MAX)。 EVM-MAX 創建了一組專門針對模運算的新操作,並將其放置在一個無法透過其他操作碼存取的新記憶體空間中,這使得使用諸如 Montgomery 乘法等最佳化成為可能。
一個較新的想法是將EVM-MAX 與單指令多資料(SIMD)特性結合,SIMD 作為以太坊的一個理念已經存在很長時間,最早由Greg Colvin 的EIP-616 提出。 SIMD 可用於加速許多形式的密碼學,包括雜湊函數、32 位元 STARKs 和基於格的密碼學,EVM-MAX 和 SIMD 的結合使得這兩種效能導向的擴展成為自然的配對。
一個組合EIP 的大致設計將以EIP-6690 為起點,然後:
·允許(i) 任何奇數或(ii) 任何最高為2768 的2 的冪作為模數
·對於每個EVM-MAX 操作碼(加法、減法、乘法),增加一個版本,不再使用3 個立即數x、y、z,而是使用7 個立即數:x_start、x_skip、y_start、y_skip、z_start、 z_skip、count。 在Python 程式碼中,這些操作碼的作用類似:
·for i in range(count):
mem[z_start + z_skip * count] = op(
mem[x_start + x_skip * count],
mem[y_start + y_skip * count]
)
實際實作中,這將以並行方式處理。
·可能會增加 XOR、AND、OR、NOT 和 SHIFT(包括循環和非循環),至少對於 2 的冪模數。同時添加ISZERO(將輸出推送到EVM 主堆疊),這將足夠強大以實現橢圓曲線密碼學、小域密碼學(如Poseidon、Circle STARKs)、傳統雜湊函數(如SHA256、KECCAK、BLAKE)和基於格的密碼學。其他 EVM 升級也可能實現,但迄今為止關注度較低。
EOF: https://evmobjectformat.org/
EVM-MAX: https://eips.ethereum.org/EIPS/eip-6690 a>
SIMD: https://eips.ethereum.org/EIPS/eip -616
目前,EOF 計劃在下一個硬分叉中納入。儘管總是有可能在最後一刻移除它——之前的硬分叉中曾有功能被暫時移除,但這樣做將面臨很大挑戰。移除 EOF 意味著未來對 EVM 的任何升級都需要在沒有 EOF 的情況下進行,雖然可以做到,但可能更困難。
EVM 的主要權衡在於 L1 複雜度與基礎設施複雜性,EOF 是需要添加到 EVM 實作中的大量程式碼,靜態程式碼檢查也相對複雜。然而,作為交換,我們可以簡化高階語言、簡化 EVM 實作以及其他好處。可以說,優先考慮以太坊 L1 持續改善的路線圖應包括並建立在 EOF 之上。
需要做的一項重要工作是實現類似 EVM-MAX 加 SIMD 的功能,並對各種加密操作的 gas 消耗進行基準測試。
L1 調整其EVM 使得L2 也能更容易進行相應調整,如果二者不進行同步調整,可能會造成不相容,帶來不利影響。此外,EVM-MAX 和 SIMD 可以降低許多證明系統的 gas 成本,從而使 L2 更有效率。它也使得透過用可以執行相同任務的 EVM 程式碼取代更多的預編譯變得更加容易,可能不會大幅影響效率。
解決了什麼問題?
目前,交易只能透過一種方式進行驗證:ECDSA 簽署。最初,帳戶抽象化旨在超越這一點,允許帳戶的驗證邏輯為任意的 EVM 程式碼。 這可以啟用一系列應用:
·切換到抗量子密碼學
·輪換舊密鑰(廣泛被認為是推薦的安全實踐)
·多重簽名錢包和社交恢復錢包
·使用一個密鑰進行低價值操作,使用另一個密鑰(或一組密鑰)進行高價值操作 p>
允許隱私協定在沒有中繼的情況下工作,顯著降低其複雜性,並消除一個關鍵的中央依賴點
自2015年帳戶抽象化提出以來,其目標也擴展到了包括大量「便利目標」,例如,某個沒有ETH 但擁有一些ERC20 的帳戶能夠用ERC20 支付gas。 以下是這些目標的總表:
MPC(多方計算)是一種已有 40 年歷史的技術,用於將金鑰分成多個部分並儲存在多個裝置上,利用密碼學技術產生簽名,而無需直接組合這些金鑰部分。
EIP-7702 是計劃在下一個硬分叉中引入的一項提案,EIP-7702 是對提供帳戶抽象便利性以惠及所有用戶(包括EOA 用戶)的日益認識的結果,旨在在短期內改善所有用戶的體驗,並避免分裂成兩個生態系。
工作始於 EIP-3074 ,並最終形成EIP-7702。 EIP-7702 將帳戶抽象的「便利功能」提供給所有用戶,包括今天的 EOA(外部擁有帳戶,即受 ECDSA 簽名控制的帳戶)。
從圖表中可以看到,雖然一些挑戰(尤其是“便利性”挑戰)可以透過漸進技術如多方計算或EIP-7702 解決,但最初提出帳戶抽象提案的主要安全目標只能透過回溯並解決原始問題來實現:允許智慧合約代碼控制交易驗證。迄今尚未實現的原因在於安全地實施,這一點是一項挑戰。
帳戶抽象的核心是簡單的:允許智能合約發起交易,而不僅僅是 EOA。整個複雜性來自於以一種對維護去中心化網路友善的方式實現這一點,並防範拒絕服務攻擊。
一個典型的關鍵挑戰是多重破壞問題:
如果有1000 個帳戶的驗證函數都依賴某個單一值S,且目前值S使得記憶體池中的交易都是有效的,那麼有單一交易翻轉S 的值可能會使記憶體池中的所有其他交易失效。這使得攻擊者能夠以極低的成本向記憶體池發送垃圾交易,從而堵塞網路節點的資源。
經過多年的努力,旨在擴展功能的同時限制拒絕服務(DoS)風險,最終得出了實現“理想帳戶抽象”的解決方案: ERC-4337。
ERC-4337 的工作原理是將使用者操作的處理分為兩個階段:驗證和執行。所有驗證首先被處理,所有執行隨後被處理。在記憶體池中,只有當使用者操作的驗證階段只涉及其自身帳戶且不讀取環境變數時,才會被接受。這可以防止多重失效攻擊。此外,對驗證步驟也強制實施嚴格的 gas 限制。
ERC-4337 被設計為一種額外協議標準(ERC),因為在當時以太坊客戶端開發者專注於合併(Merge),沒有額外的精力來處理其他功能。這就是為什麼 ERC-4337 使用了名為用戶操作的對象,而不是常規交易。然而,最近我們意識到需要將其中至少部分內容寫入協議中。
兩個關鍵原因如下:
1.EntryPoint 作為合約的固有低效性:每個捆綁約有 100,000 gas 的固定開銷,以及每個使用者操作額外的數千 gas。
2. 確保以太坊屬性的必要性:如包含清單所建立的包含保證需要轉移到帳戶抽象使用者。
此外,ERC-4337 也擴充了兩個功能:
·支付代理(Paymasters):允許一個帳戶代表另一個帳戶支付費用的功能,這違反了驗證階段只能存取發送者帳戶本身的規則,因此引入了特殊處理以確保支付代理機制的安全性。
·聚合器(Aggregators):支援簽章聚合的功能,如 BLS 聚合或基於 SNARK 的聚合。這對於在 Rollup 上實現最高的資料效率是必要的。
關於帳戶抽象歷史的演講:https://www.youtube.com/watch?v=iLf8qpOmxQc
ERC-4337 :https://eips.ethereum.org/EIPS/eip-4337
EIP-7702:https://eips.ethereum.org/EIPS/eip-7702
BLSWallet 程式碼(使用聚合功能):https://github.com/getwax/bls-wallet
EIP-7562(寫入協議的帳戶抽象):https://eips.ethereum.org/EIPS/eip-7562
EIP-7701(基於EOF 的寫入協議帳戶抽象):https://eips.ethereum .org/EIPS/eip-7701
目前主要需要解決的是如何將帳戶抽象完全引入協議,最近受到歡迎的寫入協議帳戶抽象EIP 是 EIP-7701,提案在EOF 之上實現帳戶抽象。一個帳戶可以擁有一個單獨的代碼部分用於驗證,如果帳戶設定了該代碼部分,則該代碼將在來自該帳戶的交易的驗證步驟中執行。
這種方法的迷人之處在於,它清晰地表明了本地帳戶抽象的兩種等效視角:
1. 將EIP-4337 作為協議的一部分
2. 一種新的EOA 類型,其中簽名演算法為EVM 程式碼執行
如果我們從對驗證期間可執行程式碼複雜度設定嚴格界線開始——不允許存取外部狀態,甚至在初期設定的gas 限制也低到對量子抗性或隱私保護應用無效——那麼這種方法的安全性就非常明確:只是將ECDSA 驗證替換為需要相似時間的EVM 程式碼執行。
然而,隨著時間的推移,我們需要放寬這些界限,因為允許隱私保護應用在沒有中繼的情況下工作,以及量子抗性都是非常重要的。為此,我們需要找到更靈活地解決拒絕服務(DoS)風險的方法,而不要求驗證步驟必須極度簡約。
主要的權衡似乎是「快速寫入一個讓較少人滿意的方案」與「等待更長時間,可能獲得更理想的解決方案」,理想的方法可能是某種混合方法。一種混合方法是更快地寫入一些用例,並留出更多時間來探索其他用例。另一種方法是在 L2 上首先部署更雄心勃勃的帳戶抽象版本。然而,這面臨的挑戰是,L2 團隊需要對採用提案的工作充滿信心,才能願意實施,尤其是確保 L1 和/或其他 L2 未來能夠採用相容的方案。
我們還需要明確考慮的另一個應用是密鑰儲存帳戶,這些帳戶在L1 或專用L2 上儲存帳戶相關狀態,但可以在L1 和任何相容的L2 上使用。有效地做到這一點可能要求L2 支持諸如L1SLOAD 或REMOTESTATICCALL 的操作碼,但這也需要L2 上的帳戶抽象實現支持這些操作。
包含清單需要支援帳戶抽象交易,在實踐中,包含清單的需求與去中心化記憶體池的需求實際上非常相似,儘管對於包含列表來說彈性稍大。此外,帳戶抽象實作應該盡可能在 L1 和 L2 之間實現協調。如果將來我們期望大多數使用者使用金鑰儲存 Rollup,帳戶抽象設計應以此為基礎。
它解決了什麼問題?
EIP-1559 於 2021 年在以太坊上激活,顯著改善了平均區塊包含時間。
等待時間
然而,目前 EIP-1559 的實作在許多方面並不完美:
1. 公式略有缺陷:它並不是以50% 的區塊為目標,而是針對約50-53% 的滿區塊,這取決於變異數(這與數學家所稱的「算術-幾何均值不等式」有關)。
2. 在極端情況下調整不夠迅速。
後面用於 blobs 的公式(EIP-4844)是專門設計來解決第一個問題的,整體上也更簡潔。然而,EIP-1559 本身以及 EIP-4844 都未嘗試解決第二個問題。因此,現狀是一個混亂的中間狀態,涉及兩種不同的機制,有一種觀點認為,隨著時間的推移,兩者都需要進行改進。
此外,還有其他與 EIP-1559 無關的以太坊資源定價的弱點,但可以透過對 EIP-1559 的調整來解決。其中一個主要問題是平均情況與最壞情況的差異:以太坊中的資源價格必須設定得能夠處理最壞情況,即一個區塊的全部gas 消耗佔用一個資源,但實際的平均使用遠低於此,導致了低效率。
什麼是多維Gas,它是如何運作的?
解決這些低效問題的方案是多維Gas:為不同資源設定不同的價格和限制。這個概念在技術上獨立於 EIP-1559,但 EIP-1559 的存在使得實現這一方案更容易。如果沒有EIP-1559,最優地打包一個包含多種資源約束的區塊就是一個複雜的多維背包問題。而有了 EIP-1559,大多數區塊在任何資源上都不會達到滿載,因此「接受任何支付足夠費用的交易」這樣簡單的演算法就足夠了。
目前我們已經有了用於執行和資料區塊的多維Gas;原則上,我們可以將其擴展到更多維度:如calldata(交易數據),狀態讀取/寫入,和狀態大小擴展。
EIP-7706 引入了一種新的 gas 維度,專門針對 calldata。同時,它也透過將三種類型的 gas 統一到一個(EIP-4844 風格的)框架中,簡化了多維 Gas 機制,從而也解決了 EIP-1559 的數學缺陷。 EIP-7623 是一種更精準的解決方案,針對平均情況與最壞情況的資源問題,更嚴格地限制最大calldata,而不引入整個新維度。
一個進一步的研究方向是解決更新速率問題,尋找一種更快速的基礎費用計算演算法,同時保留EIP-4844 機制所引入的關鍵不變數(即:在長期內,平均使用量剛好接近目標值)。
EIP-1559 FAQ: EIP-1559 FAQ
關於EIP-1559 的實證分析: Empirical analysis
允許快速調整的改進提案: Proposed improve.關於基礎費用機制的部分: EIP-4844 FAQ
EIP-7706: EIP-7706
EIP-7623 : EIP-7623
多維Gas: Multidimensional gas
多維Gas 的主要權衡有兩個:
1. 增加協議複雜性:引入多維Gas會使協議變得更複雜。
2. 增加填充區塊所需的最優演算法複雜性:為了使區塊達到容量的最佳演算法也會變得複雜。
協定複雜性對於calldata 來說相對較小,但對於那些在EVM 內部的Gas 維度(如儲存讀取和寫入)來說,複雜性就會增加。問題在於,不僅使用者設定 gas 限制,合約在呼叫其他合約時也會設定限制。而目前,它們設定限制的唯一方式是單維的。
一個簡單的解決方案是將多維 Gas 僅在 EOF 內部可用,因為 EOF 不允許合約在調用其他合約時設定 gas 限制。非 EOF 合約在進行儲存作業時需要支付所有類型 Gas 的費用(例如,如果 SLOAD 佔用區塊儲存存取 gas 限制的 0.03%,那麼非 EOF 用戶也會被收取 0.03% 的執行 gas 限制費用)。
對多維 Gas 進行更多研究將有助於理解這些權衡,並找到理想的平衡點。
成功實施多維 Gas 可以大幅降低某些「最壞情況」的資源使用,從而減少優化效能的壓力,以支援例如 STARKed 哈希基礎的二元樹等需求。對於狀態大小成長設定一個明確的目標,將使客戶端開發者在未來進行規劃和需求估算變得更加容易。
如前所述,EOF 的存在使得實現更極端版本的多維 Gas 變得更加簡單,因為其 Gas 不可觀察的特性。
它解決了什麼問題?
目前,以太坊使用基於RANDAO 的隨機性來選擇提議者,RANDAO 的隨機性是透過要求每個提議者揭示他們提前承諾的秘密,並將每個揭示的秘密混合到隨機性中來工作的。
每個提議者因此有「1 位元操控權」:他們可以透過不出現來改變隨機性(有成本)。這種方式對於尋找提議者來說是合理的,因為你放棄一個機會而獲得兩個新提議機會的情況非常少見。但對於需要隨機性的鏈上應用程式來說,這並不理想。理想情況下,我們應該找到一個更穩健的隨機性來源。
什麼是 VDF,它是如何運作的?
可驗證延遲函數是一種只能順序計算的函數,無法透過並行化加速。一個簡單的例子是重複雜湊:for i in range(10**9): x = hash(x)。輸出結果,使用 SNARK 證明其正確性,可用作隨機值。
這個思路是輸入基於時間T 可用的信息進行選擇,而在時間T 時輸出尚不可知:輸出只有在某人完全運行計算後才會在T 之後的某個時刻可用。因為任何人都可以運行計算,所以不存在隱藏結果的可能性,因此也沒有操控結果的能力。
可驗證延遲函數的主要風險是意外優化:有人發現以比預期更快的速度運行該函數,從而操控他們在時間T 揭示的信息。
意外最佳化可以透過兩種方式發生:
1. 硬體加速:有人製造出比現有硬體更快運行運算循環的ASIC。
2. 意外並行化:有人找到一種方法,透過並行化運行函數以更快的速度,即使這樣做需要 100 倍的資源。
創建成功的VDF 的任務是避免這兩種問題,同時保持效率實用(例如,基於哈希的方法一個問題是實時對哈希進行SNARK 證明需要重型硬體)。硬體加速通常透過一個公共利益參與者自行創建和分發接近最佳的 VDF ASIC 來解決。
VDF 研究網站: vdfresearch.org
關於以太坊中VDF 的攻擊思考,2018 年: Thinking on attacks
針對提議的VDF MinRoot 的攻擊: Attacks against MinRoot
目前,沒有一種 VDF 構造能夠完全滿足以太坊研究者在所有方面的要求。仍需更多工作來尋找這樣的函數。如果找到了,主要的權衡就是是否將其納入:功能性與協議複雜性及安全風險之間的簡單權衡。
如果我們認為VDF 是安全的,但最終它卻不安全,則根據其實現方式,安全性將退化到RANDAO 假設(每個攻擊者1 位操控權)或稍微糟糕的情況。因此,即使 VDF 失效,也不會破壞協議,但會破壞強烈依賴它的應用程式或任何新協議特性。
VDF 是以太坊協議中相對自包含的一個組成部分,除了增加提議者選擇的安全性外,它在(i)依賴隨機性的鏈上應用程序以及(ii )加密記憶體池中也有應用,儘管基於VDF 製作加密記憶體池仍依賴尚未發生的額外密碼學發現。
一個需要記住的要點是,考慮到硬體的不確定性,VDF 輸出產生與需要之間會有一些「餘裕」。這意味著資訊將在幾個區塊之前可用。這可以是一個可接受的成本,但在單槽最終確定或委員會選擇設計中應該加以考慮。
它解決了什麼問題?
Nick Szabo 最著名的文章之一是他在 1997 年撰寫的關於「上帝協議」的論文。在這篇論文中,他指出,許多多方應用依賴「受信任的第三方」來管理互動。在他看來,密碼學的作用是創造一個模擬的受信任第三方,完成同樣的工作,但實際上並不需要對任何特定參與者的信任。
到目前為止,我們只能部分實現這一理想。如果我們所需的只是一個透明的虛擬計算機,其數據和計算無法被關閉、審查或篡改,而隱私並不是目標,那麼區塊鏈可以實現這個目標,儘管其可擴展性有限。
如果隱私是目標,那麼直到最近,我們只能針對特定應用開發一些具體的協定:用於基本驗證的數位簽章、用於原始匿名性的環簽名和可連結環簽名、基於身分的加密以在對可信任發行者的特定假設下實現更方便的加密、以及用於查姆式電子現金的盲簽名等等。這種方法要求為每個新應用進行大量工作。
在 2010 年代,我們首次瞥見了一種不同且更強大的方法,這種方法基於可程式密碼學。與其為每個新應用程式創建一個新協議,我們可以使用強大的新協議——具體來說是 ZK-SNARKs——為任意程式添加密碼學保證。
ZK-SNARKs 允許使用者證明他們持有的資料的任意聲明,且證明(i)易於驗證,且(ii)不會洩露除聲明本身之外的任何數據。這在隱私和可擴展性上都是一個巨大的進步,我將其比作人工智慧中的變換器(transformers)所帶來的影響。成千上萬的人年應用特定的工作,突然被這個通用解決方案所取代,這個解決方案能夠處理意想不到的廣泛問題。
然而,ZK-SNARKs 只是類似的三種極其強大的通用原語中的第一種。這些協議強大到當我想到它們時,它們讓我想起了一組在《遊戲王》中非常強大的卡片——我小時候玩過的卡片遊戲和電視節目:埃及神卡。
埃及神卡是三張極其強大的卡片,傳說中製造這些卡片的過程可能致命,並且它們的強大使得在決鬥中禁止使用。類似地,在密碼學中,我們也有這組三種埃及神協議:
ZK-SNARKs 是我們已經擁有的三種協定之一,具有較高的成熟度。在過去五年中,證明者速度和開發者友善性的大幅提升使得 ZK-SNARKs 成為以太坊可擴展性和隱私策略的基石。但 ZK-SNARKs 有一個重要的限制:你需要知道數據才能對其進行證明。每個 ZK-SNARK 應用程式中的狀態必須有一個唯一的「所有者」,他必須在場才能批准對該狀態的讀取或寫入。
第二種沒有這項限制的協定是完全同態加密(FHE),FHE 允許你在不檢視資料的情況下,對加密資料進行任何計算。這使得你能夠在用戶的數據上進行計算,以用戶的利益為出發點,同時保持數據和演算法的隱私。
它還使你能夠擴展如 MACI 等投票系統,以獲得幾乎完美的安全性和隱私保證。長期以來,FHE 被認為效率太低,無法實際使用,但現在它終於變得足夠高效,開始出現實際應用。
Cursive 是應用程序,利用雙方計算和完全同態加密(FHE)進行隱私保護的共同興趣發現。
然而,FHE 也有其局限性:任何基於 FHE 的技術仍然需要某人持有解密金鑰。這可以是一個 M-of-N 的分散式設置,你甚至可以使用可信任執行環境(TEEs)來增加第二層防護,但這仍然是一個限制。
接下來是第三種協議,它比前兩者的組合更為強大:不可區分混淆(indistinguishability obfuscation)。雖然這項技術距離成熟仍然很遠,但截至 2020 年,我們已基於標準安全假設獲得理論上有效的協議,最近也開始著手實現。
不可區分混淆允許你創建一個「加密程式」,執行任意計算,同時隱藏程式的所有內部細節。舉個簡單的例子,你可以將私鑰放入混淆程式中,這個程式只允許你用它來簽署素數,並將此程式分發給他人。他們可以使用這個程式簽署任何素數,但無法提取密鑰。然而,它的能力遠不止於此:結合哈希,它可以用來實現任何其他密碼學原語,以及更多功能。
不可區分混淆程式唯一不能做到的,就是防止自身被複製。不過,對於這一點,前景中還有更強大的技術在等待著,儘管它依賴於每個人都擁有量子計算機:量子一次性簽名(quantum one-shot signatures)。
藉由結合混淆和一次性簽名,我們可以建立幾乎完美的無信任第三方。唯一無法僅靠密碼學實現的目標,仍需要區塊鏈來保證的是審查抗性。這些技術不僅可以使以太坊本身更安全,還可以在其上建立更強大的應用。
為了更好地理解這些原語如何增加額外的能力,我們以投票為關鍵例子。投票是一個有趣的問題,因為它需要滿足許多複雜的安全屬性,包括非常強大的可驗證性和隱私性。雖然擁有強安全屬性的投票協議已經存在數十年,但我們可以自我加大難度,要求設計能夠處理任意投票協議:如二次投票、成對限制的二次資助、集群匹配的二次資助等等。換句話說,我們希望「計票」步驟成為一個任意程式。
首先,假設我們將投票結果公開放在區塊鏈上。這使我們獲得了公開可驗證性(任何人都可以驗證最終結果是否正確,包括計票規則和資格規則)和審查抗性(無法阻止人們投票)。但我們沒有隱私。
接著,我們增加了ZK-SNARKs,現在,我們有了隱私:每一票都是匿名的,同時確保只有授權選民可以投票,每位選民只能投票一次。
接下來,我們引入了 MACI 機制,投票被加密為中央伺服器的解密金鑰。中央伺服器負責進行計票過程,包括剔除重複投票,並發布 ZK-SNARK 證明結果。這保留了先前的保證(即使伺服器作弊!),但如果伺服器誠實,它還增加了一種抗強迫的保證:用戶無法證明他們的投票方式,即使他們想這樣做。這是因為雖然用戶可以證明他們的投票,但他們無法證明自己沒有投票以抵消該票。這防止了賄賂和其他攻擊。
我們在 FHE 中執行計票,然後進行 N/2-of-N 閾值解密計算。這使得抗強迫保證提升至 N/2-of-N,而不是 1-of-1。
我們將計票程序混淆,並設計混淆程序,使其只有在獲得授權時才能輸出結果,授權方式可以是區塊鏈共識的證明、某種工作量證明,或兩者結合。這使得抗強迫保證幾乎完美:在區塊鏈共識情況下,需有51% 的驗證者串通才能破解;在工作量證明情況下,即使所有人串通,重新以不同選民子集進行計票以試圖提取單一選民的行為也將極為昂貴。我們甚至可以讓程式對最終計票結果進行小幅隨機調整,以進一步增加提取單一選民行為的難度。
我們新增了一次性簽名,這是一種依賴量子計算的原語,允許簽名僅用於一次特定類型的信息。這使得抗強迫保證變得真正完美。
不可區分混淆也支援其他強大的應用。例如:
1.去中心化自治組織(DAOs)、鏈上拍賣以及其他具有任意內部秘密狀態的應用。
2.真正的通用可信設定:某人可以創建一個包含密鑰的混淆程序,並運行任何程序並提供輸出,將hash(key , program) 作為輸入放入程式中。給定這樣的程序,任何人都可以將程序3放入自身中,結合程序的預先密鑰和他們自己的密鑰,從而擴展設置。這可用於為任何協定產生 1-of-N 的可信任設定。
3.ZK-SNARKs 的驗證只需一個簽名:實現這一點非常簡單:設定一個可信任環境,讓某人創建一個混淆程序,只有在有效的ZK-SNARK 情況下才會使用密鑰簽署訊息。
4.加密的記憶體池:加密交易變得非常簡單,這樣交易只有在未來發生某個鏈上事件時才能被解密。這甚至可以包括成功執行的可驗證延遲函數(VDF)。
借助一次性簽名,我們可以使區塊鏈免受最終性反轉的 51% 攻擊,儘管審查攻擊仍然可能。類似一次性簽名的原語使得量子貨幣成為可能,從而解決了無區塊鏈的雙重支付問題,儘管許多更複雜的應用仍需要鏈。
如果這些原語能變得足夠高效,那麼世界上大多數應用都可以實現去中心化。主要的瓶頸將是驗證實現的正確性。
1. 不可區分混淆協議(2021): Indistinguishability Obfuscation
2 . 混淆如何幫助以太坊: How Obfuscation Can Help Ethereum p>
3. 第一次已知的一次性簽名構造: First Known Construction of One-Shot Signatures
4. 混淆的嘗試實現(1): Attempted Implementation of Obfuscation (1)
5. 混淆的嘗試實現(2): Attempted Implementation of Obfuscation (2)
還有很多工作要做,不可區分混淆仍然非常不成熟,候選構造的運行速度慢得驚人(如果不是更多的話),以至於無法在應用程式中使用。不可區分混淆以「理論上」多項式時間而聞名,但在實際應用中,其運行時間可能比宇宙的生命週期還要長。最近的協議在運行時間上有所緩解,但開銷仍然太高,無法進行常規使用:一位實施者預計運行時間為一年。
量子電腦甚至還不存在:你在網路上看到的所有構造,要嘛是無法進行超過4 位元運算的原型,要嘛根本不是實質性的量子計算機,雖然它們可能有量子部分,但無法運行諸如Shor 演算法或Grover 演算法這樣的有意義計算。最近有跡象表明,「真正的」量子電腦離我們並不遙遠。然而,即使「真正的」量子計算機不久後出現,普通人要在自己的筆記型電腦或手機上使用量子計算機,可能還要等幾十年,才能在強大的機構能夠破解橢圓曲線密碼學的那一天。
對於不可區分混淆,一個關鍵的權衡在於安全假設,存在使用特殊假設的更激進設計。這些設計通常具有更現實的運行時間,但特殊假設有時最終會被破壞。隨著時間的推移,我們可能會更好地理解格,從而提出不易被破壞的假設。然而,這條路更具風險。更保守的做法是堅持使用那些安全性可證明減少到「標準」假設的協議,但這可能意味著我們需要更長時間才能獲得足夠快速運行的協議。
極其強大的密碼學可能會徹底改變遊戲,例如:
1. 如果我們獲得的ZK-SNARKs 的驗證與簽名一樣簡單,那麼我們可能不再需要任何聚合協議;我們可以直接在鏈上進行驗證。
2. 一次性簽章可能意味著更安全的權益證明協議。
3. 許多複雜的隱私協定可能只需要一個隱私保護的以太坊虛擬機器(EVM)來替代。
4. 加密的記憶體池變得更容易實現。
起初,益處將在應用層出現,因為以太坊的 L1 本質上需要在安全假設上保持保守。然而,僅應用層的使用就可能是顛覆性的,就像 ZK-SNARKs 的出現一樣。
"原文連結」
欢迎加入律动 BlockBeats 官方社群:
Telegram 订阅群:https://t.me/theblockbeats
Telegram 交流群:https://t.me/BlockBeats_App
Twitter 官方账号:https://twitter.com/BlockBeatsAsia