Giới thiệu

Trong bài đăng này, chúng tôi giới thiệu thuế MEV, một cơ chế mà các ứng dụng tùy ý có thể sử dụng để thu nạp MEV của riêng họ.

Cơ chế này có thể được sử dụng ngay hôm nay trên các OP Stack L2s như OP Mainnet, Base, và Blast, vì các người đề xuất khối trên những chuỗi đó tuân theo một bộ quy tắc chúng tôi gọi là thứ tự ưu tiên cạnh tranh.

Để thực hiện một thuế MEV trên một trong những chuỗi này, một hợp đồng thông minh tính phí một cách phụ thuộc vào phí ưu tiên của giao dịch. Chúng tôi chỉ ra rằng nếu một ứng dụng tính thuế MEV cho người tìm kiếm (ví dụ) $99 cho mỗi $1 phí ưu tiên, nó có thể thu về 99% MEV cạnh tranh cho giao dịch đó.

Thuế MEV là một kỹ thuật đơn giản mở ra một không gian thiết kế rộng lớn. Bạn có thể nghĩ về chúng như cho phép bất kỳ ứng dụng nào trên chuỗi chạy bán đấu giá MEV tùy chỉnh của riêng mình, mà không cần bất kỳ cơ sở hạ tầng nào ngoại chuỗi riêng của mình, chỉ cần kết nối vào một phiên đấu giá chung duy nhất do người đề xuất khối chạy.

Chúng tôi chỉ ra cách thuế MEV có thể được sử dụng để giải quyết ba vấn đề lớn trong nghiên cứu MEV:

• Bộ định tuyến sàn giao dịch phi tập trung (DEX) tối ưu hóa giá nhận được bởi người hoán đổi
• Các nhà tạo lập thị trường tự động (AMMs) giảm thiểu tổn thất so với việc cân đối lại (LVR) mà các nhà cung cấp thanh khoản trải qua
• Ví cho phép người dùng của họ bắt kịp bất kỳ MEV “backrunning” nào được tạo ra bởi giao dịch của họ

Nhưng có một vấn đề. Thuế MEV chỉ hoạt động nếu những người đề xuất khối tuân thủ nghiêm ngặt các quy tắc về thứ tự ưu tiên cạnh tranh, bao gồm sắp xếp giao dịch theo phí ưu tiên mà không kiểm duyệt, nhìn trộm hoặc trì hoãn bất kỳ gì. Nếu những người đề xuất khối lệch khỏi những quy tắc đó, họ có thể trốn thuế MEV để thu giữ giá trị cho bản thân mình. Vì vậy, hôm nay, thuế MEV phụ thuộc vào việc tin tưởng vào các bộ sắp xếp L2, và có lẽ sẽ không hoạt động chút nào trên Ethereum L1, nơi xây dựng khối bị chiếm ưu thế bởi một đấu giá xây dựng cạnh tranhtối đa hóa doanh thu cho người đề xuất.

Tuy nhiên, sức mạnh và linh hoạt của thuế MEV cho thấy rằng việc xác định ưu tiên có thể là lựa chọn đúng đắn cho các nền tảng có thể cung cấp nó ngay hôm nay. Và sự đơn giản tương đối của việc xác định ưu tiên cạnh tranh cho thấy rằng có thể có cách thức hiệu quả để áp dụng nó một cách phi tập trung, mà không cần phải tin tưởng vào một người xếp hàng duy nhất. Chúng tôi hy vọng bài đăng này sẽ thúc đẩy công việc tiếp theo về vấn đề đó.

Ưu tiên đặt hàng

Khi ai đó gửi một giao dịch trên Ethereum L1 hoặc L2, họ chỉ định một phí ưu tiên, mà họ trả cho người đề xuất khối.1Bạn có thể tưởng tượng rằng điều này được chỉ định là priorityFeePerGas, một con số được nhân với lượng gas được sử dụng trong giao dịch để có được builderPriorityFee—tổng thanh toán bằng ETH.2

Không có quy tắc nào trong giao thức Ethereum rằng các giao dịch trong một khối phải được sắp xếp theo tham lam giảm dần theo ưu tiên phí trên mỗi gas. Tuy nhiên, đó là một cách phổ biến để xây dựng các khối - ví dụ, đó là thuật toán mặc định được sử dụng bởi các sequencers củaOP Stackchuỗi, cũng như geth và reth. Không chỉ cho phép sắp xếp ưu tiên để người giao dịch hiệu quả biểu hiện sự cấp thiết của giao dịch của họ, nó cũng tự nhiên định hướng một số loại MEV cho người đề xuất khối.

Điều đó xảy ra vì việc ưu tiên sắp xếp biến cuộc cạnh tranh về MEV thành một đấu giá gas ưu tiênKhi có cơ hội để có lời từ việc tương tác với chuỗi, chẳng hạn như bằng cách thực hiện giao dịch đối chọi với trung tâm giao dịch phi tập trung, người tìm kiếm cạnh tranh để đầu tiên tận dụng cơ hội đó. Nếu chuỗi sử dụng sắp xếp ưu tiên để xác định việc bao gồm và sắp xếp giao dịch, người tìm kiếm cạnh tranh bằng cách đặt các phí ưu tiên cao cho giao dịch của họ.

