Arch Day 165: 系统设计 — DEX聚合器（1inch/Jupiter）

日期: 2026-09-11 (Day 165) 阶段: 第七阶段 - Web3专题深度 标签: #系统设计 #DEX聚合器 #路由算法 #MEV保护 #Jupiter #1inch

---

核心概念

一句话定义

DEX聚合器的核心是路由优化问题——给定一笔交易，在多个DEX/流动性池之间找到价格最优的拆单路径，同时考虑Gas成本和滑点。

---

系统设计

1. 需求

功能需求: 输入token对和金额→输出最优路由→执行交易 非功能需求: 报价延迟<200ms、支持多链、MEV保护

2. 高层架构

用户 → API Gateway → Quote Engine → Router
                                      ├── Price Fetcher (多DEX价格)
                                      ├── Path Finder (图搜索算法)
                                      └── Gas Estimator
         ↓
     Transaction Builder → MEV Protection → 链上执行

3. 核心组件

Price Fetcher: 实时从Uniswap/SushiSwap/Curve等获取池状态

• 监听链上事件(Sync/Swap)更新本地缓存
• 每个区块更新一次，延迟<1s

Path Finder: 图搜索找最优路径

• Token是节点，Pool是边，权重是价格
• 支持拆单(split routing)：一笔大单拆到多个池
• Dijkstra变体或动态规划

MEV Protection:

• Private mempool(Flashbots Protect/Jito)
• 滑点保护(用户设置最大滑点)

4. Trade-offs

5. 扩展到多链

Jupiter(Solana)方案：利用Solana的低Gas和高速，可以做更激进的拆单。Ethereum需要更保守(Gas敏感)。

---

面试题

问题：DEX聚合器的路由算法如何工作？

回答：将所有DEX的流动性池建模为有向图——Token是节点，Pool是带权重的边(权重=兑换率)。用Bellman-Ford变体找从源Token到目标Token的最优路径。支持拆单：将订单拆成多份走不同路径，用线性规划或动态规划求最优拆分比例。实际中还需考虑Gas成本——有时候看似更优的多跳路由，加上Gas后反而不如简单路由。