Trong 7 ngày qua, tổng TVL của ba ZK-Rollup hàng đầu giảm 15% – không phải vì thị trường bear, mà vì một lỗ hổng trong bộ chứng minh của giao thức A được phát hiện. 0.4% giao dịch trong ngày xử lý 1.2 triệu giao dịch là các cuộc tấn công khai thác điểm yếu này. Tôi không ngạc nhiên. Năm 2023, khi audit một giao thức ZK tương tự, tôi đã cảnh báo đội ngũ phát triển: “Bộ chứng minh của các bạn đang nhìn ổn định, nhưng nó chỉ an toàn trong phạm vi giả định về kích thước đầu vào.” Họ bỏ qua. Kết quả: ba tháng sau, một hacker rút 2.7 triệu USD thông qua việc gửi các chứng minh giả mạo với đầu vào được cố ý làm sai lệch.
Hãy hiểu rõ context. ZK-Rollup không phải là một công nghệ đơn lẻ – nó là một hệ thống phức tạp gồm nhiều lớp: lớp đồng thuận (Ethereum), lớp thực thi (sequencer), và lớp chứng minh (prover network). Lỗ hổng thường không nằm ở lớp đồng thuận – nơi đã được kiểm tra hàng ngàn lần – mà nằm ở lớp chứng minh, nơi các nhà phát triển cắt góc để giảm chi phí gas hoặc tăng thông lượng. Giao thức A trong vụ việc tuần trước sử dụng một biến thể của Groth16 với một số tối ưu hóa cho phép bỏ qua bước kiểm tra “knowledge of exponent” trong một số trường hợp đặc biệt. Đây là một trade-off có chủ ý: họ muốn giảm thời gian chứng minh từ 5 giây xuống còn 0.8 giây. Nhưng họ đã đánh đổi tính đúng đắn toán học để lấy hiệu suất.
Phân tích kỹ thuật cốt lõi: Lỗ hổng nằm ở thuật toán cam kết (commitment scheme) dùng để nén dữ liệu đầu vào. Cụ thể, họ sử dụng Pedersen commitment với một base point cố định nhưng không kiểm tra rằng các scalar nằm trong đúng modulo của nhóm. Kẻ tấn công có thể tạo ra một commitment hợp lệ với một scalar thứ hai khác nhau, dẫn đến việc bộ chứng minh chấp nhận một trạng thái giả. Điều này tương tự như lỗ hổng “double-spend” trong các hệ thống không có tính ràng buộc. Tôi đã thấy điều này nhiều lần trong các dự án ICO năm 2017, nơi các smart contract không kiểm tra điều kiện biên. Chỉ khác ở chỗ bây giờ nó ẩn sâu trong mã nguồn của bộ chứng minh, nơi ít ai dám đụng vào. So sánh với zkSync Era và StarkEx, cả hai đều sử dụng các phương pháp kiểm tra nghiêm ngặt hơn: zkSync dùng PLONK với bước “verify_vk” bắt buộc, StarkEx dùng STARK với tính năng “soundness” có thể chứng minh. Nhưng giao thức A đã chọn Groth16 vì nó sử dụng ít bước kiểm tra hơn trên chuỗi – chỉ 3 cặp pairing thay vì 7 như PLONK. Trade-off này giảm gas phí 40%, nhưng mở ra cánh cửa cho tấn công nếu implementation không cẩn thận.
Điều phản trực giác ở đây là: ZK không tự động đảm bảo bảo mật; nó chỉ chuyển rủi ro từ lớp đồng thuận sang lớp chứng minh. Nhiều người nghĩ “nếu dùng ZK thì an toàn tuyệt đối” – nhưng thực tế, ZK là một công cụ mật mã phức tạp, và mỗi bước tối ưu hóa đều có thể tạo ra một lỗ hổng mới. Điểm mù lớn nhất của các đội phát triển là họ tập trung vào tốc độ tạo proof và chi phí trên chuỗi, mà quên rằng bộ chứng minh – phần off-chain – mới là nơi dễ bị tấn công nhất. Một lỗi nhỏ trong việc implement thuật toán elliptic curve có thể dẫn đến việc kẻ tấn công tạo ra proof cho bất kỳ input nào. Tôi đã từng chứng kiến một dự án sử dụng thư viện bn256 với một phiên bản cũ không kiểm tra điểm vô hạn – và hacker đã khai thác nó để tạo proof hợp lệ cho một state root sai. Vá lỗ trước khi nó rò rỉ. Câu này không chỉ là khẩu hiệu – nó là nguyên tắc sống còn.
Những gì chúng ta cần học từ vụ này: không chỉ các nhà phát triển, mà cả người dùng cũng phải đặt câu hỏi về chất lượng của bộ chứng minh. Một ZK-Rollup không chỉ là một contract trên Ethereum; nó là một hệ thống off-chain phức tạp. Khi bạn deposit tiền vào một rollup, bạn đang tin tưởng vào code của prover network – không chỉ vào toán học. Thử nghiệm càng sớm, tổn thất càng nhỏ. Trong bối cảnh thị trường đi ngang hiện tại, khi các giao thức đang cạnh tranh bằng cách cắt giảm chi phí để thu hút LP, tôi dự đoán sẽ có ít nhất 2-3 lỗ hổng tương tự bị phát hiện trong 6 tháng tới. Các dự án nên ưu tiên audit bộ chứng minh bởi các chuyên gia về mật mã, chứ không chỉ audit smart contract.
Cuối cùng, câu hỏi dành cho bạn: Bạn có biết bộ chứng minh của rollup bạn đang dùng được viết bởi ai, và nó có được kiểm tra bởi một bên thứ ba độc lập không? Nếu câu trả lời là “không”, thì có lẽ bạn đang nắm trong tay một quả bom hẹn giờ toán học.
