交易费用机制已经成为理解区块生产者如何在希望交易的用户与他们所使用的“链”（或“协议”）之间充当中介的关键模型。区块生产者需要决定哪些用户可以使用链上执行的稀缺资源，以及使用这些资源的费用。在以太坊中，关于费用的设定，区块生产者受到EIP-1559费用机制的影响，该机制会动态调整每个区块的基础费用。基础费用是用户交易为了被处理和执行而必须支付的气体费用。用户还可以在基础费用之外支付额外的“优先费用”，以在网络拥堵时进一步激励区块生产者。

在这篇文章中，我们将继续探讨嵌入式费用市场的概念，这一话题在Maryam Bahrani、Pranav Garimidi和Tim Roughgarden的最新论文《后MEV世界中的交易费用机制设计》中也有涉及。在这篇论文中，作者讨论了搜索者的角色，搜索者在用户和区块生产者之间中介了对链的访问。区块生产者会收到来自搜索者的“提示”，这些提示以原子交易捆绑的形式出现，供链上处理。搜索者的费用市场是以最大化一个叫做MEV（最大可提取价值）的目标为驱动的。

在我们的设定中，用户希望访问区块链，但他们并不通过协议可读的交易来表达需求。相反，用户会生成“操作”，这些操作会被称为“打包者”的实体进行打包，打包者随后会创建一个将这些操作打包在一起的协议可读交易，以便执行。因此，在EIP-1559费用机制下，打包者实际上是链的用户，但真实的用户必须先获得打包者的打包，才能在链上被包含。换句话说，我们可以将这种情况视为区块共同创建这一更大问题的一部分，这与（部分）构建者/搜索者和包含列表有关。

我们希望这些动态尽可能透明，以确保用户在与打包者互动时不会比直接上链承受更多的认知负担或被不当利用的风险。我们还希望在某些情况下，用户能够从打包者的中介中获益，尤其是在摊销成本使得用户能享受更大福利时。

为了探讨直接费用市场与其嵌入（子）机制之间的区别，我们需要明确打包者所遵循的经济约束。在接下来的部分中，我们将提供一个简单的打包者成本函数模型，这一模型受实际操作的启发，特别是参与ERC-4337协议的打包者，我们将对此进行简要回顾。

模型

ERC-4337 中的打包

希望通过打包者在区块链上执行某项活动的用户，会发出一个用户操作（User Operation，简称UserOp或操作）。这个UserOp是从用户的钱包中发出的，例如在与去中心化应用（DApp）互动后。一旦UserOp被广播，某个打包者可能会决定将其纳入一个打包中。这个打包是一个“外部拥有账户”（EOA）的元交易，它将所有包含的UserOps的数据写入其bundle.calldata字段。打包者会将这个打包提交给区块生产者，以便将其包含在一个区块中（我们将在后续的笔记中讨论打包者与区块生产者之间的关系）。

一旦打包被纳入区块，并且该区块被添加到链上，打包将与区块中的其他交易一起被执行。打包执行的基本步骤如下：

• 预验证：打包者的EOA交易将消耗21,000气体，调用EntryPoint合约将设置一些关键变量，以跟踪操作循环中的执行情况。
• 操作循环：对于打包中的每个操作，以下两个步骤会依次进行：
  • 验证步骤：UserOps会执行包含验证步骤的操作，这些步骤编码在用户最初部署的“智能合约钱包”中（在初始UserOp期间）。验证步骤可以简单地检查签名，或者执行更复杂的操作以“授予”UserOp继续执行的权利。验证步骤的气体限制由op.verificationGasLimit设定。
  • 执行步骤：这是UserOp的核心，执行步骤会根据op.callData中的内容执行相应的操作。这个步骤也会受到气体限制的控制，使用op.callGasLimit进行限制。

如前所述，预验证步骤只需执行一次，这样可以将预验证的成本摊销到所有参与的用户身上。当打包被执行时，所有费用（例如，block.basefee和打包者支付给区块生产者的优先费用）都会由打包者承担，打包者必须确保用户操作能够足够补偿她所产生的成本。我们将在下一部分中对此进行详细说明。

打包的费用市场模型

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

用户通过发送一个出价 ( bt ) 来表达他们希望被纳入打包的意愿，并与他们的操作一起提交。当前，我们不假设用户表达其出价的特定方式，例如，用户是否能够像在EIP-1559中那样，表达最大费用和优先费用。用户操作会被收集在一个内存池 ( M ) 中，这表示这些操作在被包含之前的待处理状态。

EIP-1559费用市场引入了一个称为“基础费用”（base fee）的保留价格r ，打包者在其打包被执行时必须承担这一费用。如果打包中包含 n 个操作，打包者至少需要支付 (n × S × r.)。此外，由于打包还会消耗“预验证气体”，假设这一数量为F，打包者还需额外支付 ( F × r)。打包中包含的操作由集合B 定义。

