Khi AI Quyết Định Và ZK Chứng Minh Nhầm: Bài Học Từ Một Giao Dịch 15 Giây
15 giây. Đó là khoảng thời gian để một validator node xác minh một bằng chứng zk-SNARK trên mạng Ethereum. Cũng trong 15 giây đó, một mô hình AI bên ngoài đã đưa ra quyết định sai lầm về một khoản vay. Vấn đề không nằm ở tốc độ của ZK. Vấn đề nằm ở chỗ: bằng chứng chỉ xác nhận tính toán, chứ không xác nhận tính đúng đắn của dữ liệu đầu vào. Đối mặt với một mô hình AI “hộp đen”, việc sử dụng ZK để chứng minh độ tin cậy của nó giống như bạn kiểm tra xem một chiếc máy bay có bay đúng quỹ đạo hay không, mà không hề biết liệu chiếc máy bay đó có cánh hay không.
Lý thuyết về việc ứng dụng Zero-Knowledge Proof (ZKP) vào xác minh mô hình AI đã được bàn tán sôi nổi trong giới nghiên cứu kể từ năm 2021. Tựa đề: “ZKP-thoughts on AI model verification” không phải là một chủ đề mới, nhưng nó đang trở nên cấp thiết hơn bao giờ hết khi các ứng dụng DeFi và chuỗi chéo bắt đầu phụ thuộc vào các oracle và quyết định từ các mô hình học máy. Vấn đề cốt lõi rất đơn giản: làm sao để một blockchain phi tập trung tin tưởng vào một quyết định từ một AI mà không cần phải chạy lại toàn bộ mô hình đó (vốn cực kỳ tốn kém về mặt tính toán) và cũng không làm lộ dữ liệu đầu vào hoặc trọng số của mô hình? Đây là một bài toán về hiệu quả và quyền riêng tư, và ZKP được kỳ vọng là câu trả lời.
Trong quá trình audit các giao thức vay DeFi vào đầu năm 2024, tôi đã chứng kiến một kịch bản điển hình. Một hệ thống cho vay sử dụng một mô hình hồi quy logistic (V2) đã được xác thực qua zk-SNARKs để quyết định hạn mức tín dụng. Bề ngoài, mọi thứ hoạt động hoàn hảo: bằng chứng được sinh ra trong 2 giây, xác minh trên chuỗi trong 0.5 giây. Tuy nhiên, khi tôi đào sâu vào logic tạo bằng chứng, tôi phát hiện ra một lỗi cơ bản: Verifier contract chỉ kiểm tra rằng quá trình tính toán diễn ra đúng theo một tập hợp các trọng số cố định (circuit), nhưng không hề kiểm tra xem trọng số đó có phải là trọng số của mô hình chính thức đã được chấp nhận hay không. Một kẻ tấn công tinh vi có thể tạo một mô hình giả mạo, với các trọng số được tùy chỉnh để phê duyệt các khoản vay rủi ro, sau đó dùng ZKP để chứng minh tính hợp lệ của nó trên chuỗi. Lỗ hổng nằm ở chỗ Circuit file không được cập nhật thông qua một cơ chế on-chain đáng tin cậy. Trong trường hợp này, chi phí gas để deploy lại circuit (khoảng 5,000 USD) đã bị xem nhẹ so với lợi nhuận kỳ vọng từ việc cắt giảm thời gian xác minh, dẫn đến một mô hình bảo mật không hoàn chỉnh. Dữ liệu mô phỏng cho thấy 40% các giao dịch rủi ro có thể đã bị thông qua nếu không có lớp kiểm tra thứ hai này. Đây là sự đánh đổi điển hình: hiệu quả xác minh tăng lên, nhưng bề mặt tấn công của quá trình khởi tạo và cập nhật model cũng mở rộng tương ứng. Nếu không có quy trình quản lý khóa và phiên bản mô hình chặt chẽ, ZKP chỉ là một lớp sơn bóng bảo mật.
Điểm mù trong cuộc thảo luận hiện tại là sự nhấn mạnh quá mức vào khả năng chứng minh của ZK, trong khi quên mất khả năng thu hồi và cập nhật. Hầu hết các bài viết đều tập trung vào việc “ZK có thể chứng minh rằng một mô hình đã được huấn luyện đúng cách”. Nhưng thực tế, các mô hình AI liên tục thay đổi. Một mô hình phát hiện gian lận hôm nay có thể trở nên lỗi thời trong vòng một tuần. Các giải pháp ZKP hiện tại (như zk-SNARKs yêu cầu xây dựng lại circuit mỗi lần thay đổi model) tạo ra một gánh nặng vận hành khổng lồ. Chúng ta đang đầu tư vào việc chứng minh “mô hình này là đúng” cho một phiên bản duy nhất, trong khi giá trị thực sự nằm ở khả năng chứng minh “mô hình này đã được cập nhật và vẫn đúng”. Để làm được điều đó, cần một cơ sở hạ tầng modular hơn, nơi việc chứng minh được tách rời khỏi chính mô hình, tương tự như cách mà các chuỗi modular tách biệt đồng thuận khỏi thực thi. Công nghệ ZK có thể là chìa khóa, nhưng nó đang cố gắng mở một cánh cửa trong khi bức tường vẫn còn đứng vững. Chúng ta cần một hệ thống quản lý phiên bản mô hình có thể xác minh được bằng cryptography, chứ không chỉ là một bằng chứng đơn lẻ về một trạng thái tĩnh.
Khi tôi nhìn vào các dự án đang thử nghiệm ZKP cho AI, tôi thấy một sự lặp lại của lịch sử. Năm 2018, tôi từng audit một giao thức order matching (0x Protocol v2) và phát hiện lỗ hổng vì họ chỉ tập trung vào tính đúng đắn của từng lệnh, mà quên mất logic sắp xếp tổng thể. Hiện tại, với ZKP và AI, câu chuyện cũng vậy: người ta chỉ tập trung chứng minh “mô hình này đã được huấn luyện” mà quên mất “mô hình này đang được sử dụng trong bối cảnh nào”. Lời khuyên của tôi cho những ai đang xây dựng ở giao điểm này là: đừng chỉ tối ưu hóa tốc độ tạo bằng chứng. Hãy dành thời gian để thiết kế một cơ chế cập nhật model an toàn, nơi mà việc thay thế một bằng chứng cũ bằng một bằng chứng mới không tạo ra một cửa sổ tấn công. Nếu không, bạn đang tạo ra một hệ thống có thể chứng minh mọi thứ, ngoại trừ sự thật. Liệu một giải pháp có thể chứng minh một mô hình AI đã sai hay không, mới là câu hỏi quan trọng hơn.
