Solanaの手数料：理論と実践

はじめに

Solanaの手数料体系は、需要と供給の不均一な変動に対応しながら、ネットワークのパフォーマンスを維持できるよう設計されています。どのブロックチェーンでも、手数料にはスパムを防止し、バリデータにインセンティブを与える役割があります。Solanaでは、これらの手数料の一部がネットワークの状況に応じて動的に調整されるため、その時点の需要をより正確に価格へ反映できます。

Solanaの手数料は注目を集めているトピックです。「ローカル手数料市場」により、Solanaはブロックスペースや特定のアカウントをより正確に価格設定できます。現在の実装は完璧にはほど遠いものの、アカウント単位の順序付けについて緩やかな保証を提供しています。Solanaはまだ初期段階にありますが、ネットワーク内のステークとアクティビティが増えるにつれ、手数料モデルの変更をはじめとするプロトコル内の変更が及ぼす一次的・二次的な影響について、より踏み込んだ議論と分析が必要になります。

本稿では、手数料の理論と、それがオンチェーンでどのように現れるかを解説します。Solanaは中央集権的であり、ステーク加重型のQoSやTurbineの設計には中央集権化を促す力があるという批判もあります。しかし、長年にわたり、それが実際にどのように現れているかとの間には明確な隔たりがあります。同様に本稿でも、オンチェーン上の挙動を通じて手数料がどのように現れるかを包括的に分析します。

手数料の理論

Solanaの手数料システムは、基本手数料と優先手数料の2つの要素で構成されます。大まかに言えば、それぞれの手数料要素は理想的には次の役割を果たします。

• 基本手数料：ネットワークのリソースを利用する権利
• 優先手数料：リーダーのトランザクションキュー内での順序を決定

基本手数料

基本手数料は現在、署名ごとに0.000005 SOL（5,000 lamports）に設定されており、トランザクションコストの基礎となります。これは、ネットワークのリソースを利用する権利を得るために、アドレスが支払う手数料です。トランザクションの実行に実際に使用されたリソース量や、トランザクションが実行されたかどうかに関係なく、ネットワークへ事前に一括で支払われます。Solanaのトランザクションは、指定された数のコンピュートユニット（CU）を事前に要求し、その数を超えると失敗します。そのため現状では、開発者がコンピュートユニットの要求量を最小限に抑える金銭的インセンティブは、ほとんど、あるいはまったくありません。

優先手数料

さらにユーザーは、ブロックに含まれる可能性を高め、トランザクションを迅速に処理するために優先手数料を支払えます。ただし、優先手数料を支払ったユーザーに対する保証は決定論的ではありません。トランザクションの決定性を向上させる取り組みが進められており、1.18ではスケジューラに大幅な変更が加えられる見込みです。

なお、投票トランザクションには優先手数料がなく、通常のトランザクションとは異なる方法で扱われます。

バリデータが優先手数料付きのトランザクションを含めるインセンティブは、ランタイムの外部にあります。リーダーはトランザクションを自身のブロックに含めることで優先手数料の50%を受け取り、残りの50%はバーンされます。

現在、大半のバリデータ（80%以上）は、Solana LabsまたはJito-Solanaクライアントの未改変版を実行しています。つまり、これらのバリデータは「ブロック生成」をデフォルトのスケジューラに委ねています（Solanaでは、「ブロック順序付け」を「ブロック生成」と呼ぶ人もいますが、Ethereumではまったく異なる意味を持ちます）。一部のチームはクライアントコードを変更し、順序付けのフローをより細かく制御できる複雑なスケジューラを実装しています。これにより、トランザクションの並べ替えやサンドイッチによってMEVを抽出できる場合があります。

優先手数料の非決定性

現在のスケジューラ実装では、優先手数料が高いトランザクションが特定のブロックに含まれることは保証されません。その代わり、優先手数料付きのトランザクションが特定のブロックに含まれる可能性が高くなるという緩やかな保証を提供します。現在のスケジューラ実装は、4つの実行コアを使用します（さらに2つのコアが投票トランザクション用に予約されています）。

