Được viết bởi: Tia, Techub News
Quá trình giải quyết vấn đề MEV thực chất là xây dựng lại các quy tắc phân bổ không gian khối. Tôi tin rằng mọi người không còn xa lạ với MEV nữa, nhưng nếu bạn muốn biết một số Đề án quản trị MEV Ethereum đang nói về điều gì, bạn có thể vẫn cần bổ sung một số thông tin bối cảnh . Do đó, bài viết này đã giải đáp sê-ri về quản trị. của MEV kể từ khi Ethereum chuyển sang PoS. Đề án như PBS, ePBS và PEPC, tôi hy vọng có thể cung cấp cho bạn một số thông tin bối cảnh.
PBS (Tách biệt Trình tạo Đề xuất)
Trước khi sáp nhập Ethereum, cách giải quyết MEV là sử dụng MEV-Geth do Flashbots phát triển, một máy trạm go-ethereum đã được sửa đổi. Ý tưởng cốt lõi là cho phép thợ đào tập trung vào công việc khai thác của họ thay vì tham gia vào cuộc cạnh tranh MEV, từ đó tránh được các vấn đề tái cơ cấu tiềm ẩn có thể phát sinh. Cơ chế của MEV-Geth rất đơn giản. Đây là một giải pháp hướng đến thị trường, tức là khi thợ đào đóng gói các khối, họ có thể chọn theo quy mô lợi nhuận của gói do người tìm kiếm gửi. Thông qua cơ chế định hướng thị trường khéo léo này, tất cả các bên đều có thể đạt được lợi ích đồng thời hình thành những hạn chế nhất định. Mặc dù người tìm kiếm cần chia sẻ một phần lợi nhuận với thợ đào, nhưng những gì họ nhận được đổi lại là sự đảm bảo an toàn hơn trước việc bị thợ đào đánh cắp. Khi người tìm kiếm, nguồn lợi nhuận chính, bị mắc kẹt, thợ đào cũng sẽ bắt đầu sử dụng MEV-Geth một cách thụ động và sẽ bị hạn chế hơn nữa bởi cơ chế của MEV-Geth. MEV-Geth sẽ duy trì danh sách trắng các thợ đào và chỉ thợ đào trong danh sách trắng mới có thể nhận được gói của người tìm kiếm. Bằng cách áp đặt các hạn chế về danh tiếng đối với thợ đào và loại bỏ thợ đào đánh cắp kết quả của người tìm kiếm khỏi danh sách trắng, thợ đào có thể được ngăn chặn việc cướp lợi nhuận MEV của người tìm kiếm.
Tuy nhiên, sau khi sáp nhập, do phương pháp tạo khối thay đổi thành chọn ngẫu nhiên người đề xuất từ những người xác thực để đề xuất khối nên phương pháp hạn chế danh tiếng không còn khả thi để ngăn người đề xuất giật MEV.
Một giải pháp khả thi là làm cho nội dung khối không hiển thị đối với người xác nhận. Một hoàn thiện nữa theo hướng suy nghĩ này là PBS (Seperatioin của Người đề xuất, Seperatioin của Người đề xuất). PBS tiếp tục phân tách trách nhiệm của người xác minh của người đề xuất thành việc xây dựng khối và đề xuất khối, đồng thời giao các quyền xây dựng phức tạp có thể liên quan đến việc cạnh tranh lợi ích cho người xây dựng. Bằng cách này, công việc của người đề xuất trở nên rất đơn giản và chỉ cần các Khối được đề xuất. dựa trên lợi nhuận của người xây dựng từ việc gửi khối.
Ban đầu, Ethereum muốn nhúng PBS vào giao thức trong quá trình hợp nhất, nhưng do tính phức tạp tiềm tàng, quá trình này đã bị hoãn lại, do đó tạo cơ hội cho MEV-Boost can thiệp vào PBS. Hiện tại, PBS được triển khai thông qua MEV-Boost do Flashbots phát triển. Ngoài người xây dựng và đề xuất còn trong đó một nhân vật rất quan trọng - tiếp sức. Người xây dựng không gửi các khối trực tiếp đến người đề xuất mà thông qua người chuyển tiếp nhân vật thứ ba.
Bởi vì còn có những vấn đề khác cần phải giải quyết, chẳng hạn như làm thế nào để đảm bảo rằng người xây dựng sẽ trả tiền cho người đề xuất và cuối cùng sẽ tiết lộ nội dung khối cho người đề xuất để tránh người đề xuất không bị phạt vì gửi khối trống; ví dụ: làm thế nào để đảm bảo rằng khu vực do Khối xây dựng gửi chắc chắn sẽ được đưa vào Beacon Chain, v.v. Những vấn đề bảo vệ quyền và lợi ích của người xây dựng, người đề xuất chủ yếu được thực hiện thông qua hoạt động tiếp sức.
Người xây dựng sẽ gửi các khối đến rơle, sau đó rơle sẽ sắp xếp các khối theo lợi nhuận có thể thu được từ mỗi khối, sau đó gửi Block Header có lợi nhuận cao nhất cho người đề xuất để đảm bảo rằng người đề xuất không hiển thị với nội dung khối. Sau khi người đề xuất cam kết đề xuất khối (ký vào Block Header ), rơle sẽ tiết lộ khối hoàn chỉnh cho người đề xuất. Phí do người xây dựng trả cho người đề xuất cũng cần có sự trợ giúp của rơle để đảm bảo hoàn thành. Giao dịch được thanh toán cho người đề xuất được bao gồm trong khối đã gửi, nhưng do người đề xuất không thể nhìn thấy nội dung của khối nên vẫn cần phải được chuyển tiếp xác nhận trước.
Trong giao thức & giao thức ra
Để 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 Ethereum của bên thứ ba trong khi chạy máy trạm đồng thuận Ethereum và ứng dụng khách thực thi. Đây là điều kỳ diệu của PBS hiện đang chạy, cho phép các bên thứ ba ngoài giao thức tham gia vào việc thiết kế các quy tắc để hình thành sự đồng thuận của Ethereum. Từ góc độ quyền sở hữu, điều này thật khó tin.
Điều này cũng làm nảy sinh suy nghĩ về “độ tin cậy” của cơ chế giao thức, độ tin cậy đượ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ì có thể có những tình huống trong đó các giao thức bên ngoài thực hiện thay đổi đối với các cơ chế hiện có. Khi bản thân giao thức bắt đầu tụt lại phía sau, những thay đổi như vậy có thể bắt đầu nảy sinh từ bên ngoài. Sự nảy mầm của các cơ chế bên ngoài phải đáp ứng nhu cầu thị trường hiện tại, nhưng liệu cơ chế bên ngoài có đáng tin cậy hay không và liệu nó có được thiết kế chặt chẽ để ngăn chặn sự xuất hiện của tiềm năng hay không. các vấn đề , và thậm chí cả các cơ chế bên ngoài có thể làm suy yếu thỏa thuận vẫn chưa được biết đến.
Rơle tập trung
Khía cạnh bị chỉ trích nhiều nhất của MEV-Boost là thị trường chuyển tiếp tập trung của nó. Nhưng thiết lập này gây ra các vấn đề về niềm tin. Người xây dựng cần tin tưởng rằng rơle sẽ không đánh cắp MEV của họ. Người đề xuất cũng phải tin tưởng rằng Block Header họ nhận được và ký từ rơle là hợp lệ. Tuy nhiên, bất chấp vai trò quan trọng của chúng, không có khích lệ tài chính nào cho rơle và việc vận hành chúng đòi hỏi một khoản chi phí đáng kể. Năm ngoái, có 11 rơle hỗ trợ mạng Ethereum, nhưng ngày nay, chỉ có 9 rơle vẫn cung cấp dịch vụ.
Điều đáng chú ý là rơle không cần sự cho phép. Các rơle như Eden chỉ chuyển tiếp do chính người xây dựng của họ. Ngoài ra còn có các rơle như bloXroute tuyên bố lọc ra các giao dịch liên quan đến các cuộc tấn công chạy trước và tấn công sandwich. Ở một mức độ nào đó, chuyển tiếp cũng có một số quyền đưa ra quy tắc nhất định.
Dữ liệu đến từ Mạng được xếp hạng
Hơn nữa, từ góc độ Liveness, do sự tồn tại của rơle nên không có xác nhận cấp độ nguyên tử giữa người xây dựng và người đề xuất. Nếu người đề xuất ký cam kết với Block Header và người xây dựng cũng cung cấp nội dung tải trọng nhưng không gửi nội dung kịp thời do lỗi chuyển tiếp (dù là độc hại hay không độc hại) thì cả người xây dựng và người đề xuất đều chịu thiệt hại .
ePBS: Đóng gói PBS vào Ethereum
Cho dù đó là để giải quyết vấn đề tập trung hóa chuyển tiếp hay di chuyển các phần bên ngoài giao thức vào giao thức, việc đóng gói PBS vào ePBS của Ethereum dường như đã trở thành điều bắt buộc. Hiện tại, ePBS không còn là Đề án đang được thảo luận nữa và trình soạn thảo Ethereum EIP đã gán cho nó một số - EIP-7732.
ePBS cung cấp cơ sở hạ tầng không đáng tin cậy cho những người đề xuất và nhà xây dựng thuê ngoài quyền xây dựng khối. Nhân vật của người xây dựng, ban đầu nằm ngoài giao thức, đã được tích hợp vào giao thức, nghĩa là, một nhân vật nữa của người xây dựng được phân chia giữa những người xác nhận. Người xây dựng với tư cách là người xác nhận cũng cần hoàn thành cam kết trong Ethereum. Do trách nhiệm của người đề xuất ban đầu lớp đồng thuận đã được phân chia nên việc hoàn thành ePBS đòi hỏi phải có những thay đổi đối với lớp đồng thuận. 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 các giao dịch cuối cùng sẽ được thực hiện trong khối). Trách nhiệm của người đề xuất là đề xuất các khối báo hiệu. Quy trình cụ thể như sau:
Sau khi biết rằng mình được chọn làm Người đề xuất, tạo ra và phát Danh sách bao gồm (IL, nghĩa là các giao dịch phải được đưa vào vị trí).
Người xây dựng gửi hàm băm khối chứa tải trọng thực thi và cam kết "SignedExecutionPayloadHeader" sẵn sàng trả tiền cho người đề xuất cho người đề xuất (tải trọng thực thi cần phải đáp ứng IL)
Người đề xuất chọn một trong những "SignedExecutionPayloadHeader" do người xây dựng gửi để đưa nó vào (thường là giá trị cao nhất được trả cho người đề xuất). Và phát sóng khối báo hiệu được đề xuất "SignedBeaconBlock".
Người chứng kiến thực hiện nhiệm vụ chứng kiến
Người tổng hợp gửi tổng hợp chứng thực cùng lúc, trình tạo phát sóng tải trọng thực thi;
PTC (Ủy ban tính kịp thời của tải trọng, trong mỗi vị trí, 512 người xác thực sẽ được chọn làm thành viên PTC) kiểm tra xem người xây dựng có tiết lộ tải trọng thực thi kịp thời và phát kết quả hay không
ePBS cũng đã trải qua lần cuộc thảo luận từ khi được đề xuất cho đến khi cuối cùng có được số EIP. PBS ban đầu được Vitalik đề xuất vào ngày 21 tháng 6. Bốn tháng sau, giải pháp Hai khe cắm được hoàn thiện. Ba tháng sau, PBS một khe cắm phải đến ngày 23 tháng 7 ý tưởng về PTC mới chính thức được đề xuất. .
PEPC (Cam kết của người đề xuất được thực thi theo giao thức)
Tất nhiên, cũng có những người không đồng tình với ePBS và mong muốn sử dụng các giải pháp khác thay thế. PEPC là như vậy. ePBS nhúng một quy tắc nhất định vào giao thức, nhưng tại PEPC, người đề xuất bán quyền xây dựng khối lập trình.
PEPC được Barnabe đề xuất vào tháng 10 năm 2022. Barnabe cho rằng rằng nếu cơ chế PBS được triển khai trong giao thức thì nên xem xét việc triển khai một cơ chế chung để truyền tín hiệu đáng tin cậy, thay vì triển khai một cơ chế tín hiệu đáng tin cậy cụ thể (ví dụ: nếu tôi được yêu cầu xây dựng một khối), tôi sẽ trả lại cho bạn xx ETH).
Đúng như tên gọi của PEPC (Cam kết của người đề xuất được thực thi theo giao thức), một số cơ chế đảm bảo quyền và lợi ích của người xây dựng và người đề xuất được hoàn thành thông qua các cam kết do người đề xuất đưa ra trong giao thức. Các cam kết này có thể được xác minh trên Chuỗi, chủ yếu bằng. mã hoạt động "BEACONROOT" để đạt được. Đây là cơ chế tổng quát hơn, có thể thuê ngoài toàn bộ quyền xây dựng khối, hoặc chỉ thuê ngoài một phần khối, tức là người đề xuất bán quyền xây dựng khối lập trình.
bản tóm tắt
Trên đây là phần giới thiệu ngắn gọn về PBS, ePBS và PEPC. Từ góc độ thiết kế giao thức, không chỉ cần thiết kế cơ chế thị trường để phân phối lại MEV mà còn phải xem xét cách làm cho các trình xác nhận phi tập trung hơn và cách cải thiện khả năng chống kiểm duyệt. Hơn nữa, có rất nhiều sự đánh đổi trong việc thiết kế giao thức. Lấy ePBS, đã nhận được số EIP, làm ví dụ. Mặc dù thiết kế của ePBS giải quyết được vấn đề chuyển tiếp tập trung, nhưng nhân vật chính của nó với tư cách là chuyển tiếp của bên thứ ba ngoài thỏa thuận có thực sự chỉ có tác động tiêu cực không? Từ góc độ cơ chế thanh toán của nhà xây dựng, sử dụng rơle tốt hơn cơ chế ePBS, bởi vì ePBS là cơ chế trả trước. Nếu nhà xây dựng đóng gói một khối lợi nhuận siêu cao, nó sẽ không thể cung cấp số tiền cao cho người đề xuất theo. cơ chế trả trước.
