我的 Uniswap V4 学习笔记

欢迎大家来参加技能进阶挑战!

在本帖下用回复的方式上传你的学习笔记完成打卡 :partying_face:

Uniswap V4

新特性

  1. 单例架构 Singleton Pool 与 ERC-6909 协议

到 V3 为止,协议有两个独立组件:factory 和 pool。每当一个新池被创建时,factory 合约就会部署一个新的 pool 合约;然而在 V4 中,一个名为 PoolManager单一合约管理所有池,会使得在多个池之间的交换路由变得更便宜。在一次交易的开始和结束时,仅执行一次余额更新,而不是为每个池单独修改余额,大大简化了路由和降低成本;而且现在进入池的方式只需要调用 PoolManager 合约的一个函数,部署成本显著降低。

V4 使用 ERC-6909 代币来结算增量(由于交换或其他池交互而导致的代币余额差异)和 PoolManager 中的代币管理。这是对 ERC-1155 的一种 Gas 优化替代方案,专门针对在单个合约中管理多个代币而设计。V4 在标准的 ERC-6909 接口外提供了 mint 函数,可以为用户铸造某种代币的 ERC-6909 包装版本:

function mint(address to, uint256 id, uint256 amount) external onlyWhenUnlocked {
    unchecked {
        Currency currency = CurrencyLibrary.fromId(id);
        // negation must be safe as amount is not negative
        _accountDelta(currency, -(amount.toInt128()), msg.sender);
        _mint(to, currency.toId(), amount);
    }
}
  1. 闪电结算 Flash Accounting

V4 在交换或其他流动性操作期间追踪池和用户之间的未清余额。系统不会立即结算每一笔交易,而是确保所有未清余额仅在交易结束时才得到完全清算。

V4 使用 PoolManager 合约里特殊的 unlock 函数解锁合约内的余额修改,从而允许进行修改。unlock 函数有两个目的:防止重入攻击,即一笔交易执行两次函数;调用 Router 的回调函数,处理实际的交换逻辑。实际的交换处理发生在回调函数 unlockCallback 内,通过调用多个 PoolManager 内的函数来执行请求的操作。当 unlockCallback 结束后,unlock 函数会检查 NonzeroDeltaCount,如果没有实现平衡,就会 revert 交易。

  1. 钩子 Hook

V4 允许池创建者通过钩子自定义他们的池,添加额外逻辑和新功能。钩子合约通过其实现的函数编码到其合约地址中与 PoolManager进行通信。这一编码的关键部分是钩子地址的最后四个十六进制数字(16位),表示钩子实现了哪些函数。

beforeSwapReturnDataafterSwapReturnData 两个权限代表 hook 在兑换过程中修改 hook 地址对应的代币,意味着被赋予这个权限的话,hook 可以在兑换过程中掌握一部分代币。

beforeSwap 更新当前的 LP 费率、修改用户的 amountToSwap、修改 hookDeltaafterSwap 修改 hookDelta

除了定制外,hooks 的实现也是更广泛的 V4 安全模型的一部分,通过 解锁回调系统,这是其安全架构的关键部分。任何可能应用增量的函数都可以在解锁时调用,并在再次锁定之前验证增量。

在研究 V4 時,感覺整個 DeFi 的邏輯又往前進了一大步。不得不說,V4 不只是性能提升,還增加了許多可以讓開發者發揮創意的功能,可以進一步擴大生態系:

Singleton + Flash Accounting

  • Singleton 合約設計:V3 是每個交易對各自一個合約,舉凡 Pool 建立、Multi‑hop 都要跑很多合約 call,很吃 gas;而V4 則把所有池子統一存在一個 PoolManager 裡,建立池子、交易流程都變得更順更便宜。
  • Flash Accounting:以前 swap 完交易、再扣 balance,每個中間步驟都要寫鏈上狀態。V4 則是把所有變動暫存起來,最後結算一次,省 gas 也更有效率。

Hooks

V4 引入 Hooks,讓開發者可以在 swap、add/remove 流動性前後裝進自定義邏輯,宛如 AMM 的插件系統,開發者可以做到:

  • 做限價單 (limit order)
  • 套入 price oracle、動態調費 (dynamic fees)
  • 自動調整流動性
  • 設計新的交易曲線,甚至跳脫原本集中流動性模型。

換句話說,V4 不只是讓 LP 提供流動性,同時還可以定義「這個池子行為是什麼」,非常自由。

調費更多元、效能更好

  • 原生支援 ETH:不需要 wrap/unwrap 的 WETH,也省了一筆操作費用、節省不少 gas 。
  • 動態手續費:不像 V3 固定 0.05 / 0.3 / 1%,V4 可以調整成任意頻率、任意模式(swap、每區塊、每日、甚至更長)。

訂閱者機制

V4 新加入 Subscribers 機制,允許你設定一個訂閱合約,當每次 LP position 變動時,它都會收到通知,這讓 staking、liquidity mining 可以不必轉移 NFT(ERC‑721),更加安全更高效 。

V4 vs V3

特性 V3 V4
資本效率 高(集中流動性) 同樣高,但成本更低
gas 成本 高,需部署 Pool 合約 低,採 Singleton + Flash Accounting
自定義能力 Hooks + Dynamic Fee + Subscriber 超自由
ETH 支援 必須 wrap 原生支援
複雜度 普通 比較高,需要懂 Hook 邏輯

心得 + 小觀察

