Security vs Trustlessness, ZK協議在機制上該如何取捨

近日，zkSync 和 Polygon 都推出了各自的 zkEVM，掀起了一波行業的熱潮。與此同時，社區對於 zkEVM 的安全性和去中心化也有了很多討論。IOSG 在前不久剛結束的 ETHDenver 期間，舉辦了一場以安全為主題的活動（Stay SAFU, Security Day），有幸邀請到了在零知識證明領域的頭部項目參與討論，他們分享了零知識證明協議在機制設計和工程建構上的安全原則與新穎方案，以及在設計過程中的種種權衡。

以下為各位嘉賓分享的 insight 原文，參與者為：

Queenie Wu, IOSG Ventures 合夥人（主持人）；

Alex Gluchowski, zkSync 聯合創始人；

Ye Zhang, Scroll 聯合創始人和研究負責人；

Matt Finestone, Taiko 首席營運官；

Mikhail Komarov, Nil foundation 創始人；

Brian R, Risc0 創始人；  

 Q1：零知識證明是如何增強你們正在構建的系統的安全性的？另一方面，部署零知識證明會帶來哪些安全問題？

[Brian R]

我是 Risk Zero 的 CEO Brian Redford。我們是在 Risk-V Micro Architecture 構建的 Risk Zero zkVM 的開發者，可以在 ZK 系統中執行任意代碼。我們還在部署一個名為 Bonsai 的 Layer2 網路，它可以在 ZK 場景下執行任何代碼，可以把它理解為是一個 ZK 加速器。在 ZK 如何增強安全性方面，我想這取決於具體的應用場景。當然，能夠進行計算並生成可以在世界任何地方驗證的證明方式完全改變了區塊鏈安全的範式。你不再需要一遍又一遍地重新做相同的計算，再通過複雜的各種機制（比如經濟機制）來保證整個系統的安全性。

[Mikhail Komarov]

我是 Nil 的創始人 Mikhail Komarov。我們為正在開發的 ZK 項目提供基礎設施，例如 zk-EVM 編譯器。這個編譯器可以將高級語言編譯成電路，使得高級語言中定義的每個計算都可以被證明，無需執行任何操作，只需要簡單的電路即可。除此之外，我們還引入了一個「證明市場（Proof Market）」的概念，給想要生成 zkSNARK/STARK 證明的項目方，提供了一個去中心化的競價市場。每個開發者都可以提交所需要生成的零知識證明的競價單，然後只需要在應用程序中調用證明，以獲取所需的服務（比如 zkRollup 就可以使用證明市場）。

基本上，我們是開發人員所需的基礎設施。從我們自身來說，它並沒有增強我們的安全性，但從整體來說，它確實增強了安全性。正如 Brian 所說的那樣，它通過消除協議中應在 Trustless 的環境中運行的信任假設來增強安全性。它的關鍵在於進一步減少信任假設。這就是它如何增強安全性的方式。我相信零知識證明如果被項目，去年發生的一些安全事故可能可以避免。

[Matt Finestone]

我是 Matt 來自 Taiko，我們是一個以太坊兼容的 ZK Rollup。我們追求最大程度的以太坊和 EVM 兼容性。在安全方面，我們獨特的地方是我們非常依賴於經過充分測試和驗證的以太坊構建模塊、客戶端和智能合約模式。正如 Mikhail 所說，ZK 減少了信任假設或將其轉移到 Protocol/證明層面。「需要信任的」不再是一些有動機的人，而是數學和圍繞數學證明開發的協議和應用。對於 ZK Rollup，有很多安全考慮，不僅僅是 ZK。

我認為我們儘可能地從以太坊中重用安全的部分，以保持安全。隨著時間的推移和實戰測試，ZK 將是非常強大的系統。

[Ye Zhang]

大家好，我的名字是 Ye。我在 Scroll 工作。我先簡單介紹一下 Scroll。Scroll 是以太坊的擴容解決方案。它與以太坊兼容度非常高，用戶可以與應用程序交互，開發者可以部署智能合約，只需將代碼複製粘貼並遷移到 Scroll 上即可。它比以太坊更快，更便宜，同時具有更高的吞吐量和更嚴格的安全性。我們會去中心化我們的證明系統（Decentralized Prover Network），防止證明系統的單點故障。這是我們邁向去中心化的第一步，因為 ZK Rollup 的在未來相當長的一段時間內會是去中心化的。即使你對數學非常信任，對密碼學非常信任，但你仍然可能遇到這種單點故障，因為你要依賴於某個證明者。

