Solanaのローカル手数料市場の真実

実践的な知見

• ローカル手数料市場（LFM）により、Solanaは競合の度合いに応じて個々の状態にきめ細かな手数料を設定できます。トランザクションは書き込み先の状態に基づいて手数料を支払うため、局所的なホットスポットによってブロックチェーン全体の手数料が上昇するのを防げます。 
• LFMは、すべてのアプリケーションがシームレスに共存できる、スケーラブルで統合されたベースレイヤーというSolanaのビジョンを実現するうえで不可欠です。LFMがなければ、チェーンの一部で発生した手数料の急騰がすべてのトランザクションの手数料を押し上げます。これは、ブロックスペースの価格設定をグローバル手数料市場のみに依存する他のネットワークでよく見られる問題です。
• 2023年後半にSolana上の経済活動が加速し始めると、LFMの初期実装にある複数の重大な欠陥が明らかになりました。特に顕著だったのは、スケジューラによる優先順位付けが非決定的だったことです。トランザクションは主にブロックビルダーへの到着時刻で並べられ、優先手数料は二次的な要素にすぎませんでした。
• 2024年5月のAgaveクライアントv1.18アップデートでは、新しいトランザクションスケジューラと改良されたトランザクション優先度の計算式が導入されました。スケジューラは依存関係グラフを構築し、スレッド間で競合するトランザクションの処理と優先順位付けを改善します。この大規模アップデートにより、プロトコルがトランザクションを決定論的に順序付ける能力が大幅に向上しました。
• LFMが効果的に機能しているかを評価する有用な指標は、トランザクション優先手数料の中央値と平均値の比較です。競合していない状態に関わる手数料（50パーセンタイルの中央値）は低く維持されると予想されます。一方、競合する状態の手数料は、需要の増加に伴って急騰し、平均値を押し上げるはずです。最近のデータはこの傾向を裏付けています。2024年11月、非投票トランザクションの平均手数料は過去最高の0.0003 SOL超に達しました。しかし、手数料の中央値は0.00000861 SOLで安定しており、約35分の1でした。
• 現在、SolanaのLFMは機能していますが、改善の余地は大きく残っています。Anzaのエンジニアが実施したバンキングステージのスレッド負荷分析によると、スケジューラのバグにより、バリデータクライアントが能力を最大限に活用できていません。その結果、Agaveクライアントは潜在能力の一部しか発揮できていません。さらに、トランザクションの順序付けに関する正式な仕様もありません。
• 現在の優先手数料APIは、開発者に決定論的な結果を提供するために必要な高度さを欠いています。主要なRPCプロバイダーはそれぞれ独自の優先手数料APIを提供しており、緩やかなベンダーロックインにつながる可能性があります。中核となるオープンソースのRPC API実装は、Jitoの影響など重要なネットワーク動態を考慮しておらず、不正確な手数料推定につながっています。
• 優先手数料を決定論的に算出する方法がないため、開発者はトランザクションの処理を保証するために、過剰に支払うという慎重な対応を取りがちです。また、ブロック先頭の確保が不要なトランザクションであっても、代替手段としてJitoチップを過剰に使用する場合があります。
• Solanaの手数料構造をさらに改善するため、さまざまな戦略が提案されています。指数関数的な書き込みロック手数料や動的基本手数料などです。正当な人間のユーザーには低い手数料を維持しつつ、スパムを抑止する経済的なバックプレッシャーをかける方法は、まだ確立されていません。

はじめに

手数料市場は、トランザクション手数料を動的に調整することで、希少なブロックスペースを最も価値の高いトランザクションへ効率的に割り当てる経済的メカニズムです。トランザクションが支払ってもよいと考える手数料を、その価値の代理指標とします。LFMはこの一般的な概念を発展させ、競合の度合いに応じて個々の状態にきめ細かな手数料を設定します。同じ状態にアクセスする2つのトランザクション、つまり同じアカウントへの2つの書き込み、または読み取りと書き込みは競合していると見なされます。

LFMでは、トランザクションは書き込み先の状態に基づいて手数料を支払うため、局所的なホットスポットがブロックチェーン全体の手数料を押し上げることを防げます。需要が高い、または競合している状態にアクセスするトランザクションには高い手数料がかかり、需要の低い状態を扱うトランザクションの手数料は低くなります。Solanaは並列実行により、競合しないトランザクションを効率的に処理できるため、これは重要です。

