撰文：Austbot
編譯：深潮TechFlow
Anagram Build 大部分時間都用於研究新型的加密用例，並將這些用例應用於特定產品中。我們最近的一個研究項目進入了可驗證計算（VC）領域。我們的團隊利用這項研究創建了一個名為 Bonsol 的新開源系統。我們之所以選擇這一研究領域，是因為可驗證計算帶來了許多有效的用例，而且各個 L1 都在共同努力優化可驗證計算的成本效益和可擴展性。
在本文中，我們有兩個目標
首先，我們希望確保您對 VC 作為一個概念以及它在 Solana 生態系統中可能啟用的產品有更好的理解。
其次，我們希望向您介紹我們的最新作品：Bonsol
什麼是可驗證計算呢
“可驗證計算（Verifiable Compute）”這個術語在牛市初創公司的投資說明書中可能不會出現，但“零知識”這個術語會。那麼，這些術語是什麼意思呢？
可驗證計算（VC）是以一種能夠生成其工作過程的證明的方式運行特定工作負載，而這個證明可以在不重新運行計算的情況下公開驗證。零知識（ZK）是指能夠證明關於數據或計算的陳述，而無需揭示所有數據或計算的輸入。在現實世界中，這些術語有些混淆在一起，ZK 有些是一個誤稱。它更多地與選擇需要公開以證明其陳述的信息有關。VC 是一個更準確的術語，並且是許多現有分佈式系統架構的總體目標。
VC 如何幫助我們構建更好的加密產品？
那麼，為什麼我們想要在 Solana 和以太坊等平臺上添加 VC 或 ZK 系統呢？答案似乎更多地與開發者的安全有關。系統的開發者充當了用戶對黑匣子的信任與使該信任客觀有效的技術功能之間的中介。通過利用 ZK/VC 技術，開發者可以減少他們正在構建的產品中的攻擊面。VC 系統將信任的重點轉移到了證明系統和被證明的計算工作負載上。這類似於從典型的 web2 客戶端/服務器方法轉向 web3 區塊鏈方法時發生的信任倒置。信任從依賴於公司的承諾轉變為信任開源代碼和網絡的加密系統。從用戶的角度來看，沒有真正的零信任系統，我認為對用戶來說，這一切都像一個黑匣子。
例如，通過使用 ZK 登錄系統，開發者在維護安全數據庫和基礎設施方面的責任就會減少，因為這個系統只需驗證某些加密屬性是否已實現。VC 技術正在應用於許多需要共識以確保所需共識的唯一條件是數學是有效的地方。
雖然有許多在野外使用 VC 和 ZK 的成功案例，但其中許多目前都依賴於加密軟件棧各個層面的開發進度，以使其足夠快速、高效地用於生產。
作為我們在 Anagram 所做的工作的一部分，我們有機會與眾多加密創始人/開發者交談，瞭解當前加密軟件堆棧的狀態如何影響產品創新。從歷史上看，我們的談話幫助我們識別出了一個有趣的趨勢。具體來說，一批項目正在積極將鏈上產品邏輯轉移到鏈下，因為它變得太昂貴了，或者他們需要添加更多的奇特業務邏輯。因此，最終這些開發者發現自己試圖找到平衡他們正在開發的產品的鏈上和鏈下部分的系統和工具，這些產品變得越來越強大。這就是 VC 在幫助使用不可信任和可驗證方法連接鏈上和鏈下世界的道路上成為關鍵部分的地方。
當下 VC/ZK 系統是如何工作的呢？
現在，VC 和 ZK 函數主要是在替代計算層（如Rollup、側鏈、中繼、預言機或協處理器）上執行的，可通過智能合約運行時回調使用。為了實現這一工作流程，許多 L1 鏈正在努力提供智能合約運行時之外的快捷方式（例如系統調用或預編譯），以便執行一些在鏈上否則會太昂貴的操作。
當前 VC 系統有幾種常見的模式。我將提及我知道的前四種。除了最後一種情況外，ZK 證明是在鏈下進行的，但正是證明何時何地被驗證給了這些模式各自的優勢。
完全在鏈上驗證
對於能夠生成小證明的 VC 和 ZK 證明系統，例如 Groth16 或一些 Plonk 變種，證明隨後被提交到鏈上，並且使用先前部署的代碼在鏈上進行驗證。這樣的系統現在非常常見，嘗試此方法的最佳方式是使用 Circom 和 Solana 或 EVM 上的 Groth16 驗證器。缺點是這些證明系統相當慢。它們通常還需要學習一種新語言。在 Circom 中驗證一個 256 位哈希實際上需要手動處理每個 256 位。雖然有許多庫允許您只需調用哈希函數，但在幕後，您需要在 Circom 代碼中重新實現這些函數。當您的用例中的 ZK 和 VC 元素較小時，以及您需要證明在採取某些其他確定性操作之前證明是有效的時，這些系統非常棒。Bonsol 目前屬於此第一類別。
鏈下驗證
證明被提交到鏈上，以便所有各方都能看到它，並且稍後可以使用鏈下計算進行驗證。在這種模式下，您可以支持任何證明系統，但由於證明不是在鏈上進行的，因此您無法為依賴於證明提交的任何操作獲得相同的確定性。對於具有某種挑戰窗口的系統而言，這是很好的，其中各方可以“否決”並嘗試證明證明是不正確的。
驗證網絡
證明被提交到驗證網絡，並且該驗證網絡充當調用智能合約的預言機。您會獲得確定性，但您也需要信任驗證網絡。
同步鏈上驗證
第四種和最後一種模式相當不同；在這種情況下，證明和驗證是同時在鏈上完成的。這就是 L1 或 L1 上的智能合約實際上能夠在用戶輸入上運行 ZK 方案，並允許證明私有數據上的執行。在外並沒有太多廣泛的例子，通常您可以使用這種方法做的事情被限制在更基本的數學操作上。
總結
所有這四種模式都正在各種鏈生態系統中進行測試，我們將看到是否會出現新的模式，並且哪種模式會佔主導地位。例如，在 Solana 上，沒有一個明顯的贏家，而且 VC 和 ZK 的景觀還處於早期階段。跨許多鏈，包括 Solana 在內，最受歡迎的方法是第一種模式。完全在鏈上驗證是黃金標準，但正如所討論的那樣，它也帶來了一些缺點。主要是延遲和它限制了您的電路可以做什麼。當我們深入研究 Bonsol 時，您將看到它遵循了第一種模式，但有些不同之處。
介紹 Bonsol
Bonsol，這是我們 Anagram 所構建並開源的一個新的 Solana 原生 VC 系統。Bonsol 允許開發者創建一個可驗證的可執行文件，涉及私有和公共數據，並將結果集成到 Solana 智能合約中。請注意，該項目依賴於流行的 RISC0 工具鏈。
這個項目的靈感來自於我們每週與許多項目交流時提出的一個問題：“我怎樣才能使用私有數據在鏈上證明它？”雖然每個情況下的“事情”都有所不同，但底層的願望是相同的：減少他們的中心化依賴。
在我們深入瞭解系統的細節之前，讓我們通過兩個不同的用例來說明 Bonsol 的強大之處。
情景一
一個 Dapp 允許用戶購買各種代幣池中的彩票。這些池子每天從一個全局池中“傾斜”，這樣一來，池子中的金額（每種代幣的金額）都是隱藏的。用戶可以購買訪問越來越具體範圍的池子中的代幣。但有一個陷阱：一旦用戶購買了該範圍，它就會同時對所有用戶公開。然後用戶必須決定是否購買彩票。他們可以決定不值得購買，或者他們可以通過購買彩票來確保他們在池子中有一份利益。
當池被創建並且當用戶為範圍付費時，Bonsol開始發揮作用。當創建/傾斜池子時，ZK 程序接收每種代幣的數量的私有輸入。代幣的類型是已知的輸入，而池子地址是已知的輸入。該證明是對從全局池隨機選擇到當前池子中的證明。證明中還包含對餘額的承諾。鏈上的合約將接收此證明，對其進行驗證，並保存這些承諾，以便在最終關閉池子並將餘額從全局池發送到彩票所有者時，他們可以驗證自從池子開始時的隨機選擇以來代幣數量是否發生了變化。
當用戶購買隱藏代幣餘額範圍的“開放”時，ZK程序將實際代幣餘額作為私有輸入，並生成一系列數值，與證明一起承諾。此ZK程序的公共輸入是先前承諾的池創建證明及其輸出。通過這種方式，整個系統得到驗證。先前的證明必須在範圍證明中進行驗證，並且代幣餘額必須散列到與第一個證明中承諾的相同值。範圍證明也被提交到鏈上，並且如先前所述，使範圍對所有參與者可見。
雖然有許多方法可以實現這種類似抽獎票的系統，但 Bonsol 的屬性使得對組織舉辦抽獎的信任要求很低。它還突顯了 Solana 和 VC 系統的互操作性。Solana 程序（智能合約）在促成信任方面發揮著關鍵作用，因為它驗證證明，然後允許程序採取下一步行動。
情景二
Bonsol 允許開發人員創建供其他系統使用的工具套件。Bonsol 包含部署的概念，開發人員可以創建一些 ZK 程序並將其部署到 Bonsol 運營商那裡。Bonsol 網絡運營商目前有一些基本方式來評估是否對一個 ZK 程序的執行請求經濟上有利。他們可以看到有關 ZK 程序將需要多少計算、輸入大小和請求者提供的小費的一些基本信息。開發人員可以部署一個他們認為許多其他 Dapp 會想要使用的工具套件。
在 ZK 程序的配置中，開發人員指定所需輸入的順序和類型。開發人員可以發佈一個預先配置了一些或全部輸入的 InputSet。這意味著他們可以配置部分輸入，幫助用戶在非常大的數據集上驗證計算。
例如，假設開發人員創建了一個系統，根據 NFT，可以證明鏈上的所有權轉移包括了特定的一組錢包。開發人員可以有一個預配置的輸入集，其中包含大量歷史交易信息。ZK 程序搜索該集合以找到匹配的所有者。這是一個人為的例子，可以用許多方法實現。
再考慮另一個例子：開發人員能夠編寫一個 ZK 程序，可以驗證一個密鑰對簽名來自一個密鑰對或分層密鑰對，而不洩露這些授權密鑰對的公鑰。假設這對許多其他 Dapp 有用，並且它們使用這個 ZK 程序。協議為這個 ZK 程序的作者提供了一小筆使用小費。由於性能至關重要，開發人員被激勵使他們的程序運行速度快，以便運營商願意運行它們，而試圖剽竊另一個開發人員工作的開發人員需要改變程序的某些方式才能部署它，因為對 ZK 程序的內容進行驗證。添加到 ZK 程序的任何操作都會影響性能，雖然這肯定不是絕對可靠的，但這可能有助於確保開發人員因創新而受到獎勵。
Bonsol 架構
這些用例有助於描述 Bonsol 的用途，但讓我們來看看它的當前架構、當前激勵模型和執行流程。
上述圖像描述了一個用戶需要執行某種可驗證計算的流程，這通常通過需要用戶執行某些操作的 dapp 來實現。這將採取執行請求的形式，其中包含關於正在執行的 ZK 程序、輸入或輸入集、必須在其中證明計算的時間和小費（這是中繼收費的方式）。請求被中繼拾取，他們必須競賽決定是否要聲明對此執行的所有權並開始證明。根據特定的中繼運營商的能力，他們可以選擇放棄，因為小費不值得或者 zk 程序或輸入太大。如果他們決定執行此計算，他們必須對其執行聲明。如果他們是第一個獲得聲明的人，那麼他們的證明將被接受直到某個時間。如果他們沒有及時產生證明，其他節點可以聲明執行。為了聲明，中繼必須提供一些抵押品，當前硬編碼為小費/2，如果他們未能產生正確的證明則會被削減。
Bonsol 的構建基於這樣一個論點，即更多的計算將轉移到一個層面，在該層面上對其進行驗證並進行鏈上驗證，並且 Solana 將很快成為 VC 和 ZK 的首選鏈。Solana 的快速交易、廉價計算和不斷增長的用戶群使其成為測試這些想法的絕佳場所。
這很容易構建嗎？當然不是！
這並不是說在構建 Bonsol 時沒有挑戰。為了將 Risco0 證明帶到 Solana 並在其上驗證，我們需要使其變小。但我們不能簡單地這樣做，而不犧牲證明的安全性。因此，我們使用 Circom 將 Risc0 Stark 包裝起來，該 Stark 可以是約 200kb，然後將其包裝在 Groth16 證明中，其大小始終為 256 字節。幸運的是，Risc0 為此提供了一些初步的工具，但它增加了許多開銷和依賴項到系統中。
當我們開始構建 Bonsol 並使用現有的工具包裝 Stark 與 Snark 時，我們尋求減少依賴性並增加速度的方法。Circom 允許將 Circom 代碼編譯成 C++ 或 wasm。我們首先嚐試將 Circom 電路編譯為由 LLVM 生成的 wasmu 文件。這是使 Groth16 工具包便攜且仍然快速的最快、最有效的方法。我們選擇 wasm 是因為其可移植性，而 C++ 代碼依賴於 x86 cpu 架構，這意味著新的 Macbooks 或基於 Arm 的服務器將無法使用此代碼。但在我們必須工作的時間表上，這對我們來說成為了一個死衚衕。因為我們大部分的產品研究實驗都是有時間限制的，直到證明其價值為止，我們有 2-4 周的開發時間來測試這個想法。llvm wasm 編譯器無法處理生成的 wasm 代碼。通過更多的工作，我們可能會克服這一難題，但我們嘗試了許多優化標誌和使 llvm 編譯器作為 wasmer 插件工作的方法，以將此代碼預編譯為 llvm，但我們沒有成功。由於 Circom 電路約為 150 萬行代碼，您可以想象到 wasm 的數量會很大。然後，我們將目光轉向嘗試創建一個僅在 C++ 和我們的 Rust 中繼代碼庫之間創建橋樑。這也很快被擊敗了，因為 C++ 包含一些 x86 特定的彙編代碼，我們不想去擺弄。為了將系統公開給公眾，我們最終簡單地啟動了一個使其使用 C++ 代碼但移除了一些依賴的系統。在未來，我們希望擴展另一條我們正在努力的優化線路。那就是將 C++ 代碼實際編譯成執行圖。Circom 編譯的這些 C++ 構件主要只是對具有非常非常大的素數生成器的有限域的模塊化算術。這對於較小、更簡單的 C++ 構件顯示了一些有希望的結果，但需要更多的工作來使其與 Risc0 系統配合。這是因為生成的 C++ 代碼約為 700 萬行代碼，而圖生成器似乎達到了堆棧大小限制，並且提高這些限制似乎會產生其他故障，我們沒有時間確定。儘管其中一些方法沒有取得預期的結果，但我們能夠對開源項目做出貢獻，並希望在某個時候這些貢獻將被合併到上游。
接下來的一系列挑戰更多地涉及設計領域。該系統的一個重要部分是能夠擁有私有輸入。這些輸入需要來自某個地方，並且由於時間限制，我們無法添加一些花哨的 MPC 加密系統，以允許私有輸入在系統中形成閉環。因此，為了滿足這個需求並解除開發人員的阻塞，我們添加了私有輸入服務器的概念，它需要驗證請求者是否通過有效載荷的簽名驗證了當前的索賠者，併為他們提供服務。隨著我們擴展 Bonsol，我們計劃實現一個 MPC 閾值解密系統，通過該系統，中繼節點可以允許索賠者解密私有輸入。所有關於私有輸入的討論都使我們想到了我們計劃在 Bonsol 倉庫中提供的設計演進。那就是 Bonsolace，這是一個更簡單的系統，使您作為開發人員能夠輕鬆地在自己的基礎架構上證明這些 zk 程序。您可以自己證明，然後在與證明網絡相同的合同上進行驗證。這種用例適用於非常高價值的私有數據用例，其中對私有數據的訪問必須儘可能減少。
最後關於 Bonsol 的一點我們還沒有在其他地方使用 Risc0 的地方看到的是，我們強制要求在輸入數據進入 zk 程序時進行承諾（哈希）。我們實際上在合同上檢查了證明者必須承諾的輸入，以確保它與用戶期望併發送到系統中的輸入相匹配。這會產生一些成本，但如果沒有它，意味著證明者可能會作弊，並對用戶沒有指定的輸入運行 zk 程序。Bonsol 的其餘開發工作落入了正常的 Solana 開發中，但應該注意的是，我們有意在那裡嘗試了一些新的想法。在智能合約中，我們使用 flatbuffers 作為唯一的序列化系統。這是一種有些新穎的技術，我們希望將其發展並製作成一個框架，因為它很適合生成跨平臺的 sdk。關於 Bonsol 的最後一點是，它目前需要預編譯才能工作得最有效，這個預編譯計劃將在 Solana 1.18 中實現，但在那之前，我們正在努力看看團隊是否對此研究感興趣，並且超越 Bonsol 探索其他技術。
總結
除了 Bonsol，Anagram 構建團隊還深入研究了 VC 領域的許多地方。像 Jolt、zkllvm、spartan 2、Binius 這樣的項目是我們正在跟蹤的項目，還有在全同態加密（FHE）領域工作的公司。
請查看 Bonsol 軟件庫，併為您需要的示例或您想要擴展它的方式提出問題。這是一個非常早期的項目，您有機會大顯身手。
如果您正在進行有趣的 VC 項目，請申請 Anagram EIR 計劃。