去中心化的第一步是想要將證明系統去中心化，以使其更加可靠。至於 ZK 的安全性，我認為其他嘉賓已經介紹了 ZK 給你帶來了非常強大的公共可驗證性屬性。基本上，任何人都可以進行計算和執行證明，然後任何人都可以驗證這個證明並得到相同的保證。如果你有數百萬個節點，每個人只需要重新執行驗證算法，而不是初始計算，這樣也實現了系統的可擴展性。這就是 ZK 技術的威力所在，至於它可能存在的問題，如果我們的系統完全依賴數學的運算，如果存在一些錯誤，比如缺失一些約束條件，那麼可能會很危險。這就是為什麼我們採取多種方法來提高我們的安全性。例如，我們採用社區驅動的方法進行開發。從第一天開始，我們就開源了所有開發過程，並由以太坊和我們自己的社區進行了審核，這是一個更高的標準。這就是我們最小化信任和提高安全性的方法。

[Alex Gluchowski]

我叫 Alex Gluchowski，是 Matter Labs 的 CEO，我們是 zkSync 協議背後的公司。我們正在構建 zkSync Era Network，這是一個與 ZK EVM 兼容的 ZK Rollup。我們採取了與 EVM 等效的 Rollup 略有不同的方法。我們認為應該採取務實的方法, 從兼容的東西開始，這樣開發者可以輕鬆接入和移植現有應用程序，並從現有工具中啟動。但是，最終的 ZK 環境是不同的。如果你將自己綁定到原有技術上，將很難實現 ZK 系統的最大容量。這很重要，因為我們的使命是將區塊鏈擴展到真實世界的範圍，將下一個十億用戶引入區塊鏈，創造新的價值網路。如果你考慮到數百萬甚至數十億用戶，你真的想要降低成本，因為隨著所有這些數十億個交易的累加，成本將變得非常重要。

這如何影響我們如何增強安全性？這是一個非常有趣的問題。當你詢問如何提高安全性或任何其他因素時，你想要比較替代方案，對吧？我的基準是什麼？使用 ZK 的替代方案是什麼？替代方案可能是在 ZK Rollup 之前可用的其他擴展技術，例如 Optimistic Rollup、側鏈、Plasma 等。這些方案引入了新的信任假設。如果我們的目標是將規模擴大到 10 億用戶，而我們的使命不僅是擴大吞吐量，而是擴大價值規模，同時保持自我主權、自我保管、無需許可的性質以及完全無需信任的系統特性，那隻有使用 ZK 可以實現。

Q2：我們在比較不同類型的 zkEVM 時，通常關注的是他們的可擴展性和兼容性，（Vitalik 對此進行了詳細的比較:https://vitalik.ca/general/2022/08/04/zkevm.html），如果我們在此增加一個安全的維度，zkSync Era、Scroll 和 Taiko 會如何比較不同的機制設計可能帶來的不同的潛在安全風險？

[Alex Gluchowski]

正如前面的發言者所提到的，你需要隱含地信任這些複雜系統的許多組件來保證安全性，例如，你信任編譯器產生的代碼，你認為它正在執行你放在這個編譯器中的代碼邏輯。為什麼你會相信它是 Solidity？它沒有形式化定義，所以你只是信任編譯器在各個版本中的行為是正確的。我們認為這是必須要解決的問題。這就是為什麼我們開始建立基於 LLVM 框架的編譯器，它支持 Solidity 作為前端之一，並依賴於這個成熟的框架，有很多工具可用於代碼的靜態分析、安全檢查等，而後端是我們的 zkVM 虛擬機。我們還可以支持其他更成熟的語言，這些語言實際上已經被用於其他安全環境，如 Rust，或者是一些更新穎的語言，這些語言是增加了安全考量的，如 Move，它能避免一些安全問題，比如雙花之類的。總而言之，儘管比較複雜，我們必須從不同的層面去解決。

[Ye Zhang]