Trong tình huống cạnh tranh nơi lợi nhuận không rủi ro được cạnh tranh giảm xuống mức không, người tìm kiếm chiến thắng sẽ phải trả toàn bộ số tiền MEV trong các phí ưu tiên.3Vì vậy nếu có 100 ETH lợi nhuận có thể được đạt được từ việc tương tác với một hợp đồng, giao dịch đầu tiên để yêu cầu nó sẽ đặt một phí ưu tiên là 100 ETH. (Chúng tôi sẽ thảo luận một số điều cần chú ý trong phần Giới hạn).

Thuế MEV

Giả sử một hợp đồng thông minh muốn thu thập MEV từ bất kỳ giao dịch nào tương tác với nó. Có một thư viện nghiên cứu rộng lớn về các cách cụ thể cho ứng dụng mà các hợp đồng thông minh có thể thử thu thập MEV của riêng họ.

Nhưng trong thực tế, chúng ta không nhất thiết phải biết bất cứ điều gì về ứng dụng. Nếu chúng ta biết rằng khối đang được xây dựng thông qua sắp xếp ưu tiên cạnh tranh, thì chúng ta có một tín hiệu chung duy nhất cho số 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 phí ưu tiên của giao dịch và tính phí riêng của nó như một hàm tăng của nó. Ví dụ, hợp đồng có thể yêu cầu người gọi nó chuyển applicationPriorityFee = 99 * proposerPriorityFee trong ETH cho hợp đồng.4

Phí mới này được thanh toán bởi người gửi giao dịch tìm kiếm, vì vậy nó ảnh hưởng đến hành vi của người đó. Nếu có 100 MEV trong một cơ hội, giao dịch chiến thắng sẽ chỉ đặt một khoản phí ưu tiên của 1 ETH, vì điều đó sẽ dẫn đến tổng thanh toán là 100 ETH (1 ETH cho người đề xuất khối, và 99 ETH cho hợp đồng thông minh). Bất kỳ khoản phí ưu tiên cao hơn sẽ làm cho giao dịch không có lợi nhuận; bất kỳ khoản phí ưu tiên thấp hơn sẽ dẫn đến mất cơ hội cho một đối thủ đặt một khoản phí cao hơn. Điều này có nghĩa là hợp đồng thông minh đã chiếm 99% MEV trong giao dịch.

Chúng tôi gọi khoản phí bổ sung này do hợp đồng thông minh áp đặt là một loại thuế MEV. Thuế MEV cho phép một ứng dụng chiếm đoạt thứ tự ưu tiên vì lợi ích của chính nó, cho phép nó thu lại MEV cho người dùng của mình thay vì rò rỉ cho người đề xuất khối.

Nếu phí này tăng đủ nhanh theo hàm của priorityFeePerGas, thì chỉ một lượng MEV không đáng kể sẽ được tích luỹ cho người đề xuất. Khi priorityFeePerGas được định giá bằng wei (một tỷ phần tỷ của một ETH), chúng ta có rất nhiều độ chính xác để làm việc. Ví dụ, miễn là thuế MEV đủ nhạy cảm sao cho một priorityFeePerGas là 50.000 sẽ dẫn đến một mức thuế cấm kỵ cao, thì tổng số tiền thanh toán cho người đề xuất sẽ ít hơn $0.01.5

Tuy nhiên, có một lưu ý quan trọng. Như đã thảo luận trong phần Hạn chế, thuế MEV chỉ hoạt động nếu người đề xuất khối tuân theo một số quy tắc nhất định—chúng ta gọi là “thứ tự ưu tiên cạnh tranh”—thay vì lệch khỏi những quy tắc đó để tối đa hóa doanh thu của riêng mình. Việc áp dụng những quy tắc này một cách không tin cậy là một vấn đề mở.

Single-application MEV capture

Ở đây, chúng tôi sẽ phác thảo cách mà, trên một chuỗi mà được đảm bảo sử dụng thứ tự ưu tiên cạnh tranh để xây dựng khối, thuế MEV có thể được sử dụng để giảm ba vấn đề quan trọng trong MEV: để giao diện DEX cải thiện thực hiện giao dịch cho những người thay đổi, để AMMs giảm thiểu thiệt hại do cơ hội sử dụng cho các LPs của họ, và để các ví giảm rò rỉ MEV cho người dùng của họ bằng cách bán quyền để chạy ngược lại người dùng.

Bộ định tuyến DEX

Trong các giao thức định tuyến DEX dựa trên ý định như UniswapXvà1inch Fusion, một người dùng (Alice) ký kết một ý định để trao đổi, và những người tìm kiếm cạnh tranh để định tuyến hoặc điền vào ý định đó với giá tốt nhất cho Alice.

Các phiên bản hiện tại của UniswapX sử dụng hai cơ chế để chạy cuộc thi đấu: một cuộc đấu giá Hà Lan, nơi giá giới hạn của Alice thay đổi theo thời gian cho đến khi một người tìm kiếm điền vào nó, và một cuộc đấu giá yêu cầu báo giá ban đầu (RFQ) ngoại tuyến để đặt giá khởi điểm cho cuộc đấu giá Hà Lan đó.

Trên một nền tảng đảm bảo việc đặt hàng ưu tiên cạnh tranh, UniswapX có thể thay thế chúng bằng một cơ chế duy nhất: một thuế MEV. Nó có thể thực hiện điều này bằng cách yêu cầu người dùng ký một đơn đặt hàng có thể được thực hiện ngay lập tức bởi bất kỳ ai, nhưng với một giá thực hiện được đặt là một hàm của ưu tiên giao dịch.

