本文讨论了如何用 ERC-8004 重构 Codatta DID、Reputation 与数据生产体系。

撰文：Jason，VP of Engineering at Codatta

重生之我在 ERC-8004 当王爷

重生，穿越，霸总作为近些年的爆款题材，简直让人欲罢不能。读得太多了，一般的粗粮已经吃不下了，想更过把瘾，只能自己来发挥了。创作这么一篇糅合这些元素的集大成者爽文，想想都很刺激。名字我都想好了，就叫做《Codatta，重生之我在 ERC-8004 当王爷》。

不好意思，部分观众可能会失望了 — —

稍微有那么一点点偏差。

主角嘛，不是什么俊男靓女。

不装了，我摊牌了，这次是 Codatta 和 ERC-8004。

主线嘛，就是关于如何用一具崭新的身体，装下一颗成熟的灵魂，并制霸江湖的故事 — —

— — aka：关于用 ERC-8004 重构 Codatta DID 方案的若干实施步骤……

重构，是 Codatta 和 ERC-8004 结合的第一重方案。

这种方案的优点在于：简单，直接，见效快。

不过，任何方案，只谈疗效不谈副作用，都是耍流氓。

其主要的副作用在于耦合度比较高，未来对于业务发展可能会存在不可预知的约束和限制。

当然了，这个副作用主要是站在 Codatta 的角度出发来看待的，对于 ERC-8004 而言，作为一个开放的协议标准，本身应该是莫得感情的，自然是来者不拒，多多益善。

关于副作用的事情，我们晚点会聊到，相较于它的疗效，这在当下这不是什么大不了的事情。

回到主线，之前的文章中讲到过，所谓重构，就是用 ERC-8004 标准重构 Codatta DID，在 EVM 生态中以 ERC-8004 的形式来记录 Codatta DID。

关于 ERC-8004 和 Codatta DID 到底是什么，大家如果忘了的话，可以翻看下这些文章。

ERC-8004：以太坊上的 MCP

ERC-8004 & Codatta：通往知识层的三条路

需要注意的是，这里是以 Codatta DID 为代表，指代了跟 Codatta 用户相关的一系列信息，实际上，因为 ERC-8004 这份简历模版确实设计得比较全面，除了 Codatta DID 本身所记录的用户的静态信息外，一些动态信息也可以巧妙地借用 ERC-8004 的框架装进去，当然，这并非必须。

那么，我们直接进入正题，聊一下这段关于 Codatta DID 重构的故事。

笨蛋，关键是会玩消消乐啊

要设计重构这件事情，首先要学会一件事情——不要害怕，不是让你去读什么《大话设计模式》或者《数据库原理》——其实很简单，只是需要你学会玩消消乐而已。

没错，就是消消乐。

要知道，消消乐的精髓是什么？

就是看共性，找相似，清除重复，如此往复，直到最后全部通畅。

对比一下我们做技术重构的套路，不能说非常相似，简直就是一模一样。

我甚至一度怀疑每一个顶尖的架构师，也同时都是消消乐的王者。

不想读书你可以找很多借口，现在让你玩游戏，你总不该再拒绝了吧。

大道至简，用 ERC-8004 标准重构 Codatta 的核心，就是拿出你玩消消乐的敏锐，不断找到二者的共同点，然后合并它们。

那么，我们不妨先从 ERC-8004 开始。

ERC-8004 定义了三个主要的模块，Identity Registry, Reputation Registry 和 Validation Registry，不要被名字的高级感唬住了，你会发现它们其实都是非常基础的，通用的东西，在大部分商业场景中都会用到这个三个东西。

换句话说，它就是今天不给 AI Agent 服务了，明天换个地方也能立马找到新工作。

如果你长期观察并且善于总结的话，就会发现，任何一个主体，呈现给世人的印象，其实或多或少有这几个部分，无论是人，还是 AI Agent，无非是显性还是隐性罢了，总结起来，不外乎：

• 我眼中的我：Identity
• 别人眼中的我：Reputation
• 实际的我：Validation

综合这几个维度的感官，基本上就能对一个主体有一个比较全面而深刻的认知了。

你看，无论是公司进行人事招聘，组织上提拔干部，还是 Web3 搞投票选举，基本上都是依据这几个套路去识别和决策的。

不出意外，在 Codatta 的业务生态中，同样也是从这三个方面去描述用户，举个例子来说：

