見出し画像

理論と実践におけるソラナ料金

原題:https://www.helius.dev/blog/solana-fees-in-theory-and-practice


はじめに

Solanaの料金体系は、需要と供給の不均一なショックのバランスを取りながら、ネットワークのパフォーマンスを維持するように設計されています。ブロックチェーンの料金は、スパムを防止し、バリデーターにインセンティブを与えることを目的としています。Solanaでは、これらの料金の一部はネットワーク条件に基づいて動的に調整され、ネットワークは特定の時間に需要をより正確に価格設定できます。
Solanaの料金はホットなトピックであり、“ローカル料金市場”は、Solanaがブロックスペースと特定のアカウントをより正確に価格設定するための表現力を提供します。現在の実装は完全とはほど遠いですが、アカウントごとの注文については緩やかな保証があります。ソラナはまだ初期段階にありますが、ネットワークでのより多くの利害関係と活動には、プロトコル内の変更による1次および2次の影響のより深い議論と分析が必要です, 料金モデルの変更など。
この作品では、理論的には料金と、それらがどのように連鎖的に現れるかを説明します。一部の人々は、QoSのステーク加重設計で集中化され、集中力を備えているとSolanaを批判し タービン, これが実際にどのように現れるかには、長年にわたって明確な不一致がありました。同様に、私たちは、チェーン上の行動によって料金がどのように現れるかを包括的に分析することを目指しています。

理論上の料金

ソラナの料金体系は、基本料金と優先料金の2つのコンポーネントで構成されています。大まかに言えば、各料金コンポーネントは理想的には次の目的を果たします:

  • 基本料金: ネットワークのリソースを利用する権利

  • 優先料: リーダーのトランザクションキューで順序を決定します

基本料金

現在、署名ごとに0.00005 SOL(5,000ランポート)に設定されている基本料金は、トランザクションコストの基礎を形成します。これは、ネットワークのリソースを使用する権利のためにアドレスが支払う料金です。これは、トランザクションの実行に使用された実際のリソースの量に関係なく(またはトランザクションが実行された場合でも)、ネットワークに前払いされる単一の一括支払いです。Solanaトランザクションは、指定された数の計算単位(CU)を事前に要求し、この数を超えるとトランザクションは失敗します。つまり、開発者は現在、コンピューティングユニットの要求を最小限に抑えるための金銭的インセンティブをほとんどまたはまったく持っていません。

優先料金

さらに、ユーザーは優先料金を支払って、ブロック内に含まれる可能性が高くなるようにトランザクションを促進できます。これは、ユーザーが優先度を支払うための非決定的な保証です。トランザクションの決定論を改善するための取り組みが進行中であり、1.18に着陸すると予想されるスケジューラの大幅な変更があります。

補足として、投票トランザクションには関連する優先料金がなく、標準のトランザクションとは異なる扱いを受けます。

検証者が優先手数料を伴うトランザクションを含めるインセンティブは、実行時間外に存在します。リーダーは、ブロック内にトランザクションを含めるための優先料金の50%を収集し、残りの50%は燃やされます。

今日、ほとんどのバリデーター(80%+)は、Solana LabsまたはJito-Solanaクライアントの未変更バージョンを実行しています。これは、これらのバリデーターがデフォルトのスケジューラーに“ブロック生成”をアウトソーシングしていることを意味します(Solanaの一部の人々は、“ブロック注文”を“ブロック生成”と呼んでいます。イーサリアム)。一部のチームはクライアントコードを変更し、注文フローをより詳細に制御できるより複雑なスケジューラーを実装しました。これにより、トランザクションを再注文またはサンドイッチしてMEVを抽出できるチームもあります。

優先手数料不確定

スケジューラーの現在の実装は、優先度の高い料金のトランザクションが特定のブロックに含まれることを保証しません。代わりに、優先手数料を伴うトランザクションが特定のブロックに含まれる可能性が高いことを大まかに保証します。スケジューラーの現在の実装では、4つの実行コアが制定されています(2つの追加コアは投票トランザクション用に予約されています)。

各スレッドは独自のキューを操作し、他のスレッドで処理されているパケットを知らずにパケットに個別に優先順位を付けます。各スレッドは、開始から終了まで継続的に循環し、トランザクションをロックして実行しようとします。スレッドが現在のサイクルを完了すると、より多くのパケットが収集され、サイクルが再び開始されます。

