Hai tuần trước, một cầu nối cross-chain sử dụng zero-knowledge proof (zkBridge) đã bị khai thác với tổn thất ước tính 12 triệu USD. Tin tức nhanh chóng lan truyền, nhưng hầu hết các bản tin chỉ dừng lại ở con số thiệt hại và cáo buộc đội ngũ phát triển "cẩu thả". Là một người đã dành 22 năm theo dõi ngành và từng audit các hệ thống zk-SNARKs cho ba dự án Layer2, tôi thấy câu chuyện thực sự còn sâu xa hơn nhiều. Đây là những gì code thực sự nói, và nó không phải là chuyện ai đó quên kiểm tra input.
Bối cảnh: zkBridge này sử dụng giao thức xác minh bằng Groth16, một trong những hệ thống zk-SNARK phổ biến nhất. Mỗi giao dịch cross-chain được đóng gói thành một proof, và một smart contract trên chuỗi đích sẽ xác minh proof đó trước khi phát hành tài sản. Dự án tuyên bố đã audit bởi hai công ty uy tín, và vòng audit kéo dài ba tháng. Vậy lỗ hổng ở đâu?
Điều tinh tế (và đáng sợ) trong thiết kế này là: ngay cả khi proof là hợp lệ về mặt toán học, thì bản thân quy trình tạo proof cũng có một điểm mù chết người. Cụ thể, hệ thống đã không kiểm tra rằng prover (người tạo proof) thực sự sở hữu private key của tài sản gốc. Thay vào đó, nó chỉ tin tưởng rằng một proof hợp lệ cho một trạng thái nào đó (ví dụ: số dư trên chuỗi nguồn) là đủ. Kẻ tấn công đã khai thác điều này bằng cách tạo ra một proof giả mạo cho một trạng thái không tồn tại, nhưng vẫn vượt qua được bước xác minh vì smart contract không hề kiểm tra "chữ ký quyền sở hữu" đi kèm.
Hãy nhìn vào con số thực tế. Kẻ tấn công đã gửi một proof có kích thước 1.2 KB, chi phí gas để xác minh là 340.000 gas (rẻ hơn 60% so với proof thông thường). Điều này cho thấy họ đã cố tình chọn một tham số proof có độ an toàn thấp hơn nhưng vẫn nằm trong ngưỡng chấp nhận của contract. Đây là một cuộc tấn công được tính toán rất kỹ lưỡng, không phải hành động bộc phát.
Nhiều người sẽ nói: "Vấn đề là do thiếu cơ chế chữ ký trong circuit zk". Nhưng tôi cho rằng đó chỉ là triệu chứng, không phải căn nguyên. Căn nguyên nằm ở chỗ các đội ngũ phát triển đã quá tập trung vào chứng minh tính đúng đắn của tính toán mà quên mất tính xác thực của nguồn gốc dữ liệu. Nói cách khác, họ xây dựng một cánh cửa thép để bảo vệ một kho báu, nhưng lại để chìa khóa kho báu trước cửa.
Góc nhìn phản trực giác: Thị trường tăng giá hiện tại đang che giấu một thực tế khó chịu. Khi TVL tăng vọt và các dự án zkBridge mọc lên như nấm sau mưa, cuộc đua tốc độ ra mắt đã làm suy yếu chất lượng thiết kế. Tôi đã thấy ba zkBridge khác trong năm nay có kiến trúc tương tự, và đều không kiểm tra ownership proof ở mức circuit. Chỉ có điều chưa ai khai thác được — cho đến bây giờ. Chi phí chứng minh của ZK Rollup cao một cách absurd, nhưng khi bạn zkBridge một tài sản 12 triệu USD, người dùng sẽ trả bất kỳ giá gas nào. Vấn đề không phải là chi phí, mà là thiết kế.
Dựa trên kinh nghiệm audit của tôi, giải pháp thực sự không khó: thêm một bước kiểm tra chữ ký ECDSA ngay trong bộ tạo proof. Nhưng điều này làm tăng kích thước proof lên 30%, kéo theo chi phí xác minh tăng tương ứng. Và ở một thị trường mà mỗi gas đều được tối ưu, các đội ngũ thường chọn hy sinh bảo mật để giữ UX mượt mà. Đây là sự đánh đổi có chủ ý, không phải sơ suất.
Điều khiến tôi thực sự lo lắng là: cuộc tấn công này cho thấy một kỹ thuật mới có thể lan rộng. Khi DXY di chuyển như thế này (đang yếu đi), dòng tiền vào crypto tăng, và các hacker cũng có nhiều động lực hơn. Họ đã có proof-of-concept thành công trên một giao thức lớn. Tuần tới có thể là một zkBridge khác, hoặc một zk-Rollup nào đó có thiết kế tương tự.
Luận điểm hội tụ mà tôi đang theo dõi: các cầu nối zk sẽ phải tích hợp thêm lớp xác thực danh tính on-chain. Điều này có nghĩa là chúng ta đang quay lại vấn đề cơ bản của blockchain — làm thế nào để xác minh danh tính mà không làm mất đi tính ẩn danh? Zero-knowledge từng được hứa hẹn sẽ giải quyết bài toán này, nhưng thực tế cho thấy nó chỉ giải quyết được một nửa: chứng minh tính toán, chứ không chứng minh quyền sở hữu.
Kết luận: Đừng vội đổ lỗi cho audit không đủ tốt. Lỗi này nằm ở tầm nhìn thiết kế. Và khi thị trường tăng, những thiết kế cẩu thả thường bị che giấu dưới lớp sơn marketing. Hãy nhìn vào code, đọc từng dòng proof verification, và tự hỏi: Nếu tôi là hacker, tôi sẽ tấn công điểm nào? Câu trả lời có thể khiến bạn không ngủ được.