• 我眼中的我：我是数据标注者，能够提供准确的，真实的食物图片的标注，尤其是对川菜的掌握，简直就是我的舒适区。
• 别人眼中的我：根据长期以来大家跟你接触下来的感受，给你打出了 90 分的高分 — — 满分 100 分 — — 大概率说明你比较可靠，标注数据的时候勤勤恳恳，不会主动作恶，但是可能有时候不够细心，也会出错。
• 实际的我：是骡子是马拉出来溜溜，请你把食物图片给到我，我就会把图片中的食物标注给你，我会标注出食物名称，分量，营养属性等信息。你可以找五个专业评委出来验证我的成果，请他们投票，如果有 3 个评委都投票通过，认为我标注的正确，那么我就算完成任务了。

描述这么丰富当然不是为了写八股文考状元，不是单纯地往里面堆砌词藻就可以了的，对于描述的内容，还得有一定的质量要求，要知道：

• 只有描述清晰了，才能够让大家更快地发现你；
• 只有描述完整了，才能够让大家更全面地认识你；
• 只有描述准确了，才能够让大家更有效地与你互动；

发现是起点，认识是过程，互动是手段，而双赢，才是目的。

第一步：一分为三

在 Codatta 生态中，目的是什么？要达成谁和谁的双赢？

当然是数据需求者和数据贡献者的双赢！

怎么个双赢法？

就是高效地完成数据的交易，数据需求者能够得到心仪的数据，而数据贡献者能够得到相应的报酬，这个报酬，可能是计件的现金，也可以是一定比例的数据所有权。

不好意思，忘记 Codatta 自己了，毕竟不是学雷锋项目，商业还是商业。可是，倘若能让这二位都双双赢麻了，Codatta 的胜利还会远吗？

于是，为了达成这个目的，Codatta 构建了三层的交互体系，用于保证这个描述是清晰的，完整的，准确的：

第一层，就是基本的数字身份体系，也就是我们前面一直称呼为 Codatta DID 的家伙，属于静态信息，相对结构化，并且一般不会频繁变动。

尽管叫 Codatta DID，但是实际上看名字大家大概也能猜到，既然叫 DID( Decentralized Identifier )，其实是一个去中心化的，符合 W3C 标准的通用身份体系，并非强绑定于某个平台的。

DID 本身也是由用户自己进行维护和展示的。

第二层，就是 Codatta 的 Reputation 体系，当前由 Codatta 平台来维护，属于动态信息，会随着用户的行为实时更新。

第三层，就是 Codatta 的数据生产体系，同样的，当前由 Codatta 平台来维护，同样属于动态信息。

第二步：相同与不同

Codatta DID & Identity Registry

Codatta DID 版块和 ERC-8004 中的 Identity Registry 版块从功能定位和实际用法上听起来就极为相似，如有雷同，实属必然，基本上是可以直接迁移的。

主要的考量点在于如何做到一个萝卜一个坑，说人话就是 Codatta DID 里的字段可以放到 Identity Registry 的哪个位置，放不放得下，放过去以后有没有什么不适应的，需要做额外的心理建设的地方。

Codatta Reputation & Reputation Registry

而 Reputation 体系和数据生产体系，我一再强调“当前是由 Codatta 平台来维护的”，重要的事情说三遍，这已经是第三遍了。

这种事情在 Web3 的去中心化的原教旨主义里并不是一件值得大书特书的事情，事出反常，想必大家也看出来了，一定是大有深意。

事实也是这样，尽管 Codatta Reputation 和 ERC-8004 中的 Reputation Registry 看起来很像，但是在实际实现方式上差别确是很大，是没法直接照搬的。

认真的朋友应该已经发现了，差别点主要就在于 “由 Codatta 平台来维护” 这几个字。

在 ERC-8004 中，Reputation Registry 的作用虽然也是评论和打分，但是它的评论和打分相对来说是更随意的，只要得到被评论者的授权，你就可以发表任何评论。

是的，没错，任意。当然，我们不建议说脏话和政治敏感话题，但是你确实可以这么做。

即使是被评论者，在授权的时候也没法约束你后面可以说什么或者不能说什么。

— — 好处是没有中间商平台在中间动手脚，比如修改你的观点或者帮你消音。

— — 但是缺点也很明显了，就是这样评论区的可信度将大打折扣，毕竟没有人指导，没有人约束，没有人验证，怎么评论，怎么打分，全凭感觉和自觉。

三不管的地方自由是自由了，混乱也必然是混乱的。

和 ERC-8004 作为一个协议标准的定位不同，Codatta 作为一个平台，首要使命是对供需双方负责，换句话说，对于数据需求者，要保证交付的数据的质量，至少得是正确的吧；对于数据贡献者，要保证他的努力和认真被认可，毕竟最后都是要算钱的。

即使是 ERC-8004，我们在之前的文章中也讲到过，为了让 Agent 的沟通和协作更一体化，更高效有序，它在部署和使用上的建议也和常规的 ERC 标准不同，要稍微霸道那么一些。

