Hook
Một bức tường lửa sụp đổ, và dòng dữ liệu bị bơm xả ngược. Không, tôi không nói về một vụ hack DeFi nữa. Tôi đang nói về cách Andrej Karpathy, nhà đồng sáng lập OpenAI, vừa công khai một phương pháp làm việc với AI mà theo tôi sẽ làm thay đổi cách chúng ta audit smart contract. Phương pháp gọi là “long-form verbal prompting” – dài dòng, lộn xộn, nói như trút bầu tâm sự. Nhưng đừng nhầm: đây không phải là mẹo tăng năng suất. Đây là một lỗ hổng trong tư duy của toàn bộ ngành bảo mật blockchain.
Context
Hơn 2 năm làm Market Surveillance Analyst tại Tallinn, tôi đã chứng kiến hàng trăm vụ hack. Điểm chung: không phải code sai, mà là con người không đặt đúng câu hỏi. Một audit thường bắt đầu với một spec rõ ràng, một danh sách yêu cầu khô khan. Người audit ngồi đọc code, tìm lỗi theo checklist. Rồi bot của tôi quét pool thanh khoản, phát hiện mô hình bơm xả – cũng dựa trên dữ liệu đã được cấu trúc sẵn. Vấn đề ở đây là tư duy tuyến tính – chúng ta nghĩ rằng một vấn đề phức tạp có thể được giải quyết bằng một lời nhắc chính xác. Karpathy chỉ ra: không, bộ não con người không hoạt động như vậy. Chúng ta suy nghĩ bằng những mảnh ghép rời rạc, những ý tưởng nhảy cóc, những lo lắng mơ hồ. Và phương pháp của anh ấy – nói 10 phút mà không cần tổ chức, để AI hỏi lại – chính là tận dụng sức mạnh của sự hỗn loạn.
Core
Tôi đã thử nghiệm ngay trên bot Python của mình. Thay vì viết prompt yêu cầu quét pool thanh khoản theo tham số, tôi bật micro, nói 5 phút: “Mày biết không, tao thấy có mấy pool trên Uniswap V3 lạ lắm. Mà không biết có phải do thanh khoản thấp hay do cá voi đang chơi trò gì. Mà thôi, mày cứ xem cái contract lưu trữ metadata của OpenSea nữa, hồi 2021 tao từng phát hiện lỗi URI bị thay đổi sau mint. Ừ thì tao muốn mày xây một cái framework đánh giá rủi ro cho tất cả pool mới trong 24 giờ qua, nhưng mà đừng báo cáo dài quá, chỉ highlight cái gì bất thường thôi.” Kết quả: AI đặt 3 câu hỏi – “Pool nào có TVL dưới 10 ETH thì có cần loại trừ không?”, “Có cần cross-check với dữ liệu giá từ Coingecko không?”, “Mức độ bất thường theo số lần giao dịch hay theo biến động giá?”. Tôi trả lời từng câu, rồi nó sinh ra một bảng đánh giá rủi ro 10 dòng. Chính xác cái tôi cần, nhưng mà tốn ít thời gian hơn nhiều so với việc tôi phải ngồi suy nghĩ và gõ từng dòng prompt.
Phân tích kỹ thuật: Phương pháp này dựa trên 3 nền tảng. Thứ nhất, khả năng hiểu ngữ cảnh dài của mô hình – với 128k token context, 10 phút nói (khoảng 1500 từ) chỉ chiếm 1/10. Thứ hai, khả năng chủ động hỏi – đây là điểm mấu chốt. Hầu hết các mô hình khi nhận prompt lộn xộn sẽ cố gắng suy diễn và trả lời ngay, dẫn đến sai lệch. Karpathy khuyến khích mô hình “phỏng vấn ngược” – và điều này yêu cầu mô hình có thể nhận diện điểm mù trong yêu cầu của bạn. Thứ ba, giảm tải nhận thức – bạn không cần phải tổ chức suy nghĩ trước khi nói; bạn chỉ cần “xả” hết những gì trong đầu, và AI sẽ làm công việc tổ chức sau. Điều này đặc biệt hữu ích trong audit, nơi mà một lỗ hổng thường nằm ở ranh giới giữa các module, nơi mà trực giác của bạn nói “có gì đó sai” nhưng bạn chưa thể diễn đạt thành lời.
Từ góc nhìn bảo mật hệ thống, phương pháp này tiết lộ một sự thật khó chịu: các audit truyền thống đang bỏ qua phần lớn tri thức ngầm của người audit. Khi bạn giao cho tôi một smart contract EOS.IO để kiểm tra, tôi dành 3 tuần đọc code và suy nghĩ. Nhưng nếu tôi chỉ việc nói ra tất cả nghi ngờ của mình trong 10 phút, để AI đặt câu hỏi và sau đó tìm bằng chứng trên chuỗi – quy trình có thể rút xuống còn vài giờ. Không phải vì AI giỏi hơn, mà vì nó bắt buộc tôi phải “nghĩ ra tiếng” và đối mặt với những khoảng trống trong lập luận của mình thông qua các câu hỏi của nó.
Contrarian
Nhưng tôi không lạc quan. Hãy bơm xả một chút – có một góc tối mà Karpathy không nói. Bức tường thực sự ở đây không phải là khả năng của AI, mà là tính riêng tư và bảo mật của dữ liệu đầu vào. Bạn đang nói 10 phút, tiết lộ mọi suy nghĩ lộn xộn của mình về một dự án – bao gồm cả những nhận định chưa kiểm chứng, những con số nhạy cảm, thậm chí cả những đồng nghiệp bạn nghi ngờ. Tất cả đều được ghi lại và xử lý trên cloud. Trong audit bảo mật, đây là thảm họa. Một lần tôi phát hiện lỗ hổng trong hợp đồng ICO EOS.IO, tôi đã báo cáo kín qua GitHub. Nếu tôi dùng phương pháp này với một AI không đảm bảo dữ liệu, thông tin có thể rò rỉ và kẻ tấn công sẽ khai thác trước khi dự án kịp vá.
Hơn nữa, phương pháp này giả định AI có khả năng đặt đúng câu hỏi. Nhưng AI cũng bị giới hạn bởi kiến thức nền của nó. Trong các lĩnh vực chuyên sâu như mật mã học (chuyên ngành của tôi), AI thường hỏi những câu sáo rỗng. Nó không biết rằng một lỗi trong cơ chế phân phối token thường đến từ việc không kiểm tra overflow trong phép nhân. Nếu tôi không nói ra điều đó, AI sẽ không hỏi. Vậy gánh nặng vẫn đè lên vai tôi – tôi vẫn phải biết trước những gì cần hỏi.
Cuối cùng, đây là con dao hai lưỡi về mặt tâm lý. Phương pháp này khiến bạn cảm thấy mình đang “nói chuyện” với một đồng nghiệp thông minh. Bạn dễ bị bơm xả cảm giác tin tưởng sai lầm. Một AI hỏi “Có cần kiểm tra reentrancy không?” – bạn gật đầu, và nó kiểm tra. Nhưng nếu nó không hỏi về flash loan attack, bạn sẽ bỏ qua. Hệ quả là những lỗ hổng nằm ngoài “vùng hiểu biết” của AI sẽ bị bỏ sót hoàn toàn, và bạn thậm chí không nhận ra mình đã bỏ sót.
Takeaway
Tôi không nói hãy bỏ audit truyền thống. Nhưng tôi đang tích hợp phương pháp này vào bot của mình: một bước “verbal brainstorming” trước khi chạy các script kiểm tra chính thức. Nó giúp tôi phát hiện những góc khuất tưởng chừng như ngẫu nhiên – những câu hỏi mà tôi không bao giờ viết ra trong prompt. Câu hỏi thực sự là: liệu ngành bảo mật blockchain có đang xây dựng quá nhiều bức tường quy trình để bảo vệ chúng ta khỏi sự hỗn loạn, đến nỗi chúng ta mất đi khả năng phát hiện những điểm mù do chính quy trình tạo ra? Một bức tường lửa có thể bị vượt qua không phải vì nó yếu, mà vì nó được xây theo một thiết kế mà kẻ tấn công đã biết trước. Đã đến lúc xé bỏ một vài bức tường đó – và bắt đầu bằng cách nói chuyện với AI như một người bạn loạn trí.