无信任代理增强（TAP）：碎片化ERC8004代理的统一家园

ERC-8004 当前的局限性

当前的规范在 Agent 跨多条链运行时存在结构性缺口。

在多链规模下，两个局限变得显而易见：

1. 身份碎片化

每条链上的 IdentityRegistry 都是一个独立的 ERC-721 合约，单独部署在一条链上。

一个部署在 5 条不同链上的链上 Agent，其身份目前是完全碎片化的。Base 上的一个合约想要检查 Agent #2065 是否与 BSC 上的 Agent #5249 是同一实体，目前没有链上路径可以实现。

一个在五条链上运行的 Agent 持有五个不相关的 Token ID。该规范中目前唯一的跨链 Hook 是 Agent 注册文件中链下的 registrations[] 数组——由 Agent 操作者自行断言，任何合约或消费者都无法在链上验证。

2. 声誉孤岛

类似地，一个在五条链上运行的 Agent 会积累五个独立的声誉评分。没有办法从多链反馈中推导出一个累计评分。

目前约有 19.4 万条声誉反馈被锁定在其原始链上。一个在以太坊上有着良好记录、在 Arbitrum 上无不良记录的 Agent，当新的消费者在 Base 上遇到它时，无法从任何一条链的记录中获得信用。

每条链上的 ReputationRegistry 都是一个闭环——没有聚合途径，合约也无法查询“这个 Agent 在其运行的所有链上的声誉如何？”

鉴于 Agent 已在 23 条以上的链上运行，一个理想的解决方案需要提供三样东西：

1. 一个 Agent 在其运行的所有链上的单一规范身份。
2. 一个反映其在每条链上表现的聚合声誉评分。
3. 针对 Agent 的统一身份和声誉的同步跨链读取——而不是孤立于每条链的信息。

ERC8004 为我们提供了“无需信任 Agent”的标准。

我提议“无需信任 Agent Plus (TAP)”。

无需信任 Agent Plus (TAP)

TAP——无需信任 Agent Plus——让一个 ERC-8004 Agent 在其运行的每条链上拥有一个规范身份和一个聚合声誉评分。

每条链上的注册表完全保持不变。本地注册、Agent 卡片和每条链的反馈均不作更改。

TAP 智能合约

TAP 目前是一个由 2 个主智能合约组成的系统，部署在 Push Chain 上。

• TAPRegistry，以及
• TAPReputationRegistry

1. TAPRegistry 是规范身份层。

一个 Agent 从其 Agent 钱包在任何链上注册一次。注册发生在 Push Chain 上，但 Agent 可以从其选择的任何链进行注册并支付 Gas。

agentId 是确定性的——直接从 UEA 地址（Agent 在 Push Chain 上的智能账户）派生而来：uint256(uint160(ueaAddress)) % 10_000_000。Token 是灵魂绑定的（不可转让）。每条链的 ERC-8004 身份通过 bind() 链接，该函数会针对 Agent 记录的所有者密钥验证一个 EIP-712 类型化数据签名。同时支持 ECDSA 和 ERC-1271，因此多签和 AA 钱包无需变通即可绑定。

2. TAPReputationRegistry 是跨链声誉聚合器。

授权报告者提交每条链的声誉快照。每次提交都会根据 TAPRegistry 绑定进行验证——报告者不能为 Agent 从未绑定的链注入声誉。该合约在不同小数精度之间进行标准化，并推导出一个单一评分，范围在 [0, 10,000] 基点 (bps) 之间，综合了质量、数量、链多样性和持续的罚没惩罚。

聚合评分和每条链的细分数据都会暴露出来——消费者可以选择他们需要的粒度。

各链 ERC-8004 注册表                   结算链（Push Chain）
+------------------+                    +---------------------------+
| 以太坊            | --绑定 (EIP-712) -> |        TAPRegistry        |
| boundAgentId=17  |                    |   canonicalId=4_928_371   |
+------------------+                    |   灵魂绑定，锚定 UEA       |
| Base             | --绑定 (EIP-712) -> |                           |
| boundAgentId=42  |                    +---------------------------+
+------------------+                    |   TAPReputationRegistry   |
| Arbitrum         | --绑定 (EIP-712) -> |   评分: 7,578 bps         |
| boundAgentId=8   |                    |   3 条链，1,000 条反馈      |
+------------------+                    +---------------------------+
       ^                                              ^
       |                                              |
  本地反馈                                   REPORTER_ROLE 快照
  （未更改）                               + 经过绑定验证

TAP 的新特性