打包者成本函数

我们现在考虑打包者在其打包被纳入区块时所产生的成本。

链上成本函数：当基础费用为 r 时，发出打包 B 的打包者所需承担的成本为：

打包者所面临的问题类似于[Roughgarden 2021]中描述的区块生产者问题。在那篇文章中，区块生产者必须确保提供一定的价值μ，以补偿将额外交易纳入其区块的成本（例如，μ 可以补偿区块的额外负载，这会延缓传播并增加重组风险）。因此，区块级费用市场必须确保区块生产者至少能够获得总成本n×S×μ 的补偿，如果区块中包含

n个交易的话。打包者级费用市场则需要至少补偿打包者因嵌入在更大费用市场中而产生的外部成本Con-chain(B,r)。

ERC-4337提供了摊销成本的可能性，超出共享预验证气体成本的范围。如果所有操作在验证步骤中使用相同的签名方案，打包者可以将这些操作的签名 聚合，这样就可以用一个签名替代在链上验证n个签名。在这种情况下，打包者的成本函数需要考虑在执行聚合时产生的链下成本。我们假设这些成本与操作数量成线性关系，边际成本为ω，这一假设与[Wang et al., 2024]的观点相似。

我们还需要考虑由于聚合带来的每个操作气体消耗的减少。当操作被聚合时，它们不再需要发布各自的签名，但会增加一个配对操作的需求。在数据调用成本较高而配对操作/计算成本较低的链上，聚合能够为每个操作节省成本。在这种情况下，我们用

S′<S表示交易的减少大小。同时，我们需要考虑增加的预验证气体使用量F′>F，这包含了单个链上聚合签名的发布和验证。

聚合成本函数：当基础费用为r时，发出带有聚合签名的打包B 的打包者所需承担的成本为：

在此讨论中，我们不再深入，但人们也可以考虑打包者在其打包在汇总上结算时可能需要支出的数据发布成本。我们提出两种建模方式，并将此问题留待未来研究：

• 打包者自己负责数据发布（例如，作为排序者），因此需要从用户那里获得支付潜在数据发布成本的必要资金。
• 打包级费用市场嵌入在更大的批处理级费用市场中，通过该市场，汇总向汇总用户（包括打包者）公开因拥堵（例如，基础费用）和潜在数据发布成本而需要支付的金额。在这种情况下，汇总负责平衡其未来成本与当前收入。

重新审视费用市场数量

我们现在可以正式阐述与打包级费用市场相关的概念，这些概念直接源自于之前的文献，并考虑了嵌入的因素。

打包级分配规则：一个打包级的分配x确定了在当前内存池M 和基础费用r的情况下，打包者将哪些用户操作纳入其打包中。

打包级支付规则：根据选定的操作集合B，支付规则为每个被包含的用户分配相应的费用。

用户效用函数：

原则上，我们可以考虑一个燃烧规则 qt(B) ，它表明打包者可能无法收到所有用户支付的总额。不过，在此讨论中我们不予考虑。

（短视的）打包者效用函数：

如果对于每个 mempool M 和基本费用 r，一个近视捆绑器通过遵循分配规则 x 的建议（即设置B = x(M,r))。

一个打包级的交易费用机制（TFM）(x,p)对于短视打包者（MBIC）是激励兼容的，意味着对于每个内存池M和基础费用r，短视打包者通过遵循分配规则x 的建议（即设置B=x(M,r)来最大化其效用。

形成多个打包

在前面的部分中，我们只讨论了打包者创建单个打包的情况。然而，我们可能会对打包者如何利用内存池中的可用操作来形成多个打包感兴趣。给定内存池M，我们用

P(M)来表示内存池的所有可能分区，这些分区将每个操作分配到一个独立的打包中（我们可以假设每个分区都有一个索引为 0 的集合，包含所有未被分配到任何打包中的操作）。分配规则会返回该操作被分配到的分区集合的索引。

我们可以将分区x(M,β)输出的打包集合表示为

B(x(M,r))。直观地说，这些打包由那些不在索引为 0 的集合中的操作组成。给定一组打包B，相应的支付规则则为：

用户效用函数变为：

而打包者效用函数变为：

打包者游戏

将交易包含在区块中必须向区块生产者支付一定的费用μ，这一费用通常与交易大小成线性关系，例如在[Roughgarden, 2021]中提到的。这一费用反映了区块生产者在其区块中添加额外交易的机会成本，比如增加传播延迟，从而提高区块被重组的风险。在权益证明机制中，尽管协议安排了足够的时间来传播完整的区块，但 时间博弈 导致了“最后一刻”的传播动态，使得这个μ参数再次变得重要。

