Với việc tiêu chuẩn ERC-8004 (Trustless Agents) chính thức được triển khai lên mạng chính Ethereum, quản lý danh tính và uy tín của AI Agent đã bước vào một giai đoạn mới có thể xác minh và không cần tin cậy. Tiêu chuẩn này, thông qua ba sổ đăng ký cốt lõi: Sổ đăng ký Danh tính, Sổ đăng ký Uy tín và Sổ đăng ký Xác minh, cung cấp một "hệ thống nhận dạng" có thể xác minh trên chuỗi cho các đại lý. Bài viết này, từ góc độ kiểm toán bảo mật, kết hợp với các chi tiết kỹ thuật của ERC-8004, sẽ phân tích các điểm rủi ro chính của từng sổ đăng ký, cung cấp một hướng dẫn kiểm toán thực tế cho các nhà phát triển và kiểm toán viên.
Chi tiết kỹ thuật và Điểm kiểm toán
Điểm then chốt của ERC-8004 nằm ở ba sổ đăng ký (Registry) của nó:
1. Sổ đăng ký Danh tính (Identity Registry)
Dựa trên ERC-721 với handle trên chuỗi tối thiểu, có mở rộng URIStorage, phân giải đến tệp đăng ký đại lý, cung cấp định danh có thể mang theo và chống kiểm duyệt cho mỗi đại lý.
Trong kiến trúc ERC-8004, Sổ đăng ký Danh tính được xây dựng trên nền tảng ERC-721 và mở rộng chức năng URIStorage. Nói cách khác, mỗi đại lý trên chuỗi tương ứng với một NFT độc nhất, NFT này được gọi là AgentID.
Khi nhà phát triển tạo một đại lý, họ sẽ gọi hàm register của hợp đồng sổ đăng ký để đúc một AgentID mới. Token này được liên kết với một tokenURI, trỏ đến một tệp JSON được lưu trữ ngoài chuỗi — được gọi là "tệp đăng ký đại lý". Tệp đăng ký phải tuân thủ nghiêm ngặt các quy định, thường bao gồm ba loại nội dung cốt lõi:
- Thông tin cơ bản, ví dụ: tên, mô tả, URL avatar;
- Điểm cuối dịch vụ, tức là địa chỉ mạng mà đại lý có thể được truy cập, hỗ trợ nhiều giao thức như HTTP, WebSocket, Libp2p, A2A, MCP;
- Tuyên bố năng lực, tức là danh sách các nhiệm vụ mà đại lý có thể thực hiện, chẳng hạn như tạo hình ảnh, giao dịch chênh lệch giá hoặc kiểm toán mã.
Chỉ có tuyên bố tự thân rõ ràng là không đủ để xây dựng niềm tin, do đó ERC-8004 giới thiệu cơ chế xác minh tên miền. Đại lý phải lưu trữ một tệp chữ ký tại tên miền mà nó tuyên bố, với đường dẫn là /.well-known/agent-card.json. Sổ đăng ký trên chuỗi sẽ xác minh liên kết này, từ đó liên kết AgentID trên chuỗi với tên miền DNS tương ứng. Bước này có ý nghĩa ngăn chặn các cuộc tấn công lừa đảo và mạo danh; đại lý không thể tự ý tuyên bố mình thuộc về một tên miền nào đó mà phải chứng minh quyền kiểm soát bằng chữ ký mã hóa.
Điểm kiểm toán:
● Kiểm tra điều khiển truy cập của hàm setTokenURI, đảm bảo chỉ cho phép chủ sở hữu đại lý hoặc vai trò được ủy quyền (như onlyOwnerAfterMint) cập nhật URI.
● Xem xét liệu URI có hỗ trợ các phương án lưu trữ bất biến (như IPFS, Arweave) hay không. Nếu sử dụng liên kết HTTP tập trung, cần đánh giá tính bảo mật của quyền kiểm soát tên miền để ngăn chặn chiếm quyền điều khiển DNS.
● Xác minh tính hợp lệ của định dạng URI, tránh các con trỏ null hoặc URI không hợp lệ dẫn đến ngoại lệ hợp đồng.
● Xác minh hợp đồng có thực thi nghiêm ngặt việc xác minh chữ ký mã hóa (như EIP-712) khi kiểm tra chữ ký tên miền hay không, để ngăn chặn giả mạo chữ ký hoặc tấn công phát lại.
● Kiểm tra cơ chế hết hạn của bằng chứng sở hữu tên miền, ngăn chặn việc tái sử dụng chữ ký có hiệu lực lâu dài.
● Đảm bảo quá trình phân giải tên miền không phụ thuộc vào oracle tập trung, tránh lỗi điểm đơn hoặc thao túng.
2. Sổ đăng ký Uy tín (Reputation Registry)
Giao diện tiêu chuẩn để công bố và nhận tín hiệu phản hồi. Việc chấm điểm và tổng hợp diễn ra cả trên chuỗi (có thể kết hợp) và ngoài chuỗi (thuật toán phức tạp), cho phép hệ sinh thái dịch vụ chuyên nghiệp như chấm điểm đại lý, mạng kiểm toán và bể bảo hiểm được thực hiện.
Được sử dụng để đánh giá phản hồi đối với AI Agent đã đăng ký. Phản hồi đơn giản được gửi lên chuỗi, có thể mở rộng ngoài chuỗi để xử lý phức tạp, tổng hợp rồi đưa lên chuỗi.
ERC-8004 còn có thể thông qua cơ chế "Liên kết Bằng chứng Thanh toán" (Payment-Proof Linking) để ngăn chặn việc chấm điểm gian lận. Khi đại lý A hoàn thành đánh giá đại lý B, nó gọi hàm giveFeedback. Hàm này không chỉ chấp nhận điểm số (0-100) và hash bình luận, mà còn cho phép truyền vào một trường paymentProof, thường là hash của giao dịch x402. Điều này làm cho chi phí gian lận đánh giá trở nên cực kỳ cao, giảm đáng kể khả năng tấn công Sybil. Cuối cùng, toàn bộ hệ thống sẽ tự nhiên khen thưởng những đại lý hoạt động ổn định và chất lượng cao.
Điểm kiểm toán:
● Xác minh hàm giveFeedback có bắt buộc yêu cầu tham số paymentProof hay không, và kiểm tra xem tham số đó có phải là hash giao dịch x402 hợp lệ (hoặc tuân thủ tiêu chuẩn thanh toán khác) hay không. Cần đảm bảo bằng chứng thanh toán không thể sử dụng lại (như ghi lại các hash đã sử dụng), ngăn chặn việc một lần thanh toán cho nhiều đánh giá.
● Kiểm tra phạm vi chấm điểm (0-100) có bị ràng buộc ở cấp độ hợp đồng hay không, tránh điểm số vượt quá giới hạn phá vỡ logic tổng hợp.
● Đánh giá khả năng chống thao túng của thuật toán tổng hợp ngoài chuỗi: ví dụ, có sử dụng trung vị, cắt bỏ giá trị cực đoan hoặc trung bình có trọng số hay không, có trừng phạt hành vi bất thường (như số lượng lớn đánh giá trong thời gian ngắn) hay không.
● Xem xét các điều kiện tịch thu có rõ ràng và có thể xác minh hay không, ví dụ: có phụ thuộc vào bằng chứng trên chuỗi hoặc oracle của bên thứ ba gửi bằng chứng gian lận hay không.
● Đảm bảo logic tịch thu không chứa đặc quyền tập trung (như quản trị viên có thể tùy ý tịch thu tiền đặt cọc), điều kiện kích hoạt tịch thu phải hoàn toàn do hợp đồng thông minh tự động thực thi.
● Kiểm tra thời gian khóa và điều kiện rút tiền đặt cọc, ngăn chặn đại lý rút khẩn cấp tiền trước khi đối mặt với việc tịch thu.
3. Sổ đăng ký Xác minh (Validation Registry)
Được sử dụng để yêu cầu và ghi lại các hook kiểm tra của trình xác minh độc lập (ví dụ: trình xác minh zkML, oracle TEE, giám khảo đáng tin cậy).
Uy tín phản ánh quá khứ, nhưng trong các tình huống rủi ro cao (như điều phối số tiền lớn), chỉ dựa vào lịch sử là chưa đủ. Sổ đăng ký Xác minh cho phép đại lý gửi kết quả cho bên thứ ba hoặc hệ thống tự động xác minh, có thể sử dụng các phương pháp như thực thi lại suy luận an toàn có đặt cọc, trình xác minh zkML hoặc oracle TEE để xác minh hoặc từ chối yêu cầu.
Mô hình đầu tiên là xác minh kinh tế mật mã, dựa trên thiết kế an ninh lý thuyết trò chơi. Đại lý phải đặt cọc một số lượng token gốc hoặc stablecoin nhất định trong sổ đăng ký. Nếu đại lý không thực hiện nghĩa vụ hoặc cung cấp kết quả sai, mạng lưới người xác minh có thể gửi bằng chứng gian lận, kích hoạt hợp đồng thông minh tự động tịch thu tiền đặt cọc của họ. Mô hình này phù hợp với các nhiệm vụ dễ xác minh kết quả nhưng quá trình tính toán không minh bạch, chẳng hạn như thu thập dữ liệu hoặc dịch vụ API đơn giản.
Mô hình thứ hai là xác minh mật mã, dựa trên thiết kế an ninh nguyên lý toán học. Chứng nhận TEE (Trusted Execution Environment - Môi trường Thực thi Đáng tin cậy) cho phép đại lý chạy trong môi trường phần cứng được bảo mật, chẳng hạn như Intel SGX hoặc AWS Nitro. Sổ đăng ký Xác minh có thể lưu trữ và xác minh báo cáo chứng nhận từ xa từ phần cứng, chứng minh rằng mã mà đại lý đang chạy thực sự là một phiên bản cụ thể chưa bị sửa đổi.
zkML (Học máy Zero-Knowledge) là một cách xác minh mật mã khác. Khi đại lý gửi kết quả suy luận, đồng thời gửi một bằng chứng zero-knowledge. Bằng chứng này có thể được hợp đồng xác minh trên chuỗi xác minh với chi phí cực thấp, về mặt toán học đảm bảo rằng đầu ra đó thực sự được tạo ra bởi một mô hình cụ thể (như Llama-3-70B) với đầu vào cụ thể. Điều này có thể ngăn chặn cuộc tấn công "đánh tráo mô hình", tức là nhà cung cấp dịch vụ tuyên bố sử dụng mô hình cao cấp nhưng thực tế sử dụng mô hình cấp thấp để tiết kiệm chi phí.
Điểm kiểm toán
Nếu là xác minh kinh tế mật mã, cần kiểm tra:
● Kiểm tra cửa sổ thời gian gửi bằng chứng gian lận: có cho người xác minh đủ thời gian để phát hiện và gửi bằng chứng không? Cửa sổ quá ngắn có thể bỏ sót hành vi độc hại, quá dài thì khiến tiền bị khóa trong thời gian dài.
● Xác minh logic phán quyết của bằng chứng gian lận: có phụ thuộc vào một tập hợp người xác minh đa chữ ký không? Nếu có, cần xem xét mức độ phi tập trung của việc chọn người xác minh và cài đặt ngưỡng; nếu hoàn toàn phán quyết trên chuỗi, cần đảm bảo cơ sở phán quyết (như kết quả có thể xác minh trên chuỗi) tồn tại và không mơ hồ.
● Đảm bảo số tiền đặt cọc phù hợp với rủi ro, ngăn chặn hành vi độc hại chi phí thấp (như đặt cọc quá ít, lợi nhuận từ hành vi xấu lớn hơn nhiều so với thiệt hại).
Nếu là chứng nhận TEE, cần kiểm tra:
● Kiểm tra xem hợp đồng có xác minh tính thời hạn của chứng chỉ TEE không (như chứa dấu thời gian hoặc chiều cao khối), ngăn chặn việc chấp nhận chứng chỉ đã hết hạn.
● Xác minh nội dung chứng chỉ có chứa hash mã, tóm tắt đầu vào/đầu ra của đại lý không, đảm bảo chứng chỉ được gắn với nhiệm vụ cụ thể, tránh tái sử dụng xuyên nhiệm vụ.
● Đánh giá logic xác minh chứng chỉ TEE có phụ thuộc vào oracle bên ngoài (như Intel IAS) không, nếu có, cần kiểm toán tính bảo mật và mức độ phi tập trung của oracle.
Nếu là xác minh zkML, cần kiểm tra:
● Xác nhận hợp đồng đã tích hợp thư viện xác minh zk đã được kiểm toán (như SnarkVerifier) và được cấu hình chính xác khóa xác minh cho hệ thống chứng minh cụ thể (như Groth16, PLONK).
● Kiểm tra hợp đồng xác minh có giới hạn phạm vi mô hình và đầu vào áp dụng cho bằng chứng không, ngăn chặn các cuộc tấn công đánh tráo mô hình (ví dụ: bằng chứng được tạo cho mô hình nhỏ, nhưng lại tuyên bố là đầu ra của mô hình lớn).
● Đánh giá mức độ phi tập trung của việc tạo bằng chứng: có phụ thuộc vào một người chứng minh duy nhất không? Nếu tồn tại nhiều người chứng minh, cần thiết kế cơ chế đồng thuận để ngăn chặn người chứng minh độc hại.
Kết luận
ERC-8004 cung cấp tiêu chuẩn để xây dựng niềm tin cho AI Agent, tính bảo mật của nó là chìa khóa cho toàn bộ hệ sinh thái Agent trên chuỗi. Công việc kiểm toán bảo mật cần hiểu sâu ý định thiết kế và rủi ro tiềm ẩn của ba sổ đăng ký. Ngoài ra, sự phức tạp của tương tác giữa các hợp đồng chéo và các lỗ hổng thông thường cũng không thể bỏ qua. Cần thông qua kiểm toán toàn diện và nghiêm ngặt để đảm bảo ERC-8004 thực sự thực hiện được lời hứa "không cần tin cậy" của nó, đặt nền móng an toàn cho tương lai của các đại lý tự trị.











