在少引用代码的情况下，做一个简单的 Uniswap v4 前瞻。

撰文：zelos

单例

网络手续费

我们讲单例模式首先要了解单例着重要解决什么问题。这个问题是网络手续费。不需要太深入到 opcode 计价表，区分 calldata 和 storage，我们只需要记住一个事实：跨合约调用是昂贵的，写数据是昂贵的。举个例子来说，如果我们观察一个 user->A->B->C 的 uniswap v2 的路由交易，我们需要访问几个合约呢？对于用户来说，只想完成 A-C 的兑换，我们一起来算：

1.  router 合约
2. user A 资产减少变更，需要去 A token 合约登记一下，写入新余额
3. 调用 pairA->B
4. pairA->B 的 B 资产转移到用户 user 地址，需要去 B token 合约登记一下 transfer，写新余额
5. pair B-C 的 的 B 资产增加，user 的资产减少，去 B token 合约登记一下
6. 调用 pair B ->C
7. pair B ->C 的 C 资产减少， B 资产增加

除了传递兑换信息的 router 调用外，其他的 6 次：两次 pair 调用，token 的结算 4 次。单例要解决的就是这六次的调用。我们有机会减少嘛？

pool 不再是一个地址

我们在 v2 和 v3 时，pool 是一个通过工厂合约创造的智能合约。里面有流动性的数据和负责交易的接口。而在 v4 中，多个 pool 都在 pool manager 下面的存储。当我们构造一个新的 pool 时，并没有构造一个新的智能合约，而是在 pool mananger 下多了一些数据。

按照传统软件工程的观点，这么设计耦合严重，所有的代码功能塞到一个文件 / 智能合约里是不太好的。但是对于无情的 gas 计价程序来说，这么做能省下不少 gas，这就是好设计。

但是这么做也有一个明显的问题，就是原来一个 pool 管理两种资产，现在一个 pool manager 管理无数个资产。怎么才能算清楚我账上的 10 个 A token 是属于哪个 pool 的呢？ 这和下一个问题也有关系。

从菜市场到赌场

我们回到 7 次调用的问题，我们只解释了单例为什么能解决 pair 的调用。对于 V2 V3 的模式来说，更像是菜市场买菜。我们每一次 swap 都要钱货两清。然后去下一个档口卖不同的菜。但是对于以太坊的 ERC20 来说，钱货两清这一动作是要支付手续费的。

我们现实生活中有另一种办法管理多个档口的方法，就是赌场筹码。筹码可以出入口清算，至于个别用户是如何亏的、如何赚的，负责兑换的服务员毫不关心，我们只在进门出门清算，中间的输赢并不需要上报银行系统划转资产。而 v2 v3 的菜市场模式中，我们则支付了 eth 来把每笔的清算都写进区块链了，自然就贵了。当然这也不是什么新鲜的方案，这是我们熟悉的 CEX 方案。

但是相较于 CEX，一个智能合约筹码清算方案有额外的优势：如果我们极端一些，如果我们在 A 档口赢了 10 U 的筹码，但是在你跑步去前台清算的路上，赌场倒闭了，那么我们的钱就没有了。not your key ， not your money。 但是 dex 不一样，你化身闪电侠，一笔链上交易的结构中跑了很多 swap 的操作，你会光速但是按照顺序跑完入金，兑换筹码，下场，出场结算。evm 落后的单线程保护你跑得赢，跑得快。当然，我们焦虑也是多余的，一个去中心化交易所是不会倒闭的，更为重要的优势是这一笔交易是可以链接其他 DeFi 的，虽然业务走的多，但是还是 Defi lego 世界的一环。

我们基本讲清楚了单例是如何解决我们说的 7 次调用的问题。至于筹码是如何记账的，为什么大家还在说复式记账法，这部分就需要深入代码讲了。我们先略过。我们再来复习一下 user->A->B->C 的 uniswap v4 的路由交易:

1. 调用 router
2. outer 找 pool manager
3. 兑换筹码
4. 去 pool manager 找 pool 的内部位置
5. 交易
6. 重复 2/3 步骤两次
7. 兑换筹码

那么我们这次调用了几个合约呢？4 个。router、pool manager、tokenA、token C。我们使用了 pool manager 来规避了额外的两次 pair 调用和两次 token b 的记账。

HOOK

一个 pool 有下面八个时点 (v4-core/contracts/interfaces/IHooks.sol)：