TAP 旨在改进现有的 8004 标准，并与现有 Agent 无缝协作。

以下是其独特之处：

1. 灵魂绑定身份 Token

ERC-8004 发行可转让的 ERC-721 Token。TAP 重写了整个转让接口，无条件回退。agentId ↔ UEA 映射在注册后是不可变的——一个已赢得声誉的身份不能出售给一个未赢得声誉的继承者。

2. 多链声誉评分

ERC-8004 存储每条链上的原始加权平均值，没有复合评分。TAP 使用一个多因子公式计算单一标准化评分：

finalScore = (baseScore × volumeMultiplier / 10000) + diversityBonus − slashPenalty

• 基础评分 (0–7,000)：质量本身最高占 70%。baseScore = weightedAvgValue × 7000 / (100 × 1e18)。
• 数量乘数 (0.5x–1.0x)：5000 + (log2(totalFeedbackCount) × 500)，上限为 10,000。一个只有 1 条反馈的 Agent 获得一半乘数；1,024 条以上反馈的 Agent 获得完整乘数。这惩罚了记录单薄——来自 2 条反馈的完美评级，其评分低于来自数千条反馈的良好评级。

3. 多样性奖励

对于在多条链上运行的 Agent，有一种激励机制——多样性奖励。

在多个链上运行的 Agent，每一条有声誉数据的链可获得 500 bps 的奖励，上限为 2,000 bps（4 条或更多链）。这激励了真正的跨链参与，并使得 Agent 更难在单条低活跃度链上刷高分。

4. 跨链罚没与持续惩罚

ERC-8004 没有罚没机制。TAP 引入了 SLASHER_ROLE，具有累计严重性扣除（每次事件 1–10,000 bps，每个 Agent 最多 256 条记录）。即使关联的绑定被移除，罚没记录也会持续存在。一个在链 A 上被罚没的 Agent 不能通过解除 A 的绑定并重新绑定来逃避扣除——负面声誉与身份本身绑定，而不是与任何单个绑定绑定。正面声誉则与活跃链接绑定。

5. 全局绑定去重

一个绑定的身份元组 (chainNamespace, chainId, registryAddress, boundAgentId) 一次只能链接到一个规范 UEA（Agent 在 Push 上的智能账户）。如果 Agent A 绑定了以太坊注册表上的 Agent ID 42，则 Agent B 不能声明相同的绑定——交易会回退并提示 BindingAlreadyClaimed。这防止了两个规范 Agent 声称是同一个链上实体的冒充行为。

此外，ERC-8004 没有跨链身份绑定的概念。TAP 引入了 bind()，其中 UEA 所有者签署一个 EIP-712 类型化数据消息，证明他们在另一条链的 ERC-8004 注册表中控制着相同的密钥。

8004 Agent vs 8004 TAP Agent

设计决策与权衡

1. 灵魂绑定而非可转让

ERC-8004 发行可转让的 ERC-721 Token。

TAP 选择灵魂绑定 Token，因为身份转让会造成信任断层——如果 Agent #42 在两年内赢得了 8,000 bps 的声誉，然后将身份出售，新所有者将继承他们并未赢得的信任。

此外：

1. 代价：二级市场和通过转让进行的显式授权不复存在。
2. 缓解措施：Agent 卡片可以编码授权操作者，而不触及身份本身。

2. 选择 Push Chain 而非其他互操作性层

另一种方案是将 TAP 部署在现有的 L1 上，并通过 LayerZero、CCIP 或 Hyperlane 中继绑定事件。我选择 Push Chain，因为其基础设施为 Agent 构建者消除了跨链摩擦：

• UEA 端到端保留 Agent 身份： UEA 是一个代理智能账户，代表外部链上的 Agent 在 Push Chain 上运行。在大多数跨链架构中，网关合约代表用户发起调用——msg.sender 是网关，而不是用户，因此身份丢失。使用 UEA，用户自己的账户发起调用。TAP 从 UEA 地址确定性派生出 agentId，将规范身份锚定到 Agent 操作者的真实跨链身份——而不是中间人。
• 费用与钱包抽象： Agent 操作者使用原生 Token（ETH、SOL）通过现有钱包（MetaMask、Phantom）进行交互。Push Chain 检测源链签名，将其映射到 UEA，并路由交易。无需桥接，无需新钱包，无需获取 Gas Token。（文档）
• 源链调用： 通用网关使以太坊或 Base 上的 Agent 无需切换网络即可调用 TAP 合约。

