Trò chơi hiện tại giữa sự đồng thuận Ethereum và MEV bắt đầu từ ngày PoW chuyển sang PoS.

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ố đề xuất quản trị MEV của Ethereum đang nói về điều gì, bạn có thể vẫn cần bổ sung một số thông tin cơ bản. Do đó, bài viết này đã giải đáp một loạt câu hỏi về quản trị. của MEV kể từ khi Ethereum chuyển sang PoS. Các đề xuất như PBS, ePBS và PEPC, tôi hy vọng có thể cung cấp cho bạn một số thông tin cơ bản.

PBS (Proposer Builder Seperatioin) 

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 là một The đã được sửa đổi. khách hàng go-ethereum. Ý tưởng cốt lõi là cho phép các thợ mỏ tập trung vào công việc của họ - khai thác, 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 người khai thác đó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 những người khai thác, 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ị những người khai thác đánh cắp. Khi những người tìm kiếm, nguồn lợi nhuận chính, bị mắc kẹt, những người khai thác 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ợ mỏ. Chỉ những người khai thác trong danh sách trắng mới có thể nhận được gói tìm kiếm. Bằng cách áp đặt các hạn chế về danh tiếng đối với người khai thác và loại bỏ những người khai thác đánh cắp kết quả của người tìm kiếm khỏi danh sách trắng, người khai thác 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 thức tạo khối chuyển sang chọn ngẫu nhiên những người đề xuất từ ​​những người xác nhận để đề xuất các khối nên phương pháp hạn chế danh tiếng nhằm ngăn chặn những người đề xuất giật 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 hiển thị đối với người xác nhận. Một cải tiế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 ẩn nên quá trình này đã bị hoãn lại, vì vậy MEV-Boost đã có cơ hội can thiệp vào PBS Opportunity. 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 có một vai trò rất quan trọng - tiếp sức. Người xây dựng không gửi khối trực tiếp đến người đề xuất mà thông qua người chuyển tiếp vai trò thứ ba.  

Bởi vì có những vấn đề khác cần được giải quyết , chẳng hạn như cách Đảm bảo rằng người xây dựng chắc chắn sẽ trả tiền cho người đề xuất và sẽ tiết lộ nội dung khối cho người đề xuất ở cuối để tránh người đề xuất bị phạt vì gửi khối trống; bởi người xây dựng sẽ được đưa vào chuỗi báo hiệu, 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 tiêu đề khối có lợi nhuận cao nhất tới 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. Rơle sẽ không tiết lộ khối hoàn chỉnh cho người đề xuất cho đến khi người đề xuất cam kết với đề xuất khối (ký vào tiêu đề khối). 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 được rơle xác nhận trước.  

Trong giao thức và 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 phải chạy Ethereum At Cùng lúc với ứng dụng khách đồng thuận và ứng dụng khách thực thi, chương trình MEV-Boost không phải Ethereum của bên thứ ba sẽ được chạy. Đâ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 dẫn đến việc 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 vào rơ le để không lấy cắp MEV của họ. Người đề xuất cũng phải tin tưởng rằng các tiêu đề khối 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ó động cơ 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à chuyển tiếp không yêu cầu quyền truy cập. Một chuyển tiếp như Eden chỉ chuyển tiếp trình tạo của chính nó. Ngoài ra còn có các rơle như bloXroute yêu cầu 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 xếp hạng

Và, từ góc độ của Liveness, do sự tồn tại của rơle nên không có sự xác nhận cấp độ nguyên tử nào 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 tiêu đề khối và người xây dựng cũng cung cấp nội dung tải trọng, nhưng rơle không gửi nội dung kịp thời (dù là độc hại hay không độc hại), người xây dựng và người đề xuất sẽ bị 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 để chuyển các phần bên ngoài giao thức vào trong giao thức, ePBS được gói gọn trong Ethereum dường như là điều bắt buộc. Hiện tại, ePBS không còn là đề xuất đ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à người xây dựng thuê ngoài quyền xây dựng khối. Vai trò của người xây dựng, ban đầu nằm ngoài giao thức, đã được đưa vào giao thức, nghĩa là, một vai trò 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 thực 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 của 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 số đó, 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:

1. Sau khi biết rằng mình đượ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, phải được bao gồm trong giao dịch đánh bạc).

2. 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 thanh toán cho người đề xuất "SignedExecutionPayloadHeader" cho người đề xuất (tải trọng thực thi cần đáp ứng IL )

3. Người đề xuất chọn một trong số "SignedExecutionPayloadHeader" được 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 được chọn đó). Và phát khối báo hiệu được đề xuất "SignedBeaconBlock".

4. Nhân chứng thực hiện nhiệm vụ chứng kiến

5. Người tổng hợp gửi tổng hợp chứng thực; đồng thời, người xây dựng phát sóng tải trọng thực thi

6. 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 nhận 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 nhiều cuộc thảo luận từ khi được đề xuất cho đến khi cuối cùng có được số EIP. Ban đầu PBS được Vitalik đề xuất vào ngày 21 tháng 6 và giải pháp hai khe đã được cải tiến 4 tháng sau đó. Sau ba tháng nữa, PBS một khe đã được đưa ra. Cho đế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 ý với ePBS và hy vọng 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 tin 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. Những cam kết này có thể được thực hiện trên chuỗi. Việc xác minh chủ yếu được thực hiện bằng mã hoạt động "BEACONROOT". Đây là một cơ chế tổng quát hơn. Cam kết 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 của các khối, tức là người đề xuất bán quyền xây dựng khối lập trình.

Tóm tắt 

Phần trên 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 trở nê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 vai trò chính của chuyển tiếp bên thứ ba ngoài thỏa thuận có thực sự chỉ có tác động tiêu cực? 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.