Anagram Buildは、革新的な暗号プリミティブの研究に大部分の時間を費やし、これらのプリミティブを特定の製品に適用しています。 最近の研究プロジェクトの1つは、私たちを検証可能なコンピュート（VC）の領域に導きました。私たちのチームはこの研究を活用して、新しいオープンソースシステムを作成しました。ボンソル私たちは、VCが可能にする効果的なユースケースの出現と、さまざまなL1でのVCのコスト効率とスケーラビリティの最適化に向けた総力を挙げた取り組みを考慮して、この研究領域を選択しました。

このブログでは、2つの目標があります。

• まず、VCという概念やそれがソラナエコシステムで可能にする製品について、よりよい理解を得ていただきたいと考えています。
• 次に、最新の作品を紹介したいと思います、ボンソル.

Verifiable Computeって、一体何ですか？

「検証可能なコンピューティング」という用語は、牛市スタートアップの投資デッキには登場しないかもしれませんが、「ゼロ知識」という用語は登場します。それでは、これらの用語はどういう意味ですか？

検証可能なコンピューティング（VC）は、再計算することなく公に検証できる動作の証明を生成する方法で特定のワークロードを実行しています。ゼロ知識（ZK）は、データや計算に関する文を証明する能力であり、データのすべてまたは計算への入力のすべてを明らかにすることなく行うことができます。これらの用語は実世界では多少混同されていますが、ZKは多少誤った呼び方です。これは、公開する必要のある情報を選択することとより関係があります。VCはより正確な用語であり、多くの既存の分散システムアーキテクチャの全体的な目標です。

VCがどのようにして私たちがより良い暗号製品を構築するのに役立つのでしょうか？

なぜソラナやイーサリアムのようなプラットフォームの上にVCやZKシステムを追加したいのでしょうか？ 答えは開発者のセキュリティに関するものです。 システムの開発者は、エンドユーザーの信頼とその信頼を客観的に有効にする技術機能との間で仲介者として機能します。 ZK/VCの技術を利用することで、開発者は構築中の製品における攻撃面積を減らすことができます。 VCシステムは、信頼の焦点を証明システムと証明される計算ワークロードに移します。 これは、典型的なweb2クライアント/サーバーアプローチからweb3ブロックチェーンアプローチに移行する際に発生する類似した信頼の逆転です。 信頼は、企業の約束に依存するのではなく、オープンソースコードとネットワークの暗号システムを信頼する方向にシフトします。 ユーザーの視点からは、真のゼロ信頼システムは存在せず、エンドユーザーにとってはすべてがブラックボックスのように思えると主張します。

例えば、ZKログインシステムを使用することで、開発者は、単に暗号化された特性が達成されたことを検証するシステムよりも、安全なデータベースとインフラを維持する責任が少なくなります。VC技術は、合意が必要な多くの場所で適用されており、合意を作成するために必要なのは数学が有効であることだけであることを保証するために使われています。

多くの有望なVCやZKの使用例がある一方で、それらの多くは現在進行中の開発に依存しており、暗号ソフトウェアスタックのすべてのレベルでそれを迅速かつ効率的にするために使用されています。

Anagramの仕事の一環として、暗号通貨の創設者・開発者と話す機会があり、現在の暗号通貨のソフトウェアスタックが製品革新の速度を遅らせている箇所を理解しています。歴史的に、これらの会話は興味深いトレンドを特定するのに役立っています。具体的には、一部のプロジェクトは、オンチェーン製品ロジックをオフチェーンに移行していることが活発化しています。これは、コストが高すぎるため、またはよりエキゾチックなビジネスロジックを追加する必要があるためです。結局、これらの開発者は、開発中の製品のオンチェーンとオフチェーンの部分をバランスさせるシステムやツールを見つけようとしており、これらの部分はますます強力になっています。ここで、VCが重要な役割を果たし、信頼性のある検証可能な方法を使用してオンチェーンとオフチェーンの世界を結びつけるための前進の道筋となります。

いきましょう！では、VC/ZKシステムは今日どのように機能しますか？

VCおよびZK機能は現在、代替コンピュートレイヤー（別名、ロールアップ、サイドチェーン、リレー、オラクル、またはコプロセッサ）で主に実行されており、スマートコントラクトランタイムへのコールバックを介して利用可能です。このワークフローを有効にするために、多くのL1チェーンが、スマートコントラクトランタイム外（例：syscallsまたはprecompiles）で実行することができる作業を進行中です。これにより、オンチェーンでは費用がかかりすぎる作業を行うことができます。

