Bonsolを紹介：Solana上のZK、検証可能な計算がもたらす新たなユースケースとは？

2024.04.28

共有先

TechFlow厳選深潮セレクト

Bonsolを紹介：Solana上のZK、検証可能な計算がもたらす新たなユースケースとは？

検証可能な計算（VC）とは、特定のワークロードを実行する際にその処理過程の証明を生成する方式であり、この証明は計算を再実行することなく公開的に検証可能である。

2024.04.28 - 07:22:45

bonsol

Web3業界の深掘り報道に専念し潮流を洞察

執筆：Austbot

編集・翻訳：TechFlow

Anagram Build は、通常、新しい暗号化ユースケースの研究と、それらのユースケースを特定の製品に適用することに多くの時間を費やしています。最近の私たちの研究プロジェクトの一つは、検証可能計算（Verifiable Computation, VC）の領域に入りました。この研究を通じて、私たちは Bonsol という新しいオープンソースシステムを作成しました。この分野を選んだのは、検証可能計算が多くの有効なユースケースを提供し、各L1がVCのコスト効率とスケーラビリティの最適化に取り組んでいるためです。

本記事では、以下の2つの目的があります。

まず、VCという概念と、Solanaエコシステムで実現可能なプロダクトについて、より深く理解していただくことです。
次に、私たちの最新作である Bonsol をご紹介します。

検証可能計算（VC）とは何か？

「検証可能計算（Verifiable Compute）」という用語は、好況期のスタートアップ投資資料には登場しないかもしれませんが、「ゼロ知識（Zero-Knowledge, ZK）」という言葉はよく見かけます。では、これらの用語にはどのような意味があるのでしょうか？

検証可能計算（VC）とは、特定のワークロードを実行する際、その実行結果とともに証明を生成できる方法であり、その証明は再計算なしに公開で検証可能である、ということです。一方、「ゼロ知識（ZK）」とは、データや計算に関する主張を、すべての入力情報やデータを開示せずに証明できることを指します。現実世界では、これらの用語はしばしば混同されており、ZKという名称自体もやや誤解を招く部分があります。むしろ、どの情報を公開して主張を証明するかという「選択」に関わるものと言えます。この点から、VCの方が正確な用語であり、既存の多くの分散システムアーキテクチャの全体的な目標でもあります。

VCはどのようにしてより良い暗号化製品の構築を支援するのか？

なぜ Solana や Ethereum などのプラットフォームに VC や ZK システムを導入したいのでしょうか？その答えは、開発者のセキュリティに関係していると言えるでしょう。システムの開発者は、ユーザーがブラックボックスとして信頼するものと、その信頼性を客観的に保証する技術的機能との間の中継点となります。ZK/VC 技術を利用することで、開発者は製品における攻撃面を削減できます。VC システムは、信頼の中心を「証明システム」と「証明される計算ワークロード」に移すのです。これは、従来の Web2 のクライアント／サーバー方式から、Web3 ブロックチェーン方式への移行時に起こる「信頼の逆転」と似ています。つまり、企業の約束に依存するのではなく、オープンソースコードとネットワークの暗号学的システムを信じるようになるのです。ユーザーの視点からは、真に「ゼロ信頼」のシステムは存在せず、すべてがブラックボックスのように見えると思います。

たとえば、ZKログインシステムを使用すれば、開発者が安全なデータベースやインフラの維持管理に負う責任が軽減されます。なぜなら、このシステムは特定の暗号的特性が満たされていることだけを検証すればよいからです。VC技術は、必要な合意の条件が数学的に有効であることを保証するために、合意が必要な多くの場面で活用されています。

野外でのVCおよびZKの成功事例は多くありますが、その多くは現在、生産環境で十分に高速かつ効率的になるために、暗号化ソフトウェアスタックのさまざまなレベルでの開発進行に依存しています。

Anagram での私たちの活動の一環として、多数の暗号化起業家や開発者と対話する機会があり、現在の暗号化ソフトウェアスタックの状態が製品革新にどのように影響しているかを把握しています。過去のやり取りから、興味深いトレンドが浮かび上がりました。具体的には、一部のプロジェクトが、オンチェーンの製品ロジックをオフチェーンに移行しようとしているのです。これは、オンチェーン処理が高額すぎるか、または複雑なビジネスロジックを追加する必要があるためです。その結果、これらの開発者は、強力になりつつあるプロダクトのオンチェーンとオフチェーンのバランスを取るためのツールやシステムを求めることになります。ここで、VCは、信頼できないが検証可能な方法でオンチェーンとオフチェーンの世界を接続する道筋において、重要な役割を果たします。

