意图的采用代表了从命令式范式到声明式范式的转变，这有望显著改善由于 MEV 泄漏而导致的用户体验和效率损失。

原文标题：《Intent-Based Architectures and Their Risks》

撰文：Quintus Kilbourn、Georgios Konstantopoulos

编译：Kate, Marsbit

介绍

最近，围绕「意图」及其应用的讨论已经成为以太坊社区的热门话题。

如果交易明确指的是应该「如何」执行某个操作，那么意图指的是该操作的预期结果应该是什么。如果交易内容是「先做 A，再做 B，支付 C 以获得 X」，那么意图则是「我想要 X，我愿意支付 C」。

这种声明式范式在用户体验和效率方面带来了令人兴奋的改进。有了意图，用户可以简单地表达期望的结果，同时将最佳实现该结果的任务外包给经验丰富的第三方。意图的概念与今天的命令式交易范式形成对比，在命令式交易范式中，每个参数都由用户明确指定。

虽然这些改进的承诺为生态系统提供了急需的一步，但以太坊上基于意图的设计也可能对链下基础设施产生重大影响。特别是，与 MEV 相关的活动和市场控制有重要的联系。本文旨在提供意图及其好处的简要定义，探索其实施所涉及的风险，并讨论潜在的缓解措施。

什么是意图？

用户与以太坊交互的当前标准方法是制作和签署交易，以特定格式提供以太坊虚拟机 (EVM) 执行状态转换所需的所有必要信息。然而，创建交易可能是一件复杂的事情。创建交易需要对庞大的智能合约网络和随机数管理等细节进行推理，同时持有特定资产以支付 gas 费。这种复杂性导致了次优用户体验和效率损失，因为用户被迫在没有足够的信息访问或复杂的执行策略的情况下做出决策。

人们产生了减轻这些负担的意图。非正式地，意图被签署为一组声明性约束，允许用户将交易创建外包给第三方，而不放弃对交易方的完全控制。

在基于交易的标准流程中，交易签名允许验证器针对某个状态精确地遵循一条计算路径，而提示则激励验证器这样做。另一方面，意图并不指定必须采取的计算路径，而是允许任何满足特定约束的计算路径。通过签名和共享意图，用户可以有效地向接收者授予权限，让他们代表自己选择计算路径 ( 见下图 )。这种区别允许将意图稍微更严格地定义为签名消息，允许从给定的起始状态进行一组状态转换，一种特殊情况是允许唯一转换的交易。话虽如此，我们将继续将「意图」与交易区分开来。

图 1：提交交易时，用户指定确切的计算路径。当提交意图时，用户指定目标和一些约束条件，然后匹配过程决定要采取的计算路径。

重要的是，许多意图可以包含在单个交易中，允许匹配重叠的意图，增加 gas 和经济效率，例如，在建造者维护的订单簿中，两个订单可以在进入市场之前相互抵消。其他应用包括跨域意图——签署一条消息，而不是在不同的域上签署多笔交易——使用不同的重放阻力方案，以及更灵活的用户 gas 支付，比如允许第三方赞助 gas 或以不同的代币支付。

过去和未来是意图

已经创建了将与区块链交互的复杂性外包的意图，同时允许用户保持对其资产和加密身份的保管。

你可能会注意到，其中许多想法与已经运行多年的系统相对应：

• 限价订单：如果我收到至少 200Y，则可以从我的账户中扣除 100X。
• CowSwap 式拍卖：与上述相同，但依赖于第三方或机制来匹配许多订单，以最大限度地提高执行质量。
• Gas 赞助：用 USDC 而不是 ETH 支付 Gas。该意图只能通过向 ETH 支付费用的匹配意图来实现。
• 授权：只允许以某些预先授权的方式与某些帐户进行交互。只有当最终交易遵守意图中指定的访问控制列表时，意图才能实现。
• 交易批处理：允许对意图进行批处理以提高效率，减少 gas 费。
• 聚合器：只使用「最佳」价格 / 收益来进行操作。可以通过证明执行了多个场所的聚合并采用了最佳路径来实现该意图。

