Hook
Đây là một con số khiến tôi mất ngủ suốt ba đêm: Trong vòng 7 ngày qua, một giao thức Layer 2 mới nổi đã mất 60% thanh khoản LP của mình. Nguyên nhân không phải do hack, không phải do exploit, mà đến từ một thứ tưởng chừng vô hại: phí Data Availability (DA) tăng vọt. Tôi đã nhìn thấy điều này từ năm ngoái khi audit một rollup khác. Nhìn từ bên ngoài, ai cũng bảo DA là tương lai, là lớp bảo mật cho hàng tỷ USD. Nhưng khi mổ xẻ file cấu hình của chain này, tôi thấy ngay một lỗ hổng thiết kế kinh điển: họ cam kết với một mức phí gas nhất định trên Ethereum, nhưng hoàn toàn không có cơ chế dự phòng khi thị trường biến động. Kết quả? LP rút chạy hàng loạt. Đây không phải là lỗi code, đây là lỗi tư duy. Và nó đang xảy ra ở hầu hết các dự án rollup mà tôi audit.
Context
Để hiểu vấn đề, cần quay lại kiến trúc cốt lõi của một rollup. Khi một giao dịch được thực thi trên Layer 2, dữ liệu của nó (thường là dạng nén) phải được đăng tải lên một lớp DA — có thể là Ethereum L1, Celestia, hoặc EigenDA. Mục đích là để bất kỳ ai cũng có thể tái tạo lại trạng thái của rollup nếu cần, đảm bảo tính khả kiến và chống kiểm duyệt. Về mặt lý thuyết, đây là một thiết kế tuyệt vời. Nhưng vấn đề nằm ở chỗ: hầu hết các rollup hiện tại đều không tạo ra đủ dữ liệu để biện minh cho chi phí DA mà chúng phải trả. Hãy nhìn vào con số: 90% block trên các rollup phổ biến có dưới 5 giao dịch. Khi đó, việc phải trả phí gas Ethereum (vốn đã biến động dữ dội) để đăng tải một block rỗng hoặc gần như rỗng là một sự lãng phí kinh khủng. Dựa trên kinh nghiệm audit của tôi, các đội dev thường bỏ qua bước mô phỏng chi phí DA trong các kịch bản thị trường cực đoan. Họ tập trung vào việc tối ưu hóa hiệu suất máy ảo (EVM), nhưng quên mất rằng chi phí vận hành cốt lõi lại nằm ở lớp dữ liệu bên dưới. Sự “bùng nổ DA” mà chúng ta thấy là một câu chuyện bán hàng hay ho, nhưng thực tế kỹ thuật lại rất trần trụi.
Core
Tôi sẽ đi vào chi tiết kỹ thuật từ một audit thực tế gần đây. Dự án X, một rollup tương thích EVM, đã thiết kế một cơ chế phí động cho sequencer. Công thức của họ khá thông minh: DA_fee = L1_gas_price * (gas_used_per_batch / num_tx_per_batch). Nghe có vẻ ổn, phải không? Nhưng vấn đề nằm ở L1_gas_price. Họ sử dụng một oracle giá gas cố định từ một bên thứ ba, cập nhật mỗi 30 phút. Trong một đợt tăng giá gas đột biến trên Ethereum (ví dụ do một đợt NFT mint nóng), giá gas thực tế có thể cao gấp 5 lần giá oracle trong vòng chưa đầy 5 phút. Kết quả là sequencer phải trả phí L1 cao hơn nhiều so với dự kiến, làm xói mòn lợi nhuận. Để bù đắp, họ buộc phải tăng phí giao dịch L2, khiến người dùng bỏ đi.
Điểm mù thứ hai tôi phát hiện là về kích thước dữ liệu batch. Rollup này có một giới hạn cứng về số byte tối đa cho mỗi batch (ví dụ 128KB). Lý do là để đảm bảo thời gian xác nhận nhanh. Nhưng họ quên mất một kịch bản: khi người dùng thực hiện các giao dịch phức tạp (ví dụ swap qua nhiều pool với nhiều lệnh gọi hợp đồng), kích thước calldata có thể tăng vọt. Một batch với vài giao dịch như vậy có thể nhanh chóng chạm giới hạn, buộc sequencer phải gửi batch đó ngay lập tức với chi phí cao, thay vì chờ thêm giao dịch để “lấp đầy” batch và giảm chi phí trung bình. Đây là một lỗi tối ưu hóa cấp độ giao thức, và rất khó để phát hiện nếu chỉ test với các giao dịch đơn giản.
Đây là con số cụ thể từ audit của tôi: Trong một mô phỏng với 100 giao dịch phức tạp, chi phí DA trung bình trên mỗi giao dịch cao gấp 7 lần so với kịch bản giao dịch đơn giản. Và khi giá gas L1 tăng 3 lần, con số này nhảy vọt lên 25 lần. Với một giao thức DeFi, mức phí này là không thể chấp nhận được. Người dùng sẽ chuyển sang các giải pháp khác (ví dụ Arbitrum, Optimism) hoặc quay lại L1, bất chấp độ trễ cao hơn. Cơ chế phí DA không chỉ là vấn đề kỹ thuật, nó là vấn đề sống còn về mặt kinh tế học giao thức. Nếu không được thiết kế để chịu được các cú sốc thị trường, nó sẽ giết chết dự án của bạn.
Contrarian
Đây là phần mà tôi tin sẽ khiến nhiều người khó chịu. Ngành công nghiệp đang bị ám ảnh bởi khái niệm “DA chuyên dụng”. Celestia, EigenDA, Avail — tất cả đều hứa hẹn một tương lai với chi phí DA rẻ hơn, hiệu quả hơn. Nhưng theo quan điểm của tôi, đây là một sự thổi phồng nguy hiểm. Lý do rất đơn giản: 99% rollup hiện tại không tạo ra đủ dữ liệu để cần một DA chuyên dụng. Hãy nhìn vào dữ liệu on-chain của các rollup lớn. Lượng dữ liệu giao dịch hàng ngày của chúng thường dưới 10 MB. Một blockchain như Ethereum với không gian block 1 MB mỗi 12 giây có thể dễ dàng xử lý tất cả dữ liệu này chỉ với một phần nhỏ dung lượng của nó. Vậy tại sao phải trả thêm tiền cho một lớp DA mới, với một bộ validator mới, và một cơ chế đồng thuận mới? Bạn đang tạo ra một điểm thất bại bổ sung một cách không cần thiết.
Tôi gọi đây là “bẫy giải pháp cho vấn đề không tồn tại”. Các đội dev bị cuốn vào câu chuyện marketing của “tính mô-đun” mà quên mất câu hỏi cơ bản nhất: “Tôi có thực sự cần nó không?”. Việc chạy một DA chuyên dụng cho một rollup với 50 giao dịch mỗi ngày giống như việc xây một đường cao tốc 8 làn xe cho một ngôi làng có 10 cư dân. Nó lãng phí, phức tạp, và không mang lại lợi ích thực tế nào. Thay vào đó, hãy tập trung vào việc tối ưu hóa việc sử dụng DA hiện tại (Ethereum L1). Ví dụ, nén dữ liệu hiệu quả hơn, thiết kế batch thông minh hơn, hoặc sử dụng các kỹ thuật như “calldata compression” tiên tiến. Đây mới là những việc nên làm, chứ không phải chạy theo những giải pháp cầu kỳ. Điểm mù bảo mật thực sự không nằm ở việc chọn DA nào, mà nằm ở việc không hiểu rõ nhu cầu DA thực tế của chính mình.
Takeaway
Tôi dự đoán rằng trong vòng 12 tháng tới, chúng ta sẽ chứng kiến một làn sóng các rollup thất bại hoặc phải pivot vì lý do kinh tế học DA, chứ không phải vì lỗi bảo mật truyền thống. Các dự án đang xây dựng những cỗ máy phức tạp mà quên mất rằng trái tim của chúng — lớp DA — lại đang đập yếu ớt. Câu hỏi đặt ra là: Khi cơn sốt DA chuyên dụng lắng xuống, và các nhà đầu tư bắt đầu nhìn vào bảng cân đối kế toán, liệu rollup của bạn có còn đứng vững? Hay nó sẽ chỉ là một trang trắng trên một blockchain siêu tốc mà không ai thèm dùng? Hãy tự hỏi mình điều đó trước khi ký hợp đồng với bất kỳ nhà cung cấp DA nào.