Solana v1.16アップデートについて知っておくべきこと
この記事の内容
Solanaのバリデータネットワークでは、Solana Labsのバリデータクライアントに対する最新アップグレードであるバージョン1.16の採用が超多数に達しました。ボランティアとカナリアノードによる献身的な取り組みに支えられた徹底的な監査期間を経て、このマイルストーンは約10か月に及ぶ厳格な開発の集大成となりました。
以下では、v1.16のテスト方法と、ネットワークへ新機能を段階的に導入する仕組みであるSolanaのフィーチャーゲートシステムについて詳しく説明します。その後、v1.16で実装された新機能を紹介します。
v1.16はどのようにテストされたのか
v1.16は、過去数か月にわたって厳格なテストを受けてきました。v1.16リリースは2023年6月7日からtestnetで稼働し、数多くのストレステストを経ています。さらに、2023年8月23日から、一部のボランティアノードがv1.16へアップデートしました。これらのボランティアは、RPCノードの起動遅延や一般保護違反など、さまざまな問題を特定して解決しました。Solana Labsは、複数のカナリアノードもmainnet-betaにデプロイしました。これは、実環境下でv1.16ノードの安定性を監視するためです。これらのカナリアノードの過去の活動と進捗については、Solana Tech Discordの#canaries-monitoringチャンネルをご覧ください。
エッジケースや発生頻度の低い競合状態を検出するため、複数のランタイムファザーを使用して、部分的にランダム化されたトランザクションを実行しました。一貫した性能を確認するため、これらのトランザクションは異なるランタイムバージョン上で実行されました。v1.16はHalbornによる広範な監査も受けています。監査レポートは、完成次第こちらのリポジトリで順次公開されます。
フィーチャーゲート
以下で説明する機能のうち、一部は現時点ではまだ稼働していない点に注意してください。各機能はフィーチャーゲートシステムを使用して段階的に展開されます。相対的な優先度と、他のネットワークで有効化された順序に基づき、特定のエポックで機能が有効化されます。これまでフィーチャーゲートの有効化スケジュールは、こちらに記載された基準に基づいて個別に決定されてきました。基本的には、まずtestnet、次にdevnet、最後にmainnet-betaで有効化します。機能を有効化するには、必要な有効化キーペアを持つエンジニアがトランザクションを送信します。そのトランザクションが処理されると、次のエポックで機能が稼働します。適切なパフォーマンスを確保するため、各ネットワークでは一度に1つのフィーチャーゲートのみを有効化します。一部の機能には「ソーク」期間が必要な場合があり、優先度の低いゲートの有効化が遅れる可能性がある点にも注意が必要です。
このフィーチャーゲートシステムは、コンセンサスを破壊する変更により、新しいバージョンを実行するバリデータが正規チェーンからフォークし、そのままブロックを生成し続けることを防ぐために設けられています。たとえば、v1.14のバリデータはv1.16の新機能を認識しないため、競合が発生した際にネットワークをクラッシュさせる可能性があります。今週Solanaのコードベースにマージされたコミットでは、コンセンサスを破壊するすべての変更にSolana Improvement Document（SIMD）を用意することが推奨されています。今後、フィーチャーゲートのIssueテンプレートには、そのIssueに対応するSIMDの記載を求める項目が追加されます。これにより開発プロセスが標準化され、新しい変更のドキュメントを通じて透明性も高まります。
機密送金
Token2022で導入された機密送金は、ゼロ知識証明を使用してSPLトークンの残高とトランザクション金額を暗号化する機能です。この機能は、匿名性よりも機密性を重視することで、ユーザーのプライバシーを向上させることを主な目的としています。
機密送金では、暗号化された金額に対する数学的演算にTwisted ElGamal暗号を活用します。これらの送金は、ゼロ知識証明の一種であるSigma Protocolsを使用して検証されます。Sigma Protocolsでは、ある当事者（証明者）が秘密そのものを開示することなく、その秘密を知っていることを別の当事者（検証者）に証明できます。機密送金の仕組みをさらに詳しく知りたい方は、Token2022とは？をご覧ください。
機密送金の展開に伴う便利な機能として、コマンドラインインターフェース（CLI）のサポートも追加されました。create-tokenコマンドが拡張され、--enable-confidential-transfersフラグが追加されました。これにより、機密送金を有効にしたトークンをミントできます。また、特定のミントについて機密送金の設定を動的に変更できるよう、update-confidential-transfer-settingsコマンドも追加されました。これにより、監査キーと承認設定を更新できます。
ゼロ知識証明に対するランタイムサポートの強化
v1.16リリースでは、ゼロ知識計算、特に128ビット楕円曲線演算に対するランタイムサポートが強化され、Solanaのゼロ知識機能が向上しました。v1.16では、証明を効率的に生成するうえで不可欠なalt_bn128 syscallが導入されています。
alt_bn128は、Barreto-Naehrig曲線（BN-128）として知られる、暗号演算に使用される楕円曲線の特定の実装を指します。BN-128はペアリングに適した楕円曲線の一種で、zk-SNARKs（Zero-Knowledge Succinct Non-Interactive Argument of Knowledge）を効率的に実装できます。補足すると、特定の計算をより効率的に実行できる楕円曲線は「ペアリングフレンドリー」とみなされます。したがって、今回のケースではBN-128曲線を使用することで、ゼロ知識に関する数学的処理と証明を大幅に高速化できます。
Syscall（システムコール）は、オペレーティングシステムのカーネルにサービスを要求するために使用されます。Solanaでは、syscallにより、Solana Virtual Machine（SVM）上で動作するプログラムが外部リソースとやり取りできます。
つまりalt_bn128 syscallは、Solanaプログラムが非常に効率的なBN-128曲線とやり取りするために使用できる呼び出しです。これによりゼロ知識証明の検証が効率化され、Solanaでより優れたセキュリティ機能とプライバシー機能を提供できます。最近ではalt_bn128 g1およびg2 syscallも追加され、Groth16証明を圧縮できるようになりました。これらの証明は1件あたり256バイトの命令データを使用し、現在のプライベートSolanaプログラム（PSP）は2件のGroth16証明を検証する必要があるため、この機能は重要です。g1およびg2圧縮を使用すると、証明1件あたりに必要なバイト数を半分の128バイトに削減でき、領域効率が大きく向上します。
さらに、Solidityベースのコントラクトに、楕円曲線演算用の以下のプリコンパイル済みコントラクトへの呼び出しが含まれている場合、Solanaとの互換性に問題が生じます。
- bn256Add - 楕円曲線演算で加算を実行します
- bn256ScalarMult - 楕円曲線演算でスカラー乗算を実行します
- bn256Pairing - ブロックのガス上限内でzkSNARKs検証を実行するための楕円曲線ペアリング演算です
これらの演算は、EthereumではEIP-196、EIP-197、EIP-198によって標準化されています。alt_bn128 syscallの導入は、互換性の隔たりを埋めるための大きな前進です。これらの楕円曲線演算に依存するSolidityコントラクトは、Solanaへの移行やSolanaとの相互運用が容易になる可能性があります。
Solanaのv1.16アップデートにalt_bn128 syscallが組み込まれたことで、ゼロ知識証明を効率的かつ安全に処理するSolanaの能力は大きく進歩しました。alt_bn128 syscallについて詳しく知りたい方は、以下のプルリクエストをご覧ください。
バリデータ
v1.16アップデートでは、バリデータのRAM使用量が大幅に削減されました。以前のSolanaでは、アカウントのインデックス作成にRAMを使用していました。現在は、デフォルトでディスク上にアカウントのインデックスを作成するようシステムが再構成され、RAM使用量が大幅に減少しています。LuganodesのYanshu氏によると、以前のバージョンでは約120 GBのRAMを使用していたのに対し、v1.16のリリース以降、同氏のバリデータはわずか約39 GBのRAMで安定して稼働しています。
v1.16リリースでは、gossip pull-requestのピアサンプリングシステムも刷新されました。この新しいシステムは、バリデータ起動時の帯域幅を効果的に削減します。以前のバージョンでは、大量のgossip pull-requestによってバリデータの帯域幅が制約されることがありました。その結果、バリデータの動作が遅くなったり、処理能力を超えたりする可能性がありました。v1.16では、前回のリクエストからの経過時間を示す変数を導入して、この問題に対処しています。この変数で受信トラフィックの水準を測定し、レート制限を適用することで、起動中のバリデータが過負荷になるのを防ぎます。
ネットワークから遅れたステーク済みバリデータは、ステーク量に比例する新しい修復リクエスト機能により、現在の状態へさらに迅速に追いつけるようになりました。大きなステークを持つバリデータがネットワークからフォークした場合、そのバリデータは修復リクエストを送信します。大きなステークを保有しているため、今後はshredをより早く受け取れます。これによりバリデータはネットワークからフォークした状態を解消し、貢献を続けられます。RPCノードはブロックを生成しないため、修復リクエストではステーク済みバリデータの方がRPCノードよりも高い優先度を持ちます。
shredの修復を開始する遅延しきい値も、100msから200msへ引き上げられました。この変更は、最終的にTurbine経由で配信されるshredに対する修復リクエスト数を減らすために行われました。補足すると、Turbineは、Solanaが台帳エントリをすべてのノードへブロードキャストするために使用する多層ブロック伝播メカニズムです。Solanaクラスターは複数のノード層に分かれ、各層のそれぞれのノードが、次の下流層へデータを伝播する役割を担います。この調整によって不要な修復リクエストが最小限に抑えられ、Turbineのデータ伝播効率が向上するため、非常に重要です。
独自のバリデータ運用は、これまでになく簡単になりました。独自のバリデータを運用したい方に向けて、SolanaはYouTubeチャンネルで視聴できる一連のバリデータワークショップ、Solana Validator Educationを提供しています。
サイズ変更可能なアカウントのサポート
Solanaにプログラムをデプロイする際、プログラムに割り当てられる容量は常にプログラムサイズの2倍です。v1.16では、サイズ変更可能なデータアカウントを使用してプログラムをデプロイできます。つまり、より小さいアカウントでプログラムをデプロイし、後からメモリ差分の料金を支払ってサイズを拡張できます。サイズ変更可能なアカウントのサポートにより、Solanaへアプリケーションをデプロイする開発者は、柔軟性を高め、リソースをより適切に割り当てられます。
Epoch Accounts Hash
以前のバージョンでは、ブロックと、状態に含まれるすべてのアカウントの検証に関する問題がありました。バリデータが特定のアカウントと長期間やり取りしなかった場合、そのアカウントの破損したバージョンを保持していても、バリデータがそれに気付かない可能性がありました。これは、アカウントの状態を変更するトランザクションが行われない限り、そのアカウントの状態が他のバリデータノードの保持する状態と照合されなかったためです。
v1.16では、Epoch Accounts Hashを導入してこの問題に対処しています。これは、対象のアカウントに対する操作がなくても、各エポックの終了時に生成される全アカウントのハッシュです。Epoch Accounts Hashにより、ネットワークは破損したデータを持つノードを特定してフォークさせることができ、Solanaの完全性とセキュリティが向上します。
システムチューニング
システムチューニングとは、最適なパフォーマンスを実現するために、バリデータのオペレーティングシステムとハードウェア構成を最適化するプロセスです。v1.16リリースではsolana-sys-tunerが削除され、現在は手動テストが推奨されています。以前のバージョンでは、RocksDBのTransactionStatus列とAddressSignature列が適切にクリーンアップされなかったため、この機能は削除されました。さらに、ストレージ領域を回収する処理である定期的なコンパクションは、デフォルトで無効になっていました。その結果、--enable-rpc-transaction-historyフラグを使用するノードでは、これらの列が際限なく増大していました。今後、このフラグを使用するバリデータでは、以下のコミットにより、ストレージ領域がより効率的に管理されます。不要なトランザクションステータスやアドレス署名を保存する必要がなくなるため、バリデータのストレージ要件を効率化するうえで大きな改善です。
まとめ
Solanaのv1.16リリースは、10か月にわたる開発を結実させた重要なマイルストーンです。リリースに時間がかかったのはQUICが優先されたためであり、機密送金、ゼロ知識サポート、バリデータ最適化に関するこれらの進歩は待望のものでした。それでも、これらの改善は画期的です。このリリースにより、Solanaの効率性とプライバシーは新たな水準へ引き上げられます。
今後Solana Labsは、よりアジャイルなリリースサイクルへ移行し、およそ3か月ごとに新しいリリースを提供する予定です。将来のリリースは、v1.16よりも大幅に小規模になります。これにより、デプロイ時のイテレーションが高速化し、リスクも軽減されます。v1.17のリリーススケジュールはこちらで確認できます。ゼロ知識サポートのさらなる強化と、Posidon syscallが導入される可能性があり、今回も非常に期待されるリリースとなっています。
匿名の皆さん、ここまでお読みいただきありがとうございます。よりアジャイルなリリースサイクルと数多くの新機能や改善により、Solanaの未来はこれまで以上に明るいものになっています。開発者、投資家、バリデータ運用者、Solanaファンのいずれであっても、今後のリリースにぜひご注目ください。Solanaの旅はまだ始まったばかりです。
その他のリソースと参考資料
Heliusを購読
Solana開発の最新情報や新しい記事の公開通知を受け取れます