Tuần trước, tôi ngồi trước màn hình, kiểm tra log giao dịch của một dApp trên zkSync Era. Hợp đồng trông sạch sẽ, UI bóng bẩy. Nhưng khi tôi chạy thử proof verification với một bằng chứng giả mạo, nó pass. Tôi submit lên Immunefi. 50.000 USD bounty. Bug đã tồn tại 3 tháng, không ai thấy.
Họ tập trung vào UX, quên mất rằng zk proof không chỉ là buzzword – nó là rào chắn cuối cùng giữa tiền của bạn và kẻ tấn công. Và rào chắn đó bị thủng.
Context: Cơn Sốt zk Rollup và Niềm Tin Mù Quáng
Năm 2025, zkSync Era, StarkNet, Scroll chạy đua TVL. Nhà đầu tư bơm tiền vào bất cứ thứ gì có chữ "zero-knowledge". Nhưng họ quên rằng zk proof là một công nghệ trẻ, implementation dễ sai. Tôi đã audit 12 dApp trên các rollup trong 6 tháng qua. 3 trong số đó có lỗi verify zk proof. Không phải lỗi toán học cao siêu, mà là lỗi logic code cơ bản: quên kiểm tra input, dùng thư viện sai version, hoặc không verify proof đủ điều kiện.
DApp tôi audit lần này là một lending protocol – cho vay và vay bằng tài sản được wrap qua zkSync. Họ quảng cáo "bảo mật zk-level". Nhưng contract verify proof của họ chỉ kiểm tra 3 trong 5 điều kiện cần thiết. Attacker có thể tạo proof giả mạo cho bất kỳ giao dịch nào: rút tiền vô hạn, thay đổi lãi suất, thậm chí mint token giả.
Core: Phân Tích Dòng Lệnh – Lỗi Nằm Ở Đâu?
Tôi mở contract chính, tìm hàm verifyProof. Nó dùng thư viện snarkjs – phổ biến. Nhưng nhìn kỹ: