交易費用機制已成為瞭解希望交易的使用者與使用者進行交易的“鏈”（或“協定”）之間區塊生產者仲介的主力模型。鑒於能夠使用鏈提供的一些供應，區塊生產者必須仲裁哪些使用者將有能力使用鏈上執行的稀缺資源，以及成本是多少。在乙太坊上，對於成本問題，區塊生產者受到 EIP-1559 費用機制的約束，該機制動態設置底價區塊到區塊，稱為“基本費用”。基本費用是一個價格，以每單位gas表示，使用者交易必須支付該價格才能被包含和執行。用戶可以在基本費用之外提供所謂的“優先費”，以在擁堵時期進一步激勵區塊生產者。

在這份筆記中，我們調查了嵌入式費用市場的問題，即存在於其他費用市場中的費用市場。這個問題在Maryam Bahrani、Pranav Garimidi和Tim Roughgarden的最近一篇論文中以不同的背景進行了討論。在後-MEV世界中的交易手續費機制設計 9在本文中，作者模擬了搜索者的使用，進一步介入用戶和區塊生產者之間的鏈接。區塊生產者從搜索者那裡接收“提示”，這些“提示”以交易的原子束形式體現，可以被鏈包含。搜索者的費用市場由一個稱為MEV（最大可提取價值）的數量的最大化目標驅動。

在我們的設置中，用戶希望訪問鏈，但並不是使用協議可讀的交易來表達他們的需求。相反，用戶生成“操作”，由稱為“打包者”的實體打包，然後發起一個將這些操作打包在一起以進行執行的協議可讀交易。因此，根據EIP-1559費用機制，打包者是鏈的用戶，但實際用戶必須首先獲得被打包者打包才能獲得鏈的包含。換句話說，我們可以把這種設置看作是更大問題的一部分。區塊共創，與（部分）建立者/搜索者以及包含清單一起出現。

我們希望這些動態盡可能透明，以便用戶在與直接上鏈相比，既不會增加過多的認知負擔，也不會被打包者不合理地利用。我們希望能夠取得更強大的結果，這些情況下用戶確實從打包者的中介服務中獲益，當分攤成本使用戶能夠享受更大的福利時。

為了調查直接費用市場及其嵌入式（子）機制之間的區別，我們必須明確界定捆綁者遵守的經濟限制。在接下來的部分中，我們提供了一個捆綁者成本函數的簡單模型，該模型受到實踐的激勵，特別是參與 ERC-4337 協議的捆綁者，我們將進行簡短的重述。

模型

在ERC-4337中捆绑

一個希望通過打包器在鏈上執行某些活動的用戶發出用戶操作（UserOp，或操作）。此UserOp從用戶的錢包發出，例如，在與DApp交互後。一旦UserOp被廣播，某些接收操作的打包器可能決定將其包含在捆綁中。捆綁是一個“外部擁有帳戶”（EOA）元交易，它將包含的UserOps的數據寫入其bundle.calldata字段。打包器向一個區塊生產者發出捆綁，以便將其包含在區塊中（我們將在未來的筆記中討論打包器和區塊生產者之間的關係）。

一旦捆绑包含在區塊中，並且區塊沿著鏈路徑前進，捆綁將與區塊中的其他交易一起執行。基本上，捆綁執行步驟如下：

• 預驗證：打包者的EOA交易將消耗21,000氣體，並且對EntryPoint合約的調用將設置關鍵變量，以跟踪操作循環中操作的執行。
• 操作迴圈 3: 對於包中包含的每個操作，以下兩個步驟將發生:
  • 驗證步驟：UserOps執行包含驗證步驟的操作，這些操作在用戶最初部署的“智能合約錢包”中進行編碼（在初始的UserOp期間）。驗證步驟可能僅檢查簽名，或者執行更複雜的操作以“授予” UserOp 繼續執行的權利。驗證步驟由 op.verificationGasLimit 計量。
  • 執行步驟：UserOp的核心，執行步驟執行op.callData中描述的操作。此步驟也使用op.callGasLimit進行計量。

