
Cách hoạt động của ERC-8004: danh tính và uy tín cho đại lý
Cách các sổ đăng ký ERC-8004 hoạt động là một quy trình ba sổ cái: một AgentID ERC-721 chỉ đến một tệp đăng ký ngoài chuỗi, trong khi các sổ đăng ký Danh tiếng và Xác thực riêng biệt ghi lại các tín hiệu tin cậy từ 0 đến 100 cùng với các điểm chứng minh.
Thiết kế không đưa "sự thật của đại lý" lên chuỗi, mà chuẩn hóa nơi để tìm (danh tính), ai có thể phát ngôn (danh tiếng được ủy quyền), và cách định giá sự đảm bảo (xác thực) cho danh tính đại lý 8004.
Điểm chính
- ERC-8004 định nghĩa ba sổ đăng ký trên chuỗi nhẹ: Danh tính, Danh tiếng và Xác thực.
- Đăng ký Danh tính sử dụng một AgentID ERC-721 có tokenURI trỏ đến một tệp đăng ký đại lý ngoài chuỗi liệt kê các điểm cuối và định danh như A2A, MCP, ENS và địa chỉ ví.
- Sổ đăng ký Danh tiếng ghi lại các tín hiệu phản hồi di động từ 0 đến 100 với các thẻ tùy chọn và ngoài chuỗi.liên kết, và một hướng dẫn dành cho nhà phát triển mô tả một cổng feedbackAuth được ký bởi tác nhân để giảm thiểu spam tùy ý.
- Sổ đăng ký xác thực ghi lại các cuộc gọi validationRequest và 0–100 phản hồi của các validator, cho phép các ứng dụng hoán đổi trong staking, zkML proofs hoặc TEE.chứng thựcmà không thay đổi việc khám phá.
Các sổ đăng ký ERC-8004 và mục đích của chúng
Các sổ đăng ký ERC-8004 là hợp đồng thông minh lưu trữ các bản ghi tiêu chuẩn hóa và phát ra sự kiện để các ứng dụng khác có thể tra cứu danh tính đại lý và tín hiệu tin cậy mà không cần thương lượng các sơ đồ tùy chỉnh.
Di chuyển cốt lõi của tiêu chuẩn là phân chia "niềm tin" thành ba bề mặt khác nhau: một sổ đăng ký danh tính để khám phá, một sổ đăng ký danh tiếng để phản hồi của người dùng, và một sổ đăng ký xác thực cho các kiểm tra bên thứ ba. Sự phân tách đó là lý do tại sao các sổ đăng ký erc 8004 vẫn nhẹ trên chuỗi trong khi vẫn có thể kết hợp giữa các ứng dụng.
Mô hình tư duy hữu ích là một hồ sơ tín dụng trên chuỗi cho các đại lý tự trị. Sổ đăng ký danh tính là số tài khoản và thông tin định tuyến, không phải điểm tín dụng. Danh tiếng và Xác thực là hai sổ cái khác nhau của các tín hiệu gọn gàng từ 0–100, mỗi cái được phép mang theo thẻ và chỉ dẫn đến bằng chứng ngoài chuỗi.
Đây là mẫu sổ đăng ký xác thực danh tiếng danh tính: giữ chuỗi như là chỉ mục chính và điểm neo toàn vẹn, và giữ các chi tiết lộn xộn ngoài chuỗi.
ERC-8004 được mô tả như một Đề xuất Cải tiến Ethereum ở trạng thái Dự thảo và đang trải qua quá trình xem xét đồng nghiệp. Hướng dẫn chính liệt kê ngày tạo là 13 tháng 8 năm 2025 và tên các đồng tác giả Marco De Rossi (MetaMask), Davide Crapis (Quỹ Ethereum), Jordan Ellis (Google), và Erik Reppel (Coinbase).
Tư thế dự thảo đó quan trọng vì các giao diện được dự kiến sẽ đủ ổn định cho việc thử nghiệm, nhưng các nhà xây dựng nên mong đợi các chi tiết ở cấp độ thực địa sẽ phát triển.
Chủ đề rộng hơn là danh tính của tác nhân, và luận điểm của ERC-8004 được thiết kế hẹp: nó không tuyên bố chứng minh khả năng của một tác nhân trên chuỗi. Nó chuẩn hóa nơi những tuyên bố đó tồn tại (đăng ký tokenURI), cách phản hồi được đăng theo cách khó bị spam (ủy quyền), và cách đảm bảo độc lập có thể được mua khi rủi ro tăng lên (xác thực).
Cách thức hoạt động của sổ đăng ký danh tính
Vòng đời của Sổ Đăng Ký Danh Tính ngắn trên chuỗi và dài ngoài chuỗi. Trên chuỗi, cơ chế là một ERC-721 với lưu trữ URI: đúc một token AgentID duy nhất, thiết lập tokenURI của nó, và dựa vào chuẩn hóaNFTchỉ mục và sự kiện để phát hiện. Ngoài chuỗi, tokenURI giải quyết thành một tệp đăng ký tác nhân hoạt động như một tài liệu cấu hình sống cho cách tiếp cận và diễn giải tác nhân.
Một quy trình cụ thể trông như thế này:
1. Một nhà điều hành tác nhân đúc một ERC-721 AgentID trong sổ đăng ký danh tính và thiết lập tokenURI. 2. Các chỉ mục và ứng dụng theo dõi sự kiện trong sổ đăng ký và liệt kê các AgentID theo cách tương tự như họ sẽ liệt kê các NFT. 3. Ứng dụng lấy tokenURI và đọc tệp đăng ký tác nhân ngoài chuỗi để tìm hiểu các điểm cuối và định danh.
Nguồn chính mô tả tệp đăng ký đó chứa các điểm cuối và định danh như A2A, MCP, ENS, và địa chỉ ví. Đó là tải trọng hoạt động. Nếu một ứng dụng đang cố gắng định tuyến một nhiệm vụ đến một tác nhân, sổ đăng ký danh tính cung cấp cho nó con trỏ chính xác đến gói "nơi để nói chuyện với tôi" và "những tay cầm tôi tuyên bố" của tác nhân.
Đây cũng là nơi mà hầu hết các tích hợp bị bất ngờ. Token ERC-721 không cho một ứng dụng biết liệu tệp đăng ký ngoài chuỗi đã thay đổi một cách âm thầm, liệu một điểm cuối đã không còn hoạt động, hay liệu một tên ENS đã được chuyển hướng. Đối xử với nội dung tokenURI như cấu hình sản xuất là tư thế đúng: phiên bản nó, gắn nó vào lưu trữ theo địa chỉ nội dung khi có thể, và cảnh báo về các thay đổi. Phần trên chuỗi cố tình nhàm chán, và đó là điểm chính.
Các đối tượng cần thiết xuất hiện ở đây một cách tự nhiên: sổ đăng ký danh tính là hợp đồng, AgentID là token ERC-721, và thẻ tác nhân là những gì nhiều giao diện người dùng sẽ hiển thị từ tokenURI cộng với bất kỳ tóm tắt xác thực và danh tiếng nào đã được lưu trữ.
Cách tín hiệu danh tiếng được ghi lại
Danh tiếng trong erc 8004 được thiết kế để có thể di chuyển nhưng không phải là không cần phép. Sổ đăng ký Danh tiếng cung cấp một giao diện tiêu chuẩn để đăng và truy xuất tín hiệu phản hồi, và nguồn chính định hình các tín hiệu đó dưới dạng điểm số từ 0 đến 100 với các thẻ tùy chọn và liên kết đến dữ liệu phản hồi chi tiết ngoài chuỗi. Chuỗi lưu trữ tín hiệu ngắn gọn. Liên kết ngoài chuỗi mang theo câu chuyện, biên lai và bất kỳ ngữ cảnh nào mà một ứng dụng muốn hiển thị cho con người.
Cơ chế chính giữ cho sổ đăng ký danh tiếng không trở thành một bức tường spam không thể giao dịch là sự ủy quyền. Một hướng dẫn dành cho nhà phát triển mô tả việc gửi danh tiếng yêu cầu ủy quyền do đại lý phát hành thông qua một phản hồi đã ký feedbackAuth. Ý tưởng rất đơn giản: đại lý ủy quyền trước cho một đối tác cụ thể để để lại phản hồi, vì vậy các địa chỉ ngẫu nhiên không thể phun ra các đánh giá tiêu cực quy mô mà không bao giờ tương tác.
Một chuỗi điển hình là:
1. Đại lý chấp nhận một nhiệm vụ và phát hành một ủy quyền phản hồi cho khách hàng. 2. Khách hàng gửi phản hồi đến sổ đăng ký danh tiếng với điểm số (0–100), thẻ tùy chọn, URI ngoài chuỗi tùy chọn và băm, cùng với feedbackAuth. 3. Các ứng dụng và tổng hợp đọc các sự kiện phản hồi trên chuỗi và tính toán các tóm tắt của riêng họ, trong khi chỉ lấy chi tiết ngoài chuỗi khi cần thiết.
Hướng dẫn chính cũng chỉ ra một vé vào cửa sạch hơn cho các đánh giá "sử dụng thực tế": chứng minh thanh toán x402. Nó tham chiếu rõ ràng đến mã trạng thái HTTP "402 Yêu cầu Thanh toán" như một phần của khung x402, và mô tả việc sử dụng chứng minh thanh toán để chỉ những khách hàng trả tiền mới có thể để lại đánh giá.
Đó là một cấu trúc chặt chẽ: cổng thanh toán có thể nói, sổ đăng ký lưu trữ tín hiệu tối thiểu từ 0 đến 100, và liên kết chứng cứ có thể giữ biên lai.
Tất cả những điều này không loại bỏ hành vi Sybil. Nguồn chính thừa nhận rằng việc ủy quyền trước chỉ giảm thiểu một phần spam và rằng các cuộc tấn công Sybil vẫn có thể xảy ra, đó là lý do tại sao nhiều triển khai vẫn sẽ cân nhắc các nhà đánh giá, duy trì danh tiếng của nhà đánh giá hoặc áp đặt chi phí kinh tế ở nơi khác.
Cách yêu cầu và phản hồi xác thực hoạt động
Xác thực là sổ đăng ký nơi các ứng dụng giảm thiểu rủi ro. Sổ đăng ký Xác thực hỗ trợ yêu cầu và ghi lại các kiểm tra độc lập của người xác thực, và nguồn chính mô tả một hàm validationRequest cộng với các phản hồi của người xác thực được chấm điểm từ 0 đến 100. Phạm vi từ 0 đến 100 đó được thiết kế linh hoạt: một ứng dụng có thể coi đó là đỗ hoặc trượt, hoặc như một quang phổ nơi các người xác thực khác nhau có ngưỡng khác nhau.
Luồng là một mẫu yêu cầu-phản hồi:
1. Một đại lý hoặc người tiêu dùng gọi validationRequest để yêu cầu một người xác thực kiểm tra một số yêu cầu hoặc đầu ra. 2. Một người xác thực thực hiện kiểm tra của mình bằng bất kỳ công nghệ đảm bảo nào mà họ hỗ trợ. 3. Người xác thực gửi lại một phản hồi với điểm số từ 0 đến 100 và có thể đính kèm bằng chứng ngoài chuỗi thông qua URIs và hashes.
Lựa chọn thiết kế quan trọng là danh bạ không mã hóa cứng một phương pháp xác minh duy nhất. Các nguồn thảo luận về nhiều cơ chế, bao gồm staking kinh tế tiền điện tử, chứng minh zkML và TEE.các oraclehoặc chứng thực. Nhiều triển khai có thể xác minh chứng thực ngoài chuỗi và sau đó đăng kết quả lên chuỗi, giữ cho chuỗi là lớp thanh toán cho “những gì đã được yêu cầu” và “ai đã nói điều đó.”
Đây là nơi luận án xuất hiện trên màn hình: ERC-8004 không biến lòng tin thành một huy hiệu nhị phân. Nó chuẩn hóa cách một người tiêu dùng khám phá đại lý, sau đó cho phép người tiêu dùng điều chỉnh mức độ đảm bảo với rủi ro. Định tuyến rủi ro thấp có thể dựa vào tín hiệu danh tiếng. Các hành động rủi ro trung bình có thể yêu cầu xác thực có hỗ trợ stake.
Các hành động rủi ro cao có thể yêu cầu xác minh mật mã như chứng thực TEE hoặc chứng minh zkML, với danh bạ hoạt động như nơi chính thức để tìm các phản hồi mới nhất.
Kết hợp các danh bạ một cách an toàn.
Một sự tích hợp an toàn kết hợp ba danh bạ thành một quyết định tin cậy theo tầng thay vì trung bình mọi thứ thành một “điểm tin cậy” duy nhất. Danh tính là lớp tra cứu, danh tiếng là lịch sử di động của các bên đối tác nói về kết quả, và xác thực là một sự mua sắm rõ ràng của sự đảm bảo cho một yêu cầu cụ thể. Đối xử với chúng như những con số có thể hoán đổi là cách mà các ứng dụng cuối cùng tin tưởng vào điều sai.
Một mô hình cổng thực tiễn ánh xạ rõ ràng đến các mô hình tin cậy được mô tả trong hướng dẫn chính:
1. Rủi ro thấp: sử dụng danh tính cộng với danh tiếng để khám phá và định tuyến. Ứng dụng đọc tokenURI, kiểm tra các trường thẻ đại lý mà nó quan tâm, và sử dụng tín hiệu danh tiếng như một bộ lọc. 2. Rủi ro trung bình: yêu cầu xác thực kinh tế tiền điện tử. Ứng dụng chỉ tiếp tục khi phản hồi của người xác thực đáp ứng ngưỡng của nó, và nó có thể ưu tiên các người xác thực đăng kết quả có hỗ trợ stake. 3. Rủi ro cao: yêu cầu xác minh mật mã.
Ứng dụng yêu cầu chứng thực TEE hoặc chứng minh zkML, với danh bạ xác thực lưu trữ phản hồi từ 0 đến 100 và các điểm chứng cứ.
Lưỡi sắc bén là sự trôi dạt ngoài chuỗi. tokenURI của danh bạ danh tính có thể chỉ đến một tệp đăng ký ngoài chuỗi thay đổi theo thời gian, và chuỗi sẽ không cảnh báo người tiêu dùng rằng các điểm cuối, định danh hoặc tùy chọn tin cậy được quảng cáo đã di chuyển. Phiên bản hóa và ghim tệp đó, cộng với việc theo dõi các thay đổi, không phải là tùy chọn nếu đại lý đang làm bất cứ điều gì liên quan đến quỹ hoặc dữ liệu nhạy cảm.
Tính bất biến cũng có hai mặt. Các ghi chú nguồn chính cho biết các con trỏ và băm trên chuỗi không thể bị xóa, điều này rất tốt chokiểm toáncác dấu vết và rất tồi tệ cho các sơ đồ lộn xộn. Thiết kế các định dạng đăng ký và phản hồi với việc thu hồi và thay thế trong tâm trí là quan trọng vì hệ sinh thái sẽ tích lũy các dấu vết vĩnh viễn.
Đây cũng là nơi đúng để sửa chữa những hiểu lầm phổ biến. ERC-8004 không đặt khả năng của đại lý lên chuỗi. Nó lưu trữ ID, điểm số và con trỏ. Một điểm số danh tiếng đơn lẻ không bằng lòng tin vì Danh tiếng và Xác thực là các sổ cái khác nhau dành cho các cấp độ rủi ro khác nhau. Ủy quyền như feedbackAuth giảm spam tùy ý, nhưng nó không tự mình giải quyết các cuộc tấn công Sybil.
Đó là hình dạng thực tế của erc 8004 và cách nó hoạt động khi một ứng dụng cố gắng đưa ra quyết định với vốn có nguy cơ, và đó là lý do tại sao danh tính đại lý 8004 được coi là một đường ống mà bạn có thể điều chỉnh.
Quan điểm
Tôi đã thấy các nhóm xây dựng bảng điều khiển “độ tin cậy của đại lý” mà gom tất cả vào một con số, rồi tỏ ra ngạc nhiên khi con số đó không đáp ứng được họ. Sai lầm tốn kém là trung bình Danh tiếng và Xác thực như thể chúng là cùng mộttài sản.Chúng không phải. Danh tiếng là lịch sử của các bên đối tác được ủy quyền nói.
Xác thực là một sản phẩm bảo đảm có giá gắn liền với một yêu cầu cụ thể, với công nghệ bảo đảm khác nhau từ staking đến zkML đến các chứng thực TEE.
Nếu một tích hợp sẽ bị hỏng, nó thường bị hỏng ở đường nối nhàm chán: tokenURI trỏ đến một tệp đăng ký ngoài chuỗi, và tệp đó bị trôi. ERC-721 AgentID vẫn giữ nguyên, giao diện người dùng vẫn hiển thị cùng một thẻ đại lý, và các điểm cuối hoặc định danh lặng lẽ thay đổi bên dưới. Đó là lý do tại sao lớp danh tính trong ERC-8004 cố ý đơn giản. Công việc là theo dõi những gì nó trỏ đến, và điều chỉnh xác thực lên khi cấp độ rủi ro yêu cầu.
Nguồn
Frequently Asked Questions
ERC-8004 có phải là một tiêu chuẩn token ERC-721 hay một tiêu chuẩn đăng ký không?
ERC-8004 được mô tả như một Đề xuất Cải tiến Ethereum thiết lập ba đăng ký cho Danh tính, Danh tiếng và Xác thực. Nó sử dụng ERC-721 làm nền tảng cho danh tính đại lý (AgentID), nhưng giá trị cốt lõi của tiêu chuẩn là các giao diện đăng ký cho việc khám phá và tín hiệu tin cậy.
Dữ liệu nào được lưu trữ trên chuỗi so với ngoài chuỗi trong các đăng ký ERC-8004?
Dữ liệu trên chuỗi được cố ý giữ ở mức tối thiểu: token AgentID và con trỏ tokenURI, cộng với 0–100 điểm danh tiếng và xác thực với các thẻ tùy chọn và con trỏ bằng chứng. Chi tiết phong phú được lưu trữ ngoài chuỗi trong tệp đăng ký đại lý và trong các tài liệu phản hồi hoặc xác nhận liên kết được tham chiếu bởi URIs và hashes.
feedbackAuth trong Đăng ký Danh tiếng ERC-8004 là gì?
Một hướng dẫn cho nhà phát triển mô tả feedbackAuth như một ủy quyền đã ký do đại lý phát hành cần thiết để gửi phản hồi. Mục tiêu là hạn chế ai có thể đăng tín hiệu danh tiếng và giảm spam tùy ý, trong khi vẫn giữ cho danh tiếng có thể chuyển nhượng giữa các ứng dụng.
x402 liên quan như thế nào đến danh tiếng ERC-8004?
Hướng dẫn chính mô tả việc sử dụng các bằng chứng thanh toán x402 để chỉ những khách hàng đã thanh toán mới có thể để lại đánh giá, tham chiếu đến mã trạng thái HTTP "402 Payment Required". Thanh toán trở thành vé vào cửa, trong khi đăng ký chỉ ghi lại tín hiệu 0–100 gọn gàng và liên kết đến bằng chứng ngoài chuỗi.
ERC-8004 có thể hỗ trợ những loại xác thực nào?
Đăng ký Xác thực ghi lại các yêu cầu xác thực và phản hồi của người xác thực từ 0–100, và các nguồn thảo luận về nhiều cơ chế khác nhau. Các ví dụ bao gồm staking kinh tế tiền điện tử, bằng chứng zkML, và các oracle hoặc xác nhận TEE, với bằng chứng thường được giữ ngoài chuỗi và được tham chiếu từ các bản ghi trên chuỗi.