その結果、1つのスレッドのキューの上部で優先度の高いトランザクションを同時に実行できます, 別のスレッドが、同じアカウントを含むトランザクションを処理することにより、独自のキューを締結している可能性があります。

スケジューラーの現在および将来の実装の具体的な詳細は、別の部分で説明されます。優先料金は スレッド内 (独自のレーン内)ではなく スレッド間 (レーン間)、スケジューラーが完全ではなく、“ジッター”を示していることを理解するのに十分です。

実際の料金

着陸取引(Landing Transactions)

手数料は、トランザクションが着陸するかどうかの主要な要因ですが、唯一の決定要因ではありません。たとえば、UDPネットワークパケットが失われたために、トランザクションが着陸しない場合があります。ネットワークアクティビティが高い期間中、バリデーターは管理できるよりも多くのトランザクションが殺到する可能性があります。バリデーターには過剰なトランザクションを渡す機能がありますが tpu_forwards メカニズム、それらは有限の量のデータしか処理できず、各トランザクションは有限の回数だけ中継できます(ブロックハッシュが期限切れになるまで)。ステーキ加重 サービスの質 より高いステークを持つアドレスのこれらの問題のいくつかを軽減し、予約された帯域幅を提供し、トランザクションが含まれる可能性を高めます。

トランザクションのドロップオフのあまり一般的に議論されていない2つの理由も存在します。1つ目は、RPCプール内の不一致です。RPCプールの1つのセグメントが他のセグメントよりも先に競争し、調整の問題を引き起こす可能性があります。たとえば、トランザクションの最近のBlockhashがより更新されたセグメントから取得され、より遅いセグメントに送信された場合、後者は更新されたブロックハッシュを認識せず、その結果, トランザクションを破棄します。開発者は、sendTransaction関数でプリフライトチェックが有効になっている場合、提出時にそのような問題を見つけることができます。

一時的なネットワークフォークを中心に別の問題が発生します。バリデーターがブロックの処理に遅れをとっている場合、トランザクションは正規化されない少数派のフォークになる可能性があります。クライアントがこの少数フォークにのみ存在するトランザクションでrecastBlockhashを参照し、トランザクションを処理する前にネットワークがそのフォークを放棄すると, ブロックハッシュが見つからないため、トランザクションはドロップされます。

ソラナに関する合意 https://www.helius.dev/blog/consensus-on-solana

優先料金

実際には、優先料は完全とはほど遠いものの、マクロ規模で働いているという証拠が見られます。優先料金を含むトランザクションはブロックに含まれる可能性が高く、優先度の高い料金を設定するトランザクションは、含まれる可能性が高くなります。

Helius RPCデータに基づくと、優先手数料を伴うトランザクションは着陸する可能性が高く、着陸すると、全体的に速く着陸することがわかります:

優先手数料を伴う真の=トランザクション、y軸=トランザクションの割合

1月21日、mockJUPエアドロップによる平均優先料金の急上昇があり、来週の実際のJUPエアドロップに備えました。ブロックスペースの需要には大きな変化がありましたが、実際のユーザーがトランザクションの土地レートと時間に関して感じた変化は比較的ほとんどありませんでした。

Dune

このUXは主にSolana RPCメソッドによってサポートされています getRecentPrioritizationFees, 開発者がトランザクションに追加する優先料金を正確に決定できるようにします。エンドポイントは、それぞれのアドレスと入力パラメーターを使用して少なくとも1つのトランザクションを正常に着陸させるために使用された過去150ブロックの優先料金のリストを返します。これは、優先料金に設定する必要がある最小値のスナップショットを提供し、その有用性は比較的制限されています。または、Heliusは 優先料金API これは、より優先度の高い料金の見積もりを提供するために追加の計算を行います。

優先料金は理論的には意図したとおりに機能しますが、1.18での今後のスケジューラーの変更により、スケジューラーの改善により、トランザクションを含めるための決定論がさらに追加されます。これにより、主要な戦略ではトランザクションを含めるためにチェーンをスパムする必要がなくなるため、チェーンに着地するスパムの量が減少します。

基本料金

ソラナの基本料金は明らかに低すぎ、ブロックは飽和していて動的ではないため、基本料金がブロックスペースの市場清算価格に達するのを防ぎます。Ethereumでは、動的基本料金はEIP-1559 ’のコントローラーメカニズムによって達成されます。これは、最近のブロックを調べ、50%の使用率を対象としています。

