Vitalik: Cách giải quyết vấn đề MEV trong PoS

Tiêu đề gốc: "Suy nghĩ mới nhất của V God: hai cách giải quyết vấn đề MEV theo cơ chế đồng thuận PoS"

Tác giả gốc: Vitalik Buterin

Bản tổng hợp gốc: Cháo qua đêm, Babbitt

Đặc biệt cảm ơn Justin Drake và nhóm Flashbots để nhận được phản hồi và thảo luận hỗ trợ của họ.

Rủi ro lớn đe dọa sự phân cấp liên tục của các mạng đồng thuận là tính kinh tế xung quanh giá trị có thể trích xuất của thợ mỏ (MEV), bắt nguồn từ việc chọn nội dung khối tiếp theo bằng các kỹ thuật phức tạp để kiếm lợi nhuận. Để đưa ra một ví dụ MEV đơn giản: chênh lệch giá trên tất cả các sàn giao dịch phi tập trung trên chuỗi về những thay đổi giá xảy ra kể từ khối cuối cùng. Mặc dù phần thưởng PoS nói chung khá bình đẳng ở chỗ tỷ lệ hoàn vốn của một trình xác thực duy nhất giống như nhóm trình xác thực mạnh, nhưng vẫn có lợi thế kinh tế quy mô đáng kể trong việc tìm kiếm các cơ hội rút MEV phức tạp. Nói một cách đơn giản, một nhóm lớn hơn gấp 10 lần có cơ hội trích xuất MEV gấp 10 lần và nó có thể dành nhiều nỗ lực hơn để tối ưu hóa để thu được nhiều hơn từ mỗi cơ hội lợi nhuận. Ngoài vấn đề này, MEV còn làm phức tạp các nhóm phi tập trung, bởi vì trong một nhóm phi tập trung, một thực thể vẫn phải chịu trách nhiệm đóng gói và đề xuất các khối, đồng thời họ có thể dễ dàng rút MEV một cách bí mật mà không cần phải tương tác với chính nhóm đó. Chia thu nhập.

Giải pháp nổi tiếng nhất là sự tách biệt giữa người đề xuất/người xây dựng khối. Không giống như những người đề xuất khối cố gắng tự mình tạo ra các khối nhằm tối đa hóa doanh thu, họ dựa vào một thị trường trong đó các tác nhân bên ngoài mà chúng tôi gọi là người xây dựng khối tạo ra các khối chứa toàn bộ nội dung khối và phí của người đề xuất và người đề xuất chọn gói có chi phí cao nhất. Việc lựa chọn người đề xuất được rút gọn thành việc chọn gói có mức phí cao nhất, một thuật toán đơn giản đến mức trong một nhóm phi tập trung, nó thậm chí có thể được thực hiện trong MPC để ngăn chặn gian lận.

Bài viết này đề xuất một số thiết kế về cách đạt được điều này.

Xem thêm các ý tưởng từ năm 2018 có liên quan chặt chẽ đến các ý tưởng tại đây: Kế hoạch cam kết đề xuất được tối ưu hóa (Kế hoạch cam kết đề xuất được tối ưu hóa)

Các thuộc tính mong muốn của Thiết kế đề xuất khối tách biệt của Người đề xuất/Người xây dựng

Chúng tôi sẽ tập trung vào năm thuộc tính mong muốn chính:

1.Sự thân thiện với người đề xuất không đáng tin cậy: Có rất ít hoặc không có nguy cơ người đề xuất sẽ lừa dối người xây dựng khối, vì vậy người xây dựng khối không có động cơ để chọn một người đề xuất có danh tiếng ngoài chuỗi nhất định hoặc có mối quan hệ cá nhân với người xây dựng (vì điều này sẽ mang lại lợi ích cho các nhóm lớn).

2.Tính thân thiện của người xây dựng không đáng tin cậy:Có rất ít hoặc không có nguy cơ người xây dựng khối lừa dối người đề xuất, do đó Người đề xuất không có động cơ để chọn một nhà xây dựng có danh tiếng ngoài chuỗi nhất định hoặc có mối quan hệ cá nhân nhất định với người đề xuất (vì điều này sẽ khiến các nhà xây dựng mới tham gia thị trường khó khăn hơn). Nếu cần phải đặt cọc để đạt được điều này thì ngưỡng phải được giữ ở mức thấp nhất có thể.

