Tác giả: Dan Robinson, Dave White

Biên soạn bởi: Joyce, BlockBeats

giới thiệu

Trong bài viết này, chúng tôi giới thiệu thuế MEV, một cơ chế mà theo đó bất kỳ ứng dụng nào cũng có thể thu được MEV của chính nó. Cơ chế này hiện có sẵn trên OP Stack L2 như OP Mainnet, Base và Blast, vì những người đề xuất khối trên các chuỗi này tuân theo một bộ quy tắc mà chúng tôi gọi là ưu tiên cạnh tranh.

Để áp thuế MEV đối với một trong các chuỗi, hợp đồng thông minh sẽ tính một khoản phí tương ứng với phí ưu tiên giao dịch. Nếu một ứng dụng tính thuế MEV 99 USD cho mỗi 1 USD phí ưu tiên của người tìm kiếm thì ứng dụng đó sẽ thu được 99% MEV cạnh tranh cho giao dịch đó.

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

Chúng tôi minh họa cách sử dụng thuế MEV để giải quyết ba câu hỏi chính 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 mức giá mà các sàn giao dịch nhận được;

Nhà tạo lập thị trường tự động (AMM) giúp giảm thiểu tổn thất và tái cân bằng (LVR) mà các nhà cung cấp thanh khoản gặp phải;

Ví cho phép người dùng nắm bắt mọi MEV "chạy phụ trợ" được tạo bởi các giao dịch của họ;

Nhưng có một vấn đề. Thuế MEV chỉ có hiệu lực nếu những người đề xuất chặn tuân thủ nghiêm ngặt các quy tắc ưu tiên cạnh tranh, bao gồm việc đặt hàng các giao dịch theo phí ưu tiên mà không kiểm duyệt, rình mò hoặc trì hoãn bất kỳ giao dịch nào. Nếu những người đề xuất chặn đi chệch khỏi các quy tắc này, họ có thể trốn thuế MEV và thu được giá trị cho riêng mình. Vì vậy, ngày nay, thuế MEV dựa vào những người đặt hàng 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 các cuộc đấu giá cạnh tranh của nhà xây dựng nhằm tối đa hóa thu nhập của người đề xuất.

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

Ưu tiên

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

Không có điều khoản nào trong giao thức Ethereum yêu cầu các giao dịch trong một khối phải được sắp xếp theo mức độ ưu tiênFeePerGas theo thứ tự giảm dần. Tuy nhiên, đó là một cách xây dựng khối phổ biến - ví dụ: đó là thứ tự của chuỗi OP Stack và thuật toán mặc định được sử dụng bởi geth và reth. Ưu tiên không chỉ cho phép các nhà giao dịch thể hiện một cách hiệu quả tính cấp bách của các giao dịch của họ mà còn chuyển một số loại MEV nhất định đến những người đề xuất chặn một cách tự nhiên.

Điều này xảy ra vì việc ưu tiên biến cuộc cạnh tranh giành MEV thành một cuộc đấu giá khí đốt được ưu tiên. Khi có cơ hội thu lợi nhuận từ các tương tác với một chuỗi, chẳng hạn như kinh doanh chênh lệch giá với các sàn giao dịch tập trung thông qua AMM, những người tìm kiếm sẽ chạy đua để trở thành người đầu tiên làm điều đó. Nếu chuỗi sử dụng mức độ ưu tiên để xác định việc bao gồm và đặt hàng giao dịch, thì người tìm kiếm sẽ cạnh tranh bằng cách đặt mức phí ưu tiên cao cho giao dịch của họ.

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

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 mà nó tương tác. Có rất nhiều nghiên cứu về các cách khác nhau dành riêng cho ứng dụng mà hợp đồng thông minh có thể cố gắng nắm bắt MEV của riêng chúng.

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

