導入: なぜ私の取引が含まれていないのですか？

ソラナのトランザクション旅ユーザーの提出からブロックへの含までが困難です。取引が現在のリーダーに到達したとしても、限られたブロック空間で他の取引と競合しなければなりません。純粋な先着順での取引の含め方はスパムを助長し、一般ユーザーからの高価値な取引をブロックする可能性があります。この問題を解決するためには手数料メカニズムが必要です。

救出に優先手数料？​

優先手数料はこの問題を解決しますか？残念ながら、ほとんどのユーザーには適していません。

このシナリオを想像してみてください。あなたは町の100席の映画館に行きたいのですが、その映画館には異常なチケットシステムがあります:彼らはチケット価格を公表していません。その代わり、いくら払っても構わないと思っているのかを伝えなければなりません。(50ドルだとしましょう。需要が高く、少なくとも100人がより高い価格を提出した場合、運が悪いです。需要が低ければ、あなたは参加しています!落とし穴:劇場が空いていても50ドルを払っています。しかし、発券体験はそれだけではありません。このシステムにはもう一つ奇妙な点があります:家を出る前に、劇場に支払う意思があることを伝えなければなりません。明らかに、このシステムで劇場のチケットを取得することは、平均的な個人にとって潜在的に困難な経験です。一方、裕福で洗練された個人は、チケット価格を正確に見積もることができます。映画館の隣にカメラを設置して、リアルタイムで交通状況を監視できます。このトラフィックと収集された履歴データを使用して、特定の日の需要を推定できます。また、ヘリコプターを購入して、劇場に支払う意思を伝えた後、劇場に早く移動することもできます。このチケットシステムを効果的に使用することは可能ですが、劇場に行きたいほとんどの人にとっては恐ろしい経験です。劇場が混雑しているときは、わざわざ行こうとしない人も多いのではないでしょうか。

同様に、ソラナ取引に必要な「真の」優先手数料を推定するのは困難です。それは非常に変動します高い混雑時には、最近の平均を使用するウォレットは、おそらく必要な手数料を過大評価し、ユーザーに取引の追加料金を支払わせる可能性があります。（そして、高い優先手数料でも、取引まだ含まれていないかもしれませんマルチスレッドの連続ブロック生成の性質によるものです。理論的には、優先手数料はブロックスペースを最適に割り当てることができます。実際には、それらは完全に失敗します。幸いなことに、これらの問題を解決する方法があり、結果としてほとんどのユーザーにとってより安価な取引と含まれる可能性の高い取引が実現します。解決策に入る前に、割り当てようとしているリソースのいくつかの特性を調べてみましょう: ブロックスペース。

ブロックスペース：固定供給、乱高下する需要​

Solanaの取引は、分散型の検証者ネットワークによって独立して検証され、実行されます。これらの検証者は計算リソースに制限があるため、Solanaはブロックごとに使用できる計算リソース（CUsで測定）の合計を制限しています。ブロックスペースの需要が限られた供給を超えると、この固定リソースを競合する取引の間で割り当てる必要があります。

市場は、価格設定を通じてブロックスペースの割り当てを処理することができます。サブミッターにとってより高い効用を持つ取引は、より高い価格を支払うことを望んでいます。しかし、ユーザーがブロックスペースの価格を知らないとき、このメカニズムは機能しません！上記で議論されたように、優先手数料だけでは、ほとんどのユーザーにとって取引価格を見積もりにくく、取引のインクルージョンを保証するものではありません。他のブロックチェーンは、取引手数料メカニズムの実装によってこの問題に取り組んできました（例えば、イーサリアムのEIP-1559, そして多次元の手数料アバランチそしてペナンブラこれらの料金メカニズムは、ネットワークの予測可能な「参加費用」を提供する簡単に見積もれる基本料金を実装しており、この基本料金はトランザクションの取り込みにかかる実際の価格に近づいています。

レビュー：ソラナの手数料今日

ソラナは現在、2つの手数料メカニズムを実装しています: ベース手数料と優先手数料。ベース手数料はネットワークを利用するための「入場料」と考えることができ、優先手数料は1つの取引を他の取引よりも優先させるための追加チップと見なすことができます。ソラナのベース手数料は、通常1つの取引あたりに5000ラムポーツの固定手数料です。その結果、単純な転送を行うユーザーと、計算量の多いオンチェーンゲームをプレイするユーザー、複雑なMEV機会を狙うサーチャーといったユーザーは、同じベース手数料を支払います。したがって、現在の請求されているベース手数料は、取引のリソース使用量（および経済学の文脈での「外部性」）を正確に捉えておらず、結果として、取引のリソース使用量を適切に反映していません。使い古された ブロックスペース.

劇場の例では、同様に固定料金を設定すると、1席を購入する映画ファンと100席全てを購入する映画ファンに対して同じ価格が請求されます。

なぜベース料金メカニズムなのですか？​

ベース料金は、使用されたリソースの関数であるべきです。この消費は現在、計算ユニット（CUs）で測定されていますが、アカウントアクセスなどの他のリソースも含めることができます。ユーザーがより予測可能な参加費用を持つことを望んでいます。動的ベース料金によって与えられます。これらの料金を正しく設定するのは難しいです。（多くの学術研究があります。私たち自身を含む, trying to tackle this!) しかし、ネットワークの混雑による取引の失敗に苦しんだことがある人は、ネットワークが成長するために手数料も正しく設定することが重要であることを知っています。

