Tại sao Prop AMM lại phổ biến trên Solana nhưng vẫn vắng bóng trên EVM?

Tiêu đề gốc: Must-Watch dApps After Monad Mainnet Launch

Tác giả gốc: Optimus, Nhà sáng lập Waterloo Blockchain

Biên dịch gốc: Đinh Đang, Odaily

Prop AMMs đã nhanh chóng chiếm lĩnh 40% tổng khối lượng giao dịch trên Solana. Tại sao chúng vẫn chưa xuất hiện trên EVM?

Proprietary AMMs (Prop AMMs) đang nhanh chóng trở thành lực lượng chủ đạo trong hệ sinh thái DeFi của Solana, hiện đã đóng góp hơn 40% khối lượng giao dịch ở các cặp giao dịch chính. Những địa điểm thanh khoản chuyên biệt này do các nhà tạo lập thị trường chuyên nghiệp vận hành, có thể cung cấp thanh khoản sâu và định giá cạnh tranh hơn, chủ yếu nhờ việc giảm đáng kể rủi ro bị khai thác "báo giá lỗi thời" (stale quotes) để thực hiện front-running (giao dịch trước).

Nguồn ảnh: dune.com

Tuy nhiên, thành công của chúng gần như chỉ giới hạn trên Solana. Ngay cả trên các mạng Layer 2 nhanh và chi phí thấp như Base hoặc Optimism, Prop AMM vẫn hiếm thấy trong hệ sinh thái EVM. Tại sao chúng chưa bén rễ trên EVM?

Bài viết này chủ yếu thảo luận ba vấn đề: Prop AMM là gì, những rào cản kỹ thuật và kinh tế mà chúng gặp phải trên các chuỗi EVM, và những kiến trúc mới đầy hứa hẹn có thể đưa chúng lên tuyến đầu của EVM DeFi.

Prop AMM là gì?

Prop AMM là một loại AMM mà thanh khoản và định giá được quản lý chủ động bởi một nhà tạo lập thị trường chuyên nghiệp duy nhất, thay vì được cung cấp một cách thụ động bởi cộng đồng như các AMM truyền thống.

AMM truyền thống (như Uniswap v2) thường sử dụng công thức x * y = k để xác định giá, trong đó x và y lần lượt là số lượng hai tài sản trong pool, k là hằng số. Trong Prop AMM, công thức định giá không cố định mà được cập nhật với tần suất cao (thường nhiều lần mỗi giây). Do phần lớn cơ chế nội bộ của Prop AMM là "hộp đen", bên ngoài không biết chính xác thuật toán mà chúng sử dụng. Tuy nhiên, mã hợp đồng thông minh Prop AMM của Obric trên chuỗi Sui là công khai (cảm ơn @markoggwp đã phát hiện), trong đó bất biến k phụ thuộc vào các biến nội bộ mult_x, mult_y và concentration. Hình dưới đây minh họa cách nhà tạo lập thị trường liên tục cập nhật các biến này.

Cần làm rõ: Công thức phía bên trái của đường cong định giá Obric phức tạp hơn x*y đơn giản, nhưng điểm mấu chốt để hiểu Prop AMM là—nó luôn bằng một bất biến k có thể thay đổi, và nhà tạo lập thị trường liên tục cập nhật k này để điều chỉnh đường cong giá.

Ôn tập: AMM quyết định giá như thế nào?

Trong bài viết này, chúng ta sẽ nhiều lần nhắc đến khái niệm "đường cong giá". Đường cong giá quyết định mức giá mà người dùng phải trả khi giao dịch với AMM, đồng thời cũng là phần mà nhà tạo lập thị trường liên tục cập nhật trong Prop AMM. Để hiểu rõ hơn, hãy cùng ôn lại cách định giá của AMM truyền thống.

Lấy ví dụ pool WETH-USDC trên Uniswap v2 (giả sử không có phí). Giá được xác định thụ động bởi công thức x * y = k. Giả sử pool có 100 WETH và 400,000 USDC, điểm trên đường cong là x = 100, y = 400,000, giá ban đầu là 400,000 / 100 = 4,000 USDC/WETH. Từ đó, k = 100 * 400,000 = 40,000,000.

