Vấn đề này khá dài, để tiện theo dõi, bạn có thể xem trước danh mục:

Đánh giá: Giá trị trích xuất tối đa MEV là gì

Phần 1: MEV trong Ethereum POS

Tập trung trình xác nhận

Nhóm bộ nhớ được cấp phép

chữ

Proposer -Builder Separation

chữ

Builder API

API Builder giảm thiểu tác động của MEV như thế nào?

Phần 3: MEV có phải là duy nhất đối với Ethereum không?

Phần 4: MEV tuân theo sự phức tạp

chữ

Phần 5: Vì sao MEV khó sửa

Ở phần đầu của văn bản, trước hết, hãy xem lại MEV là gì với một ví dụ?

• Ví dụ: có cơ hội chênh lệch giá 10.000 đô la trên Uniswap sau khi một số lượng lớn giao dịch khiến giá trượt. Bot chênh lệch giá nhận thấy cơ hội và gửi một giao dịch để nắm bắt nó, cung cấp cho người khai thác phí giao dịch 10 đô la. Một trong hai điều có thể xảy ra:

• Những người khai thác sẽ sao chép và kiểm duyệt các giao dịch của các nhà kinh doanh chênh lệch giá để tự mình nắm bắt cơ hội

10,Các bot khác sẽ chú ý và đặt giá thầu txfee cao hơn, bắt đầu cuộc chiến đấu thầu để giành quyền chênh lệch giá. Cuộc đấu giá được gọi là "Đấu giá khí ưu tiên" (PGA)

Lợi nhuận tiềm năng $000 là MEV. Nếu người khai thác không nắm bắt được nó và PGA bắt đầu, thì chênh lệch giữa giá đấu giá và tổng MEV có sẵn là lợi nhuận của người giao dịch chiến thắng (ví dụ: nếu người khai thác được trả 7.000 đô la phí, 3.000 000 còn lại dành cho người giao dịch).Trong loạt MEV củabài viết đầu tiên

Ở đây chúng tôi đã giới thiệu chi tiết về hình thức MEV và tác động của nó, sau đó chúng tôi tiếp tục thảo luận về tác động của MEV đối với Ethereum.

Phần.1 MEV trong Ethereum PoS

Các nhóm đặt cược lớn hơn có thể có nhiều nguồn lực hơn để đầu tư vào các hoạt động tối ưu hóa cần thiết nhằm nắm bắt các cơ hội MEV. Các nhóm khai thác càng nhiều MEV, họ càng có nhiều tài nguyên để tăng khả năng khai thác MEV (và tăng doanh thu tổng thể), về cơ bản là tạo ra quy mô kinh tế. Những người đặt cược độc lập có thể không thu được lợi nhuận từ cơ hội MEV do họ có ít tài nguyên hơn. Điều này có thể gây áp lực lên những người xác thực độc lập tham gia vào các nhóm đặt cược mạnh để tăng doanh thu, giảm sự phân mảnh của Ethereum.

Nhóm bộ nhớ được cấp phép

Để đối phó với các cuộc tấn công bánh sandwich và tấn công chạy trước, các nhà giao dịch có thể bắt đầu thực hiện các giao dịch ngoại tuyến với trình xác thực để bảo vệ quyền riêng tư của giao dịch. Thay vì gửi các giao dịch MEV tiềm năng đến một mempool công khai, các nhà giao dịch gửi chúng trực tiếp đến những người xác thực, những người này sẽ đưa chúng vào một khối và chia sẻ lợi nhuận với các nhà giao dịch.

“Các vùng tối” là một phiên bản mở rộng của sự sắp xếp này, hoạt động như các vùng bộ nhớ chỉ dành cho quyền truy cập, được phép mở cho những người dùng sẵn sàng trả phí. Xu hướng này sẽ làm cho Ethereum ít bị cho phép và không được tin cậy hơn, đồng thời có khả năng biến chuỗi khối thành một cơ chế “trả tiền để chơi” có lợi cho người trả giá cao nhất. Các mempool được phép cũng đẩy nhanh các rủi ro tập trung được mô tả trong phần trước. Các nhóm lớn chạy nhiều trình xác nhận có thể hưởng lợi từ việc cung cấp quyền riêng tư giao dịch cho thương nhân và người dùng, do đó tăng doanh thu MEV của họ.

Giải quyết các vấn đề liên quan đến MEV này trong một Ethereum hợp nhất là một lĩnh vực nghiên cứu cốt lõi. Cho đến nay, để giảm tác động tiêu cực của MEV đối với việc phân cấp và bảo mật của Ethereum sau khi sáp nhập, hai giải pháp đã được đề xuất, đó là Tách Người đề xuất-Người xây dựng (PBS) và API Builder.

Proposer-Builder Separation  

