Giao thức Ethereum và hệ sinh thái rộng lớn liên tục cố gắng cải thiện giá trị mà Ethereum có thể mang lại. Một rào cản quan trọng trong cả hệ sinh thái để cải thiện Ethereum là Giá trị có thể Trích xuất Tối đa (MEV)MEV). MEV đề cập đến giá trị tối đa mà tác nhân giao thức chịu trách nhiệm bao gồm, đặt hàng và loại trừ các giao dịch trong một khối có thể trích xuất từ hệ thống. Bài đăng này tóm tắt các phương pháp được đề xuất để giảm thiểu tác động tiêu cực của MEV đối với các ứng dụng và giao thức và điều tra các hướng nghiên cứu trong tương lai.

Bài viết này được tổ chức như sau:

Mục đầu tiên đề xuất một phân loại 2 chiều về các kỹ thuật giảm MEV ngoài giao thức. Một ví dụ của mỗi danh mục được khám phá.

Phần tiếp theo khám phá tại sao giao thức Ethereum không thể hoạt động như cơ sở hạ tầng ngăn chặn hoặc hoàn trả MEV.

Thứ ba, chúng tôi khám phá những gì giao thức Ethereum làm để ngăn chặn những tác động bên ngoài tiêu cực của MEV.

Cuối cùng, chúng tôi khẳng định rằng không một trong những kỹ thuật giảm thiểu MEV được thảo luận trong hay ngoài giao thức nào có thể giải quyết đồng thời tất cả các vấn đề do MEV gây ra.

Bài đăng này bắt đầu bằng việc tổng hợp một phần kiến thức về giảm thiểu MEV. Tuy nhiên, phần thứ tư trình bày một luận điểm tương đối mới mẻ rằng giảm thiểu MEV ngoài giao thức không giải quyết được các vấn đề MEV trong giao thức. Luận điểm này dựa trên một giấy bằng cách Davide Crapis và tôi.

Bài viết này đề cập đến các kỹ thuật giảm thiểu MEV trong và ngoài giao thức. Kỹ thuật giảm thiểu MEV trong giao thức đề cập đến cơ chế là một phần của các quy tắc giao thức Ethereum hoặc yêu cầu thay đổi các quy tắc giao thức Ethereum. Các kỹ thuật giảm thiểu MEV ngoài giao thức là tất cả các cơ chế không thuộc giao thức.

Giảm thiểu MEV ngoài giao thức

MEV áp đặt tiền thuê cho người dùng tương tác với một blockchain. Để tăng giá trị mà Ethereum tạo điều kiện, việc giảm tiền thuê mà MEV đại diện là hợp lý. Nhiệm vụ của các kỹ thuật giảm thiểu MEV ngoài giao thức là giảm hiệu ứng làm giảm giá trị mà MEV gây ra mà không thay đổi quy tắc giao thức Ethereum.

Chúng tôi sẽ sử dụng cách MEV được trích xuất trên Trình tạo Thị trường Tự động (AMMs) và, do đó, cách nó có thể được giảm thiểu như một ví dụ. Nhiều AMMs hoạt động như sau:

Nhà cung cấp thanh khoản (LPs) cung cấp nhiều token khác nhau cho một AMM và để cho AMM đặt giá chống lại đó là mà người dùng có thể giao dịch với các token của LP.

Một AMM chỉ điều chỉnh giá của mình dựa trên các giao dịch được bao gồm trong các khối mới. Sự điều chỉnh rời rạc này tương phản với sự biến động giá liên tục của các token cơ bản trên thị trường bên ngoài.

Khi một khối cần được đề xuất, nhà sản xuất khối có thể bao gồm các giao dịch sử dụng giá thị trường bên ngoài có thể quan sát công khai để chênh lệch giá cũ trên AMM, do đó trích xuất MEV.

Hình thức MEV này, được biết đến như Loss-Versus-Rebalancing (LVR), là chi phí cho các nhà cung cấp thanh khoản. Giữ các khoản phí tích lũy cho các nhà cung cấp thanh khoản không đổi, lượng thanh khoản được cung cấp sẽ giảm theo lượng LVR được trích xuất từ AMM. Tính thanh khoản thấp hơn có nghĩa là giao dịch của người dùng có tác động giá cao hơn, có nghĩa là người dùng giao dịch trên AMM sẽ đắt hơn. Mục tiêu của thiết kế AMM là giảm chi phí mà LVR áp đặt lên AMM. Tương tự, mục tiêu của thiết kế ứng dụng, nói chung, là giảm chi phí MEV cho người dùng.

Có nhiều cách để giảm chi phí MEV. Đại khái, các kỹ thuật giảm thiểu MEV ngoài giao thức được chia thành hai trục:

• Các kỹ thuật giảm thiểu MEV hạ tầng cụ thể ứng dụng hoặc chia sẻ.
• Ngăn chặn MEV hoặc hoàn tiền MEV.