我想講一些不同的方法及其背景。我們正在建立 EVM Bytecode 級別的兼容方案。基本上我們可以與 EVM Bytecode 進行兼容。這與 zkSync 的構建方式不同，我們也相信編譯器不應該被信任。這就是為什麼我們相信 Solidity 編譯器，雖然它不成熟，但在區塊鏈的背景下，Solidity 已經是相對成熟的了。之前沒有人使用 Solidity 和 LLVM。我們相信那是一個更好的標準，因為已經經過了實踐的檢驗，很多智能合約 DeFi 已經經過了 Solidity 開發者的實踐考驗。這就是為什麼我們相信遵守這種編譯器的標準，遵守 Solidity 編譯器的標準，遵守 EVM 黃皮書的定義是保證系統安全性的最好方法。因為從電路方面來說，我們不需要考慮編譯器方面的問題，我們不需要建立我們自己的編譯器，我們只是採用現有的基礎設施，證明它的執行是正確的。

我們情願把系統構建的複雜性只放在解決 zkEVM 在 Bytecode 層面的兼容性，而不是同時構建一個編譯器以及支持 LLVM 的後端，我們不希望在構建 zkEVM 之外還需要構建編譯器。另一個考慮因素是，我們肯定關心開發者的體驗。Layer2 是為擴展 EVM 而建立的，目前的 EVM 已經因為大量 Solidity 代碼和應用變得擁擠不堪。我們希望開發者能夠無縫遷移到我們的系統，同時確保安全性。這也是為什麼我們目前不打算在 EVM 當中增加更多花俏的功能。

遵循這個標準可以使 Ethereum 真正可擴展，同時保證在此基礎上的系統最佳性能和及時交付。同時，我們也在以太坊官方推動各種開源實現，包括 Type1 和 Type2 的 zkEVM，包括隱私和擴容等。我們從第一天開始就採用開源方式構建。我們非常關注 Ethereum zkEVM 的開發和演進，我們領導了其中一半的開發，我們是團隊的一部分，因此我們確切地知道整個系統需要多長時間才能真正準備好。這就是為什麼我們採取這種方法來準備產品和深入社區，然後考慮如何推動 Ethereum 的終極目標。

[Matt Finestone]

這是兩個很好的答案，Taiko 和 Scroll 的方案更靠近，我們也沒有引入新的編譯器。我喜歡 Alex 所說的，就是在區塊鏈背景下安全的替代方案是什麼？我認為我們都會同意，以太坊可能是黃金標準。我們按照黃皮書實施，重複使用以太坊而不是調整它的組件，即使是在 EVM 以外的以太坊組件、數據儲存結構等方面，也是經過實踐驗證的。

當然，這裡始終有權衡。Alex 談到了十億用戶和超低成本以及保持價值的擴展性。我們可能會在證明成本上做出更高的犧牲，但我們堅持使用經過實戰考驗的 EVM 標準和以太坊標準。而對 Ye Zhang 所說的關於實用性和快速進入市場的一些考慮，我們也會做出了權衡。

在 ZK 的背景下，有一些方向不容易實現，例如一些哈希函數或一些數據儲存結構。我們不去改變這些東西，因為我們不確定它們的效果會如何，比如把 Merkel Patricia Tree 改成了 Verkle Tree，即使這在以太坊的路線圖上本身就存在。我們對經過試驗和實戰考驗的組件更加自信，系統的複雜性不在於試圖重新發明以太坊的 EVM 和其他組件，而是在於如果將 ZK 完全地部署兼容 EVM。這將需要更長的時間來完成，我們需要比 Scroll 更長的時間來做一些權衡以實現可用性。在安全性上，我們的實現路徑會更令人放心。

[Mikhail Komarov]

以太坊經過實戰考驗，讓我們重用所有這些系統，減少新的假設。但還有幾個安全問題，少有人真正考慮過，而我們的目標是解決它們。第一個問題，你必須信任編譯器。還有另一個問題，就是如果你想實現完全的 EVM 兼容性，比如 Type1 的 EVM 兼容性，那麼你就需要手動在電路中重新部署 EVM 的任何 Opcode，通過找出作為電路的某個表達式，它在某個確定域上的形式會是怎樣的，這是一個手動的過程，而且非常複雜，很容易出錯。我們自己就做過這樣的事情，而且搞砸了電路，因此我們知道這是糟糕的。

