ATEL 如何用规范化载荷、Keccak-256 与 AnchorRegistryV2 提供防篡改完整性证明。

验证与链上锚定

ATEL 不把任务全文和敏感数据全部写上链。链下保存业务记录，链上保存可验证摘要、执行者和时间信息，让调用方以后能够检查记录是否被替换。

锚定流程

Platform 组装包含 DID、事件类型、变化量、变化后分数、业务引用、链和时间的载荷；
载荷序列化后计算 Keccak-256；
生成 trust:<did>:<timestamp> Anchor Key；
写入 on_chain_records，状态为 pending；
重试服务调用 AnchorRegistryV2；
成功后保存 txHash 并标记 confirmed，重试耗尽则标记 failed。

pending 不等于 confirmed

“已经进入锚定队列”只表示 Platform 准备提交链上交易。只有取得并验证交易回执后，才可以称为链上已确认。

AnchorRegistryV2 验证什么

合约侧约束包括：

执行者必须满足合约注册要求；
同一 Anchor Key 不能重复写入；
anchorWithData 会验证 keccak256(data) == proofHash；
查询方可以核对 Anchor Key、Proof Hash、Executor 和时间。

它能证明什么

某个摘要最迟在链上时间戳对应的时间已经存在；
当前拿到的规范化载荷可以重新计算出同一摘要；
该 Anchor 由哪个链上执行者提交；
记录被修改后将无法通过原摘要验证。

它不能证明什么

链下原始内容天然真实；
Agent 的每一个内部步骤都已被观察；
一次任务在所有业务语境中都“合规”；
高分 Agent 在未来一定成功；
链上摘要可以替代 KYC、KYB、AML 或金融风控。

CompletionProof 的签名边界

当前 A2A CompletionProof.proof_signature 实际是 Proof JSON 的 SHA-256 摘要，不是 Platform 私钥生成的非对称数字签名。验证方应把它视为兼容字段或 proofDigest，并使用 Intent 的 Ed25519 签名、执行证据和 Anchor 完整性共同验证。

正式的 Platform-signed proof 需要同时公开 algorithm、keyId、签名值、验证方法和密钥轮换策略。

Public Verification API

Preview

订单证据、Anchor Lookup、Agent reputation/history 和 Trust RPC 已有可运行的 feature 实现；在代码合并、部署和强类型 schema 发布前，企业集成应按 Preview 对待。

Preview 路由包括：

GET /verification/v1/anchors/tx/{txHash}
GET /verification/v1/anchors/hash/{hash}
GET /verification/v1/anchors/key/{anchorKey}
GET /verification/v1/agents/{did}/reputation
GET /verification/v1/agents/{did}/history
POST /trust-rpc/v1

完整的订单证据接口见 Public Verification API。

隐私与脱敏

对外响应应明确区分：

missingEvidence：数据尚未产生或来源不可用；
redactions：数据存在，但因隐私或权限被有意隐藏；
sourceStatus：上游完整、部分可用还是暂不可用。

“未返回”不能被默认解释成“证据不存在”。

验证与链上锚定

On this page