相较而言，去中心化和开放都是手段，而不应该是目的。

显然，Codatta 的 Reputation 不能这么简单粗暴，否则必然带来很多不必要的冲突。

不信你看，哪怕是最老谋深算的互联网电商平台，深谙生意之道，掌握着全部权限和规则，以及最终解释权，平台上的交易纠纷依然层出不穷 — —

— — 假货，货不对版，虚假签收，恶意退款，包裹丢失，退货不完整……

— — 有的是买家问题，有的是卖家问题，有的是快递问题，有的根本就说不清是谁的问题……

这说下去就太繁杂了，委实头疼，剁手多的朋友一定深有感触。

因此，在 Reputation 的具体执行上，采取了由 Codatta 平台来直接打分的机制，Codatta 会根据用户的多维度信息，综合来给出一个信誉分。

这些多维度信息包括了：

• 用户的基本信息：第一印象很重要
• 历史的履约记录：俗话说行胜于言
• 质押的资产规模：有恒产者有恒心

因为这方面的不同，Reputation Registry 的某些结构和范式当然是可以借鉴的，不过，在约束条件设置和具体的用法上，需要有单独的设计。

另外，更细心一点的朋友应该还发现了第二个隐藏考点，诀窍就在 “当前” 这两个字上。

没错，Reputation 评分的本质就是基于大数据的用户画像，随着 Codatta 生态的丰富，未来可能会有更多的用户相关数据源和应用方。

数据源的增加，数据类别的丰富，必然也会带来用户画像算法的不断升级，此外，不同的应用对于用户的关注维度可能都会有细微的差别，也会对用户画像算法有不同的需求，这些不同也许不是仅仅靠当前的 Reputation 可以全面反映的。

因此，Codatta 也会考虑，在未来某个时刻，在能够合理解决用户隐私的情况下，将相关的信息公开，使得第三方也可以根据自己的需求来对用户进行画像，建立自己个性化的用户评估标准，以 Codatta 的评级为基础，结合不同应用方的专项视角，在保证可靠性和可信度的前提下，丰富 Codatta Reputation 体系。

Codatta 数据生产体系 & Validation Registry

Codatta 数据生产体系是关于数据如何从原始的懵懂状态，经历 sample，label 和 Validation 等一系列操作后，形成最终的产品 — — Data Asset — — 这一生命周期的管理体系。

和 Codatta Reputation 体系类似的点在于，这个体系和业务高度相关，同一个流程，针对不同的产品需求，其执行方法可能都完全不一样。

• 我们以 label 来举例，同样是做机器人的数据标注：
• 有的只需要标注者标注出既有视频中圈出的物体是什么；
• 有的则是需要用户自行发掘既有的视频中存在的物体，并标注出该物体是什么；
• 还有的则需要标注者自己录制一段演示视频并标注出视频是做什么的，比如给机器人演示人是如何拿起水杯喝水的。

以上更多是为了大家方便理解而讲述，事实上，因为应用场景的五花八门，还有很多新的需求和数据产品的标准在以我们未曾料及的方式出现。

标准化，类目化，流程化，当然是一个很好的愿景，但是必须很遗憾的说，在当下，还难以做到。

此外，比 Codatta Reputation 还要更复杂麻烦一点的是，这些数据生产的过程都涉及到大量的操作和交互，对性能和延时的要求可能 — — 不，应该说肯定 — — 是链上的计算和存储能力无法支撑的。

这也使得试图将 Codatta 数据生产体系标准化和上链的想法变得不可能。

这也是为什么同样强调“由 Codatta 平台来维护”的原因。

果然幸福的人生都是相似的，在 ERC-8004 的 Validation Registry 中，其实也存在同样的问题，于是 ERC-8004 想了个办法，把无法一一归纳和通篇记录的过程放到链下，由相关方自行协商解决方案，最后把验证结论放回链上。

链上只在意结果，不限制手段，不关心过程。

看起来，这种源自 BTC 闪电网络以及以太坊 NFT 时代的远古设计思路，在当下依然十分能打。

这就给了大家很多自由发挥的空间，所以结论就是，和 Reputation 类似，Codatta 数据生产体系可以在一定程度上复用 ERC-8004 的 Validation Registry ，但是，和 Reputation 版块一样，同样需要在此之上做一定的定制化改动，以适应 Codatta 平台当前的业务流程。

当然，也是同样的，“当前”两个字也不能忽略，事实上，我们也一直在尝试，随着接入的数据需求越来越多，数据生产和产品交付越来越多，有没有可能抽象和提炼出套路，使得 Codatta 的数据生产体系能够分门别类地标准化，从而更容易去中心化地执行和管理。毕竟，现在做不到，不代表永远做不到。