Trục đầu tiên là liệu một ứng dụng tự giảm thiểu MEV hay dựa vào một số cơ sở hạ tầng được chia sẻ. Trục thứ hai phức tạp hơn. Một ứng dụng có thể được thiết kế để ngăn chặn việc phơi bày MEV ngay từ đầu, hoặc nó có thể bán quyền trích xuất MEV và giảm giá doanh thu bán hàng cho những người được trích xuất từ đó. Giảm giá MEV hơi lạm dụng định nghĩa của MEV, đó là giá trị mà tác nhân chịu trách nhiệm bao gồm, đặt hàng và loại trừ các giao dịch có thể trích xuất từ hệ thống. MEV được giảm giá không được trích xuất từ hệ thống và do đó không hoàn toàn phù hợp với định nghĩa của MEV. Tuy nhiên, sử dụng thuật ngữ MEV có thể hữu ích vì tất cả các khái niệm liên quan đến MEV đều áp dụng cho giá trị được giảm giá, ngoài doanh thu đi đâu. Chúng ta sẽ xem các ví dụ về cả bốn khả năng và thảo luận về lợi thế tương đối của chúng.

Hình 1: Phân loại 2 chiều của các kỹ thuật giảm thiểu MEV ngoài giao thức với ví dụ cho mỗi danh mục.

Ứng dụng Cụ thể và Ngăn chặn MEV: Chức năng Tối đa hóa AMM.

Kỹ thuật giảm thiểu MEV thường trực quan nhất về mặt khái niệm đối với những người lần đầu tiên nghe về MEV là một ứng dụng ngăn ngừa tiếp xúc với MEV. Một ví dụ thú vị là hàm tối đa hóa AMMđề xuất bởiAndrea Canidio và Robin Fritsch. Nó gom nhóm các giao dịch được thu thập trong một khoảng thời gian và thực hiện tất cả với giá thanh lý đồng đều. Các tác giả cho thấy rằng nó loại bỏ LVR và sandwiching, một dạng MEV khác. Sự hiểu biết là tất cả các thành viên thực hiện giao dịch với giá biên của hồ sau quá trình gom nhóm và các nhà giao dịch lợi ích được khuyến khích giao dịch cho đến khi giá này bằng giá thị trường bên ngoài. Hệ thống này tương tự như một phiên đấu giá gom nhóm thường xuyên được đề xuất bởi gate.Budish, Cramton và Shim (2015)trong tài chính truyền thống văn học. Như một lời nhắc nhở, đó là một ví dụ tuyệt vời về sự kết hợp giữa tài chính phi tập trung và tài chính truyền thống. Các ý tưởng tài chính truyền thống có thể được thực hiện trong tài chính phi tập trung; gatenhững kinh nghiệm từ việc triển khai sau đó có thể được sử dụng để thông báo tài chính truyền thống.

Ứng dụng cụ thể và Rebating MEV: Các AMM nắm bắt MEV.

Cửa chínhMEV bắt giữ AMM (McAMM) là một ví dụ về giảm thiểu MEV dành riêng cho ứng dụng dựa trên giảm giá. McAMM đấu giá quyền trở thành nhà giao dịch đầu tiên tương tác với AMM trong một khối, do đó cho phép nhà giao dịch này trích xuất một chênh lệch giá có thể. Số tiền bán đấu giá sau đó được phân phối giữa các nhà cung cấp thanh khoản chênh lệch. Nếu cuộc đấu giá có hiệu quả, số tiền thu được phải bằng giá trị chênh lệch giá được trích xuất từ các nhà cung cấp thanh khoản. Thiết kế này có thể dẫn đến việc loại bỏ LVR giống như chức năng tối đa hóa AMM được thảo luận ở trên, mặc dù cách tiếp cận hoàn toàn khác nhau. Liệu điều này có xảy ra trong thực tế hay không phụ thuộc rất nhiều vào việc thực hiện cụ thể của cuộc đấu giá.

Cơ sở hạ tầng và hoàn tiền MEV: MEV-Share.

Giảm giá không nhất thiết phải dành riêng cho một ứng dụng. Flashbots, một công ty hoạt động trong không gian xây dựng khối, đã phát triển MEV-Chia sẻ. Nó cho phép người dùng lựa chọn dữ liệu giao dịch muốn chia sẻ trong một phiên đấu giá một cách riêng tư. Người đấu giá đấu giá để có quyền đặt giao dịch này vào một gói và từ đó chiết xuất MEV từ đó. Người dùng có thể nhận được thu nhập từ phiên đấu giá. Cơ sở hạ tầng này không chỉ đặc thù cho ứng dụng cụ thể, vì giao dịch có thể tương tác với bất kỳ ứng dụng nào.

Cơ sở hạ tầng và ngăn chặn MEV: Luồng lệnh bảo vệ trong một thế giới tìm lợi nhuận.

Cuối cùng, có các cơ chế cơ sở hạ tầng nhằm ngăn chặn khai thác MEV. Một ví dụ là Protected Order-Flow in a Profit-Seeking World (PROF).PROF dựa trên một nhà sản xuất khối trong Môi trường Thực thi Đáng tin cậy (TEE) mà cam kết đáng tin cậy theo một quy tắc sắp xếp, ví dụ, đến trước đến trước phục vụ. TEE có hai thuộc tính quan trọng làm cho cam kết đáng tin cậy, đó là:

• [ ] Tính toàn vẹn: mã và dữ liệu trong TEE không thể được sửa đổi hoặc can thiệp, trong quá trình thực thi hoặc khi lưu trữ, bởi các thực thể bên ngoài như hệ điều hành, hypervisor, hoặc các đối tượng độc hại.
• [ ] Bảo mật: dữ liệu và tính toán bên trong TEE vẫn ở chế độ riêng tư và không thể truy cập được đối với các thực thể trái phép, bao gồm hệ thống máy chủ, các ứng dụng khác hoặc kẻ tấn công.

Bất kỳ người dùng nào gửi giao dịch của mình cho một nhà sản xuất khối cam kết thực hiện một quy tắc sắp xếp biết rằng nhà sản xuất khối trong TEE sẽ làm như vậy. Do đó, PROF có thể ngăn chặn một số loại trích xuất MEV cụ thể, như front-running cho bất kỳ ứng dụng nào, mà không thay đổi quy tắc giao thức Ethereum.

Các kỹ thuật giảm MEV khác nhau có những ưu điểm và nhược điểm khác nhau. Các kỹ thuật ngăn chặn MEV cụ thể cho từng ứng dụng khó tìm thấy vì yêu cầu nhiều nghiên cứu và công việc triển khai cho từng ứng dụng. Mặt khác, ngăn chặn MEV cơ sở hạ tầng yêu cầu nhiều công việc phụ trợ. Ví dụ, một số kỹ thuật ngăn chặn MEV cơ sở hạ tầng yêu cầu chạy phần cứng đắt tiền và phát triển kinh doanh đáng kể. Việc áp dụng hoàn trả hiệu quả phụ thuộc rất nhiều vào việc phiên đấu giá có cạnh tranh hay không, điều này phụ thuộc vào các yếu tố cụ thể của phiên đấu giá như định dạng và thời gian diễn ra.

Bốn kỹ thuật giảm thiểu MEV này có thể không đầy đủ và cũng không loại trừ hoàn toàn lẫn nhau. Cũng lưu ý rằng kích thước giống với quang phổ chứ không phải nhị phân, như thể hiện trong Hình 1. Ví dụ, một số kỹ thuật giảm thiểu MEV có thể mang tính cơ sở hạ tầng nhiều hơn những kỹ thuật khác. Trường di chuyển rất nhanh, điều này làm cho bất kỳ phân loại nào cũng trở nên khó khăn. Cuối cùng, không gian cảm thấy lạc quan và nhiều người có thể chia sẻ ý kiến rằng MEV theo tỷ lệ phần trăm của tổng giá trị được tạo điều kiện sẽ nhanh chóng co lại.

Thiếu việc giảm thiểu MEV trong giao thức

Những kỹ thuật giảm thiểu MEV này có vẻ không đạt yêu cầu đối với một số người. Tại sao Ethereum không thể là cơ sở hạ tầng giao thức giải quyết MEV một cách toàn diện? Có lẽ một số độc giả sẽ đề nghị sử dụng một quy tắc đặt hàng cụ thể. Các đề xuất để thực thi một quy tắc đặt hàng cụ thể trong Ethereum, chẳng hạn như first-come-first-serveChưa nhận được sự ủng hộ rộng rãi. Tôi tin rằng có hai lý do cơ bản mà giao thức không thể giải quyết một cách toàn diện gánh nặng MEV đặt lên người dùng cuối và ứng dụng - cả hai đều liên quan đến ràng buộc trung lập đáng tin cậy của Ethereum.

Đầu tiên, Ethereum không thể có được một trật tự toàn cầu chuyển tiếp thỏa mãn “sự công bằng”. Ethereum lưu trữ nhiều ứng dụng khác nhau mà mỗi ứng dụng có thể được hưởng lợi từ các loại quy tắc đặt hàng khác nhau. Mặc dù đặt hàng đến trước, phục vụ trước có thể giúp một số ứng dụng, nhưng nó có thể ức chế sự phát triển của người khác. Do đó, rất khó để hệ sinh thái thống nhất về những gì là công bằng. Bên cạnh đó, ngay cả khi hệ sinh thái đồng ý về một quy tắc đặt hàng công bằng, rất khó để có được quy tắc đặt hàng chuyển tiếp toàn cầu vì một giao dịch có thể đến các nút khác nhau vào những thời điểm khác nhau.

