Agave v2.1アップデート：知っておくべきすべてのこと

Agave 2.1リリースサイクルの注目すべきアップデート 

• 広範なパフォーマンス最適化
• ブロック上限の引き上げ
• 貪欲スケジューラの導入（試験的）
• Secp256r1署名検証のネイティブサポート（更新：Agave 2.2に延期）
• レント料金徴収とレント再書き込みの無効化
• トランザクション読み込み失敗に関する制約の緩和
• ConfigおよびAddress Lookup TableプログラムのCore BPFへの移行

本記事の各セクションは単独でも読めるように構成されているため、自由に移動し、最も関心のあるトピックに集中できます。バリデータ運用者、開発者、アクティブユーザーのいずれであっても、Agave 2.1に関するこの詳細な概要から、これらの進歩を効果的に活用するために必要な知見を得られます。

機能の展開

本稿執筆時点では、ステークの88%がAgaveバージョン2.1.11で稼働しています。v2.1の普及を促すため、mainnetでのフィーチャーゲートの有効化は一時停止されていましたが、予定されている有効化順序に従って近日中に再開される見込みです。 

後半のセクションで説明する新機能の大半は、現時点ではまだ稼働していません。フィーチャーゲートシステムを使用し、2.1リリースサイクルを通じて展開される予定です。機能は、相対的な優先度とtestnetおよびdevnetクラスターで有効化された順序に基づき、特定のエポックで有効化されます。

パフォーマンスの強化

バリデータおよびRPC運用者からは、Agave 2.1によって安定性とパフォーマンスが明確に向上したとの報告が寄せられています。過去1年間、Anzaはボトルネックの解消、リソース効率の最適化、全体的なパフォーマンスの強化を優先してきました。新しいクライアントリリースでは、新機能の導入と同じくらい、帯域幅を広げ、レイテンシを短縮するという中核的な基盤の改善が重視されています。2.1アップデートの詳細に入る前に、少し視点を引き、直近の一連のクライアントアップデートで達成された大幅なパフォーマンス向上を数値で確認します。

ブロック時間

Solanaではブロック時間の短縮により、平均スロット時間が400msを下回っています。最近のエポックは2日をわずかに下回るペースで完了しており、これはネットワーク史上最速です。両クライアントとも、より短いブロック時間に対応する準備が整っています。この高速化は、トランザクションスループットの向上以外にも影響を及ぼします。ステーキング報酬は、暦年ではなく「エポック年」を用いて計算されるインフレ発行量に連動するため、バリデータとステーカーには恩恵があります。エポック年は、標準的なエポック期間である2日を基準に、年間182.5エポックと仮定します。エポックが短くなると、同じ期間内により多くのエポックが収まり、ステーキング報酬の分配速度が実質的に高まります。

稼働率

Solanaは2024年から2025年初頭にかけてほぼ完璧な信頼性を示し、1年以上にわたって100%の稼働率を維持しました。最後に記録された障害は2024年2月6日に発生し、既知のバグによってMainnetのブロックファイナライズが一時的に中断しました。この問題はすぐに特定され、修正されました。それ以降、Solanaは、Trump一家によるトークンローンチが引き起こした最近の急増のようなネットワーク負荷が非常に高い期間にも、途切れることなくブロックを生成しています。これにより、高負荷下でのレジリエンスが実証されています。

スロットスキップ率

スロットスキップ率は、特定のスロットのリーダーに割り当てられたバリデータが、割り当てられた時間内にブロックを生成できない頻度を示します。2024年11月のエポック700前後以降、スロットスキップ率は劇的に低下しました。それ以前は数年間にわたり2%から5%の間で変動していましたが、現在では十分に最適化されたバリデータの大半でほぼゼロまで低下しています。  

この改善に寄与した要因の一つが、エポック707でmainnetに導入された分割エポック報酬です。ステーク報酬を複数のブロックに分散することで、新しいエポックの最初のブロックに報酬分配が集中することによるパフォーマンス上のボトルネックを軽減し、ネットワークをより円滑に稼働させます。