現在のVCシステムにはいくつか共通のモードがあります。私が知っているトップ4つを挙げます。最後のケースを除くすべての場合、ZKプルーフはオフチェーンで行われていますが、それぞれのモードにエッジを与えるのは、プルーフがいつ、どこで検証されるかです。

完全なオンチェーン検証

VCおよびZK証明システムでは、Groth16やいくつかのPlonkのバリエーションなど、小さな証明を生成できるシステムを使用して、その後証明はオンチェーンに提出され、以前に展開されたコードを使用してオンチェーンで検証されます。このようなシステムは今では非常に一般的であり、これを試す最良の方法は、SolanaまたはEVM上のCircomおよびGroth16検証者を使用することです。欠点は、これらの証明システムがかなり遅いことです。通常、新しい言語を学ぶ必要があります。Circomで256ビットのハッシュを検証するには、実際には256ビットごとに手動で処理する必要があります。ハッシュ関数を単に呼び出すことができる多くのライブラリがありますが、裏側では、これらの関数をCircomコードで再実装する必要があります。これらのシステムは、ZKおよびVC要素が小さい場合や、証明が他の決定論的アクションが実行される前に有効である必要がある場合に優れています。Bonsolは現在、この最初のカテゴリに属しています。

オフチェーン検証

証明はチェーンに送信されるため、すべての関係者が証明が存在することを確認し、後でオフチェーンコンピューティングを使用して検証できます。このモードでは、任意の証明システムをサポートできますが、証明はオンチェーンで行われないため、証明の提出に依存するアクションに対して同じ決定論を得ることはできません。これは、当事者が「否定」し、証明が間違っていることを証明しようとすることができる、ある種のチャレンジウィンドウを持つシステムに適しています。

検証ネットワーク

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

オンチェーン同期検証

4番目の最終モードはかなり異なります。この場合、証明および検証が一度に完全にオンチェーンで行われます。これは、L1またはL1のスマートコントラクトが実際にユーザーの入力上でZKスキームを実行でき、実行をプライベートデータ上で証明できる場合です。野生ではそう多くの広範な例がなく、通常、これを使用して行うことができるタイプのことは、より基本的な数学的操作に限定されています。

要約

これらの4つのモードは、さまざまなチェーンエコシステムでテストされており、新しいパターンが現れ、どのパターンが支配的になるかを見ることになります。たとえば、Solanaでは、明確な勝者がいないため、VCとZKの状況は非常に初期段階です。Solanaを含む多くのチェーンで最も一般的な方法は最初のモードです。完全なオンチェーン検証は金の基準ですが、いくつかの欠点もあります。主に遅延があり、回路のできることが制限されます。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プログラムがどれだけの計算を必要とするか、入力サイズ、そしてリクエスターが提示しているチップに関する基本情報を見ることができます。 開発者は、多くの他のDappsが使用したいと考えるプリミティブを展開することができます。

ZKプログラムの構成では、開発者が必要な入力の順序とタイプを指定します。 開発者は、一部またはすべての入力を事前に設定するInputSetをリリースできます。 これは、非常に大規模なデータセット上で計算を検証するのに役立つプリミティブを作成できるように、入力の一部を構成できることを意味します。

例えば、開発者がNFTを与えられたシステムを作成し、所有権の移転が特定の一連のウォレットを含むことをチェーン上で証明できる場合を考えてみましょう。 開発者は、多くの過去の取引情報を含む事前に設定された入力セットを持つことができます。 ZKプログラムは、一致する所有者を見つけるためにセットを検索します。 これは人為的な例ですが、さまざまな方法で行うことができます。

別の例を考えてみましょう: 開発者が、公開鍵の公開鍵または階層化された公開鍵セットから来る公開鍵を明らかにしないで検証できるZKプログラムを書くことができるとします。このZKプログラムが多くの他のDappsに役立つと言いましょう、そして彼らはこのZKプログラムを使用します。プロトコルは、このZKプログラムの著者に少額の使用料を提供します。パフォーマンスが重要であるため、開発者はプログラムを速くすることを動機付けられ、オペレーターがそれを実行したいと思うようにするため、他の開発者の作業を盗もうとする開発者は、ZKプログラムの内容を検証するためにプログラムをいくつか変更する必要があります。ZKプログラムに追加された任意の操作はパフォーマンスに影響を与え、完全に完璧ではないかもしれませんが、これにより、開発者が革新に対して報酬を受け取ることができる可能性が高まります。

