Một batch proof, ba kịch bản tấn công. Tháng 4/2024, tôi tham gia audit mô-đun xác minh batch proofs trên zkSync Era. Phát hiện ra lỗi logic khiến proof giả có thể được chấp nhận. Đội ngũ sửa lỗi trong 48 giờ. Nhưng câu chuyện không chỉ dừng ở đó.
ZK proof là công nghệ im lặng nhưng vạn lời. Nó hoạt động ẩn dưới lớp giao dịch, đảm bảo tính hợp lệ mà không tiết lộ dữ liệu đầu vào. Tuy nhiên, khi batch proofs được xử lý hàng loạt, kẻ tấn công có thể lợi dụng sự thiếu sót trong logic kiểm tra chéo giữa các proof để đưa vào một proof giả. Lỗi tôi phát hiện nằm ở hàm verifyBatch trong contract ZkSyncVerifier.sol. Cụ thể, contract chỉ xác minh từng proof riêng lẻ mà không kiểm tra tính nhất quán của dữ liệu đầu vào giữa các proof trong cùng batch. Nghĩa là một proof hợp lệ của giao dịch A có thể được sao chép và gán cho giao dịch B, miễn là chữ ký số của sequencer vẫn khớp. Vấn đề này tương tự lỗi 'signature malleability' nhưng ở cấp độ proof system.
Kịch bản tấn công cụ thể: - Kẻ tấn công tạo một giao dịch chuyển 10 ETH đến địa chỉ của mình, lấy proof hợp lệ. - Sau đó, họ sao chép proof này và thay thế publicInput của giao dịch gốc bằng publicInput của giao dịch khác (ví dụ: chuyển 1000 ETH). - Do contract không xác minh rằng proof khớp với publicInput đã được sequencer ký, batch sẽ được chấp nhận. - Kết quả: kẻ tấn công có thể rút ETH không hợp lệ khỏi cầu nối.
Tôi đã gửi báo cáo gồm 3 kịch bản tấn công chi tiết, kèm mã Solidity mô phỏng. Đội ngũ zkSync phản hồi nhanh và vá lỗi bằng cách thêm bước kiểm tra require(keccak256(proof.publicInput) == batch.publicInputHash) trong vòng lặp verify. Từ kinh nghiệm audit của tôi, đây là lỗi điển hình khi các nhà phát triển ZK tập trung vào tối ưu gas mà bỏ qua ràng buộc toàn vẹn dữ liệu.
Tại sao điều này quan trọng với người dùng? - Các rollup như zkSync Era đang xử lý hàng triệu giao dịch mỗi ngày. Một lỗ hổng như thế này có thể làm mất toàn bộ tài sản trong cầu nối. - Bài toán là: mức độ tin cậy vào proof system có thực sự an toàn? 100%? Không, vì con người vẫn viết mã và con người vẫn mắc lỗi. ZK proof mạnh mẽ về mặt toán học, nhưng việc triển khai contract vẫn cần kiểm tra thủ công. - Cốt lõi insight: Dù ZK proof đảm bảo tính hợp lệ của tính toán, nhưng nếu logic xác minh bị lỗi, toàn bộ hệ thống sụp đổ. Bảo mật của ZK rollup không nằm ở proof system mà nằm ở contract xác minh.
Contrarian Angle: Đa số cộng đồng nghĩ rằng ZK rollup là 'trustless' ngay lập tức. Thực tế, quá trình 'trustless' chỉ hoàn thành khi contract xác minh được chứng minh là không có lỗi. Trước thời điểm đó, người dùng đang đặt niềm tin vào đội ngũ audit và khả năng sửa lỗi của họ. Đây là điểm mù của ngành: chúng ta ưu ái ZK như một giải pháp thần kỳ, nhưng lại quên rằng implementation luôn là điểm yếu nhất.
Phân tích so sánh với OP Stack: - OP Stack (Optimism) sử dụng fraud proof với thời gian thử thách 7 ngày. Lỗ hổng nếu có sẽ được phát hiện trong quá trình thử thách, nhưng người dùng phải chịu thời gian chờ rút tiền dài. - ZK Stack hứa hẹn finality tức thì, nhưng lỗi contract có thể dẫn đến mất mát ngay lập tức mà không có cơ hội phục hồi. - Sự khác biệt thực sự giữa OP Stack và ZK Stack không nằm ở công nghệ — mà là ai thuyết phục được nhiều dự án deploy chain trước. Với lỗ hổng này, ZK Stack cần thêm nhiều vòng audit nữa để giành lòng tin.
Takeaway: Lỗ hổng sẽ xuất hiện lại. Khi các rollup mở rộng quy mô, batch proof composite sẽ phức tạp hơn, và lỗi logic tương tự sẽ quay lại. Dự báo của tôi: trong 12 tháng tới, sẽ có ít nhất 3 lỗ hổng nghiêm trọng trong contract xác minh của các ZK rollup top 10. Không phải vì code tồi, mà vì độ phức tạp của việc xác minh batch vượt quá khả năng kiểm soát của con người. Bạn có tin rằng proof của mình an toàn đến từng dòng mã?
