Từ Solana đến EVM: Con đường mới dành cho các AMM độc quyền

Các Prop AMM đã nhanh chóng chiếm lĩnh 40% tổng khối lượng giao dịch trên Solana. Vì sao chúng chưa xuất hiện trên EVM?

Proprietary AMM (Prop AMM) đang nổi lên như một thế lực chủ đạo trong hệ sinh thái DeFi của Solana, chiếm hơn 40% khối lượng giao dịch trên các cặp lớn. Các nền tảng 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, cung cấp thanh khoản sâu và mức giá cạnh tranh, chủ yếu nhờ giảm rủi ro bị front-running từ các arbitrageur tận dụng báo giá lỗi thời.

https://dune.com/the_defi_report/prop-amms

Tuy nhiên, thành công của Prop AMM gần như chỉ giới hạn ở Solana. Tại sao chúng chưa phát triển trong hệ sinh thái EVM, ngay cả trên các Layer 2 nhanh và chi phí thấp như Base hay Optimism?

Bài viết này sẽ phân tích 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, cùng một kiến trúc mới đầy tiềm năng có thể đưa Prop AMM lên vị trí dẫn đầu DeFi EVM.

Prop AMM là gì?

Prop AMM là một automated market maker, trong đó thanh khoản và định giá của pool đượ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ì do cộng đồng cung cấp thụ động.

Khác với AMM truyền thống sử dụng phương trình x * y = k để xác định giá (với x và y là số lượng hai tài sản trong pool, k là hằng số), Prop AMM sử dụng công thức khác, thường được cập nhật liên tục nhiều lần mỗi giây. Vì Prop AMM thường là “hộp đen”, nên công thức mà mỗi Prop AMM sử dụng không được công khai. Tuy nhiên, mã smart contract của Prop AMM Obric trên Sui là công khai (Cảm ơn @ markoggwp đã phát hiện!), trong đó invariant k phụ thuộc các biến nội bộ mult_x, mult_y và concentration. Hình ả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.

Một điểm cần lưu ý là phía bên trái của công thức đường giá của Obric phức tạp hơn x * y, nhưng điểm cốt lõi để hiểu Prop AMM là nó bằng với một invariant k, và nhà tạo lập thị trường liên tục cập nhật k để điều chỉnh đường giá.

Nhắc lại: Giá trên AMM được xác định như thế nào?

Thuật ngữ “đường giá” sẽ xuất hiện nhiều lần trong bài viết này, vì nó quyết định mức giá mà người dùng phải trả khi giao dịch trên AMM và là thứ mà nhà tạo lập thị trường cập nhật trong Prop AMM để điều chỉnh giá. Trước khi đi sâu vào Prop AMM, hãy cùng tìm hiểu cách giá được xác định trong một AMM. Xét một pool Uniswap v2 cho WETH-USDC không có phí. Giá được xác định thụ động bởi công thức x * y = k, trong đó x và y là số lượng hai tài sản trong pool, k là một hằng số. Chỉ các điểm trên đường cong này mới là mức giá mà người dùng có thể trả cho giao dịch của mình.

Ví dụ, xét một pool WETH-USDC với 100 WETH và 400.000 USDC. Điểm hiện tại trên đường cong là x = 100 WETH, y = 400.000 USDC, nghĩa là giá ban đầu là 400.000 USDC / 100 WETH = 4.000 USDC mỗi WETH. Tính hằng số k, ta có xy = k = 40.000.000. Nếu trader muốn mua 1 WETH, họ thêm USDC vào pool, số dư WETH giảm xuống còn 99. Để giữ k không đổi, điểm x và y mới phải nằm trên đường cong, nên số dư USDC phải tăng lên 40.000.000 / 99 ≈ 404.040,40 USDC. Như vậy, trader đã trả 4.040,40 USDC cho 1 WETH, mức giá thực tế cao hơn giá ban đầu $4.000 do tác động giá (slippage). Đây là lý do công thức x y = k còn được gọi là đường giá, vì mọi mức giá khả dĩ cho pool này đều là một điểm trên đường cong.

Tại sao Market Maker lại chọn thiết kế AMM thay vì CLOB?

