取引手数料のメカニズムは、取引を希望するユーザーと、ユーザーが取引を行う「チェーン」(または「プロトコル」)との間のブロックプロデューサーの仲介を理解するための主力モデルとなっています。チェーンによって提供される供給の一部を使用する能力を考えると、ブロックプロデューサーは、どのユーザーがオンチェーン実行の希少なリソースをどの程度のコストで使用できるかを仲裁する必要があります。イーサリアムでは、コストの問題に関して、ブロックプロデューサーはEIP-1559手数料メカニズムによって制約されており、「基本手数料」と呼ばれるブロックごとに最低価格を動的に設定します。基本料金は、ガスの単位あたりで表される価格であり、ユーザートランザクションが含めて実行するために支払う必要があります。ユーザーは、輻輳時にブロックプロデューサーにさらにインセンティブを与えるために、基本料金に加えていわゆる「優先料金」を提供することができます。

このノートでは、埋め込まれた手数料マーケット、つまり他の手数料マーケット内に「存在する」手数料マーケットの問題について調査します。この問題は、最近のMaryam Bahrani、Pranav Garimidi、Tim Roughgardenによる別の文脈で議論されました。MEV世界でのトランザクション手数料メカニズムの設計9本論文では、著者たちは検索者の使用をモデル化し、ユーザーとブロック生産者の間のチェーンへのアクセスをさらに仲介することを提案している。ブロック生産者は、チェーンに含めるべきトランザクションのアトミックバンドルを具現化する「ヒント」を検索者から受け取る。検索者の手数料市場は、MEV（最大抽出可能価値）として知られる量の最大化目的によって駆動されています。

私たちの設定では、ユーザーはチェーンにアクセスしたいと考えていますが、プロトコルで判読可能なトランザクションを使用して要求を表現しません。代わりに、ユーザーは「操作」を生成し、「バンドラー」と呼ばれるエンティティによってバンドルされ、実行に向けて操作をパックするプロトコルで読みやすいトランザクションを開始します。したがって、EIP-1559の料金メカニズムでは、バンドラーはチェーンのユーザーですが、実際のユーザーは、チェーンに含める前に、まずバンドラーのバンドルに含める必要があります。言い換えれば、この設定は、ブロック共同創造, これは（一部の）ビルダー/サーチャーとインクルージョンリストと共に発生します。

私たちの希望は、これらのダイナミクスが可能な限り透明であり、ユーザーが直接チェーン上に行く場合と比べて、認知上の負担やバンドラによる不当な搾取の機会がないようにすることです。我々は、コストが償却されることでユーザーがより大きな福祉を楽しむことができる場合、バンドラの仲介から実際にユーザーが利益を得るより強い結果を期待しています。

直接手数料市場とその内包された(部分)メカニズムの違いを調査するためには、バンドラーが従う経済的制約を明確にする必要があります。次のセクションでは、特にERC-4337プロトコルに参加するバンドラーが行っている実践によって動機付けられたバンドラーコスト関数の単純なモデルを提供します。このモデルについては、簡単にまとめて説明します。

モデル

ERC-4337でのバンドル

バンドラーを介してオンチェーン上で何らかのアクティビティを実行したいユーザーは、ユーザーオペレーション（UserOp、またはオペレーション）を発行します。このUserOpは、ユーザーのウォレットから放出されます。例えば、DAppと対話した後に放出されます。 UserOpがブロードキャストされると、操作を受信したバンドラーは、バンドルに含めることを決定する場合があります。バンドルは、「外部所有アカウント」（EOA）メタトランザクションであり、そのバンドルのcalldataフィールドに含まれるUserOpsのデータを書き込みます。バンドラーは、ブロックプロデューサーに向けてバンドルを発行し、ブロックに含めるようにします（バンドラーとブロックプロデューサーの関係については、後日ノートで説明します）。

Once the bundle is included in the block, and the block makes its way to the chain, the bundle is executed along with other transactions in the block. Essentially, the bundle execution steps are as follows:

• Pre-verification: バンドラーのEOAトランザクションは21,000ガスを消費し、EntryPoint契約への呼び出しは、操作ループ内の操作の実行を追跡するためのキー変数を設定します。
• オペレーションループ3バンドルに含まれる各操作について、以下の2つのステップが行われます:
  • 検証ステップ：UserOpsは、検証ステップを含む操作を実行します。この検証ステップは、最初にユーザーによって展開された「スマートコントラクトウォレット」にエンコードされています（初期のUserOp中に）。検証ステップは、単純に署名をチェックするか、より複雑な操作を実行してUserOpが実行を続けるための「権限」を「付与」することができます。検証ステップはop.verificationGasLimitによって計測されます。
  • 実行ステップ：UserOpの中心部であり、実行ステップはop.callDataで説明された操作を実行します。このステップもop.callGasLimitを使用してメーター付けされます。

前の分解で明らかなように、事前検証ステップは一度だけ実行されるため、含まれるすべてのユーザーの事前検証コストを償却することができます。バンドルが実行されると、すべてのコスト(例:block.basefee + バンドラーがブロックプロデューサーに支払う優先料金)がバンドラーに請求され、バンドラーはユーザー操作で発生したコストを十分に補償する必要があります。次のセクションでは、これらの記述を正確に説明します。

バンドルのための料金市場モデル

我々は、クラシックな手数料市場モデルと一貫性を保とうとしています。操作を発行したいユーザーtは、操作の実行に対する価値vtを持っています。すべての操作は同じサイズS（つまり、検証および実行ステップで使用されるガスが同じ）であると仮定し、したがってすべての数量をガス単位当たりの価格として表現します。

ユーザーは、入札btを発行することで、自分が含まれることを希望していることを表現します。現時点では、ユーザーが含まれることを望むために特定の文法を想定していません。たとえば、ユーザーがEIP-1559で行うように、最大手数料と優先手数料を自分の操作と一緒に表現する能力などです。ユーザーの操作は、未含含の状態を表すメンプールMに収集されます。

EIP-1559の手数料市場は、実行されたバンドルに対してバンドラーが負担しなければならない “ベース料金” として知られる予備価格 r を公開します。バンドルに n 個の操作が含まれる場合、バンドラーは少なくとも n × S × r を費やさなければなりません。さらに、バンドルは “事前検証ガス” を消費するため、ある量 F があるとすると、バンドラーは F × r を追加で支払う必要があります。

.バンドルに含まれる操作は、セット B によって与えられます。

Bundlerのコスト関数

私たちは今、ブンドラーがブロックに彼らのバンドルを含めるために負担するコストを考慮しています。

オンチェーンのコスト関数：ベース料金がrの場合、バンドラがバンドルBを発行すると、コストが発生します:

バンドラーの問題は、ブロックプロデューサーの問題を反映しています[Roughgarden 2021] 3. そこで、ブロックプロデューサーは、彼らのブロックに別のトランザクションを含めるコストを補償する一定の価値μの提供を確保する必要がありました（例えば、μはブロックの余分な負荷を補償し、ブロックの伝播を遅らせ、再編成リスクを増加させるため）。ブロックレベルの手数料市場は、ブロックプロデューサーが彼らのブロックにn個のトランザクションを含めた場合、合計コストn×S×μの少なくとも補償されるようにする必要があります。バンドラーレベルの手数料市場は、外的コストをバンドラーに少なくとも補償する必要があります。

大きな手数料市場に埋め込まれているため、彼らが発生させるコンチェーン（B、r）

ERC-4337は、事前検証ガスコストの共有を超えてコストを償却する可能性を提供します。すべての操作がその検証ステップのために同じ署名スキームを使用する場合、これらの操作の署名はGateされる可能性があります。集計された2バンドラーによって、チェーン上でのn個の署名を検証する代わりに、1つの署名を検証できるようになります。 この場合、バンドラーコスト関数は、集約を実行する際にバンドラーが負担するオフチェーンコストを考慮する必要があります。 以下では、このようなコストが操作の数に対して線形であるという仮定をします。[Wang et al., 2024] 2、限りなく小さいコストωで。

We also account for the reduced gas consumption of each operation, due to savings from the aggregation. When aggreGated, operations are not required to publish their signature, but they do require an additional pairing operation. On chains where calldata cost is expensive, but pairing operations/computation are cheap, aggregation thus provides per-operation savings. In this case, we denote by S′ < S the reduced size of a transaction. We also need to account for the increased pre-verification gas use F′ > F, which now contains the publication and verification of the single on-chain aggreGated signature.

AggreGated cost function: A bundler issuing bundle B with aggreGated signatures when the base fee is r expends a cost:

このノートでは、さらに進まないが、バンドラーがロールアップに決着をつける際に費やすデータの公開コストも考慮することもできる。この問題については、モデリングするための2つの方法を提案し、将来の作業に委ねることをお勧めします。

• バンドラー自体がデータの公開（たとえばシーケンサーとして）に責任を持つため、最終的なデータ公開コストを支払うためにユーザーから必要な資金を得る必要があります。
• または、バンドルレベルの手数料市場が、ロールアップユーザー（バンドラーを含む）が混雑により支払う必要がある金額（例：基本料金）や最終的なデータ公開コストによる手数料を露出させる大規模なバッチレベルの手数料市場に組み込まれています。この場合、ロールアップは、将来のコストと現在の収益をバランスさせる責任があります。