結局、取引を送信したい多くのユーザーは、優先手数料にいくら支払うべきかわからない。これらの手数料を過大評価すると、彼らは遥かに多額を支払うことになる。これらの手数料を過小評価すると、取引は含まれない。一方、基本手数料については、ユーザーは正確に現在の公表手数料を支払う。私たちは、取引の含有コストを正確に捉えるために、基本手数料を設定したいと考えています。ここでは、すべての取引がスケジューラに到達すると仮定し、計算とアカウントへのアクセスを含む限られたブロックスペースを競合すると仮定します。需要が高い時期には、すべての取引を含めることはできません。この投稿では、ネットワークを混雑させず、取引の含有をより予測可能にするための動的な基本手数料メカニズムに向けた手順を概説します。

傍ら: 優先手数料とMEV​

優先手数料は、リソース消費以外の制約によって制限される特定の機会への支払いとしても捉えることができます。例えば、2人の検索者が同時に特定のローンを清算するための取引を提出した場合、これらの取引のうち1つしか成功して実行されません。ブロック内の最初の取引のみがローンを成功裏に清算します。したがって、優先手数料は、取引の順序付けだけでなく、取引の追加のみを支払うことがよくあります。これらのMEVの機会を捉えるための優先手数料の使用は、この投稿とはやや異なるものです。Solana上のMEVさらなる議論については、この投稿では、基本手数料と取引の包含に焦点を当てます。

最適なブロック

ベース料金を設定する方法について説明する前に、ブロックの選択について架空のメカニズムを考えます：全知のネットワークデザイナーが、ユーザーの幸福度（取引が含まれることによる総効用または「幸福度」）を最大化し、ネットワークのリソース消費コストを差し引いた、取引の制約（例：スマートコントラクトの制約、計算上限など）に従って、それぞれのブロックの取引を選択します。 もちろん、実際にはユーザーの幸福度はネットワークデザイナーによって未知で測定不可能であり、ネットワークデザイナーはブロックを構築しません。 ただし、スケジューラに到達した取引を含む「最適」ブロックのメンタルベンチマークとしてこの問題を使用できます。 当社の目標は、このベンチマークに近づく手数料メカニズムを設計することです。

この架空のブロック構築メカニズムは扱いにくいものですが、実際に実装可能な同等のメカニズムを考え出すことができることがわかりました。この同等のメカニズムは、ネットワークの福祉とユーザーの福祉の間のギャップを最小化するリソース価格を見つけようとします。リソース価格を正しく設定することで、ネットワークがこのユーティリティが何であるかを知らず、ユーザーが明示的に指定しない場合でも、ネットワークへのリソースコストがユーザーとバリデーターによって得られるユーティリティによって正確にバランスが取れるようにインセンティブを調整します。これらの価格は、平均して「最適」なブロックにつながります。したがって、これらの価格の設定にのみ集中できます。(技術的な詳細については、この論文.)