Khoản phí mới này được trả bởi người tìm kiếm đã gửi giao dịch nên nó ảnh hưởng đến hành vi của người tìm kiếm đó. Nếu có cơ hội là 100 MEV, giao dịch chiến thắng giờ đây sẽ chỉ đặt phí ưu tiên là 1 ETH, vì điều này sẽ dẫn đến tổng khoản 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). Mọi khoản phí ưu tiên cao hơn sẽ làm cho giao dịch không có lợi; mọi khoản phí ưu tiên thấp hơn sẽ dẫn đến mất cơ hội cho các đối thủ cạnh tranh đặt ra mức 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à thuế MEV. Thuế MEV cho phép ứng dụng chiếm quyền ưu tiên vì lợi ích riêng của nó, cho phép ứng dụng lấy lại MEV cho người dùng thay vì tiết lộ nó cho những người đề xuất chặn.

Nếu phí tăng đủ nhanh như một chức năng của mức độ ưu tiênFeePerGas, thì người đề xuất sẽ chỉ nhận được MEV không đáng kể. Vì PriorityFeePerGas được định giá bằng wei (phần tỷ của 1 ETH), nên chúng tôi cần phải xử lý rất chính xác. Ví dụ: miễn là thuế MEV đủ nhạy cảm để mức ưu tiênFeePerGas là 50.000 sẽ dẫn đến mức thuế quá mức thì tổng số tiền trả cho người đề xuất sẽ nhỏ hơn 0,01 USD. (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ế”, thuế MEV chỉ có tác dụng nếu những người đề xuất chặn tuân theo các quy tắc nhất định (cái mà chúng tôi gọi là “ưu tiên cạnh tranh”) và không đi chệch hướng để tối đa hóa doanh thu của chính họ. Việc thực thi các quy tắc này một cách không đáng tin cậy là một câu hỏi mở.

Chụp MEV ứng dụng đơn

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

Bộ định tuyến trao đổi phi tập trung

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

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

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

Ví dụ: nếu Alice có lệnh UniswapX để bán 1 ETH, cô ấy có thể xác định giá thực hiện của lệnh là Giá tối thiểu + ($0,01 * mức ưu tiênFeePerGas). giá tối thiểu có thể là một giá trị cố định nào đó mà cô mong đợi sẽ thấp hơn đáng kể so với giá hiện tại.

Người tìm kiếm sẽ cạnh tranh để thực hiện đơn đặt hàng của Alice bằng cách gửi giao dịch. Lệnh sẽ được thực hiện bất kể giao dịch nào có phí ưu tiên cao nhất và không được khôi phục, điều này sẽ đảm bảo cho người trao đổi nhận được mức giá tốt nhất mà người tìm kiếm có thể tìm thấy. (Một số trường hợp ngoại lệ được thảo luận trong phần Hạn chế.)

Nếu giá tối thiểu của Alice là 3.000 USD và giá ETH hiện tại là 3.500 USD thì mức ưu tiênFeePerGas trong giao dịch thắng là khoảng 50.000. (Lưu ý rằng trong một giao dịch trị giá 200.000 Gas, điều này sẽ dẫn đến ~10 tỷ wei (~ 0,000035 USD) chỉ được trả cho riêng người đề xuất khối.)

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

Các đơn đặt hàng sử dụng thuế MEV có thể được thực hiện nhanh hơn và ở mức giá tốt hơn so với các đơn đặt hàng sử dụng đấu giá kiểu Hà Lan. Như đã thảo luận trong bài viết này, các cuộc đấu giá trực tuyến của Hà Lan làm rò rỉ một số giá trị cho MEV do sự thay đổi 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 thường có thể được điền vào khối tiếp theo trong khi vẫn thu được phần lớn MEV.

Không giống như RFQ ngoài chuỗi, các cuộc đấu giá cho các đơn đặt hàng sử dụng thuế MEV sẽ diễn ra tự động khi các giao dịch trên chuỗi được thực hiện. Điều này có nghĩa là người trúng thầu được đảm bảo cam kết chỉ thực hiện đơn hàng nếu giao dịch trên chuỗi thành công. Điều này có thể giúp thanh khoản trên chuỗi như AMM dễ dàng cạnh tranh với thanh khoản ngoài chuỗi hơn, nghĩa là UniswapX có thể đóng vai trò là bộ định tuyến hiệu quả hơn cho các hệ thống đa nhóm như Uniswap v4.

AMM

Thông thường, AMM rò rỉ giá trị cho các nhà kinh doanh chênh lệch giá giao dịch dựa trên giá cũ ở đầu khối, như đã thảo luận trong bài viết Mất mát và Tái cân bằng. Chúng ta có thể sử dụng thuế MEV để cho AMM nắm bắt MEV. Để đơn giản, chúng ta sẽ thảo luận cách hoạt động trên AMM mà không cần thanh khoản tập trung. (Nếu bạn quan tâm đến cách giải quyết những vấn đề như vậy bằng cách gộp thanh khoản, Sorella sẽ sớm đưa ra giải pháp.)

AMM có thể nắm bắt MEV bằng cách tính phí bổ sung như một chức năng của phí ưu tiên giao dịch, cho phép nó đấu giá quyền đứng đầu trong giao dịch trong một khối. Có một số cách để tính toán và định giá khoản phí này. Chúng ta sẽ thảo luận về một điều được cho là trung lập - tính theo đơn vị thanh khoản của nhóm, sqrt(xy). Giao dịch thắng sẽ là giao dịch làm tăng tính thanh khoản của nhóm nhiều nhất.

Khi thực hiện giao dịch đầu tiên trên nhóm trong một khối, thay vì thực thi điều kiện x_end * y_end > x_start * y_start , nhóm có thể thực thi điều kiện (a dưới dạng một 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 nhà giao dịch chênh lệch giá giao dịch ở mức giá thực và sau giao dịch đó, giá trung điểm trong nhóm sẽ là giá thực.

Sau giao dịch đầu tiên, giao dịch có thể được tiến hành giống như trên Uniswap v2, với phí hoán đổi cố định. Những nhà giao dịch thiếu hiểu biết muốn giao dịch trong nhóm mà không phải trả thêm thuế MEV sẽ có mức phí ưu tiên thấp hơn.

Có nhiều cách khác để thực hiện thuế MEV đối với AMM, những cách này sẽ có những tác động khác nhau. Ví dụ: thuế MEV có thể được tính bằng mã thông báo đầu vào hoặc đầu ra của một giao dịch hoán đổi, có thể ảnh hưởng đến tỷ lệ phần trăm phí hoán đổi được áp dụng bởi một nhóm hoặc có thể xác định giá tối thiểu cho các 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ị đáng để khám phá.

Đấu giá ngược dòng

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

Ví dụ: khi Alice thực hiện các giao dịch lớn trên AMM, đôi khi cô ấy tạo ra cơ hội chênh lệch giá cho những “kẻ đi sau” để kéo giá trở lại. Điều này thường sẽ bị rò rỉ tới MEV chứ không phải cho Alice.

MEV-Share và MEVBlocker là hai giao thức cho phép người dùng nắm bắt MEV từ các giao dịch, nhưng chúng dựa vào các hệ thống đấu giá ngoài chuỗi phức tạp. Không gian thiết kế đấu giá luồng đơn hàng mô tả một số giải pháp khác.

Thuế MEV, kết hợp với ví hợp đồng thông minh dựa trên mục đích, cho phép chúng tôi xây dựng một hệ thống thay thế để nắm bắt MEV đang chạy trong nền cho Alice. Giả sử rằng Alice không tạo giao dịch để giao dịch trên AMM mà thay vào đó ký một ý định rằng bất kỳ ai cũng có thể gửi tới ví hợp đồng thông minh của Alice để yêu cầu thực hiện hành động đó. Ví hợp đồng thông minh của Alice tính thuế MEV cho bất kỳ ai gửi giao dịch và thuế này sẽ được trả cho Alice.

Những người tìm kiếm gửi ý định của Alice sẽ có độc quyền điều hành ngược lại cô ấy, vì họ có thể thực hiện điều đó một cách tự động trong cùng một giao dịch. Do đó, nếu việc tìm kiếm mang tính cạnh tranh thì tất cả lợi nhuận của Alice sẽ được chuyển cho Alice thông qua thuế MEV.

Lưu ý rằng hệ thống này không nhất thiết phải bảo vệ người dùng khỏi các cuộc tấn công liên quan đến giao dịch của người dùng chạy trước, vì các giao dịch của người dùng chạy trước 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 giảm nhẹ có thể có) sẽ được thảo luận chi tiết hơn trong phần Hạn chế bên dưới. Tuy nhiên, đây ít nhất có thể là một sự cải tiến so với các hệ thống sử dụng nhóm bộ nhớ chung mà không có bất kỳ biện pháp giảm thiểu 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 thuế MEV có thể bao gồm hầu hết mọi thứ hiện đang sử dụng đấu giá ngoài chuỗi hoặc đấu giá kiểu Hà Lan, chẳng hạn như:

Các giao thức trong đó các oracle nắm bắt giá trị mà các oracle mà chúng tạo ra có thể trích xuất được, chẳng hạn như Oval;

Đấu giá tái cấp vốn cho các giao thức thế chấp NFT như Blend;

Giá trị rò rỉ của việc thanh lý hợp đồng vay thấp hơn so với đấu giá ở Hà Lan;

Chụp MEV đa ứng dụng

Giải pháp trên được thiết kế để nắm bắt các tương tác MEV với một ứng dụng duy nhất. Nhưng đôi khi người tìm kiếm có thể nhận đượ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 này có thuế MEV thì tất cả MEV trong giao dịch sẽ được chuyển sang ứng dụng có thuế MEV, bất kể thuế MEV cao hay thấp.

Nhưng điều gì sẽ xảy ra nếu giao dịch của người tìm kiếm tương tác với hai ứng dụng sử dụng thuế MEV? Ví dụ: điều gì sẽ xảy ra nếu có một số MEV chỉ có thể được nắm bắt bằng cách thực hiện một trong các lệnh UniswapX nộp thuế MEV ở trên đối với AMM nộp thuế MEV?

Trong trường hợp này, lượng MEV vượt quá tương đối mà mỗi ứng dụng thu được sẽ phụ thuộc vào cách các ứng dụng đó đặt thuế MEV. Nếu giá trị app_i được thu thập dưới dạng thuế MEV được đưa ra bởi hàm tax_i(ưu tiên), thì mức độ ưu tiên của giao dịch trúng thưởng có thể được xác định bằng cách giải phương trình sau về mức độ ưu tiên:

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

(Về mặt kỹ thuật, chúng tôi có thể thêm thuật ngữ thứ ba vào PriorityPerGas * gasUsed để tính phí ưu tiên trả cho người đề xuất chặn, nhưng chúng tôi sẽ bỏ qua điều đó, nó có thể không đáng kể trong các trường hợp thông thường)

Trong trường hợp đơn giản khi thuế MEV là tuyến tính theo mức độ ưu tiênPerGas (vì vậy tax_1(priorityPerGas) = ​​​​a_1 * PriorityPerGas), bạn có thể giải quyết phần MEV mà mỗi ứng dụng nhận được:

a_1 * ưu tiênPerGas + a_2 * ưu tiênPerGas = MEV ưu tiênPerGas = 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

Các ứng dụng phải đối mặt với sự đánh đổi khi thiết lập thuế MEV của riêng mình - thuế cao hơn sẽ mang lại cho nó một phần MEV ứng dụng chéo lớn hơn khi nó xảy ra, nhưng có nghĩa là nó có thể bỏ lỡ một số MEV ứng dụng chéo nếu có cách cạnh tranh để trích xuất nó. Ví dụ: nếu có một AMM tính thuế MEV trên mỗi giao dịch thì lệnh UniswapX thuế MEV có nhiều khả năng được thực hiện bởi một AMM khác hoặc người thực hiện ngoài chuỗi.

Trong nhiều trường hợp, có thể có sự cân bằng trong đó hai ứng dụng thiết kế thuế MEV để họ chia sẻ MEV theo cách tối đa hóa lợi nhuận tương ứng. Ví dụ: AMM thuế MEV có thể muốn thu được giá trị từ một nhà giao dịch có hiểu biết duy nhất ở gần đầu khối, nhưng sau đó muốn cung cấp tính thanh khoản ở mức cố định thấp hơn cho các nhà giao dịch và ứng dụng khác (bao gồm cả các ứng dụng sử dụng thuế MEV). trị giá. Trong trường hợp này, AMM có thể đặt thuế MEV tương đối thấp (ví dụ: 0,00001 USD * mức ưu tiênFeePerGas) để giao dịch chênh lệch giá (nếu có) xảy ra sớm trong khối và sau đó không áp thuế MEV 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 thuế MEV cao hơn (ví dụ: 0,01 USD * mức ưu tiênFeePerGas) để đảm bảo các giao dịch của họ được bao gồm sau khi nhóm đã phân chia giá trị. Với các khoản thuế tương đối này, ngay cả khi chỉ có 1 MEV và 50.000 USD MEV trong đơn đặt hàng UniswapX, AMM cuối cùng sẽ được phân xử chênh lệch giá trước tiên.

Chúng tôi tin 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ố điểm phức tạp và hạn chế mà chúng tôi tin rằng đây là những lĩnh vực thú vị để nghiên cứu trong tương lai.

Khuyến khích không tương thích

Thuế MEV không khuyến khích tương thích với những người đề xuất khối độc quyền. Chúng chỉ hoạt động nếu có một sân chơi bình đẳng để đưa vào giao dịch, điều này chỉ xảy ra nếu những người đề xuất khối tuân theo những gì chúng tôi gọi là quy tắc "ưu tiên cạnh tranh" thay vì tối đa hóa doanh thu của chính họ. Danh sách không chính thức các quy tắc được đề xuất bao gồm nhưng không giới hạn ở những điều sau:

Ưu tiên. Các giao dịch trong khối phải được sắp xếp theo mức độ ưu tiênFeePerGas theo thứ tự giảm dần.

Chống lại sự kiểm duyệt. Nếu người đề xuất khối nhận được giao dịch t1 trong khối và khối không đầy hoặc chứa một số giao dịch t2, chẳng hạn như t2.priorityFeePerGas < t1.priorityFeePerGas, thì khối phải chứa 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 điểm cuối riêng tư và không được chia sẻ các giao dịch đó với bất kỳ ai khác trước khi gửi chúng tới một khối hoặc sử dụng nội dung của các giao dịch này làm đầu vào để xây dựng giao dịch của riêng họ.

Không có đánh giá cuối cùng. Người đề xuất chặn phải đặt thời gian chặn rõ ràng. Trước thời điểm này, họ sẽ chấp nhận yêu cầu giao dịch từ bất kỳ ai, sau thời gian này họ sẽ không chấp nhận yêu cầu giao dịch từ bất kỳ ai nữa.

Việc vi phạm một hoặc nhiều thuộc tính này có thể làm giảm hiệu quả của thuế MEV. Những người đề xuất chặn vi phạm 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 các giao dịch không có mức độ ưu tiên để lợi dụng chính họ. Chặn những người đề xuất 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 xét phí ưu tiên của họ để biết chính xác họ cần đặt mức phí của mình cao đến mức nào, trong khi chặn những người đề xuất có thể gửi giao dịch muộn hơn những người khác sẽ được Miễn phí "Cuối cùng hãy xem về việc bạn có muốn trả giá cao hơn người khác để có được cơ hội hay không, cả hai điều này đều có thể tạo ra vấn đề lựa chọn bất lợi mà cuối cùng sẽ cản trở cạnh tranh.

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

Trong trường hợp không thực thi ở lớp giao thức, một trình sắp xếp chuỗi duy nhất cam kết tuân theo các quy tắc này cần phải được tin cậy để không đi chệch khỏi các quy tắc này và nếu những người đề xuất thuê ngoài việc xây dựng khối để đấu giá tối đa hóa doanh thu cạnh tranh (ví dụ: MEV-Boost của Ethereum L1), các khối có thể không đi theo họ.

Những vấn đề này có thể được "giải quyết" bởi một trình sắp xếp chuỗi đáng tin cậy duy nhất hứa hẹn sẽ sử dụng thứ tự ư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ác cơ chế phi tập trung bằng cách sử dụng một số kết hợp giữa sự đồng thuận, mật mã và/hoặc môi trường thực thi đáng tin cậy, chẳng hạn như Angstrom của Sorella, SUAVE của Flashbots, đấu giá không có người lãnh đạo hoặc tính đa dạng.

khối hoàn chỉnh

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

Giao dịch được khôi phục

Thuế MEV thực sự dựa vào các cuộc đấu giá theo từng 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á này là giá thầu không thành công thường dẫn đến các giao dịch được khôi phục được đưa vào chuỗi, phải trả một số phí cơ bản và gây tắc nghẽn chuỗi.

Điều này sẽ giảm bớt vấn đề này nếu bộ sắp xếp có thể loại trừ hoàn toàn các giao dịch thất bại, mặc dù điều này khó đạt được ngay cả với bộ sắp xếp tập trung. (Nó cũng sẽ không tuân thủ nghiêm ngặt các đặc tính chống kiểm duyệt được đề cập ở trên, mặc dù định nghĩa đó có thể được điều chỉnh.) Các trình sắp xếp trình tự phức tạp hơn có thể tối ưu hóa quy trình này bằng cách cho phép các giao dịch chỉ định những phiên đấu giá tranh chấp mà họ đang tham gia, cho phép trình sắp xếp trình tự có đủ thông tin bỏ qua các giao dịch tiếp theo mà nó biết sẽ thất bại.

Tiết lộ ý định của người dùng

Thuế MEV chỉ có tác dụng nếu có sự cạnh tranh giữa những 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 mức độ nào đó. Đối với các ứng dụng như AMM, nơi có thể nhìn thấy các cơ hội trên chuỗi, điều này sẽ diễn 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 mục đích hoặc đấu giá nền, điều này có nghĩa là ứng dụng có thể cần chia sẻ mục đích của người dùng với 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 do truyền bá ý định của người dùng trước khi nó được nhận ra có thể làm rò rỉ giá trị theo cách mà thuế MEV không thể phục hồi được.

Ví dụ: giả sử Alice muốn mua mã thông báo có tính thanh khoản thấp bằng giao thức đấu giá phụ trợ được mô tả ở trên. Cô công bố ý định đã ký của ví hợp đồng thông minh để mua mã thông báo trên AMM và đặt ra mức độ trượt giá nhất định. Người tìm kiếm có thể cạnh tranh trong một giao dịch có mức độ ưu tiên cao để đẩy giá của mã thông báo đó lên đến khả năng chịu trượt giá của mình mà không cần thực hiện đơn đặt hàng của người dùng. Người chiến thắng Bob sau đó có thể đáp ứng ý định của Alice theo cách không cạnh tranh bằng cách đưa nó vào một giao dịch có mức độ ưu tiên thấp và thực hiện ngược lại, từ đó kẹp giao dịch của Alice và đưa cho cô ấy một mức giá tồi tệ hơn trong khi trốn thuế MEV của cô ấy. Các vấn đề tương tự có thể phát sinh khi mua NFT.

Cần lưu ý rằng một cuộc tấn công như vậy rất rủi ro đối với Bob vì anh ta không thể đảm bảo tính nguyên tử giữa việc mua mã thông báo và bán nó cho Alice. Một Bob ngây thơ có thể rơi vào bẫy "kẹp và xé": Alice lần đầu tiên thông báo ý định mua một mã thông báo vô giá trị của chính mình và Bob mua mã thông báo để thực hiện giao dịch của mình, nhưng trước khi Bob hoàn tất việc này, Alice đã rút lại ý định của mình. .

Các ứng dụng cũng có thể giảm thiểu điều này bằng cách giới hạn nhóm người tìm kiếm mà chúng có chung mục đích và giám sát hành vi của họ, giống như nhiều cuộc đấu giá luồng đơn hàng hiện tại đã thực hiện.

Cũng có thể kết hợp thuế MEV với các tính năng của trình tạo nhận thức về quyền riêng tư, giống như những gì Flashbots hình dung cho thiết kế SUAVE.

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

Các cuộc thảo luận liên quan

Đấu giá khí ưu tiên. Bài viết Flash Boys 2.0, đặt ra thuật ngữ “giá trị có thể trích xuất của thợ mỏ”, xem xét một số động lực của việc ưu tiên trong các chuỗi khối phi tập trung. Bài báo nói rằng các công cụ khai thác Ethereum (khi mạng sử dụng bằng chứng công việc) đã ưu tiên các giao dịch và các nhà kinh doanh chênh lệch giá dựa vào hành vi này để tham gia vào “các cuộc đấu giá khí ưu tiên” trong đó họ đấu thầu để có quyền được đưa vào khu vực đầu tiên các khối, dẫn đến phần lớn MEV được trao đổi thông qua các sàn giao dịch phi tập trung thuộc sở hữu của các thợ mỏ.

Ai đến trước được phục vụ trước. Một số nỗ lực nhằm giảm thiểu MEV thông qua các quy tắc đặt hàng giao dịch, chẳng hạn như người đặt hàng hiện tại của Themis hoặc Arbitrum One (7) tập trung vào việc thực thi một quy tắc đặt hàng khác, đến trước được phục vụ trước (đôi khi được gọi là "đặt hàng công bằng"), trong đó những người đề xuất khối phải Sắp xếp các giao dịch theo thứ tự họ nhìn thấy chúng.

Ưu tiên thực hiện một cách tiếp cận khác - các giao dịch đến trong một thời gian nhất định sẽ được xử lý bình đẳng và được sắp xếp theo mức độ ưu tiên đã khai báo của chúng.

Đến trước được phục vụ trước rất khó thực thi hoặc thậm chí khó xác định trong môi trường mạng thực có nhiều trình xác thực. Ngay cả với một trình tuần tự đáng tin cậy, điều này có thể dẫn đến tình trạng tranh chấp và spam lãng phí về độ trễ. Cuối cùng, thuế MEV có thể loại bỏ một số loại MEV nhất định mà đơn đặ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ừ những “sự tăng vọt” rời rạc trong giá tài sản. Những lợi thế tiềm tàng của việc đặt hàng ưu tiên so với việc đặt hàng đến trước được phục vụ trước có liên quan ở một mức độ nào đó đến những 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).