展望未来，在跨链 MEV（例如 SUAVE）、ERC4337 风格的账户抽象，甚至 Seaport 订单的背景下，人们的意图正在重新焕发活力！虽然 ERC4337 正在全速前进，但其他新颖的应用程序（如跨域意图）仍需要进一步研究。可以在本次演讲中找到对意图及其应用的进一步讨论。

至关重要的是，在所有新旧基于意图的应用程序中，至少需要有另一方了解意图，激励其执行意图并能够及时执行意图。这些各方是谁，执行是如何进行的，他们的动机是什么，这些问题必须提出，以确定意图驱动系统的有效性、信任假设和更广泛的影响。

中间商及其内存池

最明显的渠道就是以太坊内存池。不幸的是，当前的设计不支持意图的传播。对 DoS 攻击的担忧可能意味着，即使从长远来看，对以太坊内存池中完全通用意图的通用支持也是不可能的。正如我们将在下面看到的，以太坊内存池的开放性和无许可性给采用意图带来了额外的障碍。

在没有以太坊内存池的情况下，意图系统设计者现在面临着一些设计问题。一个高级决策是将意图传播到一个许可集，还是以一种无需许可的方式提供，以便任何一方都可以执行意图。

图 2：意图从用户流向许可 / 无许可和公共 / 私人意图池，由撮合者转换为交易，最终通过 MEV boost 式拍卖进入公共内存池或直接在链上

无需许可的内存池

人们可能会争取的一种设计是去中心化的 API，它允许在系统中的各个节点之间传播意图，为执行者提供无需许可的访问。这是以前做过的。例如，在 0x 协议中，中继器在彼此之间闲谈限价订单，并在有匹配时将它们放在链上。这个想法也在共享 ERC4337 内存池的背景下进行了探索，以对抗中心化和审查风险。然而，这种无需许可的「意图池」的设计面临着一些重大挑战：

• DoS 抵抗：可能必须限制意图的功能以避免攻击向量 ( 请参阅 ER C4337 提案以进一步讨论 )
• 传播激励：对于许多应用程序来说，执行意图是一项有利可图的活动。因此，操作意图池的节点有不传播意图的动机，以减少执行意图时的竞争。
• MEV：意图依赖于链下参与者的良好行为来提高执行质量，在使用公共的、无许可的意图池时可能会遇到困难。如果执行不力是有利可图的，那么无需许可的意图池很可能导致这种结果。这类似于今天的以太坊内存池，预计将成为与 DeFi 相关的一个普遍问题。这里可能的前进路径可能是无需许可但经过加密的意图池。

许可的「内存池」

受信任的中心化 API 更能抵抗 DoS 攻击，而且不需要传播意图。可信模型还为 MEV 问题提供了一些立足点。只要信任假设成立，执行质量就应该得到保证。值得信赖的中间商也可能拥有与之相关的声誉，这为他们提供了良好执行的动力。因此，许可意图池在短期内对基于意图的应用程序开发人员很有吸引力。然而，我们都很清楚，强信任假设存在缺陷，并且与区块链的许多精神有些对立。这些问题将在下面讨论。

混合解决方案

有些解决方案是上述各项的混合物。例如，可以有许可传播，但无许可执行（假设信任假设成立），反之亦然。混合解决方案的一个常见示例是订单流拍卖。

这些设计的高级思想是，需要交易对手的用户可能需要区分更好和更差的交易对手 ( 例如，以优惠的价格接受交易的另一方 )。设计流程通常包括一个可信方，它接收来自用户的意图 ( 或交易 )，并代表用户促进拍卖。参与拍卖 ( 有时 ) 是不需要许可的。

这些类型的设计有其自身的缺点，并且可能会受到许多许可意图池的担忧，但有一些重要的区别将在稍后变得明显。

底线：基于意图的应用程序不仅仅涉及与智能合约交互的新消息格式，它们还涉及以替代内存池形式的传播和对手发现机制。设计一种与激励兼容且同时不中心化的意图发现和匹配机制并非易事。

哪里会出错？

虽然意图是一种令人兴奋的新交易范式，但它们的广泛采用可能意味着加速了用户活动向其他内存池转移的更大趋势。如果管理不当，这种转变可能会导致寻租中间商的中心化和固守。

订单流

如果允许意图执行，并且不小心选择许可集，则从公共内存池迁移可能会使以太坊的区块生产集中。

如果意图执行得到许可，但未谨慎选择许可集，则从公共内存池中迁移出来可能会使以太坊的区块生产中心化。

以太坊上绝大多数的区块生产目前都是通过 MEV-Boost 进行的，MEV-Boost 是提议者 - 构建者分离 (PBS) 的一种协议外实现，目前的路线图没有迹象表明这个接口会很快改变。PBS 依赖于区块构建者竞争市场的存在，将 MEV 引导到验证者集。PBS 的一个主要问题是，区块构建者能够获得生产有价值区块所需的原材料的独家访问权——交易和意图，也就是「订单流」。在 PBS 的语言中，对意图的许可访问被称为「独占订单流」(EOF)。正如本文所讨论的那样，错误的一方掌握的 EOF 会威胁到 PBS 所依赖的市场结构，因为订单流的排他性意味着对抗竞争力量的护城河。

控制了大部分以太坊订单流的区块构建者 ( 或合作实体 ) 将能够生产大多数主网区块，从而为审查打开了一个通道。由于网络依赖于构建者之间的竞争来将价值传递给验证者 ( 或在未来被烧掉 )，单个构建者的主导地位将构成价值从以太坊向构建者的转移。寻租和审查当然是对协议的重要威胁。

信任

由于许多解决方案需要对中介的信任，新的基于意图的体系结构的开发受到了高门槛的阻碍，这意味着为了确保执行质量，创新和竞争率会较低。

在最坏的情况下，用户发现自己处于只有一方执行意图的位置，例如上一节中的垄断区块构建者。在这样一个世界里，垄断区块构建者将能够榨取租金，任何关于如何处理意图的新提议，如果不被构建者采纳，都将被拒绝。面对垄断者，个人用户失去了谈判能力——当用户意图给予中间商额外的自由度时，这种影响就会加剧。

不幸的是，由于中心化基础设施导致的市场停滞不包含对建造者市场的担忧。即使对于非区块构建业务，高进入门槛也可以使中间商处于有利地位，因为他们几乎没有面临竞争。例如，考虑当前订单流拍卖市场的状态。像 Flashbots 和 CoWswap 这样的几个实体接收了大部分流向 OFA 的订单。订单流的分布在很大程度上是因为这些实体已经存在多年，或者与信誉良好的实体有关联，这意味着它们已经成功地获得了一定程度的公众信任。如果一个新的 OFA 设计试图进入市场，那么无论谁在运营新的 OFA，都必须花费大量的时间来说服用户和钱包，他们是有信誉的，不会滥用职权。这种赢得信任的必要性无疑构成了进入的重大障碍。

订单流拍卖市场最近才开始受到关注，竞争将如何发展还有待观察，但该市场确实提供了一个说明性的例子，在这种情况下，经过许可的、受信任的内存池可能会包含少数强大的参与者，从而损害用户的最大利益。

EIP4337 意图格式提供了另一个例子，说明我们有可能采用某种机制。考虑这样一个世界，其中可信的体系结构已经到位，以支持 4337 意图。如果提出了另一种意图格式，可能服务于其他用例，如跨域功能，但已建立的可信中间商不采用这种新格式 ( 毕竟，它没有得到很多采用，并且与他们的业务模型竞争 )，则新格式的实现将需要在新实体中建立信任。再一次，我们发现自己处于这样的境地：创新和挑战现状遇到了基于信任的进入壁垒。

