以下功能对比摘抄于官网

V4 与 V3

虽然 Uniswap v4 的基础集中流动性与 Uniswap v3 相同, 架构和会计存在一些关键差异。

单例设计

矿池创建
V4:单例合约有助于创建矿池和 还会存储其 state。此模式可降低创建池时的成本 以及执行多跳交换。因为矿池是合约状态,而不是全新的合约本身,所以矿池的创建成本要低得多。

V3:工厂合约负责创建矿池。池是 一个单独的 Contract 实例,用于管理自己的 state。矿池初始化 成本高昂,因为合约创建是 gas 密集型的

Flash Accounting (快速记帐)

V4:单例使用 flash accounting,即解锁 PoolManager 的调用方 允许进行余额更改操作(多次掉期、多次流动性修改等) 并且只需要在序列的最末端执行 token 传输。

V3:因为 V3 中缺少 Flash Accounting,所以这是责任 集成合约执行代币转账,在每次单独调用后,对每个单独的矿池合约进行代币转账

流动性费用会计

V4:应计费用在修改流动性时起到抵免的作用。 增加流动性会将费用收入转化为流动性 仓内流动性降低会自动 要求提取未领取的费用收入。

在创建流动性时,可以提供一个额外的参数 salt。盐用于区分同一池中相同范围的位置。 这种分离可能是简化费用会计的首选。如果两个用户共享相同的 range 和 state 中,集成 Contract 必须小心管理 费用PoolManager

V3:相同范围和矿池的流动性持仓将共享相同的状态。虽然相信 当时 gas 效率更高,整合合约将需要处理费用管理,因为 状态在 Core Pool Contract 上共享

原生 ETH

V4:矿池对支持原生代币,因此 ETH 交换器和 流动性提供者受益于更便宜的 gas 成本降低 转移和取消额外的包装费用。

V3:ETH 需要先包装后再与其他代币配对。 由于包装和转移,这会导致更高的 gas 成本 包装的本机令牌。

用户

仅限 V4:所有者现在可以为其位置设置订阅者。 每次头寸的流动性时,都会通知订阅者合约 或所有者变更。订阅者启用质押/流动性挖矿,但用户不需要 转移他们的 ERC-721 代币。

V3:v3 中的权益质押要求用户将他们的 ERC-721 代币转移到合约上,从而使底层资产面临恶意行为的风险。

我觉得v4的最伟大功能就是实现了单例设计,原先每部署一个流动性池就要部署一个新合约,而V4却不用,它将所有的流动性池保存在一个单例合约中,然后这样的做法会节省很多gas费用,而且还增加了hook钩子的用法,让用户多了更多的体验

hook

在 Uniswap V4 中引入了 hook 的概念,可以在流动性池的调用的生命周期内某些指定点执行一些自定义的逻辑,hook 功能增加了流动性池的灵活性,可以执行更多的富有创造力的功能

Uniswap V4 目前支持在 8 个特定的位置进行 hook 回调:

  • beforeInitialize / afterInitialize
  • beforeModifyPosition / afterModifyPosition
  • beforeSwap / afterSwap
  • beforeDonate / afterDonate
    它的功能的案例也很齐全,在官方编写的hook案例可以看见如下几个例子:
  • 几何平均预言机(GeomeanOracle.sol)
  • 限价单(LimitOrder.sol)
  • 时间加权平均做市商(TWAMM.sol)
  • 波动率预言机(VolatilityOracle.sol)

Flash account

在 Uniswap V4 中一个新的设计是 Flash accounting。在 Uniswap 的早期版本中,像 swap 或者 addLiquidity 等操作都是以代币的转移结束,而在 V4 中,每一个操作会更新内部的一个净余额(delta),在所有操作结束时会校验该值是否为 0,必须保证该值为 0 才能交易成功。当 Flash accounting 和 Singleton 结合时,可以大大简化多跳交易。在 PoolManager 合约中新增了 take 和 settle 函数,分别用于向池中借出、存入资金,通过调用这两个函数,保证调用结束时不欠 PoolManager 合约或调用者任何代币。