正如前一個分解所清楚表明的，預驗證步驟僅執行一次，並提供分攤預驗證成本的可能性，跨足所有包括的使用者。當執行包裹時，所有成本（例如，區塊基本費用+由打包者支付給區塊生產者的優先費用）都由打包者支付，打包者必須確保使用者操作足夠補償其所產生的成本。我們在以下部分中對這些陳述進行了精確說明。

捆绑交易的费用市场模型

我们尝试保持与经典费用市场模型一致。希望发出操作的用户t对操作的执行有一些价值vt。我们假设所有操作的大小都相同S（即用于验证和执行步骤的相同燃料），因此我们将所有数量表示为每单位燃料的价格。

用戶通過發出出價bt來表示希望被納入，並隨操作一起進行。目前，我們不假設用戶以特定的語法表達其納入的出價，例如用戶與EIP-1559一樣表達最大費用和優先費用的能力。用戶操作被收集在一個mempool M中，代表這些操作的待定狀態，直到被納入。

EIP-1559 費用市場暴露了稱為“基本費用”的底價 r，捆綁商在執行捆綁包時必須產生該底價。如果捆綁包包含 n 個操作，則捆綁器必須至少花費 n 個 × S × r。此外，由於捆綁消耗「預驗證氣體」，例如一些數量的 F，捆綁器將額外支付 F × r

.捆綁包中包含的操作由集合 B 給出。

捆綁成本功能

我們現在考慮打包商為將其捆綁包含在區塊中而產生的成本。

On-chain成本函數：當基礎費用為r時，包裝器發出包裝B時，會產生一個成本：

打包器问题反映了区块生产者问题，表现在Gate.io[Roughgarden 2021] 3. 在這裡，區塊產生者必須確保提供一些價值μ來補償她將額外的交易包含到他們的區塊中的成本（例如，μ可能補償區塊的額外負載，這會延遲區塊的傳播，從而增加重新組織風險）。區塊級的費用市場必須確保區塊產生者至少得到n × S × μ的總成本補償，如果區塊產生者在他們的區塊中包含n個交易。捆綁器級的費用市場將需要至少補償捆綁器的外部成本

Con-chain(B,r)他們從嵌入其中的更大手續費市場中產生的負責。

ERC-4337提供了一種分攤預驗證燃氣成本之外分攤成本的可能性。 如果所有操作在其驗證步驟中採用相同的簽名方案，則這些操作的簽名可能會聚合2通過捆綁者進行捆綁，使得不再需要在鏈上驗證n個簽名，而可以驗證單個簽名。在這種情況下，捆綁者成本函數將需要考慮捆綁者在執行聚合時所承擔的離鏈成本。在接下來的內容中，我們假設這些成本與操作數成線性關係，這與[Wang et al., 2024] 2，以邊際成本 ω。

我們還考慮了由於聚合節省而減少的每次操作的氣體消耗。聚合時，不需要操作來發佈其簽名，但它們確實需要額外的配對操作。在調用數據成本昂貴但配對操作/計算成本低廉的鏈上，聚合因此提供了每個操作的節省。在這種情況下，我們用 S′ < S 表示交易規模的縮小。 我們還需要考慮預驗證氣體使用增加 F′ > F，它現在包含單個鏈上聚合簽名的發佈和驗證。

聚合成本函數：當基本費用為 r 時，捆綁器發出帶有聚合簽名的捆綁包 B，消耗成本：

在這份筆記中，我們將不再深入討論，但也可以考慮一下，當打包者的捆綁在一個Rollup上結算時，可能需要支出的數據發布成本。我們建議兩種建模方式，並將這個問題留給未來的工作：

• 無論是捆綁者本身負責數據發布（例如，作為一個順序器），因此需要從用戶那裡獲得足夠的資金來支付最終的數據發布成本。
• 或者捆綁級別的費用市場嵌入較大的批次級別費用市場中，通過該滾動公開展示給滾動用戶（包括捆綁者）由於擁擠（例如，基本費用）和最終數據發布成本所需支付的金額。在這種情況下，滾動需要負責平衡他們自己的未來成本和現在的收入。