tiêu đề phụ

Tách người đề xuất-người xây dựng (PBS) nhằm mục đích giảm thiểu tác động của MEV, đặc biệt là ở lớp đồng thuận. Tính năng chính của PBS là tách biệt các quy tắc của nhà sản xuất khối và người đề xuất khối (Proposer). Người xác nhận vẫn chịu trách nhiệm về đề xuất khối và biểu quyết; nhưng người xây dựng khối — người xây dựng khối — chịu trách nhiệm đặt hàng giao dịch và xây dựng khối.

Trong PBS, trình tạo khối tạo gói giao dịch và đặt giá thầu để nó được đưa vào khối chuỗi đèn hiệu (dưới dạng "tải trọng thực thi"). Trình xác thực đề xuất khối tiếp theo được chọn, sau đó kiểm tra các giá thầu khác nhau và chọn gói giao dịch có phí cao nhất. Về cơ bản, PBS tạo ra một thị trường đấu giá nơi các nhà xây dựng thương lượng với những người xác thực để bán không gian khối.

Thiết kế PBS hiện tại sử dụng sơ đồ cam kết tiết lộ, trong đó các nhà xây dựng chỉ công bố cam kết bằng mật mã đối với nội dung khối (tiêu đề khối) và giá thầu của họ. Sau khi chấp nhận giá thầu chiến thắng, Người đề xuất tạo một đề xuất khối đã ký bao gồm tiêu đề khối. Trình tạo khối phải xuất bản toàn bộ nội dung khối sau khi xem đề xuất khối đã ký và cũng phải nhận đủ chứng thực từ người xác nhận trước khi có thể hoàn tất.

PBS giảm thiểu tác động của MEV như thế nào?

PBS trong giao thức làm giảm tác động của MEV đối với sự đồng thuận bằng cách loại bỏ việc khai thác MEV khỏi thẩm quyền của người xác thực. Thay vào đó, các trình tạo khối chạy trên phần cứng chuyên dụng sẽ nắm bắt các cơ hội MEV trong tương lai.

Tuy nhiên, điều này không loại trừ hoàn toàn thu nhập liên quan đến MEV cho người xác thực, vì người xây dựng phải trả phí để người xác nhận chấp nhận khối của họ. Tuy nhiên, vì những người xác nhận không còn tập trung trực tiếp vào việc tối ưu hóa doanh thu MEV, nên mối đe dọa của các cuộc tấn công kẻ cướp thời gian sẽ giảm đi.

PBS cũng làm giảm nguy cơ tập trung hóa MEV. Ví dụ: sử dụng sơ đồ tiết lộ cam kết sẽ loại bỏ nhu cầu của người xây dựng tin tưởng người xác nhận không đánh cắp cơ hội MEV hoặc để lộ chúng cho những người xây dựng khác. Điều này làm giảm rào cản đối với những người đặt cược độc lập để hưởng lợi từ MEV, nếu không, các nhà xây dựng sẽ có xu hướng ưu tiên các nhóm lớn có danh tiếng ngoài chuỗi và giao dịch với họ ngoài chuỗi.

Builder API  

Tương tự như vậy, những người xác thực không cần phải tin tưởng những người xây dựng sẽ không giữ lại nội dung khối hoặc phát hành các khối không hợp lệ vì các khoản thanh toán là vô điều kiện. Phí của người xác thực vẫn được xử lý ngay cả khi khối được đề xuất không có sẵn hoặc bị vô hiệu bởi những người xác nhận khác. Trong trường hợp thứ hai, khối đơn giản bị loại bỏ, buộc người xây dựng khối phải mất tất cả phí giao dịch và doanh thu MEV.

Mặc dù đề cập đến việc PBS hứa hẹn sẽ giảm tác động của việc rút tiền MEV, nhưng việc triển khai nó đòi hỏi phải thay đổi giao thức đồng thuận. Cụ thể, các quy tắc lựa chọn fork trên Beacon Chain cần được cập nhật. API Builder là một giải pháp tạm thời nhằm cung cấp triển khai PBS hiệu quả, mặc dù có các giả định về độ tin cậy cao hơn.

API Builder là phiên bản sửa đổi của API Engine được sử dụng bởi các ứng dụng khách lớp đồng thuận để yêu cầu tải thực thi từ các ứng dụng khách lớp thực thi. Như đã nêu trong thông số kỹ thuật của Trình xác thực trung thực, các trình xác thực được chọn cho các nhiệm vụ đề xuất khối yêu cầu gói giao dịch từ các máy khách thực thi được kết nối, gói này bao gồm trong khối chuỗi beacon được đề xuất.

