ソラーナのローカル・コスト・マーケットの真実

実行可能な洞察

• ローカル手数料市場（LFM）により、Solanaは競争のレベルに基づいて個々の状態にきめ細かい手数料を設定することができます。トランザクションは、書き込んだ特定の状態に基づいて手数料を支払い、ローカルなホットスポットがブロックチェーン全体で手数料を引き上げるのを防ぎます。

• LFMは、すべてのアプリがシームレスに共存するスケーラブルで統一されたベースレイヤーというSolanaのビジョンを実現するために不可欠です。LFMがなければ、チェーンの一部で手数料が急増すると、すべてのトランザクションの手数料が上昇することになります。これは、ブロックスペースの価格設定をグローバルな手数料市場のみに依存している他のネットワークに共通する問題です。

• 2023年末にソラナの経済活動が加速すると、LFMの当初の実装におけるいくつかの重要な欠陥が明らかになります。最も顕著なのは、非決定的なスケジューラーの優先順位である。トランザクションは主にブロックビルダーに到着した時間に基づいて順序付けされ、優先順位コストは二次的な考慮事項に過ぎません。

• 2024年5月のAgaveクライアントアップデートv1.18では、新しいトランザクションスケジューラと改善されたトランザクション優先順位式が導入されました。スケジューラは、スレッド間で競合するトランザクションの処理と優先順位付けをより良く管理するために依存関係グラフを構築します。このメジャーアップデートにより、決定論的な方法でトランザクションを順序付けるプロトコルの能力が大幅に改善されました。

• 効果的に実行されているLFMを評価するための1つの価値ある指標は、中央値と平均トランザクション優先順位のコストを比較することです。争いのないステータスに関わるコスト（50％パーセンタイルの中央値）は低いままであると予想されます。係争中のステータスに関するコストは、需要が増加するにつれて急増し、平均コストを押し上げるはずである。最近のデータもこのパターンを裏付けている。2024年11月、議決権のない取引の平均手数料は0.0003SOLを超え、過去最高を記録した。しかし、手数料の中央値は0.00000861 SOLにとどまり、約35倍も低かった。

• 今日、SolanaのLFMは機能していますが、まだ大きな改善の余地があります。AnzaのエンジニアがBank Stage Threadingのワークロードを分析した結果、スケジューラーのバグがValidator Clientの能力をフルに活用することを妨げていることがわかりました。その結果、Agave クライアントはその潜在能力のほんの一部でしか動作していません。さらに、トランザクションがどのようにシーケンスされるべきかについての正式な仕様はありません。

• 現在の優先料金APIは、決定論的な結果を提供するために必要な洗練さに欠けています。各主要RPCプロバイダーは独自のカスタム優先料金APIを提供しており、ソフト・ベンダー・ロックインにつながる可能性があります。コアなオープンソースRPC APIの実装は、Jitoのような主要なネットワークダイナミクスの影響を考慮していないため、不正確なコスト見積もりとなります。

• 優先料金を計算する決定論的な方法がないため、開発者はトランザクションが確実に処理されるように過剰に支払うという慎重なアプローチを取ることがよくあります。あるいは、ブロックの先頭を確保する必要のないトランザクションであっても、代替メカニズムとしてJitoのティッピングフィーを使って過剰に支払うこともあります。

• ソラナの手数料構造をさらに強化するために、さまざまな戦略が提案されています。指数関数的な書き込みロック料金や動的な基本料金などです。ネットワークは、本当のユーザーのために料金を低く保ちながら、スパムを抑制するための経済的な対抗圧力を適用する方法をまだ見つけられていません。

はじめに

手数料市場は、トランザクション手数料を動的に調整することで、希少なブロックスペースを最も価値の高いトランザクションに効率的に割り当てるように設計された経済メカニズムです。LFMはこの一般的な概念を改良し、ステートの競争の度合いに基づいて個々のステートにきめ細かい手数料を設定する。2つのトランザクションが同じステートにアクセスする場合（2つの書き込み操作、または同じアカウントへの読み取り/書き込み操作のいずれか）、それらは競合しているとみなされます。

LFMでは、トランザクションは書き込み先の特定の状態に基づいて手数料を支払うため、局所的なホットスポットがブロックチェーン全体で手数料を引き上げるのを防ぐことができます。需要の高いステートや争いのあるステートにアクセスするトランザクションは高い手数料を支払い、需要の低いステートとやり取りするトランザクションは低い手数料を支払う。Solanaは並列実行をサポートしているため、争いのないトランザクションの処理でより優れたパフォーマンスを発揮するため、これは重要である。