Ví dụ, nếu Alice có một đơn đặt hàng UniswapX để bán 1 ETH, cô ấy có thể xác định giá thực hiện của đơn đặt hàng là minimumPrice + ($0.01 * priorityFeePerGas). minimumPrice có thể là một giá trị cố định mà cô ấy kỳ vọng sẽ thấp hơn đáng kể so với giá hiện tại.

Những người tìm kiếm sẽ cạnh tranh để điền vào đơn hàng của Alice bằng cách gửi giao dịch. Bất kỳ giao dịch nào có phí ưu tiên cao nhất và không bị hoàn trả sẽ được chọn để điền vào đơn hàng, điều này nên đảm bảo rằng người hoán đổi sẽ nhận được giá tốt nhất mà người tìm kiếm có thể tìm thấy. (Một số ngoại lệ cho điều này được thảo luận trong phần Giới hạn.)

Nếu giá tối thiểu của Alice là $3,000 và giá hiện tại của ETH là $3,500, 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 sẽ dẫn đến việc thanh toán chỉ khoảng 10 tỷ wei - khoảng $0.000035 - cho người đề xuất khối.)

Điều này có một số lợi ích tiềm năng hơn so với cơ chế hiện tại được sử dụng trong UniswapX.

Các đơn đặt hàng sử dụng thuế MEV có thể hoàn thành nhanh hơn và với giá tốt hơn so với các đơn đặt hàng sử dụng đấu giá Hà Lan. Như đã thảo luận trong bài báo này, trong các cuộc đấu giá Hà Lan onchain có sự rò rỉ một số giá trị sang MEV do sự di chuyển giá giữa các khối, và có thể mất nhiều khối để hoàn thành. Ngược lại, các đơn đặt hàng sử dụng thuế MEV có thể được hoàn thành trong khối tiếp theo trong khi chiếm được phần lớn MEV của họ.

Không giống như việc yêu cầu báo giá ngoại xích, cuộc đấu giá để điền vào một lệnh sử dụng thuế MEV sẽ xảy ra nguyên tử với việc thực thi giao dịch trên chuỗi. Điều này có nghĩa là người chào giá chiến thắng có thể được đảm bảo rằng họ chỉ cam kết điền vào lệnh nếu giao dịch trên chuỗi của họ thành công. Điều đó có thể làm cho việc cạnh tranh với thanh khoản trên chuỗi như AMM dễ dàng hơn, có nghĩa là UniswapX có thể phục vụ như một thiết bị định tuyến hiệu quả hơn cho các hệ thống nhiều hồ bơi như Uniswap v4.

AMMs

Thường, AMMs tạo ra lỗ cho các nhà giao dịch cơ hội thời điểm bị lạc hậu ở đỉnh khối, như đã thảo luận trong mất cân bằng so với việc cân bằng lại papersChúng ta có thể sử dụng thuế MEV để AMM bắt kịp MEV đó. Để giữ mọi thứ đơn giản, chúng ta sẽ thảo luận về cách thức hoạt động này trên một AMM không có độ thanh khoản tập trung. (Nếu bạn quan tâm đến cách giải quyết vấn đề này với độ thanh khoản tập trung, Sorellasẽ sớm công bố một giải pháp.)

Một AMM có thể bắt giữ MEV bằng cách tính một khoản phí phụ thuộc vào khoản phí ưu tiên trên giao dịch, cho phép đấu giá quyền giao dịch trước nhất trong khối. Có nhiều cách để tính toán và đặt tên khoản phí đó. Chúng tôi sẽ thảo luận về một cách có thể coi là trung lập—đặt tên nó trong đơn vị thanh khoản của pool, sqrt(xy). Giao dịch chiến thắng sẽ là giao dịch tăng thanh khoản của pool nhiều nhất.

Khi thực hiện giao dịch đầu tiên trên một nhóm trong một khối, thay vì áp đặt điều kiện x_endy_end > x_starty_start, hồ bơi có thể áp dụng điều kiện (với a là một hằng số nào đó):

x_endy_end > (sqrt(x_start y_start) + a*priorityFeePerGas)^2

Công thức này sẽ khuyến khích người giao dịch cơ hội để giao dịch với giá thực sự, và sau giao dịch đó, giá trung bình trên hồ bơi sẽ là giá thực sự.6

Sau giao dịch đầu tiên đó, các giao dịch có thể hoạt động giống như trên Uniswap v2, với phí hoán đổi cố định. Các giao dịch không thông tin muốn giao dịch trên pool mà không phải trả thêm thuế MEV có thể đặt một phí ưu tiên thấp.

Có nhiều cách khác nhau để thực hiện các loại thuế MEV trên một AMM mà sẽ có các hiệu ứng khác nhau. Ví dụ, thuế MEV có thể được định giá bằng token đầu vào hoặc đầu ra của sự trao đổi, có thể ảnh hưởng đến tỷ lệ phí trao đổi áp dụng bởi pool, hoặc có thể xác định giá tối thiểu của giao dịch của người dùng. Chúng tôi nghĩ rằng đây là một không gian thiết kế thú vị để khám phá.

Đấu giá Backrunning

