Giới thiệu

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

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

Để thực hiện thuế MEV đối với một trong những chuỗi này, hợp đồng thông minh tính phí là một chức năng của 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 (giả sử) 99 đô la cho mỗi 1 đô la phí ưu tiên, nó có thể chiếm 99% MEV cạnh tranh cho giao dịch đó.

MEV thuế 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 đấ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 offchain nào của riêng nó, chỉ bằng cách kết nối vào một cuộc đấu giá được chia sẻ duy nhất do người đề xuất khối điều hành.

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

• Bộ định tuyến sàn giao dịch (DEX) phi tập trung giúp tối ưu hóa giá mà người hoán đổi nhận được
• Các nhà tạo lập thị trường tự động (AMM) giúp 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 gặp phải
• Ví cho phép người dùng của họ nắm bắt bất kỳ MEV "chạy ngược" nào được tạo ra bởi các giao dịch của họ

Nhưng có một nhược điểm. MEV thuế 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 đặt hàng ưu tiên cạnh tranh, bao gồm sắp xếp các 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ỳ điều gì. Nếu những người đề xuất khối đi chệch khỏi các quy tắc đó, họ có thể trốn thuế MEV để nắm bắt giá trị cho chính họ. Do đó, ngày nay, thuế MEV phụ thuộc vào việc tin tưởng vào các trình tự L2 và có thể sẽ không hoạt động Ethereum L1, nơi việc xây dựng khối bị chi phối bởi cuộc đấu giá nhà xây dựng cạnh tranh < href = "https://github.com/flashbots/mev-boost" > nhằm tối đa hóa doanh thu cho 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 đặt hàng ư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ó ngày nay. Và sự đơn giản tương đối của thứ tự ư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 tự duy nhất. Chúng tôi hy vọng bài đăng này thúc đẩy công việc tiếp theo về vấn đề đó.

Thứ tự ưu tiên

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

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

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

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

MEV Giả

sử một hợp đồng thông minh muốn nắm bắt 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 ứng dụng cụ thể khác nhau mà hợp đồng thông minh có thể cố gắng nắm bắt MEV của chính họ.

Nhưng trên 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 thứ tự ưu tiên cạnh tranh, thì chúng ta có một tín hiệu chung 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 số chức năng ngày càng tăng của nó. Ví dụ: hợp đồng có thể yêu cầu bất kỳ ai gọi nó chuyển applicationPriorityFee = 99 * proposerPriorityFee ETH hợp đồng. 4

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

Nếu khoản phí này tăng đủ nhanh như một hàm của priorityFeePerGas, thì chỉ một lượng MEV không đáng kể sẽ tích lũy cho người đề xuất. Vì priorityFeePerGas có mệnh giá bằng wei (một phần tỷ của một phần tỷ của một ETH), chúng tôi có rất nhiều độ chính xác để làm việc. Ví dụ: long như thuế MEV đủ nhạy cảm để mức ưu tiênFeePerGas là 50.000 sẽ dẫn đến mức thuế quá cao, thì tổng số tiền thanh toán cho người đề xuất sẽ dưới 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 Giới hạn, thuế MEV chỉ hoạt động nếu những người đề xuất khối tuân theo các quy tắc nhất định — cái mà chúng tôi gọi là "đặt hàng ưu tiên cạnh tranh" — thay vì đi chệch khỏi các quy tắc đó theo lệnh để tối đa hóa doanh thu của chính họ. Thực thi các 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 phác thảo làm thế nào, trên một chuỗi đượ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 thiểu ba vấn đề quan trọng trong MEV: cho phép giao diện DEX cải thiện việc thực hiện giao dịch cho người hoán đổi, cho phép AMM giảm tổn thất đối với chênh lệch giá cho LP của họ và để 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 người dùng.

DEX bộ định tuyến

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ý ý định hoán đổi và người tìm kiếm cạnh tranh để định tuyến hoặc điền ý định đó với mức giá tốt nhất có thể cho Alice.

Các phiên bản hiện tại của UniswapX sử dụng hai cơ chế để điều hành cuộc cạnh tranh đó: một phiên đấu giá ở Hà Lan nơi 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à phiên đấu giá yêu cầu báo giá offchain ban đầu (RFQ) để đặt giá khởi điểm của phiên đấu giá Hà Lan đó.