Builder API cũng hoạt động như một phần mềm trung gian giữa trình xác thực và máy khách lớp thực thi; nhưng nó khác ở chỗ nó cho phép trình xác thực trên chuỗi đèn hiệu lấy khối từ các thực thể bên ngoài (thay vì sử dụng máy khách thực thi để xây dựng khối cục bộ) .

• API Builder hoạt động như sau:

• API Builder kết nối các trình xác thực với một mạng lưới các trình tạo khối đang chạy ứng dụng khách lớp thực thi. Cũng giống như trong PBS, các nhà xây dựng là các nhóm chuyên dụng cống hiến hết mình cho việc xây dựng khối sử dụng nhiều tài nguyên và sử dụng các chiến lược khác nhau để tối đa hóa doanh thu từ các mẹo ưu tiên MEV +.

• Trình xác thực (chạy ứng dụng khách lớp đồng thuận) yêu cầu tải trọng thực thi cùng với giá thầu từ mạng trình tạo. Giá thầu từ trình tạo sẽ chứa tiêu đề khối tải trọng thực thi — một cam kết bằng mật mã đối với nội dung của tải trọng — và một khoản phí phải trả cho người xác thực.

• Trình xác thực xem xét các giá thầu đến và chọn tải thực thi đắt nhất. Sử dụng API Builder, trình xác thực tạo một đề xuất khối đèn hiệu "bị che khuất" chỉ chứa tiêu đề khối tải trọng thực thi và chữ ký của họ, rồi gửi nó đến trình tạo.

• Một trình tạo đang chạy API Trình tạo được mong đợi sẽ phản hồi với tải thực thi đầy đủ sau khi thấy đề xuất khối ẩn. Điều này cho phép các trình xác thực tạo một khối báo hiệu "đã ký", khối này sẽ lan truyền khắp mạng.

Trình xác thực sử dụng API Builder sẽ vẫn cần tạo khối cục bộ trong trường hợp trình tạo khối không phản hồi kịp thời để họ không bỏ lỡ phần thưởng đề xuất khối. Tuy nhiên, trình xác thực không thể tạo một khối khác bằng cách sử dụng giao dịch công khai hiện tại hoặc một nhóm giao dịch khác, vì điều này dẫn đến sự mơ hồ (ký hai khối trong cùng một vị trí), đây là một lỗi nghiêm trọng.

MEV-Boost là một ví dụ triển khai BuilderAPI (chúng tôi sẽ giới thiệu riêng MEV-Boost trong số tiếp theo), đây là một cải tiến đối với cơ chế đấu giá Flashbots, nhằm mục đích ngăn chặn các tác động tiêu cực bên ngoài của MEV trên Ethereum. Các cuộc đấu giá Flashbot cho phép những người khai thác thuê ngoài công việc xây dựng các khối có lợi nhuận cho các nhóm chuyên biệt được gọi là Người tìm kiếm trong Proof-of-Work.

Những người tìm kiếm tìm kiếm các cơ hội MEV có lợi nhuận và gửi các gói giao dịch cho người khai thác cùng với giá thầu niêm yết có trong các khối. Những người khai thác đang chạy mev-geth, một phiên bản rẽ nhánh của ứng dụng khách go-ethereum (Geth), chỉ cần chọn gói giao dịch có lợi nhất và khai thác nó như một phần của khối mới. Để bảo vệ người khai thác khỏi thư rác và giao dịch không hợp lệ, các gói giao dịch được xác thực thông qua Người chuyển tiếp trước khi đến tay người khai thác.

Người chuyển tiếp vẫn chịu trách nhiệm xác thực các gói giao dịch trước khi chuyển chúng cho người đề xuất. Tuy nhiên, MEV Boost giới thiệu ký quỹ chịu trách nhiệm cung cấp tính khả dụng của dữ liệu bằng cách lưu trữ các phần thân khối do người xây dựng gửi và tiêu đề khối do người xác thực gửi. Tại đây, trình xác thực được kết nối với một bộ chuyển tiếp yêu cầu tải trọng thực thi có sẵn và sử dụng thuật toán xếp hạng của MEV Boost để chọn tiêu đề tải trọng có "giá thầu cao nhất + phí MEV".

tiêu đề phụ

API Builder giảm thiểu tác động của MEV như thế nào?

Sức mạnh cốt lõi của Builder API là khả năng dân chủ hóa quyền truy cập vào các cơ hội MEV. Việc sử dụng sơ đồ cam kết tiết lộ sẽ loại bỏ các giả định về niềm tin và hạ thấp rào cản gia nhập đối với những người xác thực đang tìm cách hưởng lợi từ MEV. Điều này sẽ làm giảm áp lực đối với những người đặt cược độc lập trong việc tích hợp với các nhóm đặt cược lớn để cải thiện lợi nhuận MEV.