Các mô tả trên cho thấy cách mà một số ứng dụng cụ thể có thể được thiết kế để tránh rò rỉ MEV. Tuy nhiên, nếu một ví muốn cố gắng giúp người dùng của mình thu về MEV mà họ tạo ra từ các giao dịch tùy ý tương tác với bất kỳ ứng dụng nào, ngay cả những ứng dụng không tích hợp thuế MEV, thì sao?

Ví dụ, khi Alice thực hiện một giao dịch lớn trên AMM, đôi khi cô ấy tạo ra một cơ hội chênh lệch giá cho "backrunners" để di chuyển giá trở lại. Điều này thường bị rò rỉ cho MEV, thay vì đến Alice.

MEV-SharevàMEVBlockerlà hai giao thức cho phép người dùng thu thập MEV từ giao dịch của họ, nhưng chúng phụ thuộc vào hệ thống đấu giá phức tạp ngoại chuỗi.Khoảng không gian thiết kế Đấu giá Orderflowmô tả một số giải pháp khác.

Thuế MEV, khi kết hợp với một ví hợp đồng thông minh dựa trên ý định, có thể cho phép chúng tôi xây dựng một hệ thống thay thế để thu lại MEV backrunning cho Alice. Giả sử thay vì tạo một giao dịch trên AMM, Alice ký một ý định mà bất kỳ ai cũng có thể gửi đến ví hợp đồng thông minh của Alice để khiến nó thực hiện hành động đó. Ví hợp đồng thông minh của Alice thu thuế MEV từ người nào gửi giao dịch đó, số tiền này được trả cho Alice.

Người tìm kiếm nào nộp ý định của Alice sẽ có quyền độc quyền để thực hiện backrun cho cô ấy, vì họ có thể làm điều này một cách nguyên tử trong cùng giao dịch. Kết quả là, nếu việc tìm kiếm là cạnh tranh, toàn bộ lợi nhuận từ việc backrunning Alice sẽ được tích lũy cho Alice thông qua thuế MEV của cô ấy.

Lưu ý rằng hệ thống này có thể không nhất thiết bảo vệ người dùng khỏi các cuộc tấn công liên quan đến việc đặt trước giao dịch người dùng, vì giao dịch đặt trước một người dùng có thể tránh phải trả thuế MEV cho người dùng đó. Vấn đề này (và một số biện pháp hạn chế có thể) được thảo luận chi tiết hơn trong phần Hạn chế ở dưới. Tuy nhiên, điều này có thể ít nhất là một cải tiến so với các hệ thống sử dụng các mempool công cộng mà không có biện pháp hạn chế nào.

Các trường hợp sử dụng khác

Ngoài những ví dụ này, các cách sử dụng tiềm năng khác của các loại thuế MEV có thể bao gồm gần như bất cứ điều gì hiện đang sử dụng một hình thức ngoại tuyến hoặc đấu giá Hà Lan, chẳng hạn như:

• Các giao thức cho các trung gian để bắt giữ giá trị có thể trích xuất từ trung gian mà họ tạo ra, như Oval
• Các phiên đấu giá tái tài chính trong các giao protocal cho vay thế chấp NFT như Blend
• Thanh lý giao thức cho vay mà giá trị rò rỉ ít hơnhơn phiên đấu giá Hà Lan

Chụp MEV chéo ứng dụng

Các giải pháp trên được thiết kế để bắt MEV từ việc tương tác với một ứng dụng duy nhất. Nhưng đôi khi có thể có khả năng cho một người tìm kiếm bắt đượ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ỉ một trong những ứng dụng đó có một khoản thuế MEV, thì tất cả MEV từ giao dịch đó sẽ được chuyển đến ứng dụng có thuế MEV, bất kể thuế MEV đó cao hay thấp như thế nào.

Nhưng nếu giao dịch của một người tìm kiếm tương tác với hai ứng dụng sử dụng thuế MEV? Ví dụ, nếu có một số MEV chỉ có thể được thu được bằng cách thực hiện một trong các đơn đặt hàng UniswapX bị đánh thuế MEV như mô tả ở trên đối với một AMM bị đánh thuế MEV?

Trong trường hợp đó, lượng MEV dư thừa tương đối được mỗi ứng dụng thu được được xác định bằng cách các ứng dụng đó đặt các thuế MEV của mình như thế nào. Nếu giá trị app_i thu phí MEV được xác định bởi hàm thuế_i(ưu tiên), thì ư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 này để tìm ưu tiên.

tax_1(priorityPerGas) + tax_2(priorityPerGas) = tổng MEV

(Kỹ thuật, chúng tôi có thể thêm một thuật ngữ thứ ba cho priorityPerGas * gasUsed để tính đến khoản phí ưu tiên được trả cho người đề xuất khối, nhưng chúng tôi sẽ bỏ qua điều đó vì, như đã thảo luận trong Phụ lục A, nó có lẽ sẽ không đáng kể dưới điều kiện bình thường.)

Trong trường hợp đơn giản của các khoản thuế MEV tuyến tính theo priorityPerGas (ví dụ tax_1(priorityPerGas) = a_1 * priorityPerGas), bạn có thể giải quyết để tính được tỷ lệ MEV mà mỗi ứng dụng nhận được:

a_1 priorityPerGas + a_2ưu tiên trên mỗi gas = 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 thuế MEV của riêng mình, một ứng dụng phải đối mặt với sự đánh đổi - thuế cao cho phép nó chiếm lĩnh một phần lớn hơn của MEV giữa các ứng dụng khi nó xảy ra, nhưng có nghĩa là nó có thể bỏ lỡ một số MEV giữa các ứng dụng nếu có cách khác nhau để khai thác nó. Ví dụ, nếu có một AMM thuế MEV trên mỗi giao dịch, thì một đơn đặt hàng MEV-tax UniswapX có thể có khả năng được điền bởi một AMM khác hoặc một bộ gom offchain.

Trong nhiều trường hợp, có thể có một sự cân bằng trong đó hai ứng dụng thiết kế thuế MEV của họ để chia sẻ MEV một cách tối đa hóa lợi ích của mỗi bên. Ví dụ, một AMM thuế MEV có thể muốn thu giá trị từ một nhà giao dịch có thông tin ở gần đỉnh khối, nhưng sau đó muốn cung cấp thanh khoản cho các nhà giao dịch và ứng dụng khác (bao gồm cả những người sử dụng thuế MEV) với một khoản phí cố định thấp. Trong trường hợp đó, AMM có thể thiết lập một mức thuế MEV tương đối thấp (ví dụ, $0.00001)priorityFeePerGas), để giao dịch chênh lệch giá (nếu có) xảy ra sớm trong khối, sau đó không thuế MEV nào cho các giao dịch tiếp theo trong khối. Các ứng dụng như UniswapX muốn tương tác với AMM có thể đặt mức thuế MEV cao hơn nhiều (ví dụ $0.01) priorityFeePerGas), để đảm bảo rằng giao dịch của họ được bao gồm sau khi hồ bơi đã được thương mại. Với những loại thuế tương đối đó, AMM sẽ kết thúc trước ngay cả khi chỉ có $1 của MEV trên đó và $50,000 của MEV trong một đơn đặt hàng UniswapX.

Chúng tôi nghĩ rằng đây là một không gian thiết kế rộng lớn đáng để nghiên cứu trong tương lai.

Giới hạn

Thuế MEV có một số phức tạp và nhược điểm. Chúng tôi cho rằng mỗi cái trong số này là một lĩnh vực thú vị để nghiên cứu trong tương lai.

Không tương thích với động cơ khích lệ

Các loại thuế MEV không phù hợp với việc khuyến khích đối với người đề xuất khối độc quyền. Chúng chỉ hoạt động nếu có sự cạnh tranh công bằng cho việc bao gồm giao dịch, điều này chỉ xảy ra nếu người đề xuất khối tuân theo các quy tắc mà chúng tôi gọi là 'thứ tự ưu tiên cạnh tranh', thay vì tối đa hóa doanh thu của riêng họ. Không chính thức và không toàn diện, chúng tôi đề xuất rằng các quy tắc này nên bao gồm:

• Thứ tự ưu tiên. Các giao dịch trong một khối phải được sắp xếp theo thứ tự giảm dần của priorityFeePerGas.
• Không thể kiểm duyệt. Nếu người đề xuất khởi phát nhận giao dịch t1 trong khội, và khội không đầy hoặc bao gồm một số giao dịch t2 sao cho t2.priorityFeePerGas < t1.priorityFeePerGas, sau đó khội phải bao gồm giao dịch t1.
• Quyền riêng tư trước giao dịch. Người đề xuất khối phải chấp nhận giao dịch thông qua một điểm cuối riêng và không được chia sẻ giao dịch đó với bất kỳ ai khác trước khi cam kết vào khối, hoặc sử dụng nội dung của những giao dịch đó như một đầu vào trong việc xây dựng giao dịch của riêng mình.
• Không nhìn lại. Người đề xuất khối phải đặt một thời gian xác định trước thời gian khối trước khi họ chấp nhận giao dịch từ bất kỳ ai, và sau đó họ không chấp nhận giao dịch từ bất kỳ ai.

Nếu một hoặc nhiều tài sản này bị vi phạm, nó có thể làm suy yếu hiệu quả của thuế MEV. Một người đề xuất khối vi phạm khả năng chống kiểm duyệt có thể tránh được hầu hết các loại thuế MEV bằng cách loại trừ các giao dịch cạnh tranh và gửi một giao dịch không ưu tiên tận dụng cơ hội cho chính nó. Một người đề xuất khối vi phạm quyền riêng tư trước giao dịch có thể đánh cắp MEV từ các giao dịch khác hoặc xem qua các khoản phí ưu tiên của họ để biết chính xác mức độ cần thiết lập của riêng mình, trong khi một người có thể gửi giao dịch muộn hơn bất kỳ ai khác sẽ có "cái nhìn cuối cùng" miễn phí về việc có nên trả giá cao hơn người khác để có cơ hội hay không, Một trong hai điều đó có thể tạo ra các vấn đề lựa chọn bất lợi mà cuối cùng không khuyến khích cạnh tranh.

Thật không may, trong khi thuộc tính đầu tiên sẽ dễ dàng thực thi ở tầng giao thức, việc thực thi các thuộc tính khác một cách đáng tin cậy là một vấn đề mở.

