应用控制执行：取消优先级案例研究

应用控制执行：取消优先级案例研究

作者： maryam和mike – 2026 年 1 月 29 日。

简而言之，应用控制执行（简称 ACE）是一种赋予应用程序交易排序控制权的机制。Hyperliquid 的取消优先级机制是目前 ACE 最显著的例子，它证明了 ACE 可以显著提升链上交易效率。本文分析了四种已提出的 ACE 实现机制，以及它们各自如何实现取消优先级。我们还探讨了一种更通用、更规范的 ACE 形式，这种形式可以用智能合约语言实现，并由 L1 共识机制强制执行。在这种模式下，我们通过实例展示了增加区块构建复杂性和降低可组合性的具体弊端。本文旨在提炼关于不同 ACE 形式的讨论。我们希望它能表明这些设计有很多共同之处，并且像取消优先级这样强大的机制也可以在不增加过多复杂性的情况下实现。

内容

（1）引言
（2）现有设计
\quad （2.1）应用链
\quad （2.2）通用链条上的批量生产
\quad （2.3）链下各方的批量处理
\quad （2.4）协议强制执行的提案人承诺
（3） 共识强制执行的应用程序指定排序
\quad （3.1）积木搭建的复杂性
\quad （3.2）可组合性
\quad （3.3）交易元数据
（4）结论

相关文章

（1）引言

本文研究应用控制执行（简称ACE），在这种执行模式下，应用程序可以指定与其交互的事务的顺序约束。为了便于讨论，我们将采用以下ACE定义。

应用程序控制的执行方式对与其交互的大量事务强制执行排序规则。

应用程序可以自行定义批次的概念，但目前我们将重点关注每个区块一个批次，这是最自然的选择。ACE 是一个非常宽泛的概念和定义，因此我们将通过具体关注 Hyperliquid 实现的取消优先级来使其更加具体。我们将使用以下取消优先级定义。

取消优先级机制确保在每个批次中，取消订单优先于接受订单。

请注意，根据 Hyperliquid 的说法，“取消订单和仅发布订单的优先级高于 GTC 订单和 IOC 订单”（请参阅此处的订单类型说明）。为简便起见，我们将“取消订单”定义为从交易场所移除流动性而不执行交易的订单，“执行订单”定义为执行交易的订单。我们忽略交易所的大部分具体细节（例如，去中心化交易所 (DEX) 与链上 CLOB），但如有必要，将在示例中进行说明。

第二部分探讨了四种现有的ACE实现方案，并分析了每种方案的优缺点。为了更好地统一这些方案，我们专门研究了取消优先级排序这一任务，即使最初的提案并非针对此用例。
第 3 节考虑了一种更通用的协议内 ACE 实现方式，其中智能合约指定函数顺序，共识机制在状态转换函数处强制执行该顺序。这种“内嵌式”解决方案有两个直接的缺点：区块构建复杂度增加和可组合性降低；我们构建了一些小示例来演示这两个缺点。

（2）现有设计

以下四个小节概述了实现ACE的不同机制，并介绍了每种机制如何实现取消优先级排序。我们分析了每种设计的主要优缺点，但并未穷尽所有方案。

（2.1）应用链

Hyperliquid 是首个实现取消优先级机制的加密货币项目；Jeff 在这里阐述了他的动机，并指出此举有助于确保用户获得更低的价差，尽管这会牺牲交易所的交易量（交易量通常被视为虚荣指标）。由于 Hyperliquid 是一个专为交易而设计的应用程序级 L1 服务，因此他们在协议层面实现了这一设计决策：

“这种排序规则由L1链上自身强制执行。节点在Hyperliquid L1链上执行区块的唯一正确方法是先对取消订单和仅发布订单进行排序。”
– Hyperliquid 的设计。

这是强制执行应用程序特定排序规则的最简单、最可靠的方法。下面的时序图展示了这一流程。“共识阶段的强制执行”发生在“验证区块”阶段，验证者通过检查“取消”操作是否在“接受”操作之前来确定区块的有效性。

upload_ebca492ec3e2ad44731712d27495d28c 1070×1276 76.8 KB

应用链在取消优先级排序方面的优势：

