现代 DEX： Cow 协议 - 是如何构建的

• 原文链接：mixbytes.io/blog...
• 译者：AI翻译官，校对：翻译小组
• 本文链接：learnblockchain.cn/article…

介绍

CoW Protocol（以及基于它构建的 CoW Swap）属于 DEX 的“求解者(solvers)”类别。

从概念上讲，求解者代表了 CEX 和 DEX 之间的中间地带，结合了类似 CEX 的订单簿，但将订单匹配外包给独立竞争实体，同时在链上完成交易，类似于 DEX。

CoW Protocol 不仅支持简单订单，还支持可编程订单，这些订单可以在保持相同工作流程的同时，加入额外逻辑。这使得交易者能够开发灵活的交易策略，求解者提供高度响应的执行层，而不受链上限制。此外，CoW Swap 的设计能够避免与 MEV 相关的风险，并提供非常有吸引力的滑点限制。 CoW Protocol 中的求解者可以接触到用户的交易，这可能导致恶意行为，通过偷取费用或重排序来利用交易。因此，CoW Protocol 只支持经过批准的求解者列表，要求每个求解者都要支付一笔大额保证金，如果发现任何不当行为，CoW DAO 可以削减这笔保证金。为了鼓励良好行为，CoW Protocol 通过 COW 代币奖励求解者，激励他们为用户的交易寻找最佳解决方案。 这是一个无疑很有趣的项目，接下来让我们深入了解它是如何构建的！

高层设计

CoW Swap 的高层交易流程如下：用户签署“意图”以交换特定数量的代币，并将其添加到链外订单簿。然后，求解者处理这些订单，寻求最大盈余的交易组合，并在拍卖中发布他们的“批次”以选择最佳方案。最佳批次随后提交到链上智能合约中，结算此“最佳”批次中的所有交易。

这种用户订单的链外匹配和一次性交易结算避免了向流动性提供者直接支付费用，并防止了与交易订单相关的 MEV 操作。此外，求解者可以利用他们的流动性来“支持”他们的批次，从而可能为某些交换提供更好的定价。另一个重要的特性是用户可以在不支付原生交易费用的情况下进行交易，因为他们不需要直接与区块链互动。求解者可以改为收集用户提供的代币中的原生代币费用。

用户单独交易的链上结算效率低下，因为每笔交易都需要支付原生交易费用。为了解决这一问题，CoW Swap 采用“批次（batch）”结算，一次处理多笔交易。这种批次是必要的，因为即使有许多不同的订单，也不常见“理想”的确切交换数量。例如，如果用户想买 100 USDT，求解者可能部分使用另一用户出售的 200 USDT 的订单，或者组合两个订单卖出 30 + 70 USDT，或者通过第三种代币进行中间交易，甚至涉及 3 个以上用户的订单以完成复杂的“轮次（round）”交换。这些情况在 这里 中有详细说明。解决这种交换的真实案例可以在 这里 找到。

在 CoW Protocol 中，使这些批次有效的一个关键概念是“统一清算价格”。同一批次中的所有交易对于相同的 token1/token2 对都使用这个相同的清算价格；否则，解决和证明最佳批次的过程将无法有效进行。在某些情况下，这一方面甚至可以改善交易。例如，当批次中特定订单的统一清算价格优于“波动”价格时，整个订单组将变得更具盈利性。我们将在本文中多次重温这一概念。

在 CoW Protocol 中，订单可以有所不同并实现不同类型的逻辑，例如：

• 简单订单（数量 + 价格）
• 限价订单（数量 + 价格 + 到期日期），可以持有直到达到目标价格
• TWAP 订单 - 一笔大的订单分解成多个小的限价订单，以允许顺序执行并保持每个部分的滑点容差更紧
• 程序化（Programmatic）订单 - 最强大的一种，允许通过检查链上条件（如价格、阈值和时间）来实施任何逻辑
• Milkman 订单 - 在交换时可由外部预言机给出的价格执行
• CoW Hooks - 在执行前后允许订单执行动作的钩子，例如解押/质押资产或签署代币授权

这些订单类型在文档的 这一部分 中有更详细的说明。上述所有类型使 CoW Protocol 具备显著的灵活性，能够使交易者实施多样化的策略。