対照的に、グローバル手数料市場ではネットワーク状態へのアクセスに一律のコストを適用します。つまり、アクセスするアカウントに関係なく、すべてのトランザクションが同じ条件で取り込みを競います。EIP-1559で実装されたEthereumの手数料モデルは、グローバル手数料市場の代表例です。EIP-1559はネットワーク需要に応じて動的基本手数料を調整し、ブロックごとの最適な計算資源（ガス）使用量を維持します。ブロック容量が埋まるにつれて、すべてのトランザクションの手数料が上昇します。ウォレットは、現在の基本手数料とトランザクションのガス上限に基づいて手数料を計算します。この方式はプロトコルで強制され、予測可能な手数料計算を提供しますが、需要の高いホットスポットをネットワーク全体から分離できません。手数料が急騰すると、すべてのトランザクションに影響します。

特定の状態に需要が集中する問題は、ブロックチェーンに限られません。この課題は、Web2のソーシャルアプリケーションで一般的に見られるホットスポットキー問題、いわゆる「セレブリティ問題」に似ています。

本稿では、SolanaのLFMについてわかりやすく分析します。内容は次のセクションで構成されています。

• Solanaの手数料の基礎: 現在のSolanaでトランザクションがどのように処理されるかについて、基本的な理解を提供します。
• 初期のローカル手数料市場の問題: LFMの初期実装における問題と欠点を検証します。
• 中央スケジューラv1.18アップデート: LFMの機能を大幅に改善した、2024年の重要なアップデートを紹介します。
• ローカル手数料市場の有効性の測定: 現在のSolanaで稼働するLFMの状況を理解するために役立つデータを示します。
• 継続中の問題と改善領域: LFMが潜在能力を最大限に発揮するために解決すべき問題と、対応が必要な領域を説明します。
• 提案されている解決策: LFMを改良し、より精緻なブロックスペース価格設定に向けて優れた経済的インセンティブを導入するための提案を検討します。

Solanaのトランザクション手数料構造にすでに詳しい方は、次の手数料の基礎に関するセクションを読み飛ばしても構いません。

Solanaの手数料の基礎

Solanaのトランザクションには、基本手数料と優先手数料の2種類があります。基本手数料は現在、署名ごとに5,000 lamportsで固定されています。ほとんどのSolanaトランザクションには署名が1つあります。優先手数料は、要求された計算ユニット（CU）ごとにmicrolamports（lamportの100万分の1）単位で設定されます。手数料は、手数料支払者のアカウント（署名者）から引き落とされます。支払者がトランザクションの支払いに必要なlamportsを保有していない場合、そのトランザクションは破棄されます。執筆時点では、基本手数料と優先手数料の各50%が、トランザクションをブロックに取り込むインセンティブとしてブロックビルダーに支払われます。残りの50%はバーンされます。昨年5月に提案SIMD-096がガバナンス投票で可決されたことを受け、今後は優先手数料の100%をブロックビルダーが受け取るようになります。例を示します。 

あるトランザクションに1つの署名があり、500,000 CUを要求するとします。送信者は、要求CUごとに50,000 microlamportsの優先手数料を設定します。トランザクションの合計手数料は、5,000 lamports +（要求された500,000 CU * 要求CUあたり50,000 microlamports）= 25,000 lamports、つまり0.000025 SOLです。

バリデータの計算資源には限りがあり、プロトコルはブロックあたりの総計算資源を4,800万CUに制限しています。この値は、400ミリ秒のブロック時間を実現するためにバリデータが合理的に処理できる量に基づき、実証的に決められました。アカウントごとのブロックあたり最大CUは1,200万に制限され、トランザクションあたりの最大計算量は140万CUに設定されています。また、トランザクションメッセージの最大サイズは1,232バイトです。これはIPv6の最小伝送単位（1280バイト）からヘッダーを差し引いた値です。

計算資源の不正利用を防ぐため、Solana上の各トランザクションには計算予算が割り当てられます。デフォルトでは、ネットワークは命令ごとに最大200,000計算ユニット（CU）を設定します。ただし、トランザクションは`SetComputeUnitLimit`命令を含めることで独自の計算ユニット上限を指定でき、より効率的に資源を割り当てられます。Agaveクライアントのコードベースには、各種操作のCUコストが記載されています。