Đồng thời, mặc dù mức độ ưu tiên dường như rò rỉ giá trị cho MEV theo mặc định, nhưng bài đăng này cho biết cách thiết kế ứng dụng của bạn để lấy lại giá trị đó.

Chia sẻ chi phí. Blast là Ethereum L2 và 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 các giao dịch.

Thuế MEV cho phép thực hiện điều gì đó tương tự (ít nhất là đối với các khoản phí ưu tiên) nhưng có thể được triển khai ở lớp ứng dụng trên bất kỳ chuỗi nào bằng cách sử dụng ưu tiên cạnh tranh mà không yêu cầu 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 chính họ như một chức năng tùy chỉnh của phí ưu tiên, mang lại sự linh hoạt cao hơn và có khả năng cải thiện khả năng kết hợp của các ứng dụng nhận biết MEV.

Giải pháp không đáng tin cậy. Bài viết này tập trung vào động lực để các nền tảng sử dụng ưu tiên cạnh tranh và các cách khai thác nền tảng, thay vì cách thực thi nó theo cách không đáng tin cậy.

Mỗi thuộc tính khác cần thiết cho việc ưu tiên cạnh tranh đã được thảo luận kỹ lưỡng trước đây. Ví dụ: trong Fox, Pai, Resnick (2023), các tác giả thảo luận về các lỗ hổng của đấu giá trực tuyến trong trường hợp không có sự phản đối kiểm duyệt và mô tả thiết kế của các cuộc đấ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 trình tự giao dịch cụ thể.

Có nghiên cứu khác về việc xây dựng các cơ chế xây dựng khối giảm thiểu niềm tin, bao gồm SUAVE của Flashbots, Angstrom của Sorella, Đấu giá không có lãnh đạo, Timeboost phi tập trung của Espresso và Offchain Labs, và việc đưa vào giao dịch công khai bắt buộc của Péter Szilági.

Chúng tôi hy vọng bài viết này khuyến khích L2 cân nhắc sử dụng mức độ ưu tiên (được hỗ trợ theo mặc định bởi ngăn xếp OP) và khuyến khích các ứng dụng thử thuế MEV nếu được hỗ trợ. Chúng tôi cũng hy vọng rằng nó sẽ truyền cảm hứng cho nghiên cứu sâu hơn về các giao thức ưu tiên cạnh tranh giảm thiểu độ tin cậy trên L1 và L2.