Tại sao Solana có đầy Prop AMM nhưng vẫn trống trên EVM?

Tiêu đề gốc: Những ứng dụng phi tập trung (dApp) phải theo dõi sau khi ra mắt Mainnet Monad

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

Người dịch gốc: Dingdang, Odaily Planet Daily

Các AMM độc quyền (Prop AMM) đã nhanh chóng chiếm lĩnh 40% tổng khối lượng giao dịch Solana. Tại sao chúng vẫn chưa có mặt trên EVM?

Các nhà tạo lập thị trường tự động độc quyền (Prop AMM) đang nhanh chóng trở thành một thế lực thống trị trong hệ sinh thái Solana DeFi, hiện đóng góp hơn 40% khối lượng giao dịch trong các cặp giao dịch chính. Các sàn giao dịch thanh khoản chuyên biệt do các nhà tạo lập thị trường chuyên nghiệp vận hành này cung cấp thanh khoản sâu và giá cả cạnh tranh hơn, chủ yếu là vì chúng giảm đáng kể rủi ro chênh lệch giá trước khi sử dụng báo giá cũ.

Nguồn ảnh: dune.com

Tuy nhiên, thành công của họ hầu như chỉ giới hạn ở Solana. Ngay cả trên các mạng Lớp 2 nhanh và chi phí thấp như Base hoặc Optimism, Prop AMM vẫn còn hiếm 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 tập trung vào ba câu hỏi: Prop AMM là gì, chúng phải đối mặt với những rào cản kỹ thuật và kinh tế nào trên chuỗi EVM và những kiến trúc mới đầy hứa hẹn có thể đưa chúng lên vị trí hàng đầu trong EVM DeFi.

Prop AMM là gì? Prop AMM là một nhà tạo lập thị trường tự động (AMM), trong đó một nhà tạo lập thị trường chuyên nghiệp duy nhất chủ động quản lý thanh khoản và giá cả, thay vì dựa vào nguồn vốn thụ động từ công chúng như trong các AMM truyền thống. Các 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 biểu thị số lượng của hai tài sản trong nhóm, và k là một hằng số. Tuy nhiên, trong Prop AMM, công thức định giá không cố định mà được cập nhật thường xuyên (thường nhiều lần mỗi giây). Vì cơ chế nội bộ của hầu hết các Prop AMM là "hộp đen", nên thuật toán chính xác mà chúng sử dụng vẫn chưa được biết. Tuy nhiên, mã cho hợp đồng thông minh Prop AMM của Obric trên chuỗi Sui được công khai (cảm ơn @markoggwp vì khám phá của anh ấy), và bất biến k của nó phụ thuộc vào các biến nội bộ mult_x, mult_y và concentration. Sơ đồ bên dưới 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ều cần làm rõ là công thức ở phía bên trái của đường cong giá Obric phức tạp hơn một công thức x*y đơn giản, nhưng chìa khóa để 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 sẽ liên tục cập nhật k này để điều chỉnh đường cong giá.

Đánh giá: AMM xác định giá như thế nào?

Trong bài viết này, chúng ta sẽ đề cập nhiều lần đến khái niệm "đường cong giá". Đường cong giá xác định mức giá mà người dùng cần trả khi sử dụng giao dịch AMM, và đây 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 về điều này, trước tiên chúng ta hãy cùng xem xét phương pháp định giá của các AMM truyền thống. Lấy nhóm WETH-USDC trên Uniswap v2 làm ví dụ (giả sử không có phí). Giá được xác định thụ động theo công thức x * y = k. Giả sử có 100 WETH và 400.000 USDC trong nhóm, các điểm đường cong là x = 100 và y = 400.000, tương ứng với giá ban đầu là 400.000 / 100 = 4.000 USDC/WETH. Từ đó, hằng số k = 100 * 400.000 = 40.000.000. Nếu một nhà giao dịch muốn mua 1 WETH, họ cần thêm USDC vào nhóm, giảm WETH trong nhóm xuống còn 99. Để duy trì tích k không đổi, điểm mới (x, y) vẫn phải nằm trên đường cong, do đó y phải trở thành 40.000.000 / 99 ≈ 404.040,40. Điều này có nghĩa là nhà giao dịch đã trả khoảng 4.040,40 USDC cho 1 WETH, cao hơn một chút so với giá ban đầu. Hiện tượng này được gọi là "trượt giá". Đây là lý do tại sao x*y=k được gọi là "đường cong giá": bất kỳ giá nào có thể 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 lại chọn thiết kế AMM thay vì sổ lệnh tập trung (CLOB)?

