ゼロ知識証明：Solanaでの応用
このシリーズの記事をレビューしてくださったMatt、Porter、Nick、Swen、bl0ckpainに心より感謝します。
はじめに
この記事は、ゼロ知識証明の入門シリーズ第2回です。本記事の分析を支える理論、数学、暗号技術の背景を理解するため、先にゼロ知識証明：基礎入門を読むことを強くおすすめします。本記事はその知識を前提としているため、ゼロ知識証明に詳しくない場合は、先にそちらの記事をお読みください。本記事の目的は、Solanaにおけるゼロ知識証明の議論に参加し、さらには革新的なゼロ知識プリミティブの開発へ進むために必要な知識を身につけてもらうことです。
この新たな知識を得たことで、ようやく問いかけられます。ゼロ知識証明とは何でしょうか？Solanaではどのように使われているのでしょうか？
ゼロ知識証明とは？
必要な理論、数学、暗号技術を身につけた今、いよいよ次の問いに進みましょう。ゼロ知識証明とは、正確には何なのでしょうか？
ゼロ知識証明とは、ある当事者が別の当事者に対し、特定の命題が真であるという事実以外の追加情報を一切明かさずに、その命題が真であることを証明できる暗号学的プロセスです。この証明には、統計的な健全性、完全性、情報漏えいに対する安全性が求められます。
ゼロ知識で証明したい命題には2つの種類があります。大きく分けると、次のとおりです。
- 事実に関する命題（例：この特定のグラフは3彩色可能である）
- 知識に関する命題（例：私はNの因数分解を知っている）
1つ目の命題は、究極的には宇宙に内在する性質、つまり1 + 1 = 2のように根本的に真である事柄に関するものです。2つ目の命題は、知識証明と呼ばれます。これは、単に何かが真であることを証明するだけでなく、証明者が知っている内容に依存します。
前述のとおり、これらの命題を証明する方法には、対話型と非対話型があります。対話型ゼロ知識証明では、検証者が合理的な疑いを超えて納得するまで、証明者と検証者が複数回のやり取りを行います。Zcashは、ユーザーが匿名トランザクションを行えるようにするため、非対話型ゼロ知識証明を使用しています。
一方、非対話型ゼロ知識証明では、証明者と検証者が直接やり取りすることなく、証明がオフラインで渡されます。証明者は必要な情報をすべて内包した証明を生成し、検証者は追加のやり取りなしで独立して証明を検証できます。Filecoinは、データ自体を公開せずに、ユーザーがデータを保存していることを証明するために非対話型ゼロ知識証明を使用しています。
zk-SNARKと回路
zk-SNARKとは、Succinct Non-interactive ARgument of Knowledge（簡潔な非対話型知識証明）です。このゼロ知識証明は、特に効率的かつコンパクト、つまり簡潔です。証明のサイズと検証に必要な時間の両方が、検証対象の計算よりも緩やかに増加する場合、その証明は簡潔であるとみなされます。そのため、簡潔な証明を求める場合、ハッシュ処理の各ラウンドで検証者に作業をさせることはできません。そうすると検証時間が計算量に比例してしまうからです。簡潔な証明は、多項式とFiat-Shamirヒューリスティックによって実現できます。
証明しようとする命題がどれほど複雑でも、zk-SNARKは証明サイズを小さく保ち、比較的短時間で検証できます。この特性が、zk-SNARKをロールアップにとって非常に魅力的なものにしています。特定のL2の全トランザクションが有効であることを証明でき、その証明はL1で検証できるほど小さいからです。Minaのようなプロトコルはさらに一歩進み、再帰的証明を使用することで、チェーンの全履歴を一定サイズの証明で検証できます。PicklesはMinaの新しい証明システムと関連ツールキットです。信頼できるセットアップなしで再帰的合成を行える、初めて実運用されたzk-SNARKです。ここでいう再帰的合成とは、回路を指します。
回路は、証明したい計算を記述します。入力を受け取り、出力を生成する一連の数学的演算です。ゼロ知識証明では、計算への入力を明かさずに、その計算が正しく実行されたことを表現するために回路が使われます。一般的なワークフローは次のとおりです。
- 回路の記述とコンパイル — 回路を記述し、コンパイルする必要があります。これは、素数p = 7で定義された有限体上に、計算x * y = zを表す算術回路を作成する程度の単純なものでも構いません。ここでの基本的な考え方は、証明対象の計算を変数間の制約の集合として表し、その制約を多項式方程式へ還元し、すべての値を新しい代数構造へ一方向に写像するコード、すなわち準同型写像を記述することです。コンパイル処理では、回路で定義された制約の集合や、後続の手順で使うスクリプトまたはバイナリなど、複数の成果物が出力されます
- 信頼できるセットアップセレモニー — 証明鍵と検証鍵の生成に使用するzk-SNARKの種類によっては、セレモニーの実施が必要です
- 回路の実行 — 回路は、コンパイル時に生成されたスクリプトまたはバイナリを、プログラムのように使って実行する必要があります。ユーザーが公開入力と非公開入力を与えると、すべての中間変数と出力変数の値が計算されます。計算の全ステップを記録したものを、witness、またはtraceと呼びます
- 証明の生成 — 2つ目の手順の証明鍵と、3つ目の手順のwitnessを使うことで、証明者は出力値だけを公開しつつ、回路で定義されたすべての制約が成立することを示すゼロ知識証明を生成できます。この証明は検証者に送られます
- 証明の検証 — 検証者は、提出された証明と検証鍵を使い、公開出力に対して証明が正しいことを検証します
Groth16など、一部のzk-SNARKでは回路ごとに信頼できるセットアップが必要です。新しいプログラムごとに新たなセレモニーを実施する必要があるため、これは障害になり得ます。PlonKなど、別のzk-SNARKでは汎用的な信頼できるセットアップが1回だけ必要となり、プロセス全体が簡素化されます。また、zk-STARKなどの別種のゼロ知識証明では、信頼できるセットアップが完全に不要です。
zk-STARK
zk-STARKとは、Scalable Transparent ARgument of Knowledge（スケーラブルで透明な知識証明）です。zk-STARKはStarkWareによって発明され、zk-SNARKの代替手段として2018年のこの論文で初めて提案されました。基本的には、ブロックチェーン上の計算を単一のオフチェーンSTARK証明者へ移し、その計算の完全性をオンチェーンのSTARK検証者で検証できるようにします。
オフチェーンの証明者が使用する入力はブロックチェーンに公開されず、ユーザーのプライバシーが保護されるため、zk-STARKはゼロ知識とみなされます。また、計算をオフチェーンに移すことでL1の検証コストを大幅に削減できるため、スケーラブルです。証明は線形にスケールしますが、zk-SNARKは準線形にしかスケールしません。さらに、zk-STARKは複雑な信頼できるセットアップセレモニーに依存しません。こうしたセレモニーは、適切に実施されなかった場合に検証者が無効な証明を受理する可能性がある、有害廃棄物の影響を受けやすいとされています。代わりに、zk-STARKは公開検証可能なランダム性を用いて、証明者と検証者のやり取りを設定します。また、これらの証明は、必要な補助入力とともに実際に計算を実行したオフチェーン証明者だけが生成できます。
zk-STARKは、スケーラブルで透明な知識証明として、zk-SNARKの制約を解決します。また、暗号学的仮定がはるかに単純で、楕円曲線などの要素を完全に不要にします。代わりに、ハッシュと情報理論のみに依存するため、耐量子性があります。ただし、証明サイズは数百キロバイトに達するため、ブロックチェーンのように帯域幅やストレージが限られる環境では、実用性が制限される可能性があります。 より複雑な証明構成やzkVMの中には、最後の検証手順のためだけに、zk-STARKを再帰的にzk-SNARKへ証明する組み合わせを使用するものもあります。
ZK Compression
状態増大の問題
Solanaが直面する最も差し迫った課題の1つが、状態増大の問題です。この問題を理解するために前提を整理すると、Solanaの状態はフルノードのディスク上にあるAccounts DBへ保存されます。これはKey-Valueストアであり、データベース内の各エントリはアカウントと呼ばれます。各アカウントには32バイトのアドレスがあり、保存できるデータ量は0〜10 MBです。現在、10 MBのデータを保存するコストは約70 SOLです。1つの10 MBアカウントに保存しても、1,000個の10 KBアカウントに分散しても変わりません。状態増大の問題に関するTolyの投稿によると、毎日およそ100万個の新規アカウントがチェーンに追加され、状態全体では5億アカウントを超えています。Solanaが成長を続けるにつれ、スナップショットサイズの無制限な増大、PCI帯域幅の制約、アカウントのインデックス作成、高コストなメモリおよびディスク管理など、複数の課題が生じます。
現在のフルスナップショットのサイズは約70 GBで、現行のハードウェアでも管理可能です。しかし、増大が続けば、状態管理の非効率化やボトルネックは避けられません。スナップショットサイズが増えるほど、ハードウェア障害後に新しいシステムをコールドブートする時間が大幅に長くなり、ネットワーク再起動時には深刻な影響を与える可能性があります。
Peripheral Component Interconnect（PCI）帯域幅とは、CPUと、グラフィックカード、ネットワークカード、ストレージデバイスなどの周辺機器との間のデータ転送速度を指します。PCI Express（PCIe）は、従来のPCI規格に代わり、より高いデータ転送速度を提供するために設計された高速インターフェース規格です。最新のPCI帯域幅は1 TB、つまり128 GB/sに達します。非常に大きく見えますが、Solanaでは十分とは限りません。1つのトランザクションが128 MBを読み書きする場合、128 GB/sのPCI帯域幅ではSolanaは毎秒1,000トランザクション（TPS）に制限されます。ただし、ほとんどのトランザクションは、すでにバリデータのRAMへ読み込まれ、キャッシュされている最近のメモリへアクセスします。それでも、Solanaのスケーリング時に高いスループットを維持するには、効率的な状態メモリが不可欠です。そうでなければ、この帯域幅がすぐに制約要因になります。
各バリデータは、既存の全アカウントのインデックスを維持する必要があります。新しいアカウントを作成するには、そのアカウントがまだ存在しないことを証明する必要があるためです。状態全体が5億アカウントを超える状況では、最小限のインデックス、つまりエントリごとに32バイトのキーと32バイトのデータハッシュだけでも、約32 GBのRAMが必要です。この状態ストレージは高コストであり、パフォーマンス低下を防ぐため慎重に管理しなければなりません。Solanaの状態が増大し続けるにつれ、特定の処理に高速で高価なメモリ、つまりRAMを使うか、低速で安価なメモリ、つまりディスクを使うかの区別が重要になります。
トランザクションと状態増大
すべてのSolanaトランザクションは、読み書きする全アカウントを指定する必要があります。現在、トランザクションは1,232バイトに制限され、次の要素を含める必要があります。
- ヘッダー（3バイト）
- 署名（各64バイト）
- アカウントアドレス（各32バイト）
- 命令データ（任意のサイズ）
- 直近のブロックハッシュ（32バイト）
トランザクションの実行時には、次の処理が行われます。
- 健全性チェック — 直近のトランザクションのみが有効です。トランザクションに対し、重複排除、構造検証、手数料チェック、署名チェックが行われます
- プログラムの読み込み — プログラムアドレスに基づいてプログラムのバイトコードが読み込まれ、Solana Virtual Machine（SVM）がインスタンス化されます
- アカウントの読み込み — トランザクションが参照する全アカウントがチェックされ、ストレージからメモリへ読み込まれてSVMに渡されます
- 実行 — プログラムのバイトコードが実行されます
- 同期 — 変更されたアカウントがストレージへ同期されます
状態が増大し続ける中、このライフサイクルには複数の課題があります。特にオンチェーン状態は高コストで、ディスク上に保存するアカウントが増えるほど、スナップショットとインデックスも大きくなります。また、すべてのアカウントが頻繁にアクセスされるわけではないため、継続的にリソースコストを負担するのは非効率です。
ZK Compressionによる状態管理の簡素化
すべてのアカウントをディスクへ保存し、必要に応じて読み込む代わりに、トランザクションのペイロードの一部としてアカウントデータを渡すことができます。Merkleツリーを使えば、トランザクションを送信するユーザーが正しい状態を提供していることを保証できます。Merkle証明は、特定のデータへコミットする方法です。証明をコミットメントと照合することで、正しい状態が渡されたこと、そしてユーザーが提示した状態について虚偽を述べていないことを検証できます。
安全ではあるものの、これらの証明は非常に大きくなる場合があります。たとえば、ツリーに10万個のアカウントが含まれる場合、証明サイズは544バイトです。複数のアカウントに証明を付けると、トランザクションサイズの上限である1,232バイトをすぐに超えてしまいます。幸い、より効率的な証明システムを使えば、この問題を回避できます。KZGやPedersenコミットメントなど、証明サイズが一定のコミットメントを使うことで証明を小さくし、トランザクションサイズの上限内に収めやすくなります。
ZK Compressionは、Merkle証明のサイズ問題を解決するための仕組みにすぎません。Solanaの台帳を活用し、オンチェーンストレージに伴うコストを負担せずに、特定の計算が正しく実行されたことを証明する方法です。
ZK Compressionとは？
ZK Compressionは、セキュリティ、パフォーマンス、コンポーザビリティを維持しながらオンチェーン状態を圧縮し、状態コストを桁違いに削減できる新しいプリミティブです。たとえば、現在100個のトークンアカウントを作成するには~0.2 SOLかかりますが、ZK Compressionを使えばコストは5,000分の1の~0.00004まで下がります。
ZK Compressionは、基盤となるデータを公開せずに状態遷移を検証するため、ゼロ知識証明を活用します。複数のアカウントを、オンチェーンに保存される単一の検証可能なMerkleルートへまとめ、基盤データは台帳に保存します。有効性証明は、m個の状態ツリー内に葉として存在するn個のアカウントを、一定の128バイトの証明サイズを維持しながら証明する、簡潔なゼロ知識証明です。この証明はオフチェーンで生成され、オンチェーンで検証されるため、Solana全体の計算負荷を軽減します。ZK Compressionは、証明システムに著名なペアリングベースのzk-SNARKであるGroth16を使用します。
ただし、これらのアカウントは通常のSolanaアカウントではありません。圧縮アカウントです。
圧縮アカウントモデル
ZKで圧縮された状態は、圧縮アカウントに保存されます。これらは通常のSolanaアカウントに似ていますが、効率性とスケーラビリティを高める重要な違いがいくつかあります。
- ハッシュによる識別 — 各圧縮アカウントは、そのハッシュで識別できます
- 書き込み時のハッシュ変更 — 圧縮アカウントへの書き込み操作が行われると、ハッシュが変わります
- 任意のアドレス — 圧縮アカウントの永続的な一意IDとして、任意でアドレスを設定できます。これはNFTなど、特定のユースケースで役立ちます。このフィールドが任意なのは、圧縮アカウントをハッシュで参照できるため、計算オーバーヘッドを避けるためです
- スパース状態ツリー — すべての圧縮アカウントはMerkleツリーに保存され、ツリーの状態ルート、つまりMerkleルートのみがオンチェーンのアカウント領域に保存されます。より具体的には、状態ツリーはPoseidonハッシュベースの並行Merkleツリーです
圧縮されたProgram-Derived Address（PDA）は、一意かつ永続的なアドレスで識別できます。Data、Lamports、Owner、Addressの各フィールドを持ち、通常のPDAアカウントと同様の構成です。ただし通常のPDAとは異なり、DataフィールドにはDiscriminator、Data、DataHashフィールドを持つAccountData構造が組み込まれています。
ノード
ZK Compressionを支えるうえで、さまざまな種類のノードが重要な役割を担います。DevnetとMainnet-Betaへ接続するPhoton RPCノード、Proverノード、Light Foresterノードは、誰でも運用できます。ローカル開発では、ZK Compression CLIのtest-validatorコマンドを使うと、関連するすべてのノード、つまりPhoton RPCとProverに加え、システムプログラム、アカウント、ランタイム機能を備えた単一ノードのSolanaクラスターが起動します。
Photon RPCノードは、圧縮プログラムのインデックスを作成します。これにより、クライアントは圧縮状態とやり取りするトランザクションを読み取り、構築できます。標準の圧縮インデクサーはPhotonと呼ばれ、Heliusが提供しています。この種類のノードは最小限の設定でローカル実行でき、既存のRPCを接続先として指定する必要があります。
Proverノードは、状態包含の有効性証明を生成するために使われます。ZK Compression RPC API仕様のgetValidityProofエンドポイントを使って、証明を取得できます。Proverノードは、スタンドアロンノードとして運用することも、別のRPCとバンドルすることもできます。標準のPhoton RPC実装にはProverノードが含まれています。
Light Foresterノードは、共有状態ツリーとプログラム所有の状態ツリーについて、作成、ロールオーバー、更新を管理します。これは、自身のプログラムが所有する状態ツリーをLight Foresterノードのネットワークに管理させたい開発者向けです。
信頼の前提
前述のノードは誰でも運用でき、証明の生成とトランザクションの送信に必要な生データも保存できます。これにより、圧縮状態のライブネスに影響する信頼の前提が生じます。具体的には、データが失われたり遅延したりすると、そのデータを自分で保存していない限り、トランザクションを送信できません。データを提供する誠実なノードは1つあればよく、証明も自己検証可能なため、問題となるのは安全性ではなく、ライブネスと潜在的な検閲です。
さらに、圧縮アカウントを検証するプログラムが現在アップグレード可能であることも、別の信頼の前提になります。これは、問題の修正や新しい要件への対応のためにプログラムを変更できるようにするためです。ただし、安定した安全な状態に達した後は、将来的にイミュータブル化または凍結できます。
Foresterノードの使用も、ライブネスに関する信頼の前提です。これらのノードは状態ルートの更新を維持し、nullifierキューを空にしながら状態ルートを非同期で進めることで、キューを管理します。ここでは、アカウントハッシュをゼロに置き換えて無効化します。更新と無効化を分離することで、トランザクションをSolanaのサイズ制約内に収めながら、圧縮状態遷移の即時ファイナリティを実現します。nullifierキューのサイズは一定であるため、Foresterノードはプロトコルのライブネスに不可欠です。キューが満杯になると、関連する状態ツリーでライブネス障害が発生します。Foresterノードはキューを空にすることで、これを防ぎます。ただし、プロトコルの完全性とライブネスを支えるには、これらのノードを実際に運用する人が必要です。これらのノードがなければ、ZK Compressionがサポートできるのは約2,000個のアカウントまたはアドレスに限られます。
制約
何かを隠す必要がない場合でも、ゼロ知識証明は、複数の計算手順を必要とする問題を、単一の証明を検証するだけで計算が正しく実行されたと確認できる問題へ変換します。そして、これらの計算は、特定の葉が特定のツリーに属するかどうかといったものに限定されず、任意の計算にできます。ただし、これにはコストが伴います。
ZK Compressionを使う前に、次の点を検討してください。
- トランザクションサイズの増大 — ZK Compressionでは、有効性証明に128バイトが必要で、オンチェーンで読み書きするデータも送信する必要があります
- Compute Unit使用量の増加 — ZK Compressionでは、有効性証明の検証に~100k CU、システム利用に~100k CU、圧縮アカウントの読み書き1回につき~6k CUが必要なため、Compute Unit（CU）の使用量が大幅に増えます
- トランザクションごとの状態コスト — 書き込み操作のたびに、以前の圧縮アカウント状態を無効化し、新しい圧縮状態を状態ツリーへ追加する必要があるため、小額のネットワークコストが発生します。そのため、状態の更新回数が多い場合、1つの圧縮アカウントの生涯コストが非圧縮の同等アカウントを上回る可能性があります
次の場合は、通常のアカウントを使用する方が適している可能性があります。
- アカウントが頻繁に更新される
- アカウントへの生涯書き込み回数が多い（例：>1000x）
- オンチェーントランザクションでアクセスする必要がある大量のデータをアカウントが保存する
メリット
ZK Compressionは、Solanaの状態増大問題へ直接対処し、幅広いアプリケーションとユースケースを支える、スケーラブルで安全、効率的かつ柔軟なプリミティブです。最も明確なメリットは、状態コストの削減でしょう。ZK Compressionでは、安価な台帳領域に状態を安全に保存しつつ、状態のフィンガープリントによってオンチェーンストレージを最小限に抑えられるため、アプリを数百万人のユーザーへ容易にスケールできます。10,000個のトークンアカウントを発行する例では、SOL価格を130米ドルと仮定すると、通常は約2,600ドルかかります。ZK Compressionなら、これを50セント未満に抑えられます。
ZK Compressionは、現在のSolana仕様とも高い親和性があります。たとえば、圧縮アカウントの構造は通常のSolanaアカウントとほぼ同じです。また、並列処理など、Solana固有のイノベーションにも対応しています。つまり、同じ状態ツリー、すなわちコミットメント配下にあり、異なる圧縮アカウントへアクセスする2つのトランザクションは並列実行できます。さらに、ZK Compressionは同期的なアトミックコンポーザビリティを強化します。たとえば、n個の圧縮アカウントとm個の通常アカウントを列挙するトランザクションは、完全に有効な構成です。圧縮アカウントを参照する命令から、通常アカウントを参照する別の命令やプログラムを呼び出せます。アカウントが異なる状態ツリーで圧縮されていても同様です。1つの命令が失敗するとトランザクション全体がロールバックされ、変更は次の命令から確認できます。これはZKロールアップと異なります。ロールアップ同士は、ロックを取得しない限り同期的またはアトミックに呼び出せません。そこで当然、ZK Compressionとロールアップを比較する必要があります。
ZK Compressionはロールアップではない
ZK Compressionはロールアップではありません。両者は同じ技術に依存していますが、実装が異なります。ロールアップには2つの種類があります。
- Optimistic Rollup — 一定期間はすべてのトランザクションを有効とみなし、その期間内に不正なトランザクションがあれば、不正証明を使って証明します
- Zero-Knowledge Rollup — 有効性証明を使い、トランザクションが有効か無効かを即座に証明します
Zero-Knowledge Rollupの状態全体は、ベースレイヤー、つまりEthereum上の単一のルートとして表されます。このため、ZK Compressionは実際にはロールアップだという主張が複数出ています。しかし、両者には重要な違いがいくつもあります。
ZKロールアップ上で500件のトランザクションを処理する場面を考えてみましょう。この場合、ロールアップ全体を単一の回路として扱います。500件のトランザクションをまとめて検証し、状態ルートがAからBへ変わったことを確認する単一の証明を生成します。この証明が検証されると、L1とL2間のやり取りを管理するスマートコントラクトが状態ルートを更新します。一方、ZK Compressionでは、500件の各トランザクションが、アカウントデータの正しさを検証する独自の証明を生成します。これらのトランザクションはSVM自体が実行し、各証明が検証されると、アカウントは「通常の」アカウントとして扱われます。
ZK Compressionをロールアップに分類するなら、Solanaに保存されるあらゆるMerkleルートを、有効性証明ベースのロールアップとみなせることになります。現在Solana上にある圧縮cNFTの全ルートを見ると、ミント数がゼロのMerkleツリーを数えるかどうかに応じて、約4,000〜5,000個の有効性証明ベースのロールアップが存在することになります。
したがって、ZK CompressionがSolanaのアーキテクチャに合わせて設計された独自のソリューションであることは明らかです。これはZKロールアップとは異なる新しいプリミティブであり、ロールアップの複雑さや分離を伴わずにスケーラビリティと効率性を高めます。
SolanaにおけるZKと相互運用性の未来
SolanaにおけるZKの現状
Heliusで最初に担当した執筆業務の1つが、Solanaのv1.16アップデートの解説でした。ゼロ知識証明に対するランタイムサポートの改善を知って非常に興奮し、記事でも取り上げました。しかし、この改善は延期されました。さらに詳しく解説しようとv1.17アップデートの記事でも再び取り上げましたが、またしても延期されました。v1.18アップデートの記事では、取り上げることすらしませんでした。当然ながら失望し、ほかの人々も不満を表明していました。
こうした状況にもかかわらず、Solanaには小規模ながら成長しつつあるZK開発者コミュニティがあります。Light Protocolは、ZK Compressionへ注力するようになる以前、当初はPSP（Private Solana Programs）形式での非公開プログラム実行に取り組んでいました。Dark protocolも、Solana上に構築されたフュターキー型のプライバシープロトコルです。中央チームはなく、提案を通じて貢献が行われます。以前はElusivとして知られていたArciumは、Multiparty computation eXecution Environments（MXE）を使用し、独自の並列化された機密コンピューティングネットワークを稼働させています。Bonsolは、開発者が任意のrisc0 imageを実行してSolana上で検証できる、ゼロ知識「コプロセッサ」です。つまり、検証可能なオフチェーン計算を実現します。チュートリアルやゼロ知識証明関連リンクの一覧も共有されています。
特に注目すべきなのが、ZK Token Proof Programです。これはcurve25519上のPedersenコミットメントとTwisted ElGamal暗号に合わせて設計された複数のゼロ知識証明を検証します。これにより、ゼロ知識証明を使ってSPLトークンの残高とトランザクション金額を暗号化するConfidential Transfersが実現します。目的は匿名性ではなく機密性です。準同型暗号を使うと、暗号化されたデータを復号せずに計算できます。Confidential Transfersでは、暗号文上の秘匿された数学演算にTwisted ElGamal暗号を使い、機密情報を公開せずに送金を検証するためにSigma Protocolsを使用します。暗号化された残高を確認できるのは、復号鍵を持つアカウント所有者だけです。ただし、Global Auditor Systemでは、個別の復号鍵を通じて、コンプライアンスや監査向けの選択的な読み取りアクセスを提供できます。
Solana上のプログラム可能な非公開残高は、現在Solana Privacy Ringsとして提供されています。
ZK Token Proof Programは、SIMD-0153: ZK ElGamal Proof Programが可決されたため、現在はブロック対象の機能です。この新しいSIMDは、SPL Tokenプログラム専用に設計された既存のZK Token Proofプログラムを廃止し、特定のアプリケーションに依存しない、より汎用的なゼロ知識証明プログラムへ置き換えることを目指しています。このSIMDは、AnzaとFiredancerチームの両方から支持を受け、マージされています。
しかし、流れは変わり始めています。これらの改善がついにDevnetとMainnet-Betaへ導入され、SolanaはZKの巨大勢力になりつつあります。現在、Solanaでは3つのZK syscallが稼働しています。
Poseidon syscall
Poseidonは、ゼロ知識証明専用に設計されたハッシュ関数群で、Zcash、Mina、Light Protocolなどのプロジェクトで使われています。Poseidonは、SHA-256のような従来の汎用ハッシュ関数よりも、ゼロ知識証明における計算効率が優れています。
Poseidonハッシュ関数がゼロ知識証明に適している理由は、次のとおりです。
- 算術演算を効率的に実行します
- 算術演算に適した設計、最適化されたS-box、少ないラウンド数により、証明生成に必要な手順が少なく、回路の複雑性を抑えられます
- 任意の長さのビット列を扱えるアルゴリズムを使用するため、非常に汎用性があります
以前は、1つのトランザクション内でPoseidonハッシュを計算するにはコストが高すぎました。しかし、エポック644とPoseidon syscallの有効化によって状況が変わります。これは2次元のバイトスライスを入力として受け取り、対応するPoseidonハッシュを出力として計算するシステムコールです。ZK Compressionは状態ツリーでPoseidonハッシュを使用しているため、これは大きな進展です。
Poseidon syscallは、BN254曲線と次のパラメータを使用してハッシュを計算します。
- S-box — x5置換ボックス
- 入力 — 1 ≤ n ≤ 12
- 幅 — 2 ≤ t ≤ 13
- ラウンド — 8回のフルラウンドと、tに応じた部分ラウンド：[56, 57, 56, 60, 60, 63, 64, 63, 60, 66, 60, 65]
出力は、指定されたエンディアンで32バイトにエンコードされたPosiedonハッシュ結果です。
このsyscallで使われる具体的なバリアントは、x5 S-boxとBN254曲線向けに調整されたパラメータを持つPoseidonです。light-poseidon crateによって、これらのハッシュを計算できます。このcrate自体は監査済みで、Circomと互換性があります。
alt_bn128 syscall
alt_bn128とは、効率的なzk-SNARK証明と計算を可能にするペアリング対応曲線、Barreto-Naehrig（BN-128）楕円曲線の実装を指します。この曲線はGroth16を含むさまざまなゼロ知識証明システムに不可欠で、ZK Compressionも状態遷移の検証にGroth16を使用しています。このsyscallは証明ごとに必要な領域を大幅に削減し、効率的なオンチェーン証明に欠かせない空間と時間の最適化を実現します。
sol_alt_bn128_group_op syscallは、G1での点加算（G1とは、単に特定の楕円曲線上の点の群を意味します）、G1でのスカラー倍算、ペアリングなど、alt_bn128曲線上の演算を実行します。
- 入力 — ビッグエンディアン形式でシリアライズされた点とスカラー
- 演算 — G1での点加算、G1でのスカラー倍算、ペアリング（G1の1点とG2の1点）
- 出力 — G1の点、または256ビット整数としてシリアライズされたペアリング結果
sol_alt_bn128_compression syscallは、alt_bn128曲線上のG1またはG2群の点を圧縮または展開し、標準のビッグエンディアン形式で点を返します。
これらのsyscallは現在testnetで稼働しており、読み込み済みプログラムの再コンパイルフェーズにあるバグが解決されれば、Devnetでも利用可能になると見られます。これはSIMD-0075: Secp256r1 Precompileに基づくものです。この提案は、alt_bn128 syscallとPoseidon syscallのエラーコードを簡素化し、一貫性を確保するとともに、バリデータが異なるエラーコードを返すことでコンセンサス障害が発生するリスクを軽減することを目指しています。
alt_bn128 syscallは、KZGコミットメントなど、証明サイズが一定の通常のベクトルコミットメントに使用できます。したがって、あらゆるペアリング対応曲線で機能し、ZK証明者回路を必要としません。
相互運用性
SolanaはZKチェーンです。低い手数料と楕円曲線演算のランタイムサポートを備えた、高性能なLayer 1ブロックチェーンです。ゼロ知識証明関連のsyscallを実装しサポートすることでイノベーションが促進され、ZK Compressionのような新しいプリミティブやアプリケーションをSolana上に構築できます。
alt_bn128 syscallの導入により、Solanaと、EIP-196、EIP-197、EIP-198で規定された楕円曲線演算用のプリコンパイル済みコントラクトに依存するSolidityベースのコントラクトとの間で、コンポーザビリティの隔たりが縮まります。これらの演算により、Ethereumのガス上限内でzk-SNARK証明を検証できます。そのため、このような楕円曲線演算に依存するSolidityコントラクトは、Solanaへの移行、さらにはSolanaとの相互運用が容易になる可能性があります。
SIMD-0075は、相互運用性ソリューションにとって不可欠です。このSIMDが完全に実装されると、近日公開予定のblobsream-solana（CelestiaからSolanaへDAをストリーミングします）のようなプロジェクトで、Merkleコミットメントを保存するためにオフチェーンでの証明生成とオンチェーン検証を利用できるようになります。これらのsyscallがなければ、Solana上でGroth16証明を検証することはできません。さらに、これらのsyscallはトラストを最小化したブリッジと相互運用性を強化し、ほかのブロックチェーンがSolanaとシームレスかつ安全に連携できるようにします。
Tolyは正しいのです。Solanaランタイムのこうした機能強化により、SolanaはEthereum L2になります。近いうちに、Solanaの全ブロックをEthereum上のデータ検証ブリッジコントラクトへ送信することを妨げるものはなくなります。逆に、Ethereumの全ブロックをSolana上のデータ検証ブリッジプログラムへ送信することも可能になります。旧式のブリッジではなくゼロ知識証明によって加速する双方向の相互運用性は、Solanaにとって明るく成長著しい未来です。
まとめ
ゼロ知識証明は、暗号研究者が開発したプリミティブの中でも、間違いなく最も強力なものの1つであり、おそらく最強のプリミティブです。第1回の記事で、この概念を支える理論、数学、暗号技術を第一原理から積み上げて検討すれば、それは自明になります。オンチェーンゲームに真の戦場の霧を実現することから、L2上の一連のトランザクションが特定の状態遷移をもたらしたことの証明まで、応用の可能性は無限です。
この2部構成のシリーズは、準同型暗号の詳細、Circomでの回路実装、さまざまなコミットメント方式の分析を含めれば、さらに50ページ以上続けることも容易でした。しかし、これらの記事の目的は、読者が新たに得た知識をSolanaへ応用できるよう、ゼロ知識証明の基礎を解説することです。
SolanaはZKの巨大勢力になりつつあります。ZK Compressionのリリースから、近い将来に稼働するさまざまなsyscallまで、その重要性はいくら強調してもしすぎることはありません。ZK Compressionのようなプリミティブは、一般的な開発者からゼロ知識証明の複雑さをすべて隠蔽しますが、Solana上での議論と開発をさらに進めるうえで、基礎を理解することには計り知れない価値があります。
ここまで読んでくださった匿名の皆さん、ありがとうございます！Solanaの最新情報を見逃さないよう、下にメールアドレスを入力してください。さらに深く学ぶ準備はできましたか？Heliusブログの最新記事を読み、今すぐSolanaの旅を続けましょう。
その他のリソース
Heliusを購読
Solana開発の最新情報や新しい記事の公開通知を受け取れます