无论如何，我们可以看到，区块级和打包级的成本分摊问题是截然不同的。在区块级，交易在制定其纳入出价时不需要了解区块内部的其他事务（虽然它可能会关心与 MEV [Bahrani et al., 2024] 相关的情况，但我们暂时将其视为一个独立的问题）。而在打包级，打包的间接成本不再是交易数量的线性函数，固定的间接成本可以通过多笔交易来分摊。此外，如果用户操作的聚合成本在交易数量上是非线性的（例如，一些证明在证明的大小上实际上是次线性的），那么就可以为多个用户分摊总成本。

这就引出了一个博弈：打包者希望用户在出价时像是在最坏情况下出价一样，即用户在打包中是唯一的，必须自己承担全部的间接燃气费用F。实际上，用户需要面对设置三个相关参数的问题：

• op.maxPriorityFeePerGas 和 op.maxFeePerGas 可以根据用户在 EIP-1559 下所采用的启发式方法来设定。也就是说，用户会根据其操作预计消耗的燃气量来调整这些属性，以便确定在最坏情况下他们愿意支付的最高费用（maxFee），以及他们愿意额外支付给区块生产者的费用（maxPriority）。那么，用户应该如何估算燃气消耗呢？
• op.preVerificationGas 是用户操作中的一个属性，必须设定以表示用户操作计划消耗的“额外燃气”量。在我们的模型中，我们用 F来表示这个“固定燃气开销”。如果打包中有 n个用户，每个用户应该设置 preVerificationGas = F / n。然而，如果用户在准备操作时考虑到最坏情况，他们则会将 preVerificationGas 设置为 F。

preVerificationGas 是用户调节出价的主要手段，并试图考虑打包者的成本摊销。假设有 n个用户带着他们的操作进入市场，所有用户都被打包者说服在最坏情况下出价，即认为自己是打包中唯一的用户。为了简化这个例子，我们还假设用户将 maxPriorityFeePerGas 设置为零。在这种情况下，这 n个用户都设置 preVerificationGas = F，而打包者能够生成一个打包，使得他们获得的报酬为：

同时，他们必须承担的成本为：

一旦他们将所有n个操作一起打包并发布到区块中。这使得打包者获得的利润为 π = (n−1)×F×r。

这一情形可以看作是一个两阶段的博弈：用户首先生成他们的操作，随后打包者决定如何打包这些操作。我们假设用户并不知道当前有多少待处理的用户，因此无法准确估计打包者摊销固定成本的能力。

在第一阶段，用户提交他们的操作，并承诺其属性，例如 preVerificationGas。在第二阶段，打包者在收到所有用户交易后决定生成一个打包或一组打包。有趣的是，即使用户知道在第一阶段将有多少其他用户参与，即使 n 是所有用户的共同知识，打包者仍可能通过威胁用户来迫使他们设置最坏情况下的 preVerificationGas = F，

，即威胁将每个用户单独保留在自己的打包中，并向他们收取最大燃气费用 F。

需要注意的是，这种威胁可能并不具备可信性， 因为用户会认为

，即打包者更倾向于输出一个包含所有操作的单一打包，以实现利润 π。然而，由于用户可能无法获知 n 的真实值，他们无法以强制打包者理想地将所有用户打包在一起的方式来设置他们的 preVerificationGas。

在理想情况下，打包中的用户能够分摊成本；而在悲观情况下，用户则可能支付过多费用，且成本没有得到分摊。

这个模型的一个扩展可能考虑贝叶斯情形，其中用户能够获得关于n 的分布信息，也就是说，他们可能预期在任何给定时刻会有一些随机变量n 用户出现，按照某种分布（例如，泊松分布），即使他们无法提前得知这个随机变量的具体结果。这种情况可能导致低效的结果，下面的例子便说明了这一点：

Alice预期除了她自己之外还有 9 个其他用户会出现，因此她将 preVerificationGas 设置为 1，因为她知道 F=10。爱丽丝及其他用户的价值都是兼容于设置 preVerificationGas = 3 的，但她试图以最低的费用获得参与资格。结果，仅有 5 个用户出现在市场上，他们也都将 preVerificationGas 设置为 1。打包者无法获得 F=10 单位的燃气补偿，因此不会输出打包，导致用户的效用为 0。这显然是次优的，因为用户本可以将 preVerificationGas 设置为 2，从而获得 1 的效用（即他们愿意支付的最大 preVerificationGas 减去他们实际支付的 preVerificationGas）。

未来的研究方向

打包者游戏揭示了用户在希望被打包者纳入时面临的分配问题。在接下来的讨论中，我们将探讨不同的方法，以改善用户的“用户体验”，以防止他们向对其打包能力需求更为了解的打包者支付过多费用。下一步的探索将需要深入理解将用户、打包者和构建者/区块生产者联系在一起的市场结构。

声明：

1. 本文转载自[ethresear]，著作权归属原作者 [DavideRezzoli]，如对转载有异议，请联系Gate Learn团队，团队会根据相关流程尽速处理。
2. 免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
3. 文章其他语言版本由Gate Learn团队翻译，除非另有说明，否则禁止复制、传播或抄袭经翻译文章。