Những không nhất quán này gây ra vấn đề trong giao thức đặt hàng theo thứ tự đến trước, phục vụ trước. Cụ thể, ngay cả khi thứ tự mà các nút cá nhân nhận các giao dịch là có tính chất chuyển tiếp, điều đó không có nghĩa là thứ tự tổng hợp cũng có tính chất chuyển tiếp. Quy tắc đặt hàng theo thứ tự đến trước, phục vụ trước có thể bị kẹt đinh trong chu kỳ để khôi phục tính chuyển tiếp, và đôi khi, những chu kỳ này phải được giải quyết bằng một quy tắc tùy ý, như chọn một thứ tự tổng quát theo bảng chữ cái. Điều này có thể có nghĩa là các giao dịch mà quy tắc đặt hàng theo thứ tự đến trước, phục vụ trước quan trọng nhất, như giao dịch cơ hội thời gian, không được sắp xếp theo cách này mà là tùy ý.

Hình 2: Slide cho thấy các quy tắc sắp xếp theo thứ tự đến trước, phục vụ trước có thể bị kẹt lại trong các chu kỳ Condorcet. Slide được lấy từ bài thuyết trình về Themis của Mahimna Kelkar.

Ngoài việc rằng quy tắc đặt hàng theo thứ tự đến trước, phục vụ trước có vấn đề lý thuyết, điều đó là không rõ ràngCho dù chúng có được ưa chuộng hay không ngay từ đầu. Quy tắc đặt hàng này có lợi cho những người có kết nối nhanh hơn. Nếu kết nối nhanh đủ giá trị, điều này có thể dẫn đến một cuộc đua độ trễ, như đã thấy trong tài chính truyền thốngvới những đầu tư lớn vào công nghệ tốc độ. Công nghệ tốc độ có thể gây hại đến tính trung lập đáng tin cậy trong các chuỗi khối vì nó khuyến khích tập trung địa lý.

Quan điểm không nhất quán về thời điểm giao dịch đến gây ra vấn đề cho quy tắc đặt hàng ai đến trước được phục vụ trước và cho mọi quy tắc đặt hàng. Các quy tắc đặt hàng thường nhằm mục đích đạt được một số tính chất kinh tế. Ví dụ, đặt hàng khí ưu tiên tìm cách bao gồm các giao dịch đó theo thứ tự bao nhiêu chúng có giá trị được đưa vào đầu tiên. Thông thường, các desiderata kinh tế này chỉ được thực hiện nếu có một cái nhìn toàn cầu về các giao dịch nên được đặt hàng. Vì rất khó để có được một cái nhìn toàn cầu chuyển tiếp từ các quan điểm địa phương chuyển tiếp, nên rất khó để có được một cái nhìn toàn cầu như vậy. Nói cách khác, một số trình xác thực sẽ nghĩ rằng một giao dịch nên được đặt hàng trong một vị trí và những người khác nghĩ rằng nó nên nằm trong một vị trí khác, làm suy giảm các đặc tính kinh tế mà hệ sinh thái có thể mong đợi nhận được từ một quy tắc đặt hàng cố định.

Thứ hai, giao thức đồng thuận không hề biết về các trò chơi MEV được chơi trên lớp thực thi. Điều này sẽ làm cho việc thiết kế một kế hoạch hoàn tiền trong giao thức trở nên khó khăn vì giao thức hiện tại sẽ không hiểu MEV là giá trị gì và phải hoàn tiền cho ai. Cuối cùng, giao thức phải duy trì tính trung lập đáng tin cậy. Nó không nên ở trong tình huống mà nó phải đưa ra một lựa chọn có quan điểm về việc hoàn tiền MEV ngay cả khi nó có thể, cũng không nên chọn các kỹ thuật ngăn chặn MEV mà ưa thích ứng dụng cụ thể hơn những ứng dụng khác.

Một ví dụ thú vị gần giống một kỹ thuật hoàn trả MEV trong giao thức là Thuế MEV, được đề xuất bởi Dan RobinsonvàDave White. Nó cho phép bất kỳ ứng dụng nào quá tải phí ưu tiên trong giao thức bằng cách thiết lập một tham số, ví dụ $k$. Bất kỳ người dùng nào tương tác với ứng dụng sau đó phải trả $k$ lần phí ưu tiên mà họ đã trả cho người xác nhận đồng thuận cho ứng dụng. Bạn có thể thấy cách mà hệ thống này có thể hoàn trả doanh thu MEV cho ứng dụng một cách tổng quát. Ví dụ, nếu có 10 ETH MEV được trích xuất từ một ứng dụng, với $k = 9$, bằng cách là người đầu tiên tương tác với nó, người dùng có thể trả phí ưu tiên là 1 ETH cho người xác nhận và 9 ETH cho ứng dụng, miễn là các giao dịch được sắp xếp theo phí ưu tiên.