如果說 V2 是「人人會用的自動販賣機」、V3 是「高效率版 AMM」,那 V4 就是「可編程的 AMM 工具箱」。

  1. V4 已經不是單純 AMM,它更像 AMM + 插件市場,讓任何人都可以打造獨特交易模式。
  2. 對開發者來說,是個超級 toolbox;對 LP 而言,如果你懂策略設計,那收益+彈性都來了。
  3. 但 Hooks 太自由,攻擊面也變多了,需特別注意安全性、審計、測試。
  4. V4 已經火速部署到好幾個鏈(像 Ethereum、Polygon、Arbitrum、Base…等),看起來生態正在快速起飛。
  5. 雖然 V4 最多 gas 省 99% 的 headline 聽起來很猛,但實際上還是要配合路由最佳化、hook 輔助、合約優化才能真正省下來。

V4

一、架构革新:从工厂模式到单例模式(Singleton)

全局合约整合
摒弃 V2/V3 的工厂合约模式,所有流动性池统一由 Singleton 合约(PoolManager.sol) 管理,池数据通过 poolId 映射存储于合约内部。此举将创建新池的 Gas 成本降低 99% ,解决了多版本中独立合约部署的高成本问题

闪电记账(Flash Accounting)
基于 EIP-1153 的瞬时存储(Transient Storage),引入 净余额(Delta) 机制:

所有交易操作(如 Swap、添加流动性)仅更新内部 Delta 值,最终通过 settle() 与 take() 函数统一结算代币净余额,确保交易结束时 Delta 归零

优势:减少多跳交易中的冗余转账,跨池操作 Gas 消耗显著降低,同时支持原生 ETH 直接交易(无需 WETH 包装),节省约 50% Gas

二、核心创新:钩子机制(Hooks)的可编程性

生命周期钩子
Hooks 是智能合约模块,可在流动性池的 8个关键生命周期节点(如初始化、Swap前后、修改头寸前后等)插入自定义逻辑。开发者可通过继承 BaseHook 合约重写函数实现以下功能

动态费用调整:根据市场波动或交易量实时变更手续费率;

复杂订单类型:支持限价单、TWAMM(时间加权平均价格订单);

预言机扩展:集成波动率预言机或自定义价格计算模型;

流动性再分配:将闲置资金自动存入借贷协议以提升收益。

Hook 地址与 Flag 控制
Hook 合约地址的二进制位决定触发节点(如 0x01 对应 afterDonate),通过 PoolKey 结构体与池绑定。结合 beforeInitialize 和 afterInitialize 等回调,实现灵活的策略注入

三、技术优化与功能增强

ERC-6909 代币协议
引入类似 ERC-1155 的多代币管理标准,允许单一合约处理多种资产,提升资金结算效率。通过 mint() 和 burn() 函数映射外部代币与内部资产,支持闪电借贷与复杂策略的无缝集成

动态费用与捐赠功能

分级费率:支持 0.01% 至 1% 的多级手续费配置,由 Hook 或治理动态调整

donate() 函数:用户可直接向特定价格区间内的 LP 捐赠代币,激励目标流动性,优化市场深度

四、安全与治理升级

安全机制强化

采用 瞬态存储 避免重入攻击,结合 onlyWhenUnlocked 修饰符限制关键函数调用权限

发布前通过高达 1550 万美元漏洞悬赏计划 进行多重审计,确保合约安全性

治理与许可模型

协议参数(如费用开关)由 UNI 代币持有者通过 DAO 治理决定;

采用 Business Source License 1.1,四年内限制未经许可的分叉,保护核心知识产权

五、市场影响与挑战

行业意义

DEX 标准化:Hooks 的可组合性推动 Uniswap 成为 DeFi 基础设施层,吸引开发者构建创新应用(如自动复投策略、链上衍生品)

CEX 竞争:动态费用与复杂订单类型缩小与中心化交易所的功能差距,可能提高链上交易占比

潜在风险

Hook 安全风险:恶意 Hook 合约可能引入漏洞(如资金窃取),需严格审计;

LP 管理复杂度:集中流动性区间需主动调整,对散户用户不友好

六、总结与展望

Uniswap V4 通过 可编程钩子 和 单例架构 实现了协议层的范式跃迁,其核心价值在于:

:white_check_mark: 开放生态:Hooks 赋予开发者无限创新空间,推动 DeFi 应用场景爆炸式增长;

:white_check_mark: 效率革命:Gas 成本降低与原生 ETH 支持提升用户体验,吸引主流资金入场;

:white_check_mark: 治理进化:DAO 治理与许可证模型平衡创新与生态保护。

Uniswap V4 学习笔记

一、Uniswap V4 核心定位

Uniswap V4 并非简单的版本迭代,而是从 “专业化 AMM” 向 “可编程 AMM 工具箱” 的范式跃迁。它通过架构革新(单例模式)、核心创新(钩子机制)与技术优化(闪电记账),在降低 Gas 成本的同时,赋予开发者极致的自定义能力,让 DeFi 生态从 “固定功能协议” 走向 “开放插件平台”,既能满足专业 LP 的策略需求,也为创新应用(如链上衍生品、自动流动性管理)提供底层支持。

二、架构革新:从 “多合约分散” 到 “单例集中管理”

V4 彻底摒弃 V2/V3 的 “工厂 - 独立池” 模式,采用 Singleton 单例架构,所有流动性池统一由 PoolManager.sol 合约管理,这是其效率提升的核心基础。

(一)单例架构(Singleton Pool)

  1. 核心逻辑
  • 不再为每个交易对部署独立 Pool 合约,而是通过 poolId(由代币对、费率、钩子地址等参数生成)将所有池数据映射存储于 PoolManager 内部。
  • 新增池子、执行交易(Swap)、管理流动性等操作,仅需调用 PoolManager 的单一函数,无需跨多个合约交互。
  1. 核心优势
  • 部署成本骤降:创建新池的 Gas 成本较 V3 降低 99%,解决了 V3 中多池分散导致的高部署门槛问题;
  • 跨池操作简化:多跳交易(如 ETH→USDC→DAI)无需多次调用不同 Pool 合约,路由逻辑更高效,进一步降低 Gas 消耗。