手数料市場の数量を再評価する

バンドルレベルの手数料市場に関連する概念を、以前の文献から直接導出しながら、埋め込みを考慮に入れて形式的に表現することができます。

バンドルレベルの割り当てルール：（バンドルレベルの）割り当てxは、現在のメモリプールMと基本料金rのもとで、バンドラがバンドルに含めるユーザ操作のセットを決定します。

バンドルレベルの支払いルール：選択された操作Bのセットが与えられた場合、支払いルールは各ユーザーに料金を割り当てます:

ユーザーユーティリティ関数：

原則として、バンドラーが含まれるすべてのユーザー支払いの合計額を受け取ることはできないということを表す燃焼ルールqt（B）が存在することを許可することができます。ただし、このノートでは考慮しません。

(近視) バンドラユーティリティ関数:

バンドルレベルTFM（x、p）は、短視眼的なバンドラー（MBIC）のためにインセンティブ互換性がある場合、すべてのメンプールMとベース料金rに対して、短視眼的なバンドラーが割り当てルールxの提案に従うことによって効用を最大化することができます（つまり、B = x（M、r）を設定することによって）。

複数のバンドルを形成する

前のセクションでは、バンドラーが 1 つのバンドルを発行する可能性のみを検討しました。ただし、バンドラーがmempoolで使用可能な操作から複数のバンドルを作成する可能性に関心があるかもしれません。mempool M が与えられた場合、P(M) は mempool のパーティションのセットを表し、各操作を 1 つのバンドルに割り当てます (各パーティションには、包含対象としてバンドルに割り当てられていないすべての操作を含むインデックス 0 のセットがあると仮定できます)。次に、割り当てルールは、操作が割り当てられているパーティション内のセットのインデックスを返します。

パーティションx(M,β)によって出力されるバンドルの集合をB(x(M,r))と書くことができます。直感的には、これらのバンドルは、インデックス0に属さない操作から構成されています。バンドルBの集合が与えられた場合、支払いルールは次のようになります:

ユーザーユーティリティ関数は次のようになります:

そして、bundlerユーティリティ関数は次のようになります:

The bundler game

ブロック内のトランザクションの追加には、例えばトランザクションサイズに比例する量μがブロックプロデューサーに報酬として支払われる必要があります。[Roughgarden, 2021] 3. この数量は、ブロックプロデューサーが追加のトランザクションを自分のブロックに追加するための機会費用を示しています。つまり、ゴシップ遅延を増やし、ブロックの再編成の可能性を高めることです。 Proof-of-Stakeでは、プロトコルのスケジュールによって十分な時間があるため、完全なブロックを伝播することができます。タイミングゲーム「最後の瞬間」の伝播ダイナミクスを引き起こし、再びこのμパラメータを関連付けました。

いずれにせよ、ブロックレベルとバンドルレベルのコストシェアリングの問題は非常に異なることがわかります。ブロックレベルでは、トランザクションはEIP-1559に従ってその含まれる入札を考案するために、ブロック内で何が起こっているかを知る必要はありません（MEVに関しては何が起こっているかを知りたいかもしれません）。[Bahrani et al., 2024] 9ですが、今のところは別の問題と見なします)。バンドル・レベルでは、バンドル間接費はトランザクション数に比例しなくなりますが、固定間接費は多くのトランザクションによって償却される可能性があります。さらに、ユーザー操作の集計コストがトランザクション数において非線形である場合(たとえば、一部の証明は、証明されるサイズにおいて実質的にサブ線形である)、多くのユーザーにわたって総コストを償却する可能性を提供する。

これにより、次のゲームが生じます：バンドラは、ユーザーがバンドル内で一人であるかのように最悪の場合に入札することを望んでおり、ユーザー自身が完全なオーバーヘッドガスFを自己補償する必要があります。実際には、ユーザーは操作に関連する3つの重要なパラメーターを設定する問題に直面します：

• op.maxPriorityFeePerGasとop.maxFeePerGasは、EIP-1559の下でユーザーが使用するヒューリスティックに従って設定することができます。つまり、ユーザーの操作が消費する予定のガス量を推定し、ユーザーはこれらの属性を設定して、最悪の場合に支払いたい金額（maxFee）と、最終的なブロックプロデューサーに支払うために追加で支払いたい金額（maxPriority）を調整します。しかし、ユーザーはどのようにガスを推定すればよいでしょうか？
• op.preVerificationGasは、ユーザーの操作が消費する「追加のガス」の量を示すために設定する必要があるUserOperationの属性です。モデルでは、
• Fは、この「固定ガスオーバーヘッド」を示します。n 人のユーザーがバンドルに含まれている場合、各ユーザーは preVerificationGas = F / n を設定する必要があります。ただし、ユーザーが最悪のシナリオを念頭に置いて操作を準備する場合は、preVerificationGas = F を設定します。

