Cuộc đấu tranh giữa Ethereum và MEV hiện tại bắt đầu từ ngày chuyển từ PoW sang PoS ...

Viết bởi: Tia, Techub News

Quá trình giải quyết vấn đề MEV thực tế là quá trình thiết lập lại quy tắc phân phối Khối. Đối với MEV, tin rằng mọi người không còn xa lạ nữa, nhưng nếu muốn biết về các đề xuất quản trị MEV trên Ethereum đang thảo luận về điều gì, có lẽ vẫn cần một số thông tin nền tảng bổ sung, vì vậy, bài viết này sẽ điều chỉnh các đề xuất quản trị MEV sau khi Ethereum chuyển sang PoS như PBS, ePBS, PEPC, hy vọng cung cấp một số thông tin nền tảng cho mọi người.

PBS (Proposer Builder Separation)

Trước khi sát nhập ETH, cách giải quyết MEV là thông qua việc sử dụng MEV-Geth được phát triển bởi Flashbots, MEV-Geth là một loại phiên bản sửa đổi của khách hàng go-ethereum. Ý tưởng cốt lõi của nó là để Người khai thác tập trung vào công việc chính của họ - Khai thác, thay vì tham gia tranh cãi MEV, từ đó tránh được vấn đề tái cấu trúc tiềm ẩn có thể xảy ra. Cơ chế của MEV-Geth rất đơn giản, đó là một giải pháp thị trường hóa, nghĩa là Người khai thác có thể chọn lựa khi đóng gói Khối dựa trên lợi nhuận của bundle mà searcher gửi. Thông qua cơ chế thị trường tinh tế này, mọi bên không chỉ có lợi ích mà còn tạo ra một số ràng buộc nhất định. Mặc dù searcher cần phải chia sẻ một phần lợi nhuận với Người khai thác, nhưng điều đổi lại là sự bảo vệ an toàn hơn không bị Người khai thác đánh cắp. Khi đã khóa chặt nguồn lợi nhuận chính từ searcher, Người khai thác cũng sẽ bắt buộc bắt đầu sử dụng MEV-Geth và bị ràng buộc bởi cơ chế của MEV-Geth. MEV-Geth sẽ duy trì một Danh sách cho phép của Người khai thác, chỉ có Những Người khai thác trên Danh sách cho phép mới có thể nhận bundle của searcher. Thông qua việc ràng buộc uy tín của Người khai thác, tức là loại bỏ Những Người khai thác đánh cắp thành quả của searcher khỏi Danh sách cho phép, có thể ngăn chặn Người khai thác tranh giành lợi nhuận MEV của searcher.

Tuy nhiên, sau khi hợp nhất, vì phương thức tạo Khối được chọn ngẫu nhiên từ Người xác thực làm người đề xuất Khối, cách ràng buộc danh tiếng để ngăn chặn người đề xuất tranh giành MEV không còn khả thi.

Một giải pháp khả thi là làm cho nội dung Khối không thể nhìn thấy được bởi Người xác thực. Tiếp theo, theo đúng hướng đi này, chúng ta có thể phát triển thêm PBS (Proposer Builder Seperatioin, Tách Biệt Xây dựng Dự thảo). PBS sẽ phân tách trách nhiệm của Người xác thực làm proposer thành xây dựng Khối và đưa ra dự thảo Khối. Quyền xây dựng phức tạp có thể tham gia tranh đấu lợi ích được giao cho builder. Vì vậy, công việc của proposer trở nên đơn giản, chỉ cần chọn đề xuất Khối dựa trên lợi nhuận được builder đệ trình.

Ban đầu, Ethereum muốn nhúng PBS vào giao thức khi thực hiện merge, nhưng do sự phức tạp tiềm tàng, quá trình này đã được tạm ngưng, từ đó để cho MEV-Boost có cơ hội tham gia vào PBS. Hiện tại, PBS được thực hiện thông qua MEV-Boost được phát triển bởi flashbots. Ngoài các đơn vị xây dựng và đề xuất, còn có một vai trò quan trọng khác là relay. Người xây dựng không gửi Khối trực tiếp cho người đề xuất, mà thông qua vai trò thứ ba là relay.

Bởi vì vẫn còn phải giải quyết một số vấn đề khác, như làm thế nào để đảm bảo builder sẽ chắc chắn trả phí cho proposer và chắc chắn sẽ tiết lộ nội dung của khối cho proposer để tránh bị phạt do gửi khối trống; như làm thế nào để đảm bảo khối do builder gửi sẽ chắc chắn được đưa vào beacon chain và những vấn đề bảo vệ quyền lợi của builder và proposer chủ yếu được thực hiện thông qua sự truyền tải.

