Hook
Có một sự thật kỹ thuật bị bỏ qua trong hầu hết các bài phân tích về AI code generation: khi bạn yêu cầu một mô hình sinh ra một hàm Solidity hay một đoạn Rust, bạn đang tin tưởng vào output đó mà không có bất kỳ bằng chứng toán học nào về tính đúng đắn của nó. Không có ZK proof, không có formal verification. Chỉ có một black box neural network sinh ra token theo xác suất.
Hôm qua, xAI phát hành Grok Build – một mô hình chuyên biệt cho tác vụ lập trình, giới hạn trong gói SuperGrok Heavy. Tin tức lan nhanh. Nhưng tôi không quan tâm đến câu chuyện marketing hay chiến lược định giá. Tôi quan tâm đến một câu hỏi kỹ thuật cốt lõi: nếu Grok Build (hay bất kỳ mô hình code nào) viết smart contract, ai đảm bảo nó không tạo ra lỗ hổng? Trong thế giới blockchain, một dòng code sai có thể gây mất 50 triệu USD.
Context
Grok Build là sản phẩm mới nhất trong cuộc đua AI code assistant. GitHub Copilot, Cursor, Claude Code, Gemini Code Assist – mỗi bên đều có model riêng. Grok Build hứa hẹn khả năng “hiểu real-time trends” nhờ tích hợp dữ liệu từ X (Twitter). Nghe có vẻ thú vị cho developer thông thường. Nhưng với tôi, người audit contract ZK hàng ngày, vấn đề không phải là model viết code nhanh hay chậm, mà là: nó có thể viết code safe không? Liệu nó có hiểu được các ràng buộc của zero-knowledge circuit? Liệu nó có tránh được các lỗi logic tinh vi mà auditor mất hàng tuần mới tìm ra?
Xin nhắc lại: Grok Build đang trong giai đoạn early beta, chỉ dành cho top-tier subscriber. Điều đó có nghĩa là xAI đang thận trọng. Họ không muốn một “Theranos moment” – công bố rộng rãi khi model chưa đủ reliable. Nhưng sự thận trọng của họ chỉ liên quan đến business risk, không phải security risk.
Core Insight
Một transaction, cả câu chuyện.
Hãy tưởng tượng kịch bản: một developer prompt Grok Build “viết một hàm verify Merkle proof trong Solidity”. Model trả về một đoạn code trông có vẻ đúng. Developer deploy lên mainnet. Một tháng sau, hacker khai thác lỗi reentrancy hoặc underflow mà model đã giấu kín trong output. Ai chịu trách nhiệm? Không ai. Code là sản phẩm của AI, nhưng contract là của developer.
Dựa trên kinh nghiệm audit của tôi, các lỗi phổ biến nhất trong smart contract đều đến từ những assumption sai lầm về dữ liệu đầu vào hoặc trạng thái. Một model được huấn luyện trên GitHub, nơi có vô số code buggy, sẽ học được patterns của lỗi. Và nó sẽ tái tạo chúng. Đây là vấn đề không thể giải quyết bằng fine-tuning thông thường.
So sánh với cách làm hiện tại:
- GitHub Copilot: sử dụng code public trên GitHub, filter bằng heuristics. Không có proof.
- Claude Code: Anthropic dùng Constitutional AI và red-teaming. Tốt hơn, nhưng vẫn là black box.
- Grok Build: lợi thế dữ liệu real-time từ X, nơi trader thảo luận về lỗ hổng mới. Nhưng dữ liệu đó cũng có thể chứa misinformation. Một hacker có thể tweet về một “lỗi” giả để đánh lừa model?
Zero-knowledge research có một nguyên tắc: không tin tưởng, phải verify. AI code generation đang vi phạm nguyên tắc đó một cách hệ thống. Model sinh ra code, developer tin tưởng, audit có thể bỏ qua vì “code từ AI chắc an toàn”. Đó là confirmation bias nguy hiểm nhất.
Contrarian Angle
Nhiều người sẽ lập luận rằng AI code assistant giúp developer viết nhanh hơn, giảm lỗi cú pháp, và các công cụ static analysis (Slither, Mythril) có thể bắt lỗi sau. Nhưng góc nhìn của tôi ngược lại: AI code assistant thực chất đang tạo ra một lớp tin cậy mới, mà chúng ta chưa có công cụ để kiểm tra.
Thử nghiệm năm 2018 của tôi với ICO contract của TokenStars cho thấy: một lỗi arithmetic overflow có thể ẩn trong hàng trăm dòng code. Nếu tôi dùng AI để viết contract đó, liệu model có “thông minh” đến mức tránh được lỗi? Chưa chắc. Các benchmark hiện tại (HumanEval, SWE-bench) chỉ kiểm tra functional correctness – code có chạy đúng expected output không. Chúng không kiểm tra security property – code có bị tấn công không. Hai tiêu chí hoàn toàn khác nhau.
Vấn đề thứ hai là incentive misalignment. Model được tối ưu để sinh ra code “looks correct” – dễ đọc, dễ hiểu, tuân theo convention. Nhưng code an toàn thường “ugly” – phải có redundant check, require statements, reentrancy guard. Một model học từ code trên GitHub sẽ học convention của code “đẹp”, không phải code “safe”. Tôi đã chứng kiến nhiều contract audit fail vì developer viết code gọn gàng nhưng thiếu protection.
Takeaway
ZK proof: im lặng nhưng vạn lời.
Grok Build là một bước tiến cho developer experience, nhưng là một bước lùi cho security nếu chúng ta không thay đổi quy trình. Tương lai của AI code generation trong blockchain không chỉ là việc model sinh ra code đúng, mà phải sinh ra code có kèm proof. Một output code + formal verification signature. Một proof rằng code không có reentrancy, không có overflow, tuân thủ spec.
Cho đến khi điều đó xảy ra, tôi vẫn sẽ đọc từng dòng code của Grok Build bằng mắt thường – giống như tôi đã làm với TokenStars năm 2018. Và tôi khuyên mọi developer đang dùng AI code assistant hãy làm điều tương tự. Nếu không, câu hỏi cuối cùng sẽ là: ai sẽ chịu trách nhiệm khi AI của bạn deploy một contract có backdoor?
Câu trả lời: bạn sẽ chịu trách nhiệm – không phải model, không phải xAI.