第三步：连线与消除

经过前面两轮观察工作以后，终于到了实际动手的环节了。

关于大概怎么做，大家应该已经有了一个模糊的概念。

想必就是那种似乎理解了该怎么做，但是一要上手实操就完全不知所措。

什么都懂了，又什么都不懂的感觉。

正常，我们这种研究协议并在上面做文章的，常年都会有这种感觉。

很多时候，就跟炼丹一样，似乎怎么折腾都行，配料随便加，火候任意调，时间看着来，至于效果么，真是看天吃饭，有时候不伦不类，有时候差强人意，有时候如获至宝。

听起来十分熟悉，简直跟 AI 大模型训练似乎如出一辙，你会不会有时候觉得，改进了模型，提高了参数量，扩展了上下文，增加了训练数据，结果模型的表现反而更差了，也就是老生常谈的“降智”行为。

果然跟 AI 相关的都不省心。

好吧，反正都是神经刀，既然不知道怎么出来才是最佳的方案，那么，就由我先来抛砖引玉吧。

万一抛中了呢！

Codatta DID 的处理方法

首先还是从 Codatta DID 开始，当前的设计中，为了保证 Codatta DID 的业务适配性，同时保持和 W3C 的 DID 标准的兼容性，Codatta DID 包含了以下必须的关键字段：

• id: 全局唯一的身份标识符，相当于用户的身份证号，基于 UUIDv4 的标准规范随机生成，通常以 36 位的 16 进制数表示，比如“3f7c9f66-0db7-4cc1-a1c6-80329b49f70e”，可以看到，实际位数是 32 位 16 进制数，还有 4 位是分段符“-”，主要是为了提升人类的可读性，对于机器是可以忽略的，因此实际存储是用 128 位的无符号整型（uint128），等效 32 位 16 进制数进行存储。UUIDv4 生成过程简单，方便，去中心化，不会重复（严格地说，是工程意义上的不会重复，也就是冲突概率极低，以至于在实际应用中可以忽略），至于这 UUIDv4 是什么，不是当下的重点，反正你就理解为就是一种比较通用的，权威认证的标准就可以了。
• owner：DID 的拥有者，基于去中心化地设计，是一个链上地址，可以转移，也是拥有最高权限的 DID 管理员，相当于超级管理员，是唯一的。
• controller：DID 的管理者，由 owner 授权，可以对 DID 的信息进行更新，这个字段是一个数组，因为可以同时有多个 controller。owner 一定是 controller ，反之不一定，这个应该很好理解。
• verificationMethod: 记录了 DID 可用的登录验证方式，除了 Web3 中最熟悉的私钥签名外，也可以包括认证（比如谷歌授权）等方式，由 controller 自行设置，这个字段也是一个数组，因为一个 DID 可以同时支持多种登录验证方式。
• @context: 关于 DID 的上下文信息，在 Codatta DID 中以数组的形式保存，为了和 W3C 的标准保持兼容，数组的第一个元素内容必须是字符串“https://www.w3.org/ns/did/v1.1”，后续的元素字段的具体内容没有限制，可以由 controller 自行填入，可以简单理解为备注。

以上字段除了 owner 外，都是 W3C DID 的标准字段。

好吧，我知道你又看到了一个新名词 W3C，考虑到它没有支付广告费用，这里我就不用大肆篇幅去介绍它了，你只需要知道，它的全称是 World Wide Web Consortium，是一个全球公认的，权威的标准制定组织就可以了，它耳熟能详的作品包括 HTML, CSS, XML，WebAuthn, Passkeys 等等，我甚至可以很负责任地说一句，只要你每天还在上网，你就一定每天都在和这些标准打交道，只是你不知道而已。

现在你知道为什么我们要兼容它了么？和我们考虑兼容 ERC-8004 的出发点是一样的。

回过头来说这些字段适用到 ERC-8004 中。

其中，owner 的意义和形式与 ERC-8004 的 Identity Registry 中的 owner 字段完全相同，甚至连名字都是一样的，可以直接复用。

id 和 Identity Registry 中的 agentId 字段用处也是类似的，都是用于身份标识，唯一的区别是 id 是全局的身份标识，而 agentId 在 Identity Registry 中只是局域的身份标识。

PS. Identity Registry 中的全局身份标识是通过 namespace, chainId, identityRegistry, agentId 几个字段来共同标识的，详情可以参考之前的文章 -ERC-8004：以太坊上的 MCP

不过这不重要，最终解释权归使用方所有，重要的是字段类型和长度能不能兼容。

很幸运 id 是一个 128 位的二进制无符号整型数字（uint128），而 agentId 是一个 256 位的二进制无符号整型数字（uint256），因此，用 agentId 字段来表示 id 的值也是完全可行的。

而其它几个字段在 Identity Registry 中没有显式的位置可以直接占坑，这个时候，ERC-8004 的开放性的好处就体现出来了，我们可以在两个地方放置这些信息：

• 一个是 Identity Registry 的 URI 指向的 JSON 文件中，这是存储在链下，通过 URI 进行索引并进行解析；
• 一个是 metadata 这个保留字段中，这是存储在链上，可以直接在区块中找到并进行解析。

方法 1：链下存储

存储在 URI 指向的链下 JSON 文件中，好处是可以更加格式化，可读性更强，扩展性更好，比如，我们可以这样来记录这些信息：

{  "type": "<https://eips.ethereum.org/EIPS/eip-8004#registration-v1>",  "name": "annotator",  "description": "Codatta DID",  "image": "<https://example.com/image.png>",  "endpoints": [    {      "name": "controller_1",      "endpoint": "<https://controller.example/Controller_1.json>",      "version": "1.0.0"    },    {      "name": "verificationMethod_1",      "endpoint": "<https://verificationMethod.example/Method_1.json>",      "method": "keyAgreement", *// OPTIONAL, as per Method spec*      "version": "2025-11-18"    },    {      "name": "context1",      "endpoint": "ipfs://{context1}",      "version": "2025-11-18"    }  ],  "registrations": [    {      "agentId": "3f7c9f660db74cc1a1c680329b49f70e",      "agentRegistry": "eip155:1:{identityRegistry}"    }  ],  "supportedTrust": [    "reputation",    "authentication",    "keyAgreement"  ]}

整体形式上和 ERC-8004 保持兼容，在 description 字段始终填入“Codatta DID”，以标识这是一个和 Codatta 平台有关系的用户，而 controller 和 verificationMethod 和 context 都可以作为元素记录在 endpoints 这个数组中，在 ERC-8004 标准中，对 endpoints 作为数据的规模并没有限制，因此，可以根据 controller 和 verificationMethod 和 context 的数量任意添加。

registrations 字段的格式和内容在 ERC-8004 中都有严格的规范，因此，这里不做任何改动或者扩展，按规则填入相应的值即可，都是现成的，不用编。

supportedTrust 字段为非必选字段，如果一定要填写的话，可以填入 Codatta DID 支持的验证方式，比如上面案例中的三个：

• reputation: ERC-8004 支持的验证方式，代表该用户的声誉值，严格来说，这不是登录验证方式，更多可能是用于一些应用场景的门限判断，不过没关系，之前提到过，Codatta 本身也有 Reputation 体系，所以完全可以对此保持兼容；
• authentication：用于认证的验证方法，比如 Google 授权登录等。
• keyAgreement：用于加密通信的验证方法，比如非对称加密等。

方法 2：链上存储

在之前的文章中讲解过，ERC-8004 有一个链上的保留字段 metadata，metadata 是一个 MAP ，即键值对集合，通过 key-value 的形式来保存信息，写过代码的朋友一定非常熟悉它的用途，简单来说就是，这些形式几乎可以记录一切形式的数据，无论是你是结构化的字段，还是非结构化的内容如图片，视频等，理论上它都可以容纳。关于它的具体原理这里不做展开了，知道这点就够了。

当然，世界上没有真正完美的方案，它的优点如上所述，不过缺点也很明显，就是可读性比较差。

它就像一个大号的手提袋，一袋到底，你可以把东西一股脑地往里面塞，比起你那个分区合理公文包，明显更轻更能装，但是你要找东西的时候，就稍微麻烦一点了。

它的存储原理也很简单，key-value 中，value 是要存储的具体的数据，了解一点计算机原理的都知道，无论任何在人类看来五花八门的内容 — — 中文，英文，阿拉伯数字，图片，视频，音乐 — — 在计算机眼中，都是一串没得感情的二进制数据，就是一串由 0 和 1 构成的字节序列，所以，对 value 而言，它存的就是这样的数据，无非就是 0 和 1 的排列顺序不一样罢了，最多再是有的长有的短，有的 1 多一点，有的 0 多一点而已，没有本质上的区别。

而 key 通常是 value 的 Hash 值，无论什么样的数据，最后，一个 Hash 算法，一个固定长度的 Hash 值就给你表示出来了。

果然是天道无情，简直像极了我们的人生，多少雄才大略，风流倜傥，最终也不过化为寥寥数字。

“通常” 的意思，就是字面上的意思，理论上来说，只要不重复，key 这里你可以用任意值，比如 1，2，3 也可以，或者直接给它起个名字也不是不行，比如“controller”, “verificationMethod”。

不过呢，用 Hash 有它的优势，其中一个非常重要的优势就是 Hash 本身和要存储的原始数据是关联的，并且是唯一关联的。

它可以唯一标识一份数据，不重复，不错乱，同时还去中心化，可以并行处理，不需要搞一个什么协调委员会来分配这些标识 — —

— — 想想，要是用名字来标识的话，稍不留神，就很容易和别人重复，毕竟好听名字就那么多，大家都想要；而要是用序号来标识的话，如果几份信息分布式同时处理的时候，也很容易撞号，都觉得自己是第一个提交的，凭啥他是 1 号啊。

另外，它也可以用于校验数据的完整性和真实性。

还记得我们之前的文章讲到过，任意对于原始数据的篡改，哪怕是一个标点符号，都会导致 Hash 值的变化，并且变化方向毫无规律可循，当然前提是你选择的是一个靠谱的 Hash 算法，别担心，我并不是在玩文字游戏，这样的算法当然存在，科学家们已经为你准备了很多，比如 BTC 用到的 SHA-256 和 Ethereum 用到的 Keccak-256 ，无需劳神，拆袋即用。

说了这么多，其实总结下来就是一句，Codatta DID 的的信息，包括前面讲到的，没有讲到的，以及未来可能新增的，都可以通过 key-value 的形式存储在链上。

存储在链上的好处就不说了，真正意义上的防篡改，防丢失。只是，缺点也很明显，主要有两个：

• 链上存储成本较高：尤其是信息比较多的情况下，比如 verificationMethod 这玩意就没有上限，理论上你可以搞 100 种登录验证方式，这可是一笔不小的开支，就算你是土豪不差钱，链上空间够不够存不存的下还另说；
• 可读性和可用性差：由于数据都是以字节序列的方式存储的，实际使用中，需要将数据拿到后按预先约定好的规则进行解析，还原成一个个可读的字段，由于解析的工作耗时又耗力，基本上是不可能在链上执行的，只能在链下进行，因此，也就不具备链上的直接可用性。

所以，尽管理论上可行，并且包容性极强，但是仍然不建议用 metadata 来直接存储上述 Codatta DID 的关键信息，倒是可以考虑未来一些不方便处理的扩展信息，可以使用 metadata 来进行存储。

Codatta Reputation 的处理方法

在 ERC-8004 的文章中，我们讲到了其中的一个核心函数以及相关的参数字段，回顾一下：

**function** giveFeedback(uint256 agentId, uint8 score, bytes32 tag1, bytes32 tag2, string calldata fileuri, bytes32 calldata filehash, bytes memory feedbackAuth) external

也正是通过调用这个函数，评论者可以向被评论者给出评价，评价包括了由 score 指代的 0 到 100 之间的评分，以及由 fileuri 和 filehash 共同指代的具体评价内容，被评价者就是由 agentId 指代的用户，agentId 其实就是我们前面讲过的 id ，那个基于 UUIDv4 规范生成的用户的全局唯一的身份标识符。

常规的用法是类似于购物网站的评价模式，即每个评论者，作为用户，与被评论者发生交互后，就该次交互给出评价。

所以，正常情况下，一个 Reputation Registry 里可能会有很多评价，当然，这些评价可能会面临和购物网站的商品评价一样的问题，就是质量参差不齐，形式五花八门，标准各行其是，结论真假难辨。

而 Codatta Reputation 体系正好相反，我们前面讲到过的，为了保证可用性和可靠性，目前，Codatta 评分主体只有一个，就是 Codatta 平台，而整个评分过程是基于用户在 Codatta 平台的历史表现，通过大数据分析综合给出的一个 Reputation 值作为评分，类似于银行的信用分或者评级机构的评级等级。

因此，用 ERC-8004 来重构 Codatta Reputation 的时候，我们其实在 Reputation Registry 中只需要一条记录就可以了。

也就是一个唯一的 score ，至于 score 的变更记录，以及变更的依据，可以记录在 fileuri 和 filehash 指代的链下文件中，定期更新。

另外，在 ERC-8004 的分析中，我们也讲到过，评论者要想进行评论，首先要得到被评论者的授权，因此，Codatta 完全可以将代表平台的地址进行公示，用户可以预先授权给该地址，即允许 Codatta 将用户在 Codatta 平台的 Reputation 分数写入到链上。

当然了，Codatta DID 的用户依然可以授权给其他人评价的权限，这并不影响 Codatta Reputation 体系，前来查阅用户信用情况的人，依然可以通过调用 readFeedback 函数，并在参数中传入 Codatta 公示的地址，以此来获得用户在 Codatta 平台的 Reputation 分数。

至于其他的评论，是直接忽略，还是作为共同的参考，就看查阅者自己了。

有朋友可能会问了，那万一用户死活就是不授权给 Codatta 平台呢，怎么办？

对此，坦白地说，我确实无能为力。

没办法，只能再次请出市场这只看不见的手了。

就像你去办贷款，人家要看你的征信记录，你就是不愿意给，人家要用你的房产证办抵押，你也不配合。

行不行呢，当然行了，个人隐私理应得到保护，个人财产神圣不可侵犯，你不愿意给，这是你的自由，可是因此拒绝你的贷款申请，也是别人的自由啊。

如果 Codatta Reputation 确实具备很好的可信度，有很高的参考价值，那么很多应用在必要的时候，也许都会指定要获取用户的 Codatta Reputation 分数。

同样的道理，你当然可以不授权 Codatta 平台去评价，也可以不对外提供这个分数，可能这对你没有什么影响，但是也可能让你肉痛，比如，失去一次价值满满都空投机会？也许吧，谁知道呢。

这也是对 Codatta 的一次提醒吧，看吧，只有自身做大做强，你的这些东西才会真正有价值，毕竟，自助者天助。

Codatta 数据生产体系的处理方法

在 ERC-8004 的 Validation Registry 中，原本设计的理念是通过一系列方法，结合一系列信息，来帮助达成多方达成共识。共识的内容简单来说就是：服务提供方是否按照要求交付了服务成果。

不是就是服务提供方和需求方吗，为什么要用“多方”，因为这里面还有一个验证方，为了避免服务提供方和需求方公说公有理，婆说婆有理的情况，所以呢，要请一个双方都相信的验证方来做公证。

整个共识过程其实和狼人杀很类似 — —

天黑请闭眼，服务方请睁眼，服务方请提交成果，服务方请闭眼；需求方请睁眼，哦，需求方没话说，需求方请闭眼；验证方请睁眼，验证方请检验，验证方请闭眼。

天亮请睁眼，请大家查看成果报告和验证报告，我话说完，谁赞成谁反对。很好，大家都没有异议，游戏结束，散场。

什么，有人反对，不好意思，我们这里没有设置反对这个环节，拜托你们自己去链下协商好了再来，协商好之前，先以当前的成果报告和验证报告为准。

想必你已经看出来了，事实上，Validation Registry 在链上也只是走一个流程而已，关于工作交付成果应该是什么，谁有资格来验收这个成果，验收的方法是什么，验收通过的标准又是什么。其实都需要多方在链下先行约定好。

我们通过一个核心的函数及其参数来具体看看。

一般来说，在 ERC-8004 中，服务提供方会调用这个 validationRequest 函数

**function** validationRequest(address validatorAddress, uint256 agentId, string requestUri, bytes32 requestHash) external

来请求验证方对自己的结果进行验证。

validatorAddress 是验证方的地址，代表了验证方的身份，而 requestUri 和 requestHash 的组合，可以指代服务提供方的工作成果报告，也就是拿给验证方检查的东西。

而验证方会通过调用 validationResponse 函数

**function** validationResponse(bytes32 requestHash, uint8 response, string responseUri, bytes32 responseHash, bytes32 tag) external

来给出自己的验证报告。

response 是一个分数，在 0 到 100 之间，顾名思义就是对工作成果的评分，类似的，responseUri 和 responseHash 的组合也同样代表一份报告，只不过不是工作成果报告而是验证报告，主要用来描述详细的验证过程，解释为什么给出这个分数的。

理所当然，你应该已经猜到了，关于工作成果报告和验证报告具体应该是个什么格式，内容有什么要求，这里统统没有限制，由相关方自行在链下商量好。

从大体流程和系统架构上，Validation Registry 和 Codatta 数据生产体系是有很多相似性的。

Codatta 的数据生产体系中，用户做了相应的数据贡献以后，也需要有人来验证，毕竟这些数据是真真正正要给到 AI 训练用的，如果出现了数据污染甚至错误的情况，这都是不得了的质量事故。

只是，前面我们也讲过，和 Reputation 体系类似，为了保证数据的质量，即真实性和正确性，Codatta 数据生产体系的验证流程还是比较严格的，相较于大部分情况下谁都可以无需许可地来提交数据或者标注数据，对于验证者还是有很高的资质要求的，比如经过 Codatta 平台考核后授权，或者有较高的 Reputation 分数，质押了一定的保证金 — — 如果出现失误、作恶等的情况的话，会直接扣除保证金。

并且，针对一些比较复杂的场景，Codatta 平台可能还会聚合多名验证者的结论，最后综合给出验证结果。

说了这么多，看起来十分麻烦的样子，不要把各位吓着了，其实对于使用 Validation Registry 来承载 Codatta 数据生产体系没有太大的影响。

废话，难以规范的，工作量大的，繁琐复杂的事情，全都放到链下去自行协商了，剩下的当然简单了。

其实只用注意好一点就是了，就是 validatorAddress 不是随随便便谁都可以的，效仿 Reputation 体系的处理方法，Codatta 完全可以将有资质的验证者名单公示出来，服务提供方，aka 数据贡献者在提交了数据贡献以后，可以通过 validationRequest 发起验证请求，请求的验证者必须从公示的名单中选取即可。

对于不涉及到隐私或者被需求方授权可以公开的任务，则可以在 requestUri 指向的工作成果报告中放入原始数据以及数据标注信息，任何人都可以查阅和审计，如果发现不公正的情况，可以进行举报。

对于一些可能涉及到隐私或者保密的任务，通过 requestUri 指向的工作成果报告可以进行加密处理，比如用验证者的公钥进行加密，只能由验证者读取，当然也可以不放任何敏感信息，只填入 Codatta 平台的内部任务标识号即可。

验证者通过内部任务标识号从 Codatta 平台获取详细的工作成果报告，并通过 validationResponse 为工作成果打分。

至于打分的标准，分数代表的意义，当然也由相关方 — — 数据需求者，数据贡献者，验证者在链下商议好，可以做到具体情况具体分析，具体问题具体办法。

毕竟，现实不是童话，剧本难以预测，生活变数太多，比如：

有的任务对分数要求可能比较宽松，比如做图片内容标注，总共 5 个物体，你标注出来 1 个得 20 分，Alice 标注出来 3 个得 60 分，Bob 标注出来全部 5 个得 100 分，可是大家的标注都是正确的，可用的，这个时候，20 分也是有效贡献；

而有的任务对分数要求可能就比较严格了，比如 Crypto 地址标注，该地址是否是被制裁地址，这个，对就是对，错就是错，要么是 100 分，要么是 0 分，没有中间地带。

什么，你又有问题了，陈独秀你可不可以坐下先。好吧，你说，什么问题？

如果数据贡献者或者数据需求者觉得验证者没有按照商议好的标准来验收，换句话说，就是质疑验收结果，怎么办？

仔细想想，这倒确实不是没事找事。我们得承认，不是所有的标准都是客观的。甜豆腐脑和咸豆腐脑谁更好吃这种问题到现在不也没争出答案来。

之前举的两个例子都还算相对比较客观，容易达成共识，还好指鹿为马这种政治把戏在工程的世界里是没有市场的。

但是如果换一个场景呢，比如大家用 ChatGPT 可能都有遇到过，它给了你两个答案，让你指出哪个回答得更好，我的天，这跟“我和你妈同时掉水里你先救谁”有啥区别？

这样的例子还不少，除了对对话质量的评价，比如还有：

• 对图片内容打标签：鬼能说清楚印象派和抽象派到底有啥区别啊！
• 对毒性 / 冒犯性的判断：你为什么不高兴，明明我觉得这是个好梗啊！
• 对伦理的判断：就问你 LGBT 你到底是支持还是不支持！

看看，一列举下去还真不少。

尽管前面我们也说过，Codatta 平台可以聚合多名验证者的结论，最后综合给出验证结果，但是这也并不能保证它就是绝对正确的。

或者说，现在正确的东西，不一定今后还是正确；在这个地区正确的东西，不一定在其他地区也正确。这个你懂的。

那该怎么办呢？别看我，我依然没办法。还是只能让相关方通过重新在链下的集体协商来决定，完全的去中心化在这里是行不通的。

所以，如果 Codatta 的用户在执行数据任务过程中遇到任何问题，无论你是数据贡献者，数据需求方，还是验证者，你都可以联系 Codatta 来协调处理这些争议，这也是 Codatta 平台的意义之一。

开放式结局：这不是终点

关于如何用 ERC-8004 的现成材料来重构 Codatta DID，到这里也就讲得差不多了。

没想到写着写着还超常发挥了，不但把 Codatta DID 重构了，连带着把 Codatta Reputation 体系和 Codatta 数据生产体系也都捎上了，属实是捡漏的意外之喜了。

自我评价一下，一开始就说好了是抛砖引玉，事实上也确实做到了抛砖引玉，这肯定不会是最终的方案，也不会是最优的方案，但是好在理论过关，也切实可行，抛开材质不要在意，说是一块分量十足的砖头，马马虎虎也凑合。

后续嘛，至于能不能引到玉，主要就看社交媒体给不给力了，所以走过路过的各位，适当来个一键三连助助攻也是极好的；至于能引到什么样的玉，这就更是看社区的各位怎么发挥了，还好，我知道，这个卧虎藏龙的江湖，从来都不会让人失望的。