Thuế MEV là một hướng phát triển hứa hẹn, nhưng như được nêu bởi tác giả, nó cần được khám phá thêm để hiểu cách nó hoạt động trên Ethereum. Một khía cạnh khó khăn có thể là thuế MEV cho rằng phí ưu tiên là tín hiệu chung cho lượng MEV. Mặc dù điều này có thể đúng nếu có một trật tự ưu tiên được áp dụng, nhưng chính việc sắp xếp có thể làm giảm tổng lượng MEV, tương tự như cách một phiên đấu giá giá đầu tiên đa đơn vị có thể có doanh thu thấp hơn so với một phiên đấu giá kết hợp. Flashbots’SUAVEdường như đang tiến theo hướng ngược lại, cho phép các lựa chọn biểu đạt hơn. SUAVE hiện tại chưa hoạt động nhưng nhằm xây dựng một công cụ xây dựng khối phi tập trung tổng hợp gói một cách tối ưu mà không có quy tắc đặt hàng cụ thể.

Các khoản phí ưu tiên có thể không phản ánh tốt MEV khi người tìm kiếm muốn diễn đạt sự ưu tiên của họ để được bao gồm theo cách phức tạp hơn so với khoản phí ưu tiên một chiều. Có thể người tìm kiếm muốn được bao gồm trong khối trước các gói tìm kiếm cạnh tranh khác nhưng không quan tâm đến vị trí tuyệt đối trong khối. Sử dụng khoản phí ưu tiên sẽ có nghĩa là người tìm kiếm cạnh tranh vị trí với tất cả người dùng, bất kể sự liên quan của họ đối với người tìm kiếm này.

Có những cách khác để giảm MEV được rút ra từ người dùng ngoài việc đặt ra các quy tắc. Một hướng nghiên cứu khác là mempools được mã hóaĐiều này có nghĩa là người dùng phát sóng giao dịch dưới dạng mã hóa. Chỉ sau khi giao dịch được bao gồm thì giao dịch mới được giải mã. Do đó, nhà sản xuất khối không biết nội dung của giao dịch, làm cho việc tiến hành giao dịch front-run dựa trên dữ liệu đã được che giấu trở nên không thể.

Các bể nhớt được mã hóa hoạt động trên Gnosis Chain, một chuỗi khối có cấu trúc tương tự Ethereum. Các cộng tác viên hệ sinh thái, đặc biệt là Mạng Shutter, nhằm mang các mempools được mã hóa đến Ethereum mainnet. Một số yếu tố giới hạn hiện tại là các giả định về sự tin tưởng cần thiết với các kỹ thuật mật mã dựa trên ngưỡng, trạng thái của chức năng trì hoãn có thể xác minh, và vấn đề sẵn có dữ liệu miễn phíliên quan đến mempools được mã hóa.

Tóm lại, Ethereum không thể là cơ sở hạ tầng ngăn chặn MEV vì hệ sinh thái chưa thể đồng ý về quy tắc đặt hàng công bằng và vì khó đạt được trật tự toàn cầu chuyển tiếp với bất kỳ quy tắc đặt hàng nào. Một số đề xuất cho các quy tắc đặt hàng, như ví dụ về thuế MEV được đưa ra ở trên và nâng cấp giao thức, đã được thảo luận có thể tạo điều kiện thuận lợi cho một trật tự toàn cầu chuyển tiếp thỏa mãn “sự công bằng”. Tuy nhiên, hiện tại không có sự đồng thuận sơ bộ về việc đây là những điều mong muốn. Ethereum không thể là cơ sở hạ tầng giảm giá MEV vì lớp đồng thuận không biết điều gì xảy ra trên lớp thực thi và Ethereum không thể chọn giữa các ứng dụng vì nó phải trung lập.

Giao thức làm gì?

Đoạn trước cho thấy giao thức khó khăn như thế nào để loại bỏ gánh nặng MEV đặt lên người dùng. Tuy nhiên, nhiều cơ chế giao thức xử lý MEV và toàn bộ phần của lộ trình của Vitalikđược dành riêng cho nó. Các cơ chế này làm gì?

Các cơ chế trong giao thức này nhằm giải quyết một vấn đề khác với các kỹ thuật giảm thiểu đã thảo luận trước đây. Thay vì tối đa hóa giá trị Ethereum tạo điều kiện bằng cách giảm thiểu MEV được trích xuất từ người dùng, các cơ chế trong giao thức nhằm mục đích tối đa hóa tính trung lập đáng tin cậy của Ethereum bằng cách giảm thiểu các ngoại ứng tiêu cực của MEV. MEV không chỉ làm giảm tiện ích của những người được chiết xuất, nó còn làm biến dạng rất nhiều hành vi của người khai thác, ví dụ, nó khuyến khích tập trung hóa thông qua tính kinh tế theo quy mô và nguyên nhân sự không ổn định về đồng thuận.