現在の VC/ZK システムの仕組み

現在、VCおよびZK関数は、Rollup、サイドチェーン、リレーノード、オラクル、コプロセッサなど、代替的な計算レイヤー上で実行され、スマートコントラクトのランタイムからコールバックによって利用されます。このようなワークフローを実現するため、多くのL1チェーンは、オンチェーンでは高価すぎる操作を可能にするため、スマートコントラクトランタイム外にショートカット（システムコールやプリコンパイルなど）を提供しようと努力しています。

現在のVCシステムにはいくつかの一般的なパターンがあります。私が知っている上位4つを紹介します。最後のケースを除き、ZK証明はオフチェーンで行われますが、証明がいつどこで検証されるかが、それぞれのパターンの利点となっています。

完全にオンチェーンで検証

Groth16やPlonkの亜種など、小さな証明を生成できるVCおよびZK証明システムでは、証明がチェーン上に提出され、事前にデプロイされたコードによってオンチェーンで検証されます。このようなシステムは現在非常に一般的です。この手法を試す最も良い方法は、CircomとSolanaまたはEVM上のGroth16検証器を使用することです。ただし、これらの証明システムは比較的遅く、新しい言語を学ぶ必要があるという欠点もあります。例えば、Circomで256ビットハッシュを検証するには、256ビットを手動で処理する必要があります。多くのライブラリを使えばハッシュ関数を簡単に呼び出せますが、裏ではCircomコード内でそれらの関数を再実装しなければなりません。ZKおよびVC要素が小さく、他の決定論的操作を行う前に証明が有効であることを保証する必要があるユースケースでは、こういったシステムは非常に優れています。Bonsolは現在、この第一カテゴリに属しています。

オフチェーンで検証

証明はチェーン上に提出され、すべての当事者がそれを確認できるようにしますが、実際に検証はオフチェーンで後から行われます。このモードでは、任意の証明システムをサポートできますが、証明がオンチェーンで検証されないため、証明の提出に基づく操作に対して同じレベルの確定性を得られません。挑戦ウィンドウを持つシステムに適しており、当事者が「否決」して証明が不正であることを示そうとする場合に有効です。

検証ネットワーク

証明は検証ネットワークに提出され、そのネットワークがスマートコントラクトを呼び出すオラクルとして機能します。確定性は得られますが、同時に検証ネットワークを信用する必要もあります。

同期的オンチェーン検証

第四番目、そして最後のパターンはかなり異なります。この場合、証明と検証が同時にオンチェーンで行われます。つまり、L1またはその上のスマートコントラクトが、ユーザーの入力に対してZKスキームを実行し、非公開データ上での実行を証明できるようになります。これに関する広範な事例はあまりなく、通常この方法でできることはより基本的な数学演算に制限されます。

まとめ

これら4つのパターンは、さまざまなチェーンエコシステムでテストされており、新たなパターンが現れるかどうか、またどのパターンが主流になるかを見守る必要があります。たとえば、Solanaではまだ明確な勝者がおらず、VCおよびZKの景観は初期段階にあります。Solanaを含む多くのチェーンで最も人気のあるアプローチは、最初のパターン、つまり完全にオンチェーンで検証する方法です。これはゴールデンスタンダードですが、前述したように、遅延や回路の機能制限といった欠点もあります。Bonsolの詳細を見ていくと、この第一のパターンに従っていますが、いくつかの違いがあります。

Bonsolのご紹介

Bonsol は、Anagram が構築しオープンソース化した、Solanaネイティブの新しいVCシステムです。Bonsol を使用すると、開発者は非公開データと公開データを扱う検証可能な実行ファイルを作成し、その結果を Solana スマートコントラクトに統合できます。なお、このプロジェクトは人気のある RISC0 ツールチェーンに依存しています。