(二)闪电记账(Flash Accounting)

配合单例架构,V4 引入 闪电记账机制,彻底改变 V3 中 “每步操作实时结算” 的模式:

  1. 核心逻辑
  • 交易过程中(如 Swap、添加 / 移除流动性),不实时修改链上代币余额,而是通过 “净余额(Delta)” 暂存所有资产变动;
  • 仅在交易结束时,通过 settle()(结算用户与池的净负债)和 take()(提取净收益)函数统一清算,确保最终 Delta 归零(即所有未清余额完全平衡)。
  1. 技术支撑:基于 EIP-1153 瞬时存储(Transient Storage),暂存数据仅在当前交易内有效,不占用链上永久存储,大幅节省 Gas。
  2. 额外价值:支持 原生 ETH 直接交易,无需像 V3 那样将 ETH 包装为 WETH(减少 “wrap/unwrap” 操作),单次交易可节省约 50% Gas。

(三)ERC-6909 代币协议集成

为适配单例架构下的多代币管理,V4 采用 ERC-6909 协议(ERC-1155 的 Gas 优化版本):

  1. 核心功能:允许 PoolManager 在单一合约内管理多种代币,通过 mint()burn() 函数实现外部代币与内部 ERC-6909 包装代币的映射;
  2. 代码示例mint 函数核心逻辑):

solidity

function mint(address to, uint256 id, uint256 amount) external onlyWhenUnlocked {
    unchecked {
        Currency currency = CurrencyLibrary.fromId(id);
        // 计算用户净余额变动(负值表示负债)
        _accountDelta(currency, -(amount.toInt128()), msg.sender);
        // 为用户铸造 ERC-6909 包装代币
        _mint(to, currency.toId(), amount);
    }
}
  1. 优势:简化多代币结算流程,为闪电贷、复杂策略(如跨资产流动性管理)提供高效的代币交互基础。

三、核心创新:钩子机制(Hooks)—— AMM 的 “插件系统”

Hooks 是 V4 最具革命性的功能,允许开发者在流动性池的 8 个关键生命周期节点 插入自定义逻辑,实现 “按需扩展”,彻底打破 V2/V3 功能固定的局限。

(一)Hook 工作原理

  1. 触发节点:覆盖池的全生命周期,核心节点包括:
  • beforeInitialize/afterInitialize:池初始化前后(如设置初始费率、初始化预言机);
  • beforeSwap/afterSwap:代币兑换前后(如动态调费、执行限价单);
  • beforeModifyPosition/afterModifyPosition:添加 / 移除流动性前后(如自动复投手续费、调整区间)。
  1. 地址编码逻辑
  • Hook 合约地址的 最后 4 个十六进制数字(16 位) 是 “功能 Flag”,用于标识该 Hook 实现了哪些生命周期函数(如 0x01 对应 afterDonate);
  • PoolManager 通过解析地址 Flag,自动在对应节点触发 Hook 逻辑,无需额外配置。

(二)Hook 核心能力与应用场景

Hook 赋予开发者极致的自定义空间,典型应用场景包括:

应用场景 实现逻辑
动态手续费调整 beforeSwap 中接入波动率预言机,当资产波动超过阈值(如 ETH 价格 10 分钟涨 5%),自动将费率从 0.3% 上调至 0.5%,补偿 LP 风险。
链上限价单(Range Order) beforeSwap 中设置价格触发条件,当市场价格触及目标价(如 ETH 跌至 1800 美元),自动触发单边流动性参与交易,实现 “低价买入”。
自动流动性管理 afterModifyPosition 中添加逻辑,当 LP 头寸的手续费累积超过阈值(如 100 USDC),自动将手续费复投为流动性,提升复利收益。
自定义交易曲线 突破 V3 集中流动性的 L=√(x×y) 模型,在 beforeSwap 中植入新公式(如线性曲线、阶梯曲线),适配稳定币兑换、衍生品定价等场景。
预言机扩展 afterSwap 中同步更新自定义预言机数据(如记录实时交易量、波动率),为外部 DeFi 协议(如借贷、清算)提供更丰富的链上数据。

(三)Hook 安全机制

  1. 重入防护:通过 unlock() 函数控制合约状态 —— 仅在 unlock 期间允许修改余额,且 unlockCallback(实际交易逻辑执行处)结束后,PoolManager 会检查 NonzeroDeltaCount(未清余额计数),若未平衡则回滚交易,防止重入攻击;
  2. 权限控制:关键 Hook 功能(如 beforeSwapReturnData,允许修改代币余额)需明确授权,避免恶意 Hook 窃取资金;
  3. 审计保障:V4 发布前通过 1550 万美元漏洞悬赏计划 进行多轮审计,Hook 合约需通过严格安全审查才能接入生态。

四、技术优化与功能增强

(一)动态费用与捐赠功能

  1. 动态费率
  • 突破 V3 固定 0.05%/0.3%/1% 费率的限制,支持 0.01%~1% 任意费率,且可通过 Hook 实现 “按交易、按区块、按天” 等多频率调整;
  • 例:稳定币对(USDC/DAI)可设置 “波动低于 0.1% 时费率 0.01%,波动高于 1% 时费率 0.1%”,兼顾交易体验与 LP 收益。
  1. 捐赠功能(donate ())
  • 用户可直接向特定价格区间的 LP 捐赠代币,激励目标流动性(如为 ETH/USDC 的 2000-2200 美元区间捐赠 USDC,吸引 LP 入驻,提升该区间深度)。