• 精细化控制：作为应用链，应用程序对其执行环境拥有最大程度的控制权。赋予每个应用链对区块构建和验证方式的控制权一直是 Cosmos 生态系统的长期理念（尽管这些独立域之间的互操作性尚未实现）。应用链还可以通过其他一些特定的方式来生成区块空间。例如， Injective以与区块生成速度相同的速度运行频繁的批量拍卖。每个交易不是按顺序处理，而是作为一个批次并发执行。类似地， dYdX使用投票扩展来限制区块提议者的权力，方法是限制提议者可以排除的交易集合（这与FOCIL的设计非常相似）。

应用链在取消优先级方面的缺点：

• 抗审查性： Hyperliquid排序规则（以及一般的应用链承诺）的稳健性仅取决于链及其验证者集合的抗审查性。提议者始终可以通过完全排除取消操作来执行接受操作，而不是取消操作。虽然这会放弃取消操作的交易费收入，但如果market maker 1愿意贿赂提议者，那么这种做法可能是合理的。
• “仅桥接”结算：在本分析中，我们将“结算”定义为交易被纳入通用 L1 区块链到交易输出可在通用 L1 区块链上的其他应用程序中使用之间的延迟时间。虽然这对 Hyperliquid 和其他应用链来说似乎不公平，但它们确实与加密货币市场的其他部分隔离，而且大多数已存在于主流公链上的资产的网络效应非常顽固。为了与以太坊 L1 区块链上的 Hyperliquid 交易输出进行交互，资产必须首先进行桥接，这会引入显著的延迟（可能长达几个区块）。尤其值得注意的是，Hyperliquid 与任何其他区块链之间都不存在有效的原子结算。

Hyperliquid 已经证明，如果一个应用程序能够完全控制其排序，那么它应该根据应用程序的具体用例做出有针对性的决策。Atlas 团队也提出了类似的观点，认为他们在“DeFi 专用 L2”框架下所做的决策也应如此。

然而，由于构建的是独立链，应用链也面临着与以太坊 L2 层相同的碎片化问题。为了应对这种碎片化，一些应用会选择直接构建在以太坊和 Solana 等通用区块链上，以利用其他运行在同一状态的应用所实现的原子性。这些应用无法控制共识规则，必须通过公链上的智能合约代码以及任何必要的协议外基础设施来实现。以下两节将探讨一些针对这些应用的拟议设计，并与我们之前看到的案例进行比较。

（2.2）通用链条上的批量生产

Cavey、Jakob 和 Max 提出了“异步消息队列”（简称 AMQ），作为一种使应用程序能够在 Solana 上实现取消优先级机制的方法。该机制的工作原理如下：

1. 在区块 N 中，异步交易会被放入队列，但不会执行。该队列作为智能合约的状态保存，并用作批次。
2. 在区块 N+1 中，排队的交易将作为一个批次执行。 “执行”本身也是一个交易，它按照应用程序指定的优先级顺序触发交易。

下图展示了分两个模块进行的这一过程。

upload_08c603422b911a7eed4b9f0ac5f4684a 1010×1356 86 KB

使用 AMQ 进行取消优先级排序的优点：

• 共识机制无需改变：通过使用 L1 状态和时间戳，目前可以在 Solana（或以太坊）上使用智能合约实现 AMQ，而无需对核心协议进行任何更改。

AMQ 取消优先级设置的缺点：

• 交易延迟：交易发起和结算之间至少存在一个区块的延迟。虽然取消交易的优先级设置可以提升流动性和执行速度，但用户体验显然会受到影响，因为用户需要等待额外的区块才能完成交易（尽管由于区块时间限制，这对于以太坊来说可能比 Solana 更为严重）。目前有两种可能的解决方案，但都需要修改共识规则。首先，区块链可以允许“定时交易”，即在每个区块末尾执行一批交易。其次，区块链可以允许合约内省每笔交易在区块中的位置。有了这种信息，合约就能知道最后一笔交易的时间，并可以在其后立即触发该批交易的执行（这种“回调”机制类似于UniV4 的钩子）。
• “下一区块”结算：由于交易延迟，正如AMQ 帖子中指出的，交易执行的异步特性导致无法与同一区块内的其他 Solana 交易进行原子结算。即使区块 N 中不再有 AMQ 交易（因此批量执行的结果确定无疑），交易结算也要到区块 N+1 才会发生，因此区块 N 中的任何交易都无法与这些输出进行交互（例如，偿还闪电贷）。
• 审查：与上述应用链设计类似，AMQ机制的可信度很大程度上取决于底层链的抗审查能力。Solana验证者可以简单地审查区块N中所有传入的取消请求，从而使优先级队列失效。作者已直接承认这一点。

  “与所有其他不涉及多个提议者的 ACE 形式类似，验证者仍然可以通过审查和延迟在协议强制执行的 tick 边界内绕过 AMQ。”
  – 执行 ACE 。