さらに、2024年11月に導入されたTimely Vote Credits（TVC）は、バリデータに迅速な投票を促し、遅延投票を抑制します。意図的に投票を遅らせるバリデータの数を減らすことで、TVCはクラスターの収束を改善し、確認とファイナリティを高速化します。この仕組みはフォークを最小限に抑え、フォークの継続時間を短縮します。現在ではTVCスコアがステークプールのランキングに影響するため、運用者はハードウェアをアップグレードし、バリデータ構成を最適化してパフォーマンスを向上させています。

1秒あたりのトランザクション数（TPS）

1秒あたりのトランザクション数（TPS）が多いほど、チェーンのスループットが高いことを示します。Solanaの非投票TPS（別名「実TPS」）は、2023年後半から着実に上昇しています。2025年2月第1週の最新データによると、ネットワークの50パーセンタイル平均は1,228 TPSを記録し、99パーセンタイルのピークパフォーマンスは2,520 TPSに達しました。  

過去最高のTPSは、2024年12月23日までのPENGUトークンのエアドロップ週に観測されました。このとき、50パーセンタイルの平均は1,260 TPS、99パーセンタイルのピークは3,252 TPSでした。この持続的な成長は、Solanaの継続的なスケーラビリティ向上とトランザクション処理効率の改善を示しています。

優先手数料

最後に、2025年1月27日から2月4日までのAgave 2.1と以前の2.0バージョンにおける優先手数料の徴収額を比較すると、Agave 2.1は一貫してわずかに高い優先手数料を徴収しています。

ブロック上限の引き上げ

SIMD-0207: Raise Block Limit to 50Mで提案されたブロック上限の引き上げは、Solanaの2.1リリースサイクルで実施される予定です。現在、プロトコルではブロックごとの総計算リソースが4,800万Compute Units（CU）に制限されています。ブロック上限は、リーダーが1つのブロックに含められる処理量を制限し、ノードがネットワークに追従できるようにします。創設チームは、バリデータが合理的に処理でき、ブロック時間を400ミリ秒に収められる量に基づき、実証的に現在の上限を決定しました。 

しかし、現在のmainnetアクティビティは実行時間による制約を受けていないため、400msの目標を超えることなく、ブロックにより多くのトランザクションを含められます。このアップデートでは、ネットワーク容量を段階的に拡大するため、ブロックごとの計算上限を48M CUから50M CUへと4%引き上げます。上限を2倍にするなど、より積極的な引き上げも実現可能ですが、最初の変更としてはリスクが高すぎると判断されました。ブロック上限の拡大はバリデータだけでなく、RPCノード、インデクサー、アーカイブサービスなどの重要なインフラにも影響するため、それらも適切にスケールする必要があります。

その他のプロトコル上限は変更されません。

• ブロックごとのアカウント単位の計算上限は12M CUのままです。
• トランザクションごとの最大計算量は1.4M CUのままです。

ブロック上限は今後さらに引き上げられる見込みであり、正式なSIMDプロセスを通じて進められる予定です。

貪欲スケジューラ

背景：中央スケジューラ

前回の主要なスケジューラアップデートである中央スケジューラは、昨年5月にAgave 1.18で導入されました。このスケジューラは、優先度の高い上位N件のトランザクションから依存関係グラフを構築します。現在、Nは256に設定されています。その後、競合しないトランザクションが先に処理されるようにしながら、優先度順にトランザクションのスケジュールを試みます。スケジュールされたトランザクションはグラフから削除されるため、それまで競合していたトランザクションを優先できるようになります。その後、スケジューラはグラフを再補充し、N件のトランザクションからなるキューを維持します。

このアプローチは主に、大規模なバッチ処理を最適化し、トランザクション全体のスループットを向上させるために設計されました。しかし、大きな欠点の一つは、依存関係グラフの構築とトランザクションの並べ替えにかなりの時間がかかり、ボトルネックになることです。 

Agave 1.18と中央スケジューラの実装について詳しくは、以前のHeliusブログ記事をご覧ください。

新しい貪欲スケジューラ

中央スケジューラとは異なり、貪欲スケジューラは依存関係グラフを構築しません。代わりに、より単純なアプローチを採用します。