(二)订阅者机制(Subscribers)

针对 V3 中 LP 头寸(NFT)参与质押 / 流动性挖矿时需转移 NFT 的风险,V4 新增订阅者机制:

  1. 核心逻辑:LP 可设置 “订阅合约”,当自身头寸发生变动(如手续费到账、区间调整)时,订阅合约会实时收到通知;
  2. 优势:无需转移 ERC-721 NFT 即可参与挖矿,降低 NFT 丢失、被盗风险,同时提升质押 / 挖矿的效率。

五、V4 与 V3 核心差异对比

维度 Uniswap V3 Uniswap V4
架构模式 工厂 - 独立池(每交易对一个 Pool 合约) 单例模式(所有池由 PoolManager 统一管理)
Gas 成本 高(部署、跨池交易需多次合约交互) 低(单例 + 闪电记账,成本降 99%,原生支持 ETH)
自定义能力 固定(仅多费率、集中流动性) 极致灵活(Hooks 支持 8 个节点自定义逻辑)
费率机制 固定三档(0.05%/0.3%/1%) 动态可调(0.01%~1%,支持多频率调整)
流动性头寸管理 ERC-721 NFT(需转移参与挖矿) ERC-721 NFT + 订阅者机制(无需转移)
安全机制 基础重入防护 瞬态存储 + 解锁回调 + 高额漏洞悬赏
开发门槛 普通(无需理解复杂扩展逻辑) 较高(需掌握 Hook 编程与安全审计)

六、优缺点总结

(一)核心优势

  1. 效率革命:单例架构 + 闪电记账 + 原生 ETH 支持,Gas 成本降至 V3 的 1% 以下,大幅提升用户体验与资金利用率;
  2. 生态开放:Hooks 相当于 AMM 的 “插件市场”,开发者可快速构建创新应用(如自动做市策略、链上衍生品),推动 DeFi 场景爆炸式增长;
  3. 策略灵活:动态费率、订阅者机制、自定义交易曲线等功能,满足专业 LP 的精细化需求(如风险对冲、手续费最大化);
  4. 安全可靠:多重审计 + 漏洞悬赏 + 重入防护,降低智能合约风险,同时 Business Source License 1.1(4 年许可保护)平衡创新与生态稳定。

(二)主要缺点

  1. 开发门槛高:Hook 编程需理解池生命周期、瞬态存储等底层逻辑,且需通过严格安全审计,普通开发者难以快速上手;
  2. 安全风险集中:Hook 功能的开放性扩大了攻击面,恶意 Hook 可能引入资金窃取、交易回滚等漏洞,需依赖第三方审计;
  3. 用户复杂度上升:专业功能(如动态调仓、Hook 策略)对散户 LP 不友好,需借助第三方工具(如流动性管理平台)才能高效参与;
  4. 生态碎片化风险:大量自定义 Hook 可能导致池逻辑差异过大,需聚合器(如 1inch)额外适配,增加生态整合成本。

七、学习感想与生态展望

  1. V4 的本质是 “AMM 基础设施化”:它不再是单一的去中心化交易所,而是成为 DeFi 的 “底层操作系统”—— 开发者可基于 Hooks 构建各类金融应用,LP 可基于自定义策略实现收益最大化,交易者可享受低滑点、低 Gas 的体验,形成 “多方共赢” 的生态闭环。
  2. 安全是核心挑战:Hook 的灵活性意味着 “功能越强,风险越高”,未来生态需建立更完善的 Hook 审计标准与风险评级体系,避免单一漏洞影响全局。
  3. 生态潜力巨大:目前 V4 已部署至 Ethereum、Polygon、Arbitrum、Base 等多条公链,随着 Hook 模板(如开源动态调费 Hook、限价单 Hook)的丰富,普通用户与中小项目方的参与门槛将逐步降低,有望推动 DeFi 从 “小众专业领域” 走向更广泛的主流市场。

八、核心价值总结

Uniswap V4 的核心价值在于 “用架构效率换生态开放,用可编程性换创新空间”

  • :white_check_mark: 单例 + 闪电记账解决了 DeFi 长期存在的 “高 Gas 痛点”;
  • :white_check_mark: Hooks 机制打破了 AMM 功能固化的瓶颈,为 DeFi 创新提供无限可能;
  • :white_check_mark: 动态费率、订阅者等功能让 AMM 更贴近传统金融的专业需求,同时保留去中心化的核心优势。

它不仅是 Uniswap 自身的迭代,更标志着 DeFi 进入 “可编程金融” 的新阶段。

Uniswap V4 学习笔记 简短版

一、核心概述:Uniswap V4 是什么?

Uniswap V4 不再仅仅是一个自动化做市商(AMM),而是一个高度可定制、可扩展的去中心化金融基础设施。如果说 V2 是“人人可用的 DEX”,V3 是“专业化的 DEX”,那么 V4 的定位则是“人人可构建自定义 AMM 的平台”或“链上流动性的应用商店”。

它的核心思想是将交易逻辑与池子管理分离,通过引入“Hooks”机制,允许开发者像安装插件一样,为流动性池添加任意自定义功能,从而将创新的权利完全开放给社区。

二、核心创新:四大支柱

1. Hooks(钩子机制)