Trên một nền tảng đảm bảo đặ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: 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 lệnh có thể được điền ngay lập tức bởi bất kỳ ai, nhưng với giá thực hiện được đặt làm chức năng ư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á khớp lệnh của lệnh là tối thiểuPrice + ($ 0,01 * priorityFeePerGas). Giá tối thiểu có thể là một số giá trị cố định mà cô ấy dự kiến 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 để lấp đầy lệnh 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 hoàn nguyên sẽ được lấp đầy lệnh, điều này sẽ đảm bảo rằng trình hoán đổ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ố 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 đô la và giá hiện tại của ETH là 3.500 đô la, priorityFeePerGas trong giao dịch chiến thắng sẽ là khoảng 50.000. (Quan sát rằng trong một giao dịch có giá 200.000 gas, điều này sẽ dẫn đến khoản thanh toán chỉ khoảng 10 tỷ wei — khoảng 0,000035 đô la — cho 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ác cơ chế hiện có đượ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 mức giá tốt hơn so với các đơn đặt hàng sử dụng đấu giá của Hà Lan. Như đã thảo luận trong bài báo này, các cuộc đấu giá onchain của Hà Lan bị rò rỉ một số giá trị để MEV do biến động 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 hoàn thành trong khối tiếp theo trong khi chiếm phần lớn MEV của chúng.

Không giống như RFQ offchain, 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 hiện giao dịch trên chuỗi. Điều này có nghĩa là một nhà thầu chiến thắng có thể được đảm bảo rằng họ chỉ cam kết lấp đầy lệnh nếu giao dịch onchain của họ thành công. Điều đó có thể giúp thanh khoản onchain như AMM dễ dàng cạnh tranh với tính thanh khoản offchain, có nghĩa là UniswapX có thể phục vụ như một bộ định tuyến hiệu quả hơn cho các hệ thống đa nhóm như Uniswap v4.

AMMs

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

Một AMM có thể nắm bắt MEV bằng cách tính thêm phí như một chức năng của phí ưu tiên trên giao dịch, cho phép nó bán đấu giá quyền giao dịch đầu tiên trong khối. Có nhiều cách để tính toán và chỉ định mức phí đó. Chúng ta sẽ thảo luận về một cái được cho là trung lập — mệnh giá nó theo đơn vị thanh khoản của nhóm, sqrt (xy). Giao dịch chiến 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 một 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 (với một số 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 nhà giao dịch chênh lệch giá giao dịch theo giá thật và sau giao dịch đó, giá trung điểm trên mỏ phải là giá thực. 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í qua đêm cố định. Các giao dịch không hiểu biết muốn giao dịch trên mỏ mà không phải trả thêm thuế MEV sẽ đặt mức phí ưu tiên thấp.

Có nhiều cách khác để thực hiện thuế MEV đối với một AMM sẽ có tác dụ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 giao dịch hoán đổi, có thể ảnh hưởng đến tỷ lệ phần trăm phí qua đêm được áp dụng bởi nhóm 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á.

Backrunning auctions

Các mô tả ở trên cho thấy cách các ứng dụng nhất định có thể được thiết kế để tránh rò rỉ MEV. Tuy nhiên, điều gì sẽ xảy ra nếu ví muốn cố gắng giúp người dùng nắm bắt MEV 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 kết hợp thuế MEV?

Ví dụ, khi Alice thực hiện một giao dịch lớn trên một 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-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 của họ, nhưng họ dựa vào một hệ thống đấu giá offchain phức tạp. Không gian thiết kế đấu giá Orderflow mô tả một số giải pháp khác.

MEV thuế, khi kết hợp với ví hợp đồng thông minh dựa trên mục đích, có thể cho phép chúng tôi xây dựng một hệ thống thay thế để nắm bắt MEV chạy ngược cho Alice. Giả sử rằng thay vì tạo một giao dịch giao dịch trên AMM, Alice ký một ý định rằng 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 tính phí bất cứ ai gửi giao dịch đó một khoản thuế MEV, được trả cho Alice.

Người tìm kiếm gửi ý định của Alice sẽ có độc quyền chạy ngược lại cô ấy, vì họ có thể làm như vậy một cách nguyên tử trong cùng một giao dịch. Do đó, nếu tìm kiếm là cạnh tranh, tất cả lợi nhuận từ việc chạy ngược Alice sẽ 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 các giao dịch người dùng chạy trước, bởi vì một giao dịch chạy trước 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 giảm thiểu có thể xảy ra) được thảo luận chi tiết hơn trong phần Giới hạn bên dưới. Tuy nhiên, điều này ít nhất có thể là một cải tiến trên các hệ thống sử dụng mempool công khai 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 các ví dụ này, các cách sử 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 offchain hoặc đấu giá Hà Lan, chẳng hạn như:

• Các giao thức cho các nhà tiên tri để nắm bắt giá trị có thể trích xuất của oracle mà họ tạo ra, như Oval
• Đấu giá tái cấp vốn trong các giao thức cho vay được thế chấp bằng NFT như Blend
• Lending giao thức thanh lý ít rò rỉ hơn giá trị hơn đấu giá Hà Lan

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

Các giải pháp trên được thiết kế để nắm bắt MEV tương tác với một ứng dụng duy nhất. Nhưng đôi khi người tìm kiếm có thể nắ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ó 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ể mức 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 điền vào một trong các đơn đặt hàng UniswapX bị đánh thuế MEV được mô tả ở trên so với AMM bị đánh thuế MEV?

Trong trường hợp đó, số lượng MEV vượt quá tương đối được nắm bắt bởi mỗi ứng dụng được xác định bởi cách các ứng dụng đó đặt thuế MEV của chúng. Nếu giá trị app_i tính 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ầu có thể được xác định bằng cách giải mức độ ưu tiên trong phương trình này:

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 cho ưu tiênPerGas * gasĐược sử dụng để tài khoản phí ưu tiên 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ó thể sẽ không đáng kể trong điều kiện bình thường.)

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

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 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 hơn cho phép nó chiếm tỷ lệ lớn hơn trong MEV ứng dụng chéo 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ó những cách cạnh tranh để trích xuất nó. Ví dụ: nếu có AMM tính thuế MEV đối với mỗi giao dịch, thì lệnh UniswapX MEV thuế có thể có nhiều khả năng được lấp đầy bởi một AMM khác hoặc chất độn ngoài chuỗi.

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

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