AMQ 依赖 Solana 验证器来执行 ACE 协议。一些应用程序可能会选择链下批量处理方案，以便将信任转移给与其应用程序更契合的第三方。

（2.3）链下各方的批量处理

另一种实现应用特定排序规则的方法是将排序权委托给链下实体。Sorella 在以太坊上实现了一个混合链上链下去中心化交易所 (DEX)。他们的设计利用了一种独立的共识机制来确定要针对以太坊 L1 持有的流动性头寸执行的交易批次。

注1 ：在Uniswap术语中，取消（cancel）是指“移除流动性头寸”。同样，接受（take）就是指“互换”。

注2 ：正如之前所提议的，Sorella并未实施取消优先级机制。他们目前专注于捆绑包顶部拍卖和批量清算交易。然而，取消优先级机制在他们的模型下很容易实现，因此我们以此为例来阐明不同设计之间的共性。

下图显示了 Sorella 上一个假设的取消优先级流程。

upload_0b068c9d53c36619ed691c39cfeced44 946×1048 62.1 KB

链下批量处理取消优先级排序的优势：

• 共识机制不变：与 AMQ 一样，链下批处理目前可以在通用 L1 上完全实现，无需修改核心协议。

链下批量处理取消优先级排序的缺点：

• 实时性：由于 Sorella 依赖于与以太坊不同的共识机制，因此承担了额外的实时性风险。如果 Sorella 的共识机制停滞或出现恶意行为，交易者和流动性提供者将无法与该应用程序进行交互。作者特别提到了这一点：

  “因此，[ACE] 不可避免地会引入外部各方，从而引入额外的活性和信任假设。”
  –活性和信任假设。

• 审查：应用链和链上批处理带来的审查问题依然存在。特别是，排序规则无法防止 Sorella 提议者忽略即将到来的取消操作，而选择执行已有的提议。另一方面，由于 Sorella 共识参与者是 Sorella 的主要利益相关者，因此可以认为，与通用 L1 验证者相比，验证者的激励机制与项目的长期成功更为紧密相关。
• “捆绑后”结算： Sorella 无法直接与以太坊交易组合，因为所有 Sorella 交易都被捆绑成一个原子单元，该单元以原子方式与 L1 池进行交易。然而，一旦 Sorella 捆绑包被放入区块，交易即完全结算，任何后续交易（即使在同一个以太坊区块内）都可以使用结算后的状态。

注3 ：Sorella的共识机制很容易被其他交易排序机制所替代。例如， BuilderNet使用TEE以可验证的方式运行区块构建。Sorella可以进行修改，使其仅允许由委托的TEE签名的交易包，而不是由Sorella共识的输出签名的交易包。在这种模型下，交易的活性、审查和结算机制与之前的模型类似，唯一的区别在于TEE的保证与拜占庭共识的保证在信任假设上的差异。

（2.4）协议强制执行的提案人承诺

Barnabé 概述了协议强制提案人承诺（简称PEPC），其提出源于共识职责的演变，尤其是在区块构建外包给MEV-boost拍卖机制之后。在PEPC机制下，提案人可以承诺采取比承诺支持最终区块构建者更为通用的行动。与依赖中继作为可信第三方的MEV-boost机制不同，PEPC承诺将由以太坊共识机制本身强制执行。这种通用性还可以用于直接在以太坊中实现取消优先级机制。下图展示了这一点。

上传_c00da71ed53662ee25a7f67ddb26097c 1090×1434 79.5 KB

PEPC在取消优先级方面的优势：

• 无需额外的信任假设：如果 PEPC 得到实施，提案者所作承诺的执行力度将与以太坊的共识保证一样强。
• “原生”结算： PEPC 足够强大，能够确保取消操作先于获取操作，同时又不破坏与以太坊其他交易的组合性。区块构建和验证过程会变得更加复杂（详见3.1 节），但从用户体验的角度来看，原子结算机制将得到完整保留。

PEPC在取消优先级方面的缺点：

• 冷启动问题： PEPC面临的最大弱点在于其自愿性。与预确认类似，PEPC强制执行的取消优先级需要相当数量的验证者才能使其可用。为了获得取消优先级，只有选择加入的验证者才有资格更新合约状态。即使只有十分之一的以太坊验证者（这仍然是一个庞大的数字！）承诺使用取消优先级，应用程序平均每10个区块才会更新一次，这对于许多交易用例来说速度太慢，难以接受。
• 需要对共识机制进行更改：以太坊 L1 共识机制需要进行更改，以便区块有效性条件可以取决于 PEPC 的承诺。

（3）共识强制执行的应用程序指定排序

PEPC实际上是一个应用开发者和验证者之间自愿参与的市场，旨在达成协议，但它也存在冷启动问题。一个相对未被探索的方向是强制验证者参与。这似乎是理想的场景：一个通用的L1层级，其去中心化的验证者集合作为流动性和经济活动的谢林点，使应用开发者能够控制其交易的顺序，而无需任何引导程序。但这真的可行吗？

答案基本是肯定的，但细节却出人意料地微妙。在本文的剩余部分，我们将探讨以太坊共识机制中最简单的改动，该改动或许能够实现 Hyperliquid 优先处理取消交易而非交易。我们想强调的是，设计空间远比我们在此提出的方案丰富得多，值得进一步研究和探索。

考虑对智能合约语言进行简单的修改，允许每个合约指定其函数在每个区块中的执行顺序。例如，我们可以将取消优先级编码为

DEX contract func Take ; func Cancel ; order = [Cancel, Take]

现在，在任何一个区块中，调用 DEX 合约上任一函数的交易都需要遵循一定的顺序，该区块才能有效。下图展示了一个包含两个合约、四笔交易和一个区块的示例。

upload_6293557cdc347eb3614eef9185df2c63-1 1038×1526 105 KB

关于该图表的几点说明：

• 有两种合约：DEX 和 Oracle，每种合约分别具有两个功能。
• 对于 DEX 来说，任何 Cancel 操作都必须位于代码块内的任何 Take 操作之前。
• 对于 Oracle 来说，在代码块内，任何 Update 操作都必须先于任何 Read 操作。
• 有四笔交易涉及对 DEX 和 Oracle 合约的各种函数调用。
• 最后一个块包含序列[TX2, TX1, TX3] ，其函数调用顺序如下： [DEX::Cancel, DEX::Take, Oracle::Update, DEX::Take] 。
• 最终的订购顺序遵循两份合同的当地订购规则。
• TX3和TX4是互斥的，因为[TX3, TX4]和[TX4, TX3]两种排序方式都违反了合约排序规则。更多内容请参见第 3.1 节。

没有根本原因阻止我们通过修改智能合约语言并在共识阶段强制执行来赋予应用程序这种控制权（Hyperliquid 实际上就是通过取消优先级机制来实现的）。在许多方面，协议内执行 ACE 比前面提到的四种替代方案更简洁（例如，它实际上就是 PEPC，其中提议者必须遵守应用程序指定的排序约束）。特别是，它具有原生结算功能，拥有与 L1 共识相同的保证，无需额外的信任假设，并且通过要求验证者参与解决了冷启动问题。

然而，以太坊也存在一些明显的缺点，尤其是在考虑到L1区块构建的复杂性有限（这是以太坊的明确目标）以及同一条链上应用程序的可组合性（这是智能合约平台的普遍特征）时。以下各小节将通过具体示例探讨这些问题。

（3.1）积木搭建的复杂性

允许合约指定排序约束会增加构建有效区块的复杂性。为了更好地说明这一点，我们可以考虑一下以太坊当前的区块构建方式。虽然大多数区块是由经验丰富的区块构建者通过 PBS 构建的，但仍有大约 8% 的区块是由提议者直接构建的（参见mevboost.pics ）。尽管将优先级最高的交易费最大化的区块打包到 gas 限制内是 NP 完全问题（0/1 背包问题），但大多数区块远低于最大容量，因此通常只需将所有有效且支付基本交易费的交易都包含在内存池中即可。如果内存池中的交易数量超过了区块 gas 限制，那么对于那些希望以简单方式构建区块的人来说，只需运行按优先级交易费排序的贪婪算法即可提供一个很好的启发式方法。即使某些交易被撤销，将它们包含在区块中仍然有效，并且它们会支付在撤销之前处理所需的单位 gas。本地建造者可以继续添加小费最高的交易，直到区块填满为止，并确保生成的区块有效，且其小费收入至少达到最优值的 1/2。

如果我们允许智能合约指定每个区块的排序规则（如上所述），那么即使只是从待处理交易列表中找到一个有效的区块（并保证合理的手续费收入），也会变得非常复杂。以下示例对此进行了说明。我们考虑两种交易类型，并使用 UniswapV2 风格的函数名称。

1. SWAP 将资产池中的一种资产交换为另一种资产（“换取”）。
2. REMOVE 以特定价格从资金池中移除流动性（“取消”）。

我们让智能合约规定，在每个区块中，所有 REMOVE 调用必须先于所有 SWAP 调用（取消优先级）。在我们的示例中，REMOVE 和 SWAP 都会改变价格的平价。对于 REMOVE 操作，您可以想象流动性提供者 (LP) 可以从资金池中移除特定代币并改变价格。对于 SWAP 操作，交换的大小决定了价格的平价是改变还是保持不变。

考虑三个假设的交易，它们的行为取决于它们开始执行时资金池价格的平价性，括号表示该操作对价格平价性的影响。

所有交易都可能是 REMOVE 或 SWAP，具体取决于奇偶校验。考虑候选区块[TX1, TX2, TX3] ；让我们看看当池子处于偶数状态时会发生什么。

1. TX1 首先执行并进行互换，将价格的平价变为奇数。
2. TX2 发现池价格异常，因此尝试执行 REMOVE 操作。

我们已经遇到问题了！我们的排序规则规定 REMOVE 操作必须先于 SWAP 操作执行，因此[TX1, TX2, TX3]不是有效的执行顺序。事实上，在所有3! = 6种交易顺序排列中，只有以 TX3 开头的两种是有效的。下面的列表显示了每个候选顺序及其对应的函数调用。请记住，资金池的价格平价一开始就是偶数。

• 123 : 1（交换：奇数）→ 2（移除：奇数）→ 3（交换：奇数）
  • 结果：SWAP，REMOVE，SWAP => 无效
• 132 : 1 (交换：奇数) → 3 (交换：奇数) → 2 (移除：奇数)
  • 结果：SWAP、SWAP、REMOVE => 无效
• 213 : 2 (交换：奇数) → 1 (移除：奇数) → 3 (交换：奇数)
  • 结果：SWAP，REMOVE，SWAP => 无效
• 231 : 2 (交换：奇数) → 3 (交换：奇数) → 1 (移除：奇数)
  • 结果：SWAP、SWAP、REMOVE => 无效
• 312 : 3 (移除：奇数) → 1 (移除：奇数) → 2 (移除：奇数)
  • 结果：删除，删除，删除 => 有效
• 321 : 3 (移除：奇数) → 2 (移除：奇数) → 1 (移除：奇数)
  • 结果：删除，删除，删除 => 有效

当然，区块开始时池价格也可能是奇数。在这种情况下， [TX3, TX2, TX1]和[TX3, TX1, TX2]现在都是无效的订单，唯一有效的订单是[TX1, TX2, TX3]和[TX2, TX1, TX3] 。

即使仅使用我们这个简单的示例和三个交易，我们也需要检查大量的排列组合才能找到一个有效的排序。随着交易数量、函数数量和约束条件的增加，寻找有效排序的问题在组合逻辑上会变得更加复杂。

（3.2）可组合性

除了区块构建的复杂性之外，ACE 还削弱了智能合约和交易在同一区块链上执行时通常享有的可组合性。假设两个去中心化交易所（A 和 B）都遵循我们上面描述的相同排序规则，即 REMOVE 操作必须先于 SWAP 操作：

• 所有 REMOVE(A) 操作必须在所有 SWAP(A) 操作之前执行。
• 所有 REMOVE(B) 操作必须在所有 SWAP(B) 操作之前执行。

现在，假设内存池中有以下两个交易：

• TX1：移除(A) + 交换(B)
• TX2：移除(B) + 交换(A)

虽然这些情况看起来可能很随意，但考虑这样一种情况：链下价格发生显著波动，Alice 在资金池 A 中持有流动性提供者 (LP) 头寸，Bob 在资金池 B 中持有流动性提供者 (LP) 头寸。Alice 和 Bob 都试图从各自的资金池中移除流动性（这两个资金池的价格都已过时），并且他们还希望用移除的流动性提供者 (LP) 代币来兑换另一个资金池中价格已过时的代币。