Nếu một trader muốn mua 1 WETH, anh ta phải thêm USDC vào pool, khiến WETH giảm còn 99. Để giữ k không đổi, điểm mới (x, y) vẫn phải nằm trên đường cong, nên y phải thành 40,000,000 / 99 ≈ 404,040.40. Nghĩa là trader đã trả khoảng 4,040.40 USDC cho 1 WETH, cao hơn giá ban đầu một chút. Hiện tượng này gọi là "trượt giá" (slippage). Đây là lý do x*y=k được gọi là "đường cong giá": mọi mức giá giao dịch đều phải nằm trên đường cong này.

Tại sao nhà tạo lập thị trường chọn thiết kế AMM thay vì sổ lệnh tập trung (CLOB)?

Hãy giải thích tại sao nhà tạo lập thị trường muốn sử dụng thiết kế AMM để tạo lập thị trường. Hãy tưởng tượng bạn là một nhà tạo lập thị trường báo giá trên sổ lệnh giới hạn tập trung (CLOB) on-chain. Nếu muốn cập nhật báo giá, bạn phải hủy và thay thế hàng nghìn lệnh giới hạn. Nếu bạn có N lệnh, việc cập nhật là thao tác cấp O(N), rất chậm và tốn kém trên chuỗi.

Nhưng nếu bạn có thể biểu diễn tất cả báo giá bằng một đường cong toán học thì sao? Bạn chỉ cần cập nhật một vài tham số xác định đường cong này, biến thao tác O(N) thành độ phức tạp hằng số O(1).

Để trực quan hóa cách "đường cong giá" tương ứng với các vùng giá hiệu quả khác nhau, chúng ta có thể tham khảo SolFi do Ellipsis Labs tạo ra—một Prop AMM trên Solana. Dù đường cong giá cụ thể bị ẩn, Ghostlabs đã vẽ một biểu đồ cho thấy trong một slot Solana (khoảng thời gian block), giá hiệu quả khi đổi số lượng SOL khác nhau lấy USDC. Mỗi đường là một pool WSOL/USDC khác nhau, cho thấy nhiều tầng giá có thể tồn tại đồng thời. Khi nhà tạo lập thị trường cập nhật đường cong giá, biểu đồ giá hiệu quả này cũng thay đổi giữa các slot.

Nguồn ảnh: github

Điểm mấu chốt ở đây là, bằng cách chỉ cập nhật một vài tham số của đường cong giá, nhà tạo lập thị trường có thể thay đổi phân bổ giá hiệu quả bất cứ lúc nào mà không cần sửa từng lệnh N. Đây chính là giá trị cốt lõi của Prop AMM—giúp nhà tạo lập thị trường cung cấp thanh khoản động và sâu với hiệu quả vốn và tính toán cao hơn.

Tại sao kiến trúc Solana rất phù hợp với Prop AMM?

Prop AMM là một hệ thống "quản lý chủ động", nghĩa là nó cần hai điều kiện then chốt:

1. Chi phí cập nhật thấp (cheap updates)

2. Quyền ưu tiên thực thi (priority execution)

Trên Solana, hai yếu tố này hỗ trợ lẫn nhau: cập nhật chi phí thấp thường đồng nghĩa với việc cập nhật được ưu tiên thực thi.

Tại sao nhà tạo lập thị trường cần hai yếu tố này? Thứ nhất, họ sẽ liên tục cập nhật đường cong giá theo biến động tồn kho hoặc giá chỉ số tài sản (ví dụ giá trên sàn tập trung) với tốc độ của blockchain. Trên các chuỗi tần suất cao như Solana, nếu chi phí cập nhật quá cao, sẽ khó thực hiện điều chỉnh tần suất cao.

Thứ hai, nếu nhà tạo lập thị trường không thể đảm bảo cập nhật nằm ở đầu block, báo giá cũ của họ sẽ bị arbitrageur "cướp" mất, gây thua lỗ chắc chắn. Nếu thiếu hai đặc điểm này, nhà tạo lập thị trường không thể vận hành hiệu quả, người dùng cũng nhận giá giao dịch kém hơn.

Lấy Prop AMM HumidiFi trên Solana làm ví dụ, theo dữ liệu của @SliceAnalytics, nhà tạo lập thị trường này cập nhật báo giá tới 74 lần mỗi giây.

Người chơi từ EVM có thể hỏi: "Slot của Solana khoảng 400ms, làm sao Prop AMM có thể cập nhật giá nhiều lần trong một slot?"

Câu trả lời nằm ở kiến trúc liên tục của Solana, vốn khác biệt về bản chất so với mô hình block rời rạc của EVM.

· EVM: Giao dịch thường được thực thi tuần tự sau khi block hoàn chỉnh được đề xuất và xác nhận cuối cùng. Điều này nghĩa là cập nhật gửi giữa chừng phải đợi tới block tiếp theo mới có hiệu lực.

· Solana: Node xác thực Leader không đợi block hoàn chỉnh mà chia giao dịch thành các gói nhỏ (gọi là "shred") và phát liên tục lên mạng. Một slot có thể có nhiều swap, nhưng cập nhật giá của shred #1 ảnh hưởng tới swap #1, shred #2 ảnh hưởng tới swap #2.

Lưu ý: Flashblocks tương tự shred của Solana. Theo chia sẻ của @Ashwinningg từ Anza Labs tại hội nghị CBER, mỗi slot 400ms có tối đa 32,000 shred, tương đương 80 shred mỗi ms. Liệu Flashblocks 200ms có đủ nhanh cho nhu cầu nhà tạo lập thị trường so với kiến trúc liên tục của Solana vẫn là câu hỏi mở.

Vậy tại sao cập nhật trên Solana lại rẻ như vậy? Và làm sao dẫn đến quyền ưu tiên thực thi?

Thứ nhất, dù Prop AMM trên Solana là hộp đen, nhưng có thư viện như Pinocchio giúp tối ưu hóa cách viết chương trình Solana để giảm tiêu thụ CU. Blog của Helius có giới thiệu chi tiết, nhờ thư viện này, chương trình Solana có thể giảm tiêu thụ CU từ khoảng 4000 CU xuống còn khoảng 100 CU.

Nguồn ảnh: github

Tiếp theo là phần thứ hai. Ở cấp độ cao hơn, Solana ưu tiên các giao dịch có tỷ lệ Fee / Compute Units cao nhất (Compute Units tương tự Gas của EVM), giống EVM.

· Cụ thể, nếu dùng Jito, công thức là Jito Tip / Compute Units

· Không dùng: Priority = (phí ưu tiên + phí cơ bản) / (1 + CU limit + CU chữ ký + CU write lock)

So sánh Compute Units của cập nhật Prop AMM và swap Jupiter, có thể thấy cập nhật cực kỳ rẻ, tỷ lệ lên tới 1:1000.

Cập nhật Prop AMM: Cập nhật đường cong đơn giản cực rẻ. Cập nhật của Wintermute chỉ 109 CU, tổng phí chỉ 0.000007506 SOL

Jupiter Swap: Swap qua Jupiter router có thể tới ~100,000 CU, tổng phí 0.000005 SOL

Vì sự chênh lệch lớn này, nhà tạo lập thị trường chỉ cần trả phí cực nhỏ cho giao dịch cập nhật là có thể đạt tỷ lệ Fee/CU cao hơn nhiều so với swap, đảm bảo cập nhật được thực thi ở đầu block, bảo vệ mình khỏi bị arbitrage.

Tại sao Prop AMM chưa xuất hiện trên EVM?

Giả sử cập nhật Prop AMM liên quan tới việc ghi giá trị quyết định đường cong giá của cặp giao dịch. Dù mã Prop AMM trên Solana là "hộp đen", nhà tạo lập thị trường muốn giữ bí mật chiến lược, nhưng ta có thể dùng giả định này để hiểu cách Obric triển khai Prop AMM trên Sui: biến quyết định báo giá được ghi vào hợp đồng thông minh qua hàm update.

Cảm ơn @markoggwp đã phát hiện!

Dựa trên giả định này, ta thấy kiến trúc EVM có rào cản lớn khiến mô hình Prop AMM của Solana không khả thi trên EVM.

Nhắc lại, trên các blockchain Layer 2 OP-Stack (như Base và Unichain), giao dịch được ưu tiên theo phí trên mỗi Gas (giống Solana ưu tiên theo Fee / CU).