Hạn chế

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

Không tương thích khuyến khích

MEV thuế không tương thích với ưu đãi đố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 để đưa vào giao dịch, điều này chỉ có thể xảy ra nếu người đề xuất khối tuân theo các quy tắc mà chúng tôi sẽ gọi là "đặt hàng ưu tiên cạnh tranh", thay vì tối đa hóa doanh thu của chính họ. Không chính thức và không đầy đủ, chúng tôi đề xuất rằng các quy tắc này nên bao gồm:

• Đặt hàng ưu tiên. Các giao dịch trong một khối phải được sắp xếp theo lệnh giảm dần của priorityFeePerGas.
• Kiểm duyệt-sự kháng cự. 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 bao gồm một số giao dịch t2 sao cho t2.priorityFeePerGas < t1.priorityFeePerGas, thì 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 các giao dịch thông qua một điểm cuối riêng và không được chia sẻ các giao dịch đó với bất kỳ ai khác trước khi cam kết với khối hoặc sử dụng nội dung của các giao dịch đó làm đầu vào trong việc xây dựng các giao dịch của riêng mình.
• Không có cái nhìn cuối cùng. Người đề xuất khối phải đặt một khối thời gian xác định trước đó 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 sự kháng cự 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 tài sản đầu tiên sẽ dễ dàng thực thi vào lớp 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 không có sự thực thi tại lớp giao thức, một trình tự duy nhất cam kết tuân thủ các quy tắc này cần phải được tin tưởng để không đi chệch khỏi chúng và nếu người đề xuất thuê ngoài việc xây dựng khối cho một cuộc đấu giá tối đa hóa doanh thu cạnh tranh (chẳng hạn như Ethereum L1 MEV-Boost), các khối có thể 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 trình tự đáng tin cậy duy nhất, người cam kết 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 một cơ chế phi tập trung bằng cách 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, 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 < href = "https://ethresear.ch/t/multiplicity-a-gadget-for-multiple-concurrent-block-proposers/14962 ">Đa dạng.

