Một dòng code trong hợp đồng thông minh của dự án Layer2 vừa huy động 50 triệu USD khiến tôi phải dừng lại.
Dòng require(msg.data.length > 0) xuất hiện ở hàm publish blob. Nó tưởng như vô hại – chỉ kiểm tra dữ liệu đầu vào không rỗng. Nhưng khi đào sâu vào logic phía sau, tôi phát hiện ra điều kỳ lạ: blob thực tế chỉ chứa 32 byte dữ liệu giả, không hề liên quan đến giao dịch thật.
Đây không phải lỗi. Đây là thiết kế cố ý. Và nó đặt ra câu hỏi: chúng ta đang xây dựng hệ thống Data Availability cho ai?
Context: Cơn sốt DA và sự thật về nhu cầu
Data Availability (DA) – khả năng đảm bảo dữ liệu giao dịch luôn có sẵn để bất kỳ ai cũng có thể tải về và xác minh – trở thành mảnh đất màu mỡ nhất cho các dự án Layer2 trong năm 2024-2026. Từ Celestia, EigenDA, Avail đến các giải pháp DA riêng của Ethereum (blob EIP-4844), hàng tỷ USD đổ vào để giải quyết bài toán "chi phí lưu trữ dữ liệu cho rollup".
Câu chuyện thường thấy: "Rollup cần DA rẻ và phi tập trung để giảm phí cho người dùng". Các VC hùng hồn tuyên bố "DA là bottleneck của Layer2". Nhưng tôi – một kẻ đã audit hơn 20 bộ mã nguồn rollup từ năm 2022 – thấy một thực tế khác.
Hầu hết các rollup không tạo ra đủ dữ liệu để cần đến DA chuyên dụng.
Hãy nhìn vào con số: Một rollup điển hình xử lý 100 giao dịch mỗi block Ethereum (12 giây). Mỗi giao dịch nén xuống còn 100 byte sau calldata optimization. Tổng dữ liệu mỗi block chỉ ~10KB. Với blob hiện tại cho phép 128KB mỗi blob, rollup đó chỉ dùng chưa đến 8% dung lượng. Và đây là kịch bản lạc quan – thực tế nhiều rollup chỉ đạt 1-2%.
Vậy tại sao chúng ta lại xây dựng các lớp DA siêu tốc, siêu rẻ khi nhu cầu thực sự còn nhỏ hơn một hạt cát?
Core: Mã nguồn nói lên tất cả
Tôi mở mã nguồn của một rollup phổ biến (tạm gọi là Project X) – dự án từng tuyên bố "giải pháp DA thế hệ mới". Trong file BatchSubmitter.sol, tôi thấy:
