ゼロ知識証明：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では、汎用的なトラステッドセットアップを一度行うだけでよく、プロセス全体を簡素化できます。また、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は複雑なトラステッドセットアップ・セレモニーに依存しません。セレモニーが正しく実施されなかった場合に検証者が不正な証明を受け入れる可能性があり、これはtoxic wasteの影響を受けやすいとされています。代わりに、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のデータを保存するには、それが1つの10 MBアカウントに格納されていても、1,000個の10 KBアカウントに分散していても、約70 SOLかかります。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トランザクションは、読み書きする全アカウントを指定する必要があります。現在、トランザクションは最大1232バイトに制限され、次の要素を含める必要があります。
- ヘッダー（3バイト）
- 署名（各64バイト）
- アカウントアドレス（各32バイト）
- 命令データ（任意のサイズ）
- 直近のブロックハッシュ（32バイト）
トランザクションの実行時には、次の処理が行われます。
- 健全性チェック — 直近のトランザクションのみが有効です。トランザクションに対し、重複排除、構造検証、手数料、署名のチェックが行われます
- プログラムの読み込み — プログラムアドレスに基づいてプログラムのバイトコードが読み込まれ、Solana Virtual Machine（SVM）がインスタンス化されます
- アカウントの読み込み — トランザクションから参照される全アカウントがチェックされ、ストレージからメモリへ読み込まれてSVMへ渡されます
- 実行 — プログラムのバイトコードが実行されます
- 同期 — 変更されたアカウントがストレージへ同期されます
状態が増大し続ける中、このライフサイクルには複数の課題があります。特に、オンチェーン状態は高コストであり、ディスクに保存するアカウントが増えるほど、スナップショットとインデックスが大きくなります。また、すべてのアカウントが頻繁にアクセスされるわけではないため、継続的なリソースコストを負担するのは非効率です。
ZK Compressionによる状態管理の簡素化
すべてのアカウントをディスクへ保存し、必要なときに読み込む代わりに、トランザクションのペイロードの一部としてアカウントデータを渡せます。Merkleツリーを使えば、トランザクションを送信するユーザーが正しい状態を提示していることを保証できます。Merkle証明は、何らかのデータへコミットする手段です。コミットメントに対して証明を検証することで、正しい状態が渡されたこと、そしてユーザーが提示した状態について虚偽を述べていないことを確認できます。
安全ではあるものの、この証明は非常に大きくなる場合があります。たとえば、ツリーに10万アカウントが含まれる場合、証明サイズは544バイトです。複数アカウントの証明を提示すると、トランザクションサイズの上限である1232バイトをすぐに超えてしまいます。幸い、より効率的な証明システムを使えば、この問題を回避できます。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）は、永続的で一意のアドレスによって識別できます。通常のPDAアカウントと同様に、Data、Lamports、Owner、Addressフィールドを持ちます。ただし、通常のPDAとは異なり、DataフィールドにはDiscriminator、Data、DataHashフィールドを持つAccountData構造が組み込まれています。
ノード
さまざまな種類のノードが、ZK Compressionを支える重要な役割を担います。誰でもPhoton RPCノード、Proverノード、Light Foresterノードを実行し、DevnetとMainnet-Betaへ接続できます。ローカル開発では、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,000回超）
- オンチェーントランザクションからアクセスする必要がある大量のデータをアカウントが保存する場合
メリット
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 Encryptionに合わせて設計された、複数のゼロ知識証明を検証します。これにより、ゼロ知識証明を使ってSPLトークンの残高とトランザクション金額を暗号化するConfidential Transfersが実現します。目的は匿名性ではなく、機密性です。準同型暗号を使うと、暗号化されたデータを復号せずに計算できます。そのためConfidential Transfersは、暗号文上の秘匿された数学演算にTwisted ElGamal Encryptionを使用し、機密情報を開示せずに送金を検証するためにSigma Protocolsを使用します。暗号化された残高を確認できるのは、復号鍵を持つアカウント所有者だけです。ただし、Global Auditor Systemでは、別の復号鍵を通じて、コンプライアンスと監査に必要な選択的読み取りアクセスを提供できます。
ZK Token Proof Programは現在、SIMD-0153: ZK ElGamal Proof Programの可決によりブロック対象の機能となっています。この新しいSIMDは、SPL Tokenプログラム専用に設計された既存のZK Token Proof Programを非推奨とし、特定のアプリケーションに依存しない、より汎用的なゼロ知識証明プログラムへ置き換えることを目指しています。この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バイトにエンコードされたPoseidonハッシュ結果です。
この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が完全に実装されると、CelestiaからSolanaへDAをストリーミングする予定のblobsream-solanaなどのプロジェクトで、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開発の最新情報や新しい記事の公開通知を受け取れます