Khối đầy đủ

Một ngoại lệ đối với hoạt động bình thường của thuế MEV xảy ra khi các khối hoàn toàn đầy. Trong trường hợp đó, những người đề xuất khối có thể phải bỏ qua các giao dịch có mức độ ưu tiên thấp hơn, thay vì chỉ đơn giản là đưa chúng vào cuối khối. Vì các giao dịch tương tác với các ứng dụng bị đánh thuế MEV có thể có phí ưu tiên cực thấp, những ứng dụng đó có thể bị lấn át 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 thấp. Tuy nhiên, trong một chuỗi sử dụng cơ chế giống như EIP-1559 để đặt một basefee riêng biệt, sẽ tương đối hiếm khi các khối được lấp đầy hoàn toàn. Ngoài ra, do 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 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ý.

Các giao dịch MEV thuế được hoàn nguyên

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 trình sắp xếp có thể loại trừ hoàn toàn các giao dịch thất bại, điều đó sẽ làm giảm bớt vấn đề này, mặc dù điều đó có thể khó thực hiện ngay cả với một trình sắp xếp tập trung. (Nó cũng sẽ không tuân thủ nghiêm ngặt tài sản sự kháng cự kiểm duyệt được mô tả ở trên, mặc dù định nghĩa đó có thể được điều chỉnh.) Một trình tự 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 các giao dịch chỉ định các cuộc đấu giá gây tranh cãi mà họ đang tham gia, cung cấp cho trình sắp xếp đủ thông tin để bỏ qua các giao dịch tiếp theo mà nó biết sẽ thất bại.

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

chỉ hoạt độ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 được biết đến rộng rãi. Đối với các ứng dụng như AMM, nơi cơ hội có thể nhìn thấy trên chuỗi, điều đó sẽ 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 mục đích hoặc đấu giá chạy ngược, điều đó có nghĩa là ứng dụng có thể cần chia sẻ ý định của người dùng với người tìm kiếm.

Trong một số trường hợp, quyền riêng tư tạm thời bị mất 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ể bị rò rỉ giá trị theo cách không thể lấy lại bằng thuế MEV

Ví dụ: giả sử Alice muốn mua một mã thông báo có tính thanh khoản thấp bằng cách sử dụng phiên đấu giá chạy ngược giao thức được mô tả ở trên. Cô ấy xuất bản một ý định đã ký cho ví hợp đồng thông minh của mình để mua mã thông báo đó trên một AMM, thiết lập một số khả năng chịu trượt. Người tìm kiếm có thể chạy đua để đẩy giá của mã thông báo đó đến khả năng chịu trượt giá của cô ấy trong một giao dịch ưu tiên cao, mà không cần lấp đầy lệnh của người dùng. Người chiến thắng, Bob, sau đó có thể không cạnh tranh thực hiện ý định của Alice bằng cách đưa nó vào một giao dịch ưu tiên thấp, do đó kẹp giao dịch của Alice và cho cô ấy một mức giá tồi 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ẽ gây 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 mã thông báo và bán nó cho Alice. Một Bob ngây thơ có thể giảm nạn nhân của một bẫy "xé bánh sandwich", trong đó Alice công bố ý định mua một mã thông báo vô giá trị từ chính mình, khiến Bob mua nó với dự đoán sẽ kẹp giao dịch của cô ấy, nhưng Alice đã thu hồi ý định của mình trước khi Bob có thể hoàn thành chiếc bánh sandwich.

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à họ chia sẻ ý định và theo dõi hành vi của họ, như nhiều phiên đấu giá luồng đặt hàng hiện có.

Cũng có thể kết hợp 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 hình dung trong các thiết kế của Flashbots cho SUAVE.

Cuối cùng, trong trường hợp Alice quyết định rằng chi phí chia sẻ ý định của mình lớn hơn lợi ích từ tìm kiếm cạnh tranh, cô ấy có thể tự xây dựng một giao dịch và gửi trực tiếp vào khối. Như đã thảo luận ở trên, một triển khai lý tưởng của thứ tự ư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

