Uniswap v4 学习 —— 单例和Hook
理解 uniswap v4 需要掌握两个概念: 单例和 hook。一个一个讲。
原文作者:zelos
原文来源:Antalpha Labs
uniswap 在其 github 上放出了 v4 的预览版。在我们阅读代码后,将尽可能在少引用代码的情况下,做一个简单的 V4 前瞻。理解 uniswap v4 需要掌握两个概念:单例和 hook。我们一个一个讲。
单例
网络手续费
我们讲单例模式首先要了解单例着重要解决什么问题。这个问题是网络手续费。不需要太深入到 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.router 找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 的用户能定义的。当然用户可以用脚投票选一个自己喜欢的。
这里我故意先使用了非常抽象而不是非常具体的描述方式,因为过于具体会限制想象力。我们马上会给出具体的例子。
我们进一步学习代码后,需要大家注意的是下面几点:
关于【Uniswap v4 学习 —— 单例和Hook】的延伸阅读
Uniswap 投票延迟,代币持有者沦为二等公民了吗?
Uniswap基金会推迟了决定是否升级协议的投票,以奖励UNI代币持有者。这是因为一位利益相关者提出了新问题,需要更多审查。这不是第一次推迟投票,也不是代币持有者与其他利益相关者冲突的唯一一次。Uniswap V3的推出引发了关于费用转换的讨论,但最终无果而终。这反映了DeFi协议中代币持有者并非最终决定权的教训。
IOSG:从用户视角重新定义Web3项目和Token-market-fit
创业团队应更关注用户需求,而不是假设。设计UI/UX时应简洁直观,移动端体验需要优化。在加密领域,吸引长期用户比短期增长更困难。空投已成为获客捷径,但需要思考其目的性和管理预期。Token的价值反映了市场对项目的共识,可以通过预期收益和叙事来吸引投机者。用户体验也很重要,注意力是稀缺资源,Crypto项目难度比以前更大,但用户需求仍是最重要的。建议Crypto创业者从用户需求出发思考。
- 1. 构造一个 pool,需要指定 hook。
- 2. hook 也没有后续修改的方法。pool 和 hook 绑定。当然 hook 也可以是一个可升级合约。
- 3.如果想做一个符合自己需求的 hook,那要构造一个新的 pool
- 4.仅仅是 hook 不同,同一个交易对可以有多个 pool
官方给了几个例子,其中比较有学习意义的是现价单的 hook。其实不需要看代码,limit order 做了下面的一些事情
- 1. 管理用户注册的:
- •place order
- •kill
- •withdraw
- 2. 管理时点的:
- • 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 。
免责声明:本文仅代表作者个人观点,不代表链观CHAINLOOK立场,不承担法律责任。文章及观点也不构成投资意见。请用户理性看待市场风险,以及遵守所在国家和地区的相关法律法规。
图文来源:zelos,如有侵权请联系删除。转载或引用请注明文章出处!