Giải thích chi tiết về nguyên lý hoạt động của quy tắc lựa chọn nhánh MEV-Boost và Ethereum

Tiêu đề gốc: "Thời gian, vị trí và thứ tự các sự kiện trong Bằng chứng cổ phần của Ethereum"

Tác giả gốc: Georgios Konstantopoulos, Mike Neuder

Bản tổng hợp gốc: Kxp , BlockBeats

Giới thiệu

Vào ngày 2 tháng 4, các hacker mạng Ethereum độc hại đã khai thác MEV -Vulnerability in Rơle tăng cường đã đánh cắp 20 triệu đô la từ một người tìm kiếm MEV (xem báo cáo). Trong vài ngày tiếp theo, các nhà phát triển đã giải quyết lỗ hổng này bằng cách phát hành năm bản vá. Các bản vá này, kết hợp với sự chậm trễ của mạng và chính sách xác thực, đã khiến mạng Ethereum gặp phải những biến động ngắn vào ngày 6 tháng 4. Các khối được tổ chức lại có tác động tiêu cực đến tình trạng mạng vì chúng làm chậm tốc độ sản xuất khối và giảm đảm bảo thanh toán (đảm bảo giải quyết).

Trong bài viết này, khi người tìm kiếm đang bị tấn công và mạng tạm thời không ổn định, chúng tôi khám phá sự tương tác giữa MEV-Boost và sự đồng thuận, phân tích Sự tinh tế trong bằng chứng của Ethereum cơ chế cổ phần và liệt kê một số con đường có thể tiến về phía trước.

MEV-Boost và tầm quan trọng của nó

MEV-Boost được thiết kế bởi Flashbots và cộng đồng Một giao thức được thiết kế để giảm thiểu tác động tiêu cực của Giá trị có thể trích xuất tối đa (MEV) trên mạng Ethereum.

Có 3 người tham gia MEV-Boost:

1. Tiếp sức—— Người bán đấu giá tin tưởng lẫn nhau, kết nối nhà sản xuất khối và người xây dựng khối

2. Builder - một thực thể phức tạp xây dựng các khối để tối đa hóa MEV của chính nó và nhà sản xuất khối

3. Nhà sản xuất khối - Trình xác thực bằng chứng cổ phần của Ethereum

Chuỗi sự kiện gần đúng cho mỗi khối là:

1. Trình xây dựng thu thập thông tin từ người dùng và người tìm kiếm hoặc những người khác (riêng tư hoặc công khai) luồng lệnh nhận các giao dịch để tạo khối

2. Người xây dựng gửi khối tới rơle

3. Rơle xác minh tính hợp lệ của khối và tính toán số lượng của nó thanh toán cho nhà sản xuất khối

4. Rơle gửi một tiêu đề trống và giá trị thanh toán cho nhà sản xuất khối của vị trí hiện tại

5. Nhà sản xuất khối đánh giá số tiền họ nhận được từ tất cả đặt giá thầu và ký vào một tiêu đề trống liên quan đến khoản thanh toán cao nhất

6. Nhà sản xuất khối gửi tiêu đề đã ký này trở lại rơle

7. Rơle sử dụng các nút Beacon gốc của họ để xuất bản các khối và trả lại chúng cho người tặng khối. Phần thưởng được phân phối cho người xây dựng và người đề xuất thông qua các giao dịch trong khối và phần thưởng khối.

Rơle là bên thứ ba đáng tin cậy tạo điều kiện trao đổi công bằng không gian khối giữa nhà sản xuất khối và nhà xây dựng để lấy thứ tự giao dịch MEV . Rơle bảo vệ người xây dựng bằng cách bảo vệ họ khỏi hành vi trộm MEV, ngăn chặn các nhà sản xuất khối sao chép các giao dịch của người xây dựng để lấy đi MEV mà không phân phối nó cho người tìm kiếm/người xây dựng đã phát hiện ra nó. Rơle bảo vệ các nhà sản xuất khối bằng cách xác nhận tính hợp lệ của các khối của họ, thay mặt họ xử lý hàng trăm khối trên mỗi khe và đảm bảo tính chính xác của các khoản thanh toán của nhà sản xuất khối.