為了不重複這些問題，也不讓任何人犯這些錯誤，我們正在致力於通過允許人們通過使用已經經過實戰測試的 EVM 實現編譯電路，來消除這種安全假設，而不是通過手動重新實現所有的 OpCode。我們的目標是通過使用 LLVM 編譯器來編譯它，而不是手動重新實現，由此有了最小的安全假設。這是另一個需要消除的安全假設，我們將針對 zkEVM 進行解決。

[Brian R]

你可以在類似 RiscV 的系統上運行 geth 來解決 Mikhail 所說的問題。我們實際上剛剛添加了 Go 的支持。我們構建並設計了 RiscZero VM，我們選擇 RiscV 指令集的部分原因是因為它有形式化定義，而且非常輕巧。RiscV 電路的安全範圍有所規範，並且已經進行了大量工作來將形式化驗證方法納入證明某個實現過程符合 RiscV 規範。我們專注於保證這個簡單系統中的密碼學正確，然後在其上運行 EVM 確實有效。當然，這種方法會有性能損失。比如進行 ERC20Token轉移需要大約 1 分鐘。

Q3：正如 Alex 剛剛提到的，對於系統的任何部分，升級或選擇另一種解決方案都是可能的。那麼，如何確保系統的可升級性，並且以非常安全的方式實現？

[Brian R]

是的，我認為在 ZK 中，可升級性是一個非常重要的話題。從我們的角度來看，在沒有部署網路和背後有大量經濟價值的情況下，我們花費了大量時間確保我們正在構建正確的技術堆棧抽象。我們可以切換哈希函數，切換有限域和證明系統，或者添加新的技術，例如 PLONK，到技術堆棧中。這也是我們選擇 RiscV 作為主要支持的「指令集」的另一個原因，因為它本身就是一個非常清晰的抽象系統。因此，您可以隨意更換任何東西。LLVM 顯然具有非常類似的特徵。

[Matt Finestone]

是的，升級是一個很大的話題，我們可以將其看作一個去信任化系統的問題。系統的部署實現可能會出現漏洞，用戶就會面臨風險，或者要信任構建該系統的人或一些參與者，他們可能會在趁虛而入等等。升級是一種在某些層面上找到安全和去信任化的平衡。當你對系統的信任度提高時，可以去除其中一些受信任的參與者。在這裡，我們應該對一些受信任的參與者持有非常警惕的態度，因為我們做這些事情的目的是為了消除這些參與者。對於這些非常複雜的系統，最好在早期就可以介入。我認為，Alex 和 Matter Labs 團隊已經在這方面提供了一些很好的參考案例。他們有一個很好的安全委員會和時間延遲的機制。

那麼升級的正確節奏是什麼？這是一個非常重要的問題，我不知道更多的用戶是否會對完全去信任的系統感到安心，因為這樣的系統往往非常複雜，引入了許多新的東西，或者是信任這些善意的參與者。這是一個非常關乎人性的問題，當然也有一些技術解決方案，比如多重證明可能是一個不錯的選擇。我認為，我們有可能從類似於 Optimism 的組件中重用一些設計。如果我們的有效性證明有問題，那麼重用 Optimistic Rollups 的實現將更容易制定欺詐證明的系統，以使其適用於以太坊等效環境。你可以混合匹配欺詐證明和有效性證明，如果有任何異議，那麼升級性或某種類型的治理方案可以覆蓋它。

[Mikhail Komarov]

讓我來說一下。我剛花了一些時間思考這個問題。我擔心我沒有理解問題，因為我想說哪裡有升級問題？只需重建電路即可。那麼，究竟是哪些升級問題呢？

[Ye Zhang]

從我們的角度來看，首先，肯定不能僅僅編譯新電路，因為它會影響您的證明密鑰、驗證密鑰和許多鏈上智能合約，所以肯定不能經常這樣做。我們在考慮多重證明的方法，添加雙重驗證等機制。有多種方法可以解決這個問題，除了像 Matt 提到的，我們不考慮直接與 Optimistic 的欺詐證明相結合，因為這會讓最終確認時間變得更長。我們正在探索一些其他方法，很快就會在以太坊研究中提出一些提案，關於如何增加一些額外的保證。

例如，Justin Drake 提出了使用 Intel SGX（TEE 環境）作為一些額外保證的方法，嚴格地增加了安全保證。此外，還可能存在一些其他的治理方式，我們認為安全委員會和時間延遲是不錯的方式。我們也在思考這個問題。這是一個權衡，我相信大多數 Rollups 仍需要更長時間才能真正擺脫這種可升級性問題，因為升級系統是一件長期的事。我們正在認真關注和研究這個問題。

