Cuộc đấu giữa đồng thuận Ethereum và MEV hiện nay bắt đầu từ ngày chuyển đổi từ PoW sang PoS...
Tuyển chọn TechFlowTuyển chọn TechFlow
Cuộc đấu giữa đồng thuận Ethereum và MEV hiện nay bắt đầu từ ngày chuyển đổi từ PoW sang PoS...
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 để các trình xác thực trở nên phi tập trung hơn, cũng như làm thế nào để nâng cao khả năng chống kiểm duyệt.
Chuyên sâu báo cáo Web3Tác giả: Tia, Techub News
Quá trình giải quyết vấn đề MEV thực chất là việc xây dựng lại quy tắc phân bổ không gian khối. Dù khái niệm MEV đã không còn xa lạ với nhiều người, để hiểu rõ các đề xuất quản trị MEV trên Ethereum đang nói về điều gì, chúng ta vẫn cần bổ sung thêm một số thông tin nền tảng. Bài viết này sẽ tổng hợp lại loạt đề xuất liên quan đến quản trị MEV kể từ khi Ethereum chuyển sang PoS như PBS, ePBS, PEPC nhằm cung cấp cho bạn đọc những thông tin tham khảo hữu ích.
PBS (Proposer-Builder Separation)
Trước khi sáp nhập (merge), cách tiếp cận phổ biến để giải quyết MEV là sử dụng MEV-Geth do Flashbots phát triển – một phiên bản sửa đổi của client go-ethereum. Tư tưởng cốt lõi là để thợ đào tập trung vào nhiệm vụ đào mỏ, thay vì tham gia tranh giành MEV, từ đó tránh được nguy cơ tái tổ chức mạng (reorg) tiềm ẩn. Cơ chế MEV-Geth rất đơn giản và mang tính thị trường: khi đóng gói khối, thợ đào chọn bundle dựa trên lợi nhuận mà searcher gửi lên. Nhờ cơ chế thị trường tinh tế này, các bên vừa thu được lợi ích, vừa bị ràng buộc nhất định. Dù searcher phải chia sẻ một phần lợi nhuận cho thợ đào, nhưng đổi lại họ có được sự bảo đảm an toàn rằng công sức MEV của mình sẽ không bị thợ đào chiếm đoạt. Khi nguồn lợi chính – searcher – bị "gò" vào hệ thống này, các thợ đào cũng bị động sử dụng MEV-Geth và chịu sự ràng buộc từ cơ chế của nó. MEV-Geth duy trì một danh sách trắng các thợ đào; chỉ những thợ đào nằm trong danh sách này mới có thể nhận bundle từ searcher. Bằng cách ràng buộc uy tín – loại bỏ khỏi danh sách trắng những thợ đào ăn cắp kết quả của searcher – hệ thống ngăn chặn hiệu quả hành vi chiếm đoạt lợi nhuận MEV.
Tuy nhiên, sau khi sáp nhập, việc lựa chọn người tạo khối chuyển thành chọn ngẫu nhiên từ các validator làm proposer, nên phương pháp ràng buộc uy tín để ngăn proposer chiếm đoạt MEV không còn khả thi.
Giải pháp khả dĩ là khiến nội dung khối trở nên vô hình đối với validator. Phát triển sâu hơn ý tưởng này dẫn đến PBS (Proposer-Builder Separation – tách biệt người đề xuất và người xây dựng). PBS phân tách trách nhiệm của validator làm proposer thành hai vai trò riêng biệt: xây dựng khối và đề xuất khối. Quyền xây dựng phức tạp, dễ phát sinh tranh chấp lợi ích, được giao khoán cho bên builder. Như vậy, công việc của proposer trở nên đơn giản: chỉ cần chọn khối nào mang lại lợi nhuận cao nhất từ các builder để đề xuất.
Ban đầu, Ethereum muốn tích hợp sẵn PBS vào giao thức khi thực hiện merge, nhưng do độ phức tạp tiềm tàng, tiến trình này tạm bị đình hoãn, mở đường cho MEV-Boost tham gia vào PBS. Hiện tại, PBS được thực hiện thông qua MEV-Boost do Flashbots phát triển. Ngoài builder và proposer, còn có một vai trò quan trọng khác – relay. Builder không gửi trực tiếp khối tới proposer, mà thông qua vai trò thứ ba này.
Cần giải quyết thêm một số vấn đề khác, ví dụ như làm thế nào đảm bảo builder chắc chắn thanh toán phí cho proposer, và chắc chắn tiết lộ nội dung khối cho proposer ở bước cuối cùng để tránh proposer bị phạt do gửi khối trống; hay làm sao đảm bảo khối do builder gửi lên chắc chắn được đưa vào chuỗi beacon. Những vấn đề đảm bảo quyền lợi cho builder và proposer này chủ yếu được giải quyết nhờ relay.
Builder gửi khối cho relay, relay sắp xếp các khối theo lợi nhuận, rồi gửi tiêu đề khối có lợi nhuận cao nhất tới proposer, đảm bảo proposer không biết nội dung khối. Chỉ sau khi proposer cam kết đề xuất khối (ký vào tiêu đề khối), relay mới tiết lộ toàn bộ nội dung khối cho proposer. Việc builder thanh toán phí cho proposer cũng cần dựa vào relay để đảm bảo hoàn tất. Giao dịch thanh toán cho proposer nằm trong khối được gửi lên, nhưng do proposer không thấy nội dung, relay phải giúp xác nhận trước.
In-protocol & out-of-protocol
Để tham gia vào thị trường do MEV-Boost xây dựng, validator phải chạy thêm chương trình bên thứ ba MEV-Boost, ngoài client đồng thuận và client thực thi của Ethereum. Đây chính là điểm kỳ lạ của PBS hiện nay – cho phép bên thứ ba ngoài giao thức tham gia vào thiết kế quy tắc hình thành đồng thuận của Ethereum. Về mặt sở hữu, điều này thật khó tưởng tượng.
Điều này đặt ra câu hỏi về "độ tin cậy" của cơ chế giao thức: độ tin cậy được tăng cường như thế nào, và bị xói mòn ra sao bởi các cơ chế khác. MEV-Boost là minh chứng điển hình: tồn tại khả năng cơ chế bên ngoài làm thay đổi cơ chế hiện tại. Khi bản thân giao thức bắt đầu chậm trễ, những thay đổi này có thể nảy sinh từ bên ngoài. Cơ chế bên ngoài chắc chắn phù hợp với nhu cầu thị trường hiện tại, nhưng liệu nó có đáng tin cậy, có được thiết kế kỹ lưỡng để ngăn ngừa rủi ro, hay thậm chí có thể phá vỡ giao thức, thì vẫn chưa ai biết chắc.
Relay tập trung
Điểm bị chỉ trích nhiều nhất ở MEV-Boost là thị trường relay tập trung. Thiết lập này tạo ra vấn đề niềm tin. Builder phải tin rằng relay sẽ không đánh cắp MEV của họ. Proposer cũng phải tin rằng tiêu đề khối họ nhận và ký từ relay là hợp lệ. Tuy nhiên, dù đóng vai trò then chốt, relay lại không có động lực kinh tế, và việc vận hành relay cũng tốn kém đáng kể. Năm ngoái, có 11 relay hỗ trợ mạng Ethereum, nhưng hiện nay chỉ còn 9 relay đang hoạt động.
Lưu ý rằng, relay không hoàn toàn mở cửa. Một số relay như Eden chỉ trung chuyển khối từ builder của chính họ. Một số relay khác như bloXroute tuyên bố sẽ lọc các giao dịch front-running và tấn công sandwich. Về mặt nào đó, relay cũng nắm giữ một phần quyền định đoạt quy tắc.
Dữ liệu từ Rated Network
Hơn nữa, xét về mặt hoạt động (liveness), do sự hiện diện của relay, builder và proposer không thể đạt được xác nhận nguyên tử. Nếu proposer đã ký commitment vào tiêu đề khối, và builder cũng đã cung cấp nội dung payload, nhưng do lỗi của relay (dù cố ý hay vô ý) mà nội dung không được gửi kịp thời, cả builder lẫn proposer đều phải gánh chịu tổn thất.
ePBS: Đóng gói PBS vào Ethereum
Bất kể là để giải quyết vấn đề relay tập trung hay nhằm đưa phần nằm ngoài giao thức vào bên trong, ePBS – đóng gói PBS vào Ethereum – dường như đã trở thành lựa chọn tất yếu. Hiện nay, ePBS không còn là đề xuất bàn luận nữa, biên tập viên EIP của Ethereum đã cấp mã số cho nó – EIP-7732.
ePBS cung cấp một cơ sở hạ tầng phi tin cậy (trustless) cho proposer và builder để thực hiện việc khoán ngoài quyền xây dựng khối. Vai trò builder trước đây nằm ngoài giao thức nay được đưa vào bên trong giao thức – tức là từ nhóm validator tách thêm vai trò builder, và builder là validator cũng phải stake ETH trên Ethereum. Vì phân tách trách nhiệm vốn có của proposer ở tầng đồng thuận, nên việc hoàn thiện ePBS đòi hỏi thay đổi tầng đồng thuận. Trong đó, builder chịu trách nhiệm xây dựng execution payload (danh sách giao dịch cuối cùng sẽ được thực thi trong khối). Nhiệm vụ của proposer là đề xuất khối beacon. Quy trình cụ thể như sau:
-
Sau khi biết mình được chọn làm Proposer, tạo và phát tán Inclusion List (IL – danh sách giao dịch bắt buộc phải bao gồm trong slot này).
-
Các builder gửi cho proposer "SignedExecutionPayloadHeader" chứa hash khối bao gồm execution payload và cam kết phí sẽ trả cho proposer (execution payload phải thỏa mãn IL).
-
Proposer chọn một "SignedExecutionPayloadHeader" từ các builder (thường chọn cái có mức phí cao nhất), đưa vào và phát tán khối beacon đã ký "SignedBeaconBlock".
-
Các validator thực hiện nghĩa vụ làm chứng (attestation).
-
Aggregators gửi các attestation aggregates; đồng thời, builder phát tán execution payload.
-
PTC (Payload Timeliness Committee – Ủy ban Đảm bảo Thời gian Payload, mỗi slot có 512 validator được chọn làm thành viên PTC) kiểm tra xem builder có tiết lộ execution payload đúng hạn hay không và phát tán kết quả.
ePBS đã trải qua nhiều cuộc thảo luận trước khi chính thức nhận mã EIP. Ban đầu, PBS được Vitalik đề xuất vào tháng 6 năm 2021, 4 tháng sau hoàn thiện phương án Two-slot, thêm 3 tháng nữa ra mắt Single-slot PBS, và mãi đến tháng 7 năm 2023, ý tưởng PTC mới được chính thức đưa ra.
PEPC (Protocol-Enforced Proposer Commitments)
Tất nhiên, cũng có những người không đồng tình với ePBS và muốn dùng giải pháp thay thế. PEPC chính là một ví dụ như vậy. Nếu ePBS là việc nhúng một quy tắc xác định vào giao thức, thì với PEPC, proposer bán quyền xây dựng khối có thể lập trình được.
PEPC được barnabe đề xuất vào tháng 10 năm 2022. Barnabe cho rằng nếu muốn đưa cơ chế PBS vào giao thức, nên hướng tới việc tạo ra một cơ chế chung để truyền tín hiệu đáng tin cậy, thay vì chỉ triển khai một cơ chế tín hiệu đáng tin cậy cụ thể nào đó (ví dụ: nếu bạn xây khối giúp tôi, tôi sẽ hoàn lại xx ETH).
Đúng như tên gọi PEPC (Cam kết của Proposer được Giao thức Thực thi), các cơ chế đảm bảo quyền lợi cho builder và proposer được thực hiện thông qua các "cam kết" (commitment) mà proposer gửi trong giao thức. Những cam kết này có thể kiểm chứng trên chuỗi, chủ yếu thông qua opcode « BEACONROOT ». Đây là một cơ chế tổng quát hơn: cam kết có thể là khoán toàn bộ quyền xây dựng khối, hoặc chỉ một phần khối – tức là proposer bán quyền xây dựng khối có thể lập trình được.
Tổng kết
Trên đây là phần giới thiệu sơ lược về PBS, ePBS và PEPC. Xét về góc độ thiết kế giao thức, không chỉ cần xây dựng một cơ chế thị trường để phân phối lại MEV, mà còn phải cân nhắc làm sao để các validator ngày càng phi tập trung hơn, và nâng cao khả năng chống kiểm duyệt. Đồng thời, trong thiết kế giao thức tồn tại nhiều sự đánh đổi. Lấy ví dụ ePBS – đã được cấp mã EIP – dù thiết kế ePBS giải quyết được bài toán relay tập trung, nhưng vai trò then chốt relay – bên thứ ba ngoài giao thức – liệu có thực sự chỉ mang tác động tiêu cực? Xét riêng về cơ chế thanh toán của builder, sử dụng relay thậm chí còn ưu việt hơn cơ chế ePBS, vì ePBS áp dụng cơ chế trả phí trước (prepaid); nếu builder đóng gói một khối có lợi nhuận cực cao, dưới cơ chế trả trước sẽ không thể thưởng cao cho proposer.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
@News_Techub
