T20 · DEX Architecture

一个现实问题

T19 的池子跑通了，你把它接上前端。

前端做的事很直接：读取两侧储备，套一遍报价公式，显示「1 ETH 约等于 3000 USDC」，用户点确认，调合约的 swap，把算好的输出数量传进去。

本地测试完美。上线第二天，用户投诉分成两类：

• 一类是交易失败。 点了确认，钱包弹窗，签名，然后 revert，Gas 照扣。
• 另一类更糟：交易成功了，但到账金额和页面上显示的对不上。 页面写 3000，实际收到 2890。

你把那笔交易翻出来看，池子没被攻击，合约没有 bug，报价公式也没算错。那 110 USDC 去哪了？

答案藏在一个你从没认真想过的问题里：你看到报价的那一刻，和这笔交易真正在链上执行的那一刻，中间隔了多久？

大概是十几秒到几分钟。在这段时间里，池子的储备已经变了——可能是别的用户正常交易，也可能是有人看到了你的交易，抢在你前面动了手。

你的前端把报价、选路和执行三件事捏在了一起，还把它们中最脆弱的一件——报价——放在了链下。这一章就是把这三件事拆开。

思想实验

先离开链上。想象一个机场的换汇柜台。

一次换汇其实经过三道工序，由三个不同的角色完成：

1. 门口的牌价板：告诉你今天大概什么价。它每隔一会儿刷新一次，上面明确写着「仅供参考」。
2. 柜员：接过你的钱，判断走哪条路——直接换、还是先换成美元再换成目标货币、还是拆成两笔走不同的额度。
3. 金库：真正把钱点出来交给你。

在机场，这三道工序在同一分钟内完成，所以你几乎感觉不到它们是分开的。

链上不一样。这三道工序发生在三个不同的时刻：

t0   你的浏览器读取池子储备，算出报价，显示给你       （链下，只读）
t1   你签名，交易进入内存池                         （链下，公开可见）
t2   区块生产者把它打包并执行                       （链上，此刻状态可能已完全不同）

t0 到 t2 之间，池子可以被任何人改变。更关键的是 t1 到 t2 之间：你的交易在内存池里是公开的，任何人都能看到你要用多少钱买什么，并且可以选择抢在你前面成交。

现在回到牌价板那个比喻。如果柜员说：「按牌价板执行」，而牌价板在你走到柜台的路上被人改了，你会收到什么价格？

你唯一能做的，是在把钱递过去的时候说一句：「低于这个数我就不换了。」

这句话，就是这一章最重要的一个参数。

你来决定

回到那个兑换函数。你要让用户不再收到「和页面显示不符」的金额。你怎么改？

观察结果

三个参数，防三件不同的事。把它们排在一起，结构就清楚了：

注意最右边那一列是同一句话：这三个参数都必须由发起者签名。

这是本章的核心结论，比任何一个参数本身更重要。因为签名是用户唯一能施加约束的地方——签名之外的一切，包括前端代码、后端服务、RPC 节点、Router 合约，在交易被打包的那一刻都已经不在用户的控制之下了。

还有一件反直觉的事值得单独说：

你设的滑点容差，就是你主动挂出的悬赏金额。

如果你允许 5% 的滑点，那么任何人只要能通过抢跑从你身上榨出 5% 以内的利润，这笔交易就依然会成功——你不会收到任何异常，链上看起来一切正常，你只是按容差的边缘成交了。

很多钱包为了「让交易别失败」，默认给了一个偏大的容差。用户看到交易成功了，以为一切正常。滑点容差不是一个体验参数，它是一个风险预算。

建立模型

把一次兑换拆成三层，每一层的职责、位置和成本都不一样：

一条必须记住的原则：链下算路径，链上只验结果。

不要试图在合约里枚举所有池子找最优路径。一是 Gas 昂贵得离谱，二是——更重要的——链上看到的储备本身就是可以被操纵的。攻击者可以在同一笔交易里先改变某个池子的状态，诱导你的链上算法选一条对他有利的路径。

把选路留在链下，把路径当成用户意图的一部分签进交易，链上就只剩下一件不可争议的事：按这条路走完，我到底收到了多少。

Router 的骨架大概长这样：

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

function swapExactTokensForTokens(
    uint256 amountIn,
    uint256 amountOutMin,     // 下限，由发起者签名带入
    address[] calldata path,  // 路径，由链下算好
    address to,               // 收款人，由发起者指定
    uint256 deadline          // 过期时间，由发起者指定
) external returns (uint256 amountOut) {
    require(block.timestamp <= deadline, "EXPIRED");
    require(path.length >= 2, "BAD_PATH");

    _transferFrom(path[0], msg.sender, _pairFor(path[0], path[1]), amountIn);

    uint256 amount = amountIn;
    for (uint256 i = 0; i + 1 < path.length; i++) {
        amount = _swapOneHop(path[i], path[i + 1], amount, i + 2 == path.length ? to : _pairFor(path[i + 1], path[i + 2]));
    }

    amountOut = amount;
    require(amountOut >= amountOutMin, "INSUFFICIENT_OUTPUT");
}

四个细节：

1. deadline 检查放在最前面。 过期了就不要再做任何事。
2. 中间跳的接收方是下一个池子，不是 Router 自己。 这样可以少一次转账，也避免资金在 Router 里短暂停留。
3. amountOutMin 的检查放在最后。 它检查的是最终到账，不是中间任何一跳。中间某一跳滑点很大但总额达标，交易照样应该成功。
4. Router 自己不持有任何资金。 一个设计良好的 Router，在两笔交易之间的余额应该是零。

至于两跳为什么有时比一跳好，把数学摊开就明白了：

直接换：A -> C
  只有一个池子，深度 D1，你的交易全部由它承担

两跳：  A -> B -> C
  第一跳深度 D2，第二跳深度 D3，滑点分别产生但都更小
  代价：多付一次手续费（0.3% 变成约 0.6%），多一次 Gas

什么时候两跳更划算：
  当 A/C 这个池子很浅，而 A/B 和 B/C 都很深时
  临界点：直接换多付的滑点 > 多出来的那 0.3% 手续费 + 额外 Gas

这就是路由算法要回答的全部问题。 它不是在找「最短路径」，而是在权衡滑点与手续费。

它叫什么

动手

A/C  一侧 10 万        （浅）
A/B  一侧 500 万       （深）
B/C  一侧 500 万       （深）

已知：你的交易金额 V，滑点容差 s，池子一侧深度 D

1. 攻击者要先把价格推到让你恰好在容差边缘成交
2. 他的本金需求：用 T19 的公式反推，约等于 D * (sqrt(1+s) - 1) 的量级
3. 他的毛利：约等于 V * s
4. 他的成本：两笔交易的手续费（约 0.6% 的本金）+ 两笔 Gas + 抢跑出价
5. 净利 = 毛利 - 成本，大于零他就会做

AI Lab

第一步：
设计一个 DEX 路由算法。已知若干个恒定乘积池子的储备量与手续费率，
给定输入资产、输出资产和输入金额，求最终到账最大的路径。
说明你的权重函数是什么，以及为什么不能用最短路径算法。

第二步：
给出三种会让你的算法给出次优路径的情况，
每种说明：什么样的池子结构会触发、错在哪、代价有多大。
另外说明：如果允许把一笔交易拆成多段走不同路径，算法要怎么改，
以及拆单带来的额外 Gas 成本在什么金额以下就不划算了。

真实案例

改一个变量

带走的问题

本章自测