Các yếu tố kinh tế là một rủi ro tập trung lớn cho sự đồng thuận của Ethereum và qua đó là sự trung lập đáng tin cậy của nó. Nếu có kinh tế quy mô, các đại lý đồng thuận nhỏ có thể kỳ vọng sáp nhập với các đại lý lớn để được hưởng lợi. Nếu có lợi nhuận cho sự tinh vi, những người xác thực hợp lý có thể cư xử khác với các thông số kỹ thuật trung thực. Kinh tế quy mô hoặc lợi nhuận cho các đại lý đồng thuận là những tác động bên ngoài tiêu cực của MEV.

Giao thức nhằm mục tiêu ngăn chặn hệ quả tiêu cực bằng cách tách ra các vai trò mà các đại lý đồng thuận có trong Ethereum và tạo tường lửa giữa chúng. Hiện nay, Ethereum gán tất cả các vai trò sau cho một đại lý, nhưng về nguyên tắc, đây là những vai trò riêng biệt. Ba vai trò đã được xác định cho đến nay là như sau:

• [ ] Chứng thực thông tin cần thiết để đạt được sự nhất quán và tạo ra các khối nhất quán là vai trò quan trọng nhất trong hệ thống nhất quán Proof-of-Stake của Ethereum. Ví dụ bao gồm việc chứng thực đến đầu chuỗi, chứng thực đến tính đúng giờcủa các tin nhắn và tạo các khối đồng thuận khi cần thiết. Phần thưởng cho những vai trò này khá đồng nhất đối với tất cả các thành viên tham gia.
• [ ] Đề xuất khối thực thi. Vai trò này đảm bảo tính sống còn của lớp thực thi. Nó có thể bao gồm việc nộp đúng hạn các gói dữ liệu thực thi và phân bổ hiệu quả quyền xây dựng gói dữ liệu thực thi. Phần thưởng cho vai trò này phụ thuộc vào khả năng chịu đựng rủi ro và tốc độ của người tham gia.
• [ ] Xây dựng khối thực thi. Vai trò này quyết định thứ tự thực hiện giao dịch trong một tải trọng thực thi. Nó có tiềm năng lớn để trích xuất MEV từ hệ thống, và có sự đa dạng rất lớn về phần thưởng giữa các thành viên. Sự kinh tế được liên kết với vai trò này có quy mô lớn, rào cản cao và tính phức tạp. Do đó, phần thưởng rất đa dạng đối với các thành viên.

Hệ sinh thái Ethereum nhằm cô lập ba vai trò này sao cho động lực xuất phát từ một vai trò không ảnh hưởng đến động lực của những người thực hiện vai trò khác. Một số vai trò, như sắp xếp giao dịch, có thể tập trung hơn miễn là xác thực khối là không đáng tin cậy và cực kỳ phi tập trung, và một nhóm người tham gia phi tập trung có thể đảm bảo chống lại sự kiểm duyệt, như Vitalik đã nói trong bài viết ảnh hưởng của mình.Bài đăng cuối cùng.

Tách Biệt Người Đề Xuất-Vận Động Viên (PBS)được thiết kế nhằm phân chia các vai trò của việc đề xuất và xây dựng gói thực thi. Đây là một triết lý thiết kế nhận thức các vai trò khác nhau và tạo điều kiện cho việc giao cho một bên chuyên môn nhiệm vụ xây dựng khối của người đề xuất. MEV-Boost là sự thể hiện hiện nay của PBS ngoài giao thức. Nó cho phép tất cả người đề xuất, bất kể sự tinh vi, truy cập vào các thị trường MEV giống nhau. Cụ thể, nó đảm bảo rằng người xây dựng nhận quyền xây dựng khối và người đề xuất nhận được tiền thanh toán cho việc bán quyền này. Với MEV-Boost, người đề xuất không có lợi hơn bằng cách đầu tư vào các kỹ thuật khai thác MEV tinh vi mà có thể giữ một sự tinh vi tương đối trong lĩnh vực này và tận hưởng các phần thưởng tương tự như những người đề xuất tinh vi hơn.

Tách rời Người chứng thực và Người đề xuất (APS)được xem như là tương tự về khái niệm với PBS. Nó cũng nhận ra sự khác biệt giữa hai vai trò: xác nhận và đề xuất các khối đồng thuận và đề xuất các khối thực thi. APS hiện đang trong giai đoạn nghiên cứu và chưa có phiên bản ngoài giao thức nào được phát hành. Người đề xuấtcó thể muốn nhanhvì nó cho phép họ gửi khối của họ sau, điều này có nghĩa họ có thể bao gồm nhiều giao dịch hơn. Điều quan trọng đối với giao thức đồng thuận là không khuyến khích độ trễ vì nó dẫn đến tập trung địa lý. APS đôi khi được xem như là đường phòng thủ cuối cùng cho giao thức Ethereum.

