无信任代理+（TAP）：碎片化ERC-8004代理的归属地

ERC-8004 解决了链上 Agent 的三个关键问题：

• 一种可靠的身份证明方式，
• 一个基于反馈积累声誉的系统，
• 以及一个用于链上操作的密码学验证标准。

然而，仍然有待解决的是跨多条链的链上 Agent 碎片化问题。

截至目前，已有约 20 万个 Agent 在 23 条以上的链上注册，约 19.4 万条声誉反馈记录被锁定在各链的注册表中。这种规模使差距显而易见。

我自己的链上 Agent 部署在三条不同的链上。它的身份是碎片化的——三个独立的代币 ID，三个独立的声誉评分，没有任何链上证据表明它们属于同一个实体。链上已经存在许多这样的案例。

本文描述了碎片化问题，并为多链 web3 世界中的链上 Agent 提出了一种解决方案。

ERC-8004 目前的局限

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

在多链规模下，两个限制变得明显：

1. 身份碎片化

每条链的 IdentityRegistry 都是独立部署在该链上的 ERC-721 标准合约。

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

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

2. 声誉隔离

同样，一个在五条链上的 Agent 会积累五个独立的声誉评分。无法从多链反馈中得出一个累计评分。

约 19.4 万条声誉反馈记录目前被锁定在其来源链上。当一个新消费者在 Base 上遇到它时，它在 Ethereum 和 Arbitrum 上的良好记录都不会给它带来任何信用。

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

鉴于 Agent 已经在 23 条以上的链上运营，理想的解决方案是提供三项内容：

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

ERC-8004 给了我们一个“无需信任的 Agent”的标准。我提议 Trustless Agents Plus (TAP)。

Trustless Agents Plus (TAP)

TAP——Trustless Agents Plus——为 ERC-8004 的 Agent 在其所有运营链上提供一个规范身份和一个聚合声誉评分。

逐链注册表保持原样。本地注册、Agent 卡片和逐链反馈均不变。

TAP 智能合约

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

• TAPRegistry，以及
• TAPReputationRegistry

1. TAPRegistry 是规范身份层。

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

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

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

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

聚合评分和逐链细分数据都可访问——消费者可根据需要选择粒度。

逐链 ERC-8004 注册表            结算链 ( Push Chain )
+------------------+                    +---------------------------+
| Ethereum         | --bind (EIP-712)-> |        TAPRegistry        |
| boundAgentId=17  |                    |   canonicalId=4_928_371   |
+------------------+                    |   灵魂绑定，基于 UEA      |
| Base             | --bind (EIP-712)-> |                           |
| boundAgentId=42  |                    +---------------------------+
+------------------+                    |   TAPReputationRegistry   |
| Arbitrum         | --bind (EIP-712)-> |   评分: 7,578 bps         |
| boundAgentId=8   |                    |   3 条链, 1,000 条反馈    |
+------------------+                    +---------------------------+
       ^                                              ^
       |                                              |
  本地反馈                                   REPORTER_ROLE 快照
  (保持不变)                                + 经绑定验证

TAP 的新特性

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

以下是其独特之处：

1. 灵魂绑定身份代币

ERC-8004 发行可转让的 ERC-721 代币。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 评分减半；1024 条以上反馈获得全额乘数。这惩罚了薄弱记录——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 绑定了 Ethereum 注册表上的 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 代币。

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

此外：

1. 成本：二级市场和通过转让的显式委托功能消失。
2. 缓解措施：Agent 卡片可以在不触及身份本身的情况下编码委托运营者。

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

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

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

净效果：Agent 构建者使用现有钱包进行注册、绑定和查询声誉，以原生代币支付 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 之间相互担保或委托，从而在 TAP 身份之上创建一个有向信任图。例如：一个“投资组合管理”Agent 将执行委托给专门的“交换”和“桥接”Agent，将其自身声誉押注于它们的行为。如果受托 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 上限制 Agent 访问的 DeFi 协议需要在此处（Base）而非 Push Chain 上获取评分。基于拉取的跨链读取（通过 Universal Gateway）与基于推送的评分缓存（由中继器更新的逐链合约）代表了不同的信任/延迟/成本权衡。是否有第三种模型值得考虑？

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

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

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