MEV-Boost là gì?

MEV-Boost là một giao thức được thiết kế bởi Flashbots và cộng đồng với mục đích 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) đối với mạng Ethereum.

Vai trò chính của MEV-Boost là gì? 

• Điểm chuyển tiếp (Relays) - Những người bán đấu giá tin cậy lẫn nhau kết nối người đề xuất với người xây dựng khối.
• Người xây dựng (Builders) - Các thực thể phức tạp xây dựng khối để tối ưu hóa MEV của chính họ và người đề xuất.
• Người đề xuất (Proposers) - Trình xác thực Proof of Stake (Bằng chứng quyền sở hữu) cho mạng Ethereum.

Trình tự gần đúng của các sự kiện

• Người xây dựng tạo ra một khối bằng cách nhận các giao dịch từ người dùng, người tìm kiếm MEV hoặc các luồng đặt hàng khác (riêng tư hoặc công khai).
• Người xây dựng gửi khối đến điểm chuyển tiếp (Relay).
• Rơle xác minh khối có hợp lệ hay không và tính toán số tiền sẽ trả cho người đề xuất.
• Rơle gửi tiêu đề "bị mù" (blinded) và giá trị thanh toán cho người đề xuất tại vị trí hiện tại.
• Người đề xuất đánh giá tất cả các đặt hàng mà họ nhận được và ký vào tiêu đề mù liên quan đến khoản thanh toán cao nhất.
• Người đề xuất gửi tiêu đề đã ký này trở lại điểm chuyển tiếp.
• Khối này được công bố bởi trạm chuyển tiếp thông qua nút chuỗi chỉ huy cục bộ của nó và trả lại cho người đề xuất. Phần thưởng được phân bố 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.

Điểm chuyển tiếp (Relay) đóng vai trò là bên thứ ba tin cậy, hỗ trợ việc trao đổi không gian khối công bằng từ người đề xuất và sắp xếp giao dịch để khai thác MEV từ người xây dựng. Điểm chuyển tiếp bảo vệ người xây dựng khỏi hành vi trộm cắp MEV, khi người đề xuất sao chép giao dịch của người xây dựng để nhận MEV thay vì chỉ định cho người tìm kiếm/người xây dựng đã phát hiện ra nó. 

Điểm chuyển tiếp cũng bảo vệ người đề xuất bằng cách xác thực tính hợp lệ của các khối, xử lý hàng trăm khối trên mỗi vị trí thay mặt cho người đề xuất và đảm bảo tính chính xác của các khoản thanh toán cho người đề xuất.

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

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

Trước khi đi sâu vào các cuộc tấn công và phản ứng, hãy cùng tìm hiểu về cơ chế bằng chứng cổ phần (PoS) của Ethereum và quy tắc lựa chọn nhánh liên quan. Quy tắc chọn nhánh cho phép mạng đạt được sự đồng thuận về đầu chuỗi. 

Theo "tái tổ chức Ethereum sau khi hợp nhất":

Quy tắc lựa chọn nhánh là một hàm được đánh giá bởi các ứng dụng khách. Quy tắc này nhận các khối đã nhìn thấy và các thông điệp khác làm đầu vào, và xuất ra cho khách hàng "chuỗi chính thức" là gì. Cần có quy tắc lựa chọn nhánh bởi vì có thể có nhiều chuỗi hợp lệ để lựa chọn.

Một khía cạnh ít được biết đến về quy tắc lựa chọn nhánh là mối liên hệ của với thời gian, điều này có ảnh hưởng lớn đến việc sản xuất khối.

Chu kỳ khe cắm và khe con

Trong PoS của Ethereum, thời gian được chia thành các khoảng tăng 12 giây được gọi là khe cắm. Thuật toán PoS chỉ định ngẫu nhiên cho các trình xác thực có cơ hội đề xuất một khối trong khe cắm này; trình xác thực này được gọi là người đề xuất. 