これとは対照的に、グローバル手数料市場は、ネットワーク状態にアクセスするための普遍的なコストを課しており、つまり、すべてのトランザクションは、それらが相互作用するアカウントに関係なく、ブロックに含めるために等しく競合します。EIP-1559で実装されているEtherの手数料モデルは、グローバル手数料市場の関連する例です。計算（ガス）使用量を最適に維持する。ブロック容量がいっぱいになると、すべてのトランザクションの手数料が増加する。ウォレットは現在の基本手数料とトランザクションのガス制限に基づいて手数料を計算する。このアプローチはプロトコルで強制され、予測可能な手数料計算を提供するが、需要の高いホットスポットをより広いネットワークから分離することはできない。手数料が高騰すると、すべてのトランザクションの手数料が高騰する。

州特有の需要が高いという問題は、ブロックチェーン特有のものではない。この課題は、Web2ソーシャルアプリケーションでよく見られる「有名人問題」とも呼ばれる「ホットキー問題」に似ています。

本稿では、Solana LFMの利用しやすい分析を提供することを目指す。

• Solana料金の基本：Solanaの現在のトランザクション処理に関する読者の基本的な理解を構築します。

• ローカル・フィー市場の初期の問題：LFMの初期の実装における初期の問題とその落とし穴を探ります。

• Central Scheduler v.1.18 Update:LFMの機能を大幅に改善する2024年のメジャーアップデートを紹介します。

• Measuring the Effectiveness of Local Fee Markets:Solana上で動作するLFMの状態を理解するための関連データを提供します。

• Continuing Issues and Areas for Improvement:このセクションでは、LFMが潜在能力を最大限に発揮するために、未解決の問題や注意を払う必要がある分野について説明します。

• 提案されている解決策：LFMを改良し、よりきめ細かいブロックスペースの価格設定のためのより良い経済的インセンティブを導入するための、提案されている解決策のレビューです。

すでにSolanaのトランザクション手数料体系に慣れている読者は、手数料の基本に関する以下のセクションを読み飛ばすことをお勧めします。

ソラナ手数料の基本

Solana トランザクションは、基本手数料と優先手数料の2つの手数料で構成されています。基本手数料は現在、署名1件につき5,000ランポートで固定されており、ほとんどのソラナ取引では署名は1件のみである。優先手数料はマイクロランポート（つまりランポートの100万分の1）で計算され、要求された計算単位（CU）で計算される。手数料は、手数料支払者（署名者）の口座から差し引かれる。支払者のランポートが取引手数料を賄うのに不足する場合、取引は破棄される。本稿執筆時点では、基本手数料と優先手数料の50％が、取引をブロックに含めるインセンティブとしてブロック構築者に保持される。残りの50％は破棄される。昨年5月のガバナンス投票の成功を受けて、SIMD-096案は、優先手数料の100%をブロック・ビルダーが保持するように変更する。の100％をブロック建設者が保持することに変更される。例えば:

ある取引に署名があり、500,000 CUを要求した場合、送信者は要求されたCUごとに50,000マイクロランプの優先手数料を設定する。

ベリファイアの計算資源は有限であり、プロトコルは1ブロックあたりの計算資源を4800万CUに制限している。この数値は、ブロック時間400ミリ秒を達成するために検証者が合理的に処理できる量に基づいて経験的に選択された。トランザクションメッセージの最大サイズも1,232バイトに制限されている。これはIPv6の最小伝送単位(1,280バイト)からヘッダーを除いたサイズである。

計算リソースの悪用を防ぐため、Solanaは各トランザクションに計算バジェットを割り当てる。デフォルトでは、ネットワークは命令ごとに200,000コンピュートユニット（CU）の上限を設定します。しかし、トランザクションは、より効率的なリソース割り当てのために、SetComputeUnitLimit ディレクティブを含めることによって、コンピュートユニットのカスタム上限を指定することができます。Agaveクライアントのコードベースは、様々な操作のCUコストをリストしています。

Solanaでは、すべてのトランザクションで、トランザクション中に読み書きされる口座アドレスの完全なリストを指定する必要があります。このリストの最大サイズは35アドレスで、chained address lookup tableを介してアクセスできる。アドレスリストの構築は開発者に追加のオーバーヘッドをもたらしますが、並列トランザクションの実行やローカライズされた費用市場など、Solanaの最適化の多くを解除する鍵になります。

Solanaのローカライズされた支出市場に関する初期の問題