Hãy lý giải vì sao một nhà tạo lập thị trường lại muốn dùng thiết kế AMM cho hoạt động market making. Hình dung bạn là market maker trên một Central Limit Order Book (CLOB) onchain. Để 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 riêng lẻ. Nếu có N lệnh, đây là phép toán tuyến tính O(N). Điều này chậm và tốn tài nguyên, đặc biệt là onchain.

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 duy nhất thì sao? Thay vì quản lý N lệnh riêng biệt, bạn chỉ cần cập nhật một vài tham số xác định toàn bộ đường cong. Điều này biến bài toán O(N) thành O(1).

Để hình dung cách một đường giá (vd. x*y = k) tạo ra nhiều mức giá hiệu quả khác nhau, hãy xem SolFi, Prop AMM do Ellipsis Labs phát triển. Dù đường giá bị ẩn, Ghostlabs đã tạo một biểu đồ dưới đây cho thấy giá hiệu quả SOL sang USDC với các lượng SOL khác nhau muốn swap tại một slot Solana nhất định. (Đối với độc giả EVM, số slot tương tự như số block). Mỗi đường là một pool WSOL/USDC khác nhau, thể hiện khả năng cung cấp nhiều mức giá đồng thời. Khi market maker cập nhật đường giá, biểu đồ giá hiệu quả bên dưới sẽ thay đổi giữa các slot.

https://github.com/tryghostxyz/solfi-sim/blob/main/static/curves_333436948.png

Điểm mấu chốt là, chỉ với một lần cập nhật một vài giá trị đường giá, market maker có thể thay đổi biểu đồ giá hiệu quả theo ý muốn, thay vì phải cập nhật N lệnh khác nhau. Đây là giá trị cốt lõi của Prop AMM, cho phép market maker cung cấp thanh khoản sâu, linh hoạt với hiệu quả sử dụng vốn và tính toán vượt trội.

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

Prop AMM được quản lý chủ động, đòi hỏi hai yếu tố: cập nhật rẻ và ưu tiên thực thi. Trên Solana, cập nhật rẻ dẫn đến việc cập nhật được ưu tiên thực thi.

Tại sao market maker cần hai yếu tố này? Đầu tiên, market maker cập nhật đường giá với tốc độ vận hành của chain, dựa trên các yếu tố như tồn kho hiện tại và biến động giá chỉ số tài sản (vd. từ các sàn tập trung). Trên các chain nhanh như Solana, nếu cập nhật không rẻ thì chi phí sẽ rất lớn.

Thứ hai, nếu market maker không thể đưa cập nhật lên đầu block, báo giá lỗi thời sẽ bị arbitrageur “bắt”, dẫn đến thua lỗ chắc chắn.

Nếu thiếu một trong hai yếu tố này, market maker sẽ hoạt động kém hiệu quả, dẫn đến giá giao dịch kém cạnh tranh cho người dùng.

Ví dụ, Prop AMM trên Solana như HumidiFi được ghi nhận cập nhật báo giá 74 lần mỗi giây (cảm ơn @ SliceAnalytics cung cấp dữ liệu), như hình dưới:

https://dune.com/queries/5980584/9644764

Đến từ thế giới EVM, có thể bạn sẽ hỏi: “Nếu slot Solana là ~400ms, làm sao một 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 hoàn toàn 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ự khi một block hoàn chỉnh được đề xuất và xác nhận. Nghĩa là cập nhật gửi trong giữa block sẽ chỉ được phản ánh khi block tiếp theo bắt đầu.
• Solana: Validator leader không chờ xây block đầy đủ. Nó chia giao dịch thành các packet nhỏ gọi là “shred” và truyền liên tục tới phần còn lại của mạng. Có thể có nhiều swap trong một slot, nhưng cập nhật giá ở shred #1 ảnh hưởng đến giá swap #1, còn cập nhật giá ở shred #2 ảnh hưởng đến giá swap #2.

Lưu ý: Các giải pháp như Flashblocks tương tự shred của Solana. Theo @ Ashwinningg từ Anza Labs tại hội nghị CBER, giới hạn trên là 32.000 shred mỗi slot 400ms, tức tối đa 80 shred mỗi mili giây! Liệu Flashblocks 200ms có đủ nhanh cho market maker 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ẻ, và điều này dẫn đến ưu tiên thực thi như thế nào?

Dù triển khai Prop AMM trên Solana là “hộp đen”, vẫn có các thư viện như Pinocchio để tạo Solana program tối ưu hóa CU. Blog của Helius có bài viết rất hay về thư viện này (tại đây), cho thấy có thể giảm Solana program từ ~4000 CU xuống ~100 CU.

https://github.com/febo/p-token?tab=readme-ov-file#compute-units

Tiếp theo, ở cấp độ cao, Solana ưu tiên giao dịch bằng cách chọn giao dịch có tỷ lệ Fee / Compute Units cao nhất (Compute Units tương tự Gas trên EVM), giống EVM.

• Cụ thể, nếu dùng Jito, công thức là Jito Tip / Compute Units,
• nếu không thì là Priority = (Prioritization fee + Base fee) / (1 + CU limit + Signature CUs + Write lock CUs) (https://solana.com/docs/core/fees)

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

Cập nhật Prop AMM: Một lần cập nhật đường cong đơn giản cực kỳ rẻ. Wintermute có lần cập nhật chỉ 109 CU, tổng phí cho tx là 0,000007506 SOL

https://orb.helius.dev/tx/325EwPasEyXYuVqow9aGT44i17cZzd9G5GYPHxJr1JmLKwyWTS6rJgV6EP1svqExo9TnoqqmMF15si17x2s7wnSu?cluster=mainnet-beta&advanced=true&tab=summary

Jupiter Swap: Một swap qua Jupiter có thể tốn tới ~100.000 CU. Tổng phí cho tx này là 0,000005 SOL.

https://orb.helius.dev/tx/4SbYyAEq6QBNv5YW517fLRatEPvBvh1kDit3C8NL84uBRXuE7FFEsVuX6BDG44reXtMt5WZCGxN7rS38jt4RSNY9?cluster=mainnet-beta&advanced=true&tab=summary)

Nhờ sự khác biệt lớn này, market maker có thể đạt được ưu tiên thực thi cho các lần cập nhật bằng cách trả một khoản phí nhỏ cho giao dịch cập nhật và đạt tỷ lệ Fee/CU cao hơn nhiều so với swapper. Điều này gần như đảm bảo cập nhật được thực thi rẻ và ở đầu block, bảo vệ khỏi bị arbitrage bởi toxic flow.

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

Giả sử việc cập nhật Prop AMM liên quan đến việc ghi các biến xác định đường giá của một cặp giao dịch. Dù mã Prop AMM trên Solana là “hộp đen” và market maker muốn giữ bí mật lợi thế, ta dùng giả định này sau khi xem triển khai Prop AMM của Obric trên Sui, nơi các biến xác định báo giá cho cặp giao dịch được ghi vào smart contract qua hàm cập nhật.

https://suiscan.xyz/mainnet/object/0xb84e63d22ea4822a0a333c250e790f69bf5c2ef0c63f4e120e05a6415991368f/contracts

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

Dựa trên giả định này, kiến trúc EVM tạo ra trở ngại lớn khiến mô hình Prop AMM của Solana không khả thi trên EVM.

Nhớ lại rằng trên các blockchain Layer 2 OP-Stack như Base và Unichain, giao dịch được sắp xếp theo Priority Fee trên mỗi Gas (tương tự Solana ưu tiên theo Fee / CU).

Trên EVM, gas cho thao tác ghi rất cao. Một lần ghi lưu trữ đơn giản trên EVM bằng opcode SSTORE đắt gấp nhiều lần so với cập nhật trên Solana.

• SSTORE (từ giá trị 0 sang giá trị khác 0): ~22.100 gas
• SSTORE (từ giá trị khác 0 sang giá trị khác 0): ~5.000 gas
• Swap trên AMM điển hình: ~200.000 - 300.000 gas

Lưu ý Gas trên EVM tương tự Compute Units trên Solana.

Cũng lưu ý các số gas SSTORE trên giả định chỉ có 1 lần ghi mỗi giao dịch (cold writes), hợp lý vì bạn sẽ 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, tỷ lệ gas chỉ khoảng ~10x (cập nhật có thể dùng nhiều SSTORE), so với tỷ lệ ~1000x trên Solana.

Đ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. Do gas cao ngay từ đầu, một khoản priority fee nhỏ không tạo ra tỷ lệ Priority Fee / Gas cao. Đảm bảo cập nhật không bị front-run và lên đầu block sẽ cần priority fee lớn hơn, tốn kém hơn.
2. Do tỷ lệ giữa gas cập nhật và gas swap trên EVM chỉ là 1:10 thay vì 1:1000 trên Solana, một arbitrageur trên EVM chỉ cần tăng Priority Fee lên 10 lần so với giao dịch cập nhật để vượt mặt và front-run cập nhật của market maker, thay vì 1000 lần trên Solana. Trong môi trường tỷ lệ thấp này, arbitrageur dễ front-run cập nhật giá để lấy báo giá lỗi thời vì chi phí không lớn.

Những đổi mới như EIP-1153 (TSTORE cho transient storage) cho phép ghi chỉ 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 giao dịch swap sau (ví dụ trong một block).

Làm sao đưa Prop AMM lên EVM?

Trước khi trả lời, hãy điểm qua “tại sao”. Người dùng luôn muốn báo giá tốt hơn khi giao dịch, nghĩa là họ nhận được giá ưu đãi hơn. Prop AMM trên Ethereum và các Layer 2 sẽ giúp người dùng nhận được báo giá cạnh tranh hơn, vốn chỉ có trên Solana và các sàn tập trung.

Để Prop AMM khả thi trên EVM, hãy nhớ lại một lý do Prop AMM hoạt động tốt trên Solana:

• Cập nhật Prop AMM lên đầu block trên Solana bảo vệ market maker khỏi bị front-run. Cập nhật lên đầu block nhờ dùng rất ít Compute Units, phí thấp vẫn tạo ra tỷ lệ Fee / CU cao, nhất là so với swap.

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

Phương án giảm chi phí ghi khó khả thi do vấn đề tăng trưởng trạng thái trên EVM, nơi SSTORE rẻ sẽ khiến spam trạng thái dễ hơn.

Chúng tôi đề xuất giải pháp theo hướng thứ hai, tạo làn ưu tiên cho cập nhật Prop AMM.

Một cách tiếp cận mới, do @ MarkToda từ đội Uniswap đề xuất, là dùng smart contract Global Storage (repo tại đây) kết hợp với chính sách builder chuyên biệt.

https://github.com/flashbots/global-storage-smart-contract

Kiến trúc hoạt động như sau:

• Global Storage Contract: Một smart contract đơn giản được triển khai làm kho lưu trữ key-value công khai. Market maker ghi các tham số đường giá vào contract này (ví dụ: set(ETH-USDC_CONCENTRATION, 4000)).

Builder Policy: Đây là thành phần offchain quan trọng. Block builder sẽ triển khai chính sách nhận diện giao dịch gửi tới địa chỉ contract Global Storage. Chính sách này tự động dành 5-10% gas của block cho các giao dịch cập nhật này, sắp xếp theo priority fee để ngăn spam.

Lưu ý giao dịch phải có to là địa chỉ Global Storage, vì không muốn giao dịch gọi thêm swap function khác được lên đầu block.

• Dưới đây là ví dụ về thuật toán xây block tùy chỉnh dùng rblib.

• Tích hợp Prop AMM: Contract Prop AMM của market maker được thiết kế để đọc dữ liệu đường giá từ Global Storage contract tại thời điểm swap, khi xác định báo giá cho người dùng.

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

• Bảo vệ: Chính sách builder tạo “làn nhanh” đảm bảo mọi cập nhật giá trong block được thực thi trước bất kỳ swap nào, loại bỏ rủi ro front-running trong cùng block.
• Hiệu quả chi phí: Market maker không còn phải cạnh tranh với mọi người dùng DeFi để lên đầu block bằng gas cao. Thay vào đó, họ chỉ cạnh tranh với các giao dịch cập nhật khác trong thị trường phí cục bộ cho phần ToB dự trữ. Điều này giảm mạnh chi phí ưu tiên thực thi.

Giao dịch swap của người dùng sẽ được thực thi dựa trên đường giá do market maker cập nhật ở đầu block, đảm bảo báo giá mới và được bảo vệ. Mô hình này tái tạo môi trường cập nhật ưu tiên, chi phí thấp đã giúp Prop AMM phát triển mạnh trên Solana, mở đường cho một kỷ nguyên mới về hiệu quả thị trường trên EVM.

Tuy nhiên, mô hình này vẫn có những điểm hạn chế, tôi xin để ngỏ thảo luận ở cuối bài viết.

Kết luận

Khả năng phát triển của Proprietary AMM phụ thuộc vào việc giải quyết bài toán kinh tế cốt lõi: cần thực thi ưu tiên với chi phí thấp để tránh bị front-running.

Kiến trúc EVM tiêu chuẩn khiến việc này trở nên đắt đỏ và rủi ro, nhưng thiết kế mới mang đến cách tiếp cận khác. Bằng cách kết hợp smart contract Global Storage onchain với chính sách builder offchain, chúng ta có thể tạo “làn nhanh” dành riêng cho cập nhật giá. Mô hình này đảm bảo cập nhật oracle lên đầu block, đồng thời thiết lập thị trường phí cục bộ, trực tiếp giải quyết các rào cản cốt lõi và không chỉ giúp Prop AMM khả thi, mà còn có thể thay đổi toàn diện DeFi EVM dựa vào cập nhật oracle lên đầu block.

Các câu hỏi mở

• Prop AMM hoạt động trên EVM với tốc độ Flashblock 200ms có đủ nhanh để cạnh tranh với kiến trúc liên tục của Solana không?
• Trên Solana, phần lớn orderflow AMM đến từ một aggregator là Jupiter, vốn cung cấp SDK để kết nối AMM với aggregator. Trên các Layer 2 EVM, orderflow bị chia nhỏ qua nhiều aggregator không cung cấp SDK công khai. Điều này có gây khó khăn cho Prop AMM trên EVM?
• Prop AMM được triển khai thế nào để cập nhật trên Solana chỉ dùng ~100 CU?
• Mô hình làn nhanh đề xuất chỉ có cập nhật Prop AMM lên đầu block. Nếu Flashblock chỉ nhanh 200ms, có thể xảy ra trường hợp có nhiều swap trong một Flashblock và market maker muốn cập nhật giá giữa các giao dịch đó. Làm sao triển khai?
• Các ngôn ngữ như Yul hoặc Huff có thể dùng để viết chương trình EVM tối ưu hóa, tương tự Pinocchio dùng để viết chương trình Solana tối ưu hóa không?
• Prop AMM so với RFQ khác nhau thế nào?
• Làm sao ngăn market maker đưa báo giá tốt ở block N để dụ user gửi giao dịch ở block N+1, rồi market maker cập nhật báo giá xấu ở block N+1? Jupiter ngăn thế nào?
• Jupiter’s Ultra V3 giới thiệu “Ultra Signaling” cho phép Prop AMM phân biệt giữa toxic flow và non-toxic flow, để cung cấp báo giá chênh lệch chỉ 3 bps. Các tính năng aggregator như vậy quan trọng thế nào để đưa Prop AMM lên EVM?

P.S: Hiện tôi đang tìm slot diễn giả hội thảo để nói về chủ đề này. Nếu bạn kết nối với sự kiện nào trong Devconnect, tôi rất mong được trao đổi về cơ hội diễn thuyết!

Tuyên bố miễn trừ trách nhiệm:

1. Bài viết này được đăng lại từ [0xOptimus]. Mọi bản quyền thuộc về tác giả gốc [0xOptimus]. Nếu có ý kiến về việc đăng lại, vui lòng liên hệ đội ngũ Gate Learn, chúng tôi sẽ xử lý kịp thời.
2. Tuyên bố miễn trừ trách nhiệm: Quan điểm và ý kiến trong bài viết này hoàn toàn thuộc về tác giả, không cấu thành lời khuyên đầu tư nào.
3. Bản dịch bài viết sang các ngôn ngữ khác do đội ngũ Gate Learn thực hiện. Nếu không có thông báo, việc sao chép, phân phối hoặc đạo văn bản dịch bị nghiêm cấm.