Solanaでは、すべてのトランザクションで、処理中に読み取りまたは書き込みを行うアカウントアドレスの完全なリストを指定する必要があります。このリストの最大サイズは35アドレスですが、オンチェーンのAddress Lookup Tablesを使用して拡張できます。アドレスリストの構築は開発者に追加の負担をもたらしますが、トランザクションの並列実行やローカル手数料市場など、Solanaの多くの最適化を実現する鍵となります。

Solanaのローカル手数料市場における初期の問題

2023年後半にSolana上の経済活動が加速し始めると、LFMの初期実装にある複数の重大な欠陥が明らかになりました。この頃、Ellipsis LabsのEugene Chen氏は、Umbra Researchの記事「Solana Fees, Part 1」で、これらの課題を包括的に分析しました。以下は、Chen氏が指摘した要点のまとめです。

CUを正確に要求するインセンティブの欠如

Solanaの手数料構造では、使用または要求された計算ユニット（CU）を考慮せず、署名ごとに基本手数料を課します。一方、混雑時にCU使用量を減らすための優先手数料によるインセンティブは限定的です。この設計では、トランザクション送信者が計算量を最適化したり、CU要求量を実際の需要に合わせたりする動機がほとんどありません。その結果、トランザクションは頻繁に過剰なCUを要求し、ネットワークのスケジューリング処理に非効率が生じます。

プロトコル外の優先メカニズムを使用するインセンティブ

優先手数料の50%をバーンすると、トランザクション送信者がブロックビルダーと結託し、優先アクセスのためのオフチェーン支払いを手配してプロトコルを回避する動機が生まれます。この動きはJitoオークションの利用拡大に表れています。Jito-Agaveクライアントを実行するバリデータは、手数料収益の増加という恩恵を受け、Jito MEVコミッション報酬を通じて委任ステーカーに利益を効率的に分配できます。Jito-Agaveクライアントの普及に伴い、多くの状況でJitoバンドルが優れたトランザクション配信サービスであることが実証されています。 

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

Solanaのコンセンサスもスケジューラも、優先手数料に基づく厳密なトランザクション順序を強制していません。トランザクションは主にブロックビルダーへの到着時刻で並べられ、優先手数料は二次的な要素にすぎません。優先手数料を高くすると、競合する状態を含むトランザクションが取り込まれる可能性は高まりますが、順序付けは依然として非決定的です。トランザクション処理ユニット（TPU）へ到達する前のネットワークジッターと、スケジューラ内部のジッターにより、予測不能性がさらに高まります。

この決定性の欠如は、トランザクション実行の予測可能性と信頼性を低下させます。そのためユーザーは、より早く取り込まれる可能性を高めるため、トランザクションスパムをネットワークへ大量に送信します。しかし、優先手数料を引き上げても、一定のしきい値を超えると効果が逓減し、より良いトランザクション配置を実現する仕組みとしての有効性が損なわれます。Solanaの共有ブロックスペースは、最終的に典型的な「コモンズの悲劇」に陥りました。各主体が自己利益を追求した結果、この公共資源の過剰利用と非効率化を招いています。

中央スケジューラv1.18アップデート

Agaveクライアントの初期スケジューラ実装では、高い優先手数料を設定したトランザクションが特定のブロックに取り込まれやすくなるという緩い保証しかありませんでした。リーダーのTransaction Processing Unit（TPU）は6つの並列スレッドで動作します。4つが非投票トランザクションを処理し、2つが投票トランザクション用に確保されています。4つの非投票トランザクションスレッドはそれぞれ独自のキューを持ち、受信トランザクションは実行用エントリにまとめられるまでそこで待機します。以前は、トランザクションがこれらのスレッドにランダムに割り当てられ、各キューは他のスレッドが処理するパケットを認識せず、個別にパケットの優先順位を付けていました。

