Nhà thầu có thể kiểm toán với các chứng thực lạc quan trong ePBS

Cảm ơn Potuz vì ý tưởng rằng người chứng thực slot n n cũng nên trực tiếp vô hiệu hóa Block beacon nếu người đề xuất chọn giá thầu xây dựng có thể kiểm toán không chính xác. Cảm ơn Francesco đã hướng dẫn về các vấn đề Consensus và Terence đã phản hồi.

Lý lịch

Enshrined proposal-builder separation ( ePBS ), được chỉ định trong Đề xuất cải tiến Ethereum (EIP)-7732 , là bản cập nhật được đề xuất cho Ethereum giúp tạo điều kiện cho tương tác Không cần tin cậy giữa builder và beacon proposal. Sau khi chuyển sang lấy mẫu khả dụng dữ liệu ngang hàng ( PeerDAS ) trong Fusaka, một ePBS proposal không đăng ký tất cả các mạng con cột blob (tức là một trình xác thực nhỏ hơn) có thể nhầm tưởng rằng dữ liệu khả dụng và mở rộng trên đầu sai. Nếu FOCIL được triển khai, thì người đề xuất trong khe n+1 n + 1 cũng sẽ cần đưa ra quyết định về tính kịp thời của IL trong khe n-1 n − 1 , đây là quyết định chủ quan. Do đó, người đề xuất sẽ được hưởng lợi từ các xác thực xác nhận rằng tải trọng đáp ứng các IL kịp thời.

Francesco đã phác thảo một cách để giải quyết những vấn đề này. Ủy ban thời gian tải trọng ( PTC ) cũng được yêu cầu kiểm tra DA (theo các cột đã đăng ký của thành viên) và thời gian của các IL. Do đó, PTC trở thành một ủy ban khả dụng (AC). AC được lên lịch bỏ phiếu ngay sau khi tải trọng được phát hành. Do đó, mong muốn không yêu cầu người bỏ phiếu thực hiện tải trọng, nhưng điều này ngăn cản họ đánh giá liệu các IL có được tuân thủ đầy đủ hay không. Giải pháp mà Francesco đề xuất là những người xây dựng tuyên bố trong tải trọng mà nó dựa trên IL nào và AC bỏ phiếu xem cam kết này có phù hợp với quan điểm của họ về các IL bắt buộc hay không. Do đó, người đề xuất nhận được tín hiệu lạc quan về thời gian của các IL.

Một đề xuất gần đây cho một mempool được mã hóa, Sealed transactions , dựa trên một lược đồ xem-hợp nhất tương tự như FOCIL, yêu cầu đánh giá chủ quan về tính kịp thời. Cụ thể, các giao dịch đã niêm phong (ST) được bao gồm trong Block beacon của khe n-1 n − 1 . Các giao dịch chưa niêm phong (UT) sau đó được tiết lộ một cách đáng tin cậy trước thời hạn do người chứng thực quan sát và cuối cùng được bao gồm trong tải trọng của khe n n . Thiết kế ePBS hiện tại yêu cầu độ trễ một khe cho đến khi người chứng thực có thể xác nhận rằng tất cả các UT kịp thời đã được bao gồm trong Block. Độ trễ như vậy cũng áp dụng cho IL, trong đó AC như đã đề cập trước đó được tuyển dụng để cung cấp tín hiệu sớm giữa các lần chứng thực của khe n n và khe n + 1 n + 1 . Tất nhiên, AC cũng có thể được tuyển dụng cho các UT, nhưng vẫn có độ trễ (và vẫn là độ trễ của toàn bộ khe cho đến khi lựa chọn ngã ba tham gia) và phiếu bầu AC cũng sẽ trở nên quá tải. Liệu có thể tuyển dụng người xác nhận slot n n để bỏ phiếu lạc quan cho cả IL và UT thay thế, ngay trước khi Block được tiết lộ không? Điều đó sẽ tăng tốc đáng kể quá trình mà tải trọng vượt qua các tiêu chí chủ quan. Nó cũng thu hẹp phạm vi của AC, với khả năng chống kiểm duyệt thay vào đó được đảm bảo bởi bộ xác nhận đầy đủ (của slot) và AC có khả năng thích ứng tốt hơn với các nhiệm vụ còn lại của nó.

Cơ chế đề xuất

Lấy cảm hứng từ công trình trước đó của Francesco, bài đăng này đề xuất rằng các nhà xây dựng tạo ra các giá thầu xây dựng có thể kiểm toán (ABB), tuyên bố trong giá thầu của họ về các IL và UT mà tải trọng sẽ tuân thủ. Điều này sẽ không tiết lộ thông tin quan trọng liên quan đến MEV, vì dù sao thì việc tuân thủ IL và UT cũng là một yêu cầu nghiêm ngặt. Với ABB, những người chứng thực khe n n có thể bỏ phiếu lạc quan về việc Block thực thi n n có tuân thủ các IL và UT kịp thời hay không, ngay cả trước khi tải trọng được phát hành. Điều này có ba lợi ích:

• Một nhiệm vụ quan trọng của cơ chế Consensus là đảm bảo khả năng chống kiểm duyệt. Khi AC xét xử tính kịp thời, nó có quyền vô hiệu hóa bất kỳ IL nào không kiểm duyệt—một quyền mà lý tưởng nhất là chỉ nằm trong bộ chứng thực đầy đủ (xem thêm phần thảo luận).
• Người chứng thực không chỉ đánh giá trực tiếp tính kịp thời mà còn bỏ phiếu (liên quan đến thời gian) sớm hơn một khe, nhanh hơn 12 giây so với thiết kế ePBS tạm thời hiện tại. Một nút xác định tải trọng mới có hiệu lực sau 5 giây vào khe n n có thể tính đến các chứng thực lạc quan của người chứng thực khe n n để đảm bảo trực tiếp rằng tải trọng cũng vượt qua các tiêu chí liên quan đến thời gian chủ quan.
• AC sẽ tập trung vào phạm vi hẹp hơn, mở ra không gian thiết kế và cho phép nó thích ứng với các nhiệm vụ cụ thể (nó không bị “quá tải”).

Hình 1 minh họa ABB với các xác nhận lạc quan trong ePBS, trong đó các trường bit IL và UT được thêm vào tiêu đề của Block thực thi n n . Người xác nhận của khe n n bỏ phiếu cho tiêu đề mở rộng này trước khi tải trọng được truyền bá.

Hình 1 2700×2028 464 KB

Hình 1. Người chứng thực (màu tím) quan sát IL và UT tại T_1 T 1 và sau đó xem xét ABB tại T_2 T 2 chỉ định IL và UT nào sẽ được tính đến trong tải trọng. Họ bỏ phiếu cho Block một cách lạc quan tại T_3 T 3 nếu quan sát của họ tại T_1 T 1 phù hợp với thông số kỹ thuật ABB.

Cơ chế này diễn ra như sau:

• Trước T_1 T 1 – IL và UT được phát và truyền bá p2p.
• T_1 T 1 – Người chứng thực khe n n đóng băng quan điểm của họ về các IL và UT được truyền bá.
• Sau T_1 T 1 – Khi các nhà xây dựng tự tin rằng họ đã quan sát tất cả các UT và IL có liên quan (những UT và IL trong chế độ xem đóng băng của hầu hết người chứng thực), họ sẽ ép kiểu ABB để có quyền xây dựng Block (hình chữ nhật màu). ExecutionPayloadHeader được mở rộng bằng một trường bit IL, trong đó các nhà xây dựng khai báo các includer có IL mà payload tuân thủ và một trường bit UT khai báo các ST có UT tương ứng sẽ được bao gồm. Cũng giống như trong Đề xuất cải tiến Ethereum (EIP)-7732 , đối tượng ExecutionPayloadHeader cũng nên được thay đổi để chỉ bao gồm thông tin tối thiểu cần thiết để cam kết với payload của nhà xây dựng.
• T_2 T 2 – Vào đầu khe n n , người đề xuất chọn một ABB chiến thắng, ít nhất phải bao quát như quan điểm của riêng họ về các IL và UT cần thiết và bao gồm ABB đó trong Block beacon.
• T_3 T 3 – Người xác nhận của khe n n bỏ phiếu cho người đứng đầu hiện tại của chuỗi. Nếu Block beacon bị thiếu hoặc nếu ABB được bao gồm không vượt qua được cuộc kiểm toán của họ do thiếu IL hoặc UT, họ sẽ chỉ ra Block trước đó là người đứng đầu của chuỗi trong chế độ xem hiện tại của họ. Nếu ABB vượt qua cuộc kiểm toán của họ, họ sẽ xác nhận một cách lạc quan cho Block. Những phiếu bầu này vẫn sẽ được tính cho cả Block n n đầy đủ và khối trống trong lựa chọn ngã ba, với điều kiện là tải trọng vẫn chưa được giải phóng.
• T_4 T 4 – Khi người xây dựng tin chắc rằng Block beacon sẽ trở thành chuẩn sau khi xem xét các chứng thực được truyền bá, nó sẽ giải phóng tải trọng.
• Sau T_4 T 4 – Sau khi tải trọng được giải phóng, có thể kiểm tra để đảm bảo rằng nó tuân theo quy định của ABB. Do đó, mọi thông tin cần thiết để xác định sự tuân thủ IL và UT đều có sẵn từ T_4 T 4 (sự tuân thủ khi thực hiện được kiểm tra cục bộ và các xác nhận khe n n vẫn đang lan truyền). Thông tin này tất nhiên sẽ được người đề xuất và người xác nhận của khe n+1 n + 1 sử dụng, nhưng cũng có thể được bất kỳ nút nào theo dõi chuỗi sử dụng trực tiếp tại thời điểm này. Khi kết hợp với các kiểm tra về DA và tính kịp thời của tải trọng, khả năng tải trọng trở thành chuẩn có thể được đánh giá với độ chính xác cao.

Xử lý người đề xuất

Người đề xuất khe n+1 n + 1 chạy các kiểm tra sau:

• tải trọng là hợp lệ,
• tải trọng thỏa mãn ABB sau khi thực hiện các giao dịch,
• dữ liệu blob đã có sẵn và tải trọng được truyền đi đúng thời hạn (theo phiếu bầu của AC).

Nếu các kiểm tra này vượt qua, người đề xuất có thể mở rộng trên Block n n . Người đề xuất chọn nhánh của mình từ cây con có trọng số xác thực lớn nhất như bình thường, cũng tính đến tất cả các xác thực trong khe n n . Giống như trong các thiết kế trước đây của ePBS, các xác thực khe n n được tính vào cả Block đầy và khối rỗng, với điều kiện là tải trọng vẫn chưa được giải phóng.

Xử lý thanh toán

Quá trình xử lý thanh toán tuân theo cấu trúc chung đã được Francesco nêu trước đó:

• Nếu tải trọng trở thành chuẩn, thanh toán sẽ được xử lý (trường hợp thành công).
• Nếu tải trọng không trở thành chuẩn, thanh toán vẫn được xử lý nếu ít nhất 60% số người xác thực ở vị trí n n bỏ phiếu cho Block và không phát hiện thấy sự mơ hồ nào của người đề xuất vào cuối kỷ nguyên tiếp theo.

Người chứng thực của khe n+1 n + 1

Người chứng thực của khe n+1 n + 1 không đóng băng quan điểm của họ tại thời hạn đóng băng áp dụng cho người chứng thực của khe n n (khoảng 9 giây vào khe n-1 n − 1 ) và tiếp tục xem xét các IL đến, giống như người đề xuất khe n n . Họ ngừng theo dõi IL và lắng nghe sự mơ hồ tại T_3 T 3. Các quy tắc dành cho người chứng thực của khe n+1 n + 1 cũng áp dụng cho những người chứng thực tiềm năng trong tương lai trong trường hợp khe bị bỏ lỡ, đây cũng là trường hợp trong phiên bản trước dựa trên AC. Có thể điều chỉnh thời hạn cho những người chứng thực này nếu muốn.

sự mơ hồ của IL

Nếu một includer không nhất quán, IL của nó sẽ không có ảnh hưởng, bất kể người đề xuất có quy định tuân thủ includer hay không. Điều này có nghĩa là người xác nhận của khe n+1 n + 1 nên bỏ qua IL không nhất quán và chấp nhận một tải trọng không tuân thủ chúng, ngay cả khi người xây dựng quy định rằng nó sẽ tuân thủ trong ABB của mình.

Trong FOCIL thông thường, một người đề xuất đã mắc lỗi khi không tuân thủ IL có thể được cứu bằng cách sử dụng sự mơ hồ sau đó của IL đó và việc phát hành một IL mơ hồ như vậy có thể chia tách tập xác thực. Hiện tượng tương tự cũng xảy ra với ABB. Một phiên bản đặc biệt là khi người xây dựng trong ABB của mình quy định tuân thủ IL, nhưng tải trọng của nó thực sự không tuân thủ, nhưng một includer lại mơ hồ sau khi Block beacon được phát hành, cứu người xây dựng. Điều này có lẽ không đáng lo ngại.

Cuộc thảo luận

Với ABB, bộ chứng thực đầy đủ đảm bảo khả năng chống kiểm duyệt (bằng cách bỏ phiếu cho IL) cũng như xử lý chính xác các giao dịch đã niêm phong. Trong phiên bản dựa vào AC, những người chứng thực trung thực phải tuân thủ phiếu bầu của AC vì nó liên quan đến tính kịp thời của IL. Do đó, người xây dựng có thể thông đồng với AC (nhỏ hơn) để quy định rằng họ không tuân thủ một bộ IL, với AC xác nhận rằng đây là lựa chọn đúng vì IL rõ ràng là đã trễ (AC có toàn quyền quyết định tính kịp thời). Những người chứng thực trung thực của khe n+1 n + 1 sau đó sẽ không có lựa chọn nào khác ngoài việc chấp nhận một tải trọng ngay cả khi họ thấy IL kịp thời bị bỏ qua, vì họ nên hoãn lại phiếu bầu của AC về tính kịp thời. Trên thực tế, do đó, AC kiểm soát khả năng chống kiểm duyệt (giả sử có sự phối hợp với người xây dựng), một kiểm soát bị loại bỏ với ABB.

Đồng thời, Threshold đa số được sử dụng bởi những người chứng thực AC thực sự ảnh hưởng đến lựa chọn ngã ba theo một cách khác so với số phiếu bầu của những người chứng thực slot -n n . Nếu loại bộ lọc ngưỡng đa số này được coi là mong muốn, thì người đề xuất slot -n+1 n + 1 và những người chứng thực có thể thay thế bằng cách chuyển hướng đến các chứng thực slot -n n ngưỡng đa số nhằm mục đích xác định tính kịp thời.

Những gì còn lại của vai trò AC là bỏ phiếu về tính kịp thời của tải trọng và DA. Một bài đăng trong tương lai sẽ khám phá cách vai trò của AC có thể phát triển hơn nữa, với những ràng buộc mới được nới lỏng này. Một lợi ích bổ sung là những người bao gồm khe n n sẽ có được thông tin sớm về các giao dịch mà tải trọng của khe n n sẽ tuân thủ. Đây là những giao dịch mà những người bao gồm không nên liệt kê (nếu tải trọng kịp thời).

Trong MEV-boost thông thường, rơle là bên đáng tin cậy đảm bảo tính hợp lệ của các khối xây dựng được chuyển tiếp dưới dạng giá thầu. Theo FOCIL, việc kiểm tra tính hợp lệ này trở thành một quyết định chủ quan, phụ thuộc vào tính kịp thời của IL. Có thể một số trình xác thực muốn tự thực hiện kiểm tra chủ quan này và do đó, ABB cũng có thể được triển khai trong MEV-boost (không có ePBS). Điều này sẽ cải thiện tính không tin cậy của thiết kế MEV-boost hiện tại và đặt nền tảng cho ABB trong ePBS.

Có thể đưa ra một lưu ý riêng về cách xử lý các giao dịch đã niêm phong trong các khối rỗng trong ePBS. Cũng giống như trong thiết kế ban đầu , một ST được đưa vào Block A phải đảm bảo rằng UT kịp thời tương ứng được đưa vào đầu khối trong tải trọng của Block B tiếp theo, ngay cả khi Block đầu tiên được đề xuất sau Block A không trở thành chuẩn. Tuy nhiên, vì các khối có thể rỗng trong ePBS, nên một loạt các khối rỗng có thể tạo ra một lượng lớn ST chưa được UT hoàn thành. Do đó, có thể mong muốn ngăn những người đề xuất beacon đưa vào các ST mới khi rõ ràng là có một lượng tồn đọng.

Phương pháp tiếp cận được đề xuất cho các IL chuyển tiếp trước đó trong ePBS là giải quyết tình trạng tồn đọng tiềm ẩn bằng cách ngăn người đề xuất trong khe n+1 n + 1 cung cấp IL chuyển tiếp, nếu tải trọng của khe n n bị thiếu (h/t Potuz). Điều này cho phép tải trọng của khe: n+1 n + 1 thỏa mãn n-1 n − 1 ; n+2 n + 2 thỏa mãn n n ; và n+3 n + 3 thỏa mãn n+2 n + 2 (do đó cuối cùng bắt kịp). Tuy nhiên, đối với các giao dịch đã niêm phong, phương pháp tiếp cận như vậy có thể khiến một giao dịch viên có ST được bao gồm trong khe n n tiết lộ UT trước khi tải trọng của khe n+1 n + 1 được xây dựng (mà nó sẽ không được bao gồm trong đó). Do đó, giải pháp cho Block n n trống là chỉ định rằng các ST từ cả hai khe n-1 n − 1 và n n phải được tuân thủ với UT trong khe n+1 n + 1 , đồng thời ngăn người đề xuất khe n+1 n + 1 bao gồm các ST mới, sao cho lượng tồn đọng không tiếp tục tăng.

Lưu ý rằng bất kể thiết kế nào được chọn, nếu UT từ nhiều hơn một Block ST được đưa vào, thì các UT liên quan đến cùng một bộ ST từ một Block đèn hiệu cụ thể phải được nhóm lại trong tải trọng, với nhóm liên quan đến Block đèn hiệu sớm nhất được định vị ở đầu khối, ETC Tuy nhiên, thứ tự của các UT trong mỗi nhóm vẫn phải tuân theo phí đầu khối đã tiết lộ.