preVerificationGasは、その後、ユーザーが入札し、バンドラーによるコストの償却を考慮するための主要な手段です。n人のユーザーがそれぞれの操作で市場に参入し、すべてがバンドラーによってバンドル内で一人きりの最悪のケースで入札することを納得していると仮定します。この例のために、ユーザーは全員、maxPriorityFeePerGasをゼロに設定していると仮定します。その後、これらのn人のユーザーはすべてpreVerificationGas = Fを設定しており、バンドラーはそれらを報酬として出力することができます:

彼らはコストを負担しなければならないが、

一度にすべてのn操作を1つのブロックにまとめて公開したら、これによってバンドラーは利益π = (n−1)×F×rを得ることができます。

この状況は、ユーザーがまずユーザー操作を行い、その後にバンドラがそれらをバンドルするという二段階のゲームによって表現される可能性があります。ユーザーは現在の保留中のユーザー数についての情報を持っていないため、バンドラが固定費を償却する能力を正確に評価することはできません。

最初の段階では、ユーザーは操作を送信し、それによってpreVerificationGasなどの属性にコミットします。第二段階では、バンドラーはすべてのユーザートランザクションを受け取った後、バンドルまたはバンドルのセットを出力することを決定します。興味深いことに、ユーザーが最初の段階で他のユーザーが何人プレイするかを知っている場合でも、つまり、すべてのユーザーにとってnが共通の知識である場合でも、バンドラーはユーザーを脅して最悪の場合のpreVerificationGas = Fを設定させることができるかもしれません。

つまり、各ユーザーを独自のバンドルに保管し、最大限のガス料金を請求する脅迫をすることです。

この脅威は信憑性がないかもしれませんが、ユーザーはバンドラがプレイを優先することを期待しています。注意してください

, つまり、すべての操作を含む単一のバンドルを出力し、πを実現します。ただし、ユーザーはnの真の値にアクセスできない場合があり、そのため、それらすべてを理想的にバンドルするようにpreVerificationGasを設定することができません。

理想的なケース:コストはバンドル内のユーザー間で分割されます。悲観的なケース:ユーザーは過払いで、コストは分割されません.731×755 77.6 KB

このモデルの拡張では、ユーザーがnに関する分布にアクセスできるベイズの場合を考慮することができます。つまり、ある時点でn人のユーザーが現れることをいくつかの分布（例：ポアソン到着）に従って予測することができますが、ランダム変数の結果を事前に知らなくても良いです。次の例で示すように、これは非効率な結果につながる可能性があります。

Alice は、自分以外に 9 人のユーザーが現れると予想しているため、F = 10 がわかっているので、preVerificationGas を 1 に設定します。Alice の値と他のすべてのユーザーの値は、preVerificationGas = 3 を設定すると互換性がありますが、Alice は自分の含めるために可能な限り最小限の金額を支払おうとします。結局のところ、市場に出回っているのは 5 人のユーザーのみで、全員が preVerificationGas を 1 に設定しています。バンドラーは F = 10 単位のガスに対して補償されないため、バンドラーはバンドルを出力せず、ユーザーは 0 ユーティリティを受け取ります。たとえば、ユーザー全員が preVerificationGas = 2 を設定し、1 つのユーティリティ (設定する予定の最大 preVerificationGas から、実際に支払った preVerificationGas を差し引いたもの) を受け取ることができるため、これは明らかに最適ではありません。

将来の仕事

バンドラーゲームが示すように、バンドラーに含まれることを望むユーザーは割り当ての問題に直面します。次のノートでは、バンドル容量の需要についてよりよく知っているバンドラーに過剰に支払うことを防ぐために、ユーザーの「良いUX」を回復するためのさまざまなアプローチについて説明します。次の調査では、ユーザー、バンドラー、ビルダー/ブロックプロデューサーを結びつける市場構造を理解する必要があります。

免責事項：

1. この記事は[から転載されましたエスレシア]、すべての著作権は原著作者に帰属します[DavideRezzoli]. この転載に異議がある場合は、お問い合わせください。Gate Learn(ゲート・ラーン)チームにお任せいただければ、迅速に対応いたします。
2. 免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
3. 他の言語への記事の翻訳はGate Learnチームによって行われます。特に言及されていない限り、翻訳された記事のコピー、配布、または盗用は禁止されています。