Trong trường hợp thiếu sự thực thi tại lớp giao thức, một người xếp hàng duy nhất cam kết tuân thủ các quy tắc này cần được tin tưởng không thay đổi từ chúng, và nếu các đề xuất viên ngoại giao việc xây dựng khối cho một phiên đấu giá tối đa doanh thu cạnh tranh (như Ethereum L1’s MEV-Boost) , các khối có lẽ sẽ không tuân theo chúng.

Những vấn đề này có thể được “giải quyết” với một bộ sắp xếp tin cậy duy nhất cam kết sử dụng thứ tự ưu tiên cạnh tranh cho việc xây dựng khối. Chúng cũng có thể được giải quyết bằng cách sử dụng cơ chế phi tập trung sử dụng một số kết hợp của sự đồng thuận, mật mã và/hoặc môi trường thực thi đáng tin cậy, như Angstrom của Sorella, SUAVE của Flashbots, Đấu giá không người dẫn đầu, hoặc Đa dạng.

Khối đầy

Một ngoại lệ của hoạt động bình thường của các thuế MEV xảy ra khi các khối hoàn toàn đầy. Trong trường hợp đó, người đề xuất khối có thể phải bỏ qua các giao dịch ưu tiên thấp, thay vì đơn giản là bao gồm chúng muộn trong khối. Khi các giao dịch tương tác với các ứng dụng bị đánh thuế MEV có khả năng có phí ưu tiên cực kỳ thấp, những ứng dụng đó có khả năng bị đẩy ra bởi các ứng dụng không sử dụng thuế MEV, hoặc những ứng dụng có thuế MEV cực kỳ thấp. Tuy nhiên, trong một chuỗi sử dụng cơ chế tương tự EIP-1559 để thiết lập một basefee riêng biệt, khối sẽ hiếm khi hoàn toàn đầy. Ngoài ra, khi một số giao dịch cần phải bị trì hoãn khi các khối đầy, việc trì hoãn các giao dịch thể hiện ưu tiên thấp bằng cách đặt thuế MEV cao hơn có thể là một kết quả hợp lý.

Giao dịch bị hoàn lại

Thuế MEV dựa hiệu quả vào các cuộc đấu giá một khối, trong đó mọi "giá thầu" là một giao dịch. Một nhược điểm của các cuộc đấu giá đó là việc mất giá thầu thường sẽ dẫn đến các giao dịch được hoàn nguyên được đưa vào chuỗi, trả một số phí cơ bản và làm tắc nghẽn chuỗi.

Nếu một bộ xếp hạng có thể loại bỏ hoàn toàn các giao dịch thất bại, điều đó sẽ giảm bớt vấn đề này, mặc dù việc triển khai điều này có thể khó khăn ngay cả với một bộ xếp hạng tập trung. (Điều này cũng không tuân thủ chặt chẽ tính chất chống kiểm duyệt được mô tả ở trên, mặc dù định nghĩa đó có thể được điều chỉnh.) Một bộ xếp hạng phức tạp hơn có thể tối ưu hóa quá trình này bằng cách cho phép giao dịch xác định các phiên đấu giá gây tranh cãi mà chúng tham gia, cung cấp đủ thông tin cho bộ xếp hạng để bỏ qua các giao dịch sau đó mà nó biết sẽ thất bại.

Rò rỉ ý định của người dùng

Thuế MEV chỉ hoạt động khi có sự cạnh tranh giữa các người tìm kiếm, điều đó có nghĩa là cơ hội cần phải được biết đến một cách khá rộng rãi. Đối với các ứng dụng như AMMs, nơi cơ hội có thể thấy trên chuỗi khối, điều đó nên xảy ra một cách tự nhiên. Nhưng đối với các ứng dụng như định tuyến dựa trên ý định hoặc đấu giá backrunning, điều đó có nghĩa là ứng dụng có thể cần chia sẻ ý định của người dùng với các người tìm kiếm.

Trong một số trường hợp, việc mất quyền riêng tư tạm thời từ việc phát sóng ý định của người dùng trước khi nó được thực hiện có thể rò rỉ giá trị một cách không thể thu lại bằng một loại thuế MEV nào đó.

Ví dụ, giả sử Alice muốn mua một token có tính thanh khoản thấp bằng giao protocal đấu giá backrunning được mô tả ở trên. Cô ấy công bố một ý định đã ký cho ví hợp đồng thông minh của mình để mua token đó trên AMM, đặt một số dung sai trượt. Người tìm kiếm có thể đua nhau đẩy giá của token đó lên dung sai trượt của cô ấy trong một giao dịch ưu tiên cao, mà không điền vào đơn đặt hàng của người dùng. Người chiến thắng, Bob, sau đó có thể điền ý định của Alice một cách không cạnh tranh bằng cách bao gồm và backrunning nó trong một giao dịch ưu tiên thấp, do đó bắt sandwiching giao dịch của Alice và cho cô ấy một giá tệ hơn trong khi trốn thuế MEV của cô ấy. Một vấn đề tương tự có thể xảy ra với việc mua NFT.

Lưu ý rằng một cuộc tấn công như vậy sẽ rủi ro cho Bob, vì anh ta sẽ không thể đảm bảo tính nguyên tử giữa việc mua token và bán nó cho Alice. Một Bob ngây thơ có thể trở thành nạn nhân của một cái bẫy “sandwich ripping” trong đó Alice công bố ý định mua một token vô giá từ chính mình, khiến Bob mua nó trong kỳ vọng sandwich giao dịch của cô ấy, nhưng Alice thu hồi ý định của mình trước khi Bob hoàn thành việc sandwich.