Hãy cùng giải thích lý do tại sao nhà tạo lập thị trường lại 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à nhà tạo lập thị trường đang báo giá trên sổ lệnh giới hạn tập trung (CLOB) trên chuỗi. Để cập nhật báo giá, bạn cần hủy và thay thế hàng nghìn lệnh giới hạn. Nếu bạn có N lệnh, thì việc cập nhật sẽ mất một thao tác O(N), chậm và tốn kém trên chuỗi.

Sẽ thế nào nếu bạn có thể biểu diễn tất cả các mức giá bằng một đường cong toán học duy nhất? Bạn chỉ cần cập nhật một vài tham số xác định đường cong này, biến đổi một phép toán O(N) thành một phép toán có độ phức tạp hằng số O(1). Để hình dung cách một "đường cong giá" tương ứng với các khoảng giá hiệu dụng khác nhau, chúng ta có thể tham khảo SolFi, một Prop AMM dựa trên Solana, do Ellipsis Labs tạo ra. Mặc dù đường cong giá cụ thể của nó chưa được biết và ẩn, Ghostlabs đã vẽ một biểu đồ hiển thị giá hiệu dụng khi trao đổi các lượng SOL khác nhau lấy USDC trong một slot Solana (khoảng thời gian khối). Mỗi đường biểu diễn một nhóm WSOL/USDC khác nhau, cho thấy có thể tồn tại nhiều mức giá cùng lúc. Khi các nhà tạo lập thị trường cập nhật đường cong giá, biểu đồ giá hiệu dụng này cũng sẽ thay đổi giữa các slot khác nhau.

Nguồn ảnh: github

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

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

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

1. Cập nhật giá rẻ

2. Thực thi ưu tiên

Trên Solana, hai yếu tố này bổ sung cho nhau: Cập nhật giá rẻ thường có nghĩa là các bản cập nhật có thể được thực hiện với mức độ ưu tiên.

Tại sao các 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á với tốc độ của blockchain dựa trên những thay đổi về hàng tồn kho hoặc biến động giá chỉ số tài sản (chẳng hạn như giá trên các sàn giao dịch tập trung). Trên một chuỗi tần suất cao như Solana, nếu chi phí cập nhật quá cao, việc điều chỉnh tần suất cao sẽ khó thực hiện được.

Thứ hai, nếu các nhà tạo lập thị trường không thể xếp hàng cập nhật lên đầu khối, giá cũ của họ sẽ bị các nhà đầu cơ chênh lệch giá "sao chép", dẫn đến thua lỗ không thể tránh khỏi. Nếu không có hai tính năng này, các nhà tạo lập thị trường không thể hoạt động hiệu quả và người dùng sẽ nhận được giá giao dịch kém hơn.

Lấy Solana Prop AMM HumidiFi 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 giá lên đến 74 lần mỗi giây.

Từ EVM, người chơi có thể thắc mắc: "Các khe của Solana có chu kỳ khoảng 400ms. Làm thế nào một Prop AMM có thể cập nhật giá nhiều lần trong một khe?"

Câu trả lời nằm ở kiến trúc liên tục của Solana, về cơ bản khác với mô hình khối rời rạc của EVM. · EVM: Các giao dịch thường được thực hiện tuần tự sau khi một khối đầy đủ được đề xuất và hoàn tất. Điều này có nghĩa là các bản cập nhật được gửi giữa khối sẽ không có hiệu lực cho đến khối tiếp theo. · Solana: Trình xác thực hàng đầu không chờ khối đầy đủ. Thay vào đó, chúng chia các 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. Nhiều lần hoán đổi có thể diễn ra trong một khe duy nhất, nhưng việc cập nhật giá cho shred #1 sẽ ảnh hưởng đến swap #1, và việc cập nhật giá cho shred #2 sẽ ảnh hưởng đến swap #2. Lưu ý: Flashblock tương tự như shred của Solana. Theo @Ashwinningg của Anza Labs tại hội nghị CBER, mỗi khe 400ms được giới hạn ở 32.000 shred, tương đương 80 shred mỗi mili giây. Liệu Flashblock 200ms có đủ nhanh để đáp ứng nhu cầu của các nhà tạo lập thị trường hay không vẫn là một câu hỏi chưa có lời giải so với kiến trúc liên tục của Solana.

