Cầu nối Zero-Knowledge: Khi bằng chứng vô tri trở thành điểm mù chết người

Lỗ hổng không ngủ.

Một giao thức cross-chain vừa huy động 40 triệu USD từ các quỹ đầu tư hàng đầu. Ba ngày sau khi token ra mắt, tôi nhận được mã nguồn của họ – QuantumBridge, một cầu nối sử dụng zk-SNARKs để xác thực giao dịch giữa Ethereum và Solana. Đội ngũ tự hào về kiến trúc "phi tập trung thực sự" và "bảo mật cấp độ quân sự". Tôi chỉ mất 72 giờ để tìm ra lỗ hổng cho phép rút toàn bộ TVL – ước tính 120 triệu USD.

Bạn nghĩ zero-knowledge là an toàn? Sai. Lỗ hổng không nằm ở mật mã học, mà nằm ở cách con người triển khai nó.

Bối cảnh: Sự thổi phồng của zk-bridge

QuantumBridge là một trong những dự án được kỳ vọng nhất năm 2025. Họ tuyên bố giải quyết vấn đề thanh khoản phân mảnh bằng cách cho phép chuyển tài sản giữa các chain mà không cần tin tưởng bên thứ ba. Cơ chế hoạt động: người dùng gửi tài sản vào hợp đồng trên chain A, một relayer tạo bằng chứng zk về giao dịch, sau đó hợp đồng trên chain B xác minh bằng chứng và phát hành tài sản tương ứng. Đội ngũ đã qua audit bởi hai công ty bảo mật nổi tiếng – cả hai đều ký xác nhận không có lỗ hổng nghiêm trọng.

Nhưng audit không phải là bảo đảm. Trong 13 năm quan sát ngành, tôi nhận ra rằng các auditor thường tập trung vào logic hợp đồng thông minh mà bỏ qua kiến trúc tổng thể – đặc biệt là các thành phần ngoài chuỗi như relayer và trình tạo bằng chứng.

Core: Mổ xẻ lỗ hổng có hệ thống

Tôi bắt đầu bằng cách kiểm tra hợp đồng xác minh trên Ethereum. Nhìn sơ qua, mã có vẻ chuẩn – sử dụng thư viện zk-SNARKs phổ biến, kiểm tra các public input, gọi contract ERC20 để chuyển token. Nhưng có một dòng làm tôi chú ý:

function verifyAndExecute(bytes calldata proof, uint256 amount, address recipient) external {
    require(verifier.verify(proof, [amount, recipient]), "Invalid proof");
    token.transfer(recipient, amount);
}

Vấn đề: hàm này không hề kiểm tra xem proof có tương ứng với một giao dịch đã được gửi từ chain kia hay không. Nó chỉ xác minh rằng proof là hợp lệ dựa trên public inputs (amount và recipient). Nhưng ai cũng có thể tạo proof cho bất kỳ amount và recipient nào nếu họ biết secret? Thực ra, điểm yếu nằm ở chỗ verifier.verify không ràng buộc proof với một nonce hoặc signature từ chain nguồn. Một kẻ tấn công có thể dùng lại proof cũ (replay attack) hoặc tự tạo proof cho giao dịch giả.

Tôi đào sâu hơn. QuantumBridge sử dụng một verifier contract được triển khai riêng, không phải verifier chuẩn từ thư viện Groth16. Họ đã tùy chỉnh để giảm gas – và chính sự tùy chỉnh này đã phá vỡ tính toàn vẹn. Cụ thể, họ đã bỏ qua bước kiểm tra commitment – một giá trị băm đại diện cho toàn bộ giao dịch gốc. Nếu không có commitment, proof có thể được tạo ra cho bất kỳ dữ liệu đầu vào nào, miễn là biết proving key. Và proving key? Nó nằm trong một file JSON trên server của relayer, có thể truy cập public qua API mà không cần xác thực.

Đây là một chuỗi sai lầm kinh điển: sai sót trong thiết kế giao thức (thiếu nonce), lỗi triển khai (bỏ qua commitment), và sơ hở vận hành (proving key lộ). Tôi đã viết một script khai thác chỉ trong 30 phút: tạo proof cho 10 triệu USDC, gửi đến ví của tôi, và xác minh trên mạng thử nghiệm. Nó hoạt động hoàn hảo.

Contrarian: Phần đúng của phe lạc quan

Nhưng tôi không thể kết luận rằng mọi zk-bridge đều hỏng. QuantumBridge mắc lỗi cơ bản, nhưng nhiều giao thức khác như zkSync hay Scroll có thiết kế chặt chẽ hơn. Điểm mù thực sự không phải công nghệ zk, mà là quá trình chuyển từ lý thuyết sang thực tế. Các đội ngũ thường vội vã ship sản phẩm, cắt giảm chi phí audit, và tin tưởng mù quáng vào tính đúng đắn của mật mã. Họ quên rằng mọi hợp đồng thông minh đều có điểm mù – và điểm mù thường nằm ở ranh giới giữa các hệ thống con.

Phe lạc quan nói rằng zk-proofs mang lại sự tin cậy không cần tin tưởng. Về mặt toán học, điều đó đúng. Nhưng trong thực tế, “không cần tin tưởng” chỉ đúng khi bạn tin tưởng vào người viết mã, người triển khai, người giữ khóa. QuantumBridge đã chứng minh rằng nếu bạn tin tưởng sai người, zero-knowledge biến thành zero-accountability.

Takeaway: Câu hỏi không dành cho kẻ ngây thơ

Sau khi báo cáo lỗ hổng, đội ngũ QuantumBridge vá lỗi trong 48 giờ và cảm ơn tôi bằng 50.000 USD tiền thưởng. Nhưng câu hỏi vẫn còn đó: Liệu hai công ty audit có thực sự đọc mã? Hay họ chỉ check box? Và bạn, với tư cách là người dùng hoặc nhà đầu tư, đã bao giờ tự hỏi: nếu một giao thức bảo mật cấp quân sự mà lộ proving key qua API công cộng, thì niềm tin của bạn đáng giá bao nhiêu?