各スレッドは独自のキューを処理し、他のスレッドが処理しているパケットを把握せずに、それぞれ独立してパケットへ優先順位を付けます。各スレッドは先頭から末尾まで継続的に巡回し、トランザクションのロックと実行を試みます。現在のサイクルが完了すると、さらにパケットを収集し、再びサイクルを開始します。

そのため、あるスレッドのキュー先頭にある優先度の高いトランザクションを処理しているのと同時に、別のスレッドが同じアカウントに関係するトランザクションを処理して、自身のキューを完了しようとしている場合があります。

現在および将来のスケジューラ実装の詳細については、別の記事で取り上げます。優先手数料はスレッド内（同じレーン内）でのみ機能し、スレッド間（異なるレーン間）では機能しないと理解すれば、スケジューラが完璧にはほど遠く、「ジッター」が発生することを理解するには十分です。

手数料の実態

トランザクションの確定

手数料はトランザクションが確定するかどうかを左右する主要な要因ですが、唯一の決定要因ではありません。たとえば、UDPネットワークパケットが失われたというだけで、トランザクションが確定しない場合があります。ネットワークのアクティビティが活発な期間には、バリデータが処理能力を超えるトランザクションを受信する可能性があります。バリデータはtpu_forwardsメカニズムを通じて余分なトランザクションを転送できますが、処理できるデータ量には限りがあり、各トランザクションを中継できる回数も有限です（blockhashが期限切れになるまで）。ステーク加重型のサービス品質は、ステークが多いアドレスに予約済み帯域幅を提供し、トランザクションが含まれる可能性を高めることで、これらの問題の一部を軽減します。

トランザクションが脱落する理由として、あまり議論されていないものがほかにも2つあります。1つ目は、RPCプール内の不一致です。RPCプールの一部がほかより先行すると、連携上の問題が発生する可能性があります。たとえば、トランザクションのrecentBlockhashをより新しい状態のセグメントから取得し、その後、更新が遅いセグメントへ送信した場合、後者が更新済みのblockhashを認識できず、トランザクションを破棄する可能性があります。開発者がsendTransaction関数でプリフライトチェックを有効にしていれば、このような問題を送信時に検出できます。

もう1つの問題は、一時的なネットワークフォークに関連して発生します。バリデータのブロック処理が遅れると、トランザクションが正規チェーンにならない少数派フォークに取り込まれる可能性があります。クライアントが、その少数派フォークにしか存在しないrecentBlockhashをトランザクションで参照し、トランザクションが処理される前にネットワークがそのフォークを放棄すると、blockhashが見つからなくなるため、トランザクションは破棄されます。

優先手数料

実際のデータからは、優先手数料が完璧にはほど遠いものの、マクロな規模では機能していることが分かります。優先手数料を含むトランザクションはブロックに含まれる可能性が高く、より高い優先手数料を設定したトランザクションほど、その可能性も高くなります。

Helius RPCのデータに基づくと、優先手数料付きのトランザクションは確定する可能性が高く、確定する場合も全体的により短時間で処理されることが分かります。

1月21日には、翌週の実際のJUPエアドロップに向けて実施されたmockJUPエアドロップにより、平均優先手数料が急増しました。ブロックスペースの需要は大きく変化しましたが、実際のユーザーが体感するトランザクションの確定率と確定時間には、比較的小さな変化しかありませんでした。

このUXは主に、Solana RPCメソッドのgetRecentPrioritizationFeesによって支えられており、開発者はトランザクションに追加する優先手数料を正確に決定できます。このエンドポイントは、各アドレスと入力パラメータで少なくとも1件のトランザクションを正常に確定させるために使用された、直近150ブロックの優先手数料一覧を返します。これにより、優先手数料として設定すべき最低値のスナップショットを取得できますが、その有用性は比較的限定的です。代わりにHeliusは、追加の計算を行ってより適切な優先手数料の推定値を提供するPriority Fee APIを提供しています。

優先手数料は理論上、ある程度は意図どおりに機能していますが、1.18で予定されているスケジューラの改善により、トランザクションが含まれるかどうかの決定性が高まります。トランザクションを含めるための支配的戦略としてチェーンへのスパム送信が不要になるため、オンチェーンに到達するスパム量は減少するはずです。

基本手数料