ボンソルアーキテクチャ

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

上の画像は、ある種の検証可能な計算を実行する必要があるユーザーからのフローを表しており、これは通常、ユーザーが何らかのアクションを実行できるようにするためにこれを必要とするdappを介して行われます。これは、実行中のZKプログラム、入力または入力セット、計算を証明する必要がある時間、およびチップ(リレーが支払われる方法)に関する情報を含む実行リクエストの形式を取ります。リクエストはリレーによって拾われ、リレーはこの実行を主張して証明を開始するかどうかを決定するために競争しなければなりません。特定のリレーオペレーターの能力に基づいて、チップに価値がない、またはzkprogramまたは入力が大きすぎるために、これを渡すことを選択する場合があります。この計算を実行する場合は、それに対してクレームを実行する必要があります。彼らが最初に請求を受けた場合、彼らの証明は特定の時間まで受け入れられます。時間内に証明を生成できなかった場合、他のノードは実行を主張できます。請求するためには、リレーは、現在チップ/2にハードコードされている杭を立てる必要があり、正しい証明を提出できなかった場合はスラッシュされます。

Bonsolは、より多くの計算が認証され、チェーン上で検証されるレイヤーに移動するというテーゼに基づいて構築されました。そして、SolanaはVCやZKのための「行き先」となるでしょう。Solanaの高速な取引、安価な計算、そして急速に成長するユーザーベースは、これらのアイデアをテストするには優れた場所です。

これを構築するのは簡単でしたか？全然違います！

それはBonsolを構築する際に課題がなかったと言うわけではありません。SolanaでRisco0プルーフを取り、検証するには、それを小さくする必要があります。しかし、それを犠牲にすることなく行うことはできません。その証明のセキュリティ特性を犠牲にせずに行うため、Circomを使用し、Risc0 Starkをラップし、その中には約200kbのものをラップし、常に256バイトになるGroth16プルーフを使用します。幸いにも、Risc0はこれに対するいくつかの新興ツールを提供してくれましたが、それはシステムに多くのオーバーヘッドと依存関係を追加します。

ボンソルを構築し、スタークをスナークで包むための既存のツールを使い始めると、依存を減らして速度を上げる方法を模索しました。Circom では、Circom コードを C++ または wasm にコンパイルできます。まず、Circom 回路を LLVM によって生成された wasmu ファイルにコンパイルしようとしました。これはGroth16の工具細工を携帯用、まだ速くさせる最も速く、最も有効な方法である。C++ コードが x86 CPU アーキテクチャに依存していたため、新しい Mackbooks や Arm ベースのサーバーではこれを使用できないため、移植性のために wasm を選択しました。しかし、これは私たちが取り組まなければならなかったタイムラインの行き止まりになってしまいました。製品研究の実験のほとんどは、その価値が証明されるまで時間区切られているため、このアイデアをテストするために2〜4週間の開発時間がありました。llvm wasm コンパイラは、生成された wasm コードを処理できませんでした。もっと作業すれば、これを乗り越えることができましたが、このコードをllvmにプリコンパイルするために、多くの最適化フラグとllvmコンパイラをwasmerプラグインとして動作させる方法を試しましたが、失敗しました。Circomの回路は約150万行のコードなので、Wasmの量が膨大になったことは想像に難くありません。次に、C++ と Rust リレー コード ベースの間にブリッジを作成することに照準を合わせました。これもまた、C++ には x86 固有のアセンブリ コードが含まれていたため、すぐに敗北しました。システムを一般に公開するために、C++ コードを利用しながら依存関係の一部を削除する方法でシステムをブートストラップすることにしました。将来的には、私たちが取り組んでいる別の最適化のラインを拡張したいと考えています。これは、C++ コードを取得し、実際に実行グラフにコンパイルすることでした。Circom コンパイルのこれらの C++ アーティファクトは、ほとんどが有限体ジェネレータとして非常に非常に大きな素数を使用しています。これは、より小さなシンプルなC++アーティファクトに対していくつか有望な結果を示しましたが、Risc0システムで機能させるためにはさらなる作業が必要です。これは、生成されたC++コードが約700万行のコードであり、グラフジェネレータがスタックサイズ制限に達し、それを引き上げると他の欠陥が発生するようですが、その原因を特定する時間がありませんでした。これらのアプローチのうちいくつかはうまくいかなかったにもかかわらず、OSSプロジェクトに貢献することができ、その貢献がいつかアップストリームに統合されることを願っています。

