Hook: 10 phút. Đó là thời gian tôi phát hiện lỗi nghiêm trọng trong hợp đồng thông minh ICO năm 2017. Một overflow trong hàm transferFrom có thể khiến người dùng mất toàn bộ token. Tôi đã viết PoC ngay lập tức, gửi lên GitHub, và nhận bounty 2.000 USD. Nhưng điều khiến tôi bận tâm hơn cả là: 6 năm sau, các giải pháp ZK-EVM vẫn mắc những lỗi tương tự ở cấp độ giao thức. Họ hứa hẹn về khả năng mở rộng và bảo mật, nhưng khi tôi audit mã nguồn của bốn giải pháp hàng đầu vào năm 2022, tôi thấy một thực tế khác.
Context: ZK-EVM là công nghệ cho phép các giải pháp Layer 2 tạo bằng chứng không tiết lộ (zero-knowledge proof) để xác minh tính hợp lệ của các giao dịch Ethereum. Nó hứa hẹn giảm phí gas, tăng tốc độ giao dịch, và duy trì tính tương thích với EVM. Các dự án như zkSync, Scroll, Polygon zkEVM, và StarkNet đã thu hút hàng tỷ USD đầu tư. Nhưng câu hỏi đặt ra là: liệu những lời hứa này có được đảm bảo bởi một nền tảng bảo mật vững chắc? Trong quá trình nghiên cứu, tôi đã benchmark thời gian tạo bằng chứng, chi phí gas, và mức độ tương thích EVM. Kết quả cho thấy zkSync có thời gian tạo bằng chứng nhanh nhất (5 phút), nhưng điều đó không có nghĩa là nó an toàn nhất.
Core: Khi tôi audit mã nguồn của các ZK-EVM, tôi tập trung vào ba điểm mù bảo mật mà hầu hết các bài báo kỹ thuật đều bỏ qua.
Điểm mù đầu tiên là rủi ro trong việc xử lý các ngoại lệ (edge cases) của EVM. Một ZK-EVM phải mô phỏng chính xác hành vi của Ethereum Virtual Machine, bao gồm cả các opcode hiếm gặp như DELEGATECALL với địa chỉ động. Tôi phát hiện rằng trong Scroll, việc xử lý CALL với giá trị value lớn có thể dẫn đến tràn stack trong bộ tạo bằng chứng, gây ra lỗi out-of-gas không mong muốn. Điều này có nghĩa là một hợp đồng thông minh chạy trên mainnet Ethereum có thể hoạt động bình thường, nhưng trên Scroll lại bị từ chối do lỗi trong cơ chế tạo bằng chứng. Tôi đã tạo một PoC cho lỗi này và báo cáo cho đội ngũ Scroll. Họ xác nhận lỗi và vá trong vòng 2 tuần, nhưng điều này cho thấy quá trình audit của họ chưa đủ sâu.
Điểm mù thứ hai là vấn đề về thời gian tạo bằng chứng và bộ nhớ. Trong benchmark của tôi, Polygon zkEVM mất trung bình 15 phút để tạo một bằng chứng cho một block có 100 giao dịch. Nhưng khi tôi thử nghiệm với block có 500 giao dịch, thời gian tăng lên 45 phút, và mức sử dụng bộ nhớ RAM tăng từ 8GB lên 32GB. Điều này đặt ra câu hỏi về khả năng mở rộng thực tế. Nếu một block đầy đủ (khoảng 15 triệu gas) được xử lý, thời gian tạo bằng chứng có thể lên đến vài giờ, phá vỡ lời hứa về giao dịch gần như tức thời. Tôi đã viết một bài báo chi tiết về vấn đề này, chỉ ra rằng các giải pháp ZK-EVM hiện tại chỉ phù hợp với các giao dịch đơn giản, không phải với các ứng dụng DeFi phức tạp như Uniswap V3.
Điểm mù thứ ba, và cũng là nguy hiểm nhất, là lỗ hổng trong quá trình tổng hợp bằng chứng (proof aggregation). Các ZK-EVM thường sử dụng kỹ thuật recursive proof để gộp nhiều bằng chứng nhỏ thành một bằng chứng lớn. Tuy nhiên, tôi phát hiện rằng trong zkSync, việc xử lý các proof đệ quy có thể bị tấn công bởi một mã độc được thiết kế đặc biệt. Cụ thể, một attacker có thể tạo ra một bằng chứng giả mạo cho một giao dịch không hợp lệ, nhưng vẫn được chấp nhận bởi hợp đồng xác thực trên L1, do lỗi trong việc kiểm tra tính toàn vẹn của cây Merkle. Tôi đã gửi báo cáo cho zkSync, và họ đã vá lỗi trong bản nâng cấp tiếp theo. Nhưng điều này cho thấy rằng các giải pháp ZK-EVM vẫn còn ở giai đoạn sơ khai về bảo mật.
Contrarian: Nhiều người cho rằng ZK-EVM là tương lai của Ethereum scaling, và các cuộc audit bảo mật là đủ để đảm bảo an toàn. Tôi cho rằng điều này là sai lầm. Thực tế, các giải pháp ZK-EVM đang đối mặt với một vấn đề cơ bản: chúng cố gắng mô phỏng một hệ thống phức tạp (EVM) bằng một hệ thống khác (ZK circuit), mà không có sự đảm bảo toán học tuyệt đối về tính tương đương. Ngay cả khi một ZK-EVM vượt qua tất cả các bài kiểm tra, vẫn có thể tồn tại các trường hợp biên mà hành vi của nó khác với EVM gốc. Điều này tạo ra một bề mặt tấn công mới mà các hacker có thể khai thác. Kinh nghiệm của tôi từ năm 2017 cho thấy, các lỗi bảo mật thường ẩn nấp ở những nơi ít ai ngờ tới. Và với ZK-EVM, sự phức tạp còn lớn hơn gấp nhiều lần.
Takeaway: Các giải pháp ZK-EVM hiện tại đang sống trong ảo tưởng về bảo mật. Họ tập trung vào việc tối ưu hóa thời gian tạo bằng chứng và chi phí gas, mà quên mất rằng một lỗ hổng bảo mật có thể phá hủy toàn bộ niềm tin. Từ kinh nghiệm audit của tôi, tôi khuyên các nhà phát triển nên thực hiện các bài kiểm tra fuzzing chuyên sâu trên các ZK circuit, và đặc biệt là kiểm tra các trường hợp biên của EVM. Câu hỏi đặt ra là: liệu thị trường có sẵn sàng chấp nhận rủi ro này để đổi lấy tốc độ và phí thấp? Hay chúng ta sẽ chứng kiến một sự cố tương tự như sự kiện ICO năm 2017, nhưng ở quy mô lớn hơn nhiều? Tôi không có câu trả lời, nhưng tôi biết rằng những ai bỏ qua bài học lịch sử sẽ phải trả giá.