这是 V4 最具革命性的创新。Hooks 是外部智能合约,可以在流动性池生命周期的关键节点被触发执行,类似于软件开发中的“中间件”或“插件”。

  • 机制:在创建流动性池时,可以“挂载”一个 Hook 合约。当池子发生特定行为时(如交易前、交易后、增删流动性前后),主合约会**回调(Callback)**并执行 Hook 合约中的自定义逻辑。

  • 关键触发点包括:

  • beforeInitialize / afterInitialize (池子初始化前后)

  • beforeModifyPosition / afterModifyPosition (增删流动性前后)

  • beforeSwap / afterSwap (交易前后)

  • beforeDonate / afterDonate (捐赠前后)

  • 应用场景(无限可能):

  • 动态费用:创建一个 Hook,根据市场波动率或其他指标自动调整交易手续费。

  • 链上限价单:通过 Hook 实现当价格达到某个 Tick 时,自动执行限价单逻辑。

  • 时间加权平均做市商 (TWAMM):将大额订单通过 Hook 拆分成无数个小订单,在一段时间内平滑执行,以减少价格冲击。

  • 自定义预言机:集成更复杂的链上预言机,如中位数或波动率预言机。

  • 合规与风控:实现 KYC/AML 检查,只允许白名单地址进行交易。

2. Singleton(单例合约架构)

V4 颠覆了 V2/V3 的“工厂-交易对”模式,引入了**单例合约(Singleton)**架构。

  • 机制:所有流动性池不再是独立的合约实例,而是全部存在于一个巨大的主合约(PoolManager.sol)中。这个主合约通过内部的账本(State)来管理和隔离数以万计的不同池子。

  • 优势:

  • 极大的 Gas 节省:创建新池子不再需要部署一个完整的合约,只是在主合约中增加几行状态记录,成本降低了约 99%。

  • 路由优化:多跳交易(如 A→B→C)可以在同一个合约内部完成,无需在多个合约地址之间进行资产转移,从而节省了大量 Gas。

3. Flash Accounting(闪电记账系统)

这是对 Singleton 架构的补充,进一步优化了 Gas 效率。

  • 机制:在一个交易(Transaction)的生命周期内,所有的操作(如多次兑换、增删流动性)都只更新内部的净额账本(balance deltas),而不会发生实际的 ERC20 代币转移。直到整个交易的最后,系统才会计算出每个地址最终应该接收或支付的代币净额,并执行一次性的、最终的代币转移。
  • 优势:将多次昂贵的 transfer 调用合并为一次,极大地降低了复杂交易的 Gas 成本。这个系统依赖于一个 lock 机制,确保所有操作都在一个受控的环境中进行结算。
4. 原生 ETH 回归

V4 重新引入了对原生 ETH 的支持(而不是强制使用 WETH)。这意味着用户可以直接用 ETH 进行交易,省去了打包和解包 WETH 的步骤和 Gas 费用。

三、V4 与 V3 的核心区别:平台 vs. 产品

特性维度 Uniswap V3 (专业化产品) Uniswap V4 (可编程平台)
核心架构 工厂-交易对:每个池子都是独立合约 单例合约:所有池子存在于一个主合约中
交易逻辑 硬编码:逻辑固定在核心合约中,不可更改 模块化:核心逻辑极简,复杂功能通过 Hooks 外部实现
定制化 有限:只能选择固定的费率等级 (0.05%, 0.3%, 1%) 无限:通过 Hooks 可实现动态费用、限价单等任意功能
Gas 效率 较高 更高:通过 Singleton 和闪电记账系统大幅优化
创新模式 自上而下:由 Uniswap Labs 主导协议升级 自下而上:任何开发者都可以通过 Hooks 进行无需许可的创新
安全性 风险集中在核心协议 风险分散,池子的安全 = 核心协议安全 + Hook 合约安全

四、新版本的优缺点

(一)核心优势
  • 无与伦比的灵活性与创新性:Hooks 将 Uniswap 从一个 DEX 变成了一个功能无限的“乐高”平台,任何人都可以构建自己的金融工具。
  • 显著的 Gas 成本降低:Singleton 和闪电记账系统让创建池子和执行复杂交易的成本大幅下降。
  • 功能集成化:过去需要通过外部机器人或复杂合约才能实现的策略(如 TWAMM、限价单),现在可以直接集成在池子层面,更高效、更可靠。
  • 市场驱动的费用模型:动态费用机制使得手续费可以更智能地适应市场变化,更好地平衡 LP 收益和交易者成本。
(二)主要缺点与挑战
  • 复杂性急剧增加:对于开发者而言,理解和安全地使用 Hooks 机制的门槛非常高。
  • 新的安全风险:Hooks 是 V4 最大的攻击面。一个编写不当或恶意的 Hook 合约可能会耗尽整个池子的资金。池子的安全性不再仅仅依赖于 Uniswap 团队,还依赖于第三方 Hook 开发者的水平。
  • 流动性碎片化加剧:理论上可以存在无数种 Hooks 组合,这可能导致同一交易对的流动性被分散到众多具有不同特性的池子中,比 V3 的费率分层问题更严重。
  • 用户体验(UX)的挑战:如何向普通用户清晰、安全地展示和解释这些功能各异、风险不同的池子,将是一个巨大的挑战。

五、结论

Uniswap V4 是一次大胆的范式转移,它放弃了对协议功能的绝对控制,转而为整个 DeFi 生态提供了一个极其强大的底层基础设施。它不再仅仅追求自身的优化,而是致力于赋能社区进行无需许可的创新。虽然 V4 带来了新的安全和复杂性挑战,但它也为自动化做市商乃至整个去中心化金融的未来,开启了前所未有的想象空间。

我的 Uniswap V4 学习笔记

V4 的代码框架,比 V3 更像一个开放战场。运营视角看,它把工具箱彻底拆开,扔给所有人 —— 没有预设规则,只有基础协议和钩子接口。

