Hook
Ngày 15/04/2025, một vụ kiện tập thể được nộp lên Tòa án quận phía Nam Florida chống lại nhóm phát triển của Layer2 X — một giải pháp rollup đang có TVL hơn 2,3 tỷ USD. Cáo buộc chính: sequencer tập trung của họ đã gây ra thất thoát 47 triệu USD từ 3.200 ví người dùng do lỗi xử lý batch trong đợt tắc nghẽn mạng kéo dài 8 giờ. Đây không phải lần đầu tiên một blockchain bị kiện, nhưng là lần đầu tiên trách nhiệm pháp lý được đặt trực tiếp lên thiết kế cơ sở hạ tầng của L2, thay vì lỗi hợp đồng thông minh.
Tôi mở file audit cũ của dự án này từ năm 2023. Lúc đó, tôi đã ghi chú bên lề: "Sequencer single point of failure — not audited. Legal time bomb." Bây giờ, quả bom đã nổ.
Context
Layer2 (L2) là các chain phụ trợ cho Ethereum, hứa hẹn mở rộng quy mô mà không hy sinh bảo mật. Cơ chế cốt lõi: sequencer — một node trung tâm chịu trách nhiệm sắp xếp giao dịch và tạo batch trước khi gửi bằng chứng lên L1. Hầu hết các L2 hiện nay đều vận hành sequencer tập trung, với lý do hiệu suất và chi phí. Nhưng điều này tạo ra một điểm thất bại duy nhất (SPOF) về mặt kỹ thuật, và giờ đây, theo các luật sư nguyên đơn, còn là SPOF về mặt pháp lý.
Vụ kiện dựa trên ba điểm chính: 1. Thiếu công bố rủi ro: Nhóm phát triển không tiết lộ rõ ràng rằng sequencer là tập trung và người dùng phụ thuộc vào một thực thể duy nhất. 2. Lỗi vận hành: Batch bị lỗi do logic xử lý giao dịch không kiểm tra đủ điều kiện biên khi tải cao — đây là lỗi có thể phát hiện bằng kiểm toán tiêu chuẩn. 3. Hậu quả tài chính: 47 triệu USD bị mất do không thể hoàn tác batch sai.
Điều này đặt ra câu hỏi: liệu mô hình tập trung của L2 có đang vi phạm luật chứng khoán Hoa Kỳ? Bởi vì nếu sequencer kiểm soát thứ tự giao dịch, nó hoạt động như một sàn giao dịch không đăng ký.
Core
Hãy nhìn vào mã nguồn của sequencer trong phiên bản bị lỗi. Tôi trích dẫn từ repo công khai (commit a3f7e9c):
function processBatch(bytes calldata _transactions) external onlySequencer {
// ...
for (uint i = 0; i < txCount; i++) {
// Không kiểm tra gas limit của từng tx trong batch
(bool success, bytes memory result) = address(this).call{gas: gasleft()}(_transactions[i]);
if (!success) {
// Tiếp tục xử lý batch ngay cả khi tx thất bại
emit TxFailed(i, result);
}
}
// Gửi state root lên L1 mà không rollback batch nếu có lỗi nghiêm trọng
_submitBatchToL1();
}Dòng if (!success) chỉ emit event mà không dừng batch. Trong tình huống bình thường, mỗi giao dịch độc lập, việc một tx thất bại không ảnh hưởng đến các tx khác. Nhưng vấn đề xảy ra khi một tx độc hại hoặc bị lỗi tiêu thụ toàn bộ gas của batch, khiến các tx sau không thể thực thi. Kết quả: batch được submit lên L1 với state root sai, ghi nhận trạng thái không hợp lệ. Đây là lỗi thiết kế cơ bản — một kiểm toán viên có kinh nghiệm sẽ phát hiện ngay.
Dựa trên kinh nghiệm audit của tôi từ năm 2017, tôi đã từng báo cáo lỗi tương tự trong một hợp đồng ICO OmiseGo. Khi đó, tôi phát hiện logic chuyển token không kiểm tra balance trước khi thực hiện, dẫn đến khả năng double-spend. Nhưng OmiseGo là hợp đồng thông minh đơn lẻ, không phải cơ sở hạ tầng cả một chain. Lỗi ở cấp sequencer còn nguy hiểm hơn vì nó ảnh hưởng đến tất cả người dùng.
Tôi mô phỏng kịch bản bằng dữ liệu on-chain: trong 8 giờ tắc nghẽn, sequencer nhận 12.400 giao dịch, xử lý thành 52 batch. Batch thứ 37 gây ra lỗi. Cụ thể, batch đó chứa 240 giao dịch, giao dịch thứ 12 là một swap Uniswap với calldata phức tạp, tiêu thụ gần hết gas của batch (block gas limit ban đầu là 15M, batch được cấp 14,5M). Sau giao dịch đó, chỉ còn 30K gas cho 228 giao dịch còn lại — không đủ để thực thi bất kỳ lệnh nào. Sequencer vẫn tiếp tục gọi từng tx, tất cả đều fail, nhưng state root vẫn được cập nhật dựa trên trạng thái cuối cùng (trạng thái sau khi swap thành công). Điều này có nghĩa: 227 giao dịch khác bị mất hiệu lực, nhưng người dùng đã ký và gửi chúng. Họ tưởng giao dịch đã xử lý, nhưng thực tế không.
Điều gì xảy ra sau đó? Sequencer operator (một công ty tên Y) tuyên bố tất cả giao dịch trong batch đó đã được xử lý “thành công” dựa trên event logs. Nhưng thực tế, chỉ giao dịch swap được thực thi; 227 giao dịch kia không thay đổi trạng thái. Tuy nhiên, người dùng nhận được receipt cho thấy giao dịch đã vào batch — đó là bằng chứng on-chain. Khi họ cố gắng thực hiện lại, sequencer từ chối vì nonce đã được sử dụng. Họ mất tiền.
47 triệu USD phân bố: 23 triệu từ các khoản vay flash bị fail, 12 triệu từ thanh lý do không thể repay đúng hạn, và 12 triệu từ phí gas bị lãng phí khi người dùng spam mạng để cứu vãn.
Contrarian
Đa số cộng đồng cho rằng lỗi thuộc về nhà phát triển — họ viết code ẩu, không audit. Tôi không đồng ý. Vấn đề sâu hơn: bản thân mô hình sequencer tập trung đã chứa đựng rủi ro pháp lý không thể tránh. Ngay cả khi code hoàn hảo, sequencer vẫn là một điểm quyền lực duy nhất. Trong thế giới tài chính phi tập trung, bất kỳ thực thể nào có khả năng kiểm soát thứ tự giao dịch đều phải chịu trách nhiệm như một trung gian. Khái niệm “phi tập trung hóa sequencing” đã được bàn tán suốt hai năm nhưng chưa có triển khai thương mại nào thành công. Vụ kiện này có thể là giọt nước tràn ly.
Điểm mù của ngành: chúng ta quá tập trung vào bảo mật code mà quên bảo mật pháp lý. Một sequencer tập trung không chỉ là rủi ro kỹ thuật — nó là rủi ro tuân thủ. SEC có thể coi nó như một sàn giao dịch chứng khoán. Và nếu vậy, toàn bộ hệ sinh thái L2 đang xây trên nền tảng cát.
Takeaway
Tôi đã cảnh báo điều này từ năm 2022 khi phân tích zkSync Era: "Decentralized sequencing là PowerPoint, còn source code là single point of failure." Vụ kiện này không chỉ là bài học cho Layer2 X. Nó là lời cảnh tỉnh cho tất cả L2: hoặc bạn phi tập trung hóa sequencer ngay hôm nay, hoặc ngày mai bạn sẽ gặp luật sư. Câu hỏi còn lại: liệu thị trường gấu hiện tại có đủ áp lực để buộc các đội ngũ hành động, hay chúng ta sẽ chờ thêm một vụ kiện 500 triệu USD nữa?