不透明度

由于许多意图架构需要用户放弃对其链上资产的一些控制，而许可的内存池意味着外部一定程度的不可渗透性，我们冒着构建一个不透明系统的风险，在这个系统中，用户的期望如何或是否得到满足是不清楚的，对生态系统的威胁仍然未被发现。

以上章节涉及订单流市场中的权力不平衡给用户和协议带来的风险。一个相关的问题是，在用户和区块链之间开发的中间件和内存池生态系统即使对敏锐的观察者来说也变得不透明。这个问题尤其适用于基于意图的应用程序，这些应用程序试图允许用户外包订单路由等重要决策。

MEV 对用户执行产生负面影响的情况通常是由于交易放弃了其执行者的高度自由（例如滑点限制）。因此，在逻辑上断言，放弃更大自由度的基于意图的应用程序应该更谨慎地设计其系统来执行，这并不是什么大的飞跃。在这方面，最糟糕的结果是使用基于意图的应用程序需要签署一个消失的意图 ( 如果你愿意，可以进入黑暗森林 )，然后以某种方式实现为交易，而不清楚交易是如何或由谁创建的。当然，监控此类生态系统的能力也与对 EOF 和基于信任的防御的担忧有关。如果这个生态系统对最敏锐的观察者来说都是模糊的，那么以太坊社区应该如何监控对其区块生产生态系统健康的威胁？

减轻风险

以太坊内存池是有限的。对于某些应用程序，这是由于它缺乏隐私 ( 夹在中间 )，而对于其他应用程序，这是由于它无法支持更广泛的消息格式。这使得钱包和应用程序开发人员陷入困境，因为他们必须找到某种方法将用户连接到区块链，同时避免上述危险。

在检查上述问题时，我们可以推断出理想系统的某些属性。这样的系统应该是

无需许可的，这样任何人都可以匹配和执行意图，而不会牺牲太多的执行质量

通用的，以便部署新的应用程序不需要建立新的内存池，

透明的，以便在隐私保证允许的情况下公开报告意图执行的过程，并提供执行质量审计的数据。

虽然像 Flashbots 和 Anoma 这样的团队正在致力于通过结合隐私和无许可来满足上述要求的通用解决方案，但理想的系统可能不会在短期内准备好。因此，不同的解决方案做出自己的权衡，可能会最好地服务于不同的应用程序。尽管像 crlists 这样的机制是为了回应围绕基于交易的应用程序的许多相同问题而出现的，但可能不适用于意图，但允许用户尽可能回退到交易的小工具可能会很好地改善最坏的情况。同样，希望启动意图池的应用程序，如果没有许可，最好寻求通用性，如果有许可，最好谨慎选择中间商。

从广义上讲，我们要求基于意图的应用程序设计者充分考虑其应用程序的链下影响，因为这些可能会触及更广泛的社区，而不仅仅是他们的用户群，我们要求更广泛的社区密切关注围绕以太坊的链下生态系统。

结论

意图的采用代表了从命令式范式到声明式范式的转变，这有望显著改善由于 MEV 泄漏而导致的用户体验和效率损失。对这些应用程序的需求是明确的，许多基于意图的应用程序已经被广泛使用多年。

在 ERC4337 的推动下，越来越多的意图被采用，可能会加速以太坊内存池向新场所的转移。尽管这种转变是合理且不可避免的，但基于意图的应用程序设计人员有充分的理由在开发强大的基础设施时谨慎设计其系统的链下组件。

在这个新生的交易范例和我们在本文中没有涉及的领域，如设计一种允许隐私的意图表达语言，仍然有大量的研究和工程要做。如果你觉得这个或其他意图相关的研究课题很吸引人，请联系 0xquintus georgios@paradigm.xyz。

非常感谢 Dan Robinson, Charlie Noyes, Matt Huang, John gu, Xinyuan Sun 和 Elijah Fox 对本文的反馈，以及 Achal Srinivasan 设计图形。