Keegan小钢从入门到实战：我的全套 Web3 学习路径（2025版）
你好，我是 Keegan 小钢。 如果你刚开始接触 Web3、准备从 Web2 转型，或者正在寻找一套真正系统、可落地、能带你从入门做到链上实战的学习路径，那么这篇文章会对你非常有帮助。 我是一名有 16 年经验的互联网从业者，过去 8 年专注于 Web3 技术方向，同时持续做个人 IP 超过 13 年。长期以来，我在公众号、知乎、B 站持续输出 Web3 的学习路线、开发知识、工程实践以及真实链上项目的研发过程。如果你对我的经历好奇，可以阅读这篇文章：《复盘我的 13 年个人 IP 之路》。 这几年，越来越多同学加我咨询，他们大多会问：我应该从哪里开始学 Web3？我有一些基础，但做不出完整项目怎么办？有没有适合“从入门到能做项目”的学习路径？我想顺利找到 Web3 工作，该怎么准备？本质上，这些问题可以归结成一句话：“我现在这个水平，下一步该学什么？”为了让不同阶段的同学都能快速找到最适合自己的学习路径，我把过去几年输出的所有 Web3 内容——免费课程、付费课程、AI+Web3 实战营、以及深度服务——做了一次系统性的梳理。 这篇文章是你最清晰、最完整的 「Web3 学习路...
Keegan小钢万字长文聊聊Web3的现状与趋势
整体数据现状与趋势首先，先来看看 Web3 的搜索热度情况，我们可以从 GoogleTrends 中看到一些数据。下图是关于 Web3 在全球过去 5 年内的搜索热度趋势图：从图中可以看出，前面几年的搜索热度一直很低，热度值一直保持在 10 以下，但从 2021 年下半年开始逐渐飙升，在 2021 年 12 月底达到了顶峰。虽然随后开始有所回落，但依然保持在很高的热度。 如果再按区域来看搜索热度，就会发现，搜索热度最高的竟然是在中国，且与其他区域的搜索热度差距很大，如下图所示这说明，中国依然是 Web3 最大的潜在市场。 接着，再来看看整个加密货币总市值的趋势图，某种程度上，这也代表了整个 Web3 行业的总市值。下图的数据来自 CoinMarketCap：从图中可以看到，总市值也是在 2021 年出现大幅度飙升，2021 年底到达顶峰，达到了将近 3 万亿美元的总市值。随后不断回落，在 2022 年底跌到了最低点，总市值降到低于 1 万亿，相比高点，跌去了三分之二。但是，就算是最低点也依然比 2021 年之前那些年的总市值高得多。 加密货币的总市值看上去好像不低，但如果跟全球股...
Keegan小钢万字长文聊聊Web3的组成架构
Web3 发展至今，生态已然初具雏形，如果将当前阶段的 Web3 生态组成架构抽象出一个鸟瞰图，由下而上可划分为四个层级：区块链网络层、中间件层、应用层、访问层。下面我们来具体看看每一层级都有什么。另外，此章节会涉及到很多项目的名称，因为篇幅原因不会一一进行介绍，有兴趣的可以另外去查阅相关资料进行深入了解。区块链网络层最底层是「区块链网络层」，也是 Web3 的基石层，主要由各区块链网络所组成。 组成该层级的区块链网络还不少，Bitcoin、Ethereum、BNB Chain(BSC)、Polygon、Arbitrum、Polkadot、Cosmos、Celestia、Avalanche、Aptos、Sui 等等，还有很多。根据 Blockchain-Comparison 的统计，截止撰文之日的区块链至少有 150 条。这里我们主要说的是公链，联盟链不包括在内。因为区块链实在太多，会有些眼花缭乱，所以有必要进行分门别类。 首先，不同区块链之间存在着分层结构，有 Layer0、Layer1、Layer2 之分。其次，Web3 的繁荣发展，依赖于智能合约技术，而智能合约的运行环境为...
Blockchain engineer
Keegan小钢从入门到实战：我的全套 Web3 学习路径（2025版）
你好，我是 Keegan 小钢。 如果你刚开始接触 Web3、准备从 Web2 转型，或者正在寻找一套真正系统、可落地、能带你从入门做到链上实战的学习路径，那么这篇文章会对你非常有帮助。 我是一名有 16 年经验的互联网从业者，过去 8 年专注于 Web3 技术方向，同时持续做个人 IP 超过 13 年。长期以来，我在公众号、知乎、B 站持续输出 Web3 的学习路线、开发知识、工程实践以及真实链上项目的研发过程。如果你对我的经历好奇，可以阅读这篇文章：《复盘我的 13 年个人 IP 之路》。 这几年，越来越多同学加我咨询，他们大多会问：我应该从哪里开始学 Web3？我有一些基础，但做不出完整项目怎么办？有没有适合“从入门到能做项目”的学习路径？我想顺利找到 Web3 工作，该怎么准备？本质上，这些问题可以归结成一句话：“我现在这个水平，下一步该学什么？”为了让不同阶段的同学都能快速找到最适合自己的学习路径，我把过去几年输出的所有 Web3 内容——免费课程、付费课程、AI+Web3 实战营、以及深度服务——做了一次系统性的梳理。 这篇文章是你最清晰、最完整的 「Web3 学习路...
Keegan小钢万字长文聊聊Web3的现状与趋势
整体数据现状与趋势首先，先来看看 Web3 的搜索热度情况，我们可以从 GoogleTrends 中看到一些数据。下图是关于 Web3 在全球过去 5 年内的搜索热度趋势图：从图中可以看出，前面几年的搜索热度一直很低，热度值一直保持在 10 以下，但从 2021 年下半年开始逐渐飙升，在 2021 年 12 月底达到了顶峰。虽然随后开始有所回落，但依然保持在很高的热度。 如果再按区域来看搜索热度，就会发现，搜索热度最高的竟然是在中国，且与其他区域的搜索热度差距很大，如下图所示这说明，中国依然是 Web3 最大的潜在市场。 接着，再来看看整个加密货币总市值的趋势图，某种程度上，这也代表了整个 Web3 行业的总市值。下图的数据来自 CoinMarketCap：从图中可以看到，总市值也是在 2021 年出现大幅度飙升，2021 年底到达顶峰，达到了将近 3 万亿美元的总市值。随后不断回落，在 2022 年底跌到了最低点，总市值降到低于 1 万亿，相比高点，跌去了三分之二。但是，就算是最低点也依然比 2021 年之前那些年的总市值高得多。 加密货币的总市值看上去好像不低，但如果跟全球股...
Keegan小钢万字长文聊聊Web3的组成架构
Web3 发展至今，生态已然初具雏形，如果将当前阶段的 Web3 生态组成架构抽象出一个鸟瞰图，由下而上可划分为四个层级：区块链网络层、中间件层、应用层、访问层。下面我们来具体看看每一层级都有什么。另外，此章节会涉及到很多项目的名称，因为篇幅原因不会一一进行介绍，有兴趣的可以另外去查阅相关资料进行深入了解。区块链网络层最底层是「区块链网络层」，也是 Web3 的基石层，主要由各区块链网络所组成。 组成该层级的区块链网络还不少，Bitcoin、Ethereum、BNB Chain(BSC)、Polygon、Arbitrum、Polkadot、Cosmos、Celestia、Avalanche、Aptos、Sui 等等，还有很多。根据 Blockchain-Comparison 的统计，截止撰文之日的区块链至少有 150 条。这里我们主要说的是公链，联盟链不包括在内。因为区块链实在太多，会有些眼花缭乱，所以有必要进行分门别类。 首先，不同区块链之间存在着分层结构，有 Layer0、Layer1、Layer2 之分。其次，Web3 的繁荣发展，依赖于智能合约技术，而智能合约的运行环境为...
Blockchain engineer
Share Dialog
Share Dialog
Subscribe to Keegan小钢
Subscribe to Keegan小钢
<100 subscribers
<100 subscribers
前面两篇文章分别讲解了 Chainlink 和 UniswapV2 的 TWAP。Chainlink 属于链下预言机，其价格源取自多个交易所，但所支持的 token 比较有限，主要适用于获取主流 token 的价格。UniswapV2 的 TWAP 则是链上预言机，可适用于获取 Uniswap 上已有的任何 token 价格，主要缺陷就是需要链下程序定时触发更新价格，存在维护成本。UniswapV3 的 TWAP 则解决了这个缺陷问题，本文就来聊聊 UniswapV3 的 TWAP 机制，以及如何正式使用。
UniswapV3 的实现机制和 UniswapV2 有很大不同，在计算 TWAP 的数据源方面，UniswapV2 只存储了最新的 price0CumulativeLast、price1CumulativeLast 和 blockTimestampLast 三个值而已。而 UniswapV3 则改为用一个容量可达 65535 的数组来存储历史数据，即 UniswapV3Pool 合约的 observations 状态变量，另外，触发数据的存储也不再需要链下程序去定时触发，而是在 Uniswap 发生交易时自动触发。
首先，UniswapV3 每个币对的底层合约为 UniswapV3Pool，其 github 的代码地址为：
其次，对所存储的预言机数据 observations 的相关操作，基本封装在了 Oracle 库，其 github 的代码地址如下：
在 Oracle 库中，定义了数据结构 Observation，即存储预言机数据的数据结构：
struct Observation {
// the block timestamp of the observation
uint32 blockTimestamp;
// the tick accumulator, i.e. tick * time elapsed since the pool was first initialized
int56 tickCumulative;
// the seconds per liquidity, i.e. seconds elapsed / max(1, liquidity) since the pool was first initialized
uint160 secondsPerLiquidityCumulativeX128;
// whether or not the observation is initialized
bool initialized;
}
blockTimestamp 就是每个 observation 所存储的时间戳，initialized 表明该 observation 是否已经初始化。最关键的是 tickCumulative，这是自池子创建之后的 tick * time 的累计值。需要注意的是，在 UniswapV2 中，存储的是价格累计值 priceCumulative，而 UniswapV3 并不直接计算价格累计值，而是计算 tick 累计值。
tick 是 UniswapV3 引入的新概念，因为在 UniswapV3 中，LP 提供的流动性是分为多个不同区间的，那为了方便计算不同区间的流动性和手续费分配，UniswapV3 就将整个价格范围划分为了多个离散的价格点，这些价格点就称为 tick，每个价格点 tick 都对应于一个实际价格，两者的关系可以表示如下：
该公式表明了，当 tick 为 0 时，价格为 1；当 tick 为 1 时，价格为 1.0001；当 tick 为 2 时，价格为 1.0001^2。也即是说，相邻价格点之间的价差为 0.01%。当然，tick 也可以为负值，为负值时表明价格 p 小于 1。
所以，observation 中所记录的不是 priceCumulative，而是 tickCumulative，请先记住这一点。
Oracle 中所定义的 Observation，主要就是在 UniswapV3Pool 使用。我们先来看看在 UniswapV3Pool 涉及预言机的都有哪些状态变量：
...
import './libraries/Oracle.sol';
contract UniswapV3Pool {
using Oracle for Oracle.Observation[65535];
struct Slot0 {
uint160 sqrtPriceX96;
int24 tick;
uint16 observationIndex;
uint16 observationCardinality;
uint16 observationCardinalityNext;
...
}
Slot0 public override slot0;
Oracle.Observation[65535] public override observations;
...
}
其实，主要就只涉及到 slot0 和 observations 两个状态变量而已。observations 就是保存 Oracle 中定义的 Observation 结构体的数组，该数组主要就是存储历史的累计值。slot0 则记录了当前的一些状态值，sqrtPriceX96 即当前的根号价格，tick 即当前价格对应的价格点，observationIndex 是 observations 数组中最新一条记录的索引值，observationCardinality 记录了 observations 数组中实际存储的容量值，observationCardinalityNext 表示 observations 即将要扩展到的容量值。
虽然 observations 最大容量为 65535，但实际存储的容量并不会这么大，这是由 observationCardinality 所决定的。默认情况下，observationCardinality 为 1，即 observations 实际容量只有 1，一直都只更新第一个元素，此时是无法适用于计算 TWAP 的，需要对其进行扩容。
可以通过调用 UniswapV3Pool 合约的 increaseObservationCardinalityNext 函数实现对 observations 数组的扩容，指定的参数就是想要扩容的容量。而扩容为多少合适呢？这就要看需要使用多长时间的 TWAP 了，还要看是用在 Layer1 还是 Layer2。假设 TWAP 的时间窗口为 1 小时，那如果是在 Layer1 的话，因为出块时间平均为 10 几秒，那 1 小时出块最大上限也不会超过 360，即是说扩容的容量最大也不需要超过 360。而如果是用在 Layer2 的话，因为 Layer2 定序器的原因，以 Arbitrum 为例，每隔 1 分钟才会有一次时间戳的更新，所以理论上，1 小时的 TWAP 只要有 60 的容量就足够，可以增加一点冗余扩容到 70。
扩展了容量之后，添加流动性、移除流动性、兑换的时候，一般都会调用 Oracle 库的 write 函数，来实现更新 observations 数据。在 write 函数中，会有一个时间戳的判断，当上一个 Observation 的时间戳和当前时间戳一致的时候，则不会更新。因此，在 Layer1 中，每个区块只会发生一次更新 observations；而在 Layer2，因为时间戳 1 分钟才会更新一次，所以也是 1 分钟才会发生一次更新 observations。
有了这些基础之后，就可以开始查询和计算 TWAP 了。
UniswapV3Pool 提供了一个查询函数 observe 用来查询指定时间段内的 tick 累计值，该函数也是计算 TWAP 的关键函数，其代码实现也是调用 Oracle 库的 observe 函数：
function observe(uint32[] calldata secondsAgos)
external
view
override
noDelegateCall
returns (int56[] memory tickCumulatives, uint160[] memory secondsPerLiquidityCumulativeX128s)
{
return
observations.observe(
_blockTimestamp(),
secondsAgos,
slot0.tick,
slot0.observationIndex,
liquidity,
slot0.observationCardinality
);
}
该函数指定的参数 secondsAgos 是一个数组，数组的每个元素可以指定离当前时间之前的秒数。比如我们想要获取最近 1 小时的 TWAP，那可传入数组 [3600, 0]，会查询两个时间点的累计值，3600 表示查询 1 小时前的累计值，0 则表示当前时间的累计值。返回的 tickCumulatives 就是对应于入参数组的每个时间点的 tick 累计值，secondsPerLiquidityCumulativeX128s 则是对应每个时间点的每秒流动性累计值，这个一般很少用到，所以就不展开讲了。
得到了这两个时间点的 tickCumulatives 之后，就可以算出平均加权的 tick 了。以 1 小时的时间间隔为例，计算平均加权的 tick 公式为：
averageTick = tickCumulative[1] - tickCumulative[0] / 3600
tickCumulative[1] 为当前时间的 tick 累计值，tickCumulative[0] 则为 1 小时前的 tick 累计值。
计算得到 averageTick 之后，还需要将其转换为价格，这时就需要使用另一个库 TickMath：
该库封装了 tick 和 sqrtPrice（根号价格）之间的转换函数，通过调用函数 getSqrtRatioAtTick 就可以将 averageTick 转换得到对应的 sqrtPriceX96。
在 UniswapV3 中的价格，都是用 sqrtPriceX96 来表示的，其实是将根号价格扩展了 2 的 96 次方，即：
sqrtPriceX96 = sqrt(price) * 2^96
另外，需要注意的是，这里说的 price 其实是 token1Amount / token0Amount = token0Price，即 token0 的价格。为了方便理解，我们直接举例来说明。假设 token1 为 USDC，token0 为 WETH，那 token1 在合约里的精度数为 6，token0 的精度数则为 18，也即是说，1 USDC 在合约里表示为 1000000（1e6），而 1 WETH 则表示为 1e18。那么，如果 WETH/USDC 的十进制价格为 2000 的话，公式中的 price 就是指 2000 * 1e6 / 1e18 = 2000 / 1e12，该值其实是小于 1 的，在合约层面就无法表示，所以才需要对其扩展。
接着，我们来看看，若要计算最近 1 小时的 TWAP 的代码大致是怎样的：
function getSqrtTWAP(address uniswapV3Pool) external view returns (uint160 sqrtPriceX96) {
IUniswapV3Pool pool = IUniswapV3Pool(uniswapV3Pool);
uint32[] memory secondsAgos = new uint32Unsupported embed;
secondsAgos[0] = 3600;
secondsAgos[1] = 0;
(int56[] memory tickCumulatives, ) = pool.observe(secondsAgos);
int56 averageTick = (tickCumulatives[1] - tickCumulatives[0]) / 3600;
// tick(imprecise as it's an integer) to price
sqrtPriceX96 = TickMath.getSqrtRatioAtTick(averageTick);
}
该函数用来获取指定 pool 在最近 1 小时内的时间加权平均价格，且表示为 sqrtPriceX96 的价格。
该函数要可行的话，主要有两个前提，一是该 pool 的 observations 已经有足够的扩容，二是扩容之后该池子已经交易了至少 1 小时。如果不满足这两个条件，在调用 pool.observe(secondsAgos) 函数时一般就会报错，因为会读取不到 1 小时前的 observation 数据。即是说，在扩容后的第一个 TWAP 时间窗口内，TWAP 本身其实是不可用的。如果 TWAP 的时间窗口是 24 小时，那就意味着前 24 个小时的 TWAP 都处于不可用的状态了。如果想让 TWAP 在第一个时间窗口内也可用的话，那就需要对以上实现进行优化。
要让第一个时间窗口内可用的话，其实也简单，在这第一个时间窗口内，计算 TWAP 的时间间隔不再是完整的一个时间窗口，而是 observations 数组中离当前时间最久的那个 observation 到目前为止的时间差。
如果 observations 只扩容过一次，该 observation 一般也是 observations 数组中的第一个元素，即 observations[0]。但如果 observations 在之前已经扩容过，但扩展的容量比较小的话，而目前是第二次扩容，此时数组中离当前时间最久的 observation 一般就不是 observations[0] 了，而是离当前最近的元素的下一个元素。
当前元素的索引为 index，那下一个元素的索引，一般就是 (index + 1)。但如果当前的 index 已经是当前容量的最后一个元素，那下一个元素索引其实就会回到了 0。因此，要获取下一个元素，精确的索引值应该为：(index + 1) % cardinality。
下面就是优化后的代码实现：
function getSqrtTWAP(address uniswapV3Pool, uint32 twapInterval) external view returns (uint160 sqrtPriceX96) {
IUniswapV3Pool pool = IUniswapV3Pool(uniswapV3Pool);
(, , uint16 index, uint16 cardinality, , , ) = pool.slot0();
(uint32 targetElementTime, , , bool initialized) = pool.observations((index + 1) % cardinality);
if (!initialized) {
(targetElementTime, , , ) = pool.observations(0);
}
uint32 delta = uint32(block.timestamp) - targetElementTime;
if (delta == 0) {
(sqrtPriceX96, , , , , , ) = pool.slot0();
} else {
if (delta < twapInterval) twapInterval = delta;
uint32[] memory secondsAgos = new uint32Unsupported embed;
secondsAgos[0] = twapInterval; // from (before)
secondsAgos[1] = 0; // to (now)
(int56[] memory tickCumulatives, ) = pool.observe(secondsAgos);
// tick(imprecise as it's an integer) to price
sqrtPriceX96 = TickMath.getSqrtRatioAtTick(
int24((tickCumulatives[1] - tickCumulatives[0]) / int56(uint56(twapInterval)))
);
}
}
其中，还有几个关键逻辑需要补充说明下。
第三行代码中，读取出索引值为 (index + 1) % cardinality 的元素之后，其会返回一个布尔值 initialized，如果该值为 false，则表示该元素还没被初始化，因此目标元素则改为了获取索引值为 0 的元素。
targetElementTime 就是目标元素记录累计值时的时间戳，当前时间戳减去该时间戳，就得到了目标元素离当前时间的时间差 delta。如果 delta 为 0 的话，那可以直接返回当前的 sqrtPriceX96 即可。否则，如果 delta 小于计算 TWAP 的时间间隔 twapInterval，那就将 twapInterval 重置为 delta。
如此一来，在 TWAP 的第一个时间窗口内也同样可以读取到 TWAP 了。
我们知道，在 UniswapV2 中，每个币对就组成了一个池子，即指定的 token0 和 token1 有且仅有一个 Pool。但在 UniswapV3 中，每个池子的唯一性组成，除了 token0 和 token1，还多了一个手续费率，不同费率的币对分开为了不同的池子。所以，在实际应用中，很多情况下还需要针对不同费率的池子做过滤处理，寻找出最优的池子作为预言机的价格源。
在实际应用中，可能有不同维度来衡量哪个池子是最优的。但大部分场景下，可以认为 TVL 最高的池子就是最优的池子，但从合约层面计算得到 TVL 不太方便。好在，合约层面可以方便地读取到当前的流动性 liquidity，所以也可以将此作为一个参考值，即 liquidity 最高的池子，也可以认为是最优的池子。
那么，获取最优池子的代码实现逻辑可以大致如下：
function getTargetPool(address token0, address token1) public view returns (address) {
uint24[4] public v3Fees;
v3Fees[0] = 100;
v3Fees[1] = 500;
v3Fees[2] = 3000;
v3Fees[3] = 10000;
// find out the pool with best liquidity as target pool
address pool;
address tempPool;
uint256 poolLiquidity;
uint256 tempLiquidity;
for (uint256 i = 0; i < v3Fees.length; i++) {
tempPool = IUniswapV3Factory(v3Factory).getPool(token0, token1, v3Fees[i]);
if (tempPool == address(0)) continue;
tempLiquidity = uint256(IUniswapV3Pool(tempPool).liquidity());
// use the max liquidity pool as index price source
if (tempLiquidity > poolLiquidity) {
poolLiquidity = tempLiquidity;
pool = tempPool;
}
}
return pool;
}
其逻辑其实很简单，就是对同个币对的每个手续费率都进行遍历，如果池子不为空且 liquidity 最高的池子就是目标池子。
一般来说，只要确定了目标池子之后，后续就不再需要重新遍历不同费率的池子了，可以将该目标池子绑定为固定的价格源池子。
如果频繁地遍历不同费率的池子，反而存在安全风险，因为攻击者可以通过闪电贷等方式短期内操控某个费率的池子，可能可以瞬间达到最高的流动性，这时候如果选中了被攻击者操控的池子作为了价格源池子，那安全风险就极高了。
简而言之，使用 UniswapV3 的价格预言机，一般来说，可总结为以下几个步骤：
遍历同个币对不同手续费率的池子，找出流动性 liquidity 最高的池子作为价格源的目标池子；
调用目标池子的 increaseObservationCardinalityNext 函数对 observations 进行扩容；
指定目标池子和 TWAP 的时间窗口，调用封装的 getSqrtTWAP 函数计算得到扩展后的加权平均根号价格 sqrtPriceX96；
根据实际需要将 sqrtPriceX96 转换为其他格式的价格。
文章首发于「Keegan小钢」公众号：
前面两篇文章分别讲解了 Chainlink 和 UniswapV2 的 TWAP。Chainlink 属于链下预言机，其价格源取自多个交易所，但所支持的 token 比较有限，主要适用于获取主流 token 的价格。UniswapV2 的 TWAP 则是链上预言机，可适用于获取 Uniswap 上已有的任何 token 价格，主要缺陷就是需要链下程序定时触发更新价格，存在维护成本。UniswapV3 的 TWAP 则解决了这个缺陷问题，本文就来聊聊 UniswapV3 的 TWAP 机制，以及如何正式使用。
UniswapV3 的实现机制和 UniswapV2 有很大不同，在计算 TWAP 的数据源方面，UniswapV2 只存储了最新的 price0CumulativeLast、price1CumulativeLast 和 blockTimestampLast 三个值而已。而 UniswapV3 则改为用一个容量可达 65535 的数组来存储历史数据，即 UniswapV3Pool 合约的 observations 状态变量，另外，触发数据的存储也不再需要链下程序去定时触发，而是在 Uniswap 发生交易时自动触发。
首先，UniswapV3 每个币对的底层合约为 UniswapV3Pool，其 github 的代码地址为：
其次，对所存储的预言机数据 observations 的相关操作，基本封装在了 Oracle 库，其 github 的代码地址如下：
在 Oracle 库中，定义了数据结构 Observation，即存储预言机数据的数据结构：
struct Observation {
// the block timestamp of the observation
uint32 blockTimestamp;
// the tick accumulator, i.e. tick * time elapsed since the pool was first initialized
int56 tickCumulative;
// the seconds per liquidity, i.e. seconds elapsed / max(1, liquidity) since the pool was first initialized
uint160 secondsPerLiquidityCumulativeX128;
// whether or not the observation is initialized
bool initialized;
}
blockTimestamp 就是每个 observation 所存储的时间戳，initialized 表明该 observation 是否已经初始化。最关键的是 tickCumulative，这是自池子创建之后的 tick * time 的累计值。需要注意的是，在 UniswapV2 中，存储的是价格累计值 priceCumulative，而 UniswapV3 并不直接计算价格累计值，而是计算 tick 累计值。
tick 是 UniswapV3 引入的新概念，因为在 UniswapV3 中，LP 提供的流动性是分为多个不同区间的，那为了方便计算不同区间的流动性和手续费分配，UniswapV3 就将整个价格范围划分为了多个离散的价格点，这些价格点就称为 tick，每个价格点 tick 都对应于一个实际价格，两者的关系可以表示如下：
该公式表明了，当 tick 为 0 时，价格为 1；当 tick 为 1 时，价格为 1.0001；当 tick 为 2 时，价格为 1.0001^2。也即是说，相邻价格点之间的价差为 0.01%。当然，tick 也可以为负值，为负值时表明价格 p 小于 1。
所以，observation 中所记录的不是 priceCumulative，而是 tickCumulative，请先记住这一点。
Oracle 中所定义的 Observation，主要就是在 UniswapV3Pool 使用。我们先来看看在 UniswapV3Pool 涉及预言机的都有哪些状态变量：
...
import './libraries/Oracle.sol';
contract UniswapV3Pool {
using Oracle for Oracle.Observation[65535];
struct Slot0 {
uint160 sqrtPriceX96;
int24 tick;
uint16 observationIndex;
uint16 observationCardinality;
uint16 observationCardinalityNext;
...
}
Slot0 public override slot0;
Oracle.Observation[65535] public override observations;
...
}
其实，主要就只涉及到 slot0 和 observations 两个状态变量而已。observations 就是保存 Oracle 中定义的 Observation 结构体的数组，该数组主要就是存储历史的累计值。slot0 则记录了当前的一些状态值，sqrtPriceX96 即当前的根号价格，tick 即当前价格对应的价格点，observationIndex 是 observations 数组中最新一条记录的索引值，observationCardinality 记录了 observations 数组中实际存储的容量值，observationCardinalityNext 表示 observations 即将要扩展到的容量值。
虽然 observations 最大容量为 65535，但实际存储的容量并不会这么大，这是由 observationCardinality 所决定的。默认情况下，observationCardinality 为 1，即 observations 实际容量只有 1，一直都只更新第一个元素，此时是无法适用于计算 TWAP 的，需要对其进行扩容。
可以通过调用 UniswapV3Pool 合约的 increaseObservationCardinalityNext 函数实现对 observations 数组的扩容，指定的参数就是想要扩容的容量。而扩容为多少合适呢？这就要看需要使用多长时间的 TWAP 了，还要看是用在 Layer1 还是 Layer2。假设 TWAP 的时间窗口为 1 小时，那如果是在 Layer1 的话，因为出块时间平均为 10 几秒，那 1 小时出块最大上限也不会超过 360，即是说扩容的容量最大也不需要超过 360。而如果是用在 Layer2 的话，因为 Layer2 定序器的原因，以 Arbitrum 为例，每隔 1 分钟才会有一次时间戳的更新，所以理论上，1 小时的 TWAP 只要有 60 的容量就足够，可以增加一点冗余扩容到 70。
扩展了容量之后，添加流动性、移除流动性、兑换的时候，一般都会调用 Oracle 库的 write 函数，来实现更新 observations 数据。在 write 函数中，会有一个时间戳的判断，当上一个 Observation 的时间戳和当前时间戳一致的时候，则不会更新。因此，在 Layer1 中，每个区块只会发生一次更新 observations；而在 Layer2，因为时间戳 1 分钟才会更新一次，所以也是 1 分钟才会发生一次更新 observations。
有了这些基础之后，就可以开始查询和计算 TWAP 了。
UniswapV3Pool 提供了一个查询函数 observe 用来查询指定时间段内的 tick 累计值，该函数也是计算 TWAP 的关键函数，其代码实现也是调用 Oracle 库的 observe 函数：
function observe(uint32[] calldata secondsAgos)
external
view
override
noDelegateCall
returns (int56[] memory tickCumulatives, uint160[] memory secondsPerLiquidityCumulativeX128s)
{
return
observations.observe(
_blockTimestamp(),
secondsAgos,
slot0.tick,
slot0.observationIndex,
liquidity,
slot0.observationCardinality
);
}
该函数指定的参数 secondsAgos 是一个数组，数组的每个元素可以指定离当前时间之前的秒数。比如我们想要获取最近 1 小时的 TWAP，那可传入数组 [3600, 0]，会查询两个时间点的累计值，3600 表示查询 1 小时前的累计值，0 则表示当前时间的累计值。返回的 tickCumulatives 就是对应于入参数组的每个时间点的 tick 累计值，secondsPerLiquidityCumulativeX128s 则是对应每个时间点的每秒流动性累计值，这个一般很少用到，所以就不展开讲了。
得到了这两个时间点的 tickCumulatives 之后，就可以算出平均加权的 tick 了。以 1 小时的时间间隔为例，计算平均加权的 tick 公式为：
averageTick = tickCumulative[1] - tickCumulative[0] / 3600
tickCumulative[1] 为当前时间的 tick 累计值，tickCumulative[0] 则为 1 小时前的 tick 累计值。
计算得到 averageTick 之后，还需要将其转换为价格，这时就需要使用另一个库 TickMath：
该库封装了 tick 和 sqrtPrice（根号价格）之间的转换函数，通过调用函数 getSqrtRatioAtTick 就可以将 averageTick 转换得到对应的 sqrtPriceX96。
在 UniswapV3 中的价格，都是用 sqrtPriceX96 来表示的，其实是将根号价格扩展了 2 的 96 次方，即：
sqrtPriceX96 = sqrt(price) * 2^96
另外，需要注意的是，这里说的 price 其实是 token1Amount / token0Amount = token0Price，即 token0 的价格。为了方便理解，我们直接举例来说明。假设 token1 为 USDC，token0 为 WETH，那 token1 在合约里的精度数为 6，token0 的精度数则为 18，也即是说，1 USDC 在合约里表示为 1000000（1e6），而 1 WETH 则表示为 1e18。那么，如果 WETH/USDC 的十进制价格为 2000 的话，公式中的 price 就是指 2000 * 1e6 / 1e18 = 2000 / 1e12，该值其实是小于 1 的，在合约层面就无法表示，所以才需要对其扩展。
接着，我们来看看，若要计算最近 1 小时的 TWAP 的代码大致是怎样的：
function getSqrtTWAP(address uniswapV3Pool) external view returns (uint160 sqrtPriceX96) {
IUniswapV3Pool pool = IUniswapV3Pool(uniswapV3Pool);
uint32[] memory secondsAgos = new uint32Unsupported embed;
secondsAgos[0] = 3600;
secondsAgos[1] = 0;
(int56[] memory tickCumulatives, ) = pool.observe(secondsAgos);
int56 averageTick = (tickCumulatives[1] - tickCumulatives[0]) / 3600;
// tick(imprecise as it's an integer) to price
sqrtPriceX96 = TickMath.getSqrtRatioAtTick(averageTick);
}
该函数用来获取指定 pool 在最近 1 小时内的时间加权平均价格，且表示为 sqrtPriceX96 的价格。
该函数要可行的话，主要有两个前提，一是该 pool 的 observations 已经有足够的扩容，二是扩容之后该池子已经交易了至少 1 小时。如果不满足这两个条件，在调用 pool.observe(secondsAgos) 函数时一般就会报错，因为会读取不到 1 小时前的 observation 数据。即是说，在扩容后的第一个 TWAP 时间窗口内，TWAP 本身其实是不可用的。如果 TWAP 的时间窗口是 24 小时，那就意味着前 24 个小时的 TWAP 都处于不可用的状态了。如果想让 TWAP 在第一个时间窗口内也可用的话，那就需要对以上实现进行优化。
要让第一个时间窗口内可用的话，其实也简单，在这第一个时间窗口内，计算 TWAP 的时间间隔不再是完整的一个时间窗口，而是 observations 数组中离当前时间最久的那个 observation 到目前为止的时间差。
如果 observations 只扩容过一次，该 observation 一般也是 observations 数组中的第一个元素，即 observations[0]。但如果 observations 在之前已经扩容过，但扩展的容量比较小的话，而目前是第二次扩容，此时数组中离当前时间最久的 observation 一般就不是 observations[0] 了，而是离当前最近的元素的下一个元素。
当前元素的索引为 index，那下一个元素的索引，一般就是 (index + 1)。但如果当前的 index 已经是当前容量的最后一个元素，那下一个元素索引其实就会回到了 0。因此，要获取下一个元素，精确的索引值应该为：(index + 1) % cardinality。
下面就是优化后的代码实现：
function getSqrtTWAP(address uniswapV3Pool, uint32 twapInterval) external view returns (uint160 sqrtPriceX96) {
IUniswapV3Pool pool = IUniswapV3Pool(uniswapV3Pool);
(, , uint16 index, uint16 cardinality, , , ) = pool.slot0();
(uint32 targetElementTime, , , bool initialized) = pool.observations((index + 1) % cardinality);
if (!initialized) {
(targetElementTime, , , ) = pool.observations(0);
}
uint32 delta = uint32(block.timestamp) - targetElementTime;
if (delta == 0) {
(sqrtPriceX96, , , , , , ) = pool.slot0();
} else {
if (delta < twapInterval) twapInterval = delta;
uint32[] memory secondsAgos = new uint32Unsupported embed;
secondsAgos[0] = twapInterval; // from (before)
secondsAgos[1] = 0; // to (now)
(int56[] memory tickCumulatives, ) = pool.observe(secondsAgos);
// tick(imprecise as it's an integer) to price
sqrtPriceX96 = TickMath.getSqrtRatioAtTick(
int24((tickCumulatives[1] - tickCumulatives[0]) / int56(uint56(twapInterval)))
);
}
}
其中，还有几个关键逻辑需要补充说明下。
第三行代码中，读取出索引值为 (index + 1) % cardinality 的元素之后，其会返回一个布尔值 initialized，如果该值为 false，则表示该元素还没被初始化，因此目标元素则改为了获取索引值为 0 的元素。
targetElementTime 就是目标元素记录累计值时的时间戳，当前时间戳减去该时间戳，就得到了目标元素离当前时间的时间差 delta。如果 delta 为 0 的话，那可以直接返回当前的 sqrtPriceX96 即可。否则，如果 delta 小于计算 TWAP 的时间间隔 twapInterval，那就将 twapInterval 重置为 delta。
如此一来，在 TWAP 的第一个时间窗口内也同样可以读取到 TWAP 了。
我们知道，在 UniswapV2 中，每个币对就组成了一个池子，即指定的 token0 和 token1 有且仅有一个 Pool。但在 UniswapV3 中，每个池子的唯一性组成，除了 token0 和 token1，还多了一个手续费率，不同费率的币对分开为了不同的池子。所以，在实际应用中，很多情况下还需要针对不同费率的池子做过滤处理，寻找出最优的池子作为预言机的价格源。
在实际应用中，可能有不同维度来衡量哪个池子是最优的。但大部分场景下，可以认为 TVL 最高的池子就是最优的池子，但从合约层面计算得到 TVL 不太方便。好在，合约层面可以方便地读取到当前的流动性 liquidity，所以也可以将此作为一个参考值，即 liquidity 最高的池子，也可以认为是最优的池子。
那么，获取最优池子的代码实现逻辑可以大致如下：
function getTargetPool(address token0, address token1) public view returns (address) {
uint24[4] public v3Fees;
v3Fees[0] = 100;
v3Fees[1] = 500;
v3Fees[2] = 3000;
v3Fees[3] = 10000;
// find out the pool with best liquidity as target pool
address pool;
address tempPool;
uint256 poolLiquidity;
uint256 tempLiquidity;
for (uint256 i = 0; i < v3Fees.length; i++) {
tempPool = IUniswapV3Factory(v3Factory).getPool(token0, token1, v3Fees[i]);
if (tempPool == address(0)) continue;
tempLiquidity = uint256(IUniswapV3Pool(tempPool).liquidity());
// use the max liquidity pool as index price source
if (tempLiquidity > poolLiquidity) {
poolLiquidity = tempLiquidity;
pool = tempPool;
}
}
return pool;
}
其逻辑其实很简单，就是对同个币对的每个手续费率都进行遍历，如果池子不为空且 liquidity 最高的池子就是目标池子。
一般来说，只要确定了目标池子之后，后续就不再需要重新遍历不同费率的池子了，可以将该目标池子绑定为固定的价格源池子。
如果频繁地遍历不同费率的池子，反而存在安全风险，因为攻击者可以通过闪电贷等方式短期内操控某个费率的池子，可能可以瞬间达到最高的流动性，这时候如果选中了被攻击者操控的池子作为了价格源池子，那安全风险就极高了。
简而言之，使用 UniswapV3 的价格预言机，一般来说，可总结为以下几个步骤：
遍历同个币对不同手续费率的池子，找出流动性 liquidity 最高的池子作为价格源的目标池子；
调用目标池子的 increaseObservationCardinalityNext 函数对 observations 进行扩容；
指定目标池子和 TWAP 的时间窗口，调用封装的 getSqrtTWAP 函数计算得到扩展后的加权平均根号价格 sqrtPriceX96；
根据实际需要将 sqrtPriceX96 转换为其他格式的价格。
文章首发于「Keegan小钢」公众号：
No activity yet