ソラナは、署名ごとに5,000のランポートを静的に価格設定します(通常、トランザクションごとに1つの署名)。これは、基本料金がブロックスペースとバリデーターリソースの使用に対する需要の変化を表さないため、効果のない料金であることを意味します。これにより、優先料金が効果的に外部化され、優先料金の市場ベースの代替となり、バリデーターが含まれない可能性が高い追加のトランザクションを処理するため、ネットワークがさらに混雑します。さらに、主要な戦略は、含めるための優先手数料を最小限に抑えて多数のトランザクションを提出することです。これにより、すべてのネットワーク参加者がUXに大きな外部性を課します。

dune

インセンティブ

RPCは、最小限のコストで最高の取引包含率を提供するために、正しい情報を下流に中継するインセンティブを与えられる。Solanaのメカニズムの多くはステークによって重み付けされているため、ステーク上位のバリデータと統合することで、RPCはネットワークの現状をより正確に把握することができる。大きなステークを持つバリデーターと統合された RPC が取引処理の効率と信頼性を高めることで、トップステークバリデーターの地位をさらに強固なものにするフィードバックループが生まれる可能性があるという共生関係が生まれる。

さらに、RPC(現在はステークスゼロのバリデーターとして扱われている)は、それ自体がステークのウェイトを持つようになる。RPC 自身は、バリデータと提携することなく、ステークを集めることができる。アプリケーション自身が独自のバリデーターを運営し、より垂直統合を進め、エンドユーザーエクスペリエンスとトランザクション/MEVサプライチェーンに対するさらなるコントロールを可能にすることは珍しくない。

株式を集中化する傾向を示唆する経済的インセンティブにもかかわらず、ソラナは株式加重利益のための資本の大規模な集積を見ていません。これはいくつかの理由である可能性があります:

  • 個人は、主にソラナの文化と社会の層によって推進される、ネットワークの長期的な利益のための主要な戦略として、地方分権を最大化することを考えるかもしれません。

  • ソラナの参加者は、主に小売業とプロシューマーであり、専門企業ほど収益に敏感ではありません。活動レベルと絶対リターンが増加するにつれて、これは参加者への調整を刺激する可能性があります’人口統計とレート感度。

  • 個人は、差別化された製品のマーケティングにおいてうまく調整されていません。

結論

この記事では、Solanaの手数料メカニズムのハイレベルな理論と、それがオンチェーンのネットワークにどのような影響を与えるかを詳しく説明した。手数料はインセンティブを促進し、それは大きな外部性を持ち、Solana上のすべての参加者の行動に影響を与える。

ソラナの基本料金や優先料金のような仕組みは、現在の実施状況では完全ではない。基本料金は調整不可能で、現在の需給均衡を反映していない。そのため、ネットワークの混雑や非効率なリソース配分といった問題が生じる。優先料金は、現在のスケジューラの実装に起因する不確定性を示す。予想されるスケジューラの変更のような将来のアップデートは、トランザクション処理に決定論と効率性をもたらし、現在観察されているオンチェーンの振る舞いを再形成する可能性がある。

これは、アカウントへのアクセスを任意にロックすることで、トランザクションのコストをより正確に値付けすることを目的としている。さらに、状態へのアクセスをより正確に値付けする動的な基本料金メカニズムについても議論が行われている。

手数料、バリデータ、RPC の相互作用は、複雑なインセンティ ブの網の目のようなものである。バリデーターとRPCは、理論的には、統合して出資比率を高めるインセンティブを与えられ、中央集権化の懸念につながる可能性がある。しかし現実には、Solanaは分散化されたオペレーターとステークを維持できている。これは、コミュニティ主導のガバナンス、技術的な障壁、経済的な逆インセンティブ、現在のところリターンが主因ではない最適化機能によるものと思われる。分散型のオペレーターと株式のセットを維持することに成功しました。これは、おそらくコミュニティ主導のガバナンス、技術的障壁、経済的反インセンティブによるものです, 現在最適化機能は、主にリターンによって駆動されていません。


以上

最後にdiscordの通知がわかりやすい説明がされています。

これはRPCが原因ではなく、純粋にSolanaのブロックスペースがボットでいっぱいになっていることと、優先手数料が決定論的に機能していないことが原因です。
https://www.helius.dev/blog/solana-fees-in-theory-and-practice。
ヒント: ネットワークのパフォーマンスはこちらで見ることができます https://dune.com/ilemi/solana-compute?hours_tf5897=24


この記事が気に入ったらサポートをしてみませんか?