Chi tiết về MEV mô-đun: Làm cách nào để đạt được thứ tự giao dịch công bằng?
Tuyển chọn TechFlowTuyển chọn TechFlow
Chi tiết về MEV mô-đun: Làm cách nào để đạt được thứ tự giao dịch công bằng?
Lý do đằng sau việc xây dựng theo hướng mô-đun không nên chỉ để phù hợp với câu chuyện, mà là vì nó mang lại các ứng dụng tốt hơn, hiệu quả hơn và có thể tùy chỉnh cao hơn.
Chuyên sâu báo cáo Web3Tác giả: Maven11
Biên dịch: Luffy, Foresight News
Trong hai phần đầu tiên của loạt bài nghiên cứu này, chúng tôi chủ yếu tập trung vào các vấn đề kỹ thuật phát sinh khi phân tách stack và những cải tiến cần thiết trong thế giới mô-đun. Chúng tôi đã giới thiệu nhiều tiến triển nhằm giải quyết các vấn đề tự nhiên xuất hiện trong thiết lập đa miền. Tuy nhiên, ở phần cuối cùng của loạt bài này, chúng tôi muốn tập trung nhiều hơn vào trải nghiệm người dùng. Chúng tôi muốn tìm hiểu cách thức mô-đun hóa, tùy chỉnh và chuyên biệt hóa có thể giúp tạo ra các ứng dụng tốt hơn. Chương cuối cùng của loạt bài này sẽ khám phá những sáng tạo và khả năng thú vị, độc đáo trong mô-đun hóa, nơi các nhà phát triển có thể xây dựng trải nghiệm người dùng Web2 với khả năng xác minh của Web3.
Lý do xây dựng hệ thống mô-đun không nên chỉ để theo xu hướng hay vì tính mô-đun, mà là bởi vì nó cho phép chúng ta xây dựng các ứng dụng tốt hơn, hiệu quả hơn và dễ tùy biến hơn. Khi xây dựng các hệ thống mô-đun và chuyên dụng, nhiều chức năng độc đáo sẽ xuất hiện. Một số rõ ràng, một số thì không. Vì vậy, mục tiêu của chúng tôi là cung cấp cái nhìn tổng quan về những khả năng của hệ thống mô-đun mà bạn chưa từng biết đến, ví dụ như khả năng mở rộng.
Chúng tôi cho rằng một trong những khả năng mà mô-đun hóa mang lại cho các nhà phát triển là khả năng xây dựng các ứng dụng chuyên biệt, có độ tùy chỉnh cao, từ đó mang lại trải nghiệm tốt hơn cho người dùng cuối. Trước đây, chúng tôi đã thảo luận về việc thiết lập quy tắc hoặc sắp xếp lại thứ tự thực thi giao dịch.
Quy tắc sắp xếp có thể xác minh (sau đây gọi tắt là VSR) là một trong những cơ hội thú vị mà kiểm soát việc sắp xếp mang lại, đặc biệt đối với các nhà phát triển quan tâm đến việc xây dựng hệ thống giao dịch "công bằng hơn" về mặt thực thi. Rõ ràng, tổn thất của nhà cung cấp thanh khoản liên quan đến tái cân bằng (LVR) nằm ngoài phạm vi bài viết này, vì vậy chúng tôi sẽ tránh đi sâu vào lĩnh vực này. Cần lưu ý rằng các thiết lập được trình bày dưới đây chủ yếu dành cho AMM chứ không phải mô hình sổ lệnh. Ngoài ra, CLOB (thậm chí cả CEX) cũng sẽ được hưởng lợi rất lớn từ việc tận dụng các quy tắc sắp xếp có thể xác minh phù hợp với thiết lập cụ thể của họ. Trong môi trường off-chain, rõ ràng cần có một khái niệm về thực thi zero-knowledge hoặc lạc quan, được hỗ trợ bởi bảo mật kinh tế học mã hóa.
VSR trở nên đặc biệt thú vị khi ta nhận ra rằng phần lớn các nhà giao dịch bán lẻ vẫn chưa (hoặc khó có thể) áp dụng các phương pháp bảo vệ. Hầu hết ví/Dex cũng chưa triển khai mempool riêng tư, RPC hoặc các phương pháp tương tự. Phần lớn giao dịch đều được gửi trực tiếp qua giao diện người dùng (dù là aggregator hay giao diện DEX). Do đó, trừ khi ứng dụng can thiệp trực tiếp vào quy trình xử lý đơn hàng, hiệu quả thực thi mà người dùng cuối nhận được có thể không lý tưởng.
Khi xem xét vị trí của việc sắp xếp chuỗi cung ứng giao dịch, vai trò của VSR trở nên rõ ràng. Nó nằm ở nơi các bên tham gia chuyên nghiệp sắp xếp (hoặc bao gồm) giao dịch, thường dựa trên một cuộc đấu giá hoặc phí cơ bản nào đó. Việc sắp xếp này rất quan trọng vì nó quyết định giao dịch nào được thực thi và khi nào được thực thi. Về bản chất, ai nắm quyền sắp xếp sẽ có khả năng trích xuất MEV, thường dưới dạng phí ưu tiên (hoặc tiền boa).
Do đó, việc viết các quy tắc xử lý việc sắp xếp để mang lại thực thi giao dịch công bằng hơn cho người dùng cuối (trong thiết lập DEX) có thể rất thú vị. Tuy nhiên, nếu bạn đang xây dựng một mạng lưới phổ quát, bạn nên tránh tuân thủ các quy tắc như vậy.
Hơn nữa, một số MEV là quan trọng, như chênh lệch giá, thanh lý, v.v. Một ý tưởng là xây dựng một làn đường "cao tốc" ở đỉnh khối, dành riêng cho các bên arbitrage và thanh lý trong danh sách trắng, những người trả phí cao hơn và chia sẻ một phần doanh thu với giao thức.
Trong bài báo Thiết kế Sàn giao dịch phi tập trung đáng tin cậy thông qua Quy tắc sắp xếp có thể xác minh, Matheus V., X. Ferreira và David C. Parkes đã đề xuất một mô hình trong đó bộ sắp xếp khối bị ràng buộc bởi một loạt quy tắc thực thi (và các ràng buộc này có thể xác minh được). Trong trường hợp không tuân thủ các quy tắc đã đặt, người quan sát có thể tạo ra bằng chứng lỗi (hoặc do các ràng buộc là có thể xác minh toán học, bạn cũng có thể hình dung một mạch ZK với các ràng buộc này sử dụng ZKP làm bằng chứng hợp lệ). Ý tưởng chính về cơ bản là đảm bảo mức giá thực thi cho người dùng cuối (người giao dịch). Đảm bảo này đảm bảo rằng giá thực thi giao dịch tốt như giao dịch duy nhất trong khối (rõ ràng, nếu giả sử thứ tự mua/bán/mua/bán dựa trên đến trước phục vụ trước, thì ở đây có mức độ trễ nhất định). Ý tưởng cơ bản của đề xuất trong bài báo là, nếu chúng được thực thi với mức giá tốt hơn mức giá sẵn có ở đỉnh khối, các quy tắc sắp xếp sẽ giới hạn người xây dựng (trong kịch bản PBS) hoặc bộ sắp xếp chỉ đưa giao dịch vào cùng hướng (ví dụ bán/bán). Ngoài ra, nếu xảy ra trường hợp bạn bán ra sau một chuỗi mua, thì giao dịch bán sẽ không được thực thi (ví dụ: mua, mua, mua, bán), điều này có thể cho thấy người tìm kiếm (hoặc người xây dựng/bộ sắp xếp) đang lợi dụng các giao dịch mua để đẩy giá theo hướng có lợi cho họ. Về cơ bản, điều này có nghĩa là các quy tắc giao thức đảm bảo người dùng sẽ không bị sử dụng để mang lại mức giá tốt hơn cho người khác (tức là MEV), hoặc bị trượt giá do phí ưu tiên. Rõ ràng, điểm yếu của các quy tắc ở đây (trong trường hợp số lượng bán nhiều hơn số lượng mua và ngược lại) là bạn có thể nhận được mức giá đuôi dài tương đối kém.
Đối với nền tảng hợp đồng thông minh nói chung, gần như không thể áp dụng các quy tắc này như các quy tắc cấu trúc hoàn toàn on-chain vì bạn không thể kiểm soát việc thực thi và sắp xếp. Đồng thời, bạn còn cạnh tranh với nhiều người khác, do đó cố gắng ép buộc những người ở đỉnh khối phải trả phí ưu tiên sẽ tốn kém không cần thiết. Một trong những chức năng của thiết lập mô-đun là cho phép các nhà phát triển ứng dụng tùy chỉnh cách hoạt động của môi trường thực thi. Cho dù là quy tắc sắp xếp, sử dụng máy ảo khác nhau hay thay đổi tùy chỉnh VM hiện tại (ví dụ thêm opcode mới hoặc thay đổi giới hạn Gas), thực tế phụ thuộc vào nhà phát triển và sản phẩm của họ.
Trong trường hợp một Rollup sử dụng lớp khả dụng dữ liệu, lớp đồng thuận và lớp thanh khoản kết toán, cấu hình có thể như sau:
Một ý tưởng khả thi khác là phân chia giao dịch. Hãy tưởng tượng một pool giao dịch, làm thế nào để thực thi một giao dịch lớn (gây ra trượt giá lớn)? Nếu giao dịch này được thực thi xuyên suốt các khối liên tục (hoặc nếu phù hợp với VSR, thực thi ở cuối khối), điều này có công bằng với người dùng cuối không?
Nếu người dùng cuối quan tâm đến độ trễ, họ có thể không muốn đơn hàng của mình bị chia nhỏ. Tuy nhiên, tình huống này khá hiếm, và tối ưu hóa việc phân chia giao dịch cho đơn hàng lớn có thể mang lại hiệu quả thực thi cao hơn cho phần lớn người dùng. Dù sao đi nữa, một mối lo ngại là kẻ săn MEV có thể nhận ra các giao dịch liên tục này và cố gắng đặt giao dịch của họ trước hoặc sau giao dịch viên trên. Tuy nhiên, do việc chia nhỏ giao dịch thành các khối liên tiếp, tổng giá trị MEV bị trích xuất có thể giảm đáng kể.
Một ý tưởng thú vị khác mà chúng tôi đã đề cập trước đây trong bài đăng là sử dụng Đấu giá lô thường xuyên (FBA) do nhân vật huyền thoại Eric Budish và các đồng nghiệp ủng hộ, xử lý giao dịch theo hình thức đấu giá lô thay vì tuần tự. Mục đích là giúp phát hiện sự trùng lặp nhu cầu (CoW) và tích hợp cơ hội arbitrage vào thiết kế cơ chế thị trường. Điều này cũng giúp "chống lại" trò chơi trễ trong việc xây dựng khối liên tiếp (hoặc cuộc chiến phí ưu tiên trong khối tuần tự). Cảm ơn Michael Jordan (DBA) đã chỉ ra bài báo này và cảm ơn anh ấy vì những nỗ lực làm dịu Latency Roast. Việc triển khai nó như một phần của quy tắc lựa chọn phân nhánh và sắp xếp Rollup cũng là một thiết lập thú vị mà các nhà phát triển có thể sử dụng, và chúng tôi đã thấy sức hút đáng kể của nó trong năm qua, đặc biệt với Penumbra và CoWSwap. Một thiết lập khả dĩ như sau:
Trong thiết lập này, không có cơ chế đến trước phục vụ trước hay cuộc chiến phí Gas ưu tiên, mà là đấu giá lô kết thúc khối dựa trên các đơn hàng tích lũy giữa các khoảng thời gian khối.
Nhìn chung, khi phần lớn giao dịch đã chuyển sang thế giới "on-chain" phi lưu ký, FBA có thể là một trong những cách hiệu quả hơn để "phát hiện giá thật", tùy thuộc vào thời gian khối. Việc tận dụng FBA cũng có nghĩa là, do tất cả các đơn hàng lớn đều được xử lý theo lô và không tiết lộ trước khi đấu giá kết thúc (giả sử có một thiết lập mã hóa), giao dịch trước sẽ giảm đáng kể. Giá thanh toán đồng nhất là yếu tố then chốt ở đây, vì việc sắp xếp lại giao dịch là vô nghĩa.
Cũng cần chỉ ra rằng, ngay từ năm 2018, các thiết kế tương tự như chúng tôi vừa giới thiệu đã được thảo luận trên diễn đàn Ethresear.ch (xem tại đây). Trong bài đăng, họ đề cập đến hai bài báo, cung cấp cơ chế đấu giá lô trên Plasma (giống như phiên bản tiền thân của Rollup hiện đại), trong đó mỗi lô chấp nhận các đơn hàng mua ERC20 khác với mức giá trần nhất định. Các đơn hàng này được thu thập trong một khoảng thời gian nhất định và cung cấp giá thanh toán đồng nhất cho tất cả cặp giao dịch token. Ý tưởng tổng thể đằng sau mô hình này là giúp loại bỏ hiện tượng giao dịch trước phổ biến trong AMM thông dụng.
Một điểm quan trọng khác cần lưu ý là trong các thiết lập này, bộ sắp xếp có thể cần một số động lực để thực thi (và thực thi) các quy tắc trên. Điểm này thường bị bỏ qua, nhưng phần lớn cơ sở hạ tầng mạng blockchain được vận hành bởi các công ty chuyên nghiệp, chi phí của họ hoàn toàn khác so với người tham gia bình thường tại nhà. Nhìn chung, động lực là thành phần quan trọng trong việc triển khai cơ sở hạ tầng an toàn. Khi động lực phù hợp với các quy tắc được thực thi, bộ sắp xếp và người xây dựng cũng có nhiều khả năng nỗ lực hơn. Điều này có nghĩa là các thiết lập này cũng nên có một thị trường sôi động. Rõ ràng, thị trường như vậy đang ngày càng tập trung, vì chi phí vốn chuyên môn có thể rất cao. Do đó, những người thông minh nhất (và giàu có nhất) có thể tập hợp và chuyên môn hóa để thu về nhiều giá trị nhất có thể. Ở đây, luồng đơn hàng độc quyền có thể là mũi tên bắn vào đầu gối đối với một số người tham gia, dẫn đến sự gia tăng tập trung. Phí chuẩn chung có thể đã đủ, nhưng nó không thực sự thúc đẩy người tham gia sắp xếp hướng tới chuyên môn hóa. Do đó, bạn có thể muốn giới thiệu một số khái niệm khuyến khích phù hợp với trường hợp cụ thể của bạn để người giao dịch hài lòng với kết quả.
Điều này rất rõ ràng với hầu hết mọi người, nhưng vẫn cần đề cập khi thảo luận về việc sắp xếp ở cấp độ Rollup. Nếu bạn có thể kiểm soát việc sắp xếp, bạn có thể dễ dàng "trích xuất" giá trị từ giao thức. Bởi vì bạn kiểm soát quyền sắp xếp lại giao dịch, thường dựa trên phí ưu tiên trên hầu hết các L1 (thiết lập kiểu MEV-boost). Nó mang lại cho bạn phí ưu tiên từ những người tham gia phức tạp trên chuỗi sẵn sàng trả để trích xuất giá trị. Những người này thường sẵn sàng trả một khoản tiền khá lớn (cho đến khi việc đó không còn mang lại giá trị). Tuy nhiên, hiện tại hầu hết các Rollup chủ yếu sử dụng cơ chế đến trước phục vụ trước. Phần lớn việc trích xuất MEV được thực hiện thông qua cuộc chiến trễ, gây áp lực nghiêm trọng lên cơ sở hạ tầng Rollup. Do những lý do trên, chúng ta có thể sẽ thấy ngày càng nhiều Rollup bắt đầu triển khai cấu trúc sắp xếp có khái niệm phí ưu tiên (ví dụ cơ chế tăng cường thời gian của Arbitrum).
Một ví dụ khác mà chúng tôi yêu thích là Uniswap. Hiện tại, Uniswap như một giao thức "tạo ra" rất nhiều sự kém hiệu quả. Những hành vi kém hiệu quả này bị khai thác bởi các bên tìm cách trích xuất MEV (arbitrage, lấy lợi ích của nhà cung cấp thanh khoản). Đồng thời, những bên này trả phí lớn để trích xuất giá trị, nhưng không đồng nào trong số đó rơi vào tay giao thức Uniswap hay người nắm giữ token của nó. Thay vào đó, phần lớn giá trị bị trích xuất này được trả dưới dạng phí ưu tiên cho người đề xuất Ethereum (trình xác thực) thông qua MEV-Boost để giành quyền được đưa vào khối tại thời điểm nhất định nhằm bắt được giá trị. Do đó, mặc dù dòng đơn hàng Uniswap chứa nhiều cơ hội MEV, nhưng không có cơ hội nào được Uniswap thu lại.
Nếu Uniswap có thể kiểm soát việc sắp xếp trong giao thức (và khả năng trích xuất phí ưu tiên từ các bên tìm kiếm), nó có thể thương mại hóa, thậm chí có thể chia một phần lợi nhuận cho người nắm giữ token, nhà cung cấp thanh khoản hoặc những người khác. Khi Uniswap thay đổi (ví dụ UniswapX, v.v.) chuyển sang thực thi off-chain (và Ethereum làm lớp thanh toán), cơ chế này dường như ngày càng khả thi.
Nếu chúng ta giả sử một Rollup có phần cơ chế PBS, luồng đơn hàng và quy trình thương mại hóa có thể như sau:
Từ đó, thương mại hóa của bộ sắp xếp Rollup, người đề xuất có thể tuân theo công thức sau:
Phát hành (PoS) + Thu nhập phí (+priority) - Chi phí DA, công bố trạng thái, lưu trữ
Một cách tốt để xem hiện tại đã trích xuất bao nhiêu giá trị trên Ethereum (đặc biệt là arbitrage) có thể được tìm thấy trên Mevboost.pics, nơi cung cấp cái nhìn tổng quan tốt về lượng giá trị thực tế có thể trích xuất từ sự kém hiệu quả.
Hơn nữa, việc tách rời cuộc chiến phí ưu tiên Gas khỏi cấu trúc off-chain có thể cô lập việc trích xuất MEV vào môi trường thực thi, từ đó giúp ngăn chặn gián đoạn chuỗi cung ứng. Tuy nhiên, cần lưu ý rằng nếu việc bầu chọn người lãnh đạo diễn ra trên Rollup, phần lớn MEV sẽ được trích xuất trên Rollup, để lại rất ít không gian cho cấu trúc nền tảng, trừ khi lớp DA bao gồm, phí ưu tiên từ lớp thanh toán đến từ tích hợp thanh khoản hoặc các lợi thế kinh tế nhờ quy mô khác.
Cần làm rõ rằng nhiều cấu trúc trên có thể hoạt động như cấu trúc hoàn toàn off-chain, không cần bất kỳ cầu nối xác minh hay đảm bảo an ninh mạnh mẽ nào. Tuy nhiên, phải thực hiện một số thỏa hiệp ở đó. Chúng tôi bắt đầu thấy ngày càng nhiều thứ như vậy xuất hiện, dù là hiện tại hay tiềm ẩn. Tôi muốn nhấn mạnh một điểm là thiết lập mô-đun không nhất thiết có nghĩa là Rollup.
Các quy tắc sắp xếp nêu trên đại diện cho một ví dụ, trong đó tinh chỉnh cơ sở hạ tầng có thể cải thiện đáng kể các ứng dụng được xây dựng trên đó.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