tiên gas đấu giá. Một số động lực của việc đặt hàng ưu tiên trong các blockchain phi tập trung đã được nghiên cứu trong bài báo Flash Boys 2.0, đặt ra thuật ngữ "giá trị có thể trích xuất của thợ mỏ". Bài báo đó quan sát thấy rằng Ethereum thợ mỏ (khi mạng đó sử dụng bằng chứng công việc) đã đặt hàng các giao dịch theo mức độ ưu tiên và các nhà kinh doanh chênh lệch giá đã dựa vào hành vi đó để tham gia vào "các cuộc đấu giá gas ưu tiên", trong đó họ đấu thầu quyền được đưa vào đầu tiên trong một khối, dẫn đến phần lớn MEV từ chênh lệch giá sàn giao dịch phi tập trung tích lũy cho các thợ mỏ.

Người đến trước, được phục vụ trước. Một số nỗ lực giảm thiểu MEV thông qua các quy tắc đặt hàng giao dịch, chẳng hạn như Themis hoặc Arbitrum One's sequencer hiện tại, 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 đó người đề xuất khối phải lệnh giao dịch trong lệnh mà họ nhìn thấy chúng.

Đặt hàng ưu tiên có một cách tiếp cận khác — xử lý các giao dịch đến trong một khoảng thời gian nhất định như nhau và thay vào đó đặt hàng chúng theo mức độ ưu tiên được tuyên bố.

Đế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à đặ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 thứ tự ưu tiên dường như rò rỉ giá trị để MEV theo mặc định, bài đăng này cho thấy cách các ứng dụng có thể được thiết kế để lấy lại nó.

Chia sẻ phí. Blast, một Ethereum L2, chia sẻ một phần của cả phí ưu tiên và phí cơ bản với hợp đồng thông minh được truy cập trong một giao dịch.

MEV thuế cho phép một cái gì đó tương tự (ít nhất là đối với phí ưu tiên), nhưng có thể được thực hiện ở lớp ứ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ó hỗ trợ đặc biệt để chia sẻ phí. Chúng cũng cho phép các ứng dụng xác định thuế của riêng chúng là các chức năng tùy chỉnh của phí ưu tiên, cung cấp tính linh hoạt hơn và có khả năng dẫn đến khả năng soạn thảo cao hơn của các ứng dụng nhận biết MEV.

Không đáng tin cậy giải pháp. Bài đăng này tập trung vào động lực cho các nền tảng sử dụng thứ tự ưu tiên cạnh tranh — và cách tận dụng lợi thế của các nền tảng — thay vì thảo luận về cách thực thi nó một cách đáng tin cậy.

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

Đã có những 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 sự tin cậy, bao gồm SUAVE của Flashbots, Sorella's Angstrom, Leaderless Auctions, 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 đưa vào giao dịch công khai bởi Péter Szilági.

Kết luận

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

Chúng tôi cũng hy vọng nó thúc đẩy nghiên cứu sâu hơn về các giao thức để đặt hàng ưu tiên cạnh tranh giảm thiểu sự tin tưởng trên cả L1 và L2. Nếu bạn quan tâm đến việc cộng tác về vấn đề đó và đang đọc bài viết này trước Thứ Năm, ngày 6 tháng 6, bạn vẫn có thể đăng ký Học bổng TLDR để làm việc trên các bộ giải trình tự L2 kháng >MEV < href = "https://www.tldresear.ch/tldr/tldr-request-for-papers/mev-resistant-l2-sequencers" với Dan. Hoặc thoải mái liên hệ với dan@paradigm.xyz và dave@paradigm.xyz với ý tưởng!

Chú thích

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

Tuyên bố từ chối trách nhiệm:

1. Bài viết này được in lại từ [paradigm]. 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 việc tái bản này, vui lòng liên hệ với nhóm Gate Learn và họ sẽ xử lý kịp thời.

2. Tuyên bố từ chối trách nhiệm: Các quan điểm và ý kiến được trình bày trong bài viết này chỉ là của tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.

3. Bản dịch bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được đề cập, việc sao chép, phân phối hoặc đạo văn các bài báo đã dịch đều bị cấm.