ZK-Rollup Việt Nam: Lặp lại sai lầm ICO 2017?

Tháng 3 vừa qua, một dự án ZK-Rollup Việt Nam bị tấn công do lỗi trong hàm verifyProof. Tôi kiểm tra mã nguồn, phát hiện lỗi tương tự với lỗi overflow trong hợp đồng ICO AuraToken năm 2017. Hợp đồng ICO lỗi? Tôi đã thấy và vá nó. Nhưng lần này, lỗi đến từ việc khởi tạo tham số public input không đúng cách, cho phép kẻ tấn công tạo bằng chứng giả. Dự án mất 200 ETH trong 2 block. Tôi gọi ngay cho CTO, nhưng chỉ nhận được câu trả lời: “Chúng tôi đã audit bởi công ty nước ngoài.” Bối cảnh: ZK-Rollup đang là xu hướng hot tại Việt Nam. Tính đến tháng 6, có ít nhất 7 dự án Layer 2 sử dụng zero-knowledge proofs được xây dựng bởi team Việt, với tổng TVL hơn 50 triệu USD. Các dự án này hứa hẹn giảm phí giao dịch 90% và tăng tốc độ. Nhưng liệu có an toàn? Từ kinh nghiệm audit của tôi, hầu hết các dự án đều vội vàng ra mắt mainnet, bỏ qua kiểm thử bảo mật nghiêm ngặt. Họ dựa vào các thư viện ZK có sẵn như snarkjs, nhưng lại custom hóa không đúng cách. Phân tích kỹ thuật: Tôi đã reverse-engineer mã nguồn của 3 dự án Việt Nam đang hoạt động. Kết quả: 2 trong số đó có lỗ hổng kiểu “variable shadowing” trong circuit, dẫn đến việc kẻ tấn công có thể thay đổi output mà không bị phát hiện. Cụ thể, trong một dự án AMM, họ sử dụng zk-SNARKs để chứng minh tính hợp lệ của lệnh swap. Nhưng họ quên kiểm tra ràng buộc số dư, khiến attacker có thể tạo ra swap ảo với số lượng token không giới hạn. Tôi đã viết PoC, chạy thử trên testnet, và xác nhận lỗi có thể gây thiệt hại lên tới 500 ETH nếu khai thác trên mainnet. Dựa trên benchmark, thời gian tạo proof của họ cũng chậm hơn 30% so với tiêu chuẩn ngành, do họ không tối ưu hóa bộ nhớ. Điểm mù bảo mật: Nhiều người nghĩ ZK-Rollup là “siêu an toàn” vì bằng chứng toán học. Nhưng thực tế, lỗi nằm ở implementation. Điểm mù lớn nhất là các team Việt Nam thường “copy-paste” code từ các dự án nước ngoài mà không hiểu sâu về cơ chế. Họ không kiểm tra các ràng buộc phi tuyến tính trong circuit, không test edge cases. Điều này dẫn đến các lỗ hổng như “under-constrained” hoặc “over-constrained” – tôi đã gặp ít nhất 4 lần trong năm qua. Sai lầm này giống hệt với lỗi overflow trong hợp đồng ICO thời 2017: lập trình viên trẻ, thiếu kinh nghiệm, nhưng được đầu tư lớn. Takeaway: Trong 6 tháng tới, tôi dự đoán ít nhất 3 dự án ZK-Rollup Việt Nam sẽ bị exploit tiếp theo. Lý do: họ đang chạy đua về TVL, marketing, mà quên mất rằng một lỗi trong circuit có thể xóa sổ toàn bộ tài sản. Tôi khuyên các nhà đầu tư: hãy yêu cầu team công bố mã nguồn verify, và tự audit bằng công cụ như circomspect. Nếu không, hãy nhìn lại bài học 2017: khi hype qua, chỉ còn lại những smart contract rỗng.