MEV-Boost là cơ sở hạ tầng giao thức quan trọng vì nó cho phép tất cả các nhà sản xuất khối truy cập MEV một cách dân chủ mà không cần thiết lập kết nối với người xây dựng hoặc người tìm kiếm. góp phần vào sự phân quyền lâu dài của Ethereum.

Quy tắc lựa chọn phân nhánh của Ethereum và MEV-Boost

Trước khi thảo luận về các cuộc tấn công và phản ứng, trước tiên chúng ta hãy hãy xem cơ chế bằng chứng cổ phần của Ethereum và các quy tắc lựa chọn nhánh liên quan. Quy tắc lựa chọn phân nhánh cho phép mạng đạt được sự đồng thuận về người đứng đầu chuỗi, điều này được xác định trong bài viết "Tái tổ chức sau sáp nhập Ethereum":

"Quy tắc lựa chọn phân nhánh là một hàm được khách hàng đánh giá, lấy các khối đầu vào và các thông báo khác đã được nhìn thấy rồi xuất ra một "chuỗi chuẩn" cho khách hàng. Các quy tắc lựa chọn nhánh rất quan trọng vì có thể có nhiều chuỗi hợp lệ để lựa chọn (ví dụ: nếu hai khối cạnh tranh có cùng cha mẹ được phát hành cùng một lúc). 》

Các quy tắc lựa chọn ngã ba cũng liên quan đến thời gian, điều này có tác động đáng kể đến việc sản xuất khối.

thời điểm và thời điểm phụ

Trong cơ chế bằng chứng cổ phần của Ethereum, thời gian được chia thành các ô cứ sau 12 giây. Thuật toán bằng chứng cổ phần chỉ định ngẫu nhiên giấy phép cho người xác nhận để đề xuất một khối trong vị trí đó; người xác nhận này được gọi là nhà sản xuất khối. Trong cùng một vị trí, những người xác nhận khác được giao nhiệm vụ xác thực (bỏ phiếu) cho người đứng đầu chuỗi bằng cách áp dụng các quy tắc lựa chọn nhánh dựa trên chế độ xem cục bộ của họ. Khoảng thời gian 12 giây được chia thành ba giai đoạn, mỗi giai đoạn tiêu tốn 4 giây.

Các sự kiện xảy ra trong ô như sau, trong đó t=0 biểu thị điểm bắt đầu của ô.

Trong thời gian diễn ra, cuối cùng Thời điểm quan trọng là thời hạn chứng nhận tại t=4. Nếu người xác thực chứng nhận không nhìn thấy khối trước thời hạn chứng nhận, họ sẽ bỏ phiếu cho tiêu đề được chấp nhận trước đó trên chuỗi (theo quy tắc lựa chọn nhánh). Khối được đề xuất càng sớm thì khối đó càng có nhiều thời gian để phổ biến và do đó tích lũy được nhiều chứng nhận hơn (vì càng có nhiều người xác nhận nhìn thấy nó trước thời hạn chứng nhận).

Từ góc độ tình trạng mạng, thời gian tối ưu để phát hành khối là t=0 (theo thông số kỹ thuật). Tuy nhiên, do giá trị khối tăng đều đặn theo thời gian nên các nhà sản xuất khối có động cơ trì hoãn việc phát hành khối của họ để tích lũy nhiều MEV hơn. Để biết thêm thông tin, hãy xem  Trò chơi tính giờ trong Proof-of-Stake   và cuộc thảo luận này .

Trước đây, nhà sản xuất khối có thể xuất bản khối sau thời hạn chứng nhận (hoặc thậm chí gần hết thời hạn), miễn là người xác nhận tiếp theo đang thiết lập khe tiếp theo của nó. Chỉ cần quan sát khối trước khối. Điều này là do khối con kế thừa trọng số của khối cha và quy tắc lựa chọn nhánh kết thúc ở nút lá. Do đó, việc trì hoãn phát hành khối không có tác dụng phụ. Để giúp chuyển hành vi hợp lý (trì hoãn phát hành khối) sang hành vi trung thực (phát hành đúng thời hạn), một "tổ chức lại trung thực" đã được thực hiện.

Cơ chế khen thưởng nhà sản xuất khối và tổ chức lại trung thực

Hai khái niệm mới đã được giới thiệu trong ứng dụng khách đồng thuận , nó có tác động quan trọng đến thời hạn chứng nhận.