次の課題は、デザイン空間にあります。このシステムの重要な部分は、プライベートな入力を持てることです。これらの入力はどこかから来る必要があり、時間の制約により、プライベート入力をクローズドループでシステム内に配置できるように、派手なMPC暗号化システムを追加することができませんでした。そこで、このニーズに対処し、開発者のブロックを解除するために、ペイロードの署名によって検証されるリクエスターが証明の現在の請求者であることを検証し、それを提供する必要があるプライベート入力サーバーの概念を追加しました。Bonsolを拡張するにつれて、リレーノードがクレーマンがプライベート入力を復号化できるようにするMPCしきい値復号システムを実装する予定です。プライベート入力に関するこのすべての議論は、Bonsolリポジトリで利用できるようにする予定の設計の進化につながります。これがBonsolaceで、開発者がこれらのzkプログラムを独自のインフラストラクチャで簡単に証明できる、よりシンプルなシステムです。証明者ネットワークに因数分解する代わりに、自分で証明し、証明者ネットワークが使用するのと同じコントラクトで検証することができます。このユースケースは、プライベートデータへのアクセスを何としても最小限に抑える必要がある、非常に価値の高いプライベートデータのユースケース向けです。

Bonsolに関する最後の注意点として、Risc0を使用している他の場所ではまだ見たことがない点が1つあります。それは、入力データに対して(zkプログラムに)ハッシュを強制的にコミットしています。そして、実際に契約で、証明者がコミットする必要があった入力が、ユーザーが期待してシステムに送信したものと一致するかどうかを確認しています。これにはある程度のコストがかかりますが、これがないと、証明者がユーザーが指定しなかった入力に対してzkプログラムを実行して不正をする可能性があります。Bonsolの開発の残りの部分は通常のSolanaの開発に落ち着きましたが、ここで意図的にいくつかの新しいアイデアを試してみたことに注意すべきです。スマートコントラクトでは、flatbuffersを唯一のシリアライゼーションシステムとして使用しています。これは、クロスプラットフォームの自動生成SDKにうまく適合するため、フレームワークに発展させてみたいと考えているやや新しい技術です。Bonsolに関する最後の注意点として、現在効率的に動作するためにはプリコンパイルが必要ですが、このプリコンパイルはSolana 1.18に計画されており、その間に、この研究に興味を持っているチームがいるかどうかを調査しています。

ラッピングアップ

Beyond Bonsol、AnagramビルドチームはVCドメイン内の多くの場所を詳しく調査しています。Jolt、zkllvm、spartan 2、Biniusなどのプロジェクトは、FHE（Fully Homomorphic Encryption）スペースで活動している企業とともに追跡しているプロジェクトです。それが何かわからない場合は、そのうち取り上げる予定なので、ご期待ください。

Bonsolリポジトリをチェックアウトして、必要な例や拡張方法に関する問題を作成してください。 これは非常に早期のプロジェクトですが、あなたは自分の足跡を残すチャンスがあります。

もし面白いVCプロジェクトに取り組んでいるなら、お勧めしますAnagram EIRプログラムの申し込みはこちらAnagram teamと一緒に、あなたのテーゼをテストし、会社を設立し、可能な限り大きな問題に取り組むことができます。ご自由にご貢献いただくか、質問をしてください。

免責事項：

1. この記事は[から転載されていますアナグラム], すべての著作権は元の著者に帰属します [austbot]. If there are objections to this reprint, please contact the Gate Learnチームがすぐに対処します。

2. 責任の免除：この記事で表現されている意見はすべて、著者個人のものであり、投資アドバイスを構成するものではありません。

3. 他の言語への記事の翻訳は、Gate Learnチームによって行われます。特に記載がない限り、翻訳された記事のコピー、配布、または盗用は禁止されています。