[Alex Gluchowski]

我可以給一些背景資訊，為什麼可升級性是一個重要的問題。打個比方，對於任何你電腦桌面上運行的某個程序，你只需下載新版本並安裝，對吧？升級有什麼問題？問題在於，在區塊鏈的背景下，我們試圖構建 Trustless 的系統，但在某些情況下，升級的需求可能會破壞這種信任。對於 Layer1，沒有這個問題。如果要升級以太坊，只需下載新的客戶端，安裝它，然後所有人協調分叉。

然後我們安排一次分叉，定個日期，在某個區塊號進行分叉，那麼任何不喜歡此次升級的人都可以留在舊版本的舊分支上。這種可升級性路徑是完全 Trustless 的。它不會讓您依賴任何誠實的大多數或任何可信的參與者。

問題出現在 Layer2 的背景下。如果我們構建的是 Rollup，Rollup 依賴於 Layer1 的智能合約。這個智能合約可能是不可變的，其中某些特定電路的某些固定功能和驗證密鑰已經內置，那麼問題就在於如果存在 Bug，那麼你將束手無策。那如果面臨 bug，或者如果想修復它該怎麼做？

我們在 zkSync 1.0（zkSync Lite）披露了過一個漏洞，具有可升級性的時間鎖定，因此團隊可以提出新版本的升級提案。然後，如果用戶不喜歡這個新的版本，所有用戶都有幾周的時間將資產從 Layer1 退出。我們有 Trustless 的機制來實現退出。但因為被迫進入了這個時間鎖定，我們無法修復它，所以我們想出了一個折衷方案，並引入了我們稱之為 Security Council 的方案，這是一個獨立的委員會。我們邀請了一些來自不同社區、不同項目的以太坊社區的 15 名知名成員加入。

團隊不控制合約，只能提出升級方案，Security Council 來做出決定，可以決定加速升級。但這仍然不是最佳選擇，因為理論上還是有一組人可以在此期間立即安裝一個惡意版本。也許他們不想這樣做，但也許他們會被某些參與者強迫，我們無法排除這種可能。因此，如果我們希望充分利用零知識證明，並且僅依賴數學和開源代碼而不是任何驗證程序的受信任方等，最終實現完全 Trustless 的機制。

我們目前在思考一個更好的方案，由團隊提出時間鎖定的升級提案，Security Council 可以介入建議凍結智能合約，然後在 Layer1 上進行軟分叉。因此，這需要與 Layer1 協調，這需要 Layer2 協議已經有一定規模足夠重要，以使社區實際上進行分叉，安裝新版本等。因為 Layer1 無法為每個小協議執行此操作，它必須是像以太坊上的系統級事物那樣重要的協議。

這是我們目前擁有的增強無需信任的可升級方案的最佳機制，以便保護我們免受第一層嚴重漏洞的影響。但這還是會引入一些類似時效性的問題，如果出現這樣的問題，協議將暫停一段時間，想象一下我們已經從 Visa 和 PayPal 切換到使用這種大型 Rollups 進行區塊鏈支付，突然之間用戶資產被凍結，沒有人可以進行支付，需要我們協調升級幾天，這是巨大的問題。我們當前沒有更好的解決方案，也沒有看到更好的解決方案。如果您有想法，請聯繫我們，讓我們進一步探討。

Q4：有一個關鍵詞被多次提到，那就是「無需信任-Trustless」。正如我們所知，當前系統中最重要的組成部分仍然是中心化的。從中心化到去中心化的演變，我們將面臨哪些安全挑戰？

[Alex Gluchowski]

我認為這（Trustless）將增強安全性。這將為我們提供多一重因素的保護。首先，ZK Rollup 必須為每個塊提供有效性證明，但它可以存在問題，例如，也許我們忘記了某些約束條件。在此之上，我們還需要通過權益證明共識機制來提供簽名，這是額外的一層保護。因為為了破壞系統，惡意攻擊者必須首先找到漏洞，然後必須在夥同這個這些驗證者中的大多數來一起作惡。

