ZK圧縮基調講演：Breakpoint 2024

ZK圧縮：ゼロへ送る

Solanaで開発を始めた開発者がすぐに気づくことの1つは、計算コストは比較的安い一方で、データストレージのコストが高いことです。たとえば、SOL価格を150ドルとすると、1,000個のトークンアカウントの作成には約300ドル、100万個のアカウントには30万ドルかかります。これらのコストはSOL価格とともに上昇するため、大規模なユーザーベースに向けたアプリケーションの拡張は経済的に困難になります。さらに、状態の増大は、状態を保持するすべてのブロックチェーンが直面する課題です。新しいアカウントを作成すると、その維持に高額なrent手数料を支払う必要があります。現在、Solanaには5億を超えるアカウントがあり、毎日約100万個の新規アカウントが追加されています。

ZK圧縮は、以下を提供することでこれらの問題を解決します。

• アカウントコストを1,000分の1に削減
• 状態増大へのソリューション
• Solana上のZK計算の基盤

状態圧縮 + ZK

ZK圧縮を理解するために、まず5つの主要な段階からなる状態圧縮を詳しく見ていきます。

1. 数百万のアカウント → 「フィンガープリント」
2. フィンガープリントをオンチェーンに保存
3. アカウント履歴をSolana台帳に保存
4. インデクサーで最新のアカウント状態をキャッシュ
5. オンチェーンの「フィンガープリント」で圧縮アカウントの状態を検証

まず、数百万のSolanaアカウントを圧縮し、ハッシュ化してコンパクトな「フィンガープリント」を作成します。このフィンガープリントはオンチェーンアカウントに保存され、基盤となる完全なアカウントデータには引き続きSolanaの台帳からアクセスできます。これらのオフチェーンアカウントの有効性を保証するため、オンチェーンのフィンガープリントを使用して整合性を検証する証明者メカニズムを採用しています。このプロセスの最終段階では、アカウントの整合性を検証する証明システムを支えるゼロ知識SNARKを使用します。

なぜZK圧縮なのか？

ZK圧縮には、状態圧縮の理想的なソリューションとなる重要な特徴がいくつかあります。たとえば、圧縮アカウントは標準的なSolanaアカウントと同様に動作するため、開発者は短期間の学習で既存のスキルや開発手法を活用できます。これにより導入障壁が下がり、開発者はZK圧縮を簡単に採用できます。

‍インデクサーが公開するAPIは、既存のRPC呼び出しに非常によく似ています。たとえば、getAccountInfoメソッドはgetCompressedAccountに直接対応し、この1対1の対応関係はRPC API全体に及びます。この一貫性により、ZK圧縮を既存のSolanaツールやワークフローへ簡単に統合できます。

圧縮PDA

このシステムの重要な特徴は、圧縮されたプログラム派生アドレス（PDA）をサポートしていることです。PDAは、特定のプログラムアドレスとシードから一貫して導出できる決定論的なアカウントアドレスです。圧縮PDAは、競合状態やアドレス衝突、同じプログラムアドレスとシードの組み合わせに対する複数アカウントの誤作成などの問題を防ぎます。この改善は、既存のSPLアカウント圧縮システムからZK圧縮へ移行する大きな理由の1つです。

‍ZK圧縮を完全にサポートすることで、Solanaには大きな効果が期待できます。PDAとプログラム同士を組み合わせる機能により、複数のプログラムや異なるPDAを含む、より複雑なアーキテクチャを構築できます。これは従来型アプリケーションの使い慣れた開発体験に似ています。しかも、コストはわずかで済み、アカウント費用を最大1,000分の1に削減できます。この劇的なコスト削減により、これまで高額な費用が障壁となっていた新しいユースケースが実現します。

コンポーザビリティの向上

すべてがSolana上で直接実行されます。L2でもvalidiumでもありません。データ可用性はSolana台帳によって自動的に提供され、実行の検証可能性と完全なコンポーザビリティが確保されます。

