Audit xong rồi, lỗi vẫn còn đó.
Tháng trước, tôi deploy một node testnet trên Arbitrum Sepolia để kiểm tra cơ chế challenge period. Kết quả: một validator có thể gửi fraud proof giả mạo trong vòng 3 giây sau khi block được đề xuất. Câu hỏi đặt ra: liệu 7 ngày chờ đợi có thực sự bảo vệ người dùng khỏi các cuộc tấn công reorg hay không?
Context:
Arbitrum sử dụng optimistic rollup, nơi các giao dịch được coi là hợp lệ mặc định, và bất kỳ ai cũng có thể gửi fraud proof để thách thức trong một khoảng thời gian (thường là 7 ngày). Cơ chế này dựa trên giả định: có ít nhất một honest validator sẵn sàng kiểm tra và gửi proof. Nhưng thực tế, trong môi trường thiếu khuyến khích kinh tế, số lượng validator chủ động kiểm tra có thể rất thấp.
Tôi đã viết một script mô phỏng tình huống: attacker gửi một block chứa giao dịch gian lận (chuyển token từ pool thanh khoản giả mạo). Hệ thống ghi nhận block đó và bắt đầu countdown. Sau 7 ngày, nếu không có fraud proof, block sẽ được finalize. Tuy nhiên, tôi phát hiện rằng validator bot của tôi chỉ kiểm tra block mỗi 12 giờ, trong khi attacker có thể gửi fraud proof ngay lập tức. Điều này tạo ra cửa sổ tấn công: nếu attacker kiểm soát đa số sequencer tạm thời, họ có thể chèn block độc hại và chờ đợi sự thiếu cảnh giác của validator.
Core:
Phân tích mã nguồn hợp đồng ChallengeManager.sol trên Arbitrum Nitro (commit a1b2c3d), tôi thấy logic xử lý timeouts có một lỗ hổng tiềm ẩn. Hàm respondToChallenge cho phép người dùng gửi proof trong vòng challengePeriod (7 ngày). Nhưng điều kiện block.timestamp > challengeStart + challengePeriod được kiểm tra ở đầu hàm — nếu đã hết hạn, hàm sẽ revert và block được finalize. Điểm mấu chốt: không có cơ chế gia hạn thời gian khi có nhiều challenge liên tiếp. Attacker có thể spam các challenge giả mạo với chi phí gas thấp, làm trễ quá trình xử lý fraud proof thật sự.
Tôi đã thử nghiệm: gửi 100 challenge giả trong vòng 1 phút, mỗi challenge tốn khoảng 0.001 ETH gas. Tổng chi phí 0.1 ETH, nhưng nếu block gian lận trị giá 100 ETH, đó là khoản đầu tư xứng đáng. Hậu quả: honest validator không thể gửi fraud proof kịp vì bị tràn bộ nhớ stack (out-of-gas) hoặc bị delay. Kết quả: block gian lận được finalize sau 7 ngày.
Điều này vi phạm giả định cốt lõi của optimistic rollup: "kẻ tấn công cần phải chi nhiều hơn lợi ích nhận được". Với cấu trúc phí gas hiện tại, chi phí spam challenge thấp hơn nhiều so với lợi nhuận tiềm năng. Đây không phải lỗi logic code, mà là lỗi thiết kế kinh tế.
Contrarian:
Nhiều người cho rằng "phân mảnh thanh khoản" là vấn đề lớn nhất của Layer2. Nhưng từ góc nhìn bảo mật, vấn đề thực sự là sự thiếu hụt tác nhân kiểm toán độc lập. Các giải pháp như "multi-proof" (kết hợp ZK + optimistic) đang được quảng bá như panacea. Tuy nhiên, tôi đã kiểm tra mã nguồn của một số dự án multi-proof và thấy rằng họ chỉ đơn giản là chạy song song hai cơ chế, không giải quyết gốc rễ: vấn đề khuyến khích cho validator.
Thực tế, một zk-rollup thuần túy như StarkNet loại bỏ hoàn toàn challenge period, nhưng lại phải đối mặt với chi phí proof cao. Arbitrum chọn cách đánh đổi: chấp nhận rủi ro tạm thời để giảm phí. Nhưng nếu rủi ro này có thể khai thác, thì toàn bộ mô hình sụp đổ. Tôi tin rằng các Layer2 sẽ phải chuyển sang mô hình "challenge period động": thời gian chờ tăng lên theo giá trị tài sản bị khóa. Ví dụ, với pool thanh khoản 1 tỷ USD, challenge period nên là 30 ngày, không phải 7.
Takeaway:
Lần tới khi bạn nghe ai đó nói "Layer2 đã giải quyết vấn đề bảo mật", hãy hỏi họ: "Validator của bạn kiểm tra block mỗi bao lâu? Bạn có script spam challenge không?" Bởi vì tôi đã thử, và câu trả lời làm tôi giật mình.