请注意，由于任何一笔交易先于另一笔交易都会违反每个独立去中心化交易所 (DEX) 强制执行的两条排序规则之一，因此这些交易不能合并在一起。当然，Alice 和 Bob 可以将他们的 REMOVE 操作与相应的 SWAP 操作分开，但这会破坏他们操作的原子性，而且除非他们从自己的资金池中移除流动性，否则他们可能没有足够的资金在另一个资金池中进行 SWAP 操作。

再举一个例子，考虑以下 Oracle 和 DEX 的排序规则。

• Oracle：UPDATE 操作必须先于 READ 操作。
• DEX：移除操作必须先于交换操作。

Oracle 希望确保所有读取操作都能访问最新数据，而 DEX 则继续使用我们的取消优先级规则。现在考虑以下两个交易：

• TX1：更新（ORACLE）+ 交换（DEX）
• TX2：读取（ORACLE）+移除（DEX）

同样，这两个交易都可以自然产生。第一个交易中，用户从预言机更新价格，然后进行原子交换。第二个交易中，在移除流动性提供者 (LP) 头寸之前读取预言机价格。然而，这两个交易不能包含在同一个区块中，因为这会导致两个合约中的一个出现顺序冲突。虽然可以将这些操作拆分成单独的交易进行重新排序，但这会破坏这两个应用程序之间的可组合性。

在不同的排序规则和涉及众多合约的大量交易的情况下，区块构建的复杂性会进一步增加。考虑以下示例，其中每笔交易都会分别调用一次预言机合约和一次去中心化交易所（DEX）合约。

我们再来看看尝试序列[TX1, TX2, TX3]会发生什么。显然，这行不通，因为 Oracle 和 DEX 的排序规则都被违反了。这里，唯一能产生有效交易集合的序列是[TX3, TX2, TX1] 。下面的每个要点都展示了一种可能的排序方式。

• 123 : 1（读取，交换） → 2 （读取，删除） → 3 （更新，删除）
  • （读取操作先于更新操作）且（交换操作先于移除操作）=> 无效
• 132 : 1（读取，交换） → 3 （更新，删除） → 2（读取，删除）
  • （读取操作先于更新操作）且（交换操作先于移除操作）=> 无效
• 213 : 2（读取，删除） → 1（读取，交换） → 3 （更新，删除）
  • （读取操作先于更新操作）且（交换操作先于移除操作）=> 无效
• 231 : 2（读取，删除） → 3 （更新，删除） → 1 （读取，交换）
  • （READ 先于 UPDATE）=> 无效
• 312 : 3（更新，删除） → 1 （读取，交换） → 2（读取，删除）
  • （SWAP 先于 REMOVE）=> 无效
• 321 : 3（更新，删除） → 2 （读取，删除） → 1（读取，交换）= >有效

在某些方面，本例中的区块构建问题比前例中运行时检查资金池奇偶性的问题更容易解决，因为可以在运行交易之前检查函数的顺序。然而，关键在于，找到所有三个交易的有效顺序可能需要比简单的按优先级费用排序的贪婪算法多得多的计算量。此外，还可以轻松构建更复杂的示例，其中交易在去中心化交易所 (DEX) 或预言机合约上调用的函数取决于资金池的价格和/或来自预言机的价格信息，而这些价格信息在运行时会发生变化。

（3.3）可能的适应和缓解措施

在前一节中，我们看到，只需对共识机制进行少量修改，即可将 ACE 集成到通用的 L1 区块链中，但代价是区块构建的复杂性会增加。区块构建复杂性的增加会带来一些弊端。首先，它可能会导致中心化，因为这会使本地构建者（那些自行构建区块而非外包的非专业验证者）更难甚至无法准确估算出最优的交易费收入。此外，或许更重要的是，用户、钱包和前端都需要调整其交易费逻辑以及调用的函数集，以应对交易排序复杂性的增加。