3.Độ thân thiện yếu với người đề xuất: Cơ chế không nên yêu cầu người đề xuất phải có (i) băng thông cao hoặc tài nguyên máy tính khác hoặc ( ii) Độ phức tạp kỹ thuật cao.

4.Không thể đánh cắp các gói gói: Người đề xuất không được phép chấp nhận gói Gói do người xây dựng khối đề xuất và trích xuất các giao dịch từ đó tạo ra Bundle của riêng mình, từ đó ngăn cản những người xây dựng khối thu lợi nhuận (và có khả năng gây hại thêm cho họ).

5 Tính đơn giản và bảo mật của lớp đồng thuận: Từ góc độ của lớp đồng thuận, cơ chế này phải tiếp tục được bảo mật, và tốt nhất là thực hiện phân tích tương tự như các cơ chế đề xuất khối hiện có.

Ý tưởng 1

1. Người xây dựng khối tạo ra các gói và xuất bản các gói mà họ tạo ra. của gói. Tiêu đề gói chứa cam kết (nội dung khối dự kiến) đối với nội dung gói, khoản thanh toán cho người đề xuất và chữ ký của người xây dựng.

2. Người đề xuất chọn tiêu đề gói mang lại khoản thanh toán cao nhất (chỉ những gói mà người xây dựng có đủ số dư để thực sự thanh toán mới được xem xét). Họ ký và xuất bản đề xuất có chứa tiêu đề gói.

3. Sau khi xem đề xuất đã ký, người xây dựng khối cung cấp tiêu đề gói sẽ xuất bản gói hoàn chỉnh.

Tại thời điểm này, quy tắc lựa chọn ngã ba có khả năng đưa ra một trong ba phán đoán (thay vì hai phán đoán như thường lệ):

1. Đề xuất khối không tồn tại

2. Đề xuất khối tồn tại, nhưng nội dung gói không tồn tại

3. phần thân gói tồn tại

Lưu ý rằng trong trường hợp thứ hai, đề xuất vẫn trở thành một phần của chuỗi và điều quan trọng là Có, các khoản thanh toán từ người xây dựng khối cho người đề xuất vẫn được xử lý (nhưng bản thân người xây dựng khối không nhận được bất kỳ khoản phí hoặc MEV nào).

Phân tích

Ba trong số năm thuộc tính dễ dàng được thỏa mãn:

1. Người đề xuất chấp nhận khoản thanh toán đã hứa vô điều kiện nên gói gói không thể đánh lừa người đề xuất;

2. Ba bước này rất Tự động và thấp. -băng thông nên điều này thỏa mãn tính thân thiện yếu với người đề xuất;

3. Người đề xuất không thể nhìn thấy nội dung của gói mà họ đang ký, do đó điều này thỏa mãn khả năng không bị đánh cắp của gói;

3. p>

Các thuộc tính của lớp đồng thuận và tính thân thiện với người đề xuất không đáng tin cậy phức tạp hơn. Thiết kế này thực sự thay đổi cách hoạt động của lựa chọn phân nhánh, tăng từ 2 tùy chọn lên 3 tùy chọn, điều này cũng có nghĩa là người đề xuất không còn là người chơi cuối cùng trong trò chơi. Về mặt lý thuyết, người ta có thể lý luận rằng nếu việc lựa chọn nhánh đưa ra quyết định thì điều này sẽ tốt, nhưng đây vẫn là một thay đổi lớn tiềm ẩn chưa được biết đến.

Người đề xuất không thể xem nội dung gói, họ cũng không thể đánh lừa người xây dựng khối bằng cách ăn cắp các gói, nhưng họ có thể lừa dối người xây dựng khối bằng cách sử dụng các cuộc tấn công tinh vi hơn. Họ có thể xuất bản đề xuất của mình ở cuối thời điểm, đảm bảo rằng người chứng minh (có thể) nhìn thấy đề xuất kịp thời, nhưng không cho người xây dựng khối đủ thời gian để xuất bản nội dung, vì vậy rất có thể người chứng minh sẽ không nhìn thấy nội dung trên thời gian. . Điều này tạo ra rủi ro cho những người xây dựng khối và khuyến khích họ ủng hộ những người đề xuất đáng tin cậy. Ngoài ra, nó tạo ra cơ hội mà qua đó đa số độc hại có thể áp đặt các hình phạt nặng nề đối với những người xây dựng khối mà họ không thích.