Vậy, tại sao chi phí cập nhật trên Solana lại rẻ như vậy? Và điều này dẫn đến việc thực thi được ưu tiên như thế nào?

Đầu tiên, mặc dù việc triển khai Prop AMM trên Solana là một hộp đen, nhưng có những thư viện như Pinocchio có thể tối ưu hóa các chương trình Solana cho CU. Blog của Helius có một bài giới thiệu tuyệt vời về điều này, cho thấy rằng khi sử dụng thư viện này, các chương trình Solana có thể giảm mức tiêu thụ CU từ khoảng 4.000 xuống còn khoảng 100 CU.

Nguồn ảnh: github

Chúng ta hãy xem phần thứ hai. Ở cấp độ cao, Solana ưu tiên các giao dịch bằng cách chọn những giao dịch có tỷ lệ Phí/Đơn vị tính toán cao nhất (Đơn vị tính toán tương tự như EVM gas), tương tự như EVM.

· Cụ thể, nếu sử dụng Jito, công thức là Jito Tip/Đơn vị tính toán

· Không có Jito: Ưu tiên = (Phí ưu tiên + Phí cơ bản) / (1 + CU Cap + CU chữ ký + CU khóa ghi)

So sánh Đơn vị tính toán của các bản cập nhật Prop AMM và Jupiter Swap, chúng ta có thể thấy rằng các bản cập nhật cực kỳ rẻ, với tỷ lệ 1:1000.

Cập nhật Prop AMM: Cập nhật đường cong đơn giản cực kỳ rẻ. Cập nhật Wintermute chỉ tốn 109 CU, với tổng phí chỉ 0,000007506 SOL

Hoán đổi Jupiter: Hoán đổi được định tuyến qua Jupiter có thể lên tới ~100.000 CU, với tổng phí là 0,000005 SOL

Do sự chênh lệch lớn này, các nhà tạo lập thị trường chỉ cần trả một khoản phí nhỏ cho các giao dịch cập nhật, đạt được tỷ lệ Phí/CU cao hơn nhiều so với hoán đổi, do đó đảm bảo rằng các cập nhật được thực hiện ở đầu khối và tự bảo vệ mình khỏi các cuộc tấn công chênh lệch giá.

Tại sao Prop AMM vẫn chưa được triển khai trên EVM?

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

Cảm ơn @markoggwp vì khám phá này!

Sử dụng giả thuyết này, chúng tôi phát hiện ra rằng kiến trúc của EVM có những trở ngại đáng kể khiến mô hình Prop AMM của Solana không khả thi trên EVM.

Hãy nhớ rằng trên các blockchain OP-Stack Lớp 2 như Base và Unichain, các giao dịch được sắp xếp theo thứ tự ưu tiên cho mỗi phí gas (tương tự như cách sắp xếp Phí/CU của Solana).