重新訪問費用市場數量

現在，我們可以正式表達有關捆綁級別費率市場的相關概念，直接從先前的文獻中推導，同時考慮到嵌入其中。

Bundle級別配置規則: (Bundle級別)的配置x根據當前mempool M和基本費用r，決定了束縛者包含在其束縛中的用戶操作集。

捆綁級別付款規則：給定一組選定的操作 B，付款規則會向每個包含的使用者分配費用：

用戶效用函數：

原則上，我們可以允許存在一個燃燒規則 qt(B)，表明打包者可能不會收到所有包含的用戶支付的總額。然而，在本文中我們並未考慮此問題。

（近視）打包程序實用程式函數：

如果對於每個內存池M和基礎費用r，一個近視捆綁者通過遵從分配規則x（即設置B = x（M，r））來最大化其效用，則捆綁級別TFM（x，p）對於近視捆綁者（MBIC）是激勵相容的。

形成多個捆綁

在前面的部分中，我们只考虑了捆绑器发行单个捆绑的可能性。然而，我们可能对捆绑器根据内存池中可用的操作制作多个捆绑的可能性感兴趣。给定内存池M，让P(M)表示内存池的分区集，将每个操作分配给单个捆绑（我们可以假设对于每个分区，有一个索引为0的集合，包含所有未分配给捆绑以供包含的操作）。然后，分配规则返回分区中将操作分配给的集合的索引。

我們可以將由分區 x(M,β) 輸出的捆綁集合表示為 B(x(M,r))。直觀地，這些捆綁是由不屬於索引為 0 的集合組成的操作所組成的。給定捆綁集合 B，支付規則是：

使用者效用函數變為:

並且捆綁工具函數變成：

捆綁器遊戲

將交易納入區塊必須向區塊生產者支付一定數量μ的報酬，該報酬被假定與交易大小成線性關係，例如，[粗糙花園，2021] 3這個數量表示區塊生產者增加額外交易的機會成本，例如，增加他們的傳播延遲，從而增加區塊被重新組織的機會。在權益證明中，即使協議的時間表允許足夠的時間來傳播整個區塊，定時遊戲誘導了“最後一秒”傳播動力學，這再次使該μ參數具有相關性。

無論如何，我們可能會觀察到塊級和捆綁級的成本分攤問題非常不同。在區塊級別，交易不需要知道區塊內還發生了什麼，就可以根據 EIP-1559 設計其包含出價（它可能想知道 MEV 發生了什麼[Bahrani等，2024] 9（但現在我們將把這個問題作為一個獨立的問題來考慮）。在束級別，束的開銷成本不再是交易數量的線性，而是可以通過多個交易來攤銷固定開銷。此外，如果用戶操作的聚合成本在交易數量上是非線性的（例如，有些證明在被證明的大小上實際上是次線性的），則可以提供在許多用戶上分攤總成本的可能性。

這導致以下的遊戲：捆綁方希望用戶按照他們競標最壞情況的方式進行競標，即用戶獨自一人在捆綁中並且必須自行補償全部額外的 gas F。實際上，用戶將面臨在其操作中設置三個相關參數的問題：

• 根據EIP-1559，op.maxPriorityFeePerGas和op.maxFeePerGas可能會根據使用者使用啟發式來設置，即給定其操作計劃預計消耗的某個估計的gas量，使用者會設置這些屬性來校準他們在最壞情況下願意支付的金額（maxFee），以及他們願意補充以支付最終區塊生產者的金額（maxPriority）。但使用者應該如何估計gas量？
• op.preVerificationGas 是 UserOperation 的一個屬性，必須設置為指示用戶操作計劃消耗的“額外Gas”量。在我們的模型中，我們讓
• F表示“固定氣體頂部”。 如果包括n個用戶在捆綁中，則每個用戶應該設置preVerificationGas = F / n。 但是，如果用戶在心中準備他們的操作考慮最壞的情況，他們將設置preVerificationGas = F。