Ứng dụng cũng có thể giảm thiểu điều này bằng cách giới hạn bộ tìm kiếm mà họ chia sẻ ý định và theo dõi hành vi của họ, giống như nhiều phiên đấu giá orderflow hiện có.

Cũng có thể kết hợp các khoản thuế MEV với các tính năng xây dựng nhận thức về quyền riêng tư như đã được mô tả trong thiết kế của Flashbots cho SUAVE.

Cuối cùng, trong những trường hợp nơi Alice quyết định rằng chi phí chia sẻ ý định của mình vượt quá lợi ích từ việc tìm kiếm cạnh tranh, cô ấy có thể xây dựng một giao dịch mình và gửi trực tiếp vào khối. Như đã thảo luận ở trên, một cài đặt lý tưởng của việc sắp xếp ưu tiên cạnh tranh sẽ cung cấp quyền riêng tư trước giao dịch từ người đề xuất khối.

Thảo luận và công việc trước đó

Đấu giá gas ưu tiên. Một số động lực của việc sắp xếp ưu tiên trong các chuỗi khối phi tập trung được nghiên cứu trong Flash Boys 2.0paper, đã đặt ra thuật ngữ “giá trị có thể khai thác của miner”. Bài báo đó đã quan sát rằng các miner Ethereum (khi mạng đó sử dụng chứng minh công việc) đã sắp xếp các giao dịch theo ưu tiên, và các nhà giao dịch chênh lệch giá đang dựa vào hành vi đó để tham gia vào “đấu giá gas ưu tiên” trong đó họ đặt giá để được bao gồm đầu tiên trong một khối, điều này đã dẫn đến việc một phần lớn của MEV từ giao dịch chênh lệch trên sàn giao dịch phi tập trung được chuyển cho các miner.

Đến trước được phục vụ trước. Một số cố gắng để giảm thiểu MEV thông qua các quy tắc sắp xếp giao dịch, như là ThemishoặcTrình xử lý hiện tại của Arbitrum One,7tập trung vào việc áp dụng một quy tắc sắp xếp khác, đầu tiên đến, đầu tiên phục vụ (đôi khi được gọi là “sắp xếp công bằng”) nơi mà người đề xuất khối phải sắp xếp giao dịch theo thứ tự họ nhìn thấy chúng.

Thứ tự ưu tiên áp dụng một cách tiếp cận khác—xem xét các giao dịch đến trong một khoảng thời gian nhất định một cách bình đẳng và sắp xếp chúng theo ưu tiên được khai báo.

Đến trước, được phục vụ trước rất khó thực thi hoặc thậm chí xác định trong môi trường mạng thực với nhiều hơn một trình xác thực. Nó cũng có thể dẫn đến các cuộc đua độ trễ lãng phí và thư rác ngay cả với một trình sắp xếp thứ tự đáng tin cậy duy nhất. Cuối cùng, thuế MEV có thể loại bỏ một số loại MEV nhất định mà việc đặt hàng đến trước được phục vụ trước không thể, chẳng hạn như lợi nhuận chênh lệch giá từ "bước nhảy" không liên tục của giá tài sản. Những lợi thế tiềm năng của việc đặt hàng ưu tiên so với đặt hàng đến trước được phục vụ trước phần nào liên quan đến lợi thế của thời gian rời rạc so với trao đổi thời gian liên tục được thảo luận trong Budish, Cramton, Shim (2015).

Trong khi đó, trong khi việc đặt hàng ưu tiên dường như mặc định rò rỉ giá trị cho MEV, bài viết này cho thấy cách thiết kế ứng dụng để thu hồi nó.

Chia sẻ phí. Blast, một Ethereum L2, cổ phiếumột phần của cả 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.

Các thuế MEV cho phép một cái gì đó tương tự (ít nhất là đối với các phí ưu tiên), nhưng có thể được triển khai tại tầng ứng dụng trên bất kỳ chuỗi nào sử dụng thứ tự ưu tiên cạnh tranh, mà không cần hỗ trợ đặc biệt cho việc chia sẻ phí. Chúng cũng cho phép các ứng dụng xác định thuế của riêng họ dưới dạng các hàm tùy chỉnh của phí ưu tiên, cung cấp tính linh hoạt hơn và có thể dẫn đến tính kết hợp lớn hơn của các ứng dụng nhận thức MEV.

Giải pháp không tin cậy. Bài viết này tập trung vào động lực cho các nền tảng sử dụng trình tự ưu tiên cạnh tranh - và cách tận dụng các nền tảng đó - thay vì thảo luận về cách thức thi hành mà không cần tin cậy.

Có cuộc thảo luận quan trọng về mỗi trong những thuộc tính khác cần thiết cho việc xác định ưu tiên cạnh tranh. Ví dụ, trong Fox, Pai, Resnick (2023), tác giả bàn luận về nhược điểm trong các phiên đấu giá trên chuỗi không có tính chống kiểm duyệt, và mô tả một thiết kế cho một phiên đấu giá chống kiểm duyệt bằng cách sử dụng nhiều người đề xuất đồng thời. Tuy nhiên, họ không đề xuất một thứ tự cụ thể cho các giao dịch.