• まず、最も優先度の高いトランザクションを選択します。
• そのトランザクションが進行中のバッチと競合しない場合、4つあるワーカースレッドキューのいずれかに追加します。
• 競合が発生した場合、現在のバッチを確定して送信し、そのトランザクションを新しいバッチに追加します。

この方法はトランザクションのスケジューリングを大幅に高速化しますが、バッチサイズが小さくなるため、トランザクションごとのオーバーヘッドが増加します。しかし、実際のmainnet環境では、実行時間の大半を占めるのはバッチ処理ではなくBPF処理であるため、このトレードオフには価値があります。

中央スケジューラは、トランザクションの並べ替えと依存関係グラフの構築に時間を要するため、ネットワーク負荷が高い状況では処理に苦戦します。このオーバーヘッドを取り除くことで、貪欲スケジューラはバッチ処理効率と引き換えに応答性を向上させます。

トランザクションがA、B、Cという3つの競合グループに分かれる場合を考えます。あるトランザクションが、別のトランザクションが読み取りまたは書き込みを行おうとするアカウントに書き込もうとすると、トランザクション同士が競合します。Aのトランザクションは、BまたはCのトランザクションよりも優先手数料が高いものとします。

• 中央スケジューラは、競合しないトランザクションA1、B1、C1を1つのバッチとしてまとめてスケジュールします：[A1, B1, C1]。
• 貪欲スケジューラは手数料が最も高いトランザクションを優先し、A1を個別のバッチとしてスケジュールした後、次のバッチでA2に進みます。

この優先順位付けによってスケジューリングは高速になりますが、中央スケジューラよりもバッチが小さくなる可能性があります。

Secp256r1署名を検証するネイティブプログラム

Solanaは、secp256r1楕円曲線署名を検証する新しいネイティブプログラムを導入し、Passkeysのオンチェーンサポートを実現します。これにより、WebAuthn標準や、2要素認証（2FA）を含む新しいアカウント抽象化モデルにも対応します。この強化により、Web2ですでに広く利用されているパスワードレス認証を、オンチェーンセキュリティの第2要素として活用できるようになります。

secp256r1楕円曲線はNISTによって標準化された暗号曲線であり、以下を含む最新のデバイスで広くサポートされています。

• WebAuthn: 公開鍵暗号に基づく認証のW3C標準で、主要なすべてのWebブラウザに対応しています。
• AppleのSecure Enclave: メッセージに署名し、生体認証を通じてのみアクセスできる、ハードウェアベースのTrusted Execution Environment（TEE）です。
• Android Keystore: 秘密鍵と署名方式を管理するAPIで、デバイスのTEEを利用して鍵を安全に保存します。
• Passkeys: パスワードを暗号鍵ペアに置き換えるFIDO AllianceおよびW3Cの標準で、楕円曲線暗号と互換性があります。

Ethereum（EIP-7212）を含む他の複数のネットワークでも、secp256r1曲線のサポート統合が検討されています。

Secp256r1プログラムの詳細

新しいプログラムは、次のIDでデプロイされます：Secp256r1SigVerify1111111111111111111111111

命令の構造：

• u8カウンターで、検証する署名の数を指定します。
• その後に1バイトのパディングが続きます。
• 各署名には、次のシリアライズ済みstructを使用します。

struct Secp256r1SignatureOffsets {
    signature_offset: u16,             // offset to secp256r1 signature of 64 bytes
    signature_instruction_index: u16,  // instruction index to find signature
    public_key_offset: u16,            // offset to public key of 32 bytes
    public_key_instruction_index: u16, // instruction index to find public key
    message_data_offset: u16,          // offset to start of message data
    message_data_size: u16,            // size of message data
    message_instruction_index: u16,    // index of instruction data to get msg data
}

このアップデートは、Bunkrチームが提案したSIMD-0048: Native Program for Secp256r1 Sigverifyに基づいています。Secp256r1 SigVerify Precompile Programは、Solanaが既存でサポートするsecp256k1およびed25519署名と同様に機能します。

レント料金徴収の無効化とレント再書き込みのスキップ

SIMD-0084: Disable Rent Fees CollectionおよびSIMD-0183: Skip Rent Rewritesで提案された2つの関連アップデートにより、レントを支払うアカウントに関連する従来のオーバーヘッドの大部分が解消されます。

