Tóm tắt nhanh
Inclusion List (IL) là cơ chế proposer Ethereum buộc builder phải include một danh sách transaction nhất định vào block — giải pháp trực tiếp cho vấn đề censorship trong PBS ecosystem. Sau khi hơn 70% Ethereum block bị OFAC-compliant builder censor năm 2022, IL trở thành ưu tiên trong Ethereum roadmap giai đoạn Scourge để khôi phục censorship resistance cấp độ L1.
01 Inclusion List là gì?
Inclusion List (IL) là một danh sách transaction mà proposer (validator được chọn) yêu cầu phải được include vào block tiếp theo. Builder muốn bid block cho proposer phải đảm bảo tất cả transaction trong IL được đưa vào block của mình.
Khái niệm này xuất phát từ một câu hỏi cơ bản: Trong PBS (Proposer-Builder Separation), proposer chỉ chọn block cao giá nhất từ builder — nhưng ai đảm bảo builder không censor transaction? Inclusion List là câu trả lời: proposer giữ quyền enforce một tập transaction tối thiểu, dù toàn bộ phần còn lại do builder quyết định.
02 Bối cảnh — Cuộc Khủng hoảng OFAC Censorship
Tháng 8/2022, OFAC (Office of Foreign Assets Control, Mỹ) đưa Tornado Cash vào danh sách trừng phạt. Hậu quả tức thì: các relays và builders tuân thủ OFAC bắt đầu từ chối transaction liên quan đến Tornado Cash addresses.
Quy mô của vấn đề
Trong vài tuần sau lệnh trừng phạt, hơn 70% Ethereum block được produce bởi OFAC-compliant builder thông qua MEV-Boost. Những block này từ chối hàng nghìn transaction mỗi ngày. User bị censor phải đợi nhiều block — đôi khi hàng giờ — để transaction được include bởi builder không OFAC-compliant.
Đây là trường hợp censorship nghiêm trọng nhất trong lịch sử Ethereum và gây ra cuộc tranh luận sâu rộng về thiết kế PBS. Nếu một thực thể ngoài chuỗi (OFAC) có thể effectively censor 70% block, Ethereum có còn là permissionless protocol không?
03 Vấn đề với PBS hiện tại
Trong MEV-Boost PBS hiện tại, flow như sau:
- Proposer broadcast "I want a block for slot X"
- Builders compete, gửi bid (block header + payment)
- Proposer chọn bid cao nhất, ký và gửi lại
- Builder reveal block body
Proposer chỉ thấy block header và payment khi commit — không biết block chứa gì. Họ không thể verify builder có include transaction họ muốn hay không trước khi commit.
Kết quả: Proposer hoàn toàn phụ thuộc vào builder về nội dung block. Builder có toàn quyền censor bất kỳ transaction nào mà không có hình phạt on-chain nào.
04 Cơ chế Inclusion List
Inclusion List giải quyết vấn đề bằng cách cho proposer quyền đặt điều kiện trước khi chấp nhận block của builder.
Quy trình cơ bản
- Proposer xây IL: Tại đầu slot, proposer quét mempool và chọn một số transaction (ví dụ: những tx đã chờ lâu, bị censor) tạo thành Inclusion List. Ký bằng validator key và broadcast.
- Builder nhận IL: Khi builder tạo block bid, họ phải đảm bảo tất cả transaction trong IL được include trong block (trừ trường hợp tx đã trong chain hoặc invalid).
- Proposer verify và commit: Proposer verify block của builder có chứa đủ IL transactions. Nếu có, accept; nếu không, reject và chọn builder khác (hoặc build local block).
- Attester verify: Attesters cũng có thể verify IL compliance — block vi phạm IL có thể bị reject bởi committee.
05 Các Thiết Kế IL Khác Nhau
Có nhiều thiết kế IL với tradeoff khác nhau:
| Thiết kế | Mô tả | Ưu điểm | Hạn chế |
|---|---|---|---|
| Forward IL | IL cho slot N+1 (slot tiếp theo) | Builder có đủ thời gian include | Proposer N và N+1 có thể thông đồng |
| Same-slot IL | IL cho block cùng slot | Khó thông đồng hơn | Timing phức tạp — IL và bid race condition |
| Partial IL | Chỉ một phần tx trong IL là bắt buộc | Linh hoạt hơn cho builder | Builder vẫn có thể censor một phần |
| IL + APS | IL kết hợp Attester-Proposer Separation | Decentralize hơn | Phức tạp nhất, xa nhất trên roadmap |
Ethereum Foundation đang nghiên cứu forward IL (slot N proposer tạo IL cho slot N+1) như thiết kế pragmatic nhất — đơn giản để implement trong khi vẫn cung cấp censorship resistance đáng kể.