Trên EVM, thao tác ghi (write) tiêu tốn Gas rất cao. So với cập nhật trên Solana, việc ghi một giá trị bằng opcode SSTORE trên EVM cực kỳ tốn kém:

· SSTORE (0 → khác 0): ~22,100 gas

· SSTORE (khác 0 → khác 0): ~5,000 gas

· Swap AMM điển hình: ~200,000–300,000 gas

Lưu ý: Gas trên EVM tương tự Compute Units trên Solana. Số gas SSTORE trên là giả định mỗi giao dịch chỉ ghi một lần (cold write), hợp lý vì thường không gửi nhiều cập nhật trong một giao dịch.

Dù cập nhật vẫn rẻ hơn swap, nhưng tỷ lệ sử dụng gas chỉ khoảng 10 lần (cập nhật có thể gồm nhiều SSTORE), trong khi trên Solana là khoảng 1000 lần.

Điều này dẫn đến hai kết luận khiến mô hình Prop AMM của Solana rủi ro hơn trên EVM:

1. Tiêu thụ gas cao khiến phí ưu tiên khó đảm bảo cập nhật được ưu tiên, phí ưu tiên thấp không đạt tỷ lệ phí/gas cao. Để đảm bảo cập nhật không bị front-run và nằm đầu block, cần phí ưu tiên cao hơn, tăng chi phí.

2. Rủi ro arbitrage trên EVM cao hơn, tỷ lệ gas cập nhật/swap trên EVM chỉ 1:10, còn Solana là 1:1000. Nghĩa là arbitrageur chỉ cần tăng phí ưu tiên 10 lần là có thể front-run cập nhật của nhà tạo lập thị trường, còn trên Solana phải tăng 1000 lần. Với tỷ lệ thấp này, arbitrageur dễ front-run giá cập nhật để lấy báo giá lỗi thời vì chi phí thấp.

Một số đổi mới (như EIP-1153 với TSTORE, dùng lưu trữ tạm thời) chỉ tốn khoảng 100 gas, nhưng lưu trữ này chỉ tồn tại trong một giao dịch, không thể dùng để lưu giá cập nhật cho các swap sau (ví dụ trong suốt block).

Làm thế nào để đưa Prop AMM lên EVM?

Trước khi trả lời, hãy trả lời "tại sao phải làm": Người dùng luôn muốn nhận báo giá giao dịch tốt hơn, nghĩa là giao dịch có lợi hơn. Prop AMM trên Ethereum và Layer 2 có thể mang lại báo giá cạnh tranh mà trước đây chỉ có trên Solana hoặc sàn tập trung.

Để Prop AMM khả thi trên EVM, hãy nhớ lại một lý do thành công của nó trên Solana:

· Bảo vệ cập nhật ở đầu block: Trên Solana, cập nhật Prop AMM nằm đầu block, bảo vệ nhà tạo lập thị trường khỏi bị front-run. Cập nhật nằm đầu block vì tiêu thụ compute unit cực thấp, dù phí thấp vẫn đạt tỷ lệ phí/CU cao, đặc biệt so với swap.

Vậy làm sao đưa cập nhật Prop AMM đầu block lên Layer 2 EVM? Có hai cách: hoặc giảm chi phí ghi, hoặc tạo kênh ưu tiên cho cập nhật Prop AMM.

Do vấn đề tăng trưởng trạng thái của EVM, phương án giảm chi phí ghi không khả thi vì SSTORE rẻ sẽ dẫn đến tấn công rác trạng thái.

Chúng tôi đề xuất tạo kênh ưu tiên cho cập nhật Prop AMM. Đây là giải pháp khả thi và là trọng tâm của bài viết này.

Nhóm Uniswap của @MarkToda đề xuất một phương pháp mới, kết hợp hợp đồng thông minh lưu trữ toàn cục + chiến lược xây dựng block chuyên biệt:

Cách hoạt động như sau:

· Hợp đồng lưu trữ toàn cục: Triển khai hợp đồng thông minh đơn giản làm kho lưu trữ key-value công khai. Nhà tạo lập thị trường ghi tham số đường cong giá vào hợp đồng này (ví dụ set(ETH-USDC_CONCENTRATION, 4000)).