‍ゼロ知識証明は証明サイズを一定の128バイトまで縮小します。これにより、各トランザクション内でほかの処理に使える領域が増え、コンポーザビリティが高まり、追加処理の柔軟性も向上します。単一トランザクションで更新、読み取り、書き込みされるアカウント数や、証明が必要な包含または除外の数にかかわらず、証明サイズは一定です。Solanaのトランザクションサイズは本質的に小さい（1.2キロバイト）ため、これは不可欠です。高速な証明時間を実現するには、状態マークルツリー用に異なるハッシュ関数が必要でした。そのため、元のSPLアカウント圧縮プログラムは使用できませんでした。

解凍

もう1つの重要な機能は解凍です。ロックインを防ぎ、「通常」のアカウントと圧縮アカウントの間でシームレスな相互運用を実現します。どのSolanaアカウントも圧縮でき、rentコストを回収できます。圧縮アカウントはいつでも解凍できるため、2つの形式を簡単に切り替えられます。たとえば、スワップが必要な圧縮トークンがある場合は、それを解凍し、Jupiterでスワップを実行できます。

解凍により、ホット状態とコールド状態をシームレスに切り替えられます。たとえば、さまざまな圧縮カードやアイテムを含むゲームを開発している場合、戦闘中にそれらを解凍して状態を高速に変更し、その後もう一度圧縮して、ヒットポイントの変化などの最終結果を保存できます。1つのslot内における単一ツリー内の並行処理には、いくつかの制約があります。同じアカウントを1つのブロック内で複数回更新する必要がある場合、圧縮は避けるべきです。その場合、その特定のアカウントを永続的に解凍し、通常のオンチェーンアカウントとして機能させる方が適しています。たとえば、AMMプールのアカウントは状態を定期的に更新する必要があるため、通常のオンチェーンアカウントに適しています。このシステムには、同じトランザクション内で圧縮アカウントと解凍済みアカウントの両方を操作できる柔軟性があります。

この完全に汎用化されたソリューションは、単一のプログラム、ビジネスロジック、アプリケーションに限定されません。Solanaアカウントを低コストで圧縮でき、インデックス作成も標準でサポートされます。完全なオープンソースで、本番環境に対応し、さまざまなユースケースに適応できます。

圧縮トークン

圧縮トークンは、取引所やDeFiプラットフォームが対応していない限り、直接の互換性はありません。ただし、圧縮トークンを標準のSPLトークンに解凍すれば簡単に解決でき、通常のトークンと同様にDeFiや取引所で使用できます。この柔軟性によりロックインがなくなり、ユーザーは必要に応じて圧縮トークンと通常のトークンを切り替えられます。圧縮トークンは操作頻度が低いコールドアプリケーションに適しており、通常のトークンアカウントはホット状態や頻繁に使用する資産に適しています。このシステムの主な利点の1つは、コールド状態のデータを圧縮ストレージへ移動することで、すべてのメリットを維持しながら状態をより効率的に管理し、状態増大の問題に対処できることです。‍

‍最初のリリースでは、圧縮対応アプリケーションと同じツールを使って構築された圧縮トークンを導入しました。圧縮トークンプログラムはSolanaトークンプログラムと同等で、同じユーザー体験を提供しながら、コストを1,000分の1に削減します。トークン拡張機能は2025年初頭に公開される予定です。

解凍などの機能により、大量のトークンをエアドロップし、DeFiで必要になったときにすぐ解凍できます。ゼロ知識（ZK）証明は高コストな計算の究極の解決策と見なされることが多い一方で、私たちは転送が標準的なSPLトークン転送と同様になるようプロセスを最適化し、証明時間をミリ秒単位まで短縮しました。これにより、本番品質のコンシューマー向けZKが前面に押し出され、トークンアカウントの管理コストが大幅に削減されます。

ZK圧縮はどのように機能するのか？

システム全体には5つの主要コンポーネントがあります。 

• 状態ツリーのフォレスト
• Light System Program
• Compressed Token Program
• Foresterノード
• インデクサー（Photon）

状態ツリーのフォレスト

まず、「状態マークルツリーのフォレスト」と呼ぶ状態マークルツリーがあります。この構造は、一連のアカウントに固有の暗号学的フィンガープリントを作成し、オンチェーンに保存できるようにします。たとえば、4つのアカウントがある場合、それらを再帰的にハッシュ化してマークルツリー構造にできます。