這個可能性是比較小的，因為攻擊者要麼已經是這個區塊鏈上的控制方，要麼必須購買大量Token，這給了我們足夠的時間，可能其他人也會發現相同的漏洞，並提交 Immunefi 或其他地方，團隊可以進行修復。或者，也許我們將同時運行一些蜜罐，這是完全開放的，任何人都可以破解並從中獲得獎勵。所以，總體來說，這為整個系統提供了兩個因素的保護。而且，我們可以在此基礎上添加更多因素。

到目前為止，我不會相信一個號稱完全無需信任的 ZK Rollup 是安全的。對我來說，這將是極具風險的。我不會在這樣的 ZK Rollup 上放置比我可承受失去的金額更大金額的資產。

我最喜歡舉的例子是波音 737 Max 事件。這個事故的原因不是因為他們試圖轉移公眾注意力的軟體問題，而是因為他們依賴於飛機上的單個傳感器，這是完全不負責任的行為。航空業已經有很長的發展歷史，過程中有很多技術迭代，不能依賴單個系統是業界的共識。但因為他們在生產波音 737 max 的過程中因為各種原因（比如成本、交付時間等）犧牲了安全的系統設計，最終導致了事故。因此，我們始終希望至少有兩個完全獨立的安全因子，來降低故障的機率。

[Ye Zhang]

我們秉持着長期主義的理念來思考 ZK Rollup 的去中心化路線圖。先去中心 Sequencer 還是 Prover，甚至如何定義 ZK Rollup 的去中心化，我們都有自己的想法。我認為最終我們將同時去中心化 Sequencer 和 Prover。但是我們有一些略微不同的優先排序，我們希望先將 Prover 去中心化。安全性絕對是重要原因之一。如果先將 Sequencer 去中心化，那在 zkEVM 變得非常成熟穩健之前，如果有人真的發現了一些漏洞並提交了虛假證明，它有一定機率會被 Sequencer 接受並出塊，對系統造成破壞。

因此，我們會先保留中心化的 Sequencer。因為 zkEVM 是有可能出現漏洞的，因為它是非常複雜的系統。因此，我們希望至少在早期階段，我們控制中心化的排序，至少能保證正確有效的出塊。

另一個先去中心化 Prover 的原因是，有許多硬體公司正在尋找如何使 zkEVM 更高效的方案。如果我們承諾去中心化 Prover 的這種方案，他們會參與優化系統的代碼。我們都知道，ZK ASIC 可能需要一年以上才能問世，如果我們首先進行 Prover 的去中心化，他們將更有動力為我們的系統進行構建，使系統變得更加高效。Sequencer 的去中心化是我們後面計劃要做的事情。

這裡還要考慮一個更複雜的因素，如果將 Prover 和 Sequencer 分配到兩個不同的群體，則需要非常小心地設計激勵方案，例如分配到這兩方的獎勵的比例，如何能夠做到足夠合理且平衡兩方的激勵。

除此之外，我們還有一些其他的安全手段。例如，我們正在構建的方式是開源的，我們正在進行一些內部安全審計，而不僅僅是外部審計。我們擁有一個非常強大的安全團隊。我們提供各種資金資助來鼓勵更多人參與安全方案的構建，比如形式化驗證等工具。我們團隊還曾經在 Consensys ZKEVM 和 Aztec 的電路上找到過漏洞。我們正在嘗試改善整個生態系統的安全性。

 [Matt Finestone]

Taiko 可能會更早地面臨這種挑戰。儘管大家都有一定程度的去中心化，但實際上我們也在計劃和以太坊保持一樣的方式，包括 EVM、Gas 時間表和狀態樹等，同時也考慮到 Ethos 和其他去中心化（我們稱之為）Sequencer Proposer，以及 Prover。在幾個月前的第一個測試網中，約有 2000 獨立個人或地址無需許可的 Propose 一個區塊。儘管可能存在一些惡意區塊，但這也是去中心化的承諾。我認為這不是漸進式的去中心化，或許是漸進式的效率提升，因為你必須放棄一些效率。Proposer 可能會建立相同的區塊，導致有些交易冗餘，同時也付出了一些向 Layer1 支付了 ETH 的有價值的區塊空間。有些人會得到退款，有的會直接跳過。

對我們來說，我們在下一個即將到來的測試網中立即實現去中心化不太現實。Permissionless provers 在測試網環境中比較難，因為有女巫攻擊，人們會讓 proposed block 中充滿垃圾資訊，而 Prover 必須花費真正的計算資源證明它們，但卻沒有實際收入。