PBS và APS cho thấy ba vai trò này có thể được cô lập. Tuy nhiên, việc triển khai hai cải tiến giao thức này cũng có nghĩa là người tham gia tạo khối sẽ rất tập trung, điều này rất tồi tệ đối với sự chống cenzor. Ethereum nhắm mục tiêu vượt qua những vấn đề này bằng cách xây dựng van một chiều giữa các vai trò này. Giao thức có thể quá tải vai trò chứng minh cho các khối với vai trò chứng minh cho các giao dịch đang chờ xử lý trong mempool. Một ủy ban của những người chứng minh sau đó sẽ chịu trách nhiệm tạo ra một danh sách các giao dịch mà người sản xuất khối phải bao gồm, nếu không thì khối của họ sẽ bị bỏ qua bởi những người chứng minh. Những loại cơ chế như vậy được gọi là danh sách bao gồm.

Những van này thách thức việc phân chia các vai trò. Nó là rất khó để thiết kếvan điều khiển mà sử dụng ý nghĩa của một nhóm người tham gia cụ thể, ví dụ như hạn chế nhóm người tham gia khác, đồng thời đảm bảo những người tham gia ở phía kia của van không ảnh hưởng đến những người tham gia ảnh hưởng đến họ. Ví dụ, nhóm người xác nhận phi tập trung sẽ chịu trách nhiệm tạo ra một danh sách bao gồm. Chúng tôi không muốn nhà sản xuất khối hoặc những động lực tập trung liên quan đến sản xuất khối ảnh hưởng đến những người xác nhận.

Hình 3: Phân chia lao động bởi Attester-Proposer Separation (APS) và Proposer-Builder Separation (PBS) với danh sách bao gồm và bán quyền xây dựng như van một chiều giữa các vai trò.

Không có một giải pháp duy nhất cho hai vấn đề riêng biệt

Mục tiêu chính của các cơ chế MEV trong giao thức khác biệt hoàn toàn so với các kỹ thuật giảm thiểu MEV ứng dụng và cơ sở hạ tầng. Các kỹ thuật giảm thiểu ngoài giao thức nhằm giảm MEV trên mỗi đơn vị giá trị được thúc đẩy. Ngược lại, các kỹ thuật giảm thiểu trong giao thức nhằm ngăn chặn các tác động tiêu cực của MEV làm tập trung các đại lý đồng thuận của Ethereum. Các kỹ thuật giảm thiểu MEV cụ thể có thể góp phần đối với cả hai mục tiêu. Ví dụ, MEV-Boost kỹ thuật ngoài giao thức, nhưng mục tiêu duy nhất của nó là ngăn chặn các tác động tiêu cực của MEV.

Ngoài ra, các ràng buộc trong hai vấn đề là khác nhau. Cơ chế trong giao thức phải được thiết kế với yêu cầu phần cứng và một giao thức trung lập. Ngược lại, các ràng buộc của các kỹ thuật giảm thiểu MEV ngoài giao thức phụ thuộc vào những mong muốn của các nhà thiết kế ứng dụng hoặc cơ sở hạ tầng, có thể phù hợp với một trường hợp sử dụng cụ thể.

Vì những vấn đề này có mục tiêu và ràng buộc khác nhau, nên dễ hiểu rằng không có một giải pháp duy nhất có thể giải quyết cả hai. Hơn nữa, có thể có một sự chia rẽ cơ bản hơn giữa hai vấn đề này. Phần này phác thảo một lập luận cho sự chia rẽ này, cũng được trình bày trong một,bài báo của Davide Crapis và tôi.

Các nhà thiết kế ứng dụng muốn giảm MEV mỗi đơn vị giá trị vì điều này sẽ thu hút nhiều người dùng hơn và do đó tăng tổng giá trị mà các ứng dụng này tạo điều kiện cho. Nếu MEV mỗi đơn vị giá trị giảm nhưng tổng giá trị tạo điều kiện tăng, tổng số MEV có thể giảm nhưng cũng có thể tăng. Các cơ chế MEV trong giao thức quan tâm đến tổng số MEV mà các đại lý đồng thuận có thể trích xuất. Ngay cả khi tổng số MEV chỉ chiếm một phần nhỏ của giá trị mà Ethereum tạo điều kiện, không rõ liệu giao thức có cần phải ngăn chặn vai trò đồng thuận khác nhau cần thiết để ngăn chặn sự tập trung trong các thành viên đồng thuận của Ethereum hay không.

Làm ví dụ cho lập luận này, hãy xem xét trường hợp của Mất cân đối so với cân đối lại(LVR), được giới thiệu sớm hơn là sự mất mát cơ hội chênh lệch thời gian phản ứng của các nhà cung cấp thanh khoản trong AMM vì báo giá trên chuỗi của họ vẫn cũ ngỏm giữa các khối so với thị trường bên ngoài cập nhật liên tục. Trong công việc của họ, Milionis và cộng sự tìm thấy rằng tổng LVR trong một khe cắm tỉ lệ với thời gian khe cắm có sức mạnh của 3/2.

Khi kiểm tra ban đầu, điều này cho thấy việc giảm thời gian khe cắm cũng làm giảm MEV. Tuy nhiên, LVR là tổn thất thương mại cơ học trên mỗi đơn vị thanh khoản. Hơn nữa, Joel Hasbrouck, Thomas Rivera và Fahad Salehhiển thịVị trí LP cá nhân có thể được coi là tài sản có thể đầu tư. Lợi nhuận dự kiến của tài sản thường dựa trên rủi ro của chúng. Không rõ là rủi ro của vị trí LP sẽ thay đổi như thế nào khi thời gian khe cắm giảm, nhưng vì lợi ích của cuộc tranh luận, hãy giả sử nó ổn định. Sau đó, lợi nhuận của vị trí LP sẽ không thay đổi bất kể thời gian khe cắm; do đó, nếu chi phí cho mỗi đơn vị thanh khoản giảm, doanh thu cho mỗi đơn vị thanh khoản cũng phải giảm. Trong AMM, doanh thu sẽ giảm vì có nhiều thanh khoản chảy vào AMM. Nhiều thanh khoản có nghĩa là nhiều đơn vị thanh khoản đối mặt với LVR. Do đó, hiệu ứng tổng hợp là mơ hồ. Vì vậy, không rõ là lượng MEV tổng cộng phát sinh từ LVR sẽ thay đổi như thế nào nếu thời gian khe cắm thay đổi, mặc dù MEV cho mỗi đơn vị giá trị có thể giảm.

Ngoài ra, việc giảm LVR sẽ làm cho AMM trở thành nơi hấp dẫn hơn để giao dịch vì có tính thanh khoản cao hơn, có nghĩa là nhiều nhà giao dịch trả phí sử dụng AMM hơn, dẫn đến thanh khoản thậm chí còn nhiều hơn. Ngoài ra, trải nghiệm người dùng được hưởng lợi từ thời gian khe ngắn hơn và tổng lượng MEV bắt nguồn từ LVR có thể tăng theo thời gian khe cắm. Đây là vấn đề đối với giao thức, mặc dù người dùng tận hưởng các giao dịch hiệu quả hơn.

Bảng 1: Tác động của thời gian khe trên LVR, lượng thanh khoản và tổng MEV. Bảng này cho thấy cách thời gian khe ảnh hưởng đến LVR mỗi khe và tỷ lệ tăng gấp đôi thanh khoản. Nó giả định rằng doanh thu phí không đổi và chi phí cơ hội mỗi khe là không. Kết quả được chuẩn hóa với các giá trị tương ứng với thời gian khe 12 giây được sử dụng như một điểm chuẩn.

Bảng 1 cho thấy tổng số lượng MEV phát sinh từ LVR có thể giữ nguyên ngay cả khi thời gian khe cắm giảm. Các giá trị trong bảng này được tạo ra dựa trên giả định rằng phí là nguồn thu duy nhất, gian lận độ trễ là chi phí duy nhất đối với nhà cung cấp thanh khoản, và chi phí cơ hội cho mỗi khe cắm giữ nguyên ở mức không đổi. Những giả định này quá đơn giản. Do đó, những con số này có thể đưa ra giới hạn trên sự tăng thanh khoản mỗi khe cắm và do đó, trên tổng số lượng MEV.

Khó nói liệu những dự đoán này sẽ được duy trì như thế nào. Hệ sinh thái ít biết về động cơ và cân nhắc rủi ro-thưởng của nhà cung cấp thanh khoản và thậm chí ít hơn về hành vi của các nhà giao dịch thanh khoản. Có lẽ LP xem xét rủi ro của các vị trí LP khác nhau tùy thuộc vào thời gian khe cắm, điều này có thể giúp dự đoán điều gì xảy ra với tổng lượng MEV khi thời gian khe giảm.

Có thể, ví dụ này có thể được tổng quát hóa. Các kỹ thuật giảm thiểu MEV ngoài giao thức nhằm mục tiêu tối thiểu hóa MEV mỗi đơn vị giá trị đồng thời tạo ra nhiều giá trị hơn chảy qua hệ thống; do đó, tác động của việc giảm thiểu MEV lên tổng số MEV là mơ hồ. Do đó, tôi tin rằng Ethereum không thể phụ thuộc vào việc giảm thiểu MEV ngoài giao thức để ngăn chặn những tác động tiêu cực của MEV đối với các nhà đồng thuận.

Thông báo từ chối trách nhiệm:

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