最上部にある最終的な32バイトのハッシュは、すべてのアカウントについて基盤となるデータの整合性を暗号学的に保証します。これにより、任意のアカウントの状態を状態ルートと比較し、マークルツリーの一部として簡単に検証できます。ここで「フォレスト」という用語を使用するのは、それぞれが独自のルートを持つ複数のマークルツリーが存在するためです。

既存のSPLアカウント圧縮との比較

既存のSPLアカウント圧縮プログラムに対するZK圧縮の大きな改善点の1つは、ある状態が特定のマークルツリーに含まれていることを証明し、Solanaのトランザクションサイズ制限内で効率的に証明を生成できる点です。これにより、状態マークルツリーに似たアドレスツリーを管理して、特定のアドレスの一意性を証明できます。ただし、追加の機能があります。あるリーフへの包含を証明すると、特定範囲の数値の除外も証明されます。これにより、はるかに小さなマークルツリーで248ビットのアドレス空間を扱い、アドレスの一意性を保証できます。

N個のツリーに対してM個のアカウントを証明しながら、証明サイズを一定の128バイトに維持できるため、Solanaの1.2kbというトランザクションサイズ制限にも十分収まります。オフチェーンで行われる証明生成は、既存のSPLアカウント圧縮プログラムより高コストです。一方、オンチェーンで行われる証明検証のコストは一定で、通常は既存の圧縮プログラムより安価です。

Light System ProgramとCompressed Token Program

このプロトコルには2つの主要なプログラムがあります。Light System ProgramはSolana System Programを再現するオンチェーンコントラクトです。マークルツリーとやり取りし、標準的なSolanaアカウントモデルを適用して、PDAの一意性を検証します。Compressed Token ProgramはSPLトークンプログラムを再現し、圧縮アカウントモデル内でSPLデータレイアウトを適用します。

Foresterノード

Foresterノードは、このライトフォレストの管理を担います。圧縮アカウントを更新すると、新しいアカウント状態がツリーに追加され、古い状態はゼロ化または無効化されます。

このアプローチには2つの重要な意味があります。まず、状態を更新すると、変更が逆マークルツリーを上方へ伝播して最上部に到達するため、ルートが変化します。次に、ツリーは徐々に埋まり、最終的には容量上限に達します。そこでライトツリーのフォレストが役立ちます。

Foresterノードは状態ルートの維持を担います。状態ルートを非同期に更新し、満杯になった状態ツリーのロールオーバーを処理します。独自の状態ツリー用にForesterノードを運用する際に許可は不要で、RPCを運用する場合と同様に、誰でも自身の状態更新を管理できます。アプリ開発者には、自身の圧縮状態を維持する直接的な利害関係があります。そのため、状態ツリーを適切に管理する自然なインセンティブが生まれます。セルフホスティング用に独自のノードを運用することも、プロバイダーに料金を支払って管理を任せることもできます。

Photon

Photonインデクサーは、ブロックチェーン上の圧縮アカウントに関連する更新、作成、変更、その他のイベントを追跡および管理するためのオープンソースソリューションです。オンチェーンのアクティビティを監視し、これらのアカウントの現在の状態をキャッシュします。さらに、検証やデータ変更に使用できる暗号学的証明を生成します。

‍本番環境に対応したPhotonインデクサーには、以前の圧縮バージョンから得られた知見に基づく大幅な改善が組み込まれています。個人開発者、企業、RPCプロバイダーのいずれにとっても、使いやすく利用しやすいことを目指しています。

ローカル開発は大幅に簡単になりました。ローカル環境とシームレスに統合できるワンクリックCLIツールを備えています。開発者向けエクスプローラーも利用でき、圧縮アカウントの表示、変更の追跡、トランザクション履歴の確認を視覚的なインターフェースで行えます。

Photonは日次スナップショットを生成し、開発とデプロイを高速化します。開発者はジェネシスから再インデックスする代わりにスナップショットから開始でき、起動時間を15分以下に短縮できます。これらのスナップショットは複製も容易にします。RPCプロバイダーが圧縮サポートを終了しても、スナップショットを簡単に取得し、インデクサーを独立して運用できます。FileCoinのような分散型ソリューションに保存できるスナップショットにより、データ損失のリスクも最小限に抑えられます。