1. Cơ chế khen thưởng của nhà sản xuất khối - được thiết kế để giảm thiểu các cuộc tấn công cân bằng tổ chức lại bằng cách cấp cho các nhà sản xuất khối một "phần thưởng" lựa chọn phân nhánh bằng 40% tổng trọng số chứng nhận. Điều quan trọng là phần thưởng này chỉ kéo dài trong toàn bộ vị trí.

2. Tổ chức lại trung thực - sử dụng khả năng tăng tốc của nhà sản xuất khối để cho phép các nhà sản xuất khối trung thực buộc tổ chức lại các khối có trọng số chứng nhận thấp hơn 20%. Điều này đã được triển khai trong Lighthouse và Prysm (kể từ phiên bản v4.0 - Capella). Thay đổi này là tùy chọn vì đây là quyết định của nhà sản xuất khối và không ảnh hưởng đến hành vi của người xác thực được chứng nhận. Vì vậy, chúng tôi không áp dụng nó cho tất cả khách hàng cùng một lúc và cũng không bị ràng buộc với bất kỳ hard fork cụ thể nào.

Cần lưu ý tránh tổ chức lại một cách trung thực trong một số trường hợp đặc biệt:

1. Trong khối ranh giới kỷ nguyên 

2. Nếu chuỗi chưa được hoàn thiện 

3. Nếu đầu chuỗi không phải là đầu của khe trước khi tổ chức lại

Trường hợp 3 đảm bảo rằng việc tổ chức lại một cách trung thực sẽ chỉ loại bỏ một khối khỏi chuỗi, hoạt động như một bộ ngắt mạch, cho phép chuỗi tiếp tục tạo ra các khối trong thời gian mạng có độ trễ cực cao. Điều này cũng phản ánh sự tin tưởng ngày càng giảm của những người đề xuất đối với tầm nhìn của mạng, vì họ không thể chắc chắn liệu các khối mà họ đề xuất nâng cao có được coi là chuẩn hay không.

Biểu đồ dưới đây cho thấy hành vi trung thực có thể được thay đổi như thế nào để thực hiện chiến lược tái tổ chức.

Trong trường hợp này, hãy để b1 đại diện cho một khối muộn. Do độ trễ nên b1 chỉ có 19% trọng lượng bằng chứng của khe thứ n. 81% trọng số chứng minh còn lại được gán cho khối mẹ HEAD vì nhiều người chứng minh đã không nhìn thấy b1 trước thời hạn chứng minh.

Nếu không tổ chức lại một cách trung thực, người đề xuất vị trí n+1 sẽ coi b1 là người đứng đầu chuỗi và xây dựng khối con b2. Người đề xuất không nỗ lực tái cấu trúc b1, mặc dù nó chỉ có trọng số chứng minh là 19%. Tại vị trí n+1, b2 có tính năng nâng cao của người đề xuất và giả sử nó được giao đúng thời hạn, b2 sẽ trở thành chuẩn bằng cách tích lũy phần lớn các bằng chứng cho vị trí đó.

Với sự tái cơ cấu trung thực, mọi chuyện đã rất khác. Bây giờ, người đề xuất vị trí n+1 thấy rằng trọng số bằng chứng 19% của b1 nằm dưới ngưỡng sắp xếp lại, vì vậy họ xây dựng một khối với HEAD làm khối chính và buộc tổ chức lại b1. Khi chúng tôi đạt đến thời hạn chứng minh cho vị trí n+1, người chứng minh trung thực sẽ so sánh trọng số tương đối của b1 (19%) với b2 (tăng 40% từ người đề xuất). Tất cả khách hàng đều triển khai việc tăng cường người đề xuất, vì vậy b2 sẽ được coi là người đứng đầu chuỗi và sẽ tích lũy bằng chứng cho vị trí thứ n+1.

Sửa lỗi nút chuyển tiếp và đèn hiệu để tách các cuộc tấn công 

Bỏ nhóm vào ngày 2 tháng 4 Trong cuộc tấn công, kẻ đề xuất đã lợi dụng lỗ hổng chuyển tiếp để gửi tiêu đề chữ ký không hợp lệ đến chuyển tiếp. Trong vài ngày tiếp theo, nhóm phát triển cốt lõi và cốt lõi đã phát hành một số bản vá phần mềm để giảm thiểu nguy cơ bị tấn công lặp lại. Năm thay đổi chính như sau:

Thay đổi rơ-le: Kiểm tra cơ sở dữ liệu để tìm những kẻ đề xuất độc hại đã biết (chỉ được sử dụng trong sản xuất bởi Sonic Relay và đã bị xóa). Kiểm tra xem rơle đã phân phối một khối hoàn chỉnh tới một khe trong mạng P2P hay chưa. Giới thiệu độ trễ ngẫu nhiên thống nhất trong phạm vi 0-500ms trước khi xuất bản chunk (được loại bỏ khỏi tất cả các rơle).

Thay đổi nút báo hiệu (chỉ áp dụng cho các nút báo hiệu chuyển tiếp): Xác minh khối đèn hiệu trước khi phát sóng. Kiểm tra mạng để tìm các xác nhận xấu trước khi xuất bản một khối. Sự kết hợp của những thay đổi này đã dẫn đến sự mất ổn định trong sự đồng thuận, một vấn đề trở nên trầm trọng hơn do thực tế là một tỷ lệ lớn người xác nhận hiện sử dụng chiến lược tổ chức lại trung thực được mô tả ở trên.

Hậu quả ngoài ý muốn 

Năm thay đổi trên đều được công bố trong khối chuyển tiếp Độ trễ là được đưa vào đường dẫn nóng, điều này làm tăng khả năng khối chuyển tiếp sẽ được phát sóng sau thời hạn xác nhận. Sơ đồ bên dưới hiển thị trình tự của năm lần kiểm tra này và cách thức mà sự chậm trễ được đưa ra có thể khiến các khối được xuất bản quá thời hạn xác nhận.

Trước khi thực hiện những kiểm tra này, một số lượng lớn các tiêu đề đã ký có độ trễ vượt quá t = 0 (ví dụ: t = 3) thường không gây ra vấn đề gì. Vì rơle có chi phí rất thấp nên nó sẽ xuất bản khối trước t = 4 mà không cần đợi thời hạn xác nhận.

Tuy nhiên, do việc giới thiệu năm bản sửa lỗi này bị chậm trễ, các trạm chuyển tiếp hiện có thể phải chịu một phần trách nhiệm đối với việc phát sóng bị trì hoãn. Hãy cùng xem quá trình xuất bản khối giả định bên dưới.

Rơle ở thời điểm t = Vào lúc 3, tiêu đề đã ký được nhận từ nhà sản xuất khối. Đến thời điểm t = 4, rơle vẫn đang thực hiện kiểm tra nên việc phát quảng bá sẽ diễn ra sau thời hạn báo nhận. Trong trường hợp này, sự kết hợp giữa tiêu đề có chữ ký bị trì hoãn do nhà sản xuất khối gửi và một số độ trễ bổ sung do rơle đưa ra đã dẫn đến việc không phát sóng trước thời hạn xác nhận. Nếu không có sự tổ chức lại một cách trung thực, các khối này có thể đã lọt vào chuỗi. Như được hiển thị trong Hình 2, các nhà sản xuất khối trung thực ở ô tiếp theo sẽ không cố tình tổ chức lại vì các khối này bị trễ. Tuy nhiên, nếu trễ thời hạn xác nhận, các khối sẽ được nhà sản xuất khối tiếp theo tổ chức lại.

Kết quả là số lượng khối phân nhánh tăng lên đáng kể trong những ngày sau cuộc tấn công.

Dữ liệu trong hai tuần của Metrika Nó cho thấy trong trường hợp xấu nhất, 13 khối (4,3%) có thể được tổ chức lại trong một giờ, gấp khoảng 5 lần so với bình thường. Khi rơle triển khai nhiều thay đổi khác nhau, số lượng khối phân nhánh đã tăng lên đáng kể. Nhờ nỗ lực cộng đồng tuyệt vời của các nhà khai thác chuyển tiếp và nhà phát triển cốt lõi, sau khi hiểu được tác động, nhiều thay đổi đã được đảo ngược và mạng trở lại trạng thái khỏe mạnh.