メカニズムに向かって

上記の議論で述べたように、最適なブロックを促進するために価格をどのように設定すればよいのでしょうか？ 最初のアプローチとしては、取引によって使用される計算ユニットごとに固定額を請求することが考えられます。残念ながら、この方法はうまくいきません。需要が低い場合、このCUごとの固定価格はユーザーに取引を送信しないように促し、ブロックは空に近づくかもしれません。需要が高い場合、この固定価格はあまりにも低すぎるかもしれず、ネットワークの混雑を緩和するか、取引の含有コストを正確に近似するためには何の効果もありません（私たちの元の目標！）。したがって、ネットワークの需要に基づいて基本料金を増減する方法と、この需要を見積もる方法が必要です。

ダイナミックベース手数料​

次のステップは、過去の使用状況に基づいてコンピュートユニット当たりの手数料を調整するコントローラを追加することです。たとえば、ブロック当たりの使用目標（つまり、チェーンの「定常状態」の理想的な使用状況）がある場合、利用状況やこの目標からの逸脱に基づいて基本手数料を増減させることができます。多くのメカニズム、例えば、などが含まれます。EIP-1559, このアイデアを実装します。リアルタイムの需要を使用して単一のブロック内でベース料金を動的に更新することに誘惑されるかもしれませんが、または各リーダーに独自の料金更新ルールを選択するように促すかもしれません。しかし、これらの変更はベース料金の予測可能性を低下させ、この料金メカニズムの元々の目的を打ち砕いてしまいます。メカニズムの選択は最終的にユーザーエクスペリエンスを決定します。

幸いにも、Solanaの高速ブロックタイムはベース料金を設定するための攻撃的なアルゴリズムを可能にします。例えば、需要が高い時期に価格を急速に引き上げることができます（例：各完全なブロックごとに価格を倍増させる）、そして需要が収束するにつれて価格をよりゆっくりと引き下げることができます。Solanaの短いブロックタイムにより、価格は依然としてかなり速く低下します。直感的に、特定のリソースが「最大限に活用された」時、ネットワークは大幅に過少料金を請求しており、最適な価格が何であるかに関する情報が少なくなっています。実際には、同様のタイプのアルゴリズムが実践で使用されています。TCP輻輳制御, 無線通信のデータリンク層、そしてマーケットプレイスの最適化.

多次元料金：ローカル料金市場​

前回の議論では、すべてのトランザクションで共有される1つの共通リソースである（グローバル）コンピューティングユニットが考慮されました。 ただし、Solana上のステートアクセスもトランザクションリソースの使用に大きな影響を与えます。 多くのトランザクションが同じステートをアクセスする場合、それらは並列で実行できず、したがってネットワークのスループットが低下します。 当然、これらのトランザクションにはより高い基本料金を支払ってもらいたいと考えており、アカウント別（ローカル）料金市場を奨励しています。（これらの手数料をどのように取得するかという問題は、この投稿の範囲外です。将来の投稿で詳しく説明します。）

具体的な例として、人気のあるNFTドロップを考えてみましょう。アカウントごとの手数料市場がないと、このドロップは他のすべての取引の基本手数料を大幅に増加させます。アカウントごとの手数料があると、NFTを請求する取引のコスト（およびその状態にアクセスするコスト）が増加する可能性がありますが、ローンの担保を補充するなどの他の取引の手数料はほぼ変わらずに残ります。このようなアカウントごとのローカル手数料市場の設計は、ソラナ改善文書のドラフト.

これらの多次元手数料は契約間の相関関係も考慮に入れることができます。例えば、2つのcNFT取引所が多くの同じコレクションを取引する場合、それらの契約は多くの同じアカウントへのアクセスを必要とします。これらの取引所の1つで特定のコレクションの取引量が急増すると、他方の取引所においてもそのコレクションのベース手数料が増加します。なぜなら、基礎となるアカウントの手数料が両方とも増加するためです。このように、「ローカル」なアカウントごとの手数料が「グローバル」な方法で適切に相関し、多次元手数料は同じアプリケーションに対して複数の契約をリリースしてシステムを操作することを防ぎます。