Photonではデータの一部だけを柔軟にインデックスできるため、ハードウェア要件とデータベースサイズを大幅に削減できます。これは、SQLiteと1つのCLIコマンドだけで実行できます。一方、RPCプロバイダーであれば、データセット全体をインデックスすることもできます。PhotonはすべてのHeliusプランで利用できます。独立して運用することも、別のプロバイダーに提供を依頼することもできます。

開発者が、開発者のために

私たちは開発者に完全に焦点を当て、開発者体験を向上させるために明確に設計された3つの主要な改善に積極的に取り組んでいます。

圧縮対応Web3.js

このSDKはSolana web3.jsと同様に動作しながら、圧縮を完全にサポートするよう設計されています。圧縮トークンの転送を開始するには、まず圧縮トークンアカウントを取得し、そのアカウントを使ってRPCまたは専用の証明者ノードから有効性証明を取得します。その後、SPLトークンプログラムの場合と同様に、送信するもの、数量、mint、受信者を指定して命令を構築し、通常のSolanaトランザクションを作成します。

‍完全なローカル開発環境

必要なすべてのプログラム、Photonインデクサー、ローカル証明者ノードなど、ローカル開発に必要なものをすべて事前設定したテストvalidatorを提供しています。これにより、開発者はセットアップを効率的に進められます。

Anchorマクロ

Anchorを使ったSolanaプログラム開発に慣れている方が、通常のアカウントと同じようにシームレスに圧縮アカウントを扱えるようにすることが私たちの目標です。以前にAnchorプログラムを作成したことがあれば、使い慣れた開発体験だとすぐに分かります。Anchorマクロは現在開発中です。

Airship

Airshipを使用すると、開発者は簡単かつ低コストな一括トークンエアドロップツールを通じて、今すぐZK圧縮を活用できます。ユーザーインターフェースとCLIの両方を提供しており、完全なオープンソースであるため、開発者はニーズに合わせてフォークおよび変更できます。圧縮トークンをエアドロップする開発者が増えるにつれ、エコシステムではさまざまなアプリケーションにわたって圧縮トークンの採用が進みます。ただし、すぐに変換したい場合は、開発者がトークンを即座に解凍できます。そのため、Airshipは通常のトークンにも今すぐ使えるエアドロップツールです。

‍このツールは、Solana mobile保有者、特定のトークン保有者、NFTコレクション保有者へのエアドロップを自動的にサポートします。受信者のリストを事前に生成している場合は、CSVファイルをインポートし、エアドロップするトークンと数量を指定することもできます。CLIとUIのどちらでも、インターネット接続の切断などの問題が発生した場合、最後に保存した状態からエアドロップを再開できます。これは、多数のアドレスにトークンを配布する際に30〜45分かかることがある大規模なエアドロップで特に便利です。

アプリの新たな設計領域

ZK圧縮は、すべてのアカウントの最終ルートハッシュだけをアクティブなvalidatorのメモリに保存することで、状態増大の問題に対処します。このアプローチにより、状態増大の問題を効果的に軽減できます。さらに、ZK圧縮はアプリケーションに新たな設計の可能性をもたらします。考えられるユースケースの一部を以下に示します。

• SPLトークンコンプレッサー
• 10億種類のミームコイン
• Twitter投稿の予測市場
• DePinネットワーク内のノード用識別子PDA
• 検証可能な報酬の計算と配布
• 信頼を最小化したブリッジ
• ZKアイデンティティプロトコル

ドキュメントでは、さらに多くのアイデアを紹介しています。

ZK圧縮は現在、mainnetとdevnetで稼働しています。ドキュメントを読み、サンプルを試すことで始められます。また、最大45,000ドルの賞金を用意したハッカソンも開催しています。

ZKについてさらに詳しく知りたい方は、以前のHeliusブログ記事をご覧ください。ゼロ知識証明の基礎と、そのSolanaでの応用を詳しく解説しています。

‍