「ローカライズされた支出市場は嘘です。

2023年末、ソラナでの経済活動が加速するにつれ、当初のLFMの実装におけるいくつかの重要な欠陥が明らかになってきました。この時点で、Ellipsis LabsのEugene Chen氏は、Umbra Researchの記事で、これらの課題について包括的な分析を行っている。ソラナ料金、パート1。以下は、チェンが指摘した重要なポイントの要約である。

正確にCUを要求するインセンティブがない

ソラーナの料金体系は、使用または要求された計算ユニット（CU）に関係なく、署名に基づく基本料金を請求する。同時に、優先手数料は、混雑時にCUの使用を減らす限定的なインセンティブしか提供しない。この設計は、トランザクションの送信者に、計算機使用を最適化したり、CU要求を実際の需要に合わせたりするインセンティブをほとんど与えない。その結果、トランザクションはしばしばCUを過剰に要求し、ネットワークのスケジューリングプロセスにおける非効率を招く。

プロトコル外の優先メカニズムを使用する動機付け

50%の優先手数料を燃やすことは、トランザクション送信者が優先アクセスを得るために、ブロックビルダーと結託し、チェーン外の支払いを手配することによって、プロトコルをバイパスする動機付けとなります。このような行動は、増加するJitoオークションに顕著である。Jito-Agaveクライアントを実行している検証者は、より高い手数料収入から利益を得ており、Jito MEV手数料報酬を通じて、これらの利益を委任された誓約者に効果的に分配することができます。Jito-Agaveクライアントの採用が増えるにつれて、Jitoスイートは多くのシナリオにおいて優れたトランザクションデリバリーサービスであることが証明されつつあります。

非決定論的なスケジューラーの優先順位付け

Solanaのコンセンサスもスケジューラーも、優先コストに基づくトランザクションの厳密な順序付けを強制しません。トランザクションは主にブロックビルダーに到達する時間によってソートされ、優先コストは二次的な検討事項としてのみ考慮される。優先度コストが高いほど係争状態に含まれる可能性が高まるが、ソートプロセスは依然として非決定論的である。トランザクション処理ユニット（TPU）に到達するまでのネットワーク・ジッターと、スケジューラ内のジッターが、予測不可能性をさらに高めている。

このような決定性の欠如は、トランザクション実行の予測可能性と信頼性を低下させ、ユーザがより高速に取り込まれる可能性を高めるために、トランザクションスパムをネットワークに氾濫させることを促します。しかし、ある閾値を超えると優先順位の高い手数料の見返りが逓減するため、より良い取引を行うためのメカニズムとしての有効性が低下し、Solanaの共有ブロック空間は最終的に古典的な「コモンズの悲劇」の犠牲となる。私利私欲に突き動かされた個々の行為者が、この公共資源の過剰利用と非効率を招いたのである。

Central Scheduler v1.18アップデート

Agaveのクライアント側スケジューラの初期実装は、優先順位の高い手数料を持つトランザクションが、与えられたブロックに含まれる可能性が高くなるという緩やかな保証しか提供しませんでした。リーダーのトランザクション処理ユニット（TPU）は6つの並列スレッドを使用して実行される。各非投票トランザクションスレッドは、保留中のトランザクションが実行のためにグループ化されるのを待つ独自のキューを維持する。以前は、トランザクションはこれらのスレッドにランダムに割り当てられ、キューは他のスレッドによって処理されたパケットに関係なく、独立してパケットに優先順位をつけていました。

このシステムでは、各スレッドがキューをループし、トランザクションをロックして実行しようとしている。スレッドが現在のループを完了すると、追加のパケットを収集し、プロセスを再起動します。この構造は、優先順位の高いコストを効率的に使用するための課題を生み出す。例えば、優先順位の高いトランザクションがあるスレッドのキューの先頭にある一方で、別のスレッドがキューの末尾にある同じアカウントを含む優先順位の低い手数料トランザクションを同時に処理しているかもしれない。優先手数料は、1つのスレッド内（スレッド内）でのみトランザクションの順序付けに影響し、すべてのスレッド間（スレッド間）では影響しません。したがって、各キューは、先入れ先出し（FIFO）処理と優先順位のコスト考慮とを組み合わせたハイブリッド・ソート機構を適用する。しかしながら、スレッド間でグローバルなソートは強制されません。

