Vào ngày 2 tháng 4, các tác nhân mạng Ethereum độc hại đã khai thác lỗ hổng trong chuyển tiếp MEV-Boost để đánh cắp 20 triệu đô la từ một người tìm kiếm MEV (xem báo cáo Flashbots). Trong vài ngày tới, các nhà phát triển đã giải quyết lỗ hổng 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 của trình xác thực, đã gây ra một biến động ngắn trong mạng Ethereum vào ngày 6 tháng 4. Việc sắp xếp lại các khối có thể gây bất lợi cho sức khỏe của 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.
Trong bài đăng này, với việc 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ế của cơ chế bằng chứng cổ phần của Ethereum và liệt kê một số cách có thể thực hiện.
MEV-Boost và tại sao nó lại quan trọng
MEV-Boost là một giao thức được thiết kế bởi Flashbots và cộng đồng để 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 diễn viên trong MEV-Boost:
Tiếp sức - Những người đấu giá tin tưởng lẫn nhau, kết nối nhà sản xuất khối và nhà xây dựng khối
Người xây dựng - các thực thể phức hợp xây dựng các khối để tối đa hóa MEV cho chính họ và người tạo khối
Nhà sản xuất khối - Trình xác minh bằng chứng cổ phần của Ethereum
Trình tự gần đúng của các sự kiện cho mỗi khối là:
Người xây dựng tạo khối bằng cách nhận giao dịch từ người dùng, người tìm kiếm hoặc các luồng đặt hàng (riêng tư hoặc công khai) khác
Người xây dựng gửi khối cho rơle
Rơle xác minh tính hợp lệ của khối và tính toán số tiền nó trả cho nhà sản xuất khối
Người chuyển tiếp gửi 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
Nhà sản xuất khối đánh giá tất cả các giá thầu mà họ đã nhận được và ký vào tiêu đề trống liên quan đến khoản thanh toán cao nhất
Nhà sản xuất khối gửi tiêu đề đã ký này trở lại rơle
Rơle xuất bản các khối bằng cách sử dụng các nút đèn hiệu gốc của chúng và trả lại chúng cho người cung cấp 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.
Chuyển tiếp là một 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 bởi các nhà sản xuất khối và yêu cầu giao dịch của các nhà xây dựng để trích xuất MEV. Rơle bảo vệ các nhà xây dựng bằng cách bảo vệ các nhà xây dựng khỏi hành vi trộm cắp MEV, ngăn chặn các nhà sản xuất khối sao chép các giao dịch của nhà xây dựng để lấy MEV đi mà không phân phối nó cho những người tìm kiếm/nhà xây dựng đã tìm thấy nó. Chuyển tiếp 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 vị trí và đảm bảo tính chính xác của các khoản thanh toán cho 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 yêu cầu mối quan hệ tin cậy với các nhà xây dựng hoặc người tìm kiếm, điều này góp phần vào sự phân cấp lâu dài của Ethereum.
Quy tắc lựa chọn fork của Ethereum và MEV-Boost
Trước khi thảo luận về cuộc tấn công và phản ứng, chúng ta 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 fork liên quan. Quy tắc lựa chọn ngã ba cho phép mạng đạt được sự đồng thuận về người đứng đầu chuỗi, như được định nghĩa trong bài viết "Tổ chức lại sau khi sáp nhập Ethereum":
“Quy tắc lựa chọn ngã ba là một chức năng được đánh giá bởi ứng dụng khách, lấy các khối đã nhìn thấy và thông tin khác làm đầu vào, đồng thời xuất ra “chuỗi chuẩn” cho ứng dụng khách. Quy tắc lựa chọn ngã ba 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 khối gốc được xuất bản cùng một lúc). "
Các quy tắc lựa chọn ngã ba cũng phụ thuộc vào thời gian, điều này có tác động đáng kể đến việc tạo khối.
chu kỳ khe và khe phụ
Trong cơ chế bằng chứng cổ phần của Ethereum, thời gian được chia thành các khe cứ sau 12 giây. Thuật toán bằng chứng cổ phần chỉ định ngẫu nhiên cho người xác thực giấy phép để đề xuất một khối trong vị trí đó; người xác thực 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 thực khác được giao nhiệm vụ xác thực (bỏ phiếu) cho người đứng đầu chuỗi áp dụng các quy tắc lựa chọn rẽ nhánh theo quan điểm cục bộ của họ. Khe 12 giây này được chia thành ba giai đoạn, mỗi giai đoạn tốn 4 giây.
Các sự kiện xảy ra trong vị trí như sau, trong đó t=0 biểu thị phần đầu của vị trí.
Trong thời điểm, thời điểm quan trọng nhất là thời hạn xác thực tại t=4. Nếu những người xác thực chứng thực không nhìn thấy khối trước thời hạn chứng thực, họ sẽ bỏ phiếu cho người đứng đầu chuỗi được chấp nhận trước đó (theo quy tắc lựa chọn ngã ba). Một khối được đề xuất càng sớm thì càng có nhiều thời gian để truyền bá và do đó tích lũy được nhiều phê duyệt hơn (vì nhiều người xác nhận sẽ nhìn thấy khối đó trước thời hạn phê duyệt).
Từ góc độ tình trạng mạng, thời gian tối ưu để giải phóng khối là t=0 (theo thông số kỹ thuật). Tuy nhiên, vì 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 các khối của họ để có thể tích lũy thêm MEV. Xem Trò chơi tính thời gian trong Proof-of-Stake và cuộc thảo luận này để biết chi tiết.
Trước đây, một nhà sản xuất khối có thể xuất bản một khối sau thời hạn chứng nhận (thậm chí gần đến cuối vị trí), miễn là người xác thực tiếp theo quan sát thấy khối đó trước khi thiết lập khối cho vị trí tiếp theo của nó. Điều này là do khối con kế thừa trọng số của khối cha và quy tắc chọn rẽ nhánh kết thúc tại nút lá. Do đó, 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ý (hoãn phát hành khối) sang hành vi trung thực (xuất bản đúng hạn), một "tổ chức lại trung thực" đã được triển khai.
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 đưa vào ứng dụng khách đồng thuận có tác động quan trọng đến thời hạn xác thực.
Cơ chế thưởng cho nhà sản xuất khối - Nhằm mục đích giảm thiểu các cuộc tấn công tái cân bằng bằng cách thưởng cho các nhà sản xuất khối một "phần thưởng" lựa chọn fork bằng 40% trọng lượng xác thực đầy đủ. Điều quan trọng, phần thưởng này chỉ kéo dài trong toàn bộ vị trí.
Tổ chức lại trung thực - tận 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ố xác thực dưới 20%. Điều này đã được triển khai trong Lighthouse và Prysm (bắt đầu với phiên bản 4.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 trình xác nhận xác thực. Vì vậy, chúng tôi không áp dụng nó cho tất cả các khách hàng cùng một lúc, cũng như không bị ràng buộc với bất kỳ hard fork cụ thể nào.
Cần lưu ý rằng tránh tổ chức lại trung thực trong một số trường hợp đặc biệt:
Trong các khối ranh giới kỷ nguyên
Nếu chuỗi chưa được hoàn thiện
Nếu người đứng đầu chuỗi không phải là người đứng đầu vị trí trước khi tổ chức lại
Trường hợp 3 đảm bảo rằng các tổ chức lại trung thực 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. Nó cũng phản ánh rằng những người đề xuất ít tin tưởng hơn vào nhận thức về mạng, vì họ không thể chắc chắn liệu các khối nâng cao được đề xuất của họ có được coi là tiêu chuẩn hay không.
Hình 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 cơ cấu.
Trong trường hợp này, hãy để b1 đại diện cho một khối muộn. Do độ trễ, b1 chỉ có 19% trọng lượng bằng chứng của vị trí thứ n. 81% trọng lượng bằng chứng còn lại được gán cho khối mẹ HEAD vì nhiều người chứng minh đã không xem b1 trước thời hạn chứng minh.
Nếu không có sự tổ chức lại 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 sắp xếp lại b1, mặc dù nó chỉ có 19% trọng lượng bằng chứng. Tại vị trí n+1, b2 có tính năng nâng cao của người đề xuất, giả sử nó được giao đúng hạn, b2 sẽ trở thành tiêu chuẩn bằng cách tích lũy phần lớn bằng chứng cho vị trí đó.
Với Tổ chức lại trung thực, mọi thứ rất khác. Bây giờ, người đề xuất vị trí n+1 nhận thấy rằng 19% trọng số bằng chứng của b1 nằm dưới ngưỡng tổ chức lại, vì vậy họ xây dựng một khối với HEAD làm cha mẹ và buộc b1 phải tổ chức lại. 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 (40% từ mức tăng của người đề xuất). Tất cả khách hàng đều triển khai cải tiến 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í n+1.
Các bản sửa lỗi nút Chuyển tiếp và Beacon cho các cuộc tấn công tách nhóm
Trong cuộc tấn công tách nhóm vào ngày 2 tháng 4, người đề xuất đã khai thác lỗ hổng chuyển tiếp để gửi tiêu đề chữ ký không hợp lệ tới chuyển tiếp. Trong vài ngày tới, các nhóm phát triển cốt lõi và chuyển tiếp đã phát hành nhiều 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 để biết các đề xuất độc hại đã biết (chỉ được sử dụng trong quá trình sản xuất bởi rơle siêu âm và đã bị xóa). Kiểm tra xem rơle đã chuyển toàn bộ khối tới một khe cắm trong mạng P2P chưa. Giới thiệu độ trễ ngẫu nhiên thống nhất trong phạm vi 0-500 mili giây trước khi một khối được xuất bản (bị xóa khỏi tất cả các rơle).
Thay đổi nút đèn hiệu (chỉ các nút đèn hiệu chuyển tiếp): Xác thực các khối đèn hiệu trước khi phát. Kiểm tra mạng để xác nhận sai 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 đồng thuận, một vấn đề trở nên trầm trọng hơn bởi thực tế là phần lớn những người xác nhận hiện đang sử dụng chiến lược tổ chức lại trung thực được mô tả ở trên.
HẬU QUẢ KHÔNG LƯỜNG
Năm thay đổi trên đều gây ra sự chậm trễ trong đường dẫn nóng của việc phát hành khối chuyển tiếp, điều này làm tăng khả năng các khối chuyển tiếp sẽ được phát sau thời hạn xác nhận. Sơ đồ bên dưới cho thấy trình tự của năm lần kiểm tra này và cách độ trễ được đưa ra khiến việc xuất bản khối vượt quá thời hạn xác nhận.
Một số lượng lớn các tiêu đề đã ký có độ trễ t = 0 (ví dụ: t = 3) thường không gây ra sự cố cho đến khi các kiểm tra này được thực hiện. Vì rơle có chi phí hoạt động 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 vá lỗi này bị trì hoãn, hiện tại rơle có thể chịu trách nhiệm một phần cho việc phát sóng bị trì hoãn. Hãy xem quy trình xuất bản khối giả định bên dưới.
Rơle nhận tiêu đề đã ký từ nhà sản xuất khối tại t = 3. Đến t = 4, rơle vẫn đang thực hiện kiểm tra, do đó, quảng bá sẽ xảy ra sau thời hạn xác nhận. Trong trường hợp này, sự kết hợp giữa tiêu đề đã 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 đã gây ra lỗi phát sóng trước thời hạn xác nhận. Nếu không có một cuộc tái tổ chức trung thực, những 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 của vị trí tiếp theo sẽ không cố ý sắp xếp lại vì các khối này bị trễ. Tuy nhiên, nếu thời hạn xác nhận bị bỏ lỡ, các khối sẽ được sắp xếp lại bởi nhà sản xuất khối tiếp theo.
Do đó, số lượng các khối được chia tách đã tăng lên đáng kể trong những ngày sau cuộc tấn công.
Dữ liệu hai tuần từ Metrika cho thấy trong trường hợp xấu nhất, 13 khối (4,3%) có thể được sắp xếp lại trong một giờ, gấp khoảng 5 lần tốc độ bình thường. Sự gia tăng đáng kể về số lượng khối được chia tách trở nên rõ ràng khi những người chuyển tiếp triển khai nhiều thay đổi khác nhau. Nhờ những nỗ lực tuyệt vời của cộng đồng của những người điều hành rơle và các nhà phát triển cốt lõi, khi tác động được biết đến, nhiều thay đổi đã được khôi phục và mạng được khôi phục về trạng thái khỏe mạnh.
Tính đến hôm nay, những thay đổi hữu ích nhất là kiểm tra xác thực và từ chối khối nút báo hiệu trước khi ban 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 các nút báo hiệu chuyển tiếp không nhìn thấy các khối bị từ chối trước khi xuất bản chúng. Tuy nhiên, các 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.
Hành động Tiếp theo
Trong bài đăng này, chúng tôi nhấn mạnh cách MEV-Boost hoạt động và tầm quan trọng của nó đối với sự đồng thuận của Ethereum. Chúng tôi cũng cung cấp một phân tích chi tiết về một số khía cạnh ít được biết đến của các quy tắc lựa chọn Ethereum fork liên quan đến thời gian. Sử dụng các phản ứng của nhà phát triển và cuộc tấn công "tách nhóm" làm nghiên cứu điển hình, chúng tôi nhấn mạnh lỗ hổng tiềm ẩn của các khía cạnh phụ thuộc vào thời gian của quy tắc lựa chọn ngã ba và tác động của nó đố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" là bao nhiêu, có tính đến mức độ phổ biến hơn của các cuộc tấn công từ chối, để xác định xem có nên thực hiện các biện pháp giảm nhẹ hay không.
Ngoài ra, một số hướng trong tương lai hiện đang được tích cực khám phá:
Triển khai 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 các thay đổi đối với phần mềm máy khách đồng thuận và có thể là các thay đổi về thông số kỹ thuật để kéo dài thời hạn gửi bằng chứng.
Tăng số lượng và phân phối các chương trình tiền thưởng lỗi cho phần mềm MEV-Boost.
Mở rộng phần mềm mô phỏng để khám phá cách thời gian của khe cắm phụ ảnh hưởng đến sự ổn định của mạng, 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.
Tối ưu hóa đường 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á.
Công nhận MEV-boost là một tính 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, tức là "PBS được lưu trữ (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 tùy chọn.
Bằng cách thêm nhiều bài kiểm tra hive và/hoặc thông số kỹ thuật xung quanh các vấn đề về độ trễ và thời hạn chứng nhận.
Khuyến khích sự đa dạng của máy khách chuyển tiếp bằng cách xây dựng các triển khai bổ sung của đặc tả chuyển tiếp.
Cân nhắc điều chỉnh 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 cơ hội MEV cực đoan tồn tại.
Xem lại thời gian của vị trí phụ và cân nhắc đ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 các cuộc tấn công và giảm thiểu phân nhóm, chúng tôi đã biết về mối quan hệ quan trọng giữa độ trễ, cơ chế tăng cường MEV và cơ chế đồng thuận; chúng tôi hy vọng giao thức sẽ tiếp tục được củng cố để xử lý vấn đề này.
Xem bản gốc
Nội dung chỉ mang tính chất tham khảo, không phải là lời chào mời hay đề nghị. Không cung cấp tư vấn về đầu tư, thuế hoặc pháp lý. Xem Tuyên bố miễn trừ trách nhiệm để biết thêm thông tin về rủi ro.
Giải thích chi tiết về nguyên tắc làm việc của MEV-Boost và quy tắc lựa chọn Ethereum fork
Tác giả: Georgios Konstantopoulos, Mike Neuder
Biên soạn: Kxp, BlockBeats
Giới thiệu
Vào ngày 2 tháng 4, các tác nhân mạng Ethereum độc hại đã khai thác lỗ hổng trong chuyển tiếp MEV-Boost để đánh cắp 20 triệu đô la từ một người tìm kiếm MEV (xem báo cáo Flashbots). Trong vài ngày tới, các nhà phát triển đã giải quyết lỗ hổng 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 của trình xác thực, đã gây ra một biến động ngắn trong mạng Ethereum vào ngày 6 tháng 4. Việc sắp xếp lại các khối có thể gây bất lợi cho sức khỏe của 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.
Trong bài đăng này, với việc 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ế của cơ chế bằng chứng cổ phần của Ethereum và liệt kê một số cách có thể thực hiện.
MEV-Boost và tại sao nó lại quan trọng
MEV-Boost là một giao thức được thiết kế bởi Flashbots và cộng đồng để 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 diễn viên trong MEV-Boost:
Tiếp sức - Những người đấu giá tin tưởng lẫn nhau, kết nối nhà sản xuất khối và nhà xây dựng khối
Người xây dựng - các thực thể phức hợp xây dựng các khối để tối đa hóa MEV cho chính họ và người tạo khối
Nhà sản xuất khối - Trình xác minh bằng chứng cổ phần của Ethereum
Trình tự gần đúng của các sự kiện cho mỗi khối là:
Người xây dựng tạo khối bằng cách nhận giao dịch từ người dùng, người tìm kiếm hoặc các luồng đặt hàng (riêng tư hoặc công khai) khác
Người xây dựng gửi khối cho rơle
Rơle xác minh tính hợp lệ của khối và tính toán số tiền nó trả cho nhà sản xuất khối
Người chuyển tiếp gửi 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
Nhà sản xuất khối đánh giá tất cả các giá thầu mà họ đã nhận được và ký vào tiêu đề trống liên quan đến khoản thanh toán cao nhất
Nhà sản xuất khối gửi tiêu đề đã ký này trở lại rơle
Rơle xuất bản các khối bằng cách sử dụng các nút đèn hiệu gốc của chúng và trả lại chúng cho người cung cấp 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.
Chuyển tiếp là một 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 bởi các nhà sản xuất khối và yêu cầu giao dịch của các nhà xây dựng để trích xuất MEV. Rơle bảo vệ các nhà xây dựng bằng cách bảo vệ các nhà xây dựng khỏi hành vi trộm cắp MEV, ngăn chặn các nhà sản xuất khối sao chép các giao dịch của nhà xây dựng để lấy MEV đi mà không phân phối nó cho những người tìm kiếm/nhà xây dựng đã tìm thấy nó. Chuyển tiếp 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 vị trí và đảm bảo tính chính xác của các khoản thanh toán cho 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 yêu cầu mối quan hệ tin cậy với các nhà xây dựng hoặc người tìm kiếm, điều này góp phần vào sự phân cấp lâu dài của Ethereum.
Quy tắc lựa chọn fork của Ethereum và MEV-Boost
Trước khi thảo luận về cuộc tấn công và phản ứng, chúng ta 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 fork liên quan. Quy tắc lựa chọn ngã ba cho phép mạng đạt được sự đồng thuận về người đứng đầu chuỗi, như được định nghĩa trong bài viết "Tổ chức lại sau khi sáp nhập Ethereum":
“Quy tắc lựa chọn ngã ba là một chức năng được đánh giá bởi ứng dụng khách, lấy các khối đã nhìn thấy và thông tin khác làm đầu vào, đồng thời xuất ra “chuỗi chuẩn” cho ứng dụng khách. Quy tắc lựa chọn ngã ba 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 khối gốc được xuất bản cùng một lúc). "
Các quy tắc lựa chọn ngã ba cũng phụ thuộc vào thời gian, điều này có tác động đáng kể đến việc tạo khối.
chu kỳ khe và khe phụ
Trong cơ chế bằng chứng cổ phần của Ethereum, thời gian được chia thành các khe cứ sau 12 giây. Thuật toán bằng chứng cổ phần chỉ định ngẫu nhiên cho người xác thực giấy phép để đề xuất một khối trong vị trí đó; người xác thực 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 thực khác được giao nhiệm vụ xác thực (bỏ phiếu) cho người đứng đầu chuỗi áp dụng các quy tắc lựa chọn rẽ nhánh theo quan điểm cục bộ của họ. Khe 12 giây này được chia thành ba giai đoạn, mỗi giai đoạn tốn 4 giây.
Các sự kiện xảy ra trong vị trí như sau, trong đó t=0 biểu thị phần đầu của vị trí.
Trong thời điểm, thời điểm quan trọng nhất là thời hạn xác thực tại t=4. Nếu những người xác thực chứng thực không nhìn thấy khối trước thời hạn chứng thực, họ sẽ bỏ phiếu cho người đứng đầu chuỗi được chấp nhận trước đó (theo quy tắc lựa chọn ngã ba). Một khối được đề xuất càng sớm thì càng có nhiều thời gian để truyền bá và do đó tích lũy được nhiều phê duyệt hơn (vì nhiều người xác nhận sẽ nhìn thấy khối đó trước thời hạn phê duyệt).
Từ góc độ tình trạng mạng, thời gian tối ưu để giải phóng khối là t=0 (theo thông số kỹ thuật). Tuy nhiên, vì 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 các khối của họ để có thể tích lũy thêm MEV. Xem Trò chơi tính thời gian trong Proof-of-Stake và cuộc thảo luận này để biết chi tiết.
Trước đây, một nhà sản xuất khối có thể xuất bản một khối sau thời hạn chứng nhận (thậm chí gần đến cuối vị trí), miễn là người xác thực tiếp theo quan sát thấy khối đó trước khi thiết lập khối cho vị trí tiếp theo của nó. Điều này là do khối con kế thừa trọng số của khối cha và quy tắc chọn rẽ nhánh kết thúc tại nút lá. Do đó, 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ý (hoãn phát hành khối) sang hành vi trung thực (xuất bản đúng hạn), một "tổ chức lại trung thực" đã được triển khai.
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 đưa vào ứng dụng khách đồng thuận có tác động quan trọng đến thời hạn xác thực.
Cơ chế thưởng cho nhà sản xuất khối - Nhằm mục đích giảm thiểu các cuộc tấn công tái cân bằng bằng cách thưởng cho các nhà sản xuất khối một "phần thưởng" lựa chọn fork bằng 40% trọng lượng xác thực đầy đủ. Điều quan trọng, phần thưởng này chỉ kéo dài trong toàn bộ vị trí.
Tổ chức lại trung thực - tận 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ố xác thực dưới 20%. Điều này đã được triển khai trong Lighthouse và Prysm (bắt đầu với phiên bản 4.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 trình xác nhận xác thực. Vì vậy, chúng tôi không áp dụng nó cho tất cả các khách hàng cùng một lúc, cũng như không bị ràng buộc với bất kỳ hard fork cụ thể nào.
Cần lưu ý rằng tránh tổ chức lại trung thực trong một số trường hợp đặc biệt:
Trong các khối ranh giới kỷ nguyên
Nếu chuỗi chưa được hoàn thiện
Nếu người đứng đầu chuỗi không phải là người đứng đầu vị trí trước khi tổ chức lại
Trường hợp 3 đảm bảo rằng các tổ chức lại trung thực 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. Nó cũng phản ánh rằng những người đề xuất ít tin tưởng hơn vào nhận thức về mạng, vì họ không thể chắc chắn liệu các khối nâng cao được đề xuất của họ có được coi là tiêu chuẩn hay không.
Hình 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 cơ cấu.
Trong trường hợp này, hãy để b1 đại diện cho một khối muộn. Do độ trễ, b1 chỉ có 19% trọng lượng bằng chứng của vị trí thứ n. 81% trọng lượng bằng chứng còn lại được gán cho khối mẹ HEAD vì nhiều người chứng minh đã không xem b1 trước thời hạn chứng minh.
Nếu không có sự tổ chức lại 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 sắp xếp lại b1, mặc dù nó chỉ có 19% trọng lượng bằng chứng. Tại vị trí n+1, b2 có tính năng nâng cao của người đề xuất, giả sử nó được giao đúng hạn, b2 sẽ trở thành tiêu chuẩn bằng cách tích lũy phần lớn bằng chứng cho vị trí đó.
Với Tổ chức lại trung thực, mọi thứ rất khác. Bây giờ, người đề xuất vị trí n+1 nhận thấy rằng 19% trọng số bằng chứng của b1 nằm dưới ngưỡng tổ chức lại, vì vậy họ xây dựng một khối với HEAD làm cha mẹ và buộc b1 phải tổ chức lại. 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 (40% từ mức tăng của người đề xuất). Tất cả khách hàng đều triển khai cải tiến 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í n+1.
Các bản sửa lỗi nút Chuyển tiếp và Beacon cho các cuộc tấn công tách nhóm
Trong cuộc tấn công tách nhóm vào ngày 2 tháng 4, người đề xuất đã khai thác lỗ hổng chuyển tiếp để gửi tiêu đề chữ ký không hợp lệ tới chuyển tiếp. Trong vài ngày tới, các nhóm phát triển cốt lõi và chuyển tiếp đã phát hành nhiều 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 để biết các đề xuất độc hại đã biết (chỉ được sử dụng trong quá trình sản xuất bởi rơle siêu âm và đã bị xóa). Kiểm tra xem rơle đã chuyển toàn bộ khối tới một khe cắm trong mạng P2P chưa. Giới thiệu độ trễ ngẫu nhiên thống nhất trong phạm vi 0-500 mili giây trước khi một khối được xuất bản (bị xóa khỏi tất cả các rơle).
Thay đổi nút đèn hiệu (chỉ các nút đèn hiệu chuyển tiếp): Xác thực các khối đèn hiệu trước khi phát. Kiểm tra mạng để xác nhận sai 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 đồng thuận, một vấn đề trở nên trầm trọng hơn bởi thực tế là phần lớn những người xác nhận hiện đang sử dụng chiến lược tổ chức lại trung thực được mô tả ở trên.
HẬU QUẢ KHÔNG LƯỜNG
Năm thay đổi trên đều gây ra sự chậm trễ trong đường dẫn nóng của việc phát hành khối chuyển tiếp, điều này làm tăng khả năng các khối chuyển tiếp sẽ được phát sau thời hạn xác nhận. Sơ đồ bên dưới cho thấy trình tự của năm lần kiểm tra này và cách độ trễ được đưa ra khiến việc xuất bản khối vượt quá thời hạn xác nhận.
Một số lượng lớn các tiêu đề đã ký có độ trễ t = 0 (ví dụ: t = 3) thường không gây ra sự cố cho đến khi các kiểm tra này được thực hiện. Vì rơle có chi phí hoạt động 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 vá lỗi này bị trì hoãn, hiện tại rơle có thể chịu trách nhiệm một phần cho việc phát sóng bị trì hoãn. Hãy xem quy trình xuất bản khối giả định bên dưới.
Rơle nhận tiêu đề đã ký từ nhà sản xuất khối tại t = 3. Đến t = 4, rơle vẫn đang thực hiện kiểm tra, do đó, quảng bá sẽ xảy ra sau thời hạn xác nhận. Trong trường hợp này, sự kết hợp giữa tiêu đề đã 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 đã gây ra lỗi phát sóng trước thời hạn xác nhận. Nếu không có một cuộc tái tổ chức trung thực, những 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 của vị trí tiếp theo sẽ không cố ý sắp xếp lại vì các khối này bị trễ. Tuy nhiên, nếu thời hạn xác nhận bị bỏ lỡ, các khối sẽ được sắp xếp lại bởi nhà sản xuất khối tiếp theo.
Do đó, số lượng các khối được chia tách đã tăng lên đáng kể trong những ngày sau cuộc tấn công.
Dữ liệu hai tuần từ Metrika cho thấy trong trường hợp xấu nhất, 13 khối (4,3%) có thể được sắp xếp lại trong một giờ, gấp khoảng 5 lần tốc độ bình thường. Sự gia tăng đáng kể về số lượng khối được chia tách trở nên rõ ràng khi những người chuyển tiếp triển khai nhiều thay đổi khác nhau. Nhờ những nỗ lực tuyệt vời của cộng đồng của những người điều hành rơle và các nhà phát triển cốt lõi, khi tác động được biết đến, nhiều thay đổi đã được khôi phục và mạng được khôi phục về trạng thái khỏe mạnh.
Tính đến hôm nay, những thay đổi hữu ích nhất là kiểm tra xác thực và từ chối khối nút báo hiệu trước khi ban 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 các nút báo hiệu chuyển tiếp không nhìn thấy các khối bị từ chối trước khi xuất bản chúng. Tuy nhiên, các 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.
Hành động Tiếp theo
Trong bài đăng này, chúng tôi nhấn mạnh cách MEV-Boost hoạt động và tầm quan trọng của nó đối với sự đồng thuận của Ethereum. Chúng tôi cũng cung cấp một phân tích chi tiết về một số khía cạnh ít được biết đến của các quy tắc lựa chọn Ethereum fork liên quan đến thời gian. Sử dụng các phản ứng của nhà phát triển và cuộc tấn công "tách nhóm" làm nghiên cứu điển hình, chúng tôi nhấn mạnh lỗ hổng tiềm ẩn của các khía cạnh phụ thuộc vào thời gian của quy tắc lựa chọn ngã ba và tác động của nó đố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" là bao nhiêu, có tính đến mức độ phổ biến hơn của các cuộc tấn công từ chối, để xác định xem có nên thực hiện các biện pháp giảm nhẹ hay không.
Ngoài ra, một số hướng trong tương lai hiện đang được tích cực khám phá:
Triển khai 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 các thay đổi đối với phần mềm máy khách đồng thuận và có thể là các thay đổi về thông số kỹ thuật để kéo dài thời hạn gửi bằng chứng.
Tăng số lượng và phân phối các chương trình tiền thưởng lỗi cho phần mềm MEV-Boost.
Mở rộng phần mềm mô phỏng để khám phá cách thời gian của khe cắm phụ ảnh hưởng đến sự ổn định của mạng, 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.
Tối ưu hóa đường 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á.
Công nhận MEV-boost là một tính 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, tức là "PBS được lưu trữ (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 tùy chọn.
Bằng cách thêm nhiều bài kiểm tra hive và/hoặc thông số kỹ thuật xung quanh các vấn đề về độ trễ và thời hạn chứng nhận.
Khuyến khích sự đa dạng của máy khách chuyển tiếp bằng cách xây dựng các triển khai bổ sung của đặc tả chuyển tiếp.
Cân nhắc điều chỉnh 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 cơ hội MEV cực đoan tồn tại.
Xem lại thời gian của vị trí phụ và cân nhắc đ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 các cuộc tấn công và giảm thiểu phân nhóm, chúng tôi đã biết về mối quan hệ quan trọng giữa độ trễ, cơ chế tăng cường MEV và cơ chế đồng thuận; chúng tôi hy vọng giao thức sẽ tiếp tục được củng cố để xử lý vấn đề này.