Hooks 机制:把规则制定权交给生态

V4 最核心的钩子函数,允许在交易前、中、后插入自定义逻辑。这不是优化,是革命。比如,我可以写一个钩子,让某个池子只允许持仓超过 30 天的 NFT 持有者交易;也可以设计动态费率,当池内资产偏离锚定价格 5% 时,手续费自动从 0.3% 跳到 1%。

传统做市商的风控策略,现在能直接嵌进交易池。测试时试过一个简单逻辑:当 ETH 价格暴跌 10%,自动暂停 ETH-USDC 池的大额交易(单笔超 100 万刀),给 LP 缓冲时间。这在 V3 里得靠外部机器人盯盘,V4 里一行钩子代码就能实现。

但钩子是把双刃剑。社群里有人上传了一个恶意钩子,能在用户添加流动性时偷偷抽走 0.1% 资产。这意味着运营不能再只信 Uniswap 官方,必须建立钩子审计机制 —— 要么平台自己审,要么引入第三方审计标签,让用户能筛选 “已验证钩子”。

资金池重组:流动性的乐高化

V4 允许资金池共享一个全局资金库,不同池子的资产可以交叉调用。这直接解决了 V3 里 “资金分散” 的死结。比如,我在 ETH-USDC 池的资产,闲置时可以自动划到 ETH-DAI 池临时做市,赚两份手续费。

对运营来说,这意味着 “流动性利用率” 成了新 KPI。以前看锁仓量(TVL)就行,现在得算 “实际参与交易的资金占比”。测试数据显示,共享资金库能让闲置资金减少 40% 以上,这部分增量收益必须让 LP 看到 —— 可以在仪表盘加一个 “资金活化率” 指标,实时显示用户资产的利用效率。

但跨池调用会增加清算风险。如果 ETH 价格急跌,多个池子同时需要平仓,资金库可能出现挤兑。这时候,钩子又能派上用场 —— 写一个优先级钩子,规定极端行情下,先满足稳定币池的清算需求。

费率战争:从固定档位到自由定价

V4 彻底放开了费率限制,0.01% 到 10% 随便设。这会引发新的内卷。稳定币池可能卷到 0.005%,而新上线的风险代币池可能敢收 20%。

运营要做的不是干预定价,而是提供比价工具。在代币搜索页加一个 “费率热力图”,用颜色标注不同池子的费率和近 7 天收益,让用户自己权衡。还可以开发 “费率预警” 功能,当某个池子费率突然提高 50% 以上,自动推送给持仓用户 —— 这比发公告有效。

另外,自定义费率会催生 “做市策略即服务”。有人会专门设计最优费率模型,按交易量抽成。运营可以开放 API,让这些第三方策略直接接入,抽成的一部分返给平台,形成生态分成。

账户抽象:让 LP 行为更像机构

V4 支持批量操作,一个交易里能同时调整 10 个池子的流动性参数。这是给专业做市商准备的武器。测试时用脚本批量调整 5 个 ETH 相关池子的价格区间,gas 费比 V3 单独操作节省 67%。

这意味着散户和机构的差距会拉大。运营必须推出 “策略模板市场”,让散户能一键复制专业 LP 的参数设置 —— 比如 “稳健型 BTC 策略” 预设在 3 万 - 4 万美元区间,“激进型山寨币策略” 设 50% 费率和宽区间。模板设计者可以收订阅费,平台抽成 10%。

但批量操作也可能放大风险。如果某个策略模板出错,会导致所有追随者同时亏损。所以必须加 “回测数据” 强制展示,每个模板都要显示过去 3 个月的模拟收益和最大回撤,且不允许隐藏亏损记录。

学 V4 最大的体会是,它不再是一个 DEX,而是一个 “去中心化金融操作系统”。运营的核心任务从 “维护规则” 变成 “维护生态秩序”—— 就像菜市场管理员,不用规定菜价,但必须确保秤准、无假货、通道畅通。剩下的,交给交易者和做市商自己厮杀。

Uniswap V4 核心技術實現分析

一、架構設計分析

1.1 單例模式實現

PoolManager.sol 採用單例架構,所有交易池由單一合約管理。相比 V3 的獨立池合約設計,這種架構帶來以下變化:

  • 狀態集中管理:所有池狀態在單一合約中統一管理
  • 跨池操作簡化:多池操作可在單個交易中完成
  • Gas 效率提升:避免跨合約調用的額外成本
  • 組合性改善:簡化複雜 DeFi 策略的實現

1.2 解鎖模式機制

Lock.sol 實現的解鎖模式:

modifier onlyWhenUnlocked() {
    if (!Lock.isUnlocked()) ManagerLocked.selector.revertWith();
    _;
}

解鎖模式的特點:

  • 狀態一致性保證:確保操作序列的完整性
  • 多步操作支持:允許複雜的組合操作
  • 餘額平衡要求:操作完成時淨餘額必須為零
  • 重入保護:防止不當的重入調用

二、鉤子系統實現

2.1 地址驅動的權限系統

Hooks.sol 使用合約地址的位標誌決定鉤子功能:

uint160 internal constant BEFORE_INITIALIZE_FLAG = 1 << 13;
uint160 internal constant AFTER_INITIALIZE_FLAG = 1 << 12;
uint160 internal constant BEFORE_ADD_LIQUIDITY_FLAG = 1 << 11;
uint160 internal constant AFTER_ADD_LIQUIDITY_FLAG = 1 << 10;

實現邏輯:

  • 地址編碼權限:合約地址的特定位決定可用的鉤子功能
  • 部署時確定:鉤子權限在部署時即確定,無法更改
  • 權限驗證:系統會驗證聲明權限與地址權限的一致性