スレッドがトランザクションを実行する準備ができたら、まず必要なアカウントロックを獲得しなければならない。必要な書き込みロックが利用できない場合、トランザクションは再キューされます。この問題は、スレッドへのトランザクションのランダムな割り当てによって悪化する。なぜなら、マルチスレッドスケジューリングシステムでは、同じトランザクションタイプが異なる位置にある可能性があるからである。このスケジューラーのランダム性はジッターを導入し、トランザクションがブロック内のどこに配置されるかのばらつきを引き起こす。

2024年5月のAgaveクライアントアップデートv1.18で、新しいトランザクションスケジューラであるセントラルスケジューラが導入されました。この改訂された構造では、中央スケジューラは、すべてのスレッド間で競合するトランザクションの処理と優先順位付けをよりよく管理するために、プライオリティグラフと呼ばれる依存関係グラフを構築します。このメジャーアップデートにより、トランザクションを決定論的に順序付けるSolanaの能力が大幅に改善され、より高い優先順位のコストを持つトランザクションがブロックに含まれる可能性が高くなった。

優先順位グラフは有向無サイクルグラフ（DAG）で、新しい取引が追加されると動的に更新されます。取引はグラフ内で時間優先順に処理される実行チェーンに編成される。競合するトランザクションについては、優先度コストが挿入順序を決定する。このアプローチはロックの競合を最小化し、トランザクションバッチをスムーズに実行できるようにし、リソースの競合による遅延を減らす。トランザクションのコンパイル前検証はワーカースレッドにオフロードされ、パフォーマンスを向上させ、より効率的な処理を可能にする。

更新されたスケジューラー設計は、スケーラビリティと柔軟性を大幅に強化し、ロックの競合のリスクを増大させることなく、スレッド数の潜在的な増加を可能にします。さらに、集中型スケジューリングのアプローチにより、報酬の発生が改善され、多くのバリデータ運営者の収益が増加します。

集中スケジューラーの詳細については、以前のAgave1.18に関するHeliusブログの投稿を参照してください。アップデートをご覧ください。

より効率的な優先度計算

スケジューラーの更新に伴い、トランザクションの優先度計算式が改良され、計算要件の低いトランザクションが有利になるようになりました。