一方、アプリケーション自体の状態が並列化されている場合、手数料は低くなります。この特性は望ましいものであり、並列化により、アクセスする異なるトランザクションが同じアプリケーションに異なるスレッドに配置されるため、基礎となるアカウントが重複しない限り、スループットが向上します(詳細は、ソラナトランザクションのライフサイクル。

これらのローカルな、アカウントごとの手数料市場の価格コントローラーは、コンピュートユニットに使用される価格コントローラーとは異なる場合があります。おそらく、私たちが請求するアカウントには、状態が大幅に争われるまで手数料は一切かかりませんが、その時点で手数料が急速に上昇します。過去の混雑期間の分析は、これらの設計上の決定に情報提供をするのに役立ちます。

代替メカニズム​

上記で議論されたオプションは手数料を設定するための唯一の方法ではありません。ほとんどの基本手数料メカニズムは、おおよそ同じ反復手順に従います: 各ブロックごとに…

1. 最新ブロックのリソース消費を見てください（含まれる取引の結果）;
2. この消費の関数を計算します（例：目標からの偏差）;
3. そして、ステップ2の出力と単純なルールを使用してリソース価格を更新します。

上記で議論された例では、ステップ1のリソースに対する異なる選択肢と、ステップ2および3の更新メカニズムに異なる選択肢を使用しました。リソース利用の優先度を具体的な手数料更新ルールに変換する方法については、この論文.

この多次元的なものは機能しますか？

私たちの学術的な仕事は主に理論的ですが、シンプルなおもちゃの例によると、アカウントなどのリソースを別々に価格設定することでネットワークの効率を向上させ、DoS攻撃や送信されるトランザクションの種類の変更に対してネットワークをより頑丈にすることができます。このセクションでは、単一次元とシンプルな多次元の手数料メカニズムの違いを強調します（セクション4を参照）。私たちの論文詳細について)。

定常状態の挙動

まず、資源1と資源2のほぼ同量のリソースを必要とする取引を持つ多次元手数料メカニズムの定常状態の挙動をシミュレートします。定常状態の挙動では、均一価格設定は資源使用目標からの偏差が大きくなります（左）。効率の低い使用はスループットの低下にも繋がります（右）。

分配のシフト

分布のシフト下でのメカニズムの挙動もテストします。ブロック10に150件の取引を追加し、大量のリソース2を要する。このシナリオは、たとえばNFTのミントで発生する可能性があります。多次元価格設定は、分布がシフトする際（左）にリソース価格を適切に調整することで、大幅にスループットが向上します（右）。

個々のリソース使用状況を見ると、多次元価格設定（左）は短いバースト容量を可能にし、一様価格設定（右）はそうではありません。

結論

ブロックチェーンには有限の計算リソースがあります。ユーザーの需要が高いとき、これらの有限リソースを競合するユーザートランザクションの間で予測可能な方法で割り当てる必要があります。この割り当ては、動的なトランザクションベースの手数料を介して暗黙的に行われるべきです。

この手数料を設定するための理論的に基づいたメカニズムを提案し、需要が高い時にネットワークのスループットを向上させるだけでなく、関連のないトランザクションを切り離し、トランザクションの取り込みコストを予測可能にすることでユーザーエクスペリエンスを向上させることができます。メカニズムの詳細については、以下をチェックしてくださいブレークポイントでのタルンのトークそして私たちの論文!

免責事項：

1. この記事は[から転載されましたアンブラリサーチ元のタイトル「多次元ソラナ手数料への道」を転送します。すべての著作権は元の著者に帰属します@theo_diamandis、@tarunchitra、@0xShitTrader]. If there are objections to this reprint, please contact the Gate Learnチームがすぐに対処します。

2. 責任の免責事項：本記事に表現されている意見は、著者個人のものであり、投資アドバイスを構成するものではありません。

3. 記事の翻訳は Gate Learn チームによって行われます。特に言及がない限り、翻訳された記事のコピー、配布、または盗用は禁止されています。-