原題:Solana & Ethereum Transaction Fee Mechanisms: Proposals to Improve Solana's TFM

Andrew Fitzgerald 氏、Harsh Patel 氏、Jon Charbonneau 氏、Kevin Galler 氏、Lanre Ige 氏、Mert Mumtaz 氏、Pranav Garimidi 氏、Ryan Chern 氏、Tao Zhu 氏、Tarun Chitra 氏にフィードバックとレビューをお寄せいただき、ありがとうございます。

紹介

Eclipseはイーサリアム初のSVM L2です。 既存のSVMのパワーをより多くのユーザーに提供できることを非常に嬉しく思いますが、SVM自体に関する継続的な研究開発も推進することに専念しています。 私たちは、Eclipseの開発がすべてのSVMチェーン、特にSolanaに間違いなく価値を還元することに重点を置いています。

本稿では、手数料市場に関する考え方に関する今後の記事の先駆けとして、Solanaの既存の手数料市場と、それを改善するための関連する提案を分析します。 これらの提案は、 Tim Roughgarden氏、 Maryam Bahrani氏、Pranav Garimidi氏、 Hao Chung氏、Elaine Shi氏などの研究から大きく借用した、取引手数料メカニズム(TFM)の主要な理論的目標と並んでいます。 中核となる定義は ** で示します。

一般に、TFMは以下を決定します。

1. 特定のブロックに含まれるトランザクション
2. 特定のトランザクションが支払う手数料
3. 累積された取引手数料をどのように(そして誰に)分配するか。

最終的に、この記事は、イーサリアム中心のTFM研究の豊富さとSolanaの革新的なエンジニアリングを組み合わせることを目的としています。

SolanaとEthereumの現在のTFMの概要

Solana vs. Ethereumの基本

まず、SolanaのTFMの概要を説明し、イーサリアムのTFMと比較します。 これにより、関連する提案の文脈が明確になり、TFMの修正と改善に取り組むことができます。 手始めに:

Solanaの基本手数料は、署名ごとに5,000ランポート(0.000005SOL)の固定で、ほとんどの取引は1つの署名です。 トランザクションのより広範な計算リソース (CU で測定) は考慮されません。

