Ủa sao nói UniswapV3 vẫn là constant-product mà có thấy dòng nào trong code đảm bảo $x * y= k$ đâu?

2. Suy luận từ V2 sang V3

2.1. Nhắc lại một chút về V2

Ai cũng biết, công thức toán khi swap của Uniswap là constant-product, nghĩa là: $x*y=k$. Giá trị k trước khi swap và sau khi swap phải được giữ nguyên, k chỉ thay đổi khi có hành động thêm hoặc rút thanh khoản.

Dễ hiểu hơn, ban đầu Pool đang có reserves là $x$ token0 và $y$ token1. Alice muốn swap một lượng $x_0$ token0 lấy một lượng $y_0$ token1. Thì $x_0$ và $y_0$ phải thoả mãn:

$(x + x_0) * (y - y_0) = x * y$

Ví dụ: ban đầu $x = 100$, $y = 48$. Alice muốn swap 20 token0 lấy token1 thì lượng token1 mà Alice nhận được là:

$y_0 = 48 - \frac{4800}{100 + 20} = 8$

Và, thanh khoản của Pool được tính theo công thức:

$L=\sqrt{x*y}$

Mắc đi hát karaoke quá mà ở quê không ai rủ đi.

Tại sao công thức tính L lại là $L = \sqrt{x * y}$ ?

Suy luận một chút, tính chất đầu tiên của L cần phải được thoả mãn là: $L$ phải được giữ nguyên giá trị trước khi swap và sau khi swap. Nếu lấy công thức $L = x + y$, tính chất đó sẽ không thể thoả mãn, mà ta đã có $x* y = k$ (hằng số), do đó L sẽ là một công thức gì đó liên quan đến $x * y$, dạng $L = f(x * y)$.

Tính chất thứ hai mà $L$ cần phải được thoả mãn là tính tỷ lệ, nghĩa là khi một liquidity provider thêm thanh khoản vào Pool, lượng liquidity được ghi nhận cho provider đó phải có tỷ lệ tương xứng với liquidity của tổng Pool dưa trên số lượng token0 và token1 mà provider đó đã thêm vào.

Ví dụ, Pool đang có reserves là $x$ token0 và $y$ token1, có tổng liquidity là $L_{total}$, Alice thêm $x_0$ token0 và $y_0$ token1 vào Pool, liquidity được ghi nhận cho Alice $L_0$, phải thoả mãn:

$\frac{L_0}{L_{total}}=\frac{x_0}{x}$ hoặc $\frac{L_0}{L_{total}} = \frac{y_0}{y}$

Nếu chúng ta sử dụng công thức $L = x * y$, công thức trên không thể thoả mãn, hãy cho các con số vào để dễ hình dung hơn.

$x = 300, y = 600 => L_{total} = 300 * 600 = 180000$

$x_0 = 100, y_0 = 200 => L_0 = 100 * 200 = 20000$

$=> \frac{L_0}{L_{total}} = \frac{20000}{180000} = \frac{1}{9}$

$=> \frac{x_0}{x} = \frac{100}{300} = \frac{1}{3}$ và $\frac{y}{y} = \frac{200}{600} = \frac{1}{3}$

Rõ ràng là công thức $L= x * y$ không thể thoả mãn tính tỷ lệ.

Nếu $L = \sqrt{x * y}$ thì sao? Hãy thử với các con số ở trên:

$x = 300, y = 600 => L_{total} = \sqrt{300 * 600} = \sqrt{180000}$

$x_0 = 100, y_0 = 200 => L_0 = \sqrt{100 * 200} = \sqrt{20000}$

$\frac{L_0}{L_{total}} = \frac{\sqrt{20000}}{\sqrt{180000}} = \frac{1}{3}$

Như vậy, công thức $L= \sqrt{x*y}$ thoả mãn tính tỷ lệ.

Oke, tiếp theo, tại sao lại hoặc giữa $\frac{x_0}{x}$, $\frac{y_0}{y}$. Hãy nhìn vào code một tí, hàm mint() của UniswapV2Pair.sol

Nếu là provider đầu tiên thêm thanh khoản thì $L$ sẽ được tính theo công thức $L =\sqrt{x * y}$, dòng 119-120.