Trên EVM, các hoạt động ghi có chi phí gas rất cao. So với các bản cập nhật Solana, việc ghi giá trị vào EVM thông qua opcode SSTORE tốn kém một cách đáng ngạc nhiên: · SSTORE (0 → not-0): ~22.100 gas · SSTORE (not-0 → not-0): ~5.000 gas · Hoán đổi AMM thông thường: ~200.000–300.000 gas Lưu ý: Gas trên EVM tương tự như Đơn vị tính toán (CU) trên Solana. Các số gas SSTORE ở trên chỉ giả định một lần ghi duy nhất cho mỗi giao dịch (ghi lạnh), điều này là hợp lý vì bạn thường không gửi nhiều bản cập nhật trong một giao dịch. Mặc dù các bản cập nhật vẫn rẻ hơn hoán đổi, nhưng mức sử dụng gas chỉ cao hơn khoảng 10 lần (các bản cập nhật có thể liên quan đến nhiều SSTORE), trong khi trên Solana, mức sử dụng gas cao hơn khoảng 1000 lần. Điều này dẫn đến hai hậu quả, khiến cùng một mô hình Solana Prop AMM trở nên rủi ro hơn trên EVM: 1. Mức tiêu thụ gas cao khiến việc ưu tiên các bản cập nhật bằng phí ưu tiên trở nên khó khăn. Phí ưu tiên thấp giúp ngăn ngừa tỷ lệ phí/gas cao. Để đảm bảo các bản cập nhật không bị xếp vào nhóm đầu tiên và được đặt ở đầu các khối, cần có mức phí ưu tiên cao hơn, làm tăng chi phí. 2. Rủi ro chênh lệch giá cao hơn trên EVM. Tỷ lệ khí cập nhật so với khí trao đổi trên EVM chỉ là 1:10, trong khi trên Solana là 1:1000. Điều này có nghĩa là các nhà đầu cơ chênh lệch giá chỉ cần tăng phí ưu tiên lên 10 lần để chạy trước các bản cập nhật của nhà tạo lập thị trường, trong khi trên Solana, con số này là 1000 lần. Với tỷ lệ thấp hơn này, các nhà đầu cơ chênh lệch giá có nhiều khả năng chạy trước các bản cập nhật giá để có được báo giá lỗi thời vì chi phí rẻ hơn.Một số cải tiến (chẳng hạn như TSTORE của EIP-1153 để lưu trữ tạm thời) cung cấp khả năng ghi với khoảng 100 gas, nhưng khả năng lưu trữ này chỉ tồn tại trong một giao dịch duy nhất, khiến nó không phù hợp để duy trì cập nhật giá cho các lần hoán đổi tiếp theo (ví dụ: trên một khối). Làm thế nào để đưa Prop AMM vào EVM? Trước khi trả lời câu hỏi đó, trước tiên chúng ta hãy trả lời câu hỏi "tại sao": người dùng luôn muốn có báo giá giao dịch tốt hơn, đồng nghĩa với việc giao dịch tiết kiệm chi phí hơn. Prop AMM trên Ethereum và Layer 2 có thể cung cấp cho người dùng báo giá cạnh tranh mà trước đây chỉ có trên Solana hoặc các sàn giao dịch tập trung. Để Prop AMM khả thi trên EVM, chúng ta hãy xem xét lại một trong những lý do thành công của nó trên Solana: Bảo vệ cập nhật đầu khối: Trên Solana, các bản cập nhật Prop AMM được đặt ở đầu khối, bảo vệ các nhà tạo lập thị trường khỏi việc chạy trước. Việc đặt các bản cập nhật này là do mức tiêu thụ đơn vị tính toán (CU) tối thiểu, cho phép tỷ lệ phí/CU cao ngay cả khi phí thấp, đặc biệt là khi so sánh với swap. Vậy, làm thế nào để các bản cập nhật Prop AMM ở đầu khối được đưa vào blockchain EVM Lớp 2? Có hai cách tiếp cận: hoặc giảm chi phí ghi chúng, hoặc tạo một kênh ưu tiên cho các bản cập nhật Prop AMM. Việc giảm chi phí ghi chúng là không khả thi do vấn đề tăng trưởng trạng thái của EVM, vì các SSTORE giá rẻ có thể dẫn đến các cuộc tấn công trạng thái rác. Chúng tôi đề xuất tạo một kênh ưu tiên cho các bản cập nhật Prop AMM. Đây là một giải pháp khả thi và là trọng tâm của bài viết này.

@MarkToda từ nhóm Uniswap đã đề xuất một cách tiếp cận mới bằng cách sử dụng hợp đồng thông minh lưu trữ toàn cầu + chiến lược xây dựng khối chuyên biệt:

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

