Bài viết mới từ Paradigm: Thuế MEV và thứ tự ưu tiên
Tuyển chọn TechFlowTuyển chọn TechFlow
Bài viết mới từ Paradigm: Thuế MEV và thứ tự ưu tiên
Cơ chế thuế MEV, cho phép bất kỳ ứng dụng nào cũng có thể thu thập MEV của riêng mình và duy trì khả năng tổ hợp.
Chuyên sâu báo cáo Web3Tác giả: Dan Robinson, Dave White
Biên dịch: Joyce, BlockBeats
Giới thiệu
Trong bài viết này, chúng tôi sẽ giới thiệu MEV Tax — một cơ chế mà bất kỳ ứng dụng nào cũng có thể dùng để thu thập MEV của chính mình. Cơ chế này hiện đã có thể sử dụng trên các L2 thuộc OP Stack như OP Mainnet, Base và Blast, vì những chuỗi này có các nhà đề xuất khối tuân theo một tập quy tắc mà chúng tôi gọi là "sắp xếp ưu tiên cạnh tranh".
Để đánh thuế MEV trên một trong những chuỗi đó, hợp đồng thông minh sẽ thu một khoản phí, được tính dựa trên phí ưu tiên (priority fee) trong giao dịch. Nếu một ứng dụng thu 99 đô la MEV tax cho mỗi 1 đô la phí ưu tiên mà searcher trả, thì nó có thể chiếm tới 99% MEV cạnh tranh từ giao dịch đó.
MEV tax là một kỹ thuật đơn giản nhưng mở ra một không gian thiết kế rộng lớn. Bạn có thể xem chúng như cách cho phép bất kỳ ứng dụng nào trên chuỗi tổ chức phiên đấu giá MEV riêng của mình, mà không cần cơ sở hạ tầng riêng ngoài chuỗi — chỉ cần kết nối với một phiên đấu giá chung duy nhất do các nhà đề xuất khối vận hành.
Chúng tôi trình bày cách sử dụng MEV tax để giải quyết ba vấn đề lớn trong nghiên cứu MEV:
Các bộ định tuyến DEX (sàn giao dịch phi tập trung) giúp tối ưu hóa giá cả mà người trao đổi nhận được;
Các AMM (thị trường tự động) giảm thiểu tổn thất so với tái cân bằng (LVR) mà các nhà cung cấp thanh khoản phải chịu;
Các ví cho phép người dùng thu lại MEV dạng "backrun" (chạy sau) được tạo ra bởi giao dịch của họ;
Nhưng có một vấn đề. MEV tax chỉ hiệu quả khi các nhà đề xuất khối nghiêm túc tuân thủ các quy tắc sắp xếp ưu tiên cạnh tranh, bao gồm việc sắp xếp giao dịch theo mức phí ưu tiên, không kiểm duyệt, không xem trước hay trì hoãn bất kỳ giao dịch nào. Nếu nhà đề xuất khối đi lệch khỏi các quy tắc này, họ có thể né tránh MEV tax và tự chiếm lấy giá trị. Do đó, hiện nay MEV tax phụ thuộc vào các trình sắp thứ tự (sequencer) L2 đáng tin cậy, và có thể hoàn toàn không hoạt động trên Ethereum L1 — nơi việc xây dựng khối bị chi phối bởi đấu giá các nhà xây dựng cạnh tranh nhằm tối đa hóa lợi nhuận cho người đề xuất.
Dù vậy, sức mạnh và tính linh hoạt của MEV tax cho thấy rằng đối với các nền tảng hiện tại có thể cung cấp dịch vụ này, sắp xếp ưu tiên có thể là lựa chọn đúng đắn. Sự đơn giản tương đối của sắp xếp ưu tiên cho thấy có thể tồn tại một phương pháp khả thi để thực thi nó một cách phân quyền, thay vì phải tin tưởng vào một trình sắp thứ tự duy nhất. Chúng tôi hy vọng bài viết này sẽ khơi gợi thêm nghiên cứu về vấn đề này.
Sắp xếp ưu tiên
Khi ai đó gửi giao dịch trên Ethereum L1 hoặc L2, họ sẽ chỉ định một mức phí ưu tiên và trả nó cho nhà đề xuất khối. Bạn có thể hình dung đây là priorityFeePerGas — một con số nhân với lượng gas dùng trong giao dịch để tạo thành builderPriorityFee, tức tổng khoản thanh toán bằng ETH.
Giao thức Ethereum không quy định bắt buộc các giao dịch trong khối phải được sắp xếp theo thứ tự giảm dần của priorityFeePerGas. Tuy nhiên, đây là một cách phổ biến để xây dựng khối — ví dụ, đây là thuật toán mặc định mà các sequencer của chuỗi OP Stack cũng như geth và reth sử dụng. Sắp xếp ưu tiên không chỉ giúp người giao dịch thể hiện rõ mức độ khẩn cấp của giao dịch, mà còn một cách tự nhiên chuyển một số loại MEV sang nhà đề xuất khối.
Điều này xảy ra vì sắp xếp ưu tiên biến cuộc đua MEV thành một phiên đấu giá gas ưu tiên. Khi có cơ hội kiếm lợi nhuận từ tương tác với chuỗi — ví dụ như chênh lệch giá giữa AMM và sàn tập trung — các searcher sẽ chạy đua giành vị trí đầu tiên. Nếu chuỗi sử dụng sắp xếp ưu tiên để xác định việc bao gồm và thứ tự giao dịch, các searcher sẽ cạnh tranh bằng cách đặt mức phí ưu tiên cao cho giao dịch của họ.
Trong một kịch bản cạnh tranh hoàn hảo với lợi nhuận rủi ro bằng không, searcher chiến thắng cuối cùng sẽ trả toàn bộ MEV dưới dạng phí ưu tiên. Vì vậy, nếu có thể kiếm được lợi nhuận 100 ETH từ việc tương tác với hợp đồng, giao dịch đầu tiên chiếm lợi nhuận đó sẽ đặt phí ưu tiên ở mức 100 ETH. (Chúng tôi sẽ thảo luận thêm về một vài lưu ý trong phần Hạn chế).
MEV Tax
Giả sử một hợp đồng thông minh muốn thu thập MEV từ mọi giao dịch tương tác với nó. Đã có rất nhiều nghiên cứu về các cách cụ thể khác nhau mà hợp đồng thông minh có thể thử thu MEV cho riêng mình.
Nhưng thật ra, chúng ta không cần biết gì cụ thể về ứng dụng đó. Nếu chúng ta biết khối được xây dựng bằng sắp xếp ưu tiên cạnh tranh, thì chúng ta có một tín hiệu phổ quát về lượng MEV trong giao dịch: phí ưu tiên.
Chúng tôi đề xuất rằng hợp đồng thông minh có thể xem xét mức phí ưu tiên của giao dịch và thu một khoản phí bổ sung là một hàm tăng dần nào đó của phí này. Ví dụ, hợp đồng có thể yêu cầu người gọi chuyển một khoản applicationPriorityFee = 99 * proposerPriorityFee bằng ETH vào hợp đồng.
Khoản phí mới này do searcher trả khi gửi giao dịch, do đó ảnh hưởng đến hành vi của searcher đó. Nếu cơ hội mang lại 100 MEV, giao dịch chiến thắng giờ sẽ chỉ đặt mức phí ưu tiên là 1 ETH, vì điều này dẫn đến tổng chi phí 100 ETH (1 ETH trả cho nhà đề xuất khối, 99 ETH trả cho hợp đồng thông minh). Bất kỳ mức phí ưu tiên cao hơn nào cũng khiến giao dịch trở nên vô lợi; bất kỳ mức thấp hơn nào cũng khiến mất cơ hội cho đối thủ đặt phí cao hơn. Điều này có nghĩa là hợp đồng thông minh đã chiếm được 99% MEV từ giao dịch.
Chúng tôi gọi khoản phí bổ sung mà hợp đồng thông minh thu được là MEV tax. MEV tax cho phép ứng dụng “chiếm đoạt” sắp xếp ưu tiên vì lợi ích riêng, từ đó giúp ứng dụng thu lại MEV vì lợi ích người dùng, thay vì để rò rỉ cho nhà đề xuất khối.
Nếu khoản phí này tăng đủ nhanh theo priorityFeePerGas, nhà đề xuất sẽ chỉ nhận được một lượng MEV không đáng kể. Vì priorityFeePerGas được tính bằng wei (một phần tỷ của 1 ETH), chúng ta cần xử lý độ chính xác rất cao. Ví dụ, chỉ cần MEV tax đủ nhạy cảm, mức priorityFeePerGas là 50.000 sẽ dẫn đến thuế quá cao, khiến tổng tiền trả cho nhà đề xuất thấp hơn 0,01 đô la. (5)
Tuy nhiên, có một cảnh báo quan trọng. Như đã thảo luận trong phần "Hạn chế", MEV tax chỉ hoạt động khi các nhà đề xuất khối tuân thủ một số quy tắc nhất định (chúng tôi gọi là "sắp xếp ưu tiên cạnh tranh"), chứ không đi lệch để tối đa hóa lợi nhuận cá nhân. Việc thực thi các quy tắc này một cách không cần tin tưởng vẫn là một vấn đề chưa được giải quyết.
Thu thập MEV theo từng ứng dụng
Ở đây, chúng tôi mô tả cách MEV tax có thể được dùng trên các chuỗi đảm bảo việc xây dựng khối theo nguyên tắc sắp xếp ưu tiên cạnh tranh để làm giảm ba vấn đề quan trọng trong MEV: giúp các giao diện DEX cải thiện thực thi giao dịch cho người trao đổi, giúp AMM giảm tổn thất do arbitrage cho LP của họ, và giúp ví giảm rò rỉ MEV cho người dùng bằng cách bán quyền backrun của họ.
Bộ định tuyến DEX
Trong các giao thức định tuyến DEX dựa trên ý định như UniswapX và 1inch Fusion, người dùng (Alice) ký một ý định trao đổi, và các searcher cạnh tranh để định tuyến hoặc lấp đầy ý định đó với giá tốt nhất cho Alice.
Phiên bản hiện tại của UniswapX sử dụng hai cơ chế cạnh tranh: đấu giá Dutch, trong đó giá giới hạn của Alice thay đổi theo thời gian cho đến khi được lấp đầy; và đấu giá RFQ (báo giá) ngoài chuỗi ban đầu để đặt giá khởi điểm cho đấu giá Dutch.
Trên các nền tảng đảm bảo sắp xếp ưu tiên cạnh tranh, UniswapX có thể thay thế hai cơ chế này bằng một cơ chế duy nhất: MEV tax. Họ có thể làm điều này bằng cách cho phép người dùng ký các đơn hàng mà bất kỳ ai cũng có thể điền ngay lập tức, nhưng giá thực thi được đặt theo hàm của phí ưu tiên giao dịch.
Ví dụ, nếu Alice có đơn hàng UniswapX để bán 1 ETH, cô ấy có thể định nghĩa giá thực thi đơn hàng là minimumPrice + ($0.01 * priorityFeePerGas). minimumPrice có thể là một giá trị cố định, mà cô ấy dự kiến rõ ràng thấp hơn giá hiện tại.
Các searcher sẽ cạnh tranh bằng cách gửi giao dịch để lấp đầy đơn hàng của Alice. Giao dịch nào có mức phí ưu tiên cao nhất và không revert sẽ hoàn tất đơn hàng, điều này nên đảm bảo người trao đổi nhận được giá tốt nhất mà searcher có thể tìm thấy. (Phần "Hạn chế" thảo luận một vài ngoại lệ.)
Nếu giá tối thiểu của Alice là 3.000 đô la và giá ETH hiện tại là 3.500 đô la, thì priorityFeePerGas trong giao dịch chiến thắng sẽ khoảng 50.000. (Lưu ý rằng trong một giao dịch tốn 200.000 gas, điều này chỉ dẫn đến khoản thanh toán khoảng 10 tỉ wei (~0,000035 đô la) cho nhà đề xuất khối.)
So với các cơ chế hiện tại trong UniswapX, điều này có một số lợi thế tiềm năng.
So với đơn hàng dùng đấu giá Dutch, đơn hàng dùng MEV tax có thể được thực hiện nhanh hơn và với giá tốt hơn. Như bài viết đã thảo luận, đấu giá Dutch trên chuỗi rò rỉ một phần giá trị do biến động giá giữa các khối, và có thể mất nhiều khối mới hoàn tất. Trong khi đó, đơn hàng dùng MEV tax thường có thể hoàn tất trong khối tiếp theo và thu lại phần lớn MEV.
Khác với RFQ ngoài chuỗi, đấu giá cho đơn hàng dùng MEV tax sẽ diễn ra tự động khi thực hiện giao dịch trên chuỗi. Điều này đảm bảo rằng người trúng thầu chỉ cam kết điền đơn nếu giao dịch trên chuỗi thành công. Điều này giúp thanh khoản trên chuỗi như AMM dễ cạnh tranh hơn với thanh khoản ngoài chuỗi, nghĩa là UniswapX có thể hoạt động hiệu quả hơn như một bộ định tuyến cho các hệ thống đa bể như Uniswap v4.
AMM
Thông thường, AMM sẽ rò rỉ giá trị cho các arbitrager, những người giao dịch dựa trên giá lỗi thời ở đỉnh khối, như được thảo luận trong bài Loss Versus Rebalancing. Chúng tôi có thể dùng MEV tax để giúp AMM thu lại MEV. Để đơn giản, chúng tôi sẽ nói về cách MEV tax hoạt động trên AMM mà không có thanh khoản tập trung. (Nếu bạn quan tâm đến cách giải quyết với thanh khoản tập trung, Sorella sẽ sớm công bố một giải pháp.)
AMM có thể thu MEV bằng cách tính thêm một khoản phí là hàm của phí ưu tiên giao dịch, từ đó cho phép họ đấu giá quyền giao dịch đầu tiên trong khối. Có nhiều cách để tính và định giá khoản phí này. Chúng tôi sẽ thảo luận một cách có thể coi là trung lập — theo đơn vị thanh khoản của bể, sqrt(xy). Giao dịch chiến thắng sẽ là giao dịch gia tăng thanh khoản bể nhiều nhất.
Thay vì bắt buộc điều kiện x_end * y_end > x_start * y_start khi thực hiện giao dịch đầu tiên trên bể trong khối, bể có thể áp dụng điều kiện (với a là hằng số):
x_end * y_end > (sqrt(x_start * y_start) + a*priorityFeePerGas)^2
Công thức này sẽ khuyến khích các trader arbitrage giao dịch ở giá thật, và sau giao dịch đó, giá giữa trong bể nên là giá thật.
Sau giao dịch đầu tiên, các giao dịch có thể diễn ra như trên Uniswap v2 với phí hoán đổi cố định. Các giao dịch vô tri muốn giao dịch trong bể mà không trả thêm MEV tax sẽ đặt mức phí ưu tiên thấp.
Có nhiều cách khác để áp dụng MEV tax lên AMM, tạo ra các hiệu ứng khác nhau. Ví dụ, MEV tax có thể được tính bằng token vào hoặc ra của hoán đổi, có thể ảnh hưởng đến phần trăm phí hoán đổi mà bể áp dụng, hoặc có thể xác định giá tối thiểu cho giao dịch người dùng. Chúng tôi cho rằng đây là một không gian thiết kế thú vị đáng được khám phá.
Đấu giá ngược (Backrun Auction)
Mô tả ở trên cho thấy cách thiết kế một số ứng dụng để tránh rò rỉ MEV. Nhưng nếu một ví muốn giúp người dùng thu MEV từ giao dịch bất kỳ của họ khi tương tác với mọi ứng dụng — kể cả những ứng dụng không có MEV tax — thì sao?
Ví dụ, khi Alice thực hiện giao dịch lớn trên AMM, cô ấy đôi khi tạo ra cơ hội arbitrage cho các "backrunner" kéo giá về. Điều này thường rò rỉ vào MEV, thay vì chảy về Alice.
MEV-Share và MEVBlocker là hai giao thức cho phép người dùng thu MEV từ giao dịch, nhưng chúng phụ thuộc vào hệ thống đấu giá phức tạp ngoài chuỗi. Không gian thiết kế đấu giá dòng lệnh (order flow auction) mô tả một số giải pháp khác.
MEV tax kết hợp với ví thông minh dựa trên ý định có thể giúp chúng ta xây dựng một hệ thống thay thế để thu MEV backrun cho Alice. Giả sử Alice không tạo giao dịch để giao dịch trên AMM, mà thay vào đó ký một ý định mà bất kỳ ai cũng có thể gửi đến ví thông minh của Alice để thực hiện hành động đó. Ví thông minh của Alice sẽ thu MEV tax từ người gửi giao dịch, và khoản thuế này được trả cho Alice.
Searcher gửi ý định của Alice sẽ có quyền độc quyền backrun cô ấy, vì họ có thể tự động thực hiện điều này trong cùng một giao dịch. Do đó, nếu cuộc cạnh tranh đủ sôi nổi, toàn bộ lợi nhuận của Alice nên chảy về cô ấy qua MEV tax.
Lưu ý rằng hệ thống này không nhất thiết bảo vệ người dùng khỏi các cuộc tấn công front-run, vì giao dịch front-run có thể tránh trả MEV tax cho người dùng. Vấn đề này (và một số biện pháp giảm nhẹ) sẽ được thảo luận chi tiết hơn trong phần Hạn chế bên dưới. Dù vậy, đây ít nhất cũng là một cải tiến so với hệ thống dùng mempool công cộng mà không có biện pháp giảm nhẹ nào.
Các trường hợp sử dụng khác
Ngoài những ví dụ này, các ứng dụng tiềm năng khác của MEV tax có thể bao gồm hầu hết mọi thứ hiện đang dùng đấu giá ngoài chuỗi hoặc đấu giá Dutch, ví dụ như:
Các giao thức oracle thu lại OEV (Oracle Extractable Value) mà họ tạo ra, ví dụ như Oval;
Đấu giá tái tài trợ cho các giao thức vay NFT như Blend;
Thanh lý trong các giao thức cho vay, giảm rò rỉ giá trị so với đấu giá Dutch;
Thu thập MEV liên ứng dụng
Các giải pháp trên nhằm thu MEV từ tương tác với một ứng dụng đơn lẻ. Nhưng đôi khi searcher có thể kiếm được nhiều giá trị hơn bằng cách tương tác với nhiều ứng dụng trong cùng một giao dịch.
Nếu chỉ có một trong các ứng dụng đó có MEV tax, thì toàn bộ MEV trong giao dịch nên chảy về ứng dụng đó, bất kể mức thuế cao hay thấp.
Nhưng nếu giao dịch của searcher tương tác với hai ứng dụng đều dùng MEV tax thì sao? Ví dụ, nếu có một chút MEV chỉ có thể thu được bằng cách dùng một đơn hàng UniswapX nộp MEV tax để lấp đầy một AMM cũng nộp MEV tax?
Trong trường hợp này, lượng MEV dư thừa mà mỗi ứng dụng thu được sẽ phụ thuộc vào cách họ đặt MEV tax. Nếu giá trị thu được bởi app_i dưới dạng MEV tax được cho bởi hàm tax_i(priority), thì mức ưu tiên của giao dịch chiến thắng có thể được xác định bằng cách giải phương trình:
tax_1(priorityPerGas) + tax_2(priorityPerGas) = total MEV
(Về mặt kỹ thuật, chúng ta có thể thêm hạng mục thứ ba là priorityPerGas * gasUsed để tính phí ưu tiên trả cho nhà đề xuất khối, nhưng chúng ta sẽ bỏ qua điều này vì trong điều kiện bình thường nó có thể bỏ qua được)
Trong trường hợp đơn giản khi MEV tax tỷ lệ tuyến tính với priorityPerGas (do đó tax_1(priorityPerGas) = a_1 * priorityPerGas), bạn có thể giải ra phần MEV mà mỗi ứng dụng nhận được:
a_1 * priorityPerGas + a_2 * priorityPerGas = MEV
priorityPerGas = MEV/(a_1 + a_2)
tax_1(priorityPerGas) = (a_1/(a_1+a_2))*MEV
tax_2(priorityPerGas) = (a_2/(a_1+a_2))*MEV
Khi thiết lập MEV tax, các ứng dụng phải đối mặt với sự đánh đổi — thuế cao hơn giúp họ chiếm phần lớn hơn khi có MEV liên ứng dụng, nhưng điều đó cũng có nghĩa là họ có thể bỏ lỡ một số MEV liên ứng dụng nếu có cách khai thác cạnh tranh. Ví dụ, nếu có một AMM thu MEV tax cho mỗi giao dịch, thì đơn hàng UniswapX dùng MEV tax có thể dễ bị lấp bởi AMM khác hoặc người điền ngoài chuỗi.
Trong nhiều trường hợp, có thể tồn tại trạng thái cân bằng mà hai ứng dụng thiết kế MEV tax để chia sẻ MEV theo cách tối đa hóa lợi nhuận riêng. Ví dụ, AMM dùng MEV tax có thể muốn thu giá trị từ các trader có thông tin đơn lẻ gần đỉnh khối, nhưng sau đó muốn cung cấp thanh khoản với mức phí cố định thấp cho các trader và ứng dụng khác (kể cả ứng dụng dùng MEV tax). Trong trường hợp đó, AMM có thể đặt mức thuế MEV tương đối thấp (ví dụ $0.00001 * priorityFeePerGas) để đảm bảo giao dịch arbitrage (nếu có) xảy ra sớm trong khối, sau đó không thu MEV tax cho các giao dịch tiếp theo. Một ứng dụng như UniswapX muốn tương tác với AMM có thể đặt mức thuế MEV cao hơn (ví dụ $0.01 * priorityFeePerGas) để đảm bảo giao dịch của họ được đưa vào sau khi bể đã được arbitrage. Với các mức thuế tương đối này, ngay cả khi chỉ có 1 đô la MEV trong đơn hàng UniswapX và 50.000 đô la MEV trong AMM, AMM vẫn sẽ được arbitrage trước.
Chúng tôi cho rằng đây là một không gian thiết kế rộng lớn đáng được nghiên cứu trong tương lai.
Hạn chế
MEV tax có một số phức tạp và điểm yếu, mà chúng tôi cho rằng đều là lĩnh vực nghiên cứu thú vị trong tương lai.
Không tương thích động lực
MEV tax không tương thích động lực với nhà đề xuất khối độc quyền. Chúng chỉ hoạt động khi có sự cạnh tranh công bằng trong việc bao gồm giao dịch, và điều này chỉ xảy ra khi nhà đề xuất khối tuân thủ các quy tắc mà chúng tôi gọi là "sắp xếp ưu tiên cạnh tranh", thay vì tối đa hóa lợi nhuận cá nhân. Một cách liệt kê không chính thức các quy tắc đề xuất, bao gồm nhưng không giới hạn:
Ưu tiên. Các giao dịch trong khối phải được sắp xếp theo thứ tự giảm dần của priorityFeePerGas.
Chống kiểm duyệt. Nếu nhà đề xuất khối nhận được giao dịch t1 trong khoảng thời gian khối, và khối chưa đầy hoặc chứa giao dịch t2 với t2.priorityFeePerGas < t1.priorityFeePerGas, thì khối phải chứa t1.
Riêng tư trước giao dịch. Nhà đề xuất khối phải chấp nhận giao dịch qua đầu cuối riêng tư, và không được chia sẻ giao dịch này với ai khác trước khi đưa vào khối, hay dùng nội dung giao dịch để xây giao dịch riêng.
Không xem xét cuối cùng. Nhà đề xuất khối phải đặt một thời điểm rõ ràng để chấp nhận giao dịch từ mọi người; sau thời điểm đó, họ không được chấp nhận thêm giao dịch nào.
Nếu vi phạm một hoặc nhiều thuộc tính trên, hiệu quả của MEV tax có thể bị suy yếu. Nhà đề xuất khối vi phạm chống kiểm duyệt có thể tránh hầu hết MEV tax bằng cách loại bỏ giao dịch cạnh tranh và gửi giao dịch ưu tiên bằng 0 cho chính mình. Nhà đề xuất khối vi phạm riêng tư trước giao dịch có thể ăn cắp MEV từ giao dịch khác hoặc xem phí ưu tiên để biết chính xác họ cần đặt phí bao nhiêu, còn nhà đề xuất có thể gửi giao dịch muộn hơn sẽ có "cơ hội nhìn cuối cùng" miễn phí để giành cơ hội với giá cao hơn — cả hai tình huống đều có thể gây ra vấn đề lựa chọn nghịch đảo, cuối cùng làm suy yếu cạnh tranh.
Thật không may, trong khi thuộc tính đầu tiên dễ thực thi ở tầng giao thức, thì việc thực thi các thuộc tính khác một cách không cần tin tưởng vẫn là một vấn đề chưa giải quyết.
Do thiếu thực thi ở tầng giao thức, cần phải tin tưởng vào một trình sắp thứ tự duy nhất cam kết tuân thủ các quy tắc này sẽ không đi lệch, và nếu người đề xuất thuê ngoài việc xây dựng khối cho đấu giá thu nhập tối đa cạnh tranh (ví dụ MEV-Boost trên Ethereum L1), khối có thể sẽ không tuân theo chúng.
Các vấn đề này có thể được "giải quyết" bằng một trình sắp thứ tự đáng tin cậy đơn lẻ cam kết dùng sắp xếp ưu tiên cạnh tranh để xây dựng khối. Chúng cũng có thể được giải quyết bằng cơ chế phân quyền sử dụng sự kết hợp của đồng thuận, mật mã học và/hoặc môi trường thực thi đáng tin cậy (TEE), ví dụ như Angstrom của Sorella, SUAVE của Flashbots, đấu giá không lãnh đạo (leaderless auctions) hay Multiplicity.
Khối đầy
Một ngoại lệ khi MEV tax hoạt động bình thường xảy ra khi khối hoàn toàn đầy. Trong trường hợp này, nhà đề xuất khối có thể phải từ chối các giao dịch có mức ưu tiên thấp thay vì đơn giản là đưa chúng vào. Vì giao dịch tương tác với ứng dụng dùng MEV tax có thể có mức phí ưu tiên cực thấp, các ứng dụng này có thể bị đẩy ra ngoài bởi các ứng dụng không dùng MEV tax hoặc dùng mức thuế rất thấp. Tuy nhiên, trên các chuỗi dùng cơ chế tương tự EIP-1559 để đặt phí cơ bản riêng biệt, tình trạng khối đầy nên khá hiếm. Ngoài ra, khi khối đầy, việc trì hoãn một số giao dịch là điều cần thiết, và việc trì hoãn giao dịch biểu thị mức độ khẩn cấp thấp hơn bằng cách đặt mức MEV tax cao hơn có thể là một kết quả hợp lý.
Giao dịch revert
MEV tax thực tế dựa vào đấu giá một khối, trong đó mỗi "mức giá thầu" là một giao dịch. Một điểm yếu của các đấu giá này là các mức thầu thất bại thường dẫn đến giao dịch revert bị đưa vào chuỗi, trả một phần phí cơ bản và gây tắc nghẽn mạng.
Nếu trình sắp thứ tự có thể hoàn toàn loại bỏ các giao dịch thất bại, vấn đề này sẽ được giảm nhẹ, mặc dù ngay cả với trình sắp thứ tự tập trung cũng khó thực hiện. (Nó cũng không tuân thủ nghiêm ngặt thuộc tính chống kiểm duyệt nêu trên, dù có thể điều chỉnh định nghĩa.) Các trình sắp thứ tự phức tạp hơn có thể tối ưu quá trình này bằng cách cho phép giao dịch chỉ định họ đang tham gia đấu giá nào, từ đó cung cấp đủ thông tin để bỏ qua các giao dịch chắc chắn thất bại.
Tiết lộ ý định người dùng
MEV tax chỉ hiệu quả khi có sự cạnh tranh giữa các searcher, nghĩa là cơ hội cần được biết đến ở mức độ nào đó. Với các ứng dụng như AMM, cơ hội hiển thị trên chuỗi nên tự nhiên xảy ra. Nhưng với các ứng dụng như định tuyến dựa trên ý định hoặc đấu giá backrun, điều này có nghĩa là ứng dụng có thể cần chia sẻ ý định người dùng với các searcher.
Trong một số trường hợp, việc lan truyền ý định người dùng trước khi thực hiện có thể gây rò rỉ giá trị theo cách mà MEV tax không thể thu hồi.
Ví dụ, giả sử Alice muốn dùng giao thức đấu giá backrun nói trên để mua một token thanh khoản thấp. Cô ấy đăng ký một ý định đã ký với ví thông minh để mua token đó trên AMM, với một mức dung sai trượt giá nhất định. Các searcher có thể竞相 đẩy giá token đó lên mức dung sai trượt giá của cô ấy trong một giao dịch ưu tiên cao, mà không điền đơn hàng của người dùng. Sau đó, người chiến thắng Bob có thể đáp ứng ý định của Alice một cách không cạnh tranh bằng cách đưa vào và backrun nó trong giao dịch ưu tiên thấp, kẹp giao dịch của Alice và đưa cho cô ấy giá tệ hơn, đồng thời né tránh MEV tax của cô ấy. Vấn đề tương tự cũng có thể xảy ra khi mua NFT.
Lưu ý rằng cuộc tấn công này có rủi ro với Bob, vì anh ta không thể đảm bảo tính nguyên tử giữa việc mua token và bán cho Alice. Một Bob ngây thơ có thể rơi vào bẫy "kẹp ngược": Alice trước tiên đăng ý định mua một token vô giá trị từ chính mình, Bob mua token đó để kẹp, nhưng trước khi Bob hoàn tất, Alice rút lại ý định.
Các ứng dụng cũng có thể giảm nhẹ tình trạng này bằng cách giới hạn tập hợp searcher được chia sẻ ý định và giám sát hành vi của họ, giống như nhiều đấu giá dòng lệnh hiện tại.
Cũng có thể kết hợp MEV tax với các chức năng builder có ý thức về riêng tư, như Flashbots hình dung cho SUAVE.
Cuối cùng, nếu Alice cho rằng chi phí chia sẻ ý định vượt quá lợi ích từ cạnh tranh, cô ấy có thể tự xây giao dịch và gửi trực tiếp vào khối. Như đã nêu, việc thực hiện lý tưởng của sắp xếp ưu tiên cạnh tranh sẽ cung cấp riêng tư trước giao dịch cho nhà đề xuất khối.
Thảo luận liên quan
Đấu giá gas ưu tiên. Bài báo Flash Boys 2.0 nghiên cứu một số động lực của sắp xếp ưu tiên trong blockchain phi tập trung, đồng thời tạo ra thuật ngữ "Miner Extractable Value". Bài báo chỉ ra rằng các thợ đào Ethereum (khi mạng dùng Proof-of-Work) đã sắp xếp giao dịch theo mức ưu tiên, và các trader arbitrage dựa vào hành vi này để tham gia "đấu giá gas ưu tiên", nơi họ đấu giá quyền được đưa vào khối đầu tiên, dẫn đến phần lớn MEV từ arbitrage DEX chảy về thợ đào.
Ai tới trước phục vụ trước. Một số nỗ lực giảm MEV thông qua quy tắc sắp xếp giao dịch, ví dụ như Themis hay trình sắp thứ tự hiện tại của Arbitrum One (7), tập trung vào việc thực thi quy tắc sắp xếp khác: phục vụ theo thứ tự đến (đôi khi gọi là "sắp xếp công bằng"), trong đó nhà đề xuất khối phải sắp xếp giao dịch theo thứ tự họ nhận được.
Sắp xếp ưu tiên chọn cách tiếp cận khác — đối xử công bằng với các giao dịch đến trong cùng một khoảng thời gian, và sắp xếp chúng theo mức ưu tiên tuyên bố.
Việc thực thi hoặc thậm chí định nghĩa "ai tới trước" rất khó trong môi trường mạng thực tế với nhiều validator. Ngay cả với một trình sắp thứ tự đáng tin cậy đơn lẻ, nó cũng có thể dẫn đến cạnh tranh trì hoãn lãng phí và spam. Cuối cùng, MEV tax có thể loại bỏ một số loại MEV mà sắp xếp "tới trước phục vụ trước" không thể, ví dụ như lợi nhuận arbitrage từ "bước nhảy" gián đoạn giá tài sản. Những lợi thế tiềm năng của sắp xếp ưu tiên so với sắp xếp tới trước phục vụ trước phần nào liên quan đến lợi thế của giao dịch rời rạc so với liên tục như được thảo luận trong Budish, Cramton, Shim (2015).
Đồng thời, mặc dù sắp xếp ưu tiên dường như rò rỉ MEV theo mặc định, bài viết này cho thấy cách thiết kế ứng dụng để thu lại giá trị đó.
Chia sẻ phí. Blast là một L2 Ethereum, chia sẻ một phần phí ưu tiên và phí cơ bản với các hợp đồng thông minh được truy cập trong giao dịch.
MEV tax cho
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
Paradigm