2.2 權限驗證機制

function validateHookPermissions(IHooks self, Permissions memory permissions) internal pure {
    if (permissions.beforeInitialize != self.hasPermission(BEFORE_INITIALIZE_FLAG)
        || permissions.afterInitialize != self.hasPermission(AFTER_INITIALIZE_FLAG)) {
        HookAddressNotValid.selector.revertWith(address(self));
    }
}

驗證特點:

  • 一致性檢查:確保聲明權限與實際地址權限匹配
  • 防欺騙機制:防止鉤子合約聲明不實權限
  • 編譯時確定:權限在合約部署時即可確定

三、數學框架與類型系統

3.1 BalanceDelta 優化

BalanceDelta.sol 實現高效的餘額變化表示:

function toBalanceDelta(int128 _amount0, int128 _amount1) pure returns (BalanceDelta balanceDelta) {
    assembly ("memory-safe") {
        balanceDelta := or(shl(128, _amount0), and(sub(shl(128, 1), 1), _amount1))
    }
}

function amount0(BalanceDelta balanceDelta) internal pure returns (int128 _amount0) {
    assembly ("memory-safe") {
        _amount0 := sar(128, balanceDelta)
    }
}

技術特點:

  • 位級打包:兩個 128 位有符號整數打包為一個 256 位字
  • 原子操作:支持同時處理兩個代幣的餘額變化
  • 內存效率:減少函數參數和返回值的數量
  • 匯編優化:使用內聯匯編提升性能

3.2 SwapMath 計算邏輯

SwapMath.sol 的核心計算函數:

function computeSwapStep(
    uint160 sqrtPriceCurrentX96,
    uint160 sqrtPriceTargetX96,
    uint128 liquidity,
    int256 amountRemaining,
    uint24 feePips
) internal pure returns (
    uint160 sqrtPriceNextX96,
    uint256 amountIn,
    uint256 amountOut,
    uint256 feeAmount
) {
    bool zeroForOne = sqrtPriceCurrentX96 >= sqrtPriceTargetX96;
    bool exactIn = amountRemaining >= 0;

    // 根據交換方向和精確輸入/輸出模式進行計算
    if (exactIn) {
        uint256 amountRemainingLessFee = FullMath.mulDiv(
            uint256(amountRemaining),
            1e6 - feePips,
            1e6
        );
        // 計算可能的輸入量...
    }
    // 費用計算和價格更新邏輯...
}

計算特點:

  • 模式處理:支持 exactIn 和 exactOut 兩種模式
  • 方向性計算:根據交換方向調整計算邏輯
  • 費用集成:在計算中整合交易費用
  • 精度控制:使用高精度數學庫保證準確性

四、Pool 狀態管理

4.1 State 結構設計

Pool.sol 中的狀態管理:

struct State {
    Slot0 slot0;
    uint256 feeGrowthGlobal0X128;
    uint256 feeGrowthGlobal1X128;
    uint128 liquidity;
    mapping(int24 => TickInfo) ticks;
    mapping(int16 => uint256) tickBitmap;
    mapping(bytes32 => Position.State) positions;
}

狀態設計特點:

  • 緊湊存儲:Slot0 將多個變量打包存儲
  • 索引結構:使用映射提供高效的數據訪問
  • 費用追蹤:全域費用增長累加器
  • 位置管理:通過唯一鍵值管理流動性頭寸

4.2 Slot0 存儲優化

struct Slot0 {
    uint160 sqrtPriceX96;    // 當前價格平方根
    int24 tick;              // 當前 tick
    uint24 protocolFee;      // 協議費用
    uint24 lpFee;           // LP 費用
}

優化效果:

  • 存儲效率:多個變量共用一個存儲槽
  • 原子更新:相關狀態可以原子性更新
  • 類型精選:根據數值範圍選擇合適的數據類型

五、ERC6909 多代幣標準

5.1 基礎實現

ERC6909.sol 支援單合約多代幣管理:

mapping(address owner => mapping(uint256 id => uint256 balance)) public balanceOf;

function transfer(address receiver, uint256 id, uint256 amount) public virtual returns (bool) {
    balanceOf[msg.sender][id] -= amount;
    balanceOf[receiver][id] += amount;
    emit Transfer(msg.sender, receiver, id, amount);
    return true;
}

技術優勢:

  • 統一管理:單一合約管理多種代幣類型
  • 批量操作:支持高效的批量轉賬和操作
  • Gas 節省:減少跨合約調用的成本
  • 擴展性:為未來的代幣類型提供擴展空間

5.2 Claims 擴展機制

ERC6909Claims.sol 添加聲明功能:

mapping(address owner => mapping(uint256 id => uint256 amount)) public claims;

function claim(uint256 id, uint256 amount) external {
    claims[msg.sender][id] -= amount;
    balanceOf[msg.sender][id] += amount;
    emit Claim(msg.sender, id, amount);
}

Claims 機制用途:

  • 延遲領取:允許用戶稍後領取應得代幣
  • 批量處理:支援批量聲明和領取操作
  • 費用分配:用於流動性挖礦和費用分發場景

六、類型系統設計

6.1 Currency 抽象

type Currency is address;

library CurrencyLibrary {
    Currency public constant NATIVE = Currency.wrap(address(0));

    function isNative(Currency currency) internal pure returns (bool) {
        return Currency.unwrap(currency) == address(0);
    }
}

抽象設計的作用:

  • 統一接口:ETH 和 ERC20 代幣使用統一處理方式
  • 類型安全:編譯時確保代幣類型的正確使用
  • 代碼簡化:減少條件判斷和分支處理