例如，对交易及时性有强烈要求的用户（例如，希望紧急取消交易以防止过期报价被抢购的用户）可以尽可能简化其交易逻辑，使其便于构建器进行静态分析。这使得构建器能够更好地预先预测交易行为，而无需在区块的不同位置重新运行。然而，这种对简洁性的追求可能会限制交易的可组合性。随着交易变得越来越复杂，并与更多合约交互，构建器对其静态预测交易将涉及哪些函数和合约的信心会降低。一个足够复杂的交易很可能改变其行为，以至于构建器可能会直接将其排除（或者由于包含该复杂交易而排除许多其他交易）。因此，这需要在交易的表达能力和预期包含时间之间进行权衡。即使不与 ACE 序列合约交互的交易也与交互的交易共享区块空间，这意味着它们也必须权衡这种利弊，因为在执行之前没有完全可靠的方法来发出交易的确切行为信号。

请注意，我们并未对上述许多论断进行正式的论证。例如，我们并未精确量化活性下降程度与表达能力之间的关系。我们也未对构建器的置信度如何受事务复杂度影响进行建模。这两个方向都值得进一步研究。例如，前者需要显式地对不同区块构建算法的近似保证进行建模，后者则需要具备EVM/SVM静态/动态分析的领域知识。我们在此的目标是定性地指出这些有趣的权衡，并希望能够说服领域专家，这些都是值得探索的有趣问题。

显式信号

与其要求区块构建者承担完整的交易排序分析，该协议可以通过添加元数据来支持或要求更明确的信号传递，以便交易能够主动证明其将要调用的函数。在以太坊中，这种交易预承诺类似于区块访问列表（BALL） ，后者目前正在考虑纳入下一次硬分叉。在 Solana 中，交易已经承诺到账户地址，但在这两种情况下，添加函数级元数据对于提高区块构建者在不直接执行交易的情况下启动排序过程的能力都至关重要。

在这种结构下，只有准确声明了函数签名的交易才会被视为有效；如果交易调用了未声明的函数，则会被撤销但仍需支付 gas 费用。这种机制有助于确保区块创建者能够收到 gas，并且意味着交易可以任意复杂而不会影响其活性。当然，这种改变会将分析负担转移到交易发起者身上。虽然钱包和前端应该能够指定其函数调用，这似乎符合直觉，但在某些状态相关的情况下，交易可能无法事先知道它将调用哪些函数（例如，链上路由交易在搜索最佳价格时，不希望预先决定在每个探测到的 DEX 上调用 swap 函数）。再次强调，从非执行层专家的角度来看，这种设计空间似乎很丰富，并且具有潜在的应用前景。

值得注意的是，在ACE中，区块构建的复杂度远高于区块验证的复杂度。在验证区块时（例如，作为验证者决定如何投票），所涉及的合约列表和交易顺序可以在运行时动态检查，任何违反合约设定的排序规则的行为都会立即导致状态转换函数返回无效状态，而不会显著增加区块验证的复杂度。

（4）结论

本文从取消优先级的角度探讨了ACE的多种候选设计方案。每种设计方案都存在一些权衡取舍，我们已在上文中重点阐述。我们还探讨了将ACE以基本形式融入L1机制的可能性，即合约可以指定其函数的顺序，该顺序必须在单个区块内得到遵守。可启用的排序规则设计空间非常广阔，值得深入探索。例如，您可以设想更具表现力的排序规则，例如当去中心化交易所（DEX）的价格波动过大时触发规则。此外，排序规则可以比仅仅指定合约内函数的顺序更加复杂。

ACE 协议就是一个例子，它对区块施加了额外的有效性约束。这些约束来自应用程序开发者，他们负责指定函数调用的顺序。Hyperliquid 已经证明，这种约束对最终用户很有用，尤其是在专门围绕交易构建的应用程序链环境中。这一理念似乎指向一个更广阔的协议设计空间，其中主要问题将是：

1. 可行性：通用区块链可以实施哪些限制（而不至于过于复杂）？
2. 合理性：哪些限制有利于最终用户或整个生态系统的福祉？

这与《分析去中心化对用户的经济影响》一文的思路类似，该文分析了协议对供应约束的承诺如何影响最终用户的定价。我们认为，将这项工作扩展到协议可以做出的特定于应用程序的承诺，具有重要价值。

希望本文通过取消优先级示例，帮助统一不同的ACE机制；通过提供具体示例，阐明ACE的一些微妙之处，展示区块构建的复杂性和可组合性问题；并探讨在以太坊环境中应用内置ACE的潜力。我们相信这是一个很有前景的想法，值得继续深入研究和探索。