Tính đến hôm nay, những thay đổi hữu ích nhất là xác thực khối nút báo hiệu và kiểm tra tính chống chối bỏ trước khi phát hành. Các nhà sản xuất khối độc hại không còn có thể thực hiện các cuộc tấn công bằng cách gửi các tiêu đề không hợp lệ tới các nút chuyển tiếp và đảm bảo rằng các nút báo hiệu chuyển tiếp không nhìn thấy khối từ chối trước khi xuất bản nó. Tuy nhiên, rơle vẫn phải đối mặt với các cuộc tấn công từ chối tổng quát hơn được đề xuất trong MEV-Boost và ePBS.

Các bước tiếp theo

Trong bài viết này, chúng tôi nêu bật Cách thức hoạt động và cách thức hoạt động của MEV-Boost điều quan trọng là sự đồng thuận của Ethereum. Chúng tôi cũng cung cấp phân tích chi tiết về một số khía cạnh ít được biết đến hơn trong quy tắc lựa chọn nhánh của Ethereum vì chúng liên quan đến thời gian. Bằng cách sử dụng các cuộc tấn công "không ràng buộc" và phản hồi của nhà phát triển làm nghiên cứu điển hình, chúng tôi nêu bật lỗ hổng tiềm ẩn về các khía cạnh liên quan đến thời gian của quy tắc lựa chọn nhánh và tác động của chúng đối với sự ổn định của mạng.

Với suy nghĩ này, cộng đồng nghiên cứu nên đánh giá số lượng tổ chức lại "có thể chấp nhận được" và xem xét mức độ phổ biến hơn của các cuộc tấn công từ chối từ chối đối với xác định xem có nên thực hiện các biện pháp giảm thiểu hay không.

Ngoài ra, nhiều hướng đi trong tương lai hiện đang được tích cực khám phá:

1. Thực hiện một Cơ chế khóa đầu để bảo vệ MEV-Boost khỏi các cuộc tấn công lỗi tương đương. Điều này cũng sẽ yêu cầu thay đổi phần mềm máy khách đồng thuận và có thể thay đổi thông số kỹ thuật để kéo dài thời gian gửi bằng chứng.

2. Tăng số lượng và phổ biến các chương trình tìm lỗi thưởng cho phần mềm MEV-Boost.

3. Mở rộng phần mềm mô phỏng để khám phá mức độ ảnh hưởng của thời gian của khe phụ đến độ ổn định của mạng, phần mềm này có thể được sử dụng để đánh giá cách điều chỉnh thời hạn gửi bằng chứng nhằm giảm việc tổ chức lại.

4. Tối ưu hóa đường dẫn giải phóng khối trên rơle để giảm độ trễ không cần thiết - điều này đã được khám phá.

5. Công nhận MEV-boost là chức năng giao thức cốt lõi và kết hợp nó vào ứng dụng khách đồng thuận, cụ thể là "enshured-PBS (ePBS)". ePBS hai khe dễ bị tấn công rõ ràng, vì vậy việc triển khai "cơ chế khóa đầu" vẫn là một lựa chọn.

6. Tăng cường kiểm tra tổ ong và/hoặc thông số kỹ thuật bằng cách giải quyết các vấn đề xung quanh độ trễ và thời hạn cấp giấy chứng nhận.

7. Khuyến khích sự đa dạng của các máy khách chuyển tiếp bằng cách xây dựng các triển khai khác của đặc tả chuyển tiếp.

8. Hãy cân nhắc việc điều chỉnh các hình phạt đối với các cuộc tấn công rõ ràng, nhưng hãy nhớ rằng ngay cả hình phạt đầy đủ 32 ETH cũng không thể ngăn chặn hành vi nguy hiểm khi tồn tại cơ hội MEV rất lớn.

9. Xem lại thời gian của khe phụ và xem xét điều chỉnh giai đoạn lan truyền khối (ví dụ: điều chỉnh thời hạn chứng nhận từ t=4 thành t=6).

Nhìn chung, chúng tôi rất vui mừng về sự hồi sinh của MEV và hệ sinh thái mev-boost. Thông qua việc tách nhóm các cuộc tấn công và biện pháp giảm thiểu, chúng tôi đã biết được mối quan hệ quan trọng giữa độ trễ, mức tăng MEV và cơ chế đồng thuận; chúng tôi hy vọng rằng giao thức có thể tiếp tục được tăng cường để giải quyết tình huống này.

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