iZUMi:如何利用 Uni V4 的限价单功能实现下一代「On-Chain Binance」
2023-06-15 17:59
iZUMi Finance
2023-06-15 17:59
订阅此专栏
收藏此文章

作者:Mac Ren、Lemon Lin from iZUMi Finance


Uniswap 在在 6 月 14 日凌晨发布了 Uniswap V4 版本代码草稿,以便用户公开构建 V4 版本。本文将从代码层面聚焦分析新推出的链上 Limit order 功能并与 iZUMi Finance 在 iZiswap 的链上 Limit order 做相应的对比,并探讨这一功能的更新对 DEFI 和未来 DEX 带来怎样的改变。


Uni V4 链上限价单代码分析:


Uniswap V4 hook 引入的一大亮点是能够实现 fully on-chain 的 limit order, 作为一个重要示例,被官方放到了代码库当中(https://github.com/Uniswap/v4-periphery/blob/main/contracts/hooks/examples/LimitOrder.sol)。


通过仔细阅读源码,我们发现相关的机制与 iZiSwap 类似,实现简洁,具有很大的参考意义。这里我们对比介绍 Uniswap V4 与 iZiSwap 处理 limitOrder 的流程和异同 :


1.首先需要明确的是,UniswapV4 的价格空间不是离散的,这里的 limitOrder 更确切的描述应该是 limitRangeOrder, 这个订单的流动性分布在 [tick, tick+tickSpacing) 上。



与常规的流动性不同,limitRangeOrder 被成交后,不会再反向作为流动性。


iZiSwap 的价格是离散空间,即 limitOrder 更加接近传统的定义,在一个精确的价格上挂单,成交后不再反向作为流动性。

   

2.UniswapV4 和 iZiSwap 均采用 limitOrder 聚合的处理方法,即在同一个区间(iZiSwap 为一个点)上的来自不同的人的 limitOrder 均合并计算一个总的 Liquidity,在 swap 的过程中,交互对象是这个总的 Liquidity。这样处理的好处是,解决了时间复杂度问题。而从用户角度看,两步操作不可避免:即一个 limitOrder 的完整操作过程是,下单,等待成交,claim 成交订单。



3.从实现上看,UniswapV4 与 iZiSwap 均能够满足时间上的正确性,即如果用户 U 在时间点 A 下了一个单,价格为 pa,如果在时间点 B 时的价格满足了 pb > pa,那么用户 U 在任意时间点 C >B 均可以取回自己的流动性订单。


而对于部分成交的情况,UniswapV4 是不支只 claim 部分成交的部分,而将剩余部分保留的。即如果用户在 [0,30)( 假设 tickSpacing 是 30) 下了一个 limitOrder, 而当前价格是 20,那么[0,20) 的成交部分与[20,30) 的未成交部分都需要一并 claim 并 cancel。


并且 UniswapV4 还存在的问题是,因为流动性是区间提供的,如果[0,20) 成交了,再跌落会 10, 那么[10,20) 这段 limitOrder 依然被当成了流动性,而不是 limitOrder 成交后就不再提供流动性的性质。这个本质是因为 Uniswap 的流动性不能在离散价格空间中提供,iZiSwap 的离散价格空间能够精确处理这个问题。


对于这种情况,iZiSwap 引入的是”先到先得“的原则,即任何人都可以随时 claim 成交的部分,保留剩余部分继续挂单。从灵活性上而言,iZiSwap 的处理方案显著灵活一些。”先到先得“的代价是在极端情况下会被机器人摊薄收益,例如价格达到 100,但是没有穿过 100,然后大幅回落到 30,100 上的成交如果没有被及时 claim,会被其他人”先到先得“拿走。但是如果穿过了 100,例如达到了 101,再跌落回 30,可以在任何时候 claim 自己的成交量。



4.实现 limitOrder 的关键在于如何处理价格穿过就不再作为流动性的问题。UniswapV4 与 iZiSwap 均提供了巧妙的处理办法,并且在实质上是相同的,即对于完全成交的 limitOrder,寻找一个空间存起来,等待用户 claim。



UniswapV4 维护了一个单调递增的 Epoch,在某个 R = [tick,tick+tickSpacing) 上,如果这个 R 上的 limitOrder 全部被成交了,那么 Epoch 会增加,旧的 Epoch 的信息被封存,等待用户 claim。


iZiSwap 的做法是如果在一个点上的 limitOrder 全部成交,那么成交部分会进如 legacy 空间,等待用户 claim。因为成交了之后的归属确定了,所以不需要额外区分 Epoch,利用单调递增的性质,只需要维护一个累积量,相对而言概念和实现复杂一些,但是节省空间。



Dex 未来会发生哪些变化?


Hooks 作为一个工具,使 Uniswap V4 走向基建属性,不少功能可以在此基础上做定制化开发。相当于交易所提供撮合逻辑、执行逻辑、手续费定制、返佣和激励、挂单范围和深度的功能都可以通过 hooks 来设计,加上链上 limit order 功能的实现,使得 DEX 超越 CEX 不再是空想,DEX 有机会在未来五年到十年内达到并超越 CEX 的市场份额。


同时,对于行业的项目方来说,在 DEX 上发币变得容易,对于做市商的依赖变小,甚至还可以要求 LP 加入和 swap 之前做 KYC。


由此可见,未来 Layer2+On Chain Order-book DEX+ 钱包的组合是最好的替代中心化交易所的方案,试想一下,如果你能用资金自托管的安全钱包在 Gas 成本低、安全性有保障的公链环境下,用拥有和 CEX 一样体验的 DEX 进行交易,你还有什么理由继续使用需要 KYC 账号登录、有丢失全部本金的风险的中心化交易所呢?


References


iZiSwap: Building Decentralized Exchange with Discretized Concentrated Liquidity and Limit Order


https://assets.izumi.finance/paper/dswap.pdf

【免责声明】市场有风险,投资需谨慎。本文不构成投资建议,用户应考虑本文中的任何意见、观点或结论是否符合其特定状况。据此投资,责任自负。

iZUMi Finance
数据请求中
查看更多

推荐专栏

数据请求中
在 App 打开