このシステムでは、各スレッドがキューを順番に処理し、トランザクションのロック取得と実行を試みます。現在のサイクルを完了すると、追加のパケットを収集して処理を再開します。この構造では、優先手数料を効果的に活用することが困難です。たとえば、優先度の高いトランザクションがあるスレッドのキュー先頭にあっても、別のスレッドが同じアカウントに関わる優先手数料の低いトランザクションをキュー末尾から同時に処理する可能性があります。優先手数料がトランザクション順序に影響するのは、個々のスレッド内だけであり、すべてのスレッド間ではありませんでした。その結果、各キューでは先入れ先出し（FIFO）処理と優先手数料を組み合わせたハイブリッドな順序付けが行われましたが、スレッド全体を横断するグローバルな順序は強制されませんでした。

スレッドがトランザクションを実行する際は、まず必要なアカウントロックを確保する必要があります。必要な書き込みロックを取得できない場合、そのトランザクションは再びキューに入れられます。トランザクションがスレッドへランダムに割り当てられることで、同じ種類のトランザクションでもマルチスレッドスケジューリングシステム内の異なる位置に配置される可能性があり、問題はさらに深刻になります。このスケジューラの確率的な性質がジッターを生み、ブロック内でのトランザクション配置にばらつきが生じます。

2024年5月のAgaveクライアントv1.18アップデートでは、中央スケジューラとも呼ばれる新しいトランザクションスケジューラが導入されました。新しい構造では、中央スケジューラがprio-graphと呼ばれる依存関係グラフを構築し、すべてのスレッドにまたがる競合トランザクションの処理と優先順位付けを改善します。この大規模アップデートにより、Solanaがトランザクションを決定論的に順序付ける能力は大幅に向上し、優先手数料の高いトランザクションほどブロックに取り込まれやすくなりました。

prio-graphは、新しいトランザクションが追加されるたびに動的に更新される有向非巡回グラフ（DAG）です。トランザクションはグラフ内で整理され、時間的優先度の順に処理される実行チェーンを形成します。競合するトランザクションでは、優先手数料によって挿入順序が決まります。この方式はロック競合を最小限に抑え、トランザクションのバッチを円滑に実行し、資源競合による遅延を減らします。パフォーマンスを高め、より効率的に処理できるように、トランザクションの事前コンパイル検証はワーカースレッドへ移されています。 

更新されたスケジューラ設計では、スケーラビリティと柔軟性が大幅に向上しています。ロック競合が増えるリスクを伴わずに、スレッド数を増やせる可能性があります。さらに、集中型のスケジューリング方式によって報酬生成が改善され、多くのバリデータ運用者の収益が増加しました。

中央スケジューラの詳細については、以前公開したAgave 1.18アップデートを解説するHeliusブログ記事をご覧ください。

より効果的な優先度計算

スケジューラのアップデートと併せてトランザクション優先度の計算式も改良され、必要な計算量が少ないトランザクションが有利になりました。これにより、開発者や資源使用量の少ないトランザクションが恩恵を受けます。 

改訂後の計算式は次のとおりです。

優先度 =（優先手数料 * 要求計算ユニット）+ 基本手数料 / 

（1 + 要求実行CU + 署名CU + 書き込みロックCU）

この新しい計算では、トランザクションに関連するすべての計算コストと運用コストが考慮され、優先度が実際の資源消費量を正確に反映します。そのため、追加の優先手数料がない単純なトークン送金やネイティブSOLトランザクションでも、キュー内で最低限の優先度が保証されます。より複雑なトランザクションでは、`SetComputeUnitLimit`命令を使用して独自のCU上限を指定しない開発者は、指定する開発者よりもトランザクションの優先順位付けで不利になります。

ローカル手数料市場の有効性の測定

このセクションでは、SolanaのLFMに関連するデータを検証します。 

トランザクション手数料の中央値と平均値

LFMが効果的に機能していれば、単純なステーブルコイン送金など、競合していない状態に関わるトランザクションの手数料は低く維持されると予想されます。一方、投機的で流動性の低いトークンなど、競合する状態へアクセスするトランザクションの手数料は需要とともに急騰するはずです。この動きを評価する有用な指標は、トランザクション優先手数料の中央値と平均値の比較です。手数料の中央値は50パーセンタイルのユーザーが支払った手数料で、一般的なコストを示します。平均手数料はすべての手数料をトランザクション総数で割った値で、全体的な傾向を示します。