处理订单批次的求解者必须竞争以提供最佳解决方案。为了确定最佳解决方案，使用一个最大化函数，如 这里 所述。这个函数处理订单集合，按顺序接受“输入/输出”代币的数量（x 和 −y）、交换价格 π，并减去订单费用。为了在不同代币之间标准化这一度量，函数的非负结果以“公共货币单位”表示（例如，以 ETH 表示），其价格由预言机确定。每个求解者提出他们的解决方案，该解决方案的 质量（quality） 定义为：

这里，U(o) 是每个订单的 盈余 函数，f(o) 是每个订单的 费用，p 是费用单价（确保整个质量结果以“公共货币单位”进行度量）。

在选择最佳求解者后，奖励他们至关重要，以激励他们不仅赢得拍卖，还为用户寻找最佳解决方案。获胜求解者的奖励表示为：

其中，observedQuality 是所呈现“最佳”解决方案的质量（在结算时观察），referenceQuality 是第二最佳解决方案的质量，cap() 函数使用预定义的上下限来限制支付（cl, cu) = (0.010, 0.012) ETH。奖励逻辑在 这里 中有详细说明，提到在某些情况下（当最佳和第二最佳解决方案之间的差异很大时），求解者可能会呈现“少报质量”，但这种行为需要求解者付出相当大的努力，因此在当前方案下是可接受的。该方案还考虑了在求解者通过外部 AMM 交换他们的流动性时可能发生的滑点。这一点也在 这里 中进行了描述。

CoW AMM

CoW Protocol 中的另一个关键组件是 CoW AMM。为了满足订单，求解者应使用外部 AMM（如 Uniswap 或 Balancer）进行交换。然而，这种交换容易受到 MEV 和套利的影响，而保持用户盈余对求解者来说至关重要。此外，前面提到的“统一清算价格”适用于相同代币对的整个订单批次，促进最佳订单批次解决方案的形成。因此，CoW AMM 被设计为支持交易批次，而不是以统一价格执行的单次交换。讨论这一 AMM 设计的论文是

这里。

CoW AMM 仓库（与 Balancer 合作开发）在

这里

。我们不会深入探讨 CoW AMM 的实现，但与 CoW 协议的主要集成点包括：

• 设置 SOLUTION_SETTLER 地址，授权“提交”交换订单
• 提交订单哈希，仅由 SOLUTION_SETTLER 执行
• 检查 isValidSignature() 函数中的订单提交（验证订单签名）
• swapExactAmountIn() 和 swapExactAmountOut() 函数
• 用于从给定参数构造 CoW 协议的 GPv2Order.Data 订单的辅助函数（如下所述），例如 orderFromBuyAmount 或 orderFromSellAmount

拥有这样的“提交” AMM 使得求解者在许多情况下能够在 CoW AMM 中结算交易，而不是使用 Uniswap、Balancer 或 0x 交换池。这种方法简化了批次的统一价格实现，促进了所有描述的方案，其中用户订单被部分填充或组合，以为用户提供最佳的盈余，同时提供防止抢跑的保护。

现在，让我们继续 CoW 协议的实现。

核心

CoW 协议（前称 Gnosis 协议）的代码库可以在

合约仓库 找到。 我们从 GPv2Order.Data 结构体 开始，该结构体保存订单数据，包括：

• 被交换的代币和接收者的地址和金额。
• uint32 订单过期时间。
• 额外的 bytes32 appData 用于与订单交互的外部应用。该字段包含一个 IPFS 哈希，指向包含元数据的 JSON，其中可以包括推荐地址、外部 ID 和其他选项。
• 订单的费用 金额。
• bool partiallyFillable 标志，指示订单是否可以部分填充。
• bytes32 kind 订单类型，这是字符串“buy”或“sell”的 keccak 哈希。这允许与 EIP-712 兼容的钱包为该字段显示描述性字符串。
• bytes32 values（卖/买）TokenBalance，指示买/卖代币余额的“来源”：直接 用户的 ERC20 余额，批准 用户的 Vault（将在下面描述），或 内部 Vault 本身的余额。哈希的使用方式与订单类型类似。

接下来，我们讨论 CoW 协议的关键核心合约，该合约处理用户的签名订单，使其可...