Paradigm đã xuất bản bài báo “Ưu tiên là tất cả những gì bạn cần” vào ngày 4 tháng 6, trong đó giới thiệu chi tiết về cơ chế thuế MEV mới.
Thuế MEV là một cơ chế mới cho phép các ứng dụng nắm bắt MEV mà chúng tạo ra thay vì tiết lộ nó cho những người đề xuất chặn (xem chú thích cuối trang ở cuối bài viết để biết thêm thông tin về những người đề xuất chặn). Cơ chế này tận dụng ưu tiên cạnh tranh trong quá trình xây dựng khối. Trong phương pháp sắp xếp này, các giao dịch được sắp xếp theo thứ tự chi phí ưu tiên giảm dần và các giao dịch có mức độ ưu tiên cao hơn sẽ được đóng gói theo khối trước tiên. Thuế MEV hoạt động bằng cách thêm một khoản phí bổ sung vào phí ưu tiên của giao dịch. Các ứng dụng có thể nắm bắt hầu hết hoặc thậm chí toàn bộ MEV bằng cách đặt mức phí riêng dựa trên phí ưu tiên của giao dịch. Điều này có nghĩa là các ứng dụng có thể chạy các phiê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 ngoài chuỗi nào bằng cách tham gia vào một phiên đấu giá chung duy nhất do người đề xuất khối điều hành.
Sự ra đời của cơ chế thuế MEV có thể tác động đến hệ sinh thái DeFi hiện tại:
- Thay đổi cách phân phối MEV truyền thống: Theo truyền thống, MEV chủ yếu chặn những người đề xuất và thuế MEV cho phép các ứng dụng nắm bắt giá trị này và phân phối lại cho người dùng hoặc sử dụng nó cho các mục đích khác.
- Cải thiện doanh thu và trải nghiệm người dùng cho các ứng dụng: Các ứng dụng có thể tăng doanh thu bằng cách thực hiện thuế MEV đồng thời cung cấp trải nghiệm người dùng tốt hơn vì người dùng đạt được hiệu quả cao hơn trong việc thực hiện giao dịch và giá giao dịch tốt hơn.
- Đã giải quyết một số vấn đề trong DeFi: M như tối ưu hóa định tuyến DEX, giảm tổn thất AMM khi kinh doanh chênh lệch giá, giảm rò rỉ MEV cho người dùng ví, v.v. Bằng cách áp dụng thuế MEV, các ứng dụng có thể cải thiện sản phẩm và dịch vụ của mình, từ đó nâng cao hiệu quả và tính bền vững của hệ sinh thái DeFi.
Trích dẫn
Trong bài viết này, chúng tôi giới thiệu thuế MEV, một cơ chế cho phép mọi ứng dụng lấy MEV (Giá trị có thể trích xuất tối đa) của chính nó.
Cơ chế này ngay lập tức có sẵn trên các chuỗi 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.
Để thực hiện thuế MEV trên các chuỗi này, hợp đồng thông minh sẽ tính phí dựa trên phí ưu tiên của giao dịch. Chúng tôi chứng minh rằng nếu một ứng dụng áp đặt mức thuế MEV trị giá 99 USD cho mỗi 1 USD mức độ ưu tiên mà người tìm kiếm thanh toán thì ứng dụng đó có thể thu được 99% MEV cạnh tranh của giao dịch đó.
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 nó 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 yêu cầu bất kỳ cơ sở hạ tầng ngoài chuỗi nào của riêng nó, chỉ cần kết nối với phiên đấu giá chung do người đề xuất khối điều hành.
Chúng tôi chỉ ra 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) giúp tối ưu hóa 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 mà các nhà cung cấp thanh khoản phải gánh chịu do tái cân bằng (LVR)
Ví cho phép người dùng nắm bắt bất kỳ MEV “rollback” nào đượ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 đặt hàng các giao dịch theo phí ưu tiên mà không bị kiểm duyệt, con mắt tò mò hoặc sự chậm trễ. 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ể lách thuế MEV để thu được giá trị. Do đó, thuế MEV ngày nay phụ thuộc vào các trình sắp xếp L2 đáng tin cậy và có thể hoàn toàn không hoạt động trên Ethereum L1, bởi vì trên mạng chính Ethereum, việc xây dựng khối chủ yếu bị chi phối bởi các cuộc đấu giá của nhà xây dựng cạnh tranh để tối đa hóa thu nhập của người đề xuất.
Tuy nhiên, khả năng 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ể đưa ra thứ tự ưu tiên. Và tính đơn giản tương đối của việc ư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 tin tưởng vào một trình tự sắp xếp 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.
Thứ tự ưu tiên
Khi ai đó gửi một giao dịch trên mạng chính Ethereum hoặc L2, họ sẽ chỉ định một khoản phí ưu tiên được trả cho người đề xuất khối. Bạn có thể tưởng tượng điều này được chỉ định thông qua PriorityFeePerGas, một con số nhân với lượng gas sử dụng trong giao dịch để nhận được builderPriorityFee, tổng số tiền được thanh toán bằng ETH.
Không có yêu cầu 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 thứ tự ưu tiên giảm dần của FeePerGas. Tuy nhiên, đây là một cách phổ biến để xây dựng khối. Ví dụ: đây là thuật toán mặc định được sử dụng bởi trình sắp xếp chuỗi và geth và reth của chuỗi OP Stack. Việc ư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 hướng dẫn một số loại MEV nhất định chặn những người đề xuất một cách tự nhiên.
Điều này xảy ra vì việc ưu tiên biến sự cạnh tranh dành cho MEV thành một cuộc đấu giá khí đốt được ưu tiên. Khi có cơ hội kiếm lợi từ việc tương tác với chuỗi, chẳng hạn như thông qua chênh lệch giá giữa AMM và sàn giao dịch tập trung, những người tìm kiếm sẽ cạnh tranh để trở thành người đầu tiên nắm bắt cơ hội. Nếu chuỗi sử dụng mức độ ưu tiên để xác định việc đóng gói và đặt hàng các giao dịch, người tìm kiếm sẽ cạnh tranh bằng cách đặt mức phí ưu tiên cao cho các giao dịch của họ.
Trong kịch bản cạnh tranh mà lợi nhuận phi rủi ro bị nén xuống 0 do cạnh tranh, người tìm kiếm chiến thắng cuối cùng sẽ phải trả toàn bộ MEV như một khoản phí ưu tiên. Vì vậy, nếu có sẵn lợi nhuận 100 ETH khi tương tác với hợp đồng, giao dịch đầu tiên nắm bắt cơ hội 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ố cân nhắc cho vấn đề này trong phần Hạn chế).
Thuế MEV
Giả sử một hợp đồng thông minh muốn nắm bắt MEV trong bất kỳ giao dịch nào mà nó tương tác. Có một tài liệu nghiên cứu sâu rộng về các cách khác nhau dành riêng cho ứng dụng trong đó các hợp đồng thông minh cố gắng nắm bắt MEV của chính chúng.
Nhưng trên thực tế, chúng ta không nhất thiết phải biết điều gì cụ thể về ứng dụng. Nếu chúng tôi biết rằng các khối được xây dựng thông qua ưu tiên cạnh tranh thì chúng tôi có tín hiệu thống nhất về lượng MEV trong một giao dịch: phí ưu tiên.
Chúng tôi đề xuất rằng các 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 dựa trên giao dịch đó, khoản phí này là một hàm tăng dần của phí ưu tiên. Ví dụ: hợp đồng có thể yêu cầu người gọi nó chuyển applicationPriorityFee = 99 * ETH của người đề xuấtPriorityFee 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ơ hội có MEV là 100 ETH, 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) . Bất kỳ khoản phí ưu tiên nào cao hơn sẽ làm cho giao dịch không có lợi; bất kỳ khoản phí ưu tiên nào thấp hơn sẽ dẫn đến cơ hội bị đối thủ cạnh tranh đặt ra mức phí cao hơn lấy đi. Đ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 các ứng dụng chiếm quyền ưu tiên vì lợi ích riêng của chúng, cho phép chúng lấy lại MEV cho người dùng thay vì để nó bị rò rỉ để chặn những người đề xuất.
Nếu phí tăng đủ nhanh như một hàm của mức độ ưu tiênFeePerGas, thì người đề xuất sẽ chỉ nhận được một MEV không đáng kể. Vì PriorityFeePerGas được định giá bằng wei (một phần tỷ ETH), nên chúng tôi có rất nhiều độ chính xác để tận dụng. Ví dụ: miễn là độ nhạy cảm về thuế MEV đủ cao để mức ưu tiênFeePerGas là 50.000 sẽ dẫn đến mức thuế quá cao thì tổng số tiền trả cho người đề xuất sẽ nhỏ hơn 0,01 USD.
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 (mà chúng tôi gọi là “ưu tiên cạnh tranh”) và không đi chệch khỏi các quy tắc này để 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 cho một ứng dụng
Trên một chuỗi nơi các khối được đảm bảo xây dựng bằng cách ưu tiên cạnh tranh, thuế MEV có thể được sử dụng để giảm bớt ba vấn đề quan trọng với MEV: cho phép giao diện DEX cải thiện việc thực hiện giao dịch của sàn giao dịch 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 ví thực hiện; pass Bán quyền cho người dùng chạy lại để giảm rò rỉ MEV của người dùng.
Trình tìm kiếm bộ định tuyến DEX
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 mục đích đó ở mức giá tốt nhất.
Phiên bản hiện tại của UniswapX sử dụng hai cơ chế để thực hiện cuộc thi này: đấu giá kiểu Hà Lan, trong đó giá giới hạn của Alice thay đổi theo thời gian cho đến khi được người tìm kiếm lấp đầy và đấu giá yêu cầu báo giá ngoài chuỗi ban đầu (RFQ) để đặt giá khởi điểm cho điều đó Đấu giá Hà Lan .
Trên nền tảng đảm bảo ưu tiên cạnh tranh, UniswapX có thể thay thế những nền tảng này bằng một cơ chế: thuế MEV. Nó hoạt động bằng cách cho phép người dùng ký một lệnh mà bất kỳ ai cũng có thể thực hiện ngay lập tức, nhưng giá thực hiện là một hàm số của phí ư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à giá trị cố định mà cô ấy mong đợi sẽ thấp hơn đáng kể so với hiện tại. giá.
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. Bất kỳ giao dịch nào có phí ưu tiên cao nhất và không có phí dự phòng sẽ được thực hiện theo lệnh, điều này sẽ đảm bảo cho nhà giao dịch 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 tiêu tốn 200.000 gas, điều này sẽ chỉ dẫn đến ~10 tỷ wei (~ 0,000035 USD) được trả cho người đề xuất khối.
Điều này có một số lợi thế 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 các đơn đặt hàng sử dụng đấu giá kiểu Hà Lan. Như được mô tả 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ể yêu cầu 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 thực hiện ở khối tiếp theo trong khi vẫn thu được phần lớn MEV của họ.
Không giống như RFQ ngoài chuỗi, các phiên đấu giá sử dụng thuế MEV để thực hiện đơn hàng sẽ diễn ra nguyên tử 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 thắng thầu được đảm bảo rằng đơn hàng sẽ chỉ được thực hiện 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) cạnh tranh với thanh khoản ngoài chuỗi dễ dàng 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 con nhiều nhóm (như Uniswap v4).
Nhà tạo lập thị trường tự động (AMM)
Thông thường, AMM bị rò rỉ giá trị do các nhà kinh doanh chênh lệch giá giao dịch ở mức giá cũ ở đầu các khối, như đã thảo luận trong bài báo Mất mát so với tái cân bằng . Chúng ta có thể sử dụng thuế MEV để yêu cầu AMM nắm bắt các MEV này. Để đơn giản, chúng tôi sẽ thảo luận cách triển khai điều này 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 loại vấn đề này bằng tính thanh khoản tập trung, 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 dựa trên mức độ ưu tiên của giao dịch, cho phép nó đấu giá quyền ưu tiên các giao dịch trong một khối. Có nhiều 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 cách tiếp cận được cho là trung lập – được biểu thị bằng đơn vị thanh khoản nhóm sqrt(xy). Các giao dịch chiến thắng sẽ là những 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, x_end * y_end > x_start * y_start nhóm có thể thực thi một điều kiện (dưới dạng hằng số some):
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 theo giá thực, sau đó giá trung điểm của nhóm sẽ là giá thực.
Sau giao dịch đầu tiên đó, các giao dịch có thể hoạt động giống như trong Uniswap v2, sử dụng phí trao đổi cố định. Những nhà giao dịch thiếu hiểu biết muốn giao dịch mà không phải trả thêm thuế MEV sẽ được đặt 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 biểu thị bằng mã thông báo đầu vào hoặc đầu ra của một sàn giao dịch, có thể ảnh hưởng đến tỷ lệ phần trăm phí trao đổ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
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. Nhưng điều gì sẽ xảy ra nếu một chiếc ví muốn giúp người dùng nắm bắt MEV mà họ tạo ra khi tương tác với bất kỳ ứng dụng nào thông qua bất kỳ giao dịch nào, ngay cả khi những ứng dụng đó không bao gồm thuế MEV?
Ví dụ: khi Alice thực hiện một giao dịch lớn trên AMM, đôi khi cô ấy tạo cơ hội chênh lệch giá cho những “người đi sau” để đưa giá trở lại bình thường. Thông thường, những cơ hội này bị rò rỉ cho MEV chứ không phải do Alice sở hữu.
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 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á dòng lệnh ” mô tả một số giải pháp khác.
Khi thuế MEV được kết hợp với ví hợp đồng thông minh dựa trên mục đích, chúng tôi có thể xây dựng một hệ thống thay thế để nắm bắt MEV của 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 nó thực hiện hành động đó. Ví hợp đồng thông minh của Alice tính thuế MEV cho người gửi giao dịch và thuế được trả cho Alice.
Người tìm kiếm đã gửi ý định của Alice có độc quyền theo dõi cô ấy vì họ có thể thực hiện điều đó một cách nguyên tử trong cùng một giao dịch. Do đó, nếu việc tìm kiếm có tính cạnh tranh cao, tất cả lợi nhuận từ việc theo dõi Alice sẽ được chuyển đến Alice thông qua thuế MEV của cô ấy.
Điều quan trọng cần lưu ý là hệ thống này có thể không bảo vệ hoàn toàn người dùng khỏi các cuộc tấn công chạy trước, vì 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ể xảy ra) được thảo luận chi tiết trong phần Hạn chế bên dưới. Tuy nhiên, đây ít nhất là một cải tiến so với hệ thống nhóm bộ nhớ công cộng mà không có bất kỳ biện pháp giảm nhẹ nào.
Các trường hợp sử dụng khác
Ngoài những ví dụ này, các ứng dụng tiềm năng khác của thuế MEV bao gồm hầu hết mọi trường hợp 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 như Oval cho phép giá trị có thể trích xuất (OEV) bằng cách ghi lại các oracle mà chúng tạo ra.
- Đấu giá tái cấp vốn trong các giao thức cho vay thế chấp NFT như Blend.
- Việc thanh lý hợp đồng cho vay bị rò rỉ ít giá trị hơn so với cuộc đấu giá ở Hà Lan
Chụp MEV đa ứng dụng
Giải pháp trên được thiết kế để ghi lại MEV được tạo khi tương tác với một ứng dụng. Tuy nhiên, đôi khi người tìm kiếm có thể thu đượ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 sử dụng thuế MEV thì tất cả MEV từ giao dịch sẽ được quy cho ứng dụng sử dụng 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ụ: nếu một số MEV nhất định chỉ có thể được thu thập bằng cách điền đơn đặt hàng UniswapX thuế MEV đối với AMM 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ẽ được xác định bằng thuế MEV do các ứng dụng đó đặt ra. Nếu giá trị của app_i 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 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 ưu tiên kỳ hạn thứ baPerGas * gasĐược sử dụng để tính phí ưu tiên trả cho người đề xuất khối, nhưng chúng tôi sẽ bỏ qua điều này vì, như đã thảo luận trong Phụ lục A, trong các trường hợp thông thường, chi phí ưu tiên có thể không đáng kể).
Trong trường hợp đơn giản về thuế MEV tuyến tính trong PriorityPerGas (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
Một ứ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ế suất cao hơn cho phép nó chiếm được phần lớn hơn MEV của ứ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 của ứng dụng chéo nếu có sự cạnh tranh phương pháp trích xuất Appmev. 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ó thể đượ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 để chia sẻ MEV theo cách tối đa hóa phúc lợi tương ứng của họ. Ví dụ: AMM Thuế MEV có thể muốn thu thập giá trị từ một nhà giao dịch được thông tin duy nhất ở gần đầu khối, nhưng sau đó muốn cung cấp giá trị đó 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ức phí cố định thấp hơn. Trong trường hợp này, AMM có thể đặt thuế MEV tương đối thấp (ví dụ: 0,00001 USD *ưu tiênFeePerGas ) để các giao dịch chênh lệch giá (nếu có) xảy ra sớm trong khối và sau đó trên các giao dịch tiếp theo trong khối sẽ không bị tính thuế MEV. Các ứng dụng như UniswapX muốn tương tác với AMM có thể đặt thuế MEV cao hơn (chẳng hạn như 0,01 USD * mức ưu tiênFeePerGas) để đảm bảo rằng 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 MEV trong đơn đặt hàng UniswapX, AMM cuối cùng sẽ được phân xử chênh lệch 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à cạm bẫy. Chúng tôi tin rằng đây là những lĩnh vực thú vị cho nghiên cứu trong tương lai.
Khuyến khích không tương thích
Thuế MEV không tương thích với các ưu đãi dành cho những 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ỉ xảy ra nếu những người đề xuất khối tuân theo các quy tắc mà chúng tôi gọi là “ưu tiên cạnh tranh” thay vì tối đa hóa doanh thu của chính họ. Chúng tôi khuyến nghị các quy tắc này bao gồm:
- Ưu tiên: Các giao dịch trong một khối phải được sắp xếp theo thứ tự ưu tiênFeePerGas giảm dần.
- Khả năng chống kiểm duyệt: Nếu người đề xuất khối nhận được giao dịch t 1 khi xây dựng khối và khối không đầy đủ hoặc chứa giao dịch t 2 và t 2.priorityFeePerGas < t 1.priorityFeePerGas, thì khối phải chứa giao dịch t 1 .
- 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 này với bất kỳ ai trước khi gửi khối và họ cũng không được sử dụng nội dung của các giao dịch này để xây dựng giao dịch của riêng mình.
- Không có thời gian đã được hoàn thành. Người đề xuất chặn phải đặt thời gian rõ ràng (blockTime) 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 thuộc tính này bị vi phạm thì hiệu quả của thuế MEV có thể bị giảm sút. Những người đề xuất chặn vi phạm khả năng chống kiểm duyệt có thể tự tận dụng cơ hội bằng cách loại trừ các giao dịch cạnh tranh và gửi giao dịch không có mức độ ưu tiên để tránh hầu hết các loại thuế MEV. Người đề xuất chặn 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ọ và biết mức phí ưu tiên cần được đặt để vượt trội hơn những người khác, trong khi người đề xuất có thể gửi giao dịch muộn hơn những người khác thì Quyền tự do “quyết định cuối cùng” xem có nên trả giá cao hơn người khác hay không sẽ tạo ra những vấn đề lựa chọn bất lợi mà cuối cùng sẽ cản trở sự 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 ở cấp độ giao thức, trình sắp xếp thứ 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 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ư MEV-Boost của mạng chính Ethereum), khối có thể không theo họ.
Những vấn đề này có thể được “giải quyết” bởi một đơn đặt hàng đáng tin cậy duy nhất cam kết xây dựng các khối bằng cách sử dụng ưu tiên cạnh tranh. Nó cũng có thể được giải quyết bằng 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ó lãnh đạo hoặc Đa bội.
Khối hoàn chỉnh
Có những trường hợp ngoại lệ đối với hoạt động bình thường của thuế MEV 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 loại trừ các giao dịch có mức độ ưu tiên thấp thay vì chỉ đưa chúng vào sau trong khối. Vì các giao dịch tương tác với các ứng dụng sử dụng thuế MEV có thể có mứ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ác ứng dụng sử dụng thuế MEV rất thấp. Tuy nhiên, trên một chuỗi sử dụng cơ chế như EIP-1559 để đặt phí cơ sở riêng, việc một khối hoàn toàn đầy là tương đối hiếm. Ngoài ra, do cần phải trì hoãn một số giao dịch khi khối đã đầy, việc trì hoãn những 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 khôi phục
Thuế MEV về cơ bản 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 loại đấu giá này là giá thầu không thành công thường dẫn đến các giao dịch quay vòng được đưa vào chuỗi, phải trả một số phí cơ bản và làm tắc nghẽn chuỗi.
Điều này sẽ giảm bớt vấn đề này nếu trình sắp xếp chuỗi 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 trình sắp xếp tập trung. (Điều này cũng không hoàn toàn tuân thủ đặc tính chống kiểm duyệt được mô tả ở trên, mặc dù định nghĩa đó có thể được điều chỉnh.) 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 các phiên đấu giá tranh chấp mà họ tham gia, từ đó cho phép trình sắp xếp thứ tự để bỏ qua các cuộc đấu giá tranh chấp mà nó biết các giao dịch tiếp theo 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 đặt giá thầu theo dõi, đ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, quyền riêng tư tạm thời bị mất do truyền đi ý định của người dùng trước khi nó được triển khai có thể bị 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 token có tính thanh khoản thấp bằng giao thức đấu giá kéo dài được mô tả ở trên. Cô đăng ý định đã ký vào ví hợp đồng thông minh của mình để mua token trên AMM và đặt ra một số khả năng chịu trượt giá. Người tìm kiếm có thể cạnh tranh trong các giao dịch có mức độ ưu tiên cao để đẩy giá của token đó lên đến mức cho phép trượt giá 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ể thỏa mãn ý định không cạnh tranh của Alice bằng cách bao gồm và hủy bỏ ý định của Alice trong một giao dịch có mức độ ưu tiên thấp, 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ác vấn đề tương tự có thể xảy ra khi mua NFT.
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 token và bán nó cho Alice. Bob ngây thơ có thể trở thành nạn nhân của bẫy “bánh sandwich xé”, trong đó Alice công bố ý định mua một token vô giá trị từ chính mình, khiến Bob mua nó với hy vọng kẹp giao dịch của cô ấy, nhưng Alice đã rút lại ý định của mình trước khi Bob có thể hoàn thành bánh mì 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à chúng có chung ý định và giám sát hành vi của họ, như trường hợp của nhiều phiên đấu giá luồng đơn hàng hiện có.
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ư, chẳng hạn như các tính năng được hình dung trong thiết kế SUAVE của Flashbots.
Cuối cùng, nếu Alice quyết định rằng chi phí chia sẻ ý định của cô ấy lớn hơn lợi ích của việc tìm kiếm cạnh tranh, cô ấy có thể tự mình xây dựng một giao dịch và gửi nó 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ẽ mang lại sự riêng tư trước giao dịch cho những người đề xuất khối.
Thảo luận và làm việc sơ bộ
Đấ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 nhận thấy 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 một “đấu giá gas ưu tiên”, nơi họ đấu thầu để có quyền được đưa vào một khối đầu tiên, dẫn đến phần lớn MEV từ hoạt động chênh lệch giá trên sàn giao dịch phi tập trung được tích lũy cho các thợ mỏ.
Ai đến trước được phục vụ trước. Thông qua các quy tắc đặt hàng giao dịch như trình sắp xếp hiện tại của Themis hoặc Arbitrum One ) để giảm thiểu MEV đã 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 chặn phải đặt hàng các giao dịch theo thứ tự họ nhìn thấy.
Ư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 khoảng 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.
“Trật tự công bằng” 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. Nó cũng có thể dẫn đến lãng phí thời gian chờ và thư rác, ngay cả với một trình sắp xếp chuỗi đáng tin cậy. Cuối cùng, thuế MEV có thể loại bỏ một số MEV “đến trước, được phục vụ trước”, 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 một phần có liên quan đế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) .
Ngoài ra, 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ế các ứng dụng để lấy lại giá trị đó.
Chia sẻ chi phí. Blast là Ethereum L2 và chia sẻ một số 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 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 riêng mình dưới dạng các 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 phương pháp tận dụng các nền tảng ưu tiên cạnh tranh, thay vì thảo luận cách thực thi nó một cách đá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 rộng rãi 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 trong đấu giá trực tuyến mà không có khả năng chống 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 chuỗi 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 sự tin cậy, bao gồm SUAVE của Flashbots, Angstrom của Sorella, Đấu giá không cần lãnh đạo, Timeboost phi tập trung của Espresso và Offchain Labs, và đóng gói giao dịch công khai bắt buộc của Péter Szilági.
Tóm lại là
Chúng tôi hy vọng bài viết này khuyến khích L2 xem xét sử dụng mức độ ưu tiên (được hỗ trợ theo mặc định bởi ngăn xếp OP) và thúc đẩy các ứng dụng thử đánh thuế MEV khi đượ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.
Chú thích cuối bài
- Trong bài viết 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 đưa vào một khối cụ thể. Trên Ethereum L2, vai trò này thường được thực hiện bởi “trình sắp xếp chuỗi”. Trên Ethereum L1, nó được phổ biến bởi một trình xác thực Ethereum cụ thể, được gọi là người đề xuất, mặc dù những người đề xuất thường thuê ngoài nhiệm vụ xây dựng các khối cho các cuộc đấu giá cạnh tranh trong đó “người chuyển tiếp” và “người xây dựng” tham gia. Chi tiết về cách phân chia những trách nhiệm này nằm ngoài phạm vi của bài viết này.
- 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 nó có thể được tính toán trong giao dịch. Giao dịch chỉ định giá Gas, nhưng Ethereum cũng tính phí cơ bản, được lấy từ giá Gas và đốt đi. Đối với thuế MEV, phí cơ bản nên được bỏ qua vì nó nằm ngoài tầm kiểm soát của đại lý. Phí ưu tiên cho mỗi Gas (tức là giá của phần phí giao dịch được chuyển đến người đề xuất khối) có thể được tính trong Solidity dưới dạng PriorityGasPrice = tx.gasprice – block.basefee .
- Chúng tôi có thể chỉ cần định nghĩa “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ẽ chuyển đến trình xác thực.
- Lưu ý rằng người đề xuất PriorityFee thực tế không thể tính bội số của tổng lượng Gas ưu tiên FeePerGas được sử dụng trong giao dịch (bằng tổng lượng Gas được sử dụng trong giao dịch) trong hợp đồng vì không có cách nào để biết cuối cùng giao dịch sẽ sử dụng bao nhiêu Gas. Tuy nhiên, điều này thường 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 của nó. Để đảm bảo an toàn, bạn có thể nhân mức độ ưu tiên FeePerGas với 30 triệu – đây là Gas tối đa hiện tại trong một khối Ethereum. Đánh giá quá cao giá trị này sẽ chỉ có nghĩa là thuế MEV chiếm tỷ trọng lớn hơn trong MEV.
- Giả sử rằng một giao dịch không thể vượt quá 30 triệu Gas, thì PriorityFeePerGas sau đó là 50.000 sẽ dẫn đến khoản thanh toán gas là 1500 gwei – khoảng 0,006 USD với giá ETH là 4000 USD.
- Nếu mức độ ưu tiên FeePerGas được đặt sao cho lợi nhuận của nhà kinh doanh chênh lệch giá bằng 0 thì giao dịch chênh lệch giá tối đa hóa lợi nhuận sẽ tương ứng với cùng một giao dịch trên hàm tối đa hóa AMM.
- Arbitrum đã thảo luận về việc thay thế nó bằng một hình thức ưu tiên gọi là TimeBoost, nhưng tính đến thời điểm viết bài này, nó vẫn chưa được sản xuất.