Những provider tiếp theo chỉ cần tính theo công thức $L_0 = min(\frac{x_0}{x} * L_{total}, \frac{y_0}{y} * L_{total})$ (dòng 122, 123) là sẽ tự động thoả mãn 2 tính chất ở trên. Điều này cho phép những provider này không cần thêm thành khoản đúng tỷ lệ $\frac{x_0}{y_0} = \frac{x}{y}$, với mục đích có thể làm thay đổi price luôn trong lúc thêm thanh khoản, cho nên $L_{0}$ phải là $min(\frac{x_0}{x} * L_{total}, \frac{y_0}{y} * L_{total})$.

2.2. Chuyển đổi từ V2 sang V3

Mặc dụ V2 ko quy ước về công thức giá, nhưng bây giờ chúng ta hãy quy ước rằng P được xem là giá của token0 trên token1, nghĩa là 1 token0 = P token1. Nghĩa là $P = \frac{y}{x}$

Chúng ta có thể biểu diễn tương quan của $x,y,P$ như sau (lưu ý, hình này không đúng về mặt toán học, đừng cố chia tỷ lệ độ dài hay diện tích làm gì, nó chỉ minh hoạ ra cho dễ hiểu):

Chúng ta có thể thấy những điều sau với Pool V2:

• $P$ sẽ có khoảng giá trị (price-range) là $(0, +\infin)$, nhưng $P$ sẽ không bao giờ chạm đến 0
• $x$ càng tăng, nghĩa là lượng token0 trong pool càng nhiều thì $P$ càng giảm
• $y$ càng tăng, nghĩa là lượng token1 trong pool càng nhiều thì $P$ càng tăng
• Bên phải của $P$, chỉ chứa toàn token0. Bên trái của $P$ chỉ chứa toàn token1

Ok, bây giờ hãy qua lại điểm khác nhau về tính năng của V2 và V3 là: thanh khoản khi một provider thêm vào V2, provider không có quyền chọn price-range, $L$ sẽ được hoà tan hoàn toàn vào price-range $(0, +\infin)$. Còn ở V3, provider có quyền chọn price-range cho lượng thanh khoản của mình, khi nào current-price đi vào price-range mà provider đã chọn thì lượng thanh khoản mà anh ấy đã thêm vào mới được phép mang ra sử dụng, và L của mỗi price-range có giá trị khác nhau.

Từ hình mình hoạ của V2, chúng ta có thể mở rộng ra minh hoạ cho V3 như sau:

Để ra được hình minh hoạ này thì mình tư duy như sau:

• Lấy A,B,C,D,E,F,G,H là những tick mà index của chúng đều chia hết cho tick-spacing, chúng không cần phải cách đều nhau.

• Đầu tiên gom cả PoolV2 thành 1 price-range nhất định, ở đây là [D,E). Trong price range này, sẽ có vừa có cả $x$ token0 và $y$ token1, giá hiện tại (current-price) đang là ở điểm D1 thuộc [D,E) và $L_{[D,E)} = \sqrt{x * y}$. Và nếu sau khi swap, price không vượt qua khỏi [$1.0001^D$, $1.0001^{E-1}$, thì lệnh swap đó mới được sử dụng token0 hoặc token1 trong thanh khoản $L_{[D,E)}$

• Bên trái của current-price vẫn sẽ toàn là token1, bên phải của current-price vẫn sẽ toàn là token0.

• Và như mình đã nói ở phần trước, liquidity provider có thể thêm thanh khoản vào bất cứ price-range nào họ muốn. Do đó, L của các đoạn sẽ nhấp nhô (không bằng nhau). Khi họ thêm thanh khoản vào price-range lớn hơn current-price-range, họ chỉ được phép deposit token0. Khi họ thêm thanh khoản vào price-range nhỏ hơn current-price-range, họ chỉ được phép deposit token1.

Nhưng có một vấn đề ở đây là, với các đoạn [E,F), [F,G), [G,H) chỉ toàn token0 và các đoạn [A,B), [B,C), [C,D) chỉ toàn là token1 thì làm sao xác định được L của mỗi đoạn nếu dựa vào công thức thuần tuý $L = \sqrt{x * y}$, chẳng phải tất cả L sẽ là 0 sao?

2.3 Hô biến các công thức