· Hợp đồng lưu trữ toàn cầu:Triển khai một hợp đồng thông minh đơn giản dưới dạng kho lưu trữ khóa-giá trị công khai. Người tạo lập thị trường ghi các 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à một thành phần quan trọng ngoài chuỗi. Block builder xác định các giao dịch được gửi đến hợp đồng lưu trữ toàn cầu, phân bổ 5–10% gas đầu tiên của khối cho các giao dịch cập nhật này và ưu tiên chúng theo phí để ngăn chặn thư rác. Lưu ý: Giao dịch phải được gửi trực tiếp đến địa chỉ lưu trữ toàn cầu; nếu không, chúng không được đảm bảo nằm ở đầu khối. Để biết ví dụ về các thuật toán xây dựng khối tùy chỉnh, hãy xem rblib. Hợp đồng Prop AMM dành cho các nhà tạo lập thị trường đọc dữ liệu đường cong giá từ hợp đồng lưu trữ toàn cầu trong quá trình hoán đổi để 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 ra một "làn đường nhanh" để đảm bảo tất cả các cập nhật giá trong một khối được thực hiện trước các giao dịch, loại bỏ rủi ro chạy trước. 2. Hiệu quả về chi phí: Các nhà tạo lập thị trường không còn cạnh tranh với tất cả người dùng DeFi về giá gas cao để giao dịch ở đầu khối. Thay vào đó, họ cạnh tranh trên thị trường phí địa phương để giành khối cao nhất dành riêng cho các giao dịch được cập nhật, giúp giảm đáng kể chi phí. Giao dịch của người dùng được thực hiện theo đường cong giá do nhà tạo lập thị trường thiết lập trong lần cập nhật ban đầu của cùng một khối, đảm bảo tính mới mẻ và an toàn của báo giá. Mô hình này mô phỏng 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ẽ thảo luận ở cuối bài viết này.

Kết luận

Tính khả thi của Prop AMM phụ thuộc vào việc giải quyết một vấn đề kinh tế cốt lõi: thực hiện chi phí thấp và được ưu tiên để ngăn chặn tình trạng chạy trước.

Mặc dù kiến trúc EVM tiêu chuẩn khiến các hoạt động như vậy tốn kém và rủi ro, thiết kế mới này mang đến một cách tiếp cận khác cho vấn đề này. Kết hợp hợp đồng thông minh lưu trữ toàn cầu trên chuỗi với chiến lược xây dựng ngoài chuỗi, thiết kế mới này tạo ra một "làn đường nhanh" chuyên dụng, đảm bảo thực hiện cập nhật ở đầu khối, đồng thời thiết lập một thị trường phí cục bộ được kiểm soát. Điều này không chỉ giúp Prop AMM khả thi trên EVM mà còn có tiềm năng cách mạng hóa mọi EVM DeFi dựa trên các bản cập nhật oracle hàng đầu.

Câu hỏi mở

· Tốc độ Flashblock 200ms của Prop AMM trên EVM có đủ nhanh để cạnh tranh với kiến trúc liên tục của Solana không?

· Hầu hết lưu lượng AMM trên Solana đến từ một bộ tổng hợp duy nhất, Jupiter, cung cấp SDK để tích hợp AMM dễ dàng. Tuy nhiên, trên EVM Lớp 2, lưu lượng được phân tán trên nhiều bộ tổng hợp và không có SDK công khai. Điều này có đặt ra thách thức cho Prop AMM không?

· Các bản cập nhật Prop AMM trên Solana chỉ tiêu tốn ~100 CU. Điều này được triển khai như thế nào?

· Mô hình kênh nhanh chỉ đảm bảo các bản cập nhật ở đầu khối. Nếu có nhiều giao dịch hoán đổi trong một khối flash, các nhà tạo lập thị trường cập nhật giá trên các giao dịch hoán đổi này như thế nào?

· Các chương trình EVM được tối ưu hóa có thể được viết bằng các ngôn ngữ như Yul hoặc Huff, tương tự như sơ đồ tối ưu hóa Pinocchio trên Solana không?

· Prop AMM so với RFQ như thế nào?

· Làm thế nào chúng ta có thể ngăn chặn các nhà tạo lập thị trường đưa ra các báo giá chất lượng cao trong khối N để thu hút người dùng, sau đó cập nhật thành các báo giá kém chất lượng trong khối N+1? Jupiter ngăn chặn điều này bằng cách nào?

· Tính năng Ultra Signaling của Jupiter Ultra V3 cho phép Prop AMM phân biệt giữa lưu lượng có hại và vô hại và cung cấp các báo giá chặt chẽ hơn. Các tính năng tổng hợp này quan trọng như thế nào đối với Prop AMM trên EVM?

Liên kết gốc