Solana Tx基本料金 = (5,000 Lamports) x (# of Signatures in Tx)

イーサリアムの基本料金の仕組みは、主に2つの点で異なります。

1. 動的 - イーサリアムの基本料金(ガスの単位あたりのgweiで測定)は、市場の需要に基づいて変動します。
2. 計算単位あたりのより詳細な料金 - イーサリアムのトランザクションあたりの基本手数料は、消費されるガスの量で直線的です。

したがって、イーサリアムのトランザクションあたりの基本手数料は次のとおりです。

イーサリアムTx基本料金=(gweiでの一般的なガス価格)x(txで使用されるガス)

Solanaユーザーは、オプションの 優先料金 を追加して、参加確率を高めることもできます。 基本料金とは異なり、優先料金はトランザクションに対して要求されたCUごとに価格設定されます。 Solana トランザクションには、以下のコンピュート予算の指示を含めることができます。

1. SetComputeUnitLimit - トランザクションは、消費できる CU の最大量を設定できます (トランザクションあたり最大 1.4M CU)。 実行されると、トランザクションは要求された CU 制限まで使用できます。 SetComputeUnitLimit 命令が指定されていない場合、トランザクションの CU 制限は (トランザクション内の命令の # 数) x (200k CU) として計算されます。
2. SetComputeUnitPrice - # of micro-lamports per CU は、トランザクションが優先料金での支払いを申し出ることを要求しました。

それらをまとめると、次のようになります。

Tx 優先手数料 = (Tx CU 制限) x (CU 価格)

この優先手数料は、トランザクションが実際に使用するガス量の関数であるイーサリアムとは異なり、(トランザクションが要求された合計金額を使用するかどうかに関係なく)要求されたCU全体に対して支払われることに注意してください。

Fee Burn vs. Validator Rewards(手数料バーン vs. バリデーター報酬)

バリデーターが高額な手数料の取引を優先するインセンティブはコンセンサスの範囲外にありますが、Solanaでは、基本手数料と優先手数料の両方が50/50でバーン/リーダー(現在のブロックプロデューサー)に送られることがコンセンサスで実施されています。

1. 基本料金 — ブロックに含めるには必須です。 必要な基本手数料を満たさない取引は拒否されます。
2. 優先権 — ブロックに含めるのに必須ではありません。 オプションで、高速インクルードの確率を高めたいトランザクションに優先順位を付けるために使用されます。

ユーザーは基本料金の支払いを避けることはできませんが、優先料金を回避し、別の方法で優先されたいという希望を示すことができます。 Jito-Solanaのオークションは、リーダーに100%(手数料を差し引いたもの)を帯域外で支払います。SIMD-0096 では、この問題を簡単に修正し、優先権の 100% をバリデーターに付与します。

直接送金*:MEV-Boost / Jito-Solanaオークションでコーディネート

重要なのは、Solanaのバリデーターがオンチェーントランザクションで各ブロックに投票することです。 彼らはこれらの取引ごとに基本料金を支払います。

Solanaは最近、優先手数料の急激な上昇により、ネットワーク手数料が過去最高を記録しています。最近の手数料の分割を以下に示します。

出典:Solana Compass

イーサリアムブロックビルダーとソラナスケジューラーの比較

イーサリアムのブロック生成は一般的に理解しやすいので、そこから始めます。 ほぼすべてのバリデーター(別名 提案者)は、 MEV-Boostを介してプロトコル外のビルダーにブロック生成をアウトソーシングします。 ビルダーは12秒ごと(イーサリアムのスロット時間)にブロックを作成し、これらのブロック全体を(リレーを介して)提案者に渡し、提案者は最も価値の高いブロックを選択します。

イーサリアムとソラナの両方で、ブロックプロデューサーはブロック内で任意のトランザクションを注文する権限を持っています。 彼らは、利益を最大化する方法でそうするインセンティブを得ています。 例えば、さまざまなイーサリアムビルダーは、競合他社に対してより効果的に利益を最大化する独自のアルゴリズムを実行することで競争することができます。

つまり、イーサリアムでも、優先度の高い手数料を送信しても、ブロックの包含や順序付けのプロトコル内の決定論的保証は達成されません。 しかし、イーサリアムの現在のブロック構築プロセスの性質上、ビルダーが各ディスクリートスロットの最後に完全な利益を最大化するブロックを構築するため、期待される結果が得られる可能性が非常に高いです。

例えば、サーチャーは、信じられないほど高い優先度の手数料(例えば、他のすべての適格な取引を合わせたよりも高い)の裁定取引をビルダーに送信し、ブロックの一番上に含め、ブロックの一番上に位置しない場合はブロックから完全に除外するように要求することができます。 この場合、合理的な利益最大化ビルダーは、12秒のスロットの終わり近くでしか受け取らなかったとしても、このトランザクションをブロックの一番上に含めます。

ここでは、手数料が達成しようとしている2つの異なる保証があることに気付くでしょう。

1. 包含 - ユーザーは自分のトランザクションをこのブロックに含めたいと考えていますが、ブロック内のどこに着地するかは気にしません。
2. 順序付け - ユーザーは、ブロックのどこかに含まれることを望んでいるだけではありません。特定の時間に特定の状態への優先アクセスが必要です。

イーサリアムの EIP-1559 メカニズムは、ユーザーが高い確率でブロックインクルージョンに簡単に入札できるようにするのに非常に効果的であることが証明されています。 誰もが支払うべきことがわかっているグローバルリザーブ価格があり、それを支払うことで(通常は名目上の優先手数料と一緒に)、ユーザーの取引が迅速に含まれるはずです。 しかし、このメカニズムは、順序付け(すなわち、状態への優先的アクセス)に関するいかなる保証も提供しようとはしないが、プロトコル外のメカニズムは、そのような保証を求めるユーザー(例えば、ビルダーから直接)にとって信頼できるものである。

Solanaのブロック構築プロセスは、まったく異なる仕組みになっています。 バリデーターは、個別のタイムスロットでのフルブロック生成を、プロトコル外のビルダーにアウトソーシングすることはありません。 「スケジューラー」は、 Solana Labsのバリデータークライアントに含まれるデフォルトのアルゴリズムで、トランザクションの実行をスケジュールし、ブロックを継続的に構築します。

さらに、 Solanaトランザクション は、実行のために読み取りおよび書き込みロックする必要があるアカウントを指定します。 これにより、スケジューラーは、同じ状態に触れないトランザクションを並行して実行できるため、同時に実行できるトランザクションを繰り返し並べ替えることができます。

ブロック内では、最大 12,000,000 CU を 1 つのアカウント (「状態の一部」) へのシーケンシャル書き込みに使用できます。 これは、妥当なノード要件で 400 ミリ秒のスロットあたり 1 つのスレッドで処理できる CU の量とほぼ同じです。 Solanaのブロックあたりの制限は 48,000,000CUです。 現在のスケジューラの実装では、投票以外のトランザクションに 4 つのスレッドが使用され、12M x 4 = 48M になります。 理論的には、これはより多くのコアを使用する = CU 制限を増やすことを意味します。 ハードウェアによるスケーリング。

スケジューラーは、優先度の高い手数料を持つトランザクションに非決定論的に優先順位を付けます。 しかし、これは一般的に、今日のイーサリアムの場合に説明されているようなメカニズムよりも信頼性の低い優先順位付けの保証を提供します。

Solanaでは、バリデーターはデフォルトのスケジューラービルドブロックを継続的に実行するため、トランザクションを進行中のブロックに追加して実行し、スロットの終わりまで待ってから優先料金のみで整理することができます。 その意図は、スケジューラが 合計 CU 価格に基づいてトランザクションに優先順位を付けることで、非常に大まかに利益を最大化することです。

Solanaのデフォルトのマルチスレッドスケジューラでは、追加の「ジッター」も発生します。 トランザクションは 4 つのスレッドのうちの 1 つにランダムに割り当てられ、各スレッドは実行を待機するトランザクションの独自のキューを維持します。 次に、優先手数料を使用して、スレッド内のトランザクションに優先順位を付けます。 ただし、スレッド間でトランザクションの優先順位付けを行うのには役立ちません。

例えば、2人のサーチャーがそれぞれ同時にトランザクションを送信して同じアービトラージの機会を獲得し、優先度の低い手数料を送信したサーチャーが、偶然に詰まりの少ないキューに着地したため、勝つことさえあります。 これにより、優先手数料の有効性が低下し、イーサリアムと比較してスパムのインセンティブが高まります - 特に、トランザクションに含めるかどうかは、特定のスロット内でトランザクションが現在のブロックプロデューサーに到達するタイミングにも依存するためです。

なお、Solanaのデフォルトスケジューラーには、トランザクションの依存関係のグラフに依存し、グラフ内で最も優先度の高いブロックされていない(書き込みロックされていない)トランザクションをスケジュールすることで、現在の実装の問題のいくつかに対処することを目的とした 変更が計画 されています。

ほとんどこの記事の範囲外ですが、 Jito-Solanaクライアント を使用すると、検索者はSolanaの負の外部性を最小限に抑える方法で、マイナー/最大抽出可能価値(MEV)をより効率的に取得できます。 Jito-Solanaは、デフォルトの連続ブロック生産とプライベートmempool(これもSolanaのデフォルトのTFMから逸脱しています)と並行して実行される、プロトコル外の200ミリ秒の Flashbots風のバンドルオークションを導入することで、Solanaのデフォルトのスケジューラーから逸脱しています。 SolanaのバリデーターによるJito-Solanaクライアントの採用(現在、バリデーターの>50%がJito-Solanaを実行)は、Solanaの既存のTFMが抱えるいくつかの問題、すなわちMEVによるスパムの蔓延に取り組むのに役立っています。

Solanaの現在のTFMの欠点

SolanaのTFMは非常に有望ですが、今のところいくつかの潜在的な欠点もあります。

スパムへのインセンティブ

前述したように、トランザクションは、ブロックプロデューサーに到達するとすぐに、先入れ先出し(FIFO)方式で順序付けられます。 さらに、ネットワーク ジッターと既定のスケジューラのランダム化されたスレッド割り当ての両方による非決定性の影響を受けます。 優先手数料は、特定の状況下ではインクルージョン確率を高めるのに役立つかもしれませんが、最速のインクルージョン確率を最大化するために取引をスパムする大きなインセンティブが依然として存在します(例えば、貸出市場でデフォルト状態のポジションを清算するためにサーチャーが競い合うなど)。 Jito Labsの以下の画像は、スパムトランザクションの最適ではない性質を示すのに役立ちます。

出典:公益財団法人地頭財団

ファーストプライスオークション

素朴なファーストプライスオークション(FPA)では、ユーザーは入札を送信するだけで、最高額がブロックに含まれます。 FPA の問題の 1 つは、あまりユーザーフレンドリーではないことです。ユーザーは、他のユーザーが何に入札しているかを推測し、自分が何に入札するかを考え、たとえば、他の人が入札していると思われるものに基づいて過払いしないように、入札額を低く抑える必要があります。

より正式には、FPAモデルは非DSICです。

**Dominant Strategy Incentive Compatible(DSIC):ブロックプロデューサーがTFMを誠実に実装すると仮定すると、所定の入札戦略がユーザーにとって支配的な戦略になるはずです。 これは、ユーザーが(取引手数料で)取引に含まれると判断する正確な値で入札することを意味します [Chu22]。

DSICは、EIP-1559の作成者がイーサリアムのTFMに導入することを目指した重要な特性の1つであり、前述したように、成功と見なすことができます。 ユーザーは、特定の時間にブロックに含まれる公開リザーブ価格を(動的基本手数料を介して)より簡単に知ることができるため、それ(および名目上の優先手数料)を支払うことで、ほとんどの場合、トランザクションがすぐに含まれます。

逆に、SolanaのTFMは素朴なFPAです。 これは、ユーザーがブロックインクルードの好みを正確に表現するための信頼できるメカニズムを欠いており、非DSICです。 実際には、適切なタイミングで適切な優先料金を設定しようとすると、非常に困難です。 これは、ネットワークやスケジューラーのジッターをバイパスする能力の高い高度な参加者に不釣り合いに有利です(例:コロケーションやスパムトランザクション経由)。

50/50 バーン/バリデーターペイアウト

前述したように、イーサリアムは基本料金の100%をバーンし、優先料金の100%をブロックプロデューサーに送金しますが、Solanaの場合、基本料金と優先料金の両方がブロックプロデューサーに50/50バーン/支払われます。 この結果、Solana TFMはOCAに耐性がありません。

**オフチェーン・アグリーメント・プルーフネス(OCA-proofnessまたはSCP):ユーザーとブロックプロデューサーの間のオフチェーン・アグリーメントは、特定のブロックに対するTFMの結果を改善することはできません [Rou21]。 c-SCPプロトコルは、ブロックプロデューサーと最大c人のユーザーが真実の報告から逸脱することで利益を得ることができる連合に耐性があります。

Jito-Solanaのアウト・オブ・プロトコル・オークションでは、50%を燃やすのではなく、100%(Jitoのカットを差し引いたもの)をブロックプロデューサーに支払うという明確な例が見られます - Jito-Solanaは、ブロックプロデューサーが使用するオフチェーン契約の一例です。 ただし、Jito-Solanaのチップは、関連するトランザクション(およびバンドル)が正常に実行された場合にのみ支払われるため、優先手数料と同等ではないことに注意してください。

最近提案された SIMD-0109 は、(Jito-Solanaのアウトプロトコルオークションで使用されているものと同様の)チップメカニズムをネイティブ命令としてプロトコルに導入します。

特権トランザクション・タイプの欠落

Solanaの投票トランザクションはオンチェーンで投稿され、ブロックに含める必要がありますが、各バリデーターは当該トランザクションの費用を支払う必要があります。 これは、投票取引を含めることの正の外部性にもかかわらず、かなりの固定費(バリデーターが個人的に支払う)を表しています。 このコストは、投票トランザクションが消費された CU に対して過剰に課金される (つまり、使用される CU が平均トランザクションに対して比較的少ない) という事実によって悪化します。 総投票コストはどのバリデーターでもほぼ一定であり、得られる報酬はステークの重みに比例するため、経済性はここで集中化効果を生み出します。

出典:Ceteris, Solana the Monolith

余談ですが、同様のロジックを拡張して、信頼性の高いオラクルの更新を含めることもできますが、正確なオンチェーン価格フィードの正の外部性にもかかわらず、ネットワークは通常料金を請求します。 特定の堅牢なオラクルから高い価値を引き出す、より独断的なチェーンは、そのコストを助成するメカニズムを祀ることを選択するかもしれません。

Solanaのローカル手数料市場

Solanaのローカル手数料メカニズムの近似は、どのアカウントも48Mブロック制限あたり12M CUを超える書き込みができないために存在します。 これは、Solanaのデフォルトスケジューラーのマルチスレッド性とともに、ブロック内のトランザクションの最大25%が1つの需要状態に対応できることを意味します。 理論的には、需要の少ない州のユーザーは、需要の高い州のユーザーと比較して、強力なインクルージョン保証のために優先料金を増やす必要はありません。

これは間違いなく、本物のローカル料金メカニズムではありません。 このメカニズムはコンセンサスによって強制されるものではなく(スケジューラーレベルのみ)、優先権とブロック包含の関係は(前述のように)かなり非決定論的です。 また、ターゲットリソース制限と最大リソース制限の両方が存在する「弾力性」の概念も欠いています。

非効率的なCUの使用と要求

Solanaの基本手数料はCUを考慮していないため、取引に以下のインセンティブを与えるものではありません。

1. CU の効率的な使用 — 1.4M CU のトランザクションは、100k CU のトランザクションと同じ基本料金を伴いますが、それ以外はすべて同じです。
2. CUの効率的なリクエスト — トランザクションが50k CUを使用する場合でも、100k CUまたは1M CUのどちらを要求しても、同じ基本料金がかかります。

これにより、スケジューラが特定のブロック内で必要とするコンピューティングが過大評価され、特定のスロットでブロックプロデューサーが必要とするリソースと比較して効率が低下する可能性があります。 DSIC TFMは、ユーザーの支配的な戦略が所定の入札戦略(この場合はCUの予想される使用量を正確に表す)であるため、この問題を解決します。

ロックアカウントの書き込みにコストがかからない

前述したように、Solanaのトランザクションは、実行中に読み書きするすべてのアカウントを前もって指定します。 ただし、このメカニズムは、今日では悪用されて、事実上無料でアカウントをグローバルにロックすることができます。 例えば：

1. アカウント_A に書き込むことを指定する Tx_A を送信します。
2. リーダーは Tx_A を受信し、スケジュールを設定し、実行を開始します。 アカウント_Aはロックされ、Tx_Aの実行が終了するまで、アカウント_Aに触れる他のトランザクションは実行できません。

この問題は、誰でも好きなアカウントを書き込みロックするトランザクションを送信できるという事実に起因しています。 アカウントのロックにコストはかからず、トランザクションは使用していないアカウントをロックすることさえあり、これは明らかなスパム攻撃ベクトルです。 さらに、アカウント所有者は、自分のアカウントを書き込みロックできるユーザーを制御することはできません。

TFMの提案とフレームワーク

すべてのブロックチェーンは、有限のブロックスペースの希少なリソースをユーザー間でどのように割り当てるかを最終的に決定する必要があり、TFMを介してそれを行います。 以下では、Solanaにとって価値があると思われるいくつかの関連するTFMの提案とフレームワークについて説明します。

多次元ブロックチェーン手数料市場

既存の手数料市場のほとんどは、1つの代替可能な勘定単位(イーサリアムのガスなど)を中心に構築された一次元的なものです。 ただし、購入されたこの単一のリソースは、多くの基盤となる代替不可能なリソース(帯域幅、計算、ストレージなど)のプロキシです。

たとえば、各 イーサリアムオペコード は、消費する一定量のガスを運びます(たとえば、ADDは3つのガスを使用し、MULは5つのガスを使用します)。 各オペコードのガス価格は、使用する基盤となるリソースと、ネットワーク内のノードにとってどの程度のコストと見なされるかの大まかな近似値として設定されました。 たとえば、この操作コストの暗黙的な測定値は、実際のハードウェアでベンチマークを実行することで決定できます。

しかし、これらの異なる代替不可能なリソースを1つのユニットにまとめるのではなく、個別に価格を設定する多次元の手数料市場を構築することも可能です。 EIP-4844は 、データブロブがイーサリアムの実行ガスから独立した独自の手数料市場を持つため、単純な2次元の手数料市場です。

Diamandis氏、Evans氏、Chitra氏、Angeris氏によるこの2022年の論文では、このような多次元的な手数料市場の構築方法を分析しています。彼らの研究は、ブロックチェーンのトランザクションとブロックの制約(スマートコントラクトの制限やCU/ガスの制限など)を条件として、ブロックチェーンのユーザーの福祉(または総効用)から当該ユーザーのリソース消費を差し引いたものを最大化することを目的としたネットワーク設計者の視点からTFM構築の問題を組み立てます。 この論文の主な成果は、福祉が未知であるにもかかわらず、それを最大化するメカニズムを設計し、そのメカニズムを明示的に構築する方法を示したことです。

**厚生の最大化:意図された配分と支払いのルールは、消費者と鉱山労働者の余剰の合計が(おおよそ)最大化されることを意味します。

彼らの重要な発見は、同等のTFMが実装可能であり、それはバリデーターとそのユーザーの福祉の差を最小化するようにリソース価格が設定されているものであり、そのような価格は、理論的には、福祉を最大化する観点から最適なブロックにつながるはずです。 この研究は、最適なTFMを設計するための学術的なフレームワークと見なすことができますが、リソースを個別に価格設定することで、ブロックチェーンをより効率的にし、混雑やスパムの時期に対する回復力を高めることができることを示すのに役立ちます。 EIP-1559のようなコントローラーベースの基本料金メカニズムは、ブロック時間が短いため、SolanaやSVMチェーンで非常にうまく機能する可能性のあるアプローチとして強調されており、基本料金はユーザーの需要やリソースの可用性の変化に迅速に対応することができます。

前述したように、この論文の結論の1つは、ブロックチェーンの多次元リソースの価格設定の定義と更新に役立つ体系的で計算効率の高い方法を設計することが可能であるということです。 しかし、当然の疑問は、どのリソースが明確に価格を設定するのが理にかなっているかということです。 そのような決定を下すために、他のブロックチェーンのコンテキスト内でいくつかの実用的な作業が行われています。 例えば、Penumbraは、プライバシー中心のブロックチェーン上で、フルノードとエンドユーザーデバイスが使用するリソースに個別に価格を設定する多次元リソースプライシングの形式 を実装し ています。

2022年の論文では、一般的に基本リソース(コンピューティング、帯域幅、ストレージなど)の多次元的な価格設定について議論していますが、アカウントごと(つまり、「状態の一部」)ごとに多次元のリソース価格を設定することも可能です。 各アカウントは異なるリソースとして扱われます。 これについては、元の論文を基にした 最近の記事で説明しています。 基盤となるリソースとして (コンピューティング、ストレージ、帯域幅などではなく) アカウントに個別に価格を設定することも、 リソース枯渇攻撃のリスクを軽減して実装がより簡単になる可能性があります。

書き込みロックアカウントの指数関数的な手数料

SVM Execution Economics に関する Anatoly氏の 最近の投稿に続き、 Tao Zhu 氏はAnatolyと共同で SIMD-0110 を提案しました。その主な動機は、経済的なバックプレッシャーでスパムを抑止し(つまり、スパムへのインセンティブを減らすために、時間をかけてターゲットを絞った方法で料金を増やす)、ネットワークリソースをより効率的に利用することです。 アービトラージ取引の失敗がSolanaのブロックスペースの約 半分(またはそれ以上) を占め続けているのは、それが合理的で、スパムが信じられないほど安価だからです。

この提案では、これを達成するために、ブロックごとの各アカウントのCU使用率の指数移動平均(EMA)を追跡することを推奨しています。 アカウントの書き込みロックのコストは、それぞれの末尾のCU使用率に基づいて指数関数的に増加し、スパムを阻止します。 コアロジックは、 EIP-1559 がイーサリアムのグローバルベースフィーをトレーリングブロックのガス使用量の関数として設定する方法と似ています。 ただし、このSIMDは、アカウントごとのローカル基本手数料市場の設定においてはるかに細かくなっています。

アカウントベースの可変書き込みロック料金の基本的な実装の考え方は次のとおりです。

1. 過去 150 スロットにおける各係争中の各アカウントの EMA コンピューティング ユニットの使用率を追跡します。
2. 追跡されるアカウントの最大数は 2048 で、書き込みロック コスト率が最も高い最も競合の多いアカウントのみが追跡されます。
3. アカウントの EMA コンピューティング ユニットの使用率が最大 CU 制限の >50% の場合、書き込みロック コスト レートは X% 増加します。 上限の<50%の場合、コスト率はX%減少します。
4. V0 では、1000 マイクロ ランポート/CU の初期書き込みロック コスト レートと、スロットあたり 1% のコスト レート調整レートを推奨しています (ここでの正確な割合は、提案の初期の性質上、すべて変更される可能性があることに注意してください)。
5. 特定のブロックでのアカウントの書き込みロック料金は、書き込みロックコスト率にトランザクションの要求されたCUを掛けて計算されます。
6. 取引には引き続き署名料が支払われ、オプションの優先手数料も残ります。
7. 回収されたライトロック料金は100%バーンされます。
8. 徴収された優先手数料は100%報酬として支払われます。
9. 集められた署名料は50%が焼却され、50%が報酬として支払われます。

この提案は、SOLANAの(通常は)DSICの書き込みロック機能を、EIP-1559がイーサリアムのTFM(通常は)DSICとMMIC [Rou23] を作った方法に類似させるものです。

MMIC プロパティは次のように定義できます。

**Myopic Miner Incentive Compatibility(MMIC):ブロックプロデューサーは、偽のトランザクションを作成せず、TFMの規定されたルールに従うことで、その有用性を最大化します。 近視眼的とは、この目標が効用最大化を判断する際に現在のブロックにのみ関係することを意味します [Rou21]。

トレーリングメカニズムは、需要の正確な現在の状態を正確に表していない可能性があるという点で不完全です。 例えば、需要が長期間にわたって低かった場合(したがって、動的基本手数料が低くなる場合)、NFTミントでは突然急増する場合があります。 これは、グローバルレベル(イーサリアムのTFMなど)に当てはまる可能性があり、ローカルアカウントごとのレベルではさらに不安定になる可能性があります(SIMD-0110で考慮されているように)。

しかし、Solanaは、ここでのブロック時間が信じられないほど短いという利点も得ています。 これにより、基本料金は、曲線がどれだけ積極的に動くかに応じて、突然の需要ショックに対してより迅速に調整することができます。 ここでの料金コントローラーの形状は非常に重要です。

また、この書き込みロック料金が要求された CU に対して課金されるという事実は、ユーザーと開発者がトランザクションの CU 使用量を正確に見積もるインセンティブを適切に与えます。 これにより、現在のフラットシグネチャベースでは、必要以上に多くのCUを要求してもペナルティがないという、前述の問題を回避できます(最大1.4mm CUまで)。 それ以外の場合、優先料金のみが現在このインセンティブを運びます (要求された CU によっても請求されるため)。

ここでの潜在的な批判の1つは、口座ベースの現地手数料市場(特に、すべての口座に対して継続的なEMAを計算する必要があるこの提案)は、計算コストが高くなる可能性があることです。 このタイプの多次元手数料は、どの口座も混雑する可能性があるため、無制限であり、このようなTFMには困難をもたらす可能性があります。 ただし、SIMD-0110 の場合、特定の時間に CU 使用量 EMA を追跡できるアカウントの数に上限を設定することで、これを回避できます。

**効率的に圧縮可能:ブロックオークションのメカニズムは、特定のブロックプロデューサー(またはビルダー)に対して効率的に計算できるように設計する必要があります — EclipseとSolanaのスロットは400ms未満であるため、特定のブロックの最大計算時間に厳しい制約が課せられます。

この提案が実装されても、Solanaのブロックインクルージョンは依然として非決定論的であることを考えると、トランザクションがブロックに含まれるようにするために、ユーザーがリアルタイムで入札を正確に更新することには潜在的な問題が生じる可能性があります。 これにさらに対処するには、次のセクションで説明するように、スケジューラを変更する必要があります。

Solanaのデフォルトスケジューラーへの変更

前述したように、「スケジューラー」は Solana Labsのバリデータークライアントに含まれるデフォルトのアルゴリズムで、トランザクションの実行をスケジュールし、ブロックを継続的に構築します。 Solanaの手数料市場では、バリデーターが他のアルゴリズムを実行することを選択する可能性があるため、デフォルトの動作はプロトコル内で強制されませんが、非常に重要な役割を果たしています。 ここでは、 Andrew Fitzgerald が取り組んでいる現在のスケジューラーと今後の変更案に焦点を当てます。

Solanaの現在のスケジューラーは、 下図 に示すように、未処理のトランザクションを優先手数料でソートし、関連するロック(「ロックグラブ」)をチェックする前に、ユーザーのトランザクションを4つの非投票トランザクションスレッドの1つにランダムに割り当てることで、ユーザーのトランザクションの処理に「ジッター」を導入しています(追加の2つのスレッドは投票トランザクションの処理用に予約されています)。 トランザクションの複数のバッチは、「バンキングステージ」(Solanaバリデーターによって実行されるプロセスでトランザクションが処理され、スケジューリングプロセスが発生するプロセス)中にスレッドに割り当てられるためにプルされます。

出典:Andrew Fitzgerald, Solana Banking Stage and Scheduler

デフォルトのスケジューラーの重大な問題の1つは、ネットワーク活動が激しい時期に、各スレッドのキューが競合するトランザクションでいっぱいになることが多いことです(たとえば、NFTミントや広く期待されているトークン生成イベントの前など)。 各スレッドには、同じまたは重複する読み取りロックまたは書き込みロックを持つトランザクションが含まれる場合があるため、これらのトランザクションは後で実行するために再スケジュールする必要があります。 ただし、この結果、極端な最悪のケースでは、4 つの既定のスケジューラ スレッドのうち 1 つだけが特定の時間にトランザクションを実行できます。

Solanaのデフォルトスケジューラーへのアップグレードの核心は、従来のアプローチ(ThreadLocalMultiIteratorモード)から、CentralSchedulerモードと呼ばれる新しいスケジューリングアプローチへの移行にあります。 この記事では、変更の概要と分析のみを提供します。 ただし、Andrew Fitzgerald 氏の記事 と、 Tiny Dancer チームのHarsh Patel氏による付随する<a href="https://medium.com/ @harshpatel_36138 /whats-new-with-solana-s-transaction-scheduler-bcf79a7d33f7">summaryブログ投稿を参照してください。新しいスケジューリングプロセスの概要を以下に示します。

出典:Andrew Fitzgerald, Solana Banking Stage and Scheduler

新しいスケジューラでは、中央の単一のスケジューラがチャネルからトランザクションを受信してから、関連するロックをチェックします。 この時点以降、トランザクションは実行のために特定の並列ワーカー スレッドに割り当てられます。 中央スケジューラは、特定のワーカー スレッドで使用されるさまざまな読み取りロックと書き込みロックのビューを保持し、新しいトランザクションに最適なスレッドを決定できるようにします。 トランザクションが特定のワーカースレッドによって実行および処理されると、メッセージが中央スケジューラに送り返され、Solanaの状態のどの部分がロックされていると見なされるかを再評価できます。

スケジューラーは、"プリオグラフ"と呼ばれるアルゴリズムを使用しますが、これは、最も優先度の高い(手数料)トランザクションと、特定の最も優先度の高いトランザクションと、ロックの重複により競合する次の最も優先度の高いトランザクションとの間の線(より正確にはエッジ)で始まる直接的なアクリルグラフです。 これは(暫定的に)2,048トランザクション(変更される可能性がある)の事前設定されたサイズの「先読み」ウィンドウに対して行われ、グラフに追加できます — 次のチャートは、prio-graphがトランザクション間のエッジが競合するロックを表す特定のトランザクションセットに対して機能することを示しています。

このバージョンでは、prio-graph スケジューラーの採用に加えて、バンキング段階の冗長な要素を削除するなど、処理のオーバーヘッドを削減するための効率性が向上しています。 新しいスケジューラーは、Solanaのアクティビティが多い期間に書き込みや読み取りロックが失敗する確率を大幅に減らすことで改善されるはずです。 新しいデフォルトスケジューラによるジッターの低減が期待できます。 それでも、ブロック構築プロセスの継続的な性質を考えると、ブロックの包含には非決定性が引き続き存在します。

プログラム・リベータブル・アカウント・ライト(PRAW)手数料

Godmode Galactus と Max Schneider によって作成された SIMD-0016 は、プログラム リベータブル アカウント書き込み (PRAW) 料金を提案しています。これらの料金の支払いとリベートの基準を設定できるため、アプリケーション開発者に大きな制御権が与えられ、ユーザーの行動にインセンティブを与えたり、インセンティブを弱めたりすることができます。

現在、Solanaプログラムには、その状態に対する書き込みロックを獲得したトランザクションにペナルティを課す機能はありません。 PRAW手数料により、Solanaのアカウント所有者は、自分の状態を書き込みロックする失敗したトランザクションに対して請求することができます。 これらの手数料は、ロックしている書き込み可能なアカウントに転送されます。 ただし、アカウント所有者は、指定された基準を満たしている場合に、トランザクションの終了時にユーザーにリベートされるようにこれらの手数料を設定できます。

特に、これにより、ユーザーがトランザクションの実行で実際に使用しないアカウントへの書き込みロックを思いとどまらせることができます。 Solanaには現在、特定のアカウントが、書き込みロックされた特定のトランザクションによって先験的に使用されるかどうかを確認するチェックがないため、現在可能です。 PRAWは、プログラムの状態をロックするトランザクションのインセンティブを削ぐ方法を提供し、実行時にオポチュニティが有効でなくなった場合に元に戻すことを意図してオポチュニティを特定しようとします。 これらの手数料は、取引が実行中に失敗した場合でも適用されます。

逆に、ユーザーはトランザクションで支払う意思のあるPRAW手数料の最大額を指定できます。 特定の書き込みロックされたアカウントの現在の PRAW 手数料を超えるトランザクションで指定された手数料は返金されます。

Solanaコミュニティのメンバーは、この提案の問題点を指摘しました:異なるプログラムが完全に自律的に動作する能力は最適ではないように思われ、料金を正確に見積もる能力は困難であることが証明されます。 さらに、SIMD-0110 のような書き込みロックされたアカウントに関するこれらの荒らしの問題に対処するための、より簡単で統一された方法がある可能性があります。

**Griefing Resistance(荒らしへの耐性):DSICのサブセットで、ユーザーがアクセスリストを偽る、つまりトランザクションに必要なリソースを誤って表示するインセンティブを与えない[Gar23]。

PRAWの提案は、アプリケーション開発者に十分に依存しているため、スパムを防止できない可能性があります:1)スパムを「通常の動作」と区別できること、および2)そうすることが最善の利益にならない可能性があるときに、部分的に責任がある負の外部性に対して自発的により多くの料金を請求することを選択し、そうしないことを選択できます。

