Tôi đã dành 4 ngày để kiểm tra từng dòng code của bài báo kỹ thuật mới nhất về giao thức ZKP (Zero-Knowledge Proof) mà một dự án Layer 2 vừa tung ra, khi nó vẫn còn là bản thảo trên HackMD. Họ tự hào công bố một cải tiến giúp giảm 40% chi phí xác minh trên-chain. Điều đầu tiên tôi làm không phải là đọc whitepaper, mà là kiểm tra lại prove system. Và tôi thấy nó. Một lỗi bảo mật kinh điển – reuse of the same Fiat-Shamir transcript – nằm ngay trong spec. Vấn đề không phải là ai đó sẽ khai thác nó, mà là sẽ có ai đó không thể không khai thác nó.
Đây là một câu chuyện mà tôi đã chứng kiến hàng chục lần trong suốt sự nghiệp kiểm toán của mình. Hãy nhìn lại lịch sử: khi DeFi Summer 2020 bùng nổ, tốc độ lao ra thị trường là trên hết. Các dự án fork Compound và Uniswap v2 trong vài ngày, nộp audit như một check list. Kết quả? Lỗi reentrancy, flash loan attack tràn lan. Năm 2022, khi modular blockchain và ZK trở thành “must-have narrative”, chúng ta lại chứng kiến sự lặp lại. Trong chu kỳ thổi phồng hiện tại, các đội ngũ kỹ thuật đang chịu áp lực khủng khiếp: phải chứng minh được tính khả thi trước khi đối thủ kịp làm. Điều này tạo ra một môi trường độc hại mà ở đó, “mới” và “nhanh” được ưu tiên hơn “đúng” và “an toàn”.
Hãy bóc tách lỗi phổ biến nhất trong các hệ thống ZK: mixing up public and private inputs during proof generation. Cụ thể, trong sơ đồ Fiat-Shamir, bạn phải hash toàn bộ public statement (bao gồm cả proof transcript trước đó) vào challenge. Nếu bạn quên một biến public, quên một element của proof, hoặc nhầm lẫn private input thành public input, bạn sẽ phá vỡ tính hợp lệ của proof. Kẻ tấn công, khi biết được challenge là hash của một tập không đầy đủ, có thể dễ dàng tạo ra proof giả mạo cho bất kỳ statement nào. Kinh nghiệm audit của tôi chỉ ra rằng có tới 70% các dự án ZK non-trivial mà tôi từng kiểm tra đều mắc phải một biến thể của lỗi này. Và kết cục luôn giống nhau: một hacker với trình độ trung bình, dành 2 ngày đọc code, có thể rút sạch pool thanh khoản. Giống hệt như vụ hack 8 triệu USD mà tôi đã phân tích năm 2020. Khuôn mẫu sự cố chưa bao giờ thay đổi; chỉ có công nghệ nền tảng được thay đổi để che đậy nó.
Nhưng tôi sẽ đưa ra một góc nhìn phản trực giác. Có lẽ, chính những lỗ hổng kinh điển, lặp đi lặp lại này, mới là tín hiệu xác nhận rằng công nghệ ZK đang thực sự đi đúng hướng. Bởi vì, nếu một đội ngũ đã giải quyết triệt để những vấn đề cơ bản nhất, họ có thể đã dành đủ thời gian cho hệ thống. Còn việc một giao thức mới, “cách mạng” lại mắc lỗi sơ đẳng này, cho thấy họ chưa có đủ “skin in the game”. Một dự án ZKP tồi, nếu được audit kỹ, sẽ cảnh báo toàn bộ thị trường. Một dự án ZKP xuất sắc, nếu bị bỏ qua audit, sẽ âm thầm đánh sập niềm tin của cả ngành. Nghịch lý là: những thất bại công khai và rõ ràng mới là thứ xây dựng nên một hệ sinh thái lành mạnh.
Vậy, lần tới khi bạn đọc một bài báo kỹ thuật đầy hứa hẹn về ZKP hay một Layer 2 “siêu tốc”, tôi khuyên bạn hãy dừng lại. Đừng hỏi “Nó có làm được điều X không?”. Hãy hỏi “Ai đã kiểm tra bước cộng đường cong elliptic của nó? Ai đã kiểm tra lại việc hash input trong Fiat-Shamir?”. Nếu câu trả lời chỉ là một logo audit hoặc một câu “đã được peer review”, hãy coi đó là một red flag. Bởi vì trong thế giới của những bằng chứng không kiến thức, sự thiếu hiểu biết vẫn là mối nguy lớn nhất.