最近のデータは、この予想どおりの傾向を裏付けています。2024年11月、Solana上の経済活動は過去最高水準となり、非投票トランザクションの平均手数料は過去最高の0.0003 SOL超に達しました。それにもかかわらず、手数料の中央値は0.00000861 SOLで安定し、約35分の1でした。これに対し、2024年4月には同様の経済活動の急増によって平均手数料が0.0002 SOLを超え、中央値も0.00001862 SOLまで上昇し、その差は約10倍でした。この乖離は、需要が高い時期でも手数料を分離することで、一般ユーザーをコスト急騰から保護し、投機目的ではないユースケースのユーザー体験を維持できることを示しています。

LFMを持たないCoinbase運営のEthereum L2 Baseなど、EVMベースのネットワークで同様のデータを分析すると、トランザクション手数料の中央値と平均値に強い相関が見られます。需要が増えるとグローバル基本手数料が上昇するため、平均値と中央値は比較的連動して動きます。また、トランザクション手数料の中央値と平均値の差も明らかに小さくなっています。たとえば、2024年12月5日、Baseの平均トランザクション手数料は0.1115ドルまで急騰し、中央値も0.0228ドルまで上昇しました。その差は約5倍です。

リバートされたトランザクションの割合

もう1つの有用な傾向は、リバートされたトランザクションの割合です。2024年4月と5月の経済活動が活発だった時期には、チェーンが大量のスパムに圧迫され、Solanaユーザーからユーザー体験の悪化が広く報告されました。決定性の欠如によってトランザクション実行の予測可能性と信頼性が低下し、ユーザーはより早く取り込まれる可能性を高めるため、トランザクションスパムをネットワークへ大量に送信しました。 

サーチャーは成功確率を考慮せず、機会的な取引のためにトランザクションを頻繁に送信します。不適切に低い優先手数料を設定したアービトラージトランザクションも有効です。プロトコルは、優先手数料がより高い他のトランザクションの後にそれらを処理しますが、スリッページロジックによってリバートする可能性が高くなります。 

リバートされたトランザクションは2024年4月にピークを迎え、すべての非投票トランザクションの75.7%を占めました。この割合は、Agave 1.18の中央スケジューラを含む主要アップデートの導入後、大幅に低下しました。

過去7日間（2024年1月6日〜13日）を対象とするBlockworks Researchのコホート分析では、活動レベルに応じてリバート率が異なることが示されています。1日に1〜5件のトランザクションを実行するアドレス（主に個人ユーザー）のリバート率は1.4%で、1日に6〜50件を実行するアドレスでは4.6%に上昇します。特に、1日に10,000件を超えるトランザクションを実行するアドレスでは、リバート率が66.7%に急上昇します。さらに、1日に100,000件を超えるトランザクションを実行する高活動アドレス（ボット）は、リバートされた全トランザクションの95.2%を占めます。2024年12月には、全非投票トランザクションの総リバート率が41.2%でした。これは、失敗したアービトラージの処理にネットワークの計算資源の大部分が費やされていることを示します。

継続中の問題と改善領域

顕著な進歩があった一方で、Agaveバリデータクライアントのスケジューラには依然として課題があります。AnzaのエンジニアAlessandro Decina氏が実施した、以下のバンキングステージのスレッド負荷分析は、現在の非効率性と改善領域を明らかにしています。

スケジューラスレッド: ブロック生成において最も重要なスレッドです。スケジューラはすべての受信トランザクションを取得し、並べ替えて実行をスケジュールします。 

投票トランザクションスレッド: 2つの専用スレッドが投票トランザクションを処理し、ユーザートランザクションとは別に処理されるようにします。

非投票トランザクションスレッド: スケジューラが割り当てたトランザクションを受信し、ユーザートランザクションを処理する4つのスレッドです。

QUIC取り込みスレッド: バリデータがリーダーの場合、TokioスレッドがQUICプロトコル経由でトランザクションの取り込みを管理します。2024年初頭の混雑期には、これらのスレッドが重大なボトルネックとなりました。

上の可視化では、リーダーの最初のブロックの冒頭ではすべてのワーカースレッドがトランザクションを並列実行するものの、その並列性がすぐに失われ、逐次実行へ移行することがわかります。具体的には、1つの非投票トランザクションスレッド（スレッド3）だけが処理を継続し、残りのスレッドはアイドル状態になります。