Đối với vấn đề này, tôi nghĩ có hai cách để giảm bớt vấn đề này:

1 Bằng chứng Có khoảng thời gian trễ 2 giây giữa thời gian tối đa mà một người cần để chấp nhận một lời đề nghị và thời gian tối đa họ cần để chấp nhận một thi thể. Điều này về cơ bản giải quyết được vấn đề nếu bạn tin tưởng vào người chứng minh, mặc dù vấn đề cơ bản về việc những người xây dựng khối có nguy cơ mất tiền vẫn còn. Hơn nữa, không rõ liệu người chứng minh có được khuyến khích bỏ phiếu theo cách này hay không (mặc dù họ có thể bị buộc phải chờ bằng cách yêu cầu họ chứng minh giải pháp VDF dài 2 giây cho một đề xuất).

2. Nếu phần thân không được đưa vào, người đề xuất chỉ nhận được một nửa số tiền thanh toán (và người xây dựng khối chỉ nhận được một nửa). Điều này làm cho chi phí cho thiệt hại có ác ý do những người đề xuất gây ra cao, nhưng nó vẫn đảm bảo rằng chi phí cho thiệt hại có ác ý do những người xây dựng khối gây ra vẫn ở mức cao (trong cả hai trường hợp, chi phí đủ cao để khiến bạn tin rằng ngay cả những người tham gia ẩn danh cũng không muốn làm điều đó ) . Ví dụ: nếu phí đề xuất của một gói là 1 và lợi nhuận của người xây dựng khối là 1,05:

(1) Hành vi trung thực sẽ dẫn đến (người xây dựng, Người đề xuất) phần thưởng là (0,05, 1);

(2) Người đề xuất hoặc người chứng minh xuất bản quá muộn, khiến một khối chỉ có tiêu đề tiêu đề được chấp nhận, sau đó trả lại là (-0,5, 0,5);

Ý tưởng 2

1. bó và xuất bản các tiêu đề gói mà họ tạo. Tiêu đề gói chứa cam kết về nội dung, khoản thanh toán cho người đề xuất và chữ ký của người xây dựng.

2. Người đề xuất chọn và ký vào một tuyên bố bao gồm danh sách các tiêu đề gói mà họ đã xem.

3 Sau khi nhìn thấy tuyên bố này, trình tạo khối được chọn sẽ xuất bản phần thân gói tương ứng của nó.

4. Người đề xuất chọn tiêu đề gói từ danh sách cam kết trước của họ và sử dụng nó để xuất bản đề xuất.

Có một điều kiện chặt chém mới sẽ trục xuất và trừng phạt bất kỳ người đề xuất nào đưa ra đề xuất không thuộc danh sách (trong cùng một khoảng thời gian).

Cũng lưu ý rằng danh sách tiêu đề gói do người đề xuất gửi ở bước (2) cũng có thể là danh sách băm mật mã của tiêu đề, trong đó mỗi hàm băm Ẩn vào khóa công khai của người xây dựng gói để chỉ người xây dựng mới biết liệu chúng có được chấp nhận hay không. Điều này làm giảm nguy cơ bị tấn công DoS.

Phân tích

Tương tự, ba trong số năm thuộc tính dễ dàng được đáp ứng:

1. Người đề xuất không thể lấy trộm các gói vì họ chỉ có thể xem bất kỳ gói nào nếu họ đã giới hạn bản thân trong một tập hợp giới hạn nội dung gói tiêu đề gói hiện có.
2. Nếu không bao gồm toàn bộ nội dung, khoản thanh toán từ người xây dựng cho người đề xuất sẽ không thể xảy ra, vì vậy người đề xuất không thể lừa gạt người xây dựng về mặt tài chính.
3. Các thuộc tính đồng thuận vẫn giống như trước đây, bởi vì hệ thống vẫn là một trò chơi trong đó người đề xuất là tác nhân cuối cùng và những gì quy tắc đồng thuận xác định không thay đổi.