Việc triển khai rộng rãi Builder API sẽ khuyến khích sự cạnh tranh lớn hơn giữa các nhà xây dựng khối, tăng khả năng chống kiểm duyệt. Khi trình xác thực xem xét giá thầu từ nhiều trình tạo, trình tạo có ý định xem xét một hoặc nhiều giao dịch của người dùng phải đặt giá thầu cao hơn tất cả các trình tạo không xem xét khác để thành công. Điều này làm tăng đáng kể chi phí kiểm duyệt người dùng và không khuyến khích thực hành.

• Một số dự án, chẳng hạn như MEV Boost, sử dụng Builder API như một phần của cấu trúc tổng thể, được thiết kế để cung cấp quyền riêng tư trong giao dịch cho các bên nhất định, chẳng hạn như các nhà giao dịch cố gắng thực hiện các cuộc tấn công bánh mì/chạy trước. Điều này đạt được bằng cách cung cấp một kênh liên lạc riêng tư giữa người dùng và người xây dựng khối. Không giống như các nhóm bộ nhớ được cấp phép được mô tả trước đó, phương pháp này có lợi vì những lý do sau:

• Phần mềm API Builder là nguồn mở và bất kỳ ai cũng có thể cung cấp dịch vụ trình tạo khối. Điều này có nghĩa là người dùng không bị buộc phải sử dụng bất kỳ trình tạo khối cụ thể nào và tăng tính trung lập và bản chất không cần cấp phép của Ethereum. Ngoài ra, các nhà giao dịch tìm kiếm MEV sẽ không vô tình góp phần vào việc tập trung hóa bằng cách sử dụng các kênh giao dịch riêng tư.

chữ

Phần.3 MEV có phải là duy nhất đối với Ethereum không?

Chúng tôi không thể không đặt câu hỏi: MEV có phải là duy nhất đối với Ethereum không?

Không, giả sử MEV cũng hiển thị trên Bitcoin. Động cơ kiểm duyệt các kênh chớp nhoáng hoặc mã thông báo chi tiêu gấp đôi về mặt kỹ thuật là MEV. Tuy nhiên, giả thuyết của chúng tôi là Bitcoin vốn ít nhạy cảm với MEV hơn so với các chuỗi khối như Ethereum.

• Lý do cho điều này là sự phức tạp và "trạng thái" của các chuỗi khối tương ứng:

• Tốc độ mà MEV tích lũy trên một chuỗi khối nhất định thường tỷ lệ thuận với mức độ phức tạp của hành vi lớp ứng dụng của nó.

• Các giao thức linh hoạt tùy ý, chẳng hạn như Ethereum, không thể hạn chế sự phức tạp này và vốn dĩ có xu hướng trở nên phức tạp hơn theo thời gian.

Đây là lý do tại sao chúng tôi nói rằng sự phức tạp của Ethereum có thể là một lời nguyền.

chữ

Part.4 MEV tuân theo độ phức tạp

Ngược lại, chúng ta có thể quan sát thấy sự tăng trưởng theo cấp số nhân của bề mặt MEV trên Ethereum, chủ yếu là do dòng giá trị lớn thông qua các ứng dụng DeFi. Những nền tảng tài chính có vẻ hứa hẹn này cũng có thể được coi là ký sinh trùng của Ethereum: dệt nên một mạng lưới MEV vô tận phát triển lớn hơn và phức tạp hơn mỗi ngày.

tiêu đề cấp đầu tiên

Part.5 MEV khó sửa chữa

Cuối cùng, điều tự nhiên là liệu Ethereum có thể xây dựng một cơ chế để bù đắp mục nhập MEV vào giao thức hay không. Tóm lại, không, ít nhất là không thay đổi trải nghiệm của nhà phát triển và/hoặc người dùng trên Ethereum.

Bất kỳ nỗ lực nào nhằm ngăn chặn các công cụ khai thác/người xác thực nhận được dòng doanh thu đều có thể thúc đẩy việc tạo ra các thị trường ngoài giao thức. Ví dụ: nếu tất cả các giao dịch chỉ được phép thanh toán một tỷ lệ thống nhất, chúng tôi sẽ mong đợi các công cụ khai thác/người xác thực thông đồng với các giao dịch viên để chấp nhận thanh toán nhằm đạt được quyền ưu tiên giao dịch. Tương tự như vậy, nếu tất cả các khoản phí giao dịch được đốt cháy hoặc trả cho một "bình công cộng", những người khai thác/người xác nhận chỉ cần thu phí riêng lẻ.

Để biết thêm kiến ​​thức về blockchain và hàng khô, hãy theo dõi Tokenview.io.

bài viết tham khảo

https://research.paradigm.xyz/MEV

https://ethereum.org/en/developers/docs/mev/#mev-in-ethereum-proof-of-stake