この動作は、スケジューラのバグによってバリデータクライアントが能力を最大限に活用できていないことを示唆します。その結果、システムは潜在能力の一部でしか稼働していません。この問題を解決できれば、バリデータは現在の最大4倍の負荷を処理できる可能性があります。

可観測性

予測可能なトランザクション到達を推定する現在の手数料APIは、決定論的な結果を提供するために必要な高度さを欠いています。主要なRPCプロバイダーはそれぞれ独自の優先手数料APIを提供していますが、中核となるオープンソースのRPC API実装は依然として最適ではありません。Jitoの影響など重要なネットワーク動態が考慮されておらず、手数料推定の精度が低下しています。 

Heliusは`getPriorityFeeEstimate` RPCメソッドを提供しています。これは、グローバル手数料市場とLFMの両方の履歴データに基づいて手数料を推奨します。開発者は、シリアライズされ署名済みのトランザクション、またはトランザクションに関係するアカウントキーのリストを入力できます。このメソッドは独自の優先手数料レベルに対応し、min、low、medium、high、very high、unsafe maxという6つのパーセンタイルに分類します。デフォルトではmedium（50パーセンタイル）が推奨値に設定されます。手数料は直近50スロットのデータを使用して計算されます。

{
 "jsonrpc": "2.0",
 "id": "helius-example",
 "method": "getPriorityFeeEstimate",
 "params": [
   {
     "transaction": "LxzhDW7T...", // Base58 encoded serialized transaction
     "options": {
       "recommended": true
     }
   }
 ]
}

上記: base58でエンコードされたシリアライズ済みトランザクションを使用するgetPriorityFeeEstimateのペイロード例です。

優先手数料を決定論的に算出する方法がないため、開発者はトランザクションの処理を保証するために、過剰に支払うという慎重な対応を取りがちです。また、ブロック先頭の確保が不要なトランザクションであっても、Jitoチップを過剰に使用する場合があります。これらのチップは、優先手数料の代替として頻繁に使用されます。特に、2024年に観測されたチップの大部分は、アービトラージやサンドイッチなどの従来型MEV活動に関連するものではなく、トランザクションをより早く取り込ませることを目的としています。バリデータは、より高いブロック報酬とMEVコミッションを受け取ることで、この非効率性から利益を得ています。

開発者がオンチェーン状況の変動に応じて優先手数料を動的に調整するロジックを実装していない場合、別の課題が生じます。大きな市場変動などの重大なイベント時には、特定の状態アカウントへアクセスする手数料が急騰する可能性があります。動的な手数料メカニズムを持たないアプリケーションは、固定された手数料設定では適時の実行を保証できないため、このような状況への対応が困難になります。

提案されている解決策

Solanaの手数料構造をさらに強化するため、さまざまな戦略が提案されています。これらの提案は、ネットワーク資源の割り当てを最適化し、スパムを送信するインセンティブを軽減することを目的としています。

指数関数的な書き込みロック手数料

Tao Zhu氏（Anza）とAnatoly Yakavenko氏が2023年1月に提案したSIMD-0110は、競合するアカウントに動的手数料を課して混雑を管理する新しいメカニズムを提示しています。このメカニズムは、書き込みロックされたアカウントの計算ユニット（CU）使用量の指数移動平均（EMA）を追跡し、一貫して高い使用率を示すアカウントの書き込みロックコストを引き上げます。

このシステムを実装するため、Solanaランタイムは、競合するアカウントの公開鍵と対応するCompute Unit Pricer（CUP）をLRU（Least Recently Used）キャッシュに保持します。CUPはアカウントのEMA CU使用率を監視し、照会時に更新されたコストレートを提供します。

このメカニズムは書き込みロック手数料を動的に調整します。アカウントのEMA CU使用率が目標しきい値を超えると、書き込みロックのコストレートが上昇します。逆に、使用率が目標を下回るとコストレートは低下します。初期パラメータは次のとおりです。

• アカウントの最大CU上限の25%を目標使用率とします。
• 初期書き込みロックコストレートは、CUあたり1,000 micro-lamportsです。
• コスト調整率はブロックあたり1%です。

