Với việc triển khai chính thức tiêu chuẩn ERC-8004 (Trustless Agents) lên mạng chủ Ethereum, việc quản lý danh tính và uy tín của các tác nhân AI đã bước vào một giai đoạn mới, có thể kiểm chứng và không cần sự tin tưởng. Tiêu chuẩn này cung cấp cho các tác nhân Chuỗi 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. Bài viết này sẽ phân tích các rủi ro rủi ro của mỗi sổ đăng ký 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, và cung cấp cho các nhà phát triển và kiểm toán một hướng dẫn kiểm toán thực tiễn.
Chi tiết kỹ thuật và các điểm kiểm toán
Điểm mấu chốt của ERC-8004 nằm ở ba mục nhập trong thanh ghi của nó:
1. Cơ quan đăng ký danh tính
Một mã định danh tối thiểu trên Chuỗi dựa trên ERC-721, với mở rộng URIStorage, sẽ được giải quyết thành tệp đăng ký của tác nhân, cung cấp một mã định danh di động, chống kiểm duyệt cho mỗi tác nhân.
Trong kiến trúc ERC-8004, hệ thống đăng ký định danh đượ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 tác nhân tương ứng với một NFT duy nhất trên Chuỗi, và NFT này được gọi là AgentID.
Khi một nhà phát triển tạo ra một tác nhân, họ gọi hàm `register` của hợp đồng đă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ý tác nhân". Tệp đăng ký phải tuân thủ các thông số kỹ thuật nghiêm ngặt và thường bao gồm ba yếu tố cốt lõi:
- Thông tin cơ bản, chẳng hạn như tên, mô tả và URL ảnh đại diện;
- Điểm cuối máy chủ, tức là địa chỉ mạng mà máy chủ proxy có thể truy cập, hỗ trợ nhiều giao thức như HTTP, WebSocket, Libp2p, A2A và MCP;
- Khai báo khả năng, là danh sách nhiệm vụ mà tác nhân có thể thực hiện, chẳng hạn như tạo ảnh, giao dịch chênh lệch giá hoặc kiểm toán mã.
Việc tự khai báo thôi là chưa đủ để tạo dựng lòng tin, do đó ERC-8004 giới thiệu cơ chế xác minh tên miền. Các tác nhân phải lưu trữ một tệp chữ ký dưới tên miền đã khai báo của họ, tại đường dẫn /.well-known/agent-card.json. Hệ thống đăng ký Chuỗi sẽ xác minh liên kết này, từ đó liên kết AgentID Chuỗi với tên miền DNS tương ứng. Bước này rất quan trọng để ngăn chặn các cuộc tấn công Phishing và mạo danh; các tác nhân không thể tùy ý tuyên bố quyền sở hữu tên miền và phải sử dụng chữ ký crypto để chứng minh quyền kiểm soát.
Trọng tâm kiểm toán:
● Kiểm tra quyền truy cập của hàm setTokenURI để đảm bảo rằng chỉ chủ sở hữu ủy quyền hoặc nhân vật được ủy quyền (chẳng hạn như onlyOwnerAfterMint) mới được phép cập nhật URI.
● Xác minh rằng URI hỗ trợ các giải pháp lưu trữ bất biến (như IPFS hoặc Arweave). Nếu sử dụng kết nối HTTP tập trung, đánh giá tính bảo mật của việc kiểm soát tên miền để ngăn chặn tấn công chiếm quyền điều khiển DNS.
● Kiểm tra tính hợp lệ của định dạng URI để tránh các ngoại lệ hợp đồng do con trỏ null hoặc URI không hợp lệ gây ra.
● Xác minh xem hợp đồng có thực hiện nghiêm ngặt việc xác thực chữ ký crypto (như EIP-712) khi xác thực chữ ký tên miền hay không để ngăn chặn ngụy tạo chữ ký hoặc các cuộc tấn công phát lại.
● Kiểm tra cơ chế hết hạn của chứng chỉ quyền sở hữu tên miền để ngăn chặn việc tái sử dụng các chữ ký có hiệu lực lâu dài.
● Đảm bảo rằng quy trình phân giải tên miền không phụ thuộc vào một oracle tập trung để tránh các điểm lỗi hoặc thao túng đơn lẻ.
2. Sổ đăng ký danh tiếng
Một giao diện tiêu chuẩn để xuất bản 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(khả năng kết hợp) và ngoài Chuỗi(các thuật toán phức tạp), cho phép hình thành một hệ sinh thái dịch vụ chuyên nghiệp về chấm điểm ủy quyền, mạng lưới kiểm toán và các quỹ bảo hiểm.
Công cụ này được sử dụng để đánh giá và cung cấp phản hồi về các Tác nhân AI đã đăng ký. Các phản hồi đơn giản được gửi Chuỗi, trong khi các phản hồi phức tạp hơn có thể được gửi ngoài Chuỗi, và phản hồi tổng hợp sau đó được tải lên Chuỗi trên chuỗi.
ERC-8004 cũng có thể ngăn chặn việc thao túng xếp hạng độc hại thông qua cơ chế "Liên kết bằng chứng thanh toán". Khi tác nhân A hoàn thành đánh giá về tác nhân B, hàm `giveFeedback` được gọi. Hàm này không chỉ chấp nhận xếp hạng (0-100) và mã băm của đánh giá, mà còn cho phép trường `paymentProof`, thường là mã băm của giao dịch x402. Điều này làm cho chi phí thao túng đánh giá trở nên cực kỳ cao, giảm đáng kể khả năng xảy ra các cuộc tấn công Phù thủy. Cuối cùng, toàn bộ hệ thống sẽ tự động thưởng cho các tác nhân có hiệu suất ổn định và chất lượng cao.
Trọng tâm kiểm toán :
● Xác minh rằng hàm `giveFeedback` yêu cầu tham số `paymentProof` và kiểm tra xem đó có phải là mã băm giao dịch x402 hợp lệ (hoặc tuân thủ các tiêu chuẩn thanh toán khác) hay không. Đảm bảo rằng bằng chứng thanh toán không được sử dụng lại (ví dụ: ghi lại các mã băm đã sử dụng) để ngăn chặn việc đánh giá lần một khoản thanh toán lần .
● Kiểm tra xem thang điểm (0-100) có được áp dụng ở cấp độ hợp đồng hay không để ngăn chặn các điểm số vượt quá giới hạn làm phá vỡ logic tổng hợp.
● Đánh giá khả năng chống lại sự thao túng của các thuật toán tổng hợp Chuỗi chuỗi: ví dụ, liệu có nên sử dụng số trung vị, loại bỏ các giá trị cực đoan hay trung bình có trọng số, và liệu có nên xử phạt hành vi bất thường (chẳng hạn như lượng lớn trong một khoảng thời gian ngắn) hay không.
● Xem xét liệu các điều kiện tịch thu có rõ ràng và có thể kiểm chứng được hay không, chẳng hạn như liệu chúng có dựa Chuỗi hoặc oracle của bên thứ ba để cung cấp bằng chứng về hành vi gian lận hay không.
● Đảm bảo rằng logic xử phạt không chứa các đặc quyền tập trung (chẳng hạn như quản trị viên có thể tùy ý tịch thu tiền đã thế chấp), và các điều kiện kích hoạt hình phạt được thực thi tự động bởi hợp đồng thông minh.
● Kiểm tra giai đoạn lock-up và các điều kiện rút gửi để ngăn chặn các đại lý rút tiền gấp trước khi phải chịu phạt hoặc tịch thu.
3. Xác thực sổ đăng ký.
Các điểm kết nối thông dụng để yêu cầu và ghi nhật ký các kiểm tra xác thực độc lập (ví dụ: trình xác thực zkML, oracle TEE, đánh giá độ 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ư chuyển khoản số tiền lớn), chỉ lịch sử thôi là không đủ. Các hệ thống đăng ký xác minh cho phép các tác nhân gửi kết quả để bên thứ ba hoặc hệ thống tự động xác minh, những hệ thống này có thể sử dụng các cơ chế như thực thi lại suy luận an toàn khi đặt cược, trình xác thực 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 crypto, dựa trên thiết kế bảo mật dựa trên lý thuyết trò chơi. Các tác nhân phải đặt cọc một lượng Token gốc hoặc stablecoin nhất định vào một hệ thống đăng ký. Nếu một tác nhân không hoàn thành nghĩa vụ hoặc cung cấp kết quả không chính xác, mạng lưới xác thực 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 số tiền đã đặt cọc. Mô hình này phù hợp với nhiệm vụ kết quả dễ dàng xác minh 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 các dịch vụ API đơn giản.
Mô hình thứ hai là xác minh mật mã, một thiết kế bảo mật dựa trên các nguyên tắc toán học. Xác thực TEE (Trusted Execution Environment) cho phép tác nhân chạy trong một hoàn cảnh phần cứng được bảo mật và tăng cường, chẳng hạn như Intel SGX hoặc AWS Nitro. Hệ thống đăng ký xác minh có thể lưu trữ và xác minh báo cáo xác thực từ xa từ phần cứng, chứng minh rằng mã mà tác nhân đang chạy thực sự là một phiên bản xác thực, không bị thay đổi của mã cụ thể đó.
zkML (Zero-Knowledge Machine Learning) là một phương pháp xác minh mật mã khác. Tác nhân gửi Bằng chứng không tri thức cùng với kết quả suy luận. Bằng chứng này có thể được xác minh bởi hợp đồng xác minh Chuỗi với chi phí cực thấp, đảm bảo về mặt toán học 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 các đầu vào cụ thể. Điều này ngăn chặn các cuộc tấn công "thay thế mô hình", trong đó các nhà cung cấp dịch vụ tuyên bố sử dụng các mô hình cao cấp nhưng thực tế lại sử dụng các 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 crypto, cần kiểm tra những điều sau:
● Kiểm tra thời gian nộp bằng chứng gian lận: Người xác minh có đủ thời gian để phát hiện và nộp bằng chứng không? Thời gian quá ngắn có thể bỏ sót hành vi gian lận, trong khi thời gian quá dài sẽ dẫn đến việc tiền bị khóa trong thời gian dài.
● Logic xét xử để xác minh bằng chứng gian lận: Liệu nó có dựa trên một tập hợp các trình xác thực đa chữ ký? Nếu vậy, cần phải xem xét mức độ phi tập trung và cài đặt ngưỡng của các trình xác thực được chọn; nếu việc xét xử hoàn toàn diễn ra Chuỗi, cần phải đảm bảo rằng cơ sở cho việc xét xử (chẳng hạn như kết quả có thể kiểm chứng Chuỗi) tồn tại và không gây hiểu nhầm.
● Đảm bảo số tiền thế chấp tương xứng với rủi ro để ngăn chặn các hành vi bất chính có chi phí thấp (chẳng hạn như thế chấp không đủ, trong đó lợi nhuận từ hành vi sai trái vượt xa tổn thất).
Nếu là chứng nhận TEE, cần kiểm tra những điều sau:
● Kiểm tra xem hợp đồng có xác minh tính hợp lệ của bằng chứng TEE (ví dụ: bao gồm dấu thời gian hoặc Block Height) hay không để tránh việc chấp nhận các bằng chứng đã hết hạn.
● Xác minh xem nội dung bằng chứng có bao gồm mã băm của máy chủ proxy và mã băm đầu vào/đầu ra hay không để đảm bảo bằng chứng được gắn với một nhiệm vụ cụ thể và tránh việc sử dụng lại giữa nhiệm vụ khác nhau.
● Đánh giá xem logic xác minh của bằng chứng TEE có dựa vào một oracle bên ngoài (chẳng hạn như Intel IAS) hay không. Nếu có, kiểm toán tính bảo mật và phi tập trung của oracle .
Nếu đó là quá trình xác thực zkML, cần kiểm tra những điều sau:
● Xác minh rằng hợp đồng tích hợp thư viện xác minh zk kiểm toán(chẳng hạn như SnarkVerifier) và cấu hình chính xác khóa xác minh cho hệ thống chứng minh cụ thể (chẳng hạn như Groth16, PLONK).
● Kiểm tra xem hợp đồng xác minh có giới hạn mô hình áp dụng và phạm vi đầu vào của bằng chứng để ngăn chặn các cuộc tấn công thay thế mô hình hay không (ví dụ: bằng chứng được tạo ra cho một mô hình nhỏ, nhưng lại tuyên bố là kết quả đầu ra của một mô hình lớn).
● Đánh giá mức độ phi tập trung trong việc tạo bằng chứng: Liệu nó có phụ thuộc vào một người chứng minh duy nhất? Nếu có nhiều người chứng minh, cần phải thiết kế một cơ chế đồng thuận để ngăn chặn những người chứng minh có ý đồ xấu.
Phần kết luận
ERC-8004 cung cấp một tiêu chuẩn để thiết lập niềm tin vào các tác nhân AI, và tính bảo mật của nó rất quan trọng đối với toàn bộ hệ sinh thái tác nhân Chuỗi. Kiểm toán bảo mật đòi hỏi sự hiểu biết sâu sắc về mục đích thiết kế và rủi ro tiềm ẩn của ba hệ thống đăng ký. Hơn nữa, sự phức tạp của các tương tác giữa các hợp đồng và các lỗ hổng phổ biến không thể bị bỏ qua. Một kiểm toán toàn diện và nghiêm ngặt là cần thiết để đảm bảo rằng ERC-8004 thực sự đáp ứng được lời hứa về "sự không cần tin tưởng", đặt nền tảng an toàn cho tương lai của các tác nhân tự động.