6.2 PoolKey 與 PoolId

struct PoolKey {
    Currency currency0;
    Currency currency1;
    uint24 fee;
    int24 tickSpacing;
    IHooks hooks;
}

function toId(PoolKey memory poolKey) internal pure returns (PoolId poolId) {
    assembly ("memory-safe") {
        poolId := keccak256(poolKey, 0xa0)
    }
}

設計考量:

  • 完整描述:PoolKey 包含創建池所需的全部信息
  • 高效識別:PoolId 作為哈希值提供快速查找
  • 唯一性保證:相同參數總是生成相同的 ID

七、安全機制實現

7.1 委託調用保護

modifier noDelegateCall() {
    if (address(this) != original) revert DelegateCallNotAllowed();
    _;
}

7.2 自定義錯誤處理

library CustomRevert {
    function revertWith(bytes4 selector) internal pure {
        assembly ("memory-safe") {
            mstore(0, selector)
            revert(0, 4)
        }
    }
}

安全特點:

  • 委託調用防護:防止邏輯合約被惡意委託調用
  • 高效錯誤處理:自定義錯誤節省 Gas 並提供清晰信息
  • 重入保護:解鎖模式天然提供重入保護
  • 權限驗證:確保鉤子權限的真實性

八、性能優化技術

8.1 存儲優化

  • 變量打包:相關變量打包在同一存儲槽
  • 位級操作:使用位操作進行數據打包和解包
  • 緩存機制:頻繁訪問的數據緩存到內存

8.2 計算優化

// UnsafeMath:在已知安全的情況下跳過溢出檢查
library UnsafeMath {
    function add(uint256 x, uint256 y) internal pure returns (uint256) {
        unchecked { return x + y; }
    }
}

優化策略:

  • 內聯匯編:關鍵路徑使用匯編優化
  • 無檢查運算:安全情況下跳過 Solidity 0.8+ 的溢出檢查
  • 批量操作:支援批量處理降低均攤成本

九、V3 與 V4 技術對比

9.1 架構差異

特性 V3 V4 改進說明
池管理 獨立合約 單例管理 Gas 效率提升
擴展性 固定邏輯 鉤子系統 可編程性增強
代幣標準 ERC20 ERC6909 多代幣統一管理
費用結構 固定費率 動態費率 更靈活的費用機制

9.2 性能提升

V3 多池操作:

  • 需要多次跨合約調用
  • 每個池合約獨立管理狀態
  • 組合操作需要多個交易步驟

V4 多池操作:

  • 單一合約內完成所有操作
  • 共享狀態管理
  • 原子性跨池套利和組合

十、技術限制與考量

10.1 複雜性增加

開發複雜性

  • 鉤子開發:需要理解複杂的鉤子機制
  • 權限管理:地址權限系統增加部署複雜度
  • 測試難度:更多的組合場景需要全面測試

用戶體驗

  • 交互複雜性:鉤子功能增加用戶理解成本
  • Gas 可預測性:鉤子執行可能影響 Gas 預估
  • 失敗場景:鉤子失敗可能導致整個操作失敗

10.2 技術權衡

優勢

  • 可編程性:鉤子系統提供高度的可定制性
  • Gas 效率:單例架構在複雜操作中更高效
  • 組合性:跨池操作的組合性大幅提升

挑戰

  • 升級風險:單例架構的升級影響更廣泛
  • 複雜性管理:系統複雜度增加帶來維護挑戰
  • 安全考量:鉤子系統擴大了潛在攻擊面

十一、學習總結

11.1 設計原則

技術實現

  • 模塊化設計:功能模塊清晰分離
  • 性能優化:在關鍵路徑進行深度優化
  • 安全考量:多層安全機制保護
  • 標準化:遵循和推動技術標準

系統架構

  • 可擴展性:通過鉤子系統提供擴展能力
  • 組合性:設計支援與其他協議組合
  • 向前兼容:為未來功能升級預留空間
  • 生態考量:考慮對整體生態的影響

11.2 技術啟發

架構創新

  • 單例 vs 多實例:在不同場景下的架構選擇考量
  • 可編程性設計:如何在安全性和靈活性間平衡
  • 狀態管理:集中式狀態管理的優勢與風險

實現技術

  • 類型系統:強類型設計提升代碼安全性
  • 位級優化:位操作在 Gas 優化中的應用
  • 錯誤處理:自定義錯誤的設計和使用

十二、應用前景分析

12.1 潛在應用場景

鉤子系統支援的創新功能:

  • 動態費用調整:基於波動性或交易量調整費用
  • 鏈上限價單:通過鉤子實現訂單簿功能
  • MEV 保護:私人內存池或 MEV 分享機制
  • 自動化策略:智能流動性管理和再平衡

12.2 生態系統影響

技術標準建立:

  • 鉤子模式:可能成為可編程 AMM 的標準
  • 單例架構:影響後續 DeFi 協議的架構選擇
  • 多代幣管理:ERC6909 標準的推廣應用

簡單的總結

Uniswap V4:模組化與效率革命

核心理念:讓每個人都能客製化交易所

主要特色:

  1. Hooks 系統
  • 想像樂高積木,可以在交易前後加入自定義功能
  • 例如:自動止損、動態手續費、MEV 保護
  1. 單例合約
  • 所有交易池都在同一個合約中
  • 大幅降低 gas 費用(約省 99%)
  1. Flash Accounting
  • 只在交易結束時結算淨額
  • 進一步減少 gas 成本

實際應用場景:

  • DCA 策略:可以設定每週自動買入 ETH
  • 範圍訂單:類似限價單的功能
  • 動態手續費:根據波動率自動調整費率