builder sẽ gửi Khối đến relay, sau đó relay sẽ sắp xếp Khối theo lợi nhuận mà mỗi Khối có thể thu được, sau đó gửi đầu Khối có lợi nhuận cao nhất đến proposer để đảm bảo proposer không thể xem nội dung của Khối. Sau khi proposer cam kết đưa ra đề xuất về Khối (ký tên cho đầu Khối đó), relay mới tiết lộ toàn bộ Khối cho proposer. Phí được builder trả cho proposer cũng cần phải thông qua relay để đảm bảo hoàn thành. Giao dịch được thanh toán cho proposer được bao gồm trong Khối đã được gửi, nhưng vì proposer không thể xem nội dung của Khối, nên vẫn cần được relay xác nhận trước đó.

Giao thức đầu vào và giao thức đầu ra

Để có thể tham gia vào thị trường do MEV-Boost xây dựng, Người xác thực cần chạy chương trình MEV-Boost không phải ETH của bên thứ ba trong khi chạy ETH Fang Nhận thức chung client và execution client. Đây là sự kỳ diệu của PBS hiện đang hoạt động, cho phép một bên thứ ba khác ngoài giao thức tham gia vào việc thiết kế các quy tắc được hình thành bởi Nhận thức chung của ETH Square. Từ quan điểm sở hữu, điều này thật đáng kinh ngạc.

Điều này cũng đã dẫn đến một sự phản ánh về “uy tín” của cơ chế Giao thức, nó đã được củng cố như thế nào và nó đã bị xói mòn như thế nào thông qua các cơ chế khác. MEV-Boost là một ví dụ điển hình về điều này, vì có thể có trường hợp một giao thức bên ngoài sẽ thay đổi cơ chế hiện có. Khi bản thân giao thức bắt đầu tụt hậu, sự thay đổi này có thể bắt đầu nảy mầm từ bên ngoài, và sự nảy mầm của cơ chế bên ngoài phải phù hợp với nhu cầu thị trường hiện tại, nhưng vẫn chưa biết liệu cơ chế bên ngoài có đáng tin cậy hay không, liệu nó có được thiết kế cẩn thận để ngăn chặn các vấn đề tiềm ẩn hay không, và thậm chí liệu cơ chế bên ngoài có thể làm suy yếu giao thức hay không.

Trung tâm Relay phi tập trung

Điểm gây tranh cãi nhất của MEV-Boost là thị trường relay tập trung. Tuy nhiên, cài đặt này đưa ra vấn đề về sự tin tưởng. Người xây dựng cần tin rằng relay sẽ không đánh cắp MEV của họ. Người đề xuất cũng phải tin rằng tiêu đề khối mà họ nhận được và ký từ relay là hợp lệ. Tuy nhiên, mặc dù có vai trò quan trọng, Chuyển tiếp không có bất kỳ động lực kinh tế nào và việc vận hành relay cũng đòi hỏi một khoản chi phí không nhỏ. Năm ngoái, có 11 relay hỗ trợ mạng Ethereum, nhưng hiện tại chỉ còn 9 relay cung cấp dịch vụ.

Lưu ý rằng, relay không phải là một hệ thống không yêu cầu quyền truy cập, như relay như Eden chỉ chuyển tiếp cho builder của nó. Một số relay khác như bloXroute cho rằng sẽ lọc bỏ các giao dịch liên quan đến tấn công chạy trước và tấn công sandwich. Đến một mức độ nào đó, relay cũng có quyền đề ra các quy tắc.

Dữ liệu đến từ Mạng Được Đánh Giá

Ngoài ra, từ quan điểm của Liveness, do sự tồn tại của relay, builder và proposer không thể cung cấp xác nhận tại mức nguyên tử. Nếu khi proposer ký cam kết cho phần đầu block và builder cung cấp nội dung payload, nhưng do lỗi của relay (có tính chất độc hại hoặc không độc hại) mà không thể gửi nội dung đó kịp thời, cả builder và proposer đều phải chịu tổn thất.

ePBS: Đóng gói PBS vào Ethereum

Dù là để giải quyết vấn đề trung tâm hóa trong việc truyền tải, hay để di chuyển phần ngoài giao thức vào bên trong giao thức, việc đóng gói PBS vào ePBS của Ethereum dường như là một lựa chọn bắt buộc. Hiện tại, ePBS không còn là một đề xuất được thảo luận nữa, biên tập viên EIP của Ethereum đã gán cho nó một số thứ tự - EIP-7732.

