Anagram Build團隊主要從事新加密技術的研究並將其應用於具體產品。最近,我們的研究圍繞可驗證計算(VC),並基於此研究開發了一種名爲 Bonsol的開源系統。我們選擇深入這一領域,是因爲VC已經顯示出其在多個L1平台上提升成本效益和可擴展性的巨大潛力。
本文有兩個目標:
雖然“可驗證計算”一詞可能不常見於牛市時期初創公司的投資簡報中,“零知識”則更爲常見。可驗證計算(VC)指的是以某種方式運行特定任務,生成一個可以公開驗證的證明,而無需重復計算過程。而零知識(ZK)則是在不完全公開數據或輸入的情況下,證明某數據或計算的真實性。雖然這兩個概念在現實中經常被混淆,但應該注意,零知識更多關注於選擇哪些信息公開以證實某種聲明,而可驗證計算則是衆多現代分布式系統架構追求的更準確的目標。
那麼,爲什麼我們要在Solana和Ethereum等平台上引入VC或ZK系統呢?這主要是考慮到開發者的安全需求。系統開發者需要在終端用戶對技術的盲信與技術實際功能之間架起橋梁。使用ZK/VC技術,開發者能夠減少潛在的安全風險。VC系統通過將信任焦點轉移到證明系統及其計算任務上,改變了原有的信任模式。這種從傳統Web2到Web3區塊鏈模式的信任轉移,意味着從依賴企業承諾轉向信賴開源代碼及網路加密體系。
例如,採用ZK登入系統的開發者比那些僅驗證加密屬性的系統的開發者承擔更少的安全維護責任。VC技術被應用於許多需要確保共識的場合,其核心是驗證數學的正確性而不是其他因素。雖然市場上已有許多VC和ZK的成功應用,但許多應用仍依賴於加密軟件各層面的持續開發,以實現足夠的速度和效率,使其適合正式投入使用。
在Anagram,我們通過與許多加密項目創始人和開發者的交流,了解到當前加密技術棧的局限性如何阻礙了產品創新。我們的討論揭示了一個趨勢,即許多項目正將鏈上邏輯轉移到鏈外,以應對成本過高或需引入復雜業務邏輯的問題。開發者正努力尋找合適的系統和工具,以平衡產品開發中鏈上與鏈外的部分,使之更加強大。在這一過程中,VC技術成爲連接鏈上與鏈外世界,採用可信且可驗證方式的關鍵技術。
VC和ZK功能現在主要在替代性計算層上進行,這些計算層包括Rollups、側鏈、中繼、預言機或輔助處理器等,它們通過智能合約運行時的回調來提供服務。爲了實現這一流程,許多L1鏈條都在開發旨在繞過智能合約運行時的快捷方式,如系統調用或預編譯,以執行那些在鏈上成本過高的操作。
目前的VC系統有幾種主流模式。以下是我了解的四種主要模式。在這些模式中,除了最後一種,ZK證明都是在鏈下完成的,但它們的優勢在於證明的驗證地點和時間。
對於那些可以生成較小證明的VC和ZK證明系統,例如Groth16或某些Plonk變體,這些證明將提交到鏈上,並使用之前部署的代碼在鏈上進行驗證。這種系統現在非常普遍,使用Circom和Groth16驗證器在Solana或EVM上進行嘗試是一種很好的方法。不過,這些系統的缺點是運行速度很慢,通常還需要學習新的編程語言。例如,在Circom中驗證一個256位的哈希值,實際上需要手動處理這256位的每一位。雖然有許多庫可以讓你直接調用哈希函數,但實際上你需要在你的Circom代碼中重寫這些函數。當你的應用場景中ZK和VC的部分較小時,這些系統非常有用,你需要在執行某些其他確定性操作之前驗證證明的有效性。目前,Bonsol就屬於這一類系統。
這種驗證方式將證據上傳到區塊鏈,以便所有參與方都能看到並利用鏈下計算進行驗證。這種模式允許使用任何驗證系統,但因爲驗證過程不在鏈上進行,所以無法保證依賴於該證據的任何操作的確定性。這種方式適合於那些有挑戰期的系統,在這期間參與者可以挑戰證據的正確性。
在這個模式下,證據被上傳到一個專門的驗證網路,該網路作爲一個預言機調用智能合約。這樣可以確保操作的確定性,但同時需要對驗證網路持有信任。
這是一種與衆不同的驗證模式,驗證和證明過程完全在鏈上同步進行。在這種模式下,L1或L1上的智能合約可以直接處理用戶的私有數據,使用零知識證明技術來確保執行的正確性。這種方法在現實中應用不廣,通常只限於執行一些基本的數學操作。
這四種驗證模式目前正在多個區塊鏈生態系統中進行試驗,未來我們將觀察到哪些新模式的出現以及哪一種將成爲主導。比如,在Solana上目前還沒有一個統治模式,而整個VC和ZK領域還處於初期階段。多個鏈,包括Solana,普遍採用的是第一種模式。全鏈上驗證雖然是公認的最佳模式,但正如討論的那樣,它存在一些問題,尤其是在延遲和電路功能限制方面。接下來,當我們詳細介紹Bonsol時,你會發現它基本遵循第一種模式,但稍作修改。
歡迎了解Bonsol,這是一個由我們Anagram團隊開發並公開源代碼的Solana原生VC系統。Bonsol允許開發者在私有和公開數據上創建可驗證的執行文件,並將結果集成進Solana的智能合約。注意,這個項目基於流行的RISC0工具鏈構建。
這個項目的啓發來自我們與多個合作項目每週都會提出的問題:“如何能在鏈上使用私有數據並進行驗證?”雖然具體問題各不相同,但所有問題的共同點在於:減少對中心化系統的依賴。
在深入了解系統細節之前,我們將通過兩個獨特的使用案例來展示Bonsol的強大功能。
有一款Dapp允許用戶購買參與各種代幣池的抽獎活動的門票。這些池每天會從一個全球代幣池中進行”分配”,分配過程中會隱藏各代幣的具體金額。用戶可以購買對池中特定代幣範圍的訪問權。但是有個限制:一旦用戶決定購買這個範圍,它就會同時對所有用戶公開。用戶隨後需要決定是否真的購買這張抽獎票。他們可以選擇放棄,認爲這次購買不劃算,或者通過購買門票來確保自己在池中的份額。
當涉及到創建池及用戶爲公開所購範圍支付費用時,Bonsol就發揮作用了。在池創建或分配時,ZK程序會處理每種代幣分配數量的隱私數據。這一證明確認了從全球池到當前池的隨機選擇,並對餘額進行了承諾。這個證明會被鏈上的合約接收和驗證,並保存這些數據,確保當池關閉並將代幣分配給抽獎票持有者時,可以證明代幣數量從開始至結束未被更改。
當用戶選擇公開某個隱藏的代幣範圍時,ZK程序將用代幣實際餘額作爲私密輸入,生成一系列被承諾的值和證明。這個過程的公開數據包括之前的池創建證明及其結果。這樣可以保證整個系統的可靠性,確保之前的證明在新的範圍驗證中有效,並且代幣的餘額與初次承諾的值一致。這個範圍的證明也會被記錄在鏈上,並使得所有參與者都可見這個範圍。盡管有許多方法可以實現這種抽獎系統,但Bonsol的特性讓舉辦方幾乎不需要贏得太多信任即可操作,這一點非常便利。同時,它還強調了Solana和VC系統之間的互通性。Solana的智能合約在構建這種信任機制中扮演了關鍵角色,通過驗證這些證明並允許後續操作的執行。
Bonsol平台允許開發者創建基礎功能模塊,供其他系統使用。開發者可以編寫特定的零知識證明(ZK)程序並將其部署到Bonsol的網路中。這些網路運營商會評估每一個ZK程序的執行請求是否具有經濟效益,例如程序的計算需求、輸入數據的大小以及請求者提供的激勵金額等。
開發者可以設置ZK程序所需的輸入數據類型和順序,甚至預先配置輸入集,使得這些基礎模塊能夠在處理大型數據集時驗證計算過程。
以NFT爲例,開發者可能創建一個系統,通過鏈上驗證機制證實某個NFT的所有權轉移涉及特定的錢包組。開發者可以預設包含大量交易歷史的輸入數據集,讓程序能找到對應的所有者信息。雖然這只是一個例子,實際應用可以多種多樣。
另一個例子是,開發者可能開發一個ZK程序來驗證某個密鑰對籤名是否來自指定的密鑰對集,而不暴露任何公鑰信息。如果這種程序被許多其他Dapps採用,那麼它的創作者可以從中獲得小額的使用費。由於高效性能是關鍵,開發者會被激勵優化他們的程序以吸引運營商使用。並且,如果其他開發者想要使用該程序,他們需要修改程序來滿足自己的需求,這種機制雖然不是絕對安全,但能夠一定程度上確保創新者得到應有的回報。
讓我們探索Bonsol平台的架構、激勵機制和操作流程。以下情景描繪了一個用戶通過Dapp進行可驗證計算的過程:
用戶發起一個包含ZK程序詳情、輸入數據、驗證時限及激勵費用(即中繼節點的報酬)的執行請求。該請求由中繼節點接手,他們需要迅速判斷是否接受此任務並開始驗證過程。中繼節點會根據自身的處理能力和激勵的價值,決定是否接受任務。一旦他們決定接受並能首先成功認領任務,他們提交的證明便被暫時接受。如果他們未能在規定時間內提交證明,其他節點則有機會接手此任務。中繼節點爲了認領任務,需要支付一定的保證金(相當於激勵費用的一半),如果驗證失敗,這部分保證金將被扣除。
Bonsol是基於一個觀點構建的:計算處理將越來越多地轉移到鏈上進行驗證,而Solana將成爲實現VC和ZK技術的首選平台。Solana的快速交易處理、低成本的計算能力及日益增長的用戶羣體,使其成爲測試這些概念的理想場所。
在Solana上驗證Risco0證明的過程中,我們面臨的主要挑戰是如何在不損害安全性的前提下減小其大小。我們採用了Circom工具,並將Risc0 Stark包裝在Groth16證明中,這種包裝方式固定輸出爲256字節。雖然Risc0提供了一些早期工具,但這大大增加了系統的復雜度和依賴性。
當我們開始構建 Bonsol 並使用現有工具將 Stark 與 Snark 包裝起來時,我們尋求減少依賴性和提高速度的方法。 Circom 允許將 Circom 代碼編譯爲 C++ 或 wasm。我們首先嘗試將 Circcom 電路編譯爲 LLVM 生成的 wasmu 文件。這是使 Groth16 工具便攜且快速的最快、最有效的方法。我們選擇 wasm 是因爲它的可移植性,因爲 C++ 代碼依賴於 x86 cpu 架構,這意味着新的 Macbook 或基於 Arm 的服務器將無法使用它。但這在我們必須合作的時間表上成爲了我們的死胡同。因爲我們的大多數產品研究實驗都有時間限制,直到證明其價值,所以我們有 2-4 周的開發時間來測試這個想法。 llvm wasm 編譯器無法處理生成的 wasm 代碼。通過更多的工作,我們本可以克服這個問題,但我們嘗試了許多優化標志和方法來讓 llvm 編譯器作爲 wasmer 插件工作,以將此代碼預編譯到 llvm 中,但我們沒有成功。因爲 Circcom 電路大約有 150 萬行代碼,所以可以想象 Wasm 的數量變得巨大。然後,我們將目光轉向嘗試在 C++ 和 Rust 中繼代碼庫之間創建一座橋梁。這也很快遭到失敗,因爲 C++ 包含一些我們不想擺弄的 x86 特定匯編代碼。爲了讓系統向公衆開放,我們最終只是以使用 C++ 代碼但刪除了一些依賴項的方式引導系統。未來,我們希望擴展我們正在研究的另一條優化路線。那就是獲取 C++ 代碼並將其實際編譯成執行圖。這些來自 Circcom 編譯的 C++ 工件大多只是對有限域 用一個非常非常大的素數作爲生成器。這爲更小、更簡單的 C++ 工件展示了一些有希望的結果,但需要做更多的工作才能使其與 Risc0 系統一起運行。這是因爲生成的 C++ 代碼大約有 700 萬行代碼,並且圖形生成器似乎達到了堆棧大小限制,並且引發這些問題似乎會產生我們還沒有時間確定的其他錯誤。盡管其中一些途徑沒有成功,但我們能夠爲 OSS 項目做出貢獻,並希望在某個時候這些貢獻將被上遊化。
接下來的設計挑戰更爲復雜。這個系統的核心在於能處理私有數據輸入。這些數據必須有可靠的來源,但由於時間限制,我們未能加入高級的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)計劃,你將有機會與Anagram團隊一道驗證你的想法、創辦公司,並挑戰最大的問題。我們歡迎你的任何貢獻和問題。
1.本文轉載自[Anagram],所有版權歸原作者[austbot]所有。若對本次轉載有異議,請聯系Gate Learn,團隊會根據相關流程盡速處理。
2、免責聲明:本文所表達的觀點和意見僅代表作者個人觀點,不構成任何投資建議。
3.文章其他語言版本由Gate Learn團隊翻譯。除非另有說明,否則禁止復制、傳播或抄襲經翻譯文章。
Anagram Build團隊主要從事新加密技術的研究並將其應用於具體產品。最近,我們的研究圍繞可驗證計算(VC),並基於此研究開發了一種名爲 Bonsol的開源系統。我們選擇深入這一領域,是因爲VC已經顯示出其在多個L1平台上提升成本效益和可擴展性的巨大潛力。
本文有兩個目標:
雖然“可驗證計算”一詞可能不常見於牛市時期初創公司的投資簡報中,“零知識”則更爲常見。可驗證計算(VC)指的是以某種方式運行特定任務,生成一個可以公開驗證的證明,而無需重復計算過程。而零知識(ZK)則是在不完全公開數據或輸入的情況下,證明某數據或計算的真實性。雖然這兩個概念在現實中經常被混淆,但應該注意,零知識更多關注於選擇哪些信息公開以證實某種聲明,而可驗證計算則是衆多現代分布式系統架構追求的更準確的目標。
那麼,爲什麼我們要在Solana和Ethereum等平台上引入VC或ZK系統呢?這主要是考慮到開發者的安全需求。系統開發者需要在終端用戶對技術的盲信與技術實際功能之間架起橋梁。使用ZK/VC技術,開發者能夠減少潛在的安全風險。VC系統通過將信任焦點轉移到證明系統及其計算任務上,改變了原有的信任模式。這種從傳統Web2到Web3區塊鏈模式的信任轉移,意味着從依賴企業承諾轉向信賴開源代碼及網路加密體系。
例如,採用ZK登入系統的開發者比那些僅驗證加密屬性的系統的開發者承擔更少的安全維護責任。VC技術被應用於許多需要確保共識的場合,其核心是驗證數學的正確性而不是其他因素。雖然市場上已有許多VC和ZK的成功應用,但許多應用仍依賴於加密軟件各層面的持續開發,以實現足夠的速度和效率,使其適合正式投入使用。
在Anagram,我們通過與許多加密項目創始人和開發者的交流,了解到當前加密技術棧的局限性如何阻礙了產品創新。我們的討論揭示了一個趨勢,即許多項目正將鏈上邏輯轉移到鏈外,以應對成本過高或需引入復雜業務邏輯的問題。開發者正努力尋找合適的系統和工具,以平衡產品開發中鏈上與鏈外的部分,使之更加強大。在這一過程中,VC技術成爲連接鏈上與鏈外世界,採用可信且可驗證方式的關鍵技術。
VC和ZK功能現在主要在替代性計算層上進行,這些計算層包括Rollups、側鏈、中繼、預言機或輔助處理器等,它們通過智能合約運行時的回調來提供服務。爲了實現這一流程,許多L1鏈條都在開發旨在繞過智能合約運行時的快捷方式,如系統調用或預編譯,以執行那些在鏈上成本過高的操作。
目前的VC系統有幾種主流模式。以下是我了解的四種主要模式。在這些模式中,除了最後一種,ZK證明都是在鏈下完成的,但它們的優勢在於證明的驗證地點和時間。
對於那些可以生成較小證明的VC和ZK證明系統,例如Groth16或某些Plonk變體,這些證明將提交到鏈上,並使用之前部署的代碼在鏈上進行驗證。這種系統現在非常普遍,使用Circom和Groth16驗證器在Solana或EVM上進行嘗試是一種很好的方法。不過,這些系統的缺點是運行速度很慢,通常還需要學習新的編程語言。例如,在Circom中驗證一個256位的哈希值,實際上需要手動處理這256位的每一位。雖然有許多庫可以讓你直接調用哈希函數,但實際上你需要在你的Circom代碼中重寫這些函數。當你的應用場景中ZK和VC的部分較小時,這些系統非常有用,你需要在執行某些其他確定性操作之前驗證證明的有效性。目前,Bonsol就屬於這一類系統。
這種驗證方式將證據上傳到區塊鏈,以便所有參與方都能看到並利用鏈下計算進行驗證。這種模式允許使用任何驗證系統,但因爲驗證過程不在鏈上進行,所以無法保證依賴於該證據的任何操作的確定性。這種方式適合於那些有挑戰期的系統,在這期間參與者可以挑戰證據的正確性。
在這個模式下,證據被上傳到一個專門的驗證網路,該網路作爲一個預言機調用智能合約。這樣可以確保操作的確定性,但同時需要對驗證網路持有信任。
這是一種與衆不同的驗證模式,驗證和證明過程完全在鏈上同步進行。在這種模式下,L1或L1上的智能合約可以直接處理用戶的私有數據,使用零知識證明技術來確保執行的正確性。這種方法在現實中應用不廣,通常只限於執行一些基本的數學操作。
這四種驗證模式目前正在多個區塊鏈生態系統中進行試驗,未來我們將觀察到哪些新模式的出現以及哪一種將成爲主導。比如,在Solana上目前還沒有一個統治模式,而整個VC和ZK領域還處於初期階段。多個鏈,包括Solana,普遍採用的是第一種模式。全鏈上驗證雖然是公認的最佳模式,但正如討論的那樣,它存在一些問題,尤其是在延遲和電路功能限制方面。接下來,當我們詳細介紹Bonsol時,你會發現它基本遵循第一種模式,但稍作修改。
歡迎了解Bonsol,這是一個由我們Anagram團隊開發並公開源代碼的Solana原生VC系統。Bonsol允許開發者在私有和公開數據上創建可驗證的執行文件,並將結果集成進Solana的智能合約。注意,這個項目基於流行的RISC0工具鏈構建。
這個項目的啓發來自我們與多個合作項目每週都會提出的問題:“如何能在鏈上使用私有數據並進行驗證?”雖然具體問題各不相同,但所有問題的共同點在於:減少對中心化系統的依賴。
在深入了解系統細節之前,我們將通過兩個獨特的使用案例來展示Bonsol的強大功能。
有一款Dapp允許用戶購買參與各種代幣池的抽獎活動的門票。這些池每天會從一個全球代幣池中進行”分配”,分配過程中會隱藏各代幣的具體金額。用戶可以購買對池中特定代幣範圍的訪問權。但是有個限制:一旦用戶決定購買這個範圍,它就會同時對所有用戶公開。用戶隨後需要決定是否真的購買這張抽獎票。他們可以選擇放棄,認爲這次購買不劃算,或者通過購買門票來確保自己在池中的份額。
當涉及到創建池及用戶爲公開所購範圍支付費用時,Bonsol就發揮作用了。在池創建或分配時,ZK程序會處理每種代幣分配數量的隱私數據。這一證明確認了從全球池到當前池的隨機選擇,並對餘額進行了承諾。這個證明會被鏈上的合約接收和驗證,並保存這些數據,確保當池關閉並將代幣分配給抽獎票持有者時,可以證明代幣數量從開始至結束未被更改。
當用戶選擇公開某個隱藏的代幣範圍時,ZK程序將用代幣實際餘額作爲私密輸入,生成一系列被承諾的值和證明。這個過程的公開數據包括之前的池創建證明及其結果。這樣可以保證整個系統的可靠性,確保之前的證明在新的範圍驗證中有效,並且代幣的餘額與初次承諾的值一致。這個範圍的證明也會被記錄在鏈上,並使得所有參與者都可見這個範圍。盡管有許多方法可以實現這種抽獎系統,但Bonsol的特性讓舉辦方幾乎不需要贏得太多信任即可操作,這一點非常便利。同時,它還強調了Solana和VC系統之間的互通性。Solana的智能合約在構建這種信任機制中扮演了關鍵角色,通過驗證這些證明並允許後續操作的執行。
Bonsol平台允許開發者創建基礎功能模塊,供其他系統使用。開發者可以編寫特定的零知識證明(ZK)程序並將其部署到Bonsol的網路中。這些網路運營商會評估每一個ZK程序的執行請求是否具有經濟效益,例如程序的計算需求、輸入數據的大小以及請求者提供的激勵金額等。
開發者可以設置ZK程序所需的輸入數據類型和順序,甚至預先配置輸入集,使得這些基礎模塊能夠在處理大型數據集時驗證計算過程。
以NFT爲例,開發者可能創建一個系統,通過鏈上驗證機制證實某個NFT的所有權轉移涉及特定的錢包組。開發者可以預設包含大量交易歷史的輸入數據集,讓程序能找到對應的所有者信息。雖然這只是一個例子,實際應用可以多種多樣。
另一個例子是,開發者可能開發一個ZK程序來驗證某個密鑰對籤名是否來自指定的密鑰對集,而不暴露任何公鑰信息。如果這種程序被許多其他Dapps採用,那麼它的創作者可以從中獲得小額的使用費。由於高效性能是關鍵,開發者會被激勵優化他們的程序以吸引運營商使用。並且,如果其他開發者想要使用該程序,他們需要修改程序來滿足自己的需求,這種機制雖然不是絕對安全,但能夠一定程度上確保創新者得到應有的回報。
讓我們探索Bonsol平台的架構、激勵機制和操作流程。以下情景描繪了一個用戶通過Dapp進行可驗證計算的過程:
用戶發起一個包含ZK程序詳情、輸入數據、驗證時限及激勵費用(即中繼節點的報酬)的執行請求。該請求由中繼節點接手,他們需要迅速判斷是否接受此任務並開始驗證過程。中繼節點會根據自身的處理能力和激勵的價值,決定是否接受任務。一旦他們決定接受並能首先成功認領任務,他們提交的證明便被暫時接受。如果他們未能在規定時間內提交證明,其他節點則有機會接手此任務。中繼節點爲了認領任務,需要支付一定的保證金(相當於激勵費用的一半),如果驗證失敗,這部分保證金將被扣除。
Bonsol是基於一個觀點構建的:計算處理將越來越多地轉移到鏈上進行驗證,而Solana將成爲實現VC和ZK技術的首選平台。Solana的快速交易處理、低成本的計算能力及日益增長的用戶羣體,使其成爲測試這些概念的理想場所。
在Solana上驗證Risco0證明的過程中,我們面臨的主要挑戰是如何在不損害安全性的前提下減小其大小。我們採用了Circom工具,並將Risc0 Stark包裝在Groth16證明中,這種包裝方式固定輸出爲256字節。雖然Risc0提供了一些早期工具,但這大大增加了系統的復雜度和依賴性。
當我們開始構建 Bonsol 並使用現有工具將 Stark 與 Snark 包裝起來時,我們尋求減少依賴性和提高速度的方法。 Circom 允許將 Circom 代碼編譯爲 C++ 或 wasm。我們首先嘗試將 Circcom 電路編譯爲 LLVM 生成的 wasmu 文件。這是使 Groth16 工具便攜且快速的最快、最有效的方法。我們選擇 wasm 是因爲它的可移植性,因爲 C++ 代碼依賴於 x86 cpu 架構,這意味着新的 Macbook 或基於 Arm 的服務器將無法使用它。但這在我們必須合作的時間表上成爲了我們的死胡同。因爲我們的大多數產品研究實驗都有時間限制,直到證明其價值,所以我們有 2-4 周的開發時間來測試這個想法。 llvm wasm 編譯器無法處理生成的 wasm 代碼。通過更多的工作,我們本可以克服這個問題,但我們嘗試了許多優化標志和方法來讓 llvm 編譯器作爲 wasmer 插件工作,以將此代碼預編譯到 llvm 中,但我們沒有成功。因爲 Circcom 電路大約有 150 萬行代碼,所以可以想象 Wasm 的數量變得巨大。然後,我們將目光轉向嘗試在 C++ 和 Rust 中繼代碼庫之間創建一座橋梁。這也很快遭到失敗,因爲 C++ 包含一些我們不想擺弄的 x86 特定匯編代碼。爲了讓系統向公衆開放,我們最終只是以使用 C++ 代碼但刪除了一些依賴項的方式引導系統。未來,我們希望擴展我們正在研究的另一條優化路線。那就是獲取 C++ 代碼並將其實際編譯成執行圖。這些來自 Circcom 編譯的 C++ 工件大多只是對有限域 用一個非常非常大的素數作爲生成器。這爲更小、更簡單的 C++ 工件展示了一些有希望的結果,但需要做更多的工作才能使其與 Risc0 系統一起運行。這是因爲生成的 C++ 代碼大約有 700 萬行代碼,並且圖形生成器似乎達到了堆棧大小限制,並且引發這些問題似乎會產生我們還沒有時間確定的其他錯誤。盡管其中一些途徑沒有成功,但我們能夠爲 OSS 項目做出貢獻,並希望在某個時候這些貢獻將被上遊化。
接下來的設計挑戰更爲復雜。這個系統的核心在於能處理私有數據輸入。這些數據必須有可靠的來源,但由於時間限制,我們未能加入高級的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)計劃,你將有機會與Anagram團隊一道驗證你的想法、創辦公司,並挑戰最大的問題。我們歡迎你的任何貢獻和問題。
1.本文轉載自[Anagram],所有版權歸原作者[austbot]所有。若對本次轉載有異議,請聯系Gate Learn,團隊會根據相關流程盡速處理。
2、免責聲明:本文所表達的觀點和意見僅代表作者個人觀點,不構成任何投資建議。
3.文章其他語言版本由Gate Learn團隊翻譯。除非另有說明,否則禁止復制、傳播或抄襲經翻譯文章。