Trong cùng một khe cắm, các trình xác thực khác được giao nhiệm vụ: bỏ phiếu ủng hộ phiên bản mới nhất của khối tại vị trí đầu chuỗi, trong chế độ xem cục bộ, bằng cách áp dụng quy tắc lựa chọn nhánh. Khoảng thời gian 12 giây được chia thành ba giai đoạn, mỗi giai đoạn kéo dài 4 giây.

Các sự kiện diễn ra trong khe cắm được thể hiện như sau, trong đó t = 0 biểu thị bắt đầu khe cắm.

Thời điểm then chốt trong khe cắm là thời hạn xác thực tại t = 4. Nếu một trình xác thực không nhìn thấy một khối trước thời hạn xác thực, họ sẽ bỏ phiếu cho đầu chuỗi đã được chấp nhận trước (theo quy tắc lựa chọn nhánh). Càng đưa ra một khối sớm, khối đó càng có nhiều thời gian lan truyền, do đó, khối đó tích lũy được nhiều chứng nhận hơn (vì nhiều trình xác thực nhìn thấy khối đó trước thời hạn xác thực).

Từ góc độ sức khỏe của mạng, thời điểm tốt nhất để công bố một khối là t = 0 (được quy định bởi tiêu chuẩn). Tuy nhiên, do giá trị khối tăng đơn điệu theo thời gian, người đề xuất có động cơ trì hoãn công bố khối của họ để cho phép tích lũy nhiều MEV hơn. 

Trong quá khứ, người đề xuất có thể công bố khối sau thời hạn xác thực hoặc thậm chí gần cuối khe cắm, miễn là trình xác thực tiếp theo quan sát khối đó trước khi xây dựng khối khe cắm tiếp theo.

Nâng cao đề xuất và tái tổ chức trung thực

Hai khái niệm mới được đưa vào ứng dụng đạt đồng thuận, có ảnh hưởng quan trọng đến thời hạn xác thực.

Nâng cao đề xuất (PR) - Cố gắng cân bằng tối thiểu hóa tấn công tái tổ chức bằng cách cấp cho người đề xuất "nâng cao" lựa chọn nhánh tương đương với trọng lượng xác thực đầy đủ 40%. Điều quan trọng là sự gia tăng này chỉ kéo dài một khe cắm.

Tái tổ chức trung thực (PR) - Sử dụng nâng cao đề xuất và cho phép người đề xuất trung thực sử dụng để ép buộc tái tổ chức các khối có trọng lượng xác thực 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, bởi vì đây là quyết định cục bộ của người đề xuất và không ảnh hưởng đến hành vi của trình xác thực. Do đó, không có nỗ lực phối hợp để triển khai đồng thời trên tất cả các ứng dụng và không liên quan đến bất kỳ nhánh cứng cụ thể nào.

Lưu ý rằng, tránh sắp xếp lại trung thực trong một số trường hợp đặc biệt:

• Trong khối giới hạn kỷ nguyên
• Nếu chuỗi chưa hoàn thành
• Nếu đầu chuỗi không được lấy từ khe cắm trước khối tái tổ chức

Điều kiện 3 đảm bảo tái tổ chức trung thực chỉ xóa một khối duy nhất khỏi chuỗi, điều này hoạt động như một công tắc, cho phép chuỗi tiếp tục tạo khối trong thời gian chậm trễ mạng cực đoan. Điều này cũng phản ánh sự giảm niềm tin của người đề xuất vào chế độ xem mạng của họ, bởi vì họ không còn chắc chắn khối nâng cao đề xuất của họ sẽ được coi là tiêu chuẩn.

Biểu đồ dưới đây minh họa cách hành vi trung thực thay đổi để triển khai 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 đến muộn. Do chậm trễ, b1 chỉ có 19% trọng lượng xác thực của khe thứ n. 81% trọng lượng xác thực còn lại được phân bổ cho khối cha HEAD, bởi vì nhiều trình xác thực không nhìn thấy b1 trước thời hạn xác thực.