レント料金の徴収は、Bank内の複雑なコンポーネントです。これを無効化することで、バリデータクライアントのコードベースが簡素化され、すべてのバリデータクライアント実装の開発が効率化されます。レント徴収ロジックを各実装で再現する必要がなくなるためです。アカウントからレントが差し引かれることはなくなり、徴収されたレント料金がバリデータに分配されることもなくなります。レントを支払う新規アカウントはすでに作成できなくなっており、作成を試みるとトランザクションエラーになります。

現在、レント徴収では各アカウントをエポックごとに少なくとも1回確認し、変更がない場合でもアカウントを読み込んで保存します。Solanaのすべてのアカウントはすでにレント免除となっているため、この処理を維持することは不要な計算作業です。

レントに関連するアカウントの再書き込みが廃止され、スロットごとに保存されるアカウント数が減少します。その結果、accounts delta hashおよびincremental account hashの計算対象となるアカウントが減り、バリデータのパフォーマンスが向上します。この変更によりincremental snapshotのサイズも縮小され、リソース消費がさらに削減されます。

トランザクション制約の緩和：読み込み失敗

現在、Solanaのトランザクションには厳格な制約があり、ブロックに含まれる前に失敗する場合があります。このようなブロック前の失敗では、トランザクション手数料を得られないままリソースが消費されるため、バリデータの計算処理が無駄になります。実質的には、報酬なしで処理を行うことになります。

無効なプログラムを呼び出すトランザクションや、読み込まれるアカウントデータの上限である64 MiB（~67.11 MB）を超えるトランザクションを除外する必要があるため、ブロック生成はさらに複雑になります。これらの制限によりブロック構築の複雑性が増し、ブロックの有効性を判断することが難しくなります。これらの制約を緩和することで、プログラムデータを事前に読み込んで検証しなくても、トランザクションをブロックに含めて手数料を課せるようになります。この変更は、ブロック検証におけるアカウント状態への依存をなくすことを目的としています。

SIMD-0191で提案されたこれらの変更は、すべてのトランザクションが実行を試みると仮定しているブロックチェーンエクスプローラーなどのツールに影響する可能性があります。また、不要な手数料の支払いを避けるため、ユーザーは自分のトランザクションが実行可能であることを確認する必要があります。

ConfigおよびAddress Lookup TableプログラムのCore BPFへの移行

ネイティブの組み込みプログラムからBerkeley Packet Filter（BPF）プログラムへの移行の一環として、ConfigおよびAddress Lookup TableプログラムはCore BPFプログラムへ移行されます。この移行により、これらの重要なプログラムがバリデータランタイムから分離され、より柔軟なアップデートと容易なメンテナンスが可能になります。

BPFプログラムはネイティブ版よりも複雑性が低く、異なるバリデータクライアント間での開発とメンテナンスが簡素化されます。この変更により、FiredancerとAnzaに取り組むチームは、それぞれのランタイムでプログラムの変更を個別に追跡して実装する必要がなくなります。代わりに、アップデートはすべてのクライアントへ一律に適用されます。 

再実装されたプログラムは、ネイティブ版と同一のABIを維持します。計算リソースの使用量のみが異なり、完全な互換性が確保されます。

まとめ

Agave 2.1アップデートはSolanaにとって大きな前進であり、主要な機能強化とランタイム最適化を導入します。このリリースは、機能の拡張、パフォーマンスの改善、Solanaが実現できる可能性の拡大を通じて、ネットワークを強化します。Secp256r1署名検証のネイティブサポート、ブロック上限の引き上げ、広範なパフォーマンス改善、そして将来的な貪欲スケジューラの導入により、Agave 2.1は効率性とスケーラビリティの両方を向上させます。開発者、バリデータ、アクティブユーザーのいずれであっても、このアップデートは新たな可能性を開き、Solanaをこれまで以上に高速で柔軟かつ強力にします。

関連リソース

• Agaveクライアントリポジトリ
• Agave v2.1リリーススケジュール
• Agave v2.1タグ付きプルリクエスト