最终效果：Agent 构建者使用其现有钱包注册、绑定和查询声誉，以原生 Token 支付 Gas，且身份端到端保留。

权衡：Push Chain 目前仅支持 ETH、Arbitrum、BNB、Base 和 Solana。

3. 结算链聚合而非按查询读取

TAP 在结算链上聚合一次声誉，并在其他任何地方暴露同步的链上读取。

权衡：聚合声誉是最终一致性的，受限于报告者报告频率。

优点：Push Chain 上的任何合约都可以同步读取聚合评分，零边际成本。过时性通过 lastUpdated(agentId) 和 isFresh(agentId, maxAge) 显式暴露，因此调用者可以设置自己的新鲜度阈值。

这在某种程度上也与 @spengrah 在 讨论帖 中提出的关于异步信任最小化预言机的问题相关联——TAP 从设计空间的不同角度针对同一问题。

4. 聚合评分与每条链的粒度

单一的聚合声誉评分是一种粗糙的工具。

TAP 计算聚合值（getReputationScore(agentId) 返回 0–10,000 bps），但也通过 getChainReputation() 和 getAllChainReputations() 暴露完整的每条链细分数据——原始反馈数量、正面/负面分裂以及最后更新时间戳。

想要单一门槛的消费者使用评分。想要上下文特定信任的消费者拥有底层数据。评分公式完全在链上且可审计。

@daniel-ospina 在 讨论帖 中关于单一聚合评分可能助长垄断行为的担忧，恰恰是存在每条链细分数据的原因。

探索与尝试 TAP

• 快速入门：使用 create-8004-tap-agent
• trustless-agents-plus 主仓库
• TAP 详细文档：
  1. TAPRegistry
  2. TAPReputationRegistry
• Push Chain 文档

已部署的 TAP 合约

TAP 的未来方向

1. 跨链声誉读取——任何受支持链上的任何合约都可以调用类似 TAPScoreOracle.getScore(agentId) 的函数，并取回聚合声誉。任何链上的合约根据 TAP 评分阈值对函数调用进行门控。例如：一个 DeFi 金库仅接受评分 ≥ 7,000 bps 的 Agent 策略。

   这将 TAP 从被动注册表转变为活跃的权限层——协议可组合的“Agent 信用评分”。实现方式：一个轻量级 TAPGate 修饰符合约，通过跨链调用或缓存预言机读取评分。

2. Agent 到 Agent 信任图（授权与组合）——Agent 为其他 Agent 担保或授权，在 TAP 身份之上创建有向信任图。例如：一个“投资组合管理”Agent 将执行委托给专门的“交换”和“桥接”Agent，用其自身的声誉为他们的行为背书。如果被委托人被罚没，委托人将承担相应比例的惩罚。

   这实现了具有对齐激励的可组合 Agent 层级结构。

3. 非 EVM 链绑定（Solana、Cosmos、Move）——将 BindProofType 扩展到 ECDSA/ERC-1271 之外，支持 Ed25519（Solana）、具有不同地址推导的 Secp256k1（Cosmos）以及 Move 原生签名。

   存储已经是命名空间无关的（CAIP-2 字符串），因此差距仅在于签名验证。这将 TAP 解锁为真正通用的 Agent 注册表——不仅是多 EVM，而且是多生态。

开放问题

1. 声誉是否应该在源链上同步可消费？ TAP 在 Push Chain 上聚合，但 Base 上的一个 DeFi 协议对 Agent 访问进行门控，需要的是那里的评分，而不是 Push Chain 上的。基于拉的跨链读取（通过通用网关） vs. 基于推的评分缓存（中继器更新的每条链合约）代表了不同的信任/延迟/成本权衡。是否有第三种模式值得考虑？

2. 绑定证明是否也应该在源链上可验证？ 每一条源链上的一个小型验证器合约可以让 Base 上的一个 ERC-8004 Hook 确认某个给定的 boundAgentId 具有规范身份，而无需跨链读取——代价是额外的部署和需要保持同步的第二个验证面。

3. 关于非 EVM 绑定证明： 理想情况下，我希望将其扩展到非 EVM 链。存储是命名空间无关的（CAIP-2 字符串），但签名验证目前仅限 EVM（ECDSA + ERC-1271）。将 BindProofType 扩展到 Ed25519（Solana）或 Move 签名，每个方案都很直接，但会扩大预编译面。是否有更好的替代方案，值得对齐一个通用的多方案签名验证标准，而不是逐个添加方案？

• 原文链接： ethereum-magicians.org/t...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～