Solanaの基本手数料は明らかに低すぎます。ブロックが飽和しているにもかかわらず手数料が動的ではないため、基本手数料をブロックスペースの需給均衡価格まで引き上げられません。Ethereumでは、EIP-1559の制御メカニズムによって動的な基本手数料を実現しています。このメカニズムは直近のブロックを参照し、使用率50%を目標に設定します。

Solanaでは、署名ごとに5,000 lamportsという固定価格が設定されています（通常、トランザクションごとに1署名です）。基本手数料にはブロックスペースの需要やバリデータのリソース使用量の変化が一切反映されないため、手数料として効果的ではありません。これにより、実質的に優先手数料が市場ベースの代替手段として外部化され、バリデータがブロックに含まれる見込みの低い追加トランザクションまで処理するため、ネットワークの混雑がさらに悪化します。さらに、最小限の優先手数料を設定した大量のトランザクションを送信することが支配的戦略となっています。これは、すべてのネットワーク参加者のUXに大きな外部不経済をもたらします。

インセンティブ

RPCには、最小限のコストで最高のトランザクション収録率を実現するために、正確な情報を下流へ中継するインセンティブがあります。Solanaの多くのメカニズムはステーク加重型であるため、ステーク量が上位のバリデータと統合することで、RPCはネットワークの現在の状態をより正確に把握できます。多額のステークを持つバリデータと統合されたRPCがトランザクション処理の効率性と信頼性を高めるという共生関係が生まれ、ステーク量が上位のバリデータの地位をさらに強固にするフィードバックループが形成される可能性があります。

さらに、現在はステークがゼロのバリデータとして扱われているRPCも、ステーク加重の対象になります。RPCは、バリデータと提携せずに自らステークを集めることもできます。垂直統合を進めるために、アプリケーションが独自のバリデータを運用することも珍しくありません。これにより、エンドユーザー体験とトランザクション／MEVサプライチェーンをより細かく制御できます。

経済的インセンティブはステークの中央集権化へ向かう傾向を示唆していますが、Solanaではステーク加重による利益を目的とした大規模な資本集積は見られていません。これには、次のような複数の理由が考えられます。

• 個人は、主にSolanaの文化とソーシャルレイヤーの影響から、各自が分散化を最大限に高めることが、ネットワークの長期的な利益につながる支配的戦略だと考えている可能性があります。
• Solanaの参加者の多くは個人ユーザーやプロシューマーであり、専門企業ほどリターンに敏感ではありません。アクティビティの水準と絶対的なリターンが増加すれば、参加者層やリターンへの感応度が変化する可能性があります。
• 個人は、差別化された自らのプロダクトを売り込むうえで、十分に連携できていません。

まとめ

本稿では、Solanaの手数料メカニズムに関する大枠の理論と、それがオンチェーンのネットワークに与える影響を詳しく説明しました。手数料はインセンティブを生み出し、それが大きな外部性となってSolanaの全参加者の行動に影響します。

Solanaの基本手数料や優先手数料といったメカニズムは、現在の実装では完璧ではありません。基本手数料は調整できず、現在の需要と供給の均衡を反映していません。その結果、ネットワークの混雑や非効率なリソース配分といった問題が発生します。優先手数料には、現在のスケジューラ実装に起因する一定の非決定性があります。予定されているスケジューラ変更など、今後のアップデートによってトランザクション処理の決定性と効率性が高まり、現在見られるオンチェーン上の挙動が変わる可能性があります。

アカウントへのアクセスを任意にロックすることでトランザクションコストをより正確に価格設定することを目指す、書き込みロックされたアカウントへの指数関数的な手数料などの新たな提案も登場しています。状態へのアクセスをより正確に価格設定する、動的な基本手数料メカニズムについても議論が進められています。

手数料、バリデータ、RPCの相互作用は、複雑なインセンティブの網を形成しています。理論上、バリデータとRPCには統合してステーク加重を高めるインセンティブがあり、中央集権化への懸念につながる可能性があります。しかし実際には、Solanaは分散化されたオペレーターとステークを維持できています。これは、コミュニティ主導のガバナンス、技術的障壁、経済的な対抗インセンティブ、そして現在の最適化関数が主にリターンによって決まるものではないことが理由だと考えられます。