当前场景
在区块链领域，用户意图，被称为“意图”，呈现出多种形式，包括DSL表达式、自然语言、动作、条件和限制。一个意图捕捉了用户对特定交易行为的设想。例如，一个常见例子是为亚马逊订单选择“当日送达”。账户抽象（ERC 4337）的整合扩展了这些表达可能性的范围。
目前，在以太坊生态系统中，没有建立用于求解器协作和协调工作的架构。现有的求解器生态系统独立运作，导致求解器的可见性有限，并复杂化了用户发现适合其意图实现的求解器的过程。
在DeFi协议中进行的MEV提取正在增加，而flashbots的新解决方案SUAVE确实提供了一种缓解方法，但这些方法相当远见卓识，取决于采用情况。这使得用户面临以MEV形式增加的资金损失。通过利用求解器协作和促进求解器之间的数据共享，可以进一步减少MEV捕获，这将引入对手方发现，并可能导致需求的潜在巧合。
以太坊作为一个采用虚拟机（VM）的有状态区块链，在EVM内实现此架构面临一个关键障碍。这个障碍在于交易构建过程。在以太坊生态系统中，交易遵循确定性方法，只捕获实现状态更改所需的有限信息集。这种设计抵制了进一步的优化。相比之下，意图旨在捕获用户的愿望，随后由求解器将其转化为优化的交易，从而为用户提供更大的灵活性和价值。
为了将意图与EVM对齐，我们引入了一种称为抽象交易对象（ATOs）的新结构。ATOs专门捕获与特定操作相关的信息。求解器利用这些信息构建针对操作要求量身定制的优化交易。
临时ATO结构
{
"operation": ENUM,
"fieldsToOptimize": hex,
"fieldsToOptimizeSchema": string,
"chainId": number,
"payload": hex,
"payloadSchema": string
}
fieldToOptimize字段包含操作中用于得分优化的必要字段，以编码形式存在。得分将求解器的解决方案转化为定量值，驱动程序可以使用它来评估和比较多个求解器收到的解决方案。fieldToOptimizeSchema包含用于解码fieldToOptimize字段的模式。chainId是用户想要执行意图的链的链ID。payload除了fieldToOptimize之外的额外信息，以编码格式由求解器将该ATO转换为有效交易。payloadSchema包含用于编码payload字段的模式。在应用程序级别捕获的意图(I)可以由n个ATO组成，可能对应于同一操作多次。理论上n可以一直到\infty，但在实际情况下，它将是某个明确的数字。
I = [ATO_{1}+ATO_{2}+……..+ATO_{n}] \;\;n \in[1,\infty)
这些ATO可以以私密方式呈现，其中信息被隐藏，并且以用户不向公共区块链公开任何信息的方式执行。
管理抽象交易对象（ATOs）：驱动程序在意图驱动架构中的作用
驱动程序在基础设施内扮演关键角色，作为一个可信赖的方，具有几个关键职责：
ATO广播：驱动程序的任务是将抽象交易对象（ATOs）广播到内存池，所有求解器都可以在那里启动它们的执行过程，以找到最优解决方案。
仿真和验证：它从所有求解器接收解决方案，进行离线仿真以确保其有效性和安全性，然后发布获胜的解决方案。
解决方案聚合：对于给定的意图，驱动程序从不同的ATO聚合解决方案，将它们结合成一个统一的执行计划以供最终实施。
ATO捆绑和广播
驱动程序有效地管理抽象交易对象（ATOs）的捆绑，每个捆绑专注于解决单个用户意图。如果意图对应于单个动作，驱动程序也可以接收单个ATO。
在接收到这些捆绑后，驱动程序执行以下任务：
并行排序：
驱动程序执行ATO捆绑的并行排序，开始提取和捆绑ATOs以进行广播。
捆绑ATOs：
它根据操作类型捆绑每个捆绑中的第一个ATO。例如，如果有四个ATO捆绑，其中两个将交换操作作为它们的第一个ATO，另外两个将桥接操作作为它们的第一个ATO，驱动程序将广播两个捆绑，一个用于交换操作，一个用于桥接操作，分别发送到它们各自的求解器。这种有组织的方法简化了ATO分发过程到求解器网络。
对于每个捆绑中的第一个ATO，不需要新的状态信息，因为求解器可以使用当前的区块链状态来找到该特定ATO的最优解决方案。
驱动程序遵循一个结构化的过程。对于捆绑的初始ATO，它不需要额外的状态信息，求解器可以继续使用可用的区块链状态。
然而，对于捆绑中后续的ATOs，驱动程序在捆绑下一组ATOs之前，从所有先前的ATOs收集相应的解决方案。这确保了求解器在解决新ATO之前拥有更新的状态信息，因为某些字段可能依赖于前面ATOs的信息。
本质上，驱动程序为每个非初始ATO保持一个持续的循环。在广播之前，驱动程序确保它拥有所有先前ATOs的胜利解决方案，促进了解决用户意图的有组织和同步的方法。
求解器网络如何增强意图驱动架构？
求解器是此系统上下文中的参与者。它在求解器网络内运作，这是一个多样化求解器的集体存储库，每个求解器都专门处理不同的领域。具有这些先决条件的个人可以成为求解器：
有效的以太坊地址：具有有效钱包地址的个人可以通过通过专用智能合约注册自己为求解器来参与这个生态系统。
领域专家：这些求解器配备了专门化的代码，旨在解决特定类型的ATO进行特定操作（交换、桥接、质押等）。例如，专门从事衍生品交易的求解器
赢得DAO投票过程：值得注意的是，求解器的选择过程扩展到去中心化自治组织（DAOs），成员可以行使他们的投票权来决定包括求解器。
这种协作方法确保了一个多样化和专家驱动的求解器网络，丰富了架构的能力。
虽然驱动程序促进了从客户端起源的ATOs到它们指定的求解器的路由，但在设计求解器网络时出现了一个重要考虑。将完整的权力委托给一个单一的求解器来解决所有ATOs引入了几个挑战：
最优解决方案探索：在单个求解器领域内缺乏竞争可能会损害为ATO获得最佳解决方案。求解器网络通过促进多个求解器贡献他们的专业知识的环境来缓解这个问题，使不同的方法得以探索，并识别出最有效的解决方案。
抗审查性：单一求解器实施审查并选择性地拒绝某些用户的ATOs的潜力是一个令人担忧的方面。求解器网络通过将ATOs分配给各种求解器来规避这个问题，促进公平和公正的执行，没有不当审查的风险。
增强可用性：仅依赖单个求解器呈现脆弱性；如果该求解器变得不可用，整个协议就会陷入停顿。求解器网络通过将任务分配给众多求解器来避免这种困境，确保即使某些求解器经历停机时间，系统仍然运行。
内存池
在系统中包括多个求解器被证明是一种明智的方法，能够处理来自驱动程序的多样化ATOs流。这些求解器共同形成一个求解器网络，合作破译ATOs并实现最佳可能的解决方案，这种努力为他们赢得了当之无愧的奖励。在这个框架内，ATOs在所有参与求解器都可以访问的共享内存池中找到了它们的家。此外，我们计划让求解器拥有自己的本地内存池，未来我们将尝试使用户能够直接将他们的ATOs发送给求解器之一，并且从本地链下内存池中，那些没有专业知识来解决他们收到的ATO的求解器可以与具有解决该ATO专业知识的邻居求解器分享这些ATOs。此外，还将由驱动程序设置拍卖期，通过该拍卖期，求解器有责任返回该特定ATO的解决方案，未能这样做可能导致ATO解决方案接受失败。
期望程度：优化意图的定量方法
求解器根据用户指定或特定于操作的字段优化ATOs，由一组质量T表示，对于特定的ATO，可优化字段可能是交换率、百分比收益，包含在ATO的fieldsToOptimize字段中。优化这些字段使求解器能够评估他们的解决方案，并为他们提供的解决方案提供得分，驱动程序验证以防止求解器进行潜在的恶意得分计算。
T \subset set\;of\;user\;defined\;optimizable\;fields
d: number\;of\;default\;fields\;to\;optimise
of_{i}: optimisableField_{i} \;\;\forall \;\; i \in [1, n(T)+d] \; \;\;n(T): cardinality \;\;of\;\;set \;\;T
fieldsToOptimize: abi.encode(of_{1}, of_{2}…..of_{n(T)+d})
f_{i}:optimisableField_{i} \rightarrow fieldValues_{i} \;\; \;\;\forall \;\; i \in [1,n(T)+d]
函数f_{i}接受optimisableField_{i}并返回整体ATO优化实现的定量表示。将这些optimisableField的定性特性映射到fieldValues的特定函数将通过社区和求解器讨论确定，这些字段可能包括各种方面，如桥接声誉和DEX滑点。如果字段未明确提及，则从优化问题中排除。
在意图中未明确说明可优化字段的情况下，将考虑可以优化的默认字段。这些默认字段是通过社区和求解器共识确定的，当为协议启用对新操作的支持时。
所有求解器计算相同的表达式，然后对其进行优化。将有一个函数代表“期望程度”（DoE），求解器试图在T（拍卖时间）时间内优化ATO，该ATO对求解器有效。DoE只包含显式最大化用户期望的值
DoE_{operation}\propto \frac{fieldValues_{positiveQuality}}{fieldValues_{negativeQuality}}
fieldValues_{positiveQuality}：代表ATO的数值（在优化optimisableField时获得的值），这些值与操作的DoE直接成比例。例如，这可以是桥接操作中桥接的声誉。基本上是量化表示ATO字段，优化后为用户提供额外价值。
fieldValues_{negativeQuality}：代表ATO的数值，这些值与操作的DoE成反比。例如：与相当大的滑点交换。同样，它是量化表示ATO字段，以积极方式优化可能导致用户损失的字段。
对于特定的ATO_{i}，其中ATO_{i} \in [ATO_{1}, ATO_{n}]，我们从所有求解器[solver_{1},solver_{m}]获得解决方案，并以求解器_{j}对\(ATO_{i}\)的DoE的形式表示为DoE_{solver_{j}}{ATO_{i}}
以更简化的方式，我们可以表示为：
DoE_{solver_{j}}{ATO_{i}}：特定ATO_{i}的期望程度，由求解器_{j}提供
对于特定的ATO_{i}，我们从求解器获得所有可能的DoEs，特定ATO的获胜DoE定义为所有这些值中的最大值：
DoE{ATO_{i}} = \max (DoE_{solver_{1}}{ATO_{i}}, DoE_{solver_{2}}{ATO_{i}},……., DoE_{solver_{m}}{ATO_{i}})
为其ATO提供最大DoE的求解器将被宣布为获胜求解器，与该ATO对应的解决方案将被接受进入最终交易捆绑包。
贪婪与DP方法
如果我们将所有ATO_{i}的所有获胜解决方案的总和形成意图I，以计算意图的总期望程度(TDoE)，我们得到这个表达式：
TDoE=\sum_{i=0}{n} DoE{ATO_{i}}
目前，我们正在采取贪婪方法来解决问题。在当前方法中，我们专注于优化当前ATO的DoE，目前我们不考虑先前DoE对当前DoE计算的影响，关于优化。现在我们只是使用先前的ATO解决方案来完成当前ATO的优化问题。
我们可以通过一个例子来理解这个问题：
意图：我在polygon上有10个USDC，用它快速给我在Gnosis上最多USDT。
上述例子导致形成两个ATO，第一个是将USDC代币从polygon快速桥接到Gnosis，另一个是在Gnosis上以最佳汇率将USDC代币交换为USDT。
在当前基础设施中，我们认为桥接求解器会解决第一个ATO，并提出使用最快桥接的解决方案，但该桥可能不会在目标链上以最佳汇率提供代币。尽管考虑到ATO，目的地链上的交换将以最低滑点（即最佳汇率）发生。
这通常是一个相对困难的问题，我们将首先采用贪婪方法进行实施。
解决方案仿真和协议
在接受任何解决方案之前，驱动程序有责任模拟解决方案，确保它与求解器共享的得分承诺一致。值得注意的是，驱动程序和求解器都使用共享的评分机制。这种相互理解要求求解器最初在自己的端上评估解决方案。这种评估基于求解器采用的优化技术以及驱动程序提供的状态信息。一旦对结果满意，求解器随后将得分连同解决方案一起承诺给驱动程序。
有趣的是，得分计算的责任完全由求解器承担。这种方法的原因是为了防止驱动程序承担评估每个ATO的责任。收到解决方案后，驱动程序开始模拟得分最高的解决方案，参考先前的状态数据。如果这个仿真与求解器最初共享的得分产生共鸣，解决方案就被誉为获胜者。此外，负责获胜解决方案的求解器随后被标记为解决特定意图的激励的受益者，该ATO是该意图的一部分。
然而，可能会出现差异。如果驱动程序的仿真产生的得分与求解器的承诺不匹配，将对提供解决方案的求解器进行惩罚。然后，驱动程序将继续模拟下一个得分最高的解决方案。这种仿真和得分验证的过程一直持续，直到驱动程序找到一个与最初承诺的得分相匹配的解决方案。
解决方案接受和聚合
在接收ATO捆绑包后，驱动程序的任务是在将它们广播到求解器之前，为每个ATO附加特定标签。这些标签起着关键作用，使驱动程序能够稍后辨别每个ATO与其相应意图的联系以及其在捆绑包中的顺序。具体来说，可以使用诸如（bundleHash，bundleOrder）之类的标签来追踪ATO。
这里，bundleHash表示ATO所属的捆绑包，而bundleOrder指示ATO在该捆绑包中的位置。
这些标签随后引导驱动程序将所有ATO解决方案汇总到各自的捆绑包中。一旦聚合，驱动程序然后将这些综合解决方案返回给客户端，将它们作为其特定意图的解决方案呈现。
此外，通过在链上通过协议合约维护和更新的声誉得分来约束求解器。这个得分随着求解器提供的每个获胜解决方案而进行修订。这个声誉得分不仅帮助驱动程序在求解器的激励过程中，而且还作为一个性能基准。如果求解器的声誉低于设定的阈值，他们可能会被系统排除。
求解器激励：为他们的计算奖励求解器
我们正在探索各种求解器激励策略，并确定了几个潜在的方法。我们对对话持开放态度，并欢迎对替代方法的建议。以下是我们正在考虑的一些方法：
交易费用模型
从像CowSwap这样的平台中汲取灵感，这种方法涉及为用户提供估计的交易费用（可能由驱动程序确定并返回）。基于这个估计，我们然后可以从用户发起的操作中扣除所需的费用。
预付费余额系统
设想为一个“油箱”，这种方法允许用户提前存入资金，有效地预付访问我们基础设施的费用。当用户发起操作时，解决他们意图的关联费用会自动从这笔预存余额中扣除。
意图执行模块
我们提议在SCW内集成一个专业模块。在这种情况下，当用户向驱动程序RPC提交意图时，他们会收到一个唯一的哈希。这个哈希作为一个参考链接到获胜求解器的地址。对于意图的链上执行，用户必须调用模块的函数，输入相关的哈希。然后，该模块与驱动程序联系以获取费用报价。一旦确定，费用与提供的报价相符，通过模块发送给驱动程序以进行分配。在成功的费用转移之后，驱动程序随后为模块提供捆绑交易的调用数据以促进执行。
MSCA：促进支付和执行的模块
我们正在开发阶段的一个专业4337兼容模块，旨在通过引入基于意图的交易执行能力来增强智能合约钱包。许多公司如Rhinestone、Safe、Biconomy等都在设计模块化智能合约钱包，目标是使其与它们的架构兼容。这个模块旨在简化执行用户意图、调用数据检索的过程，同时无缝集成一个机制为求解器激励。以下是该模块旨在提供的关键时刻和功能：
模块激活：
激活后，模块将发出信号，表明相关智能合约钱包现在能够支持基于意图的交易执行。这个声明作为外部实体的绿旗，确保兼容性和准备就绪，以进行基于意图的交互。
报价和费用处理：
该模块将包含预定义的方法，以便于检索解决意图所需的费用报价。在意图执行之前，模块将自动从智能合约钱包的余额中扣除报价的费用。随后，这笔金额将被引导到指定的驱动程序合约中，作为求解器的激励。
意图执行：
该模块的核心功能之一是实现用户意图的执行。这包括处理意图，将其转换为可执行的交易，并确保使用模块公开的方法正确执行。
调用数据检索：
为了确保准确和完整地实现用户意图，该模块将具备从驱动程序获取用户意图所需的调用数据的能力。
结论
在我们对基于意图的架构的探索中，我们已经检查了各种组件，包括求解器网络、内存池、将意图表示为ATO，以及求解器激励的细微差别等。虽然我们已经勾画了某些方面，但仍有一些元素，如激励和解决方案评估的机制，其中更精细的细节正在讨论中。
未来，所提出的解决方案可以以各种方式集成，这取决于ATO生成方法。我们基础设施的核心是将多种构造——无论是流动性、代币还是数据——聚合到多个领域。通过整合广泛的求解器，我们旨在处理各种操作，确保最终用户的无缝和高效体验。
应考虑此文档可能潜在地存在一些不准确之处，因为其主要目的是社区反馈。