Hai trong số những đặc tính khó đảm bảo hơn trong trường hợp này là tính thân thiện với người đề xuất yếu và tính thân thiện với người xây dựng khối không đáng tin cậy. Điều đáng lo ngại là những kẻ xây dựng khối độc hại có thể tấn công những người đề xuất bằng cách đưa ra một số lượng lớn đề xuất, tất cả đều đưa ra mức phí rất cao nhưng không bao giờ xuất bản nội dung của bất kỳ đề xuất nào. Nếu những người đề xuất có giới hạn về số lượng gói mà họ chấp nhận thì cuộc tấn công này có thể định giá tất cả các gói hợp pháp và khiến người đề xuất không có gói nào có thể được đưa vào khối của họ một cách hợp pháp. Nếu không có giới hạn trên về số lượng gói mà người đề xuất có thể chấp nhận thì điều này có thể dẫn đến việc gửi số lượng gói đầy đủ không giới hạn (nghĩ là 500 kb mỗi gói) cho người đề xuất, đây là một yêu cầu băng thông rất lớn.

Một giải pháp cho vấn đề này là giới hạn tỷ lệ gửi tiêu đề gói theo một số cách không giới hạn cứng.

1. Chi phí gửi gói gói được điều chỉnh thông qua một số cơ chế tương tự như EIP-1559 để đạt được một tỷ lệ nhất định (ví dụ: 8 gói gói cho mỗi vị trí) .

2. Yêu cầu gửi tiền với tư cách là người xây dựng khối và quy tắc là khi bao gồm gói gói có giá thấp hơn nhưng gói gói bạn đã xuất bản không được bao gồm thì bạn không thể chấp nhận gói đó. cho các khe N.

Bản thân khoản phí này cũng chỉ có thể bị tính nếu nó không được bao gồm trong gói của bạn nhưng được bao gồm trong gói có giá thấp hơn, vì đây là những gì bạn có thể cụ thể trường hợp xảy ra hành vi nguy hiểm (người đề xuất có ác ý hoặc mạng lúc đó kém).

Đã có tiền lệ cho việc này, chẳng hạn như cuộc đấu giá ENS tính phí thua 0,5% để ngăn cản mọi người đấu giá khi họ rõ ràng sẽ không thắng (chỉ để tăng số tiền người thắng cuộc phải trả).

Tuy nhiên, những kỹ thuật này có nguy cơ đưa ra các yêu cầu về độ tin cậy đối với người đề xuất, vì vậy chúng cần được thực hiện một cách thận trọng và sẽ bị phạt nếu không bao gồm một gói không nên quá cao.

Một giải pháp khác là cho phép xuất bản phần thân gói miễn phí và không giới hạn, nhưng hạn chế việc truyền bá phần thân ở lớp mạng. Một thuật toán đơn giản là:

1. Thêm một chút độ trễ vào thời gian tối thiểu mà nội dung gói có thể được truyền bá: gói trả cao nhất Độ trễ của gói là 0 giây, độ trễ của gói trả cao thứ hai là 0,2 giây, độ trễ của gói trả cao thứ ba là 0,38 giây, gói trả cao thứ K bị trễ

giây.

1. Thêm quy tắc rằng nếu nút đã phát nội dung gói có thu nhập cao hơn thì nút đó sẽ không phát sóng nội dung bó khác.

Có thể kết hợp hai kỹ thuật này: với một khoản phí nhỏ, bạn có thể giảm số lượng gói dự kiến xuống (ví dụ: 50 gói mỗi vị trí) và sau đó sử dụng các cơ chế lớp mạng như vậy để giảm hơn nữa yêu cầu về băng thông.

Kết luận

Cho đến bây giờ, tôi không chắc liệu hai phương pháp trên có phải là phương pháp hay không Giải pháp cho vấn đề là cách duy nhất, có thể có những cách khác. Trong hai cách tiếp cận, ý tưởng (1) đơn giản hơn về mặt khái niệm, nhưng nó gây ra rủi ro cho người xây dựng khối và các yêu cầu quy tắc tùy chọn phân nhánh phức tạp hơn.

Từ góc độ lựa chọn phân nhánh và đồng thuận, ý tưởng (2) đơn giản hơn, nhưng nó có những thách thức trong việc đối phó với các cuộc tấn công DoS của trình tạo khối độc hại và bất kỳ giải pháp nào cho vấn đề này vấn đề cũng có khả năng tạo ra các vấn đề khác (mặc dù điều này có thể được giảm thiểu). Cho đến giờ tôi vẫn chưa chắc lựa chọn nào tốt hơn.

Liên kết gốc

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia