Raid - Hộp thư đến tổng hợp để sắp xếp theo trình tự

Cảm ơn các nhóm Nethermind và Taiko đã thảo luận và phản hồi.

Tóm tắt (TLDR)

Raid ("Xác nhận hồi tố của dữ liệu hộp thư") là một tập hợp các hợp đồng mà các hộp thư rollup có thể áp dụng để cho phép trình tự dựa trên tính tương thích preconf. Raid sử dụng nhiều cấp lọc on-chain để đảm bảo chỉ các blob được gửi bởi các preconfer mới được các nút rollup coi là chính tắc. Điều này được thực hiện không thông qua một cái nhìn on-chain về beacon chain lookahead hoặc các sửa đổi trên L1 như Đề xuất cải tiến Ethereum (EIP-7917) sẽ làm điều này đơn giản hơn rất nhiều.

Một bài viết với nhiều bối cảnh hơn có thể được tìm thấy tại đây.

Vấn đề

Các rollup cần một điểm nhập L1 để xuất bản các blob.

OP Stack sử dụng một địa chỉ EOA ngẫu nhiên batchInbox và lọc các blob chính tắc bằng cách xác minh rằng tất cả các giao dịch blob đã được ký bởi batchSubmitter chuyên dụng trong quá trình phát sinh rollup của họ. Thay vì một địa chỉ cố định, trình tự dựa trên yêu cầu một địa chỉ batchSubmitter động để luân chuyển giữa các proposer L1.

Trong Taiko, bất kỳ ai cũng có thể xuất bản blob một cách không cần cho phép vào hợp đồng TaikoInbox để lưu siêu dữ liệu cần thiết cho việc chứng minh ở các giai đoạn sau. Điều này đủ cho trình tự dựa trên, nhưng vì bất kỳ ai cũng có thể xuất bản bất cứ lúc nào, nên các preconfer không thể đưa ra cam kết đáng tin về trạng thái tranh chấp. Bất kỳ preconfer nào đưa ra các preconf thực thi L2 đều được đảm bảo sẽ phá vỡ cam kết của mình nếu một đối thủ thay đổi trạng thái của rollup trước khi họ xuất bản.

Điều cần thiết là một cách để cấp cho preconfer một khóa ghi trên rollup cho đến vị trí của họ. Ý nghĩ phổ biến là hiển thị một góc nhìn về beacon lookahead cho hợp đồng hộp thư và sử dụng nó để lọc các đề xuất blob. Mặc dù EIP-7917 sẽ giải quyết điều này trong tương lai, nhưng beacon lookahead hiện tại là một chức năng của trạng thái beacon và do đó không thể chứng minh trực tiếp thông qua các bằng chứng Merkle so với gốc block beacon EIP-4788. Thay vào đó, việc hiển thị beacon lookahead một cách không cần tin cậy trên chuỗi yêu cầu chứng minh ZK một cách bi quan về chức năng beacon chain hoặc đăng nó một cách lạc quan và sau đó slashing thông qua bằng chứng gian lận như trong cách tiếp cận của Nethermind.

• blobProposer_1 là một preconfer không hợp lệ nên việc xuất bản B_1 bị hoàn nguyên
• blobProposer_2 là một preconfer hợp lệ xuất bản B_2 với replaceUnsafeHead = false
• Do replaceUnsafeHead là false, validatorProof của blobProposer_2 chứng minh rằng publicationId_{B_0} đã được gửi trong slot của blobProposer_0
• Giả sử validatorProof là hợp lệ, publicationId_{B_0} được thăng cấp lên safeHead, và publicationId_{B_2} trở thành unsafeHead mới
• Các nút Rollup nhận được sự kiện NewSafeHead và xử lý B_0 để cập nhật trạng thái L2 cục bộ

Slot N+2

• blobProposer_3 là một preconfer hợp lệ xuất bản B_3 với replaceUnsafeHead = true
• Do replaceUnsafeHead là true, validatorProof của blobProposer_3 chứng minh rằng nó không phải là slot của blobProposer_2 khi xuất bản B_2
• Giả sử validatorProof là hợp lệ, publicationId_{B_2} bị thay thế bởi publicationId_{B_3} làm unsafeHead
• Các nút Rollup không cập nhật trạng thái vì không có safeHead mới

Slot N+3

• blobProposer_4 là một preconfer hợp lệ xuất bản B_4 với replaceUnsafeHead = false
• Vì replaceUnsafeHead là false, blobProposer_4 của validatorProof chứng minh rằng publicationId_{B_3} đã được gửi trong slot của blobProposer_3
• Giả sử validatorProof là hợp lệ, publicationId_{B_3} được thăng cấp lên safeHead, và publicationId_{B_4} trở thành unsafeHead mới
• Các nút Rollup nhận được sự kiện NewSafeHead và xử lý B_3 để cập nhật trạng thái L2 cục bộ

Giả định

• do mỗi bản xuất bản sẽ thay thế hoặc thăng cấp unsafeHead trước đó, chỉ có thể thêm một bản xuất bản mỗi block để dành thời gian cho beacon block root có sẵn on-chain
• theo giả định trước, một proposer L1 hợp lý sẽ đảm bảo chỉ giao dịch xuất bản của họ được thực hiện
• các bản xuất bản phải diễn ra ít nhất hàng ngày để đảm bảo các đề xuất liên tiếp có thể truy cập các beacon block root cần thiết (chỉ có 8091 beacon block root cuối cùng có thể truy cập on-chain).