対照的に、Solanaの研究コミュニティのメンバーは、EMAの基本料金の導入について意見が分かれていることは間違いありませんが、CUに比例する基本料金の構成要素を追加することについては、一般的に合意しています。 これにより、開発者による正確な CU の見積もりと CU の効率的な使用を奨励できます。

別れの想い

Solana独自のエンジニアリングとパフォーマンスの目標には、TFMに関する独自の考慮事項が必要です。 もちろん、イーサリアムの既存の手数料市場をソラナに移植するだけでは解決策にはなりませんが、そこから学ぶべき貴重な教訓があります。 これは、次の両方を行うメカニズムに大きく関連しています。

1. プロトコル内 - コンセンサスで実施されるTFM( EIP-1559 や SIMD-0110など)
2. アウトオブプロトコル - MEV-BoostによるPBS、Solanaスケジューラーの改善、Jitoオークション

ソラナとイーサリアムの両社にとって、プロトコル内とプロトコル外のメカニズムは共存し、今後共に進化していく可能性が高いと思われます。 それらのバランスは、これらのシステムを設計する際の基本的な問題の 1 つです。 SIMD-0110をめぐる議論は、しばしば2つの相反する見解を中心に展開されます。

1. ジッターを低減するためのスケジューラとネットワークの改善は、ここで説明する問題に十分に対処するため、プロトコル内TFMへの大きな変更は必要ありません。
2. プロトコル外のスケジューラとネットワークの改善は必要ですが、 本質的には不十分です。 プロトコル内の経済的なバックプレッシャーが必要です。

何らかの形での多次元的な資源価格設定は、どちらの場合も明らかに価値があります。 イーサリアムは、 EIP-4844 がBLOBデータを実行市場から分離することで、ベースリソースレベルでこのようなTFMを追求し始めています。 逆に、Solanaは「ローカル手数料市場」を開拓するために、個人アカウントレベルでの多次元リソース価格設定を推進しています。

ここでのTFMの研究は最先端であり、研究者はSolanaやその他のチェーンの手数料の仕組みを改善するための新しく革新的な方法を常に見つけています。 ここで取り上げた提案はすべて、Solanaをさらに効率的でスケーラブルで、ユーザーフレンドリーで、経済的に持続可能なものにするだろうと楽観視しています。

Eclipseのメインネットローンチが近づくにつれ、この既存の作業を、今後数年間確実に進化し続ける私たち自身のTFMにどのように適用するかについて、さらに共有できることを嬉しく思います。 この分野でのメカニズムを実験し、推進していくつもりです。 モジュラーパラダイムの本質的な利点は、異なるエコシステムからの研究とエンジニアリングの相互受粉を容易にすることです。 この実験のペースは今後も増え続け、長期的にはここに建設するすべての人に利益をもたらすでしょう。

免責事項：

1. この記事は[Eclipse]からの転載で、原題は「Solana & Ethereum Transaction Fee Mechanisms: Proposals to Improve Solana's TFM」で、すべての著作権は原作者[Eclipse]に帰属します。 この転載に異議がある場合は、 Gate Learn チームに連絡していただければ、迅速に対応いたします。
2. 免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
3. 記事の他言語への翻訳は、Gate Learnチームによって行われます。 特に明記されていない限り、翻訳された記事を複製、配布、盗用することは禁止されています。