Có nghiên cứu khác về việc xây dựng cơ chế cho việc xây dựng khối tín cậy tối thiểu, bao gồm cả của Flashbots’sSUAVE, Sorella's Angstrom, Đấu giá không có lãnh đạo, Espresso và Offchain Labs’@espressosys/espresso-systems-and-offchain-labs-release-r-d-roadmap-for-decentralized-timeboost-5d0007dff66d">decentralized Timeboost, và bắt buộc bao gồm giao dịch công cộngbởi Péter Szilági.

Kết luận

Chúng tôi hy vọng bài viết này khuyến khích các L2s xem xét việc sử dụng đơn hàng ưu tiên (như được hỗ trợ mặc định trong OP Stack) và truyền cảm hứng cho các ứng dụng thử nghiệm thuế MEV nơi được hỗ trợ.

Chúng tôi cũng hy vọng nó sẽ thúc đẩy nghiên cứu tiếp theo về giao thức để xác định ưu tiên cạnh tranh tối thiểu tin cậy trên cả L1 và L2. Nếu bạn quan tâm đến việc hợp tác giải quyết vấn đề đó và đang đọc điều này trước thứ Năm, ngày 6 tháng 6, bạn vẫn có thể nộp đơn xin học bổng TLDR để làm việc về Các bộ xử lý hàng loạt L2 chống MEV with Dan. Hoặc cứ thoải mái liên hệ với dan@paradigm.xyzvàdave@paradigm.xyzvới những ý tưởng!

Chú thích

1. Trong bài viết này, chúng tôi sử dụng thuật ngữ “người đề xuất” để chỉ người thực hiện hoặc quyết định các giao dịch được bao gồm trong một khối cụ thể. Trên các nền tảng Ethereum L2, vai trò này thường được thực hiện bởi một “người xếp hàng.” Trên Ethereum L1, nó được thực hiện bởi một nhà xác thực Ethereum cụ thể được gọi là người đề xuất, mặc dù thường người đề xuất sẽ ủy thác công việc xây dựng khối cho một cuộc đấu giá cạnh tranh mà trong đó “người truyền thông” và “người xây dựng” tham gia. Chi tiết về cách phân chia các trách nhiệm này nằm ngoài phạm vi của bài viết này.↩
2. Phí ưu tiên mỗi gas thực sự không được chỉ định rõ ràng trong giao dịch, nhưng có thể được tính toán trong đó. Giao dịch chỉ định một giá gas, nhưng Ethereum cũng tính một phí cơ bản, được trừ ra khỏi giá gas và đốt cháy. Phí cơ bản nên được bỏ qua cho mục đích thuế MEV, vì nó không nằm trong sự kiểm soát của người giao dịch. Phí ưu tiên mỗi gas - giá cho phần phí giao dịch đi đến người đề xuất khối - có thể được tính toán trong Solidity như priorityGasPrice = tx.gasprice - block.basefee.↩
3. Hoặc chúng ta có thể đơn giản chỉ định MEV để loại trừ bất kỳ lợi nhuận nào từ người tìm kiếm và chỉ đề cập đến giá trị sẽ được chuyển đến người xác thực.↩
4. Lưu ý rằng proposerPriorityFee—bằng với priorityFeePerGas nhân với tổng gas sử dụng trong giao dịch—không thể thực sự được tính toán trong hợp đồng, vì không có cách nào để biết được giao dịch sẽ sử dụng bao nhiêu gas cuối cùng. Tuy nhiên, điều này thường không quan trọng, vì tất cả những gì chúng ta cần là một giới hạn trên cho nó. Để đảm bảo an toàn, bạn có thể nhân priorityFeePerGas với 30 triệu—số gas tối đa hiện tại trong một khối Ethereum. Ước lượng giá trị này cao hơn đơn giản có nghĩa là MEV tax sẽ chiếm một phần trăm MEV lớn hơn.↩
5. Giả sử một giao dịch không thể nhiều hơn 30 triệu gas, một priorityFeePerGas là 50.000 sẽ dẫn đến việc thanh toán gas là 1500 gwei—khoảng $0.006 với giá ETH là $4000.↩
6. Trong trường hợp priorityFeePerGas được thiết lập sao cho lợi nhuận của người đánh giá là không, giao dịch đối với lợi nhuận tối đa của người đánh giá nên tương ứng với cùng một giao dịch trên tối ưu hóa chức năng AMM. Chứng minh điều này để lại cho đọc giả làm bài tập. ↩
7. Arbitrum has đã thảo luậnthay thế điều này bằng một hình thức sắp xếp ưu tiên gọi là Timeboost, nhưng cho đến thời điểm viết bài này, điều đó vẫn chưa được đưa vào sản xuất.

Miễn trừ trách nhiệm：

1. Bài viết này được tái bản từ [Gatemô hình], Tất cả bản quyền thuộc về tác giả gốc [Dan Robinson, Dave White]. Nếu có ý kiến ​​phản đối về việc tái in này, vui lòng liên hệ với Gate Learnđội ngũ, và họ sẽ xử lý ngay lập tức.
2. Miễn trừ trách nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ thuộc về tác giả và không hợp thành bất kỳ lời khuyên đầu tư nào.
3. Các bản dịch của bài viết sang các ngôn ngữ khác được thực hiện bởi đội ngũ Gate Learn. Trừ khi được nêu, việc sao chép, phân phối hoặc đạo văn các bài viết dịch là không được phép.