アカウントの書き込みロック手数料は、そのコストレートにトランザクションが要求するCUを掛けて計算します。このシステムでは、トランザクションの合計手数料は、基本署名手数料、優先手数料、書き込みロック手数料という3つの要素の合計です。書き込みロック手数料は100%バーンされます。

SIMD-0110は公開時にコミュニティで活発な議論を巻き起こしました。しかし、現在この提案は非アクティブで、クローズ済みとされています。

動的基本手数料

SolanaのLFMを改善するもう1つの長期的な解決策は、グローバルおよびアカウント単位の動的基本手数料（DBF）を導入することです。Ellipsis LabsのJarry Xiao氏とEugene Chen氏は、この方式の著名な提唱者です。

優先手数料は任意ですが、基本手数料は必須です。現在、Solanaの基本手数料は署名ごとに5000 lamportsで固定されています。単純なトークン送金を行うユーザーも、複数の取引所をまたぐ複雑なスワップを行うユーザーや、高度なMEVアービトラージを実行しようとするサーチャーも、同じ基本手数料を支払います。基本手数料は、トランザクションの計算資源使用量を正確に反映していません。

動的基本手数料を導入すると、不適切な基本手数料を設定したアービトラージトランザクションを無効と見なし、スケジューラに到達する前に破棄できます。基本手数料を引き上げることで、スパマーが送信するトランザクション数を減らすよう促せます。

基本手数料は最終的に均衡点へ収束し、トランザクションの価格はブロックスペース市場の価値に基づいて決まります。基本手数料が上昇するため、最終的にはトランザクション送信が取引の機会費用に見合わなくなる限界費用へ達します。手数料が高すぎるとユーザー活動に影響するため、過度に上昇してはなりません。ボットには高すぎる一方、一般ユーザーにはおおむね許容できる上限が理想的です。このようなシステムでは、取り込みを狙ってトランザクションをスパム送信するアカウントは、保有するすべてのSOLをバーンすることになります。

Solanaの短いブロック時間により、基本手数料には積極的なアルゴリズムを適用できます。需要が高い時期には、ネットワークの混雑を反映するため、ブロックごとに倍増させる可能性も含めて手数料を迅速に調整できます。逆に需要が減少すると、手数料をより緩やかに引き下げられます。Solanaはブロック時間が短いため、引き下げも比較的速く進み、ネットワークは変化する状況へ迅速に適応できます。

同様の経済的バックプレッシャーの例として、Metaplex Candy Machineプログラムがあります。このプログラムは、2022年にスパム対策としてボット税を導入しました。ボット税は、無効なトランザクションに対する任意の課金です。通常は、正当なミスをした実ユーザーに影響を与えないよう、十分に少額に設定されます。この税は効果を発揮し、ミントスナイパーの資金はすぐに枯渇して、スパム送信が止まりました。

まとめ

SolanaのLFMは機能していますが、大きな改善の余地が残されています。

• 優先手数料メカニズムの強化: 優先手数料のRPC呼び出しを改善する必要があります。理想的には、開発者が簡単かつ決定論的に手数料を設定し、その後数ブロック以内へのトランザクション取り込みを保証できるべきです。
• スパムを経済的に抑止: ネットワークは、経済活動が活発な時期にボットへ経済的なバックプレッシャーをかけながら、正当な人間のユーザーには低い手数料を維持する方法を確立する必要があります。
• 開発者の教育: 開発者はアプリケーションのトランザクション手数料を固定するのをやめ、通常のトランザクションでJitoのようなプロトコル外メカニズムへの依存を減らす必要があります。
• スケジューラのさらなる最適化: 需要が高い時期にすべてのワーカースレッドを活用できるよう、トランザクションスケジューラをさらに最適化する必要があります。

Solana共同創業者のAnatoly Yakovenko氏が指摘するように、これらの課題は主に「単なるエンジニアリング上の問題」であり、適切な技術的注力によって解決できます。

その他のリソース

• Solanaの手数料、パート1 - Umbra Research
• 多次元的なSolana手数料に向けて - Umbra Research
• Ethereumのスケーリングにローカル手数料市場が必要な理由 - Eclipse Labs
• Solanaのローカル手数料市場は実在しない | Eugene Chen - Lightspeed Podcast
• Solanaのバンキングステージとスケジューラ - A.Fitzgerald