このプロジェクトの着想は、毎週多数のプロジェクトと交流する中で繰り返し聞かれた質問から生まれました。「私は非公開データを使って、オンチェーンでそれが正しいことをどうやって証明できるでしょうか？」状況により「それ」の内容は異なりますが、根底にある願いは共通しています。すなわち、中央集権的な依存を減らしたいというものです。

システムの詳細に入る前に、2つの異なるユースケースを通して、Bonsolの強みを説明しましょう。

シナリオ1

Dappが、さまざまなトークンプール内の宝くじの購入をユーザーに許可します。これらのプールは毎日グローバルプールから「傾斜」され、プール内の金額（各トークンの量）が非表示になります。ユーザーは、プール内のトークンの範囲について、徐々により具体的な情報を購入できます。ただし、条件があります。一度ユーザーがその範囲を購入すると、それはすべてのユーザーに公開されます。その後、ユーザーは宝くじを購入するかどうかを判断します。購入価値がないと判断するかもしれませんし、宝くじを購入してプール内での自分の利益を確保するかもしれません。

プールの作成時、およびユーザーが範囲の購入を行う際に、Bonsolが機能します。プールの作成／傾斜時には、ZKプログラムが各トークンの数量という非公開入力を受信します。トークンの種類とプールアドレスは公開入力です。証明は、グローバルプールから現在のプールへランダムに選ばれたことの証明です。証明には残高へのコミットメントも含まれます。オンチェーンのコントラクトはこの証明を受け取り、検証を行い、コミットメントを保存します。最終的にプールが閉鎖され、グローバルプールから当選者に残高が送られるとき、プール開始時のランダム選択以降にトークン数量が変化していないかを検証できます。

ユーザーが非表示のトークン残高範囲の「開示」を購入するとき、ZKプログラムは実際のトークン残高を非公開入力として受け取り、一連の数値を生成して証明とともにコミットします。このZKプログラムの公開入力は、以前のプール作成証明とその出力です。このようにして、システム全体が検証されます。以前の証明は範囲証明内で検証されなければならず、トークン残高は最初の証明でコミットされた値と同じハッシュ値になる必要があります。範囲証明もオンチェーンに提出され、前述のようにすべての参加者に可視化されます。

このような宝くじシステムを実現する方法は他にもありますが、Bonsolの特徴により、抽選主催者に対する信頼要件が非常に低くなります。また、SolanaとVCシステムの相互運用性も強調されます。Solanaプログラム（スマートコントラクト）は証明を検証し、次のアクションを許可することで、信頼の形成に重要な役割を果たします。

シナリオ2

Bonsol は、開発者が他のシステムが利用できるツールキットを作成することを可能にします。Bonsolには「デプロイ」という概念があり、開発者はZKプログラムを作成し、Bonsolのオペレーターにデプロイできます。Bonsolネットワークのオペレーターは、ZKプログラムの実行リクエストが経済的に有利かどうかを評価する基本的な手段を持っています。彼らは、ZKプログラムがどれくらいの計算量を必要とするか、入力サイズ、リクエスターが提供するチップの額といった基本情報を確認できます。開発者は、他の多くのDappが使いたいと思うようなツールキットをデプロイできます。

ZKプログラムの設定において、開発者は必要な入力の順序とタイプを指定します。開発者は、一部またはすべての入力を事前設定したInputSetを公開できます。つまり、非常に大規模なデータセット上で計算の検証を支援する形で、ユーザー向けに部分的な入力を設定できるのです。

たとえば、NFTに基づいて、特定のウォレット群を含む所有権の移転をオンチェーンで証明できるシステムを作成したとします。開発者は、大量の履歴取引情報を含む事前設定された入力セットを持つことができます。ZKプログラムはそのセット内を検索し、一致する所有者を見つけます。これは人工的な例ですが、多くの方法で実現可能です。

別の例を考えましょう。開発者が、ある鍵ペアまたは階層型鍵ペアからの署名を、その公钥を明かさずに検証できるZKプログラムを作成できるとします。これが多くの他のDappにとって有用であり、それらがこのZKプログラムを利用する場合、プロトコルは作者にわずかな使用料（チップ）を支払います。性能が重要であるため、開発者はプログラムを高速に動作させるインセンティブを持ち、オペレーターが実行を望むようになります。一方、他の開発者の作業を模倣しようとする者は、ZKプログラムの内容を検証するために何らかの変更を加える必要があり、その操作の追加は性能に影響を与えます。これは完全に信頼できるわけではありませんが、開発者が革新によって報酬を得ることを助ける可能性があります。