Nếu không có tái tổ chức trung thực, người đề xuất trong khe thứ n+1 sẽ coi b1 là đầu chuỗi và xây dựng khối con b2. Mặc dù chỉ có 19% trọng lượng xác thực, nhưng người đề xuất sẽ không cố gắng tái tổ chức b1. Trong khe thứ n+1, b2 có tính năng nâng cao đề xuất và giả sử b2 được giao đúng hạn, nó sẽ trở thành tiêu chuẩn thông qua việc tích lũy đa số xác thực của khe đó.

Với việc tái tổ chức trung thực, tình hình hoàn toàn khác. Bây giờ, người đề xuất trong khe thứ n+1 phát hiện ra, 19% trọng lượng xác thực của b1 thấp hơn ngưỡng tái tổ chức, do đó họ xây dựng một khối mới với HEAD làm khối cha cho b2 và buộc phải tái tổ chức b1. Khi chúng ta đạt đến thời hạn xác thực của khe n+1, các trình xác thực trung thực sẽ so sánh trọng lượng tương đối của b2 (40% từ nâng cao đề xuất) và b1 (19%). Tất cả các ứng dụng đều thực hiện nâng cao đề xuất, do đó b2 sẽ được coi là đầu chuỗi và tích lũy xác thực của khe n+1.

Cải tiến cho nút trung chuyển và nút chuỗi Beacon

Trong vụ tấn công tách nhóm vào ngày 2/4, người đề xuất đã tận dụng một lỗ hổng trung chuyển, tấn công bằng cách gửi chữ ký đầu không hợp lệ đến nút trung chuyển. Trong những ngày tiếp theo, đội phát triển trung chuyển và lõi đã phát hành nhiều bản vá phần mềm để giảm thiểu rủi ro tấn công lặp lại. Có năm thay đổi chính như sau:

Thay đổi rơle:

• Kiểm tra cơ sở dữ liệu để xem có tồn tại người đề xuất độc hại nào không (chỉ được sử dụng trong sản xuất bằng rơle siêu âm và đã bị xóa).
• Kiểm tra xem liệu trong khoảng thời gian đó đã chuyển giao khối đầy đủ cho mạng P2P hay không.
• Giới thiệu độ trễ ngẫu nhiên thống nhất trong khoảng từ 0-500 ms trước khi xuất bản khối (đã loại bỏ khỏi tất cả các rơle).

Thay đổi nút chuỗi Beacon (chỉ áp dụng cho nút trung chuyển chuỗi Beacon):

• Xác minh tính hợp lệ của khối Beacon trước khi phát sóng.
• Kiểm tra xem liệu có bản sao trên mạng trước khi xuất bản khối hay không.

Sự kết hợp của những thay đổi này đã dẫn đến sự không ổn định của đồng thuận, trong khi đa số trình xác thực hiện tại đều sử dụng chiến lược tái tổ chức trung thực đã nêu trên làm tăng thêm tình trạng này.

Hậu quả 

Mỗi thay đổi trong số 5 thay đổi trên sẽ tăng thời gian trễ trên đường dẫn nóng giải phóng khối rơle, do đó làm tăng khả năng khối rơle có thể vượt quá thời hạn xác minh và được phát sóng. 

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 việc đưa ra độ trễ có thể khiến việc xuất bản khối vượt quá thời hạn kiểm chứng.

Các tiêu đề chữ ký đến muộn hơn đáng kể so với t=0 (ví dụ: t=3) thường không phải là vấn đề cho đến khi các kiểm tra này được thực hiện. Chi phí chuyển tiếp rất thấp, vì vậy các khối được xuất bản trước t=4.

Tuy nhiên, với độ trễ tăng lên do năm bản vá này đưa ra, giờ đây rơle có thể chịu trách nhiệm một phần cho việc trì hoãn phát sóng. Hãy xem xét xuất bản khối trong tình huống giả định sau đây.

Rơle nhận tiêu đề đã ký từ người đề xuất tại t=3. Đến t=4, rơle vẫn đang thực hiện kiểm tra, vì vậy, quá trình phát sóng diễn ra sau thời hạn kiểm chứng. Trong trường hợp này, sự kết hợp của người đề xuất gửi tiêu đề đã ký muộn và chuyển tiếp đưa ra một số độ trễ bổ sung khiến thời hạn chứng thực bị bỏ lỡ. 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ể sẽ hoạt động trên chuỗi. 

Như chúng ta đã thấy trong Hình 2, những người đề xuất trung thực cho các vị trí tiếp theo không cố ý sắp xếp lại các khối đã bị từ chối do đến quá muộn. Tuy nhiên, trong trường hợp tổ chức lại một cách trung thực, việc bỏ lỡ thời hạn chứng minh có nghĩa là khối sẽ được tổ chức lại bởi người đề xuất tiếp theo.

Kết quả là, 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 của Metrika trong 2 tuần cho thấy, trong trường hợp tồi tệ nhất, có 13 khối (4,3%) bị tái tổ chức trong một giờ, cao hơn khoảng 5 lần so với bình thường. Việc tăng đột biến số khối phân nhánh trở nên rõ rệt khi các thay đổi được triển khai trên các trạm trung chuyển. Nhờ vào nỗ lực của cộng đồng từ các nhà điều hành trung chuyển và nhà phát triển lõi, khi hiểu được tác động, nhiều thay đổi đã được hoàn tác và mạng lưới đã phục hồi lại trạng thái khỏe mạnh.

Tính đến nay, những thay đổi hữu ích nhất là việc xác thực khối nút chuỗi phát tín hiệu và kiểm tra tương đương trước khi phát sóng. Những người đề xuất ác ý không thể tiếp tục tấn công bằng cách gửi tiêu đề không hợp lệ cho trạm trung chuyển và đảm bảo các nút chuỗi phát tín hiệu trung chuyển không nhìn thấy khối tương đương trước khi xuất bản. Tuy nhiên, trạm trung chuyển vẫn dễ bị ảnh hưởng bởi các cuộc tấn công tương đương phổ biến hơn mà Mev-Boost và ePBS gây ra.

Lời kết

Trước hết, giới nghiên cứu cần đánh giá xem số lượng tái tổ chức "chấp nhận được" là bao nhiêu và cân nhắc nguy cơ do các cuộc tấn công tương đương phổ biến gây ra để xác định liệu có cần thực hiện các biện pháp giảm nhẹ hay không.

Bên cạnh đó, hiện nay đang tích cực khám phá một số hướng đi trong tương lai:

• Triển khai "headlock" để bảo vệ Mev-Boost khỏi các cuộc tấn công tương đương. Điều này cũng đòi hỏi thay đổi phần mềm khách đồng thuận và có thể yêu cầu thay đổi tiêu chuẩn để kéo dài thời hạn chứng minh.
• Tăng số lượng và tầm nhìn của chương trình thưởng lỗ hổng phần mềm Mev-Boost.
• Mở rộng phần mềm mô phỏng để nghiên cứu cách thức thời gian con ảnh hưởng đến sự ổn định của mạng. Điều này có thể được sử dụng để đánh giá việc làm thế nào để giảm tái tổ chức thông qua việc điều chỉnh thời hạn chứng minh.
• Tối ưu hóa đường dẫn xuất bản khối trên trạm trung chuyển để giảm độ trễ không cần thiết. 
• Mev-Boost là một tính năng giao thức lõi và hấp thụ vào phần mềm khách đồng thuận, tức là enshrined-PBS (ePBS). ePBS với hai khung thời gian dễ bị ảnh hưởng bởi các cuộc tấn công tương đương, do đó việc triển khai "headlock" vẫn là một lựa chọn.
• Tăng cường các kiểm tra hive và/hoặc tiêu chuẩn dựa trên vấn đề độ trễ và thời hạn chứng minh.
• Khuyến khích đa dạng các ứng dụng khách trung chuyển bằng cách xây dựng các phiên bản triển khai trung chuyển khác nhau.
• Xem xét điều chỉnh các biện pháp xử phạt tương đương, nhưng hãy nhớ rằng, trong trường hợp cơ hội MEV lớn, việc cắt giảm hoàn toàn 32 ETH có thể không đủ để ngăn chặn hành vi xấu.