Tác giả: Tiểu Bạch
Bài viết này là bài viết gốc của tác giả, quan điểm chỉ đại diện cho sự hiểu biết cá nhân của tác giả, ETHPanda đã biên tập chỉnh sửa nội dung.
Sau khi AI Agent lên chuỗi, vấn đề không còn chỉ là "nó có thể trò chuyện hay không" nữa.
Nó có thể ký tên, nhận tiền, khởi tạo giao dịch, triển khai hợp đồng, quản lý ví, gọi API, thậm chí hợp tác với các agent khác để hoàn thành nhiệm vụ. Lúc này, điều người dùng thực sự quan tâm không phải là nó có một cái tên hay hay không, mà là:
Agent này cuối cùng có đáng tin cậy hay không?
Ví của nó có sạch sẽ không? Hợp đồng mà nó liên kết có thực sự tồn tại không? Website và API của nó có rủi ro không? Nội dung truyền thông mà nó phát hành có phải là giả mạo không? Mã Solidity của nó có lỗ hổng rõ ràng không? Nó đã từng bị tấn công chưa?
ERC-8126 nhắm đến chính là loại vấn đề xác minh này.
Nói đơn giản, ERC-8126 là tầng xác minh cho AI Agent. Nó được xây dựng trên nền tảng agent registration (đăng ký danh tính) của ERC-8004, cho phép các verification provider độc lập thực hiện xác minh nhiều lớp xung quanh một danh tính agent duy nhất, và biến kết quả thành các tín hiệu rủi ro mà ví, thị trường, ứng dụng và các agent khác đều có thể sử dụng.
Nó không nhằm chứng minh một agent nào đó sẽ mãi mãi đáng tin, mà là tiêu chuẩn hóa "làm thế nào để xác minh một agent, kết quả xác minh nên được biểu đạt thế nào, các hệ thống khác nên đọc các kết quả này ra sao".
Có danh tính, không bằng có thể tin cậy
ERC-8004 giải quyết vấn đề danh tính của agent.
Bạn có thể hiểu nó như thế này: trước hết, để AI Agent có một danh tính trên chuỗi có thể đăng ký, có thể phát hiện, có thể lập chỉ mục. Danh tính này sẽ tương ứng với một agentId, và thông qua metadata mô tả tên, ví, endpoint, website, địa chỉ hợp đồng... của agent này.
Nhưng bản thân danh tính không bằng sự tin cậy.
Một agent độc hại cũng có thể đăng ký danh tính. Một agent lừa đảo cũng có thể viết một metadata thật đẹp. Một agent hôm nay bình thường, không đại diện cho ngày mai endpoint của nó sẽ không bị chiếm đoạt. Một agent có avatar, có website chính thức, có địa chỉ ví, cũng không có nghĩa là hợp đồng của nó an toàn, ví sạch sẽ, nội dung chân thực.
Vì vậy, ERC-8004 giống như đang trả lời:
Agent này là ai?
ERC-8126 tiếp tục hỏi:
Agent này có đáng để tương tác không?
ERC-8126 xác minh như thế nào?
Đầu tiên, yêu cầu xác minh sẽ tham chiếu đến agentId trong ERC-8004 Identity Registry. Sau đó, verification provider thông qua agentId này đọc metadata tương ứng, và phân tích thông tin về ví, hợp đồng, website, endpoint, nội dung truyền thông... từ đó, cuối cùng tạo ra điểm số rủi ro và bằng chứng xác minh.
Quy trình này có thể chia thành bốn bước:
- AI Agent trước tiên đăng ký danh tính thông qua ERC-8004.
- ERC-8126 provider đọc agentId và metadata của agent này.
- Provider thực hiện xác minh nhiều lớp đối với agent.
- Kết quả xác minh được tiêu thụ bởi ví, thị trường, dApp hoặc các agent khác dưới dạng risk score, proof, attestation.
Trọng tâm ở đây là: ERC-8126 không giới thiệu một "cơ quan chứng nhận chính thức" duy nhất.
Nó giống một thị trường verification provider mở hơn. Các provider khác nhau có thể sử dụng phương pháp riêng để kiểm tra an toàn, nhưng kết quả đầu ra phải được biểu đạt theo định dạng tiêu chuẩn hóa. Như vậy, ví, agent marketplace, thị trường nhiệm vụ và các ứng dụng khác mới có thể đọc các tín hiệu này xuyên nền tảng.
Điều này tiến xa hơn một bước so với "bên phát hành dự án tự nói mình an toàn": nó chia nhỏ phán đoán tin cậy thành các tín hiệu có thể được kiểm tra, ghi lại và đọc bởi bên thứ ba.
Năm lớp xác minh: chia nhỏ agent để nhìn
ERC-8126 chủ yếu định nghĩa năm loại xác minh, lần lượt bao phủ một số mặt dễ gặp vấn đề nhất sau khi agent lên chuỗi: hợp đồng, truyền thông, mã nguồn, website và ví. Nó tiêu chuẩn hóa loại xác minh, biểu đạt kết quả và giao diện có thể tiêu thụ, chứ không phải biến mỗi phương pháp kiểm tra an toàn thành một phương pháp kiểm toán chính thức duy nhất. Các verification provider khác nhau vẫn có thể sử dụng quy trình phát hiện và mô hình rủi ro riêng của mình.
ETV: Token / Contract Verification
ETV kiểm tra token hoặc hợp đồng liên kết với agent.
Nếu trong metadata của agent có ghi một contractAddress, provider sẽ kiểm tra xem địa chỉ này trên chuỗi tương ứng có thực sự có mã hợp đồng không, có tồn tại rủi ro rõ ràng không, có phải chỉ là địa chỉ giả được điền bừa vào không.
Đối với người dùng, ETV trả lời:
Tài sản hoặc hợp đồng trên chuỗi mà agent này tuyên bố liên kết, cuối cùng có thật hay không?
Bởi vì một khi agent bắt đầu nhận tiền, phát hành token, staking, thực hiện chiến lược, hợp đồng đằng sau không còn là đồ trang trí nữa, mà là nơi tiền của người dùng thực sự sẽ tiếp xúc.
MCV: Media Content Verification
MCV kiểm tra nội dung truyền thông mà agent sử dụng, chẳng hạn như avatar, hình ảnh, tài liệu thương hiệu, hình ảnh chứng minh, v.v.
Điều này nghe có vẻ không phải là vấn đề cốt lõi, nhưng rất quan trọng trong bối cảnh AI Agent. Một agent giả mạo có thể mạo nhận logo dự án, làm giả ảnh chụp màn hình chính thức, thậm chí sử dụng hình ảnh được tạo bởi AI để tạo cảm giác được chứng thực.
MCV cần kiểm tra nguồn gốc nội dung, tính toàn vẹn, dấu vết bị sửa đổi, watermark, chữ ký, v.v.
Nó trả lời:
Nội dung mà agent này hiển thị cho người dùng xem, có bị giả mạo hoặc sửa đổi không?
SCV: Solidity Code Verification
SCV kiểm tra mã Solidity hoặc an toàn hợp đồng liên kết với agent.
Nếu metadata bao gồm thông tin mã nguồn hoặc hợp đồng liên quan, provider có thể kiểm tra các rủi ro phổ biến, chẳng hạn như reentrancy, vấn đề quyền hạn, lời gọi nguy hiểm, attack surface cho flash loan, v.v.
SCV có thể giảm một số rủi ro hợp đồng thông thường, nhưng nó không tương đương với kiểm toán thủ công hoàn chỉnh.
Nó giống như một lối vào kiểm tra an toàn hợp đồng được tiêu chuẩn hóa. Thông qua SCV, không có nghĩa là hợp đồng hoàn toàn an toàn; nó nói lên rằng, mã nguồn hoặc hợp đồng của agent này đã trải qua kiểm tra của một provider nào đó, và tạo ra tín hiệu rủi ro có thể tiêu thụ.
WAV: Web Application Verification
WAV kiểm tra website, API và endpoint của agent.
Nhiều agent tuy có danh tính trên chuỗi, nhưng lối vào tương tác thực sự vẫn nằm ngoài chuỗi, chẳng hạn như website chính thức, API, MCP server, A2A endpoint hoặc dashboard.
Một khi những nơi này gặp sự cố, rủi ro có thể không nhỏ hơn hợp đồng. Chứng chỉ website hết hạn, người dùng có thể bị tấn công trung gian; API bị chiếm đoạt, agent có thể thực hiện lệnh sai; frontend bị tiêm mã độc, người dùng có thể ký giao dịch nguy hiểm.
WAV trả lời:
Lối vào Web và endpoint dịch vụ của agent này có an toàn không?
WV: Wallet Verification
WV kiểm tra rủi ro ví của agent.
Nó sẽ xem ví này có lịch sử giao dịch không, có phải là vỏ trống mới tạo không, có liên quan đến địa chỉ rủi ro cao, địa chỉ lừa đảo, địa chỉ của kẻ tấn công hoặc các đối tượng khác trong cơ sở dữ liệu threat intelligence không.
WV trả lời:
Hồ sơ hành vi trên chuỗi của agent này có sạch sẽ không?
Điểm rủi ro thống nhất: để ví và ứng dụng thực sự sử dụng được
ERC-8126 sẽ chuyển đổi kết quả xác minh thành điểm rủi ro từ 0 đến 100.
Điểm càng thấp, rủi ro càng thấp; điểm càng cao, rủi ro càng cao.
- 0-20: Rủi ro thấp
- 21-40: Rủi ro trung bình
- 41-60: Rủi ro tăng
- 61-80: Rủi ro cao
- 81-100: Rủi ro nghiêm trọng
Ý nghĩa sản phẩm của thiết kế này rất trực tiếp.
Ví không thể yêu cầu người dùng thông thường mỗi lần đọc một báo cáo an toàn hoàn chỉnh. Marketplace cũng không phù hợp chỉ dựa vào tự thuật của bên phát hành dự án để sắp xếp. Một risk score thống nhất có thể trở thành đầu vào cho chiến lược sản phẩm.
Ví dụ:
- Điểm rủi ro quá cao, ví có thể cảnh báo hoặc ngăn chặn tương tác.
- Không có kết quả xác minh, marketplace có thể giảm trọng số hiển thị.
- Rủi ro ví bất thường, thị trường nhiệm vụ có thể hạn chế nhận đơn.
- Web endpoint rủi ro cao, frontend có thể nhắc người dùng thận trọng khi truy cập.
Tuy nhiên, một tổng điểm không thể đại diện cho toàn bộ tình hình.
Rủi ro hợp đồng, rủi ro ví, rủi ro website, rủi ro truyền thông, vốn dĩ là các loại rủi ro khác nhau. Thiết kế sản phẩm tốt hơn là đồng thời hiển thị tổng điểm và điểm thành phần, để người dùng biết vấn đề cụ thể nằm ở đâu.
PDV và ZKP: Chứng minh đã vượt qua xác minh, không đồng nghĩa với việc công khai tất cả chi tiết
Xác minh agent sẽ liên quan đến nhiều thông tin nhạy cảm.
Chẳng hạn như mã nguồn, cấu hình cơ sở hạ tầng, báo cáo an toàn, nhật ký riêng tư, hồ sơ ví, v.v. Nếu công khai tất cả, ngược lại có thể mở rộng attack surface.
Vì vậy, ERC-8126 giới thiệu PDV và ZKP.
PDV là Private Data Verification, ZKP là Zero-Knowledge Proof. Tác dụng của chúng là: để agent có thể chứng minh mình đã vượt qua một xác minh nào đó, nhưng không cần công khai toàn bộ chi tiết cơ sở.
Có thể hiểu nó như sau:
Thế giới bên ngoài thấy là "đã vượt qua xác minh, điểm rủi ro là bao nhiêu, proof ở đâu", chứ không phải là toàn bộ tài liệu an toàn nội bộ.
Điều này khiến ERC-8126 giống một bản tóm tắt due diligence có thể xác minh hơn, chứ không phải trải ra toàn bộ dữ liệu cho toàn mạng xem.
ERC-8004 / ERC-8126 / ERC-8183: Danh tính, xác minh, giao dịch
Nếu chia kinh tế AI Agent thành ba tầng, có thể hiểu như thế này. Ở đây cần nói rõ trạng thái: ERC-8126 đã vào trạng thái Final, trong khi ERC-8004 và ERC-8183 vẫn ở giai đoạn Draft, vì vậy ba thứ này phù hợp hơn để được hiểu là một hướng cơ sở hạ tầng đang hình thành, chứ không phải là một chồng giao thức đã hoàn toàn định hình.
- ERC-8004: Identity cho phép agent có danh tính, có thể đăng ký, có thể phát hiện.
- ERC-8126: Verification cho phép tín hiệu an toàn và rủi ro của agent có thể xác minh, có thể tiêu thụ.
- ERC-8183: Commerce cho phép agent có thể nhận nhiệm vụ, gửi kết quả, đi vào quy trình ký quỹ và thanh toán.
Nói thẳng ra hơn:
- ERC-8004 trả lời: Bạn là ai?
- ERC-8126 trả lời: Bạn có đáng tin không?
- ERC-8183 trả lời: Bạn có thể làm việc, nhận tiền, thanh toán không?
Ba thứ này đặt cùng nhau, thể hiện một câu chuyện khá rõ ràng về agent economy:
Trước tiên có danh tính, sau đó có xác minh, cuối cùng mới dễ dàng đi vào giao dịch và thanh toán hơn.
Có thể nói kỹ hơn một chút về mối quan hệ này. ERC-8126 thực sự được xây dựng trên nền tảng ERC-8004; ERC-8183 và ERC-8126 giống như bổ sung tự nhiên cho nhau hơn là mối quan hệ ràng buộc chặt chẽ.
Nói cách khác, các giao thức agent commerce như ERC-8183 có thể tiêu thụ tự nhiên tín hiệu xác minh của ERC-8126, chẳng hạn như kiểm tra điểm rủi ro của agent trước khi nhận nhiệm vụ, xác minh proof trước khi evaluator giải ngân. Nhưng điều này giống hướng kết hợp về mặt kỹ thuật hơn, không phải là sự phụ thuộc cứng của ERC-8183 vào ERC-8126.
Ý nghĩa đối với nhà phát triển là gì?
Nếu chỉ nhìn AI Agent từ góc độ câu chuyện thị trường, thảo luận rất dễ dừng lại ở token, launch, marketplace và sức nóng giao dịch. Nhưng đối với những người thực sự muốn làm sản phẩm agent, tích hợp ví, mạng lưới nhiệm vụ hoặc cơ sở hạ tầng giao thức, vấn đề then chốt hơn là: Khi một agent bắt đầu quản lý tài sản, gọi dịch vụ, gửi kết quả, hợp tác với các agent khác, ai sẽ gánh chịu chi phí tin cậy?
Trước đây, chi phí này chủ yếu bị ném cho người dùng. Người dùng tự đánh giá dự án có đáng tin không, tự xem hợp đồng có được kiểm toán không, tự kiểm tra ví có sạch không, tự nhận diện website chính thức có phải giả không, cuối cùng tự chịu hậu quả bị lừa hoặc tương tác thất bại.
Giá trị của ERC-8126 nằm ở chỗ, nó cố gắng chia nhỏ những phán đoán này thành các tín hiệu xác minh được tiêu chuẩn hóa, có thể kết hợp, có thể được sản phẩm đọc.
Nó sẽ không tiêu diệt rủi ro, cũng không thể đảm bảo một agent nào đó sẽ mãi mãi đáng tin. Nhưng nếu loại tín hiệu xác minh này được nhiều ví, marketplace, dApp và mạng lưới agent áp dụng hơn, nhiều quyết định sản phẩm có thể không còn chỉ dựa vào tự thuật của bên phát hành dự án.
Cụ thể:
Đối với ví, risk score có thể trở thành đầu vào cho kiểm soát rủi ro trước giao dịch và cảnh báo rủi ro.
Đối với agent marketplace, kết quả xác minh có thể ảnh hưởng đến thứ tự, lọc, trọng số hiển thị và nhãn rủi ro.
Đối với ứng dụng AI x ETH, nó có thể trở thành một kiểm tra an toàn trước khi agent được tích hợp.
Đối với sự hợp tác agent-to-agent, nó có thể giúp agent sàng lọc các đối tượng có rủi ro cao rõ ràng trước khi hợp tác.
Đây cũng là điểm đáng chú ý của ERC-8126: Nó không phải là một ERC khái niệm AI nữa, mà đang thử nghiệm đưa agent trên chuỗi từ "có thể đăng ký" tiến tới "có thể xác minh, có thể kiểm soát rủi ro".
Nó vẫn là một bộ tiêu chuẩn, chưa phải là mạng lưới đang chạy
Phần này có thể nhìn từ một góc độ khác.
ERC-8126 định nghĩa giao diện tiêu chuẩn và khuôn khổ xác minh. Nó nói rõ xác minh có thể làm như thế nào, kết quả có thể biểu đạt ra sao, nhưng không đồng nghĩa với việc hiện tại đã có một mạng xác minh công cộng trưởng thành, thống nhất xuyên ví, xuyên marketplace, xuyên chuỗi đang chạy.
Từ quy chuẩn hiện tại, nó đã làm rõ mấy điều:
- ERC-8126 định nghĩa quy trình tiêu chuẩn cho agent verification.
- Nó yêu cầu xác minh phải neo vào agentId của ERC-8004.
- Nó bao phủ năm loại rủi ro: token/hợp đồng, truyền thông, Solidity, Web, ví.
- Nó hỗ trợ điểm số rủi ro, proof và attestation.
- Nó cung cấp nền tảng cho ví, marketplace, dApp tiêu thụ tín hiệu xác minh.
Những khả năng này thực sự phát huy tác dụng, còn phụ thuộc vào việc sau này có bao nhiêu provider, ví, marketplace và ứng dụng sẵn sàng áp dụng. Nói cách khác, nó hiện chưa phải là trạng thái như dưới đây:
- Tất cả ví đều đã được tích hợp.
- Tất cả agent marketplace đều đã áp dụng.
- Tất cả provider đều đang sử dụng tiêu chuẩn tính điểm hoàn toàn nhất quán.
- Toàn ngành đã hình thành mạng lưới verification trưởng thành.
- ZKP và risk score đã hoàn toàn thống nhất trong môi trường production.
Nói cách khác:
ERC-8126 trước tiên tiêu chuẩn hóa ngôn ngữ xác minh cho AI Agent. Để nó trở thành lớp tin cậy công cộng, vẫn cần provider, ví, thị trường và ứng dụng tiếp tục tích hợp.
Kết luận
Sau khi AI Agent bước vào nền kinh tế trên chuỗi, danh tính chỉ là điểm khởi đầu, phía sau sẽ còn gặp một vấn đề thực tế hơn: nó có thể được xác minh hay không.
ERC-8004 cho phép agent có danh tính. ERC-8126 cho phép rủi ro đằng sau danh tính đó có thể được xác minh. ERC-8183 thì cho phép agent có cơ hội sử dụng các tín hiệu xác minh này trong các tình huống nhiệm vụ, ký quỹ và thanh toán.
Vì vậy, ý nghĩa của ERC-8126 không phải là trao cho agent một huy hiệu "mãi mãi đáng tin", mà là tiêu chuẩn hóa một vấn đề thực tế hơn:
Khi một AI Agent muốn bước vào quy trình ví, thị trường, mạng lưới nhiệm vụ và giao dịch trên chuỗi, chúng ta nên kiểm tra nó như thế nào? Kết quả kiểm tra nên được biểu đạt ra sao? Các hệ thống khác nên tiêu thụ những kết quả này như thế nào?
Có lẽ đây chính là lớp tin cậy mà nền kinh tế AI Agent tiếp theo cần bổ sung.
Tài liệu tham khảo
- ERC-8126: AI Agent Verification
- ERC-8126 Raw Markdown
- ERC-8004: Trustless Agents
- ERC-8183: Agentic Commerce
- Ethereum Magicians: ERC-8126 Discussion
- DonJohnson X Thread: Introducing ERC-8126
- Cybercentry Web3 Security & Verification Services
- ERC-8126 Scan