preVerificationGas 然後是用戶通過它來調節成本攤銷的主要向量，通過它用戶競標並嘗試讓組合者考慮其成本攤銷。假設 n 名用戶通過其操作來到市場，並且組合者使他們在最壞情況下競標獨立於組合中。為了這個例子，我們還假設用戶將其 maxPriorityFeePerGas 設置為零。那麼這些 n 名用戶都將 preVerificationGas 設置為 F，並且組合者能夠輸出一個組合來報酬他們：

儘管他們必須承擔成本:

一旦他們在一個區塊中發布捆綁所有n個操作的捆綁。這將使捆綁者獲得利潤 π = (n−1)×F×r。

這種情況可以用兩階段博弈來表示，其中用戶首先生成其用戶操作，然後打包程序決定是否將它們捆綁在一起。我們假設用戶不知道當前待定用戶的數量，因此無法估計打包者攤銷固定成本的真實能力。

在第一階段，用戶發送他們的操作，這些操作提交到他們的屬性，如preVerificationGas。在第二階段，打包器在收到所有使用者事務后決定輸出一個捆綁包或一組捆綁包。有趣的是，即使使用者知道在第一階段有多少其他使用者將玩，即即使n是所有使用者的常識，捆綁器也可能通過威脅玩來強迫用戶設置最壞情況preVerificationGas = F

，即威脅將每個使用者保留在自己的單獨捆綁包中，並向他們收取最大數量的 gas F。

請注意，這個威脅可能並不可信，因為使用者會期望捆綁程式優先播放

即輸出一個包含所有操作的單個捆綁，實現π。但是，用戶可能無法訪問n的真實值，因此無法以一種強制捆綁所有操作的理想方式來設置其preVerificationGas。

理想情況：成本在捆綁包中的用戶之間分攤。悲觀情況：使用者多付錢，成本不分攤.731×755 77.6 KB

這個模型的擴展可以考慮貝葉斯情況，在該情況下，用戶對 n 的分佈有所了解，即他們可以預期在任何給定的時間步驟中會有一些隨機變量 n 的用戶出現，根據某個分佈（例如，泊松到達），即使他們事先不知道隨機變量的結果。這可能會導致效率低下的結果，如下面的例子所示：

Alice 預計除了她自己之外還會有 9 個其他用戶出現，因此她將 preVerificationGas 設置為 1，因為她知道 F = 10。Alice 的值和所有其他使用者的值與他們設置 preVerificationGas = 3 相容，但她試圖為她的包含支付盡可能少的金額。事實證明，市場上只有 5 個使用者，他們都將其 preVerificationGas 設置為 1。對於 F = 10 單位氣體，捆紮器將不會獲得補償，因此捆紮器不會輸出捆綁包，並且使用者收到 0 效用。這顯然是次優的，因為例如，使用者可以全部設置preVerificationGas = 2並獲得1個實用程式（他們願意設置的最大預驗證氣體減去他們支付的實際預驗證氣體）。

未來的工作

就像包裝者遊戲所展示的那樣，一個分配問題面臨著希望被包裝者納入的用戶。在下一個筆記中，我們將討論恢復用戶的“良好UX”以防止他們向一個對其捆綁能力的需求更為了解的包裝者支付過多的不同方法。下一個探索將需要對將用戶、包裝者和建築師/區塊製造者聯繫在一起的市場結構有所了解。

免責聲明：

1. 本文轉載自[ethresear]，所有版權歸原作者所有[大衛·雷佐利]. 如對此轉載有異議，請聯繫Gate Learn團隊，他們會及時處理。
2. 免責聲明：本文所表達的觀點和意見僅代表作者本人，並不構成任何投資建議。
3. 文章的翻譯由Gate Learn團隊完成。除非有特別說明，否則禁止複製、分發或抄襲翻譯後的文章。