Bonsol アーキテクチャ

これらのユースケースはBonsolの用途を説明するのに役立ちますが、現在のアーキテクチャ、インセンティブモデル、実行フローを見てみましょう。

上記の図は、ユーザーが何らかの検証可能な計算を実行する必要がある流れを表しており、通常はユーザーに何らかの操作を求めるdappによって実現されます。これは実行リクエストの形を取り、実行されるZKプログラム、入力または入力セット、計算が証明されるべき時間枠、およびチップ（これは中継手数料の支払い方法）に関する情報を含みます。リクエストは中継ノードによって拾われ、誰がその実行の所有権を主張し、証明を開始するかを競います。特定の中継オペレーターの能力に応じて、チップが見合わない、またはZKプログラムや入力が大きすぎる場合は、放棄を選ぶこともできます。計算を実行すると決めた場合、その実行を主張する必要があります。もし最初に主張したのが自分であれば、一定時間までその証明が受け入れられます。所定の時間内に証明を生成できなかった場合、他のノードが実行を主張できます。主張するには、現在ハードコードで「チップの半分」に設定された保証金を提供する必要があり、正しい証明を生成できなかった場合には没収されます。

Bonsolの構築は、「より多くの計算が、その検証が行われオンチェーンで検証される層に移行し、SolanaがまもなくVCおよびZKの主要チェーンとなるだろう」という主張に基づいています。Solanaの高速トランザクション、安価な計算、成長し続けるユーザーベースは、これらのアイデアをテストするための理想的な場所です。

簡単に構築できたのか？もちろん、そうではありません！

Bonsolの構築には課題がなかったわけではありません。Risc0の証明をSolanaに持ち込み、そこで検証するには、証明を小さくする必要がありました。しかし、安全性を犠牲にすることなくそれを行うことはできません。そこで、Risc0 StarkをCircomでラップし、約200KBのStarkを、常に256バイトのサイズに保てるGroth16証明にさらにラップしました。幸運にも、Risc0はこれを支援する初期ツールを提供していましたが、システムに多くのオーバーヘッドと依存関係を追加しました。

Bonsolの構築を始め、既存のツールを使ってStarkをSnarkでラップしていたとき、依存関係を減らし、速度を向上させる方法を探りました。Circomは、C++やwasmにコンパイルできます。まず、Circom回路をLLVMが生成するwasmuファイルにコンパイルする方法を試みました。これはGroth16ツールキットをポータブルかつ高速に保つ最も迅速かつ効率的な方法でした。ポータビリティのためwasmを選択しましたが、C++コードはx86 CPUアーキテクチャに依存しており、新しいMacbookや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プログラムを証明できるようにします。自分で証明を行い、証明ネットワークと同じコントラクト上で検証できます。このユースケースは、極めて高価値な非公開データを扱う場合に適しており、非公開データへのアクセスを最小限に抑える必要があります。

最後に、Risc0を他の場所で使用しているのとは異なり、Bonsolでは、入力データがzkプログラムに入る時点でコミットメント（ハッシュ）を強制しています。実際に、証明者がコミットすべき入力が、ユーザーが期待してシステムに送信したものと一致しているかをコントラクト上でチェックしています。これにはコストがかかりますが、これをしないと、証明者がユーザーが指定しなかった入力に対してzkプログラムを実行する可能性があります。Bonsolの残りの開発作業は通常のSolana開発の範疇に入りますが、そこにいくつかの新しいアイデアを意図的に試していることに注意してください。スマートコントラクトでは、flatbuffersを唯一のシリアライズシステムとして使用しています。これはやや新しく、跨プラットフォームSDKの生成に適しているため、将来的にフレームワークとして育てていきたいと考えています。Bonsolについて最後に述べると、現在は最大限の効率を得るために事前コンパイルが必要ですが、この機能はSolana 1.18で実装される予定です。それまでは、チームがこの研究に興味を持つか、Bonsolを超えて他の技術を探求するかを見極めています。