Solana v1.17アップデートについて知っておくべきこと
この記事の内容
Solanaネットワークは、Solana Labsのバリデータクライアントの最新バージョンである1.17が圧倒的多数に採用され、重要なマイルストーンに到達しました。最近のネットワーク障害後、バリデータはバージョン1.17.20を使用して再起動しました。執筆時点では、バリデータの~68.6%がバージョン1.17.21を、~31.3%がバージョン1.17.20を実行しています。 この新バージョンでは、ネットワークの効率性、スケーラビリティ、ユースケースを強化する一連の改善が導入されています。ゼロ知識証明の先進的な進歩からGossipプロトコルの改良まで、v1.17はSolanaの継続的な開発における重要な一歩です。
この記事では、Solana Labsのバリデータクライアントのバージョン1.17アップデートについて知っておくべきことをすべて解説します。v1.17で実施された厳格なテスト、最近のネットワーク障害、このアップデートで実装された新機能を見ていきます。
v1.17はどのようにテストされたのか
v1.17は2023年10月3日からtestnetで稼働しています。高いトランザクション負荷をかけるストレステストも定期的に実施されました。Solana Labsは、実環境での安定性を監視するため、v1.17を実行するmainnet-betaのカナリアノードもいくつかデプロイしました。これらは過去数か月にわたって安定しています。カナリアノードの過去のアクティビティと進捗は、 Solana Tech Discordの**#canaries-monitoring**チャンネルで確認できます。さらに、2023年12月4日から、mainnet-betaの有志ノードの一部がv1.17へアップグレードしました。
部分的にランダム化したトランザクションを実行し、エッジケースや発生頻度の低い競合状態を検出するため、複数のランタイムファザーが開発されました。一貫した性能を保証するため、これらのトランザクションは複数のバージョンで実行されました。v1.17は外部監査機関による監査も複数回受けており、利用可能になり次第、Solanaセキュリティ監査のGitHubリポジトリに掲載されます。
2月の障害
2024年2月6日9時53分（UTC）、mainnet-betaで障害が発生し、ブロックのファイナライズが一時停止しました。14時55分（UTC）にコンセンサスが再開するまで、ネットワークのアクティビティは約5時間中断しました。この障害は、ネットワークが実行用のプログラムコードをコンパイルしてキャッシュする方法に関連するバグに起因し、特に旧バージョンのプログラムローダーに影響しました。
根本原因は、頻繁に使用されるプログラムのJust-in-time（JIT）コンパイル済み出力をバリデータが処理する方法にありました。この処理を最適化するための新しいキャッシュシステムが、意図せず致命的なバグを引き起こしました。この新システムは、特定のレガシープログラムで無限再コンパイルループに陥る可能性がありました。大半のバリデータがこの問題に遭遇してトランザクション処理を継続できなくなったため、Solanaのコンセンサスメカニズムが停止しました。
このバグは直近のdevnet障害と多くの類似点があったため、根本原因は迅速に特定されました。1.17.20は問題へ直接対処するよう修正され、バリデータは連携してネットワークを再起動しました。修正は2段階で行われました。短期的な対策として、ループを引き起こす可能性のある2つのレガシーローダーを非推奨にして無限ループの発生を防ぎ、より包括的な対策として、今後同様の問題が起きないよう新しいプログラムキャッシュシステムを調整しました。
ZK Token Proof Program
ZK Token Proof Programは1.16アップデートでリリースされる予定でしたが、大規模な監査により有効化が延期されました。Feature Gate Activation Scheduleでは、このプログラムは最低バージョン1.17.12で「Testnetでの有効化待ち」と記載されています。
Confidential Transfers
ZK Token Proof Programの有効化により、ついにConfidential Transfersが利用可能になります。Confidential Transfersはゼロ知識証明を使用し、SPLトークンのトークン残高と送金額を暗号化します。ここでの全体的な目的は、匿名性ではなく機密性です。準同型暗号を使うと、暗号化されたデータを復号せずに計算できます。たとえば、対象額を復号して再暗号化することなく、残高を加算または減算できます。そのため、これらの計算は平文に適用した場合と同じ方法で暗号化されたまま実行されます。
Confidential TransfersはTwisted ElGamal EncryptionとSigma Protocolsを使用し、機密情報を開示せずに安全でプライベートなトランザクションを実現します。
補足すると、
- Twisted ElGamal Encryptionは標準的なElGamal暗号方式のシンプルな変種です。暗号文を、暗号化されたメッセージのPedersenコミットメントと復号ハンドルに分割し、暗号文に対する秘匿された数学的演算を可能にします
- Sigma ProtocolsはConfidential Transfersの検証に使用されます。これはゼロ知識証明の特殊なクラスで、一方の当事者（証明者）が、特定の情報を明かすことなく、その情報を知っていることを別の当事者（検証者）に証明できます
Confidential Transfersでは、復号鍵を保持するアカウントだけが暗号化された残高を確認できます。Global Auditor Systemは、第三者による確認が必要な状況（コンプライアンスチェックや監査など）のために実装されています。このシステムでは、アカウント所有者が別個の復号鍵を通じて特定のアカウントへの選択的な読み取りアクセスを付与できます。また、安全な監査を可能にするため、mintに「監査者暗号鍵」を組み込んでいます。
トランザクションでは、送信者、受信者、監査者の金額に暗号化されたパラメータを使用し、証明によってプライバシーと完全性を確保します。フロントランニング攻撃を防ぐため、アカウント残高は「Pending」と「Available」に分割されます。そうしなければ、悪意のあるユーザーがアカウントにトークンを送信し、暗号化された残高を使って生成された証明を無効化できてしまいます。
Confidential Transfersでは、新しいキーペアを使用する必要がある点に注意してください。
コマンドラインのサポート
spl-token crateを介したConfidential Transfers向けCommand Line Interface（CLI）のサポートも利用可能です。有効化後、create-tokenコマンドは–enable-confidential-transfers autoフラグを含むよう拡張されています。これにより、Confidential Transfers拡張機能を有効にしたトークンをmintできます。ほかにも、次のような便利なコマンドがあります。
configure-confidential-transfer-account- 既存のアカウントをConfidential Transfers向けに構成します。アカウントのConfidential Transfersを構成できるのは、そのアカウントの所有者だけですdeposit-confidential-tokens- 非機密アカウントから機密アカウントへトークンを入金します。入金されたトークンは機密残高へ完全に移動するため、アカウントの非機密残高には存在しなくなりますapply-pending-balance- 残高を「Pending」から「Available」へ移動します。アカウントが送金や入金によって機密トークンを受け取ると、その残高はアカウントの「Pending」残高に表示されるため、この操作が必要です。そのため、ユーザーは資金へすぐにはアクセスできず、保留中の残高を適用する必要がありますtransfer（–confidentialフラグを有効化） - Confidential Transfers向けに構成された別のアカウントへトークンを送金します。この操作には依存関係のある複数のトランザクションが必要なため、通常のトークン送金より時間がかかる場合がありますwithdraw-confidential-tokens- アカウントの機密残高から非機密残高へトークンを引き出します。想定されるすべてのトークンを引き出すには、このコマンドを実行する前に保留中の残高が適用されていることを確認してくださいupdate-confidential-transfer-settings- 指定したトークンmintのConfidential Transfer構成を更新します。Confidential Transfersを承認するポリシーの自動設定（–aprove-policyフラグ）と、監査者の公開鍵の設定（–auditor-pubkeyフラグ）が可能です。さらに、blockhash、Confidential Transferのauthority、構成ファイル、fee payerの詳細、JSON RPC URL、nonceアカウントの詳細、出力形式、トークンプログラムIDを指定するフラグもあります
互換性
次の拡張機能の組み合わせは、動作しないか、Confidential Transfersと組み合わせる意味がないことに注意してください。
- Confidential Transfer + 譲渡不可
- Confidential Transfer + 手数料（1.18までは動作しません）
- Confidential Transfer + Transfer Hooks（これらの送金では送信元または送信先アカウントしか確認できず、送金額に基づく処理を実行できないためです）
監査
Confidential Transfers、およびToken-2022 Program全般は、Halborn、Zellic、Trail of Bits、NCC Group、OtterSecなどの企業による大規模な監査を受けています。OtterSecは2回監査を行い、1回目の監査ではToken-2022、2回目の監査ではConfidential Transfersに焦点を当てました。
Poseidon syscall
Poseidonは、ゼロ知識証明に適したハッシュ関数ファミリーです。Poseidonハッシュ関数は、Zcash、Mina、SolanaのLight Protocolなど、ZKベースのブロックチェーンプロジェクトの多くで使用されています。現在、Solana上でPoseidonハッシュを計算するにはコストがかかりすぎるため、1つのトランザクションでは実行できません。Poseidon syscallは、この状況を変えると期待されています。現在は、testnetでの有効化待ちとしてv1.17.5でのリリースが予定されています。
初心者向けの説明
安全な通信で使われる特定の種類のパズルを効率よく解く、高性能な電卓を想像してください。この電卓は、情報の断片を受け取り、細かく分割して、独自の方法で混ぜ合わせます。元の内容は完全に隠されますが、検証は可能な状態になるよう情報を混ぜ合わせます。
この混合処理では、あらかじめ定められた特定の数の集合に含まれる数値を加算し、特定の指数で累乗する特殊な方法を使います。この方法により、毎回、徹底的かつ一貫した混合が行われます。
Poseidonは、この高性能な電卓とまったく同じことを行います。この種のハッシュ関数は、ゼロ知識回路の作成に非常に適しています。回路とは、基本的には数学的演算の集合です。一方の当事者（証明者）が、特定の情報を明かさずに、その情報を知っていることを別の当事者（検証者）へ証明する仕組みを数学的に表します。一般的には、封をした箱を実際に開けずに、中身を知っていると証明することだと考えてください。箱を封じた人に対して、一連の叩き方や手順によって証明できます。これらの叩き方や手順は、箱の中身や開け方を一切明かさず、箱を開けたことがある人にしか理解できないよう設計されています。
トランザクションを非公開に保ちながら真正性を検証できることは極めて重要なため、これはブロックチェーンにとって有用です。
ZKに適した特性
Poseidonハッシュ関数がゼロ知識証明に適しているとされる理由はいくつかあります。具体的には、
- Poseidonは、ゼロ知識証明の計算で一般的な算術演算（加算、乗算、累乗）を効率的に実行できるよう設計されています
- ゼロ知識証明システムでは、計算ロジックを暗号学的証明に変換する必要があります。Poseidonは、算術演算に適した設計、最適化されたS-box、カスタマイズ可能なパラメータ、少ないラウンド数（入力データまたはハッシュ関数の内部状態に反復適用される一連の演算）により、ほかのハッシュ関数より回路の複雑性を抑えられます。つまり、特定のデータに対する証明をより少ない手順で生成できます
- Poseidonハッシュ関数はスポンジ構造に基づいています。つまりPoseidonは、任意の長さのビット列を受け取り、任意の長さの出力を生成するアルゴリズム群を使って設計されています。そのため、Poseidonハッシュ関数をさまざまなゼロ知識アプリケーションへ非常に簡単に統合できます。
従来のハッシュ関数との比較
ゼロ知識証明向けに調整されたPoseidonの計算効率は、SHA-256などの従来のハッシュ関数が行う、より汎用的で計算負荷の高い処理に対して明確な優位性があります。
従来のハッシュ関数は安全で信頼性が高い一方、ゼロ知識証明内でより大規模かつ複雑な回路を生み出す傾向があります。これは、これらのハッシュ関数が本来、ゼロ知識証明システム固有の制約を考慮して設計されていないためです。ブロックチェーン上のゼロ知識証明は、計算に有限体を使用します。有限体とは、すべての算術演算（加算、減算、乗算、除算）を素数で剰余演算する数の集合です。これにより値が集合内で循環し、すべての演算結果がこの数の集合内に収まります。
SHA-256などの従来のハッシュ関数は、ビット演算と事前に定められた演算手順に大きく依存しています。これらの機能は、有限体で使用される算術演算と直接互換性がありません。有限体のコンテキストでこれらの演算を実装するには追加の手順が必要となり、最終的に回路が複雑になります。
さらに、従来のハッシュ関数は通常、2の累乗に基づく剰余演算を使用します。これは、素数を基礎とすることが多いゼロ知識証明の有限体で使われる剰余演算とは異なります。この非互換性によってさらに多くの手順が必要となり、回路のサイズと複雑性が増します。
ゼロ知識証明を構築する目的は、特定の情報を明かさずに、その情報を知っていることを証明する計算ロジックの数学的表現を作成することです。この知識を効率的かつシンプルに表現することが、証明のスケーラビリティに不可欠です。Poseidonファミリーのハッシュ関数は、有限体内で効率的な演算を使用することで、これらのニーズへ直接対応し、回路の作成に必要な手順を大幅に削減します。その結果、より小さく単純な回路になります。従来のハッシュ関数は、回路構築のニーズへ直接対応するものではなく、汎用目的で設計されています。
v1.17へのPoseidon syscallの統合は、Solana上でゼロ知識証明を効率的に生成、検証するため、専用の暗号ツールを使用する方向への転換を示しています。これにより、トランザクション処理が高速化し、コストが削減され、ゼロ知識計算のスケーラビリティが向上します。Poseidonの柔軟性とカスタマイズ性も相まって、Solana上でのゼロ知識証明の生成と検証が大幅に容易になりました。
具体的な実装
v1.17では、2次元バイトスライスを入力として受け取り、対応するPoseidonハッシュを出力として計算するsol_poseidon syscall、つまりシステムコールが導入されます。BN254曲線を使用し、次のPoseidonパラメータを受け取ります。
- x^5 S-box（置換ボックス）
- 1 ≤ n ≤ 12の入力
- 2 ≤ t ≤ 13の幅
- 8回のフルラウンドと、tに応じた部分ラウンド：[56, 57, 56, 60, 60, 63, 64, 63, 60, 66, 60, 65]
これらのPoseidonハッシュの計算には、監査済みでCircomと互換性のあるlight-posiedon crateが使用されます。
次のセクションでは、alt_bn128 syscallの追加について説明します。BN254は通称BN128（セキュリティビット数に由来）、alt_bn128、またはalt_bn_128と呼ばれます。ここでは、いずれも同じ曲線を指しています。
alt_bn128 syscall
v1.16では、ゼロ知識計算、特に128ビット楕円曲線演算のランタイムサポート強化が提案されました。 証明の効率的な生成に不可欠なalt_bn128 syscallは、v1.16でリリースされる予定でしたが延期されました。Feature Gate Activation Scheduleでは現在、alt_bn128 syscallはmainnet-betaでの有効化待ちとしてv1.17.15に、alt_bn128圧縮はtestnetでの有効化待ちとしてv1.17.15に予定されています。
さらに詳しく知りたい方への補足として、alt_bn128はBarreto-Naehrig（BN-128）楕円曲線の実装を指します。これは、効率的なzk-SNARK（Zero-Knowledge Succinct Non-Interactive Argument of Knowledge）を可能にする、ペアリングに適した特定の楕円曲線です。特定のゼロ知識計算と証明をより効率的に実行できるため、「ペアリングフレンドリー」とされています。Solanaでは、alt_bn128 syscallにより、プログラムがこの曲線を利用してゼロ知識証明の検証を効率化し、セキュリティとプライバシーを強化できます。alt_bn128のg1およびg2 syscallの追加は、Groth16証明の圧縮に役立ちます。これにより、証明ごとに必要な領域が大幅に減り、Solanaプログラムの領域効率が向上します。
alt_bn128 syscallの導入は、Solanaと、EIP-196、EIP-197、EIP-198で規定された楕円曲線演算用のプリコンパイル済みコントラクトに依存するSolidityベースのコントラクトとの互換性の差を縮めます。これらの演算（bn256Add、bn256ScalarMult、bn256Pairing）は、Ethereumのgas制限内でのzk-SNARK検証を可能にします。これらの楕円曲線演算に依存するSolidityコントラクトは、Solanaへの移行やSolanaとの相互運用が容易になる可能性があります。
Gossipの改善
v1.17では、pushメッセージの伝播を強化し、pullリクエストへの依存を減らすことで、Gossipメッセージの伝播効率を向上させます。Gossipプロトコルの処理を効率化することで、コンセンサスバリデータのリソース使用量を削減できます。
前提として、SolanaのGossip Serviceは、バリデータ間の情報交換に不可欠です。これには、台帳の高さ、連絡先情報、コンセンサス投票などが含まれます。「push」と「pull」のメッセージを使用して、ネットワーク全体で情報を共有、検証します。このメッセージングシステムにより、すべてのノードが同期された状態に保たれます。
従来、AccountsHashVerifierはアカウントハッシュをGossipへpushしていました。しかし、このデータをpullするネットワークコンポーネントは存在せず、この処理は冗長でした。EpochAccountsHashの導入に伴い、Gossipのアカウントハッシュと既知のバリデータの値を比較するような従来の処理は削除されました。 getHealth RPCメソッドも、Gossipのアカウントハッシュに依存しないよう書き直されました。これについては次のセクションで詳しく説明します。そのため、v1.17以降、Gossipからアカウントハッシュをpullするものはありません。AccountsHashVerifierはアカウントをGossipへpushしないよう変更され、Gossipとの間でアカウントハッシュをpushおよびpullする関数も削除されました。
getHealth
以前は、getHealth RPC呼び出しが、特定のノードについて誤った状態を返すことがありました。これは、solana catchup CLIコマンドとgetHealth RPC呼び出しに食い違いがあり、ノードが同時に追いついているとも遅れているとも表示される可能性があったためです。その結果、正常なノードが誤って異常と判定され、RPCプールから削除される可能性がありました。
当初、正常性はGossipで公開されたローカルアカウントハッシュのスロットをほかのノードのものと比較して判定され、デフォルトの比較値には100スロットが使用されていました。これは、特に100スロットを超える値で構成されたノードでは不正確になる可能性がありました。getHealthは、クラスターで最新の楽観的に確認されたスロットを使用するよう書き直されました。これは、すべてのバリデータが処理し、圧倒的多数によって確認されたものの、まだファイナライズされていない最後のスロットです。クラスターで確認されたスロットを、楽観的に確認された最新のbankと比較することで、ノードがどの程度遅れているかを判断できるため、より正確な比較が可能です。この変更により、よりきめ細かなチェックが可能になり、偽陰性（正常なノードが異常と判定されること）の可能性が低下します。また、既知のバリデータに影響する問題による連鎖的な影響も回避できます。
getHealthの問題へ対処するため、wait-for-restart-windowおよびexitコマンドには–skip-health-checkフラグも追加されました。これにより、バリデータはノードが正常かどうかの確認を省略できます。
QUIC
v1.17では、QUICを使用してshredをブロードキャストし、修復を実行できるようになります。Turbineおよび修復用QUICエンドポイントは、testnetがQUICへ完全に移行するまでは不要なため、現在無効になっています。ただし、これはこれらのプロトコルをQUICへ移行するための基盤となります。この基盤機能を導入するため、次のような複数のPRがマージされています。
非同期TPU接続
v1.17では非同期TPUクライアント接続が導入され、接続キャッシュの仕組みが大幅に改善されます。このアップデートは、デフォルトの接続プールサイズを4としてバックグラウンドで接続を確立できるようにし、トランザクションのレイテンシを削減するものです。非同期TPUクライアント接続により、同期接続に伴う待機時間なしで、よりスムーズにトランザクションを処理できます。
バリデータ起動の効率化とスナップショット形式の更新
v1.17では、新しいフラグの導入と、サポートされるスナップショットファイル形式の更新により、バリデータの起動プロセスが効率化されます。これによりバリデータの起動時間が短縮され、ダウンタイムが減ることでネットワークのレジリエンス向上につながります。
v1.17では、新しい–use-snapshot-archives-at-startupフラグが導入されます。これによりバリデータは、ローカルスナップショット、ディスク上のローカル状態、または両者のうち新しい方を自動選択することで、起動プロセスを高速化できます。このフラグにより、ディスク上の状態の方が新しい場合はスナップショットを処理する必要がなくなり、再起動時間が短縮されます。
以前のSolanaは、スナップショットにさまざまな圧縮形式をサポートしていました。アーカイブ形式には、bz2、gzip、zstd、lz4、tar、圧縮なしが含まれていました。しかし、最新のアップデートでは、効率を最適化し、サポートの複雑性を減らすため、選択肢がzstdまたはlz4に絞られます。–snapshot-archive-format引数ではほかの形式が非推奨となりましたが、後方互換性を確保するため、バリデータはこれらの形式の既存スナップショットを引き続き読み取れます。これにより、solana-validatorとsolana-ledger-toolのコマンドラインインターフェースが自然に簡素化されます。
まとめ
多数の機能実装と、最近のネットワーク障害への迅速な対応により、Solanaのv1.17アップデートは大きな前進となります。ZK Token Program、Poseidon syscall、alt_bn128 syscallのリリースにより、これまでにないゼロ知識サポートと機能が導入されます。バリデータとネットワーク効率の改善と合わせて、このアップデートは次のバージョンアップデートに向けた強固な基盤となります。このアップデートはv1.16より小規模で、3か月に一度の新バージョンリリースという目標に沿っています。1.18のリリーススケジュールはこちらから確認できます。
ここまでお読みいただき、ありがとうございます、anon！Solanaの最新情報を見逃さないよう、以下にメールアドレスを入力してください。さらに深く学ぶ準備はできましたか？Heliusブログの最新記事を読み、今日からSolanaの旅を続けましょう。
その他のリソース
関連記事
Heliusを購読
Solana開発の最新情報や新しい記事の公開通知を受け取れます