ePBS cung cấp hạ tầng không đáng tin cậy cho nhà đề xuất và nhà xây dựng để hoàn thành việc tạo Khối. Vai trò của nhà xây dựng ban đầu bên ngoài giao thức đã được tích hợp vào giao thức, nghĩa là vai trò của người xác thực đã được phân chia ra khỏi vai trò của người xác thực, với vai trò của người xây dựng được thực hiện trong khối Nhà xác thực và cần thế chấp trên Ethereum. Do vai trò của nhà đề xuất được chia nhỏ từ lớp Nhận thức chung, vì vậy việc hoàn thành ePBS yêu cầu sửa đổi lớp Nhận thức chung. Trong đó, người xây dựng chịu trách nhiệm xây dựng tải trọng thực thi (danh sách cuối cùng của các giao dịch sẽ được thực hiện trong khối đó). Trách nhiệm của nhà đề xuất là đề xuất Khối dấu hiệu. Quá trình cụ thể như sau:

1. Sau khi biết được được chọn làm người đề xuất, hãy tạo và phát sóng Danh sách Bao gồm (IL, nghĩa là giao dịch phải được bao gồm trong khe cắm đó).
2. Các builder sẽ gửi KhốiHàm băm, chứa ution payload và cam kết trả phí cho proposer, đến proposer 「SignedutionPayloadHeader」(ution payload phải đáp ứng IL)
3. Người đề xuất chọn một ‘SignedutionPayloadHeader’ từ builders và đưa nó vào (thường chọn cái có giá trị cao nhất để trả cho người đề xuất). Và phát sóng khối mốc đề xuất ‘SignedBeaconBlock’.
4. Nhân chứng thực hiện nhiệm vụ chứng minh
5. Tổng hợp viên nộp aggreGate chứng thực; Đồng thời, Builder phát sóng UTION Payload
6. PTC (Ủy ban Thời gian Dữ liệu, trong mỗi slot, sẽ có 512 người xác thực được chọn làm thành viên PTC) kiểm tra xem người xây dựng đã giải mã ution payload kịp thời và phát sóng kết quả.

ePBS từ việc đề xuất cho đến khi cuối cùng nhận được số EIP cũng trải qua nhiều cuộc thảo luận. Ban đầu, PBS được Vitalik đề xuất vào tháng 6 năm 21, sau 4 tháng hoàn thiện kế hoạch Two-slot, sau 3 tháng, Single-slot PBS được ra mắt, cho đến tháng 7 năm 23, ý tưởng của PTC mới được đưa ra chính thức.

PEPC (Cam kết của người đề xuất được áp đặt bởi giao thức)

Tất nhiên, cũng có những người không đồng ý với ePBS và muốn thay thế bằng các giải pháp khác. PEPC chính là một ví dụ. Trong ePBS, một quy tắc cụ thể được nhúng vào giao thức, nhưng ở PEPC, những người đề xuất bán quyền xây dựng Khối có khả năng lập trình.

PEPC là một đề xuất của barnabe được đưa ra vào tháng 10 năm 2022. barnabe cho rằng, nếu muốn triển khai cơ chế PBS trong giao thức, cần xem xét triển khai một cơ chế chung để truyền tải tín hiệu đáng tin cậy, thay vì triển khai cơ chế của một tín hiệu đáng tin cậy cụ thể (ví dụ, nếu bạn cho tôi xây dựng một Khối, tôi sẽ trả lại cho bạn xx ETH).

Giống như tên gọi PEPC (Protocol-Enforced Proposer Commitments), một số cơ chế đảm bảo quyền lợi của người xây dựng và người đề xuất được thực hiện thông qua sự cam kết mà người đề xuất gửi trong giao thức, những cam kết này có thể được xác minh trên chuỗi, chủ yếu thông qua Mã thao tác “BEACONROOT”. Đây là một cơ chế phổ quát hơn, cam kết có thể là việc toàn bộ quyền xây dựng Khối được giao cho bên ngoài, hoặc chỉ một phần của Khối, nghĩa là quyền xây dựng Khối có thể được người đề xuất bán.

Tổng kết

Trên đây là một số thông tin đơn giản về PBS, ePBS và PEPC. Từ góc độ thiết kế giao thức, không chỉ cần thiết kế một cơ chế thị trường để phân phối lại MEV, mà còn cần xem xét làm thế nào để tập trung phi tập trung hơn cho Người xác thực, và làm thế nào để tăng cường khả năng chống kiểm duyệt. Ngoài ra, thiết kế giao thức còn đòi hỏi nhiều sự lựa chọn. Ví dụ về ePBS đã có số EIP, mặc dù thiết kế của ePBS giải quyết vấn đề trung tâm relay, nhưng vai trò quan trọng của bên thứ ba relay trong giao thức có thực sự chỉ có tác động tiêu cực không? Xét về cơ chế thanh toán của builder, việc sử dụng relay thậm chí còn tốt hơn cơ chế ePBS, vì ePBS có cơ chế trả trước, nếu builder đóng gói một Khối có lợi nhuận cực cao, thì trong cơ chế trả trước sẽ không thể cung cấp lợi nhuận cao cho người đề xuất.