• beforeInitialize / afterInitialize(before/after the state of a pool is initialized).
• beforeModifyPosition / afterModifyPosition(The hook called before/after a position is modified)
• beforeSwap / afterSwap(The hook called before/after a swap)
• beforeDonate / afterDonate(The hook called before/after donate)

在这 8 个时点，pool 的创建者可以插入自己的代码。注意，用户可以在 hook 规定好的行为中，选择注册自己期待使用的时点和方法。当其他人触发，例如其他用户交易后，用户可以被动的执行代码。注意，hook 定义权在 pool 的构建者，并不是 pool 的用户能定义的。当然用户可以用脚投票选一个自己喜欢的。

这里我故意先使用了非常抽象而不是非常具体的描述方式，因为过于具体会限制想象力。我们马上会给出具体的例子。

我们进一步学习代码后，需要大家注意的是下面几点：

1. 构造一个 pool，需要指定 hook。
2. hook 也没有后续修改的方法。pool 和 hook 绑定。当然 hook 也可以是一个可升级合约。
3. 如果想做一个符合自己需求的 hook，那要构造一个新的 pool
4. 仅仅是 hook 不同，同一个交易对可以有多个 pool

官方给了几个例子，其中比较有学习意义的是现价单的 hook。其实不需要看代码，limit order 做了下面的一些事情

管理用户注册的：

• place order
• kill
• withdraw

管理时点的：

• afterswap：触发后，查找是否有可执行的 limit order，fill 订单。

这就是 limited order hook 的全部功能。

我们认为 hook 只是一种业务描述思路，如果你想做的业务可以分解成用户行为注册，和时点被动触发行为，那么你的业务就可以迁移到 uniswap v4 中。可以是限价单，可以是时间加权 AMM。

从这个角度出发，我们完全可以处理业务，不能局限于交易场景。借贷、期权、稳定币、NFT 都可以用 hook 重构。swap 处理瞬时业务，ModifyPosition 处理跨期业务。swap 兑换了什么、modifiyposition 了什么其实没那么重要。

这里我臆造一个 hook 作为例子：功能是通过 hook，使我把资产留在里面，不着急退出 uniswap 低手续费平台。

1. 管理用户注册

• mint/burn 会构造单边流动性，把资产以 lp 形式存进去

2. 管理时点

• before swap 时点中 创造巨大抢跑优势，或者用高昂的动态手续费，阻止普通用户 swap

那么我的 pool 是没有交易者会来的，这是一个静态的资金池，我的资产通过 lp 形式暂时存在了 uniswap 里，后续我可以提取出来处理用于其他交易。减少了清算次数。

用 hook 重写业务是一个很确定的方向。为了确保长期竞争优势，uni 的 grant 支持也会强很多。

现在已经有一些项目蓄势待发，等待 v4 上线了。例如下面的借贷协议将和 uniswap v4 一起上线。

https://blog.instadapp.io/oracleless-lending-protocol-on-uniswap-v4/

Uniswap v4 是什么

对于 v4，我们盲人摸象地做两个比较：

uni v4 和 layer 2:

• 相同点：

1. 低手续费优势
2. eth 生态兼容

• 不同点：

1.  v4 项目方需要用 hook 的方式重写
2. 一笔交易内进入低手续费环境再返回 eth 主网，调用其他主网上服务
3. 不需要跨链桥

uni v4 和 云交易所：

• 相同点：

1. 一起开 pool，共享低手续费环境
2. 共享流动性

• 不同点：

1.  v4 不限制业务类型，不一定是交易所
2. v4 共享流动性需要外包给好的路由提供商
3. v4 无准入

我们认为应当以平台的视角来定义 uniswap v4。当达到临界点后，在 eth 手续费的压力下，v4 可能是一个比 layer2 好的方案，会有更多金融业务主动或者被动的从主网迁移到 uniswap v4 平台。尤其金融业务其实相对不复杂，但是安全性要求更高，可以在 eth 主网闪电撤出，缓解 eth 主网的紧急需求。这个角度讲，uniswap 已经打赢了 dex 战争，v4 的竞争对手是 cex 云交易所，matic 这种平台级别的竞争对手。

那么代价呢？

1. 流动性代币 ：没有流动性代币了。或者说这个记账单位不能脱离 uniswap 范围，项目方要在 uniswap v4 的生态里解决问题。
2. 流动性碎片化 ：v3 一个资产对有三个不同手续费池，而 v4 则是完全不同的，这对 router 和 maker 的管理要求更高了。这个的解决办法除了市场博弈也要看 uniswap 社区能不能有一些标准化的方案，U（uniswap）RC 。