因此，我們將使用 Permissioned Proposer，讓任何去中心化的 Prover 提交區塊，並得到相應的獎勵，這個很重要。另外，如果系統出現故障，一個 Prover 提交了有效性證明，同時也出現了一個不一致的證明被提交，那麼智能合約就可以知道並且暫停。它會識別到為什麼有兩個正確的有效性證明在不同的塊上？出現這種情況立即暫停，也就引發了時間延遲。如 Alex 所說，我們當前無法對完全無需許可、無需信任的實施感到放心，我們要努力實現平衡。

[Mikhail Komarov]

我們從一開始就考慮了這個問題。一些人最初的解決方案是自上而下的方法，例如決定創建 Rollup，然後考慮去中心化的次序問題，比如先去中心化 Sequencer。然後去中心化 Prover，一環接一環。相比之下，我們採用了一種不同的方法，我們自下而上來解決問題。

我們首先建立了一個去中心化的 Prover 網路，來無需許可地匯集算力。然後我們試圖在 Prover 網路的基礎上添加 Sequencer，因為 Sequencer 必須和 Prover 網路緊密結合，特別是與成熟的去中心化 Prover 網路。這裡涉及到需要支付額外的證明費用，通信的複雜性等問題，所以 Sequencer 必須緊密結合 Prover 網路，以確保其有效性。我們所開發的系統可以作為 ZK Rollup 的底層基建。

為了確保所有的證明生成都有一個激勵機制來加速完成，並提高質量和保持安全性，我們引入了證明市場（Proof market）來管理所有證明的生成和排序。同時，我們保持了這個系統的去中心化和無需許可性。這種方法是從底層解決問題，而不是從頂層解決問題。

[Brian R]

我認為我們採取的方法，與其他網路有很大的不同。類似於 Nil 團隊正在建立的證明市場（Proof market），但是我們採用了一種更無需信任的方式。我們當前沒有關注 Sequencing 的問題，而是關注在證明系統上，讓它能夠更加強健地進行各種運算。這種方法簡化了很多複雜性，有利於儘快將最多的計算量投入市場。

我們希望降低開發人員的使用門檻，讓他們在以太坊或任何系統上建立任何他們想要的應用程序，並擁有這個去中心化的基礎計算層，用零知識證明來保證計算的正確性。

Q5. 觀眾：在 Algorand 中，出現了一種名為 State Painting 的技術。它的基本思想是從一個共識區塊鏈中提取狀態，並將其「Paint」到另一個共識區塊鏈上。這種技術更像是一種跨鏈方案，同時運用到了零知識證明的方案。那在 Layer2 中，系統共識其實依賴於 Layer1 的共識，這樣是否會降低 Layer2 的安全性？

[Alex Gluchowski]

在 ZK Rollups 的實施中，Layer1 和 Layer2 的之間的資產流動是完全無需信任的，Layer2 完全承接了 Layer1 的安全性。關於資產在 Layer2 之間的轉移，如果你是通過以太坊 Layer1 的原生橋接，那麼它也是完全無信任的。但是，如果沒有通過 Layer1，其安全性取決於通過哪種跨鏈方式實現橋接。

在 zkSync 中，我們正在實現一種被稱為 Hyperchain 的方案。具體而言，我們將建立多個由相同電路驅動的鏈，這些鏈仍然通過以太坊上進行橋接。Hyperchain 將提供免費的、完全無信任的、非常便宜的交易，可以從任何鏈到任何其他鏈。當我們談論將數億甚至數十億的用戶引入區塊鏈時，這一點非常重要。

在未來，我們不可能讓數以兆的交易都運行在一個單一的系統或共識上。它們將不得不在許多不同的共識系統上運行，比如分片、獨立的應用鏈等。但同時我們需要保證這些不同鏈之間的可連接和通信的低成本。

打個比方，就像我們今天使用不同系統的電子郵件，用戶可以輕鬆地完成不同電子郵件系統之間的通信。這就是我們希望通過 Hyperchain 實現的東西。除了完美地承接 Layer1 的安全性，高效且無需信任的跨鏈通信，Hyperchain 還可以通過遞歸證明來實現使用的超低成本。

原文連結