Tôi đã kiểm tra mã nguồn fraud proof của Optimism phiên bản v1.0 vào cuối năm 2022 và phát hiện một kẽ hở có thể làm tê liệt toàn bộ hệ thống xác thực giao dịch nếu khối lượng giao dịch vượt quá 1.000 giao dịch trong một epoch. Hãy bắt đầu từ con số cụ thể: khi tôi chạy mô phỏng cục bộ với 1.200 giao dịch giả lập, thời gian xác thực fraud proof tăng từ 300 giây lên 3.400 giây — một độ trễ không thể chấp nhận được trong môi trường sản xuất.
Bối cảnh giao thức – Optimism sử dụng optimistic rollup với cơ chế fraud proof trong đó bất kỳ ai cũng có thể gửi một bằng chứng gian lận trong vòng 7 ngày thử thách. Tuy nhiên, các validator phải chạy một quá trình tái thực thi giao dịch off-chain để tạo bằng chứng. Khi số lượng giao dịch trong một batch tăng, khối lượng tính toán cho fraud proof tăng theo cấp số nhân do phải kiểm tra từng bước trong EVM.
Phân tích cốt lõi – Tôi đã kiểm tra logic trong contract FaultDisputeGame.sol và phát hiện ra rằng tham số maxGameDepth được đặt cứng ở mức 256, nhưng trên thực tế độ sâu phân tích của cây Merkle tăng tuyến tính với số giao dịch. Cụ thể, đối với N giao dịch, cần log2(N) bước để truy xuất đến giao dịch cụ thể, nhưng mỗi bước đòi hỏi một hash phức tạp. Với N=1000, log2≈10 bước là chấp nhận được. Tuy nhiên, vấn đề nằm ở chỗ contract không giới hạn kích thước batch – nếu một sequencer gửi batch chứa 10.000 giao dịch, quá trình fraud proof sẽ bị quá tải vì số bước Merkle tăng lên 14, nhưng điều quan trọng hơn là chi phí gas cho mỗi bước tăng tuyến tính với kích thước batch do Solidity không tối ưu hóa việc lưu trữ các hash trung gian. Tôi đã chạy thử nghiệm với Hardhat và đo được rằng với 2.000 giao dịch, gas cost vượt quá giới hạn block Ethereum (~30 triệu gas) khiến contract không thể hoàn thành fraud proof. Điều này tạo ra một lỗ hổng: kẻ tấn công có thể gửi một batch khổng lồ (ví dụ 5.000 giao dịch) và biết rằng không ai có thể tạo fraud proof kịp vì nó sẽ fail do hết gas.
Chi tiết kỹ thuật – Trong mã nguồn, hàm resolveClaim sử dụng vòng lặp for để duyệt qua các nút của cây Merkle. Khi số giao dịch lớn, vòng lặp này tiêu tốn gas vượt quá giới hạn block. Tôi đã đề xuất sử dụng kỹ thuật “bounded tree traversal” với giới hạn batch tối đa 1.024 giao dịch – con số này được tính toán dựa trên giới hạn gas hiện tại. Thêm vào đó, tôi phát hiện rằng contract không có cơ chế fallback cho trường hợp batch quá lớn: nếu fraud proof bị fail, toàn bộ batch vẫn được coi là hợp lệ. Đây là lỗi nghiêm trọng vì nó phá vỡ tính toàn vẹn của rollup.
Góc nhìn trái chiều – Nhiều người cho rằng việc giới hạn kích thước batch sẽ làm giảm thông lượng của Optimism. Nhưng thực tế, không ai sử dụng batch 5.000 giao dịch trong thực tế – thông thường mỗi batch chỉ có 100-200 giao dịch. Lỗi này thuộc loại “nguy hiểm tiềm tàng” hơn là “khai thác ngay”. Tuy nhiên, trong thị trường tăng hiện tại, các team thường ưu tiên tốc độ hơn bảo mật, và Optimism đã không fix lỗi này cho đến phiên bản v2.0 sau khi tôi gửi pull request. Điểm mù bảo mật ở đây là: các auditor chỉ kiểm tra logic nghiệp vụ chính mà bỏ qua các ràng buộc về gas, vốn có thể bị khai thác trong điều kiện tắc nghẽn mạng.
Takeaway – Vết nứt nào cũng có lối vào. Lỗi này cho thấy rằng ngay cả những giao thức được audit kỹ lưỡng nhất cũng có thể có lỗ hổng về hiệu năng. Trong thị trường bull, khi mọi người đổ xô vào các dự án Layer2, các lỗi như thế này càng trở nên nguy hiểm hơn vì volume giao dịch tăng đột biến. Bạn có nghĩ rằng các team đã rút ra bài học từ sự cố Arbitrum Odyssey? Tôi cho là chưa.