· Chiến lược builder: Đây là thành phần off-chain then chốt. Block builder nhận diện giao dịch gửi tới hợp đồng lưu trữ toàn cục, dành 5–10% gas đầu block cho các giao dịch cập nhật này và ưu tiên theo phí, ngăn chặn spam.

Lưu ý: Giao dịch phải gửi trực tiếp tới địa chỉ lưu trữ toàn cục, nếu không không đảm bảo nằm đầu block.

Có thể tham khảo ví dụ thuật toán xây dựng block tùy chỉnh tại rblib.

Tích hợp Prop AMM: Hợp đồng Prop AMM của nhà tạo lập thị trường sẽ đọc dữ liệu đường cong giá từ hợp đồng lưu trữ toàn cục khi swap để cung cấp báo giá.

Kiến trúc này giải quyết khéo léo hai vấn đề:

1. Bảo vệ: Chiến lược builder tạo "kênh nhanh", đảm bảo mọi cập nhật giá trong block được thực thi trước giao dịch, loại bỏ rủi ro front-run.

2. Hiệu quả chi phí: Nhà tạo lập thị trường không còn phải cạnh tranh phí gas cao với mọi người dùng DeFi để được nằm đầu block, chỉ cần cạnh tranh trong thị trường phí cục bộ dành riêng cho cập nhật, giảm chi phí đáng kể.

Giao dịch của người dùng sẽ được thực thi theo đường cong giá mà nhà tạo lập thị trường cập nhật đầu block, đảm bảo báo giá mới và an toàn. Mô hình này tái hiện môi trường cập nhật chi phí thấp, ưu tiên cao của Solana trên EVM, mở đường cho Prop AMM trên EVM.

Tuy nhiên, mô hình này cũng có một số nhược điểm, tôi sẽ để lại các vấn đề này ở cuối bài để thảo luận.

Kết luận

Tính khả thi của Prop AMM phụ thuộc vào việc giải quyết vấn đề kinh tế cốt lõi: cập nhật rẻ và ưu tiên thực thi để ngăn front-run.

Dù kiến trúc EVM tiêu chuẩn khiến loại thao tác này tốn kém và rủi ro, nhưng thiết kế mới đã cung cấp các phương án khác nhau để giải quyết vấn đề. Kết hợp hợp đồng thông minh lưu trữ toàn cục on-chain và chiến lược builder off-chain, có thể tạo "kênh nhanh" chuyên dụng, đảm bảo cập nhật được thực thi đầu block, đồng thời xây dựng thị trường phí cục bộ, kiểm soát. Điều này không chỉ giúp Prop AMM khả thi trên EVM, mà còn có thể thay đổi mọi ứng dụng EVM DeFi phụ thuộc cập nhật oracle đầu block.

Các vấn đề mở

· Liệu tốc độ Flashblock 200ms trên EVM có đủ để cạnh tranh với kiến trúc liên tục của Solana cho Prop AMM?

· Phần lớn lưu lượng AMM trên Solana đến từ một aggregator duy nhất là Jupiter, cung cấp SDK thuận tiện cho AMM tích hợp. Nhưng trên Layer 2 EVM, lưu lượng phân tán ở nhiều aggregator và không có SDK công khai, điều này có gây khó khăn cho Prop AMM?

· Cập nhật Prop AMM trên Solana chỉ tiêu tốn khoảng 100 CU, cơ chế thực hiện như thế nào?

· Mô hình kênh nhanh chỉ đảm bảo cập nhật đầu block. Nếu một Flashblock có nhiều swap, nhà tạo lập thị trường làm sao cập nhật giá giữa các swap đó?

· Có thể viết chương trình EVM tối ưu bằng Yul hoặc Huff, tương tự giải pháp Pinocchio trên Solana không?

· So sánh Prop AMM và RFQ như thế nào?

· Làm sao ngăn nhà tạo lập thị trường đưa báo giá tốt ở block N để dụ người dùng, rồi cập nhật báo giá xấu ở block N+1? Jupiter làm sao phòng tránh?

· Tính năng Ultra Signaling của Jupiter Ultra V3 cho phép Prop AMM phân biệt lưu lượng có hại và không có hại, cung cấp báo giá sát hơn, vậy đặc điểm này của aggregator có quan trọng với Prop AMM trên EVM không?

Liên kết gốc