{
  "jsonrpc":  "2.0",
  "id":  "helius-example",
  "method": "getPriorityFeeEstimate", 
  "params": [
   {
        "LxzhDW7T...", // Base58 エンコードされたシリアル化トランザクション
             。align: left;">上図: Base58エンコードされたシリアル化トランザクションを使用したgetPriorityFeeEstimateのロード例。
優先料金を計算する決定論的な方法がないため、開発者はトランザクションが確実に処理されるように過剰に支払うことで、慎重なアプローチを取ることがよくあります。あるいは、ブロックの先頭を確保する必要のないトランザクションであっても、Jitoのチップで過剰に支払うこともある。これらのチップは優先手数料の代わりとして使われることが多い。2024で観察されるチップのほとんどは、アービトラージやピン留めといった伝統的なMEVの活動とは関係なく、むしろトランザクションの迅速な組み入れを可能にするために設計されていることは注目に値する。バリデータはより高いブロック報酬とMEV手数料を請求することで、この非効率性から利益を得ています。
別の課題は、開発者がチェーン上の状況の変動に応じて優先手数料を動的に調整するロジックを実装していない場合に生じます。大きなイベント（市場の大幅な変動など）が発生すると、特定のステートアカウントにアクセスするための手数料が劇的に跳ね上がることがあります。動的な手数料メカニズムを持たないアプリケーションは、静的な手数料設定がタイムリーな実行を保証するのに十分でないため、このような状況で困難に直面することになります。
解決策の提案
Solanaの手数料構造をさらに強化するために、さまざまな戦略が提案されています。これらの提案は、ネットワークのリソース割り当てを最適化し、スパムのインセンティブを緩和することを目的としています。
Exponential Write-Lock Fees
SIMD-0110は、係争中のアカウントに動的な手数料を課すことで、輻輳を管理する新しいメカニズムを提案している。このメカニズムは、書き込みロックされたアカウントの計算ユニット(CU)利用率の指数移動平均(EMA)を追跡し、利用率が常に高い書き込みロックされたアカウントの料金を引き上げます。
このようなシステムを実装するために、Solanaランタイムは、係争中のアカウントの公開鍵のLRU（Least Recently Used）キャッシュと、それに対応するCUP（Compute Unit Pricer）を維持する。
このメカニズムは、書き込みロック料金を動的に調整します。アカウントのEMA CU利用率が目標しきい値を超えた場合、書き込みロック費用率は増加します。逆に、利用率が目標値を下回ると、費用率は減少します。
目標利用率は、口座の最大CU限度額の25%です。
1CUあたり1,000マイクロラポートの初期書き込みロックコスト率。
コスト調整率はブロックごとに1%です。
アカウント書き込みロック手数料は、手数料率にトランザクション要求のCUを乗じて計算されます。このシステムでは、トランザクション手数料の合計は、基本署名手数料、優先手数料、書き込みロック手数料の3つの要素の合計となる。書き込みロック料は100％破棄される。
リリース当時、SIMD-0110はコミュニティ内で多くの議論を巻き起こしました。しかし、この提案は現在非アクティブで、クローズとマークされています。
Dynamic Base Fee
Solana の LFM を改善するもう 1 つの長期的なソリューションは、グローバルおよびアカウントごとの Dynamic Base Fee (DBF) の導入です。Ellipsis LabsのJarry Xiao氏とEugene Chen氏は、このアプローチの有名な支持者です。
優先料金はオプションですが、基本料金は必須です。現在、Solanaの基本料金は署名1件につき5,000ラビッツで固定されている。単純なトークン譲渡を提出するユーザーは、複雑なマルチプレース交換を行うサーチャーや複雑なMEV裁定取引を実行しようとするサーチャーと同じ基本手数料を支払う。基本手数料はトランザクションの計算された使用量を正確に反映していません。
動的な基本手数料では、基本手数料が不適切な裁定取引は無効として扱われ、ディスパッチャに到達する前に破棄される可能性があります。基本手数料を上げることは、スパマーがより少ないトランザクションを送信することを促します。
ベースフィーは最終的に均衡に達し、トランザクションはブロックスペース市場の価値に従って価格が決定される。基本手数料が上昇するにつれ、最終的には限界費用に達し、その時点で取引を送信することはもはや取引の機会費用に見合わなくなります。手数料は高すぎてはならない。そうでなければ、ユーザーの活動は低下する。ロボットにとっては高すぎるが、ユーザーにとっては一般的に受け入れられる上限値が理想的である。
Solanaの高速ブロックタイムにより、積極的なアルゴリズムが基本手数料を設定できる。需要の高い時期には、手数料はネットワークの混雑を反映するために迅速に調整され、ブロックごとに倍増する可能性があります。逆に、需要が減少するにつれて、手数料はより緩やかに減少させることができます。ソラーナのブロックタイムは短いため、手数料は比較的迅速に削減され、ネットワークが状況の変化に迅速に適応することを保証します。
同様の経済的逆ストレスの例として、メタプレックス・キャンディーズ・プログラムがある。マシン・プログラムで、2022年にスパム対策としてボット税を導入した。ボット税とは、無効な取引に対する任意の課金である。通常、これは本物のミスを犯したかもしれない本物のユーザーへの影響を避けるため、比較的少額になる。この税金は効果的であることが証明された。キャスティングスナイパーはすぐに枯渇し、スパムは止まった。
結論
SolanaのLFMは機能的ですが、まだ改善の余地がたくさんあります:
優先料金メカニズムの強化：優先料金RPC呼び出しには改善が必要です。理想的には、開発者は、トランザクションが次の数ブロック内に含まれることを確実にするために、手数料を設定するシンプルで決定論的な方法を持つべきです。
スパムに対する経済的な阻害要因：ネットワークは、経済活動が活発な期間中にボットに経済的な対抗圧力をかける方法を見つけなければなりません。
開発者を教育する：開発者は、アプリの取引手数料を固定的に設定するのをやめ、通常の取引のためにJitoのようなプロトコル外のメカニズムへの依存を減らす必要があります。
スケジューラーをさらに最適化する:トランザクションのスケジューラーは、需要が高い期間にすべてのワーカースレッドが利用されるように、さらに最適化する必要があります。
Solanaの共同設立者であるAnatoly Yakovenko氏が指摘するように、これらの課題は主に「エンジニアリングの問題」であり、適切な技術的注意を払えば解決できるものです。-適切な技術的注意を払えば解決できる。
その他のリソース
Solana Fees, Part 1 - アンブラリサーチ
Toward Multidimensional Solana Fees - アンブラリサーチ
ローカルフィーMarket are Necessary to Scale Ethereum - Eclipse Labs
Solana's Local Fee Markets Aren't Real｜Eugene Chen - Lightspeed Podcast
Solanaのローカルフィー市場は実在しない。ソラーナ・バンキング・ステージとスケジューラー - A.Fitzgerald