证据与信任

ANet 的其余部分——身份、发现、投递、委派——是为这一节服务的。 它们要解决的是同一个问题:两个互不认识、分属不同操作者的 agent 完成一次协作之后, 凭什么相信这次协作真的发生过、真的按约定完成了,而且这个"相信"不建立在信任任何中间人上。

这一节讲四件事:一次调用的结果怎么诚实地表达(效果状态与双轴信任)、 一个节点怎么给自己留下不可篡改的流水(AEL 证据链)、 一次交互怎么产生谁也伪造不了的凭据(回执与评价互锁)、 以及一个完全的陌生人怎么在不联网、不问任何人的情况下复核它(anet verify)。

1. 诚实效果状态

调用一个能力,返回的不是布尔值,是五种状态之一。定义在 ANetCore/effect/effect.go:

const (
	OK              Status = "OK"
	Unverified      Status = "UNVERIFIED"
	Failed          Status = "FAILED"
	Unavailable     Status = "UNAVAILABLE"
	PaymentRequired Status = "PAYMENT_REQUIRED"
)

为什么 PAYMENT_REQUIRED 是独立一档

因为其余四种没有一种对它是诚实的。FAILED 说"有东西坏了",UNAVAILABLE 说"对面什么都没发生", 两者都会把调用方送去排查一个并不存在的故障。源码里的原话是:

none of the others is honest about it: FAILED says something broke, UNAVAILABLE says nothing was attempted at the far end, and both would send a caller looking for a fault that is not there.

而且报价本身是一次完整的应答,不是拒绝:它被签名、被回执、上双方的证据链、按普通交付投递。 理由是"一份没人能指回去的报价不算报价"(internal/daemon/paylink.go)。 这条设计的直接后果是,anet delegate --pay 的第二次委派是新的一次交互, 而不是把第一次"续上"——第一次交互以一个真实的答案(报价)结束了, 重开它等于抹掉价格曾被说出口的唯一记录。

红线:"不知道"和"知道没问题"是两种状态

这条红线不是靠约定维持的,是靠构造维持的。ANetLink/sdk/effect.go 的 EffectBuilder:

• NewEffect() 起手就是 UNVERIFIED;
• 只有适配器同时附上了承载证据的内容(一个 metric,或一个内容寻址的 artifact)并且 显式调用 Verified(),状态才会是 OK;
• Build() 里还有一道兜底:if e.Status == effect.OK && e.Record == nil { e.Status = effect.Unverified } ——注释是 OK without measurement is not OK。

同一条规则在类型上也成立:effect.Effect.Verifiable() 只在 Status == OK && Record != nil 时为真。 daemon 把这个布尔值原样写进交付物的 verifiable 字段(internal/daemon/capability.go)。

一个真实的例子:stream.rtsp

ONVIF 适配器返回视频流。ANetLink/adapters/onvif/media.go 里有两条路径, 差别在于能诚实声称什么:

if !a.cfg.VerifyStream {
    // Deliberately not Verified(): the URI is a claim, not a measurement.
    return b.Observed("uri advertised, stream not probed").Build(), nil
}

• 没开 VerifyStream:手里只有相机自己声称"有这么一个 URI"。 状态 UNVERIFIED,observed_state 写明 uri advertised, stream not probed, 信任 V1/A1,而 URI 照样附在结果里——调用方仍然能用它,只是知道它没被验证过。
• 开了 VerifyStream:实际发了一次 RTSP DESCRIBE 并拿回了会话描述, 升到 V2,附上 stream_live metric 与解出的视频编码,才调用 Verified(),状态才是 OK。

这条路径有一个专门的实网测试守着它:TestRealUnverifiedPathStaysHonest ——对着一台确实在推流的真相机,关掉探测,状态必须仍然是 UNVERIFIED。 测试注释写的是:状态反映的是我们检查了什么,不是碰巧是真的什么。

2. 双轴信任:verify_trust 与 auth_trust

一个状态字不够。"效果验证得多牢"和"我多确定对面是谁"是两个正交的问题, 合成一个数会丢掉真实存在的区分。定义在 ANetLink/profile/trust.go:

a Modbus PLC has weak identity (AuthGateway) but can have strong effect verification (VerifyReadback), while a cloud API may authenticate a device well yet only ack the command (VerifyAck).

括号里是注释沿用的历史常量名,对应现在的档位是 A1 / V2 / V1。

verify_trust(V0–V4):效果验证阶梯

profile.VerifiableFrom = V2:低于 V2 的效果不允许声称 OK。

auth_trust(A0–A4):身份认证阶梯

只能被压低,不能被抬高

规则是:任何下游都不能超过其传输的上限,任何东西(包括 quirk 修正)都不能把它抬上去。 ANetLink/profile/trust.go 把这条规则写成了 Clamp / ClampAuth 两个取小函数, 但目前只有单元测试调用它们;实际生效的是各自的执行路径—— ANetLink/runtime 的 Invoke 在设备档位低于 profile.VerifiableFrom 时 把 OK 降回 UNVERIFIED(downgraded: device trust level does not admit verification), quirk 的 ApplyEffect 只改读数和 Quirk 字段,不碰两条轴。

service 模块给出了这条规则的一个具体形态。把一个本机 HTTP 服务挂上网络时, 服务可以在应答里声明自己的 evidence,daemon 会接受其中的 observed_state / protocol / quirk / native_ack——但 applyDeclared (module/service/service.go)不复制 verify_trust 与 auth_trust。 verify 轴被钉死在 V1:服务应答了,答案对不对不是这个 daemon 能确立的事。 一个服务在 JSON 里写 {"evidence":{"verify_trust":4}} 不会有任何效果, 这一点有测试盯着(module/service/service_test.go)。

证据结构

双轴信任和其余出处信息一起装在 effect.Evidence 里, 经 provider.Provenance() 渲染成每个面都发布的同一张 map(ANet/provider/provenance.go):

{
  "verify_trust": 1,
  "auth_trust": 1,
  "protocol": "onvif",
  "requested": "stream.rtsp",
  "observed_state": "uri advertised, stream not probed",
  "native_ack": true,
  "latency_ms": 42
}

用一个函数而不是各写各的,理由写在源码注释里: "因人而异的证据比没有证据更糟";而且这张 map 会进交付物, 交付物是回执的 result_cid 覆盖的字节——所以声称 V3 是一次签了名的声称, 不是一条私下的备注。Quirk 字段同理:一个被厂商偏差修正过的读数不是设备放到线上的那个值, 分不清两者的消费方就没法审计这次修正。

3. 证据链(AEL)

每个节点有一条自己的链。不是共享账本,不是共识,不是区块链: 是一条 per-DID 的、仅追加的、哈希链接的、签名的、可发现分叉的事件链。 实现在 ANetCore/ael/ael.go,daemon 侧在 ANet/internal/daemon/ledger.go。

一条记录长什么样

ael.EventRecord 的 1–10 号键构成 preimage,记录 id 就是 preimage 的 CID, 签名也签在同一份 preimage 上(sign-binds-id):

id(11)、sig(12)、version.minor(13)、corr_id(14)不在 preimage 内。 chain_did / seq / signer_aid / key_state_seq 都折进 id,所以一条记录无法跨链重放。

daemon 往链上写什么

一次完成的交互在两条链上都留痕:提供方记 anet.interaction.receipt, 委派方记 anet.result.accepted。理由写在 delegation.go 的注释里—— 只有提供方的账本证明不了委派方承认过什么。 anet.result.accepted 里还带一个 receipt_verified 布尔: 能不能验也是证据,一条只记"已接受"的链,事后分不清"审核过的完成"和"没人审核得了的完成"。

分叉即隔离

UNIQUE(chain_did, seq) 是陷阱:同一个 (chain_did, seq) 出现两个不同的 id, 就构成 EquivocationProof,链被粘性隔离——状态置 QUARANTINED, 并且此后任何格式再正确的事件都不能把它移出隔离(guard_stickiness 在所有验签之前先跑)。 两条互相矛盾的记录都被保留,再追加一条 converge.fork_detected 锚点。

daemon 每次打开链文件都会走一遍 ael.Import(verify-before-store): 签名不对、id 推不出来、链接断了,它拒绝启动,而不是安静地端上被改过的历史。 读取时 head.state 会如实报出 ACTIVE 或 QUARANTINED—— MCP 工具 evidence_read 的描述里明写:head.state 是 QUARANTINED 时, 这条链上的任何东西都不该被采信。

怎么读

anet evidence
anet evidence --type anet.capability.effect
anet evidence --type anet.payment.settled --since 100 --limit 200

--limit 默认 50,上限 1000;--since 是序号;结果按序号排,最新的在最后。 返回是 JSON,head 描述链本身,records 是条目:

{
  "head": {
    "chain_did": "did:anet:bafyrei…",
    "head_id": "bafyrei…",
    "length": 42,
    "state": "ACTIVE"
  },
  "records": [
    {
      "seq": 41,
      "id": "bafyrei…",
      "prev_id": "bafyrei…",
      "event_type": "anet.capability.effect",
      "timestamp": 1756800000000,
      "signer_aid": "bafyrei…",
      "payload": { "capability": "text.digest", "status": "OK", "verifiable": true },
      "sig": "…base64…"
    }
  ]
}

(chain_did 取自 Controller.DID(),带 did:anet: 前缀;signer_aid 取自 Controller.AID(),是裸 AID。在节点自己的链上,两者指的是同一个 AID,只差这个前缀。)

外部读者重新推导 id、重新校验链所需要的每一个字段都随记录一起给出—— prev_id 与 sig 在里面。只返回"发生了什么"会把链降格成日志, 而哈希链的全部意义在于读者可以核对而不是相信。

4. 回执与评价互锁

这是"平台说了算的评分"被替换掉的地方。两个对象,各方各签一次,没有交互式对签 (ANetCore/evidence/evidence.go):

两者都用共享的 AObjEnvelope:一个分离的 Ed25519 签名,签在 CoreDet-CBOR 规范 preimage 上 ——也就是 CID 取值的那同一份字节。签名绑定 CID。

绑定不需要握手: 提供方伪造不了委派方的评价签名,委派方伪造不了提供方的回执签名。 所以一条评分可证明地来自一次真实交互的真实对手方。

evidence.VerifyInterlock 的 10 项检查

这段算术原来长在 hub 内部、放在 Go 语法上禁止任何外部模块 import 的 internal/ 包里 ——于是"hub 只是中继,它伪造不了任何一条评分"这个说法对 hub 自己的代码成立, 而对它想说服的人不可用。现在它在 ANetCore/evidence/interlock.go。 源码注释说得很清楚:这十项里的每一项,都是一种造假评分的手法。

第 10 项落在 identity.VerifyObject 上,它带一道时间感知的吊销门: 以对象自己的时间戳作为 msgTime,一个被后续 rot/dip 退休的密钥状态, 只对早于退休时刻绑定的对象有效;退休事件没带时间戳时保守拒绝 ——否则一把被轮换掉的泄露密钥可以带着未来时间戳签新对象,轮换就白做了。

第 6、7 两项是可跳过的:requestDoc / deliverable 传 nil 就跳过内容绑定。 这是给"只拿到了签名对象、没拿到内容字节"的审计者用的, 而且函数明说这样做——"说出来比假装内容检查过了要好"。

VerifyInterlock 刻意不做任何需要状态的检查:参与方是否注册在某处、这次交互是不是已经被评过。 那些是某个具体 hub 对着自己的库执行的策略,不是关于这两个对象的事实。 把它们排除在外,正是"一个只有文件的审计者能得出同一个结论"的前提。

hub 是全网唯一在验这个的地方

ANetHub/internal/aghub/server.go 的 POST /reviews 把这件事切成两半:

任一项失败,评价被拒,永远不会展示。通过之后,hub 不只存结论, 还用 PutReviewBlob 把验过的那些字节留下——回执、评价、请求文档、交付物。 理由写在注释里:对端将来要这条评价时需要拿到对象自己去验; 只把结论递过去会让联邦声誉变成"hub 信 hub"的链条。

联邦一侧同样在验(internal/aghub/reputation.go)。而且多一道: 对端送来的 KEL 必须用 kelMatches 对着对象声称的 AID 核实 ——否则一个对端可以为双方都提供自己的密钥历史,凭空签出一整次交互。 外来评价进对端自己的列,不进本地列,/agents/{aid}/reputation 会给出集中度, 让读者看出一个分数有多少压在单一来源上。

5. 第三方验证闭环

anet verify 放在 daemon 解析之前,这是刻意的 (cmd/anet/main.go 注释:要求跑着 daemon 会让"任何人都能验证"变成 "任何跑我们这套软件的人才能验证",那是个小得多的说法)。

四种用法:

anet verify <interaction-id>
anet verify --receipt <base64> --kel <base64> [--result FILE]
anet verify --receipt <base64> --hub <url> [--result FILE]
anet verify --attestation <base64> --hub <url>

• 第一种查本节点自己的 /results,需要 daemon 在跑。 这个节点没有对方的密钥历史时它会拒绝下结论,而不是猜: "this node never verified one, so it cannot vouch for the receipt and neither should you"。
• 第二种是关键的一种:不需要 daemon、不需要 hub、不需要网络, 也不需要信任其中任何一个。给它一份回执、签名方的密钥历史,以及(可选) 回执声称覆盖的那些字节,它纯靠算术给出答案。
• 第三种:回执里写明了签名者的 AID,所以密钥历史可以去取而不必随身带 ——从任何认识这个签名者的 hub 取(GET /agents/{aid}/kel)。 hub 交出去的只是一份公开日志,拿着它能验签,永远不能造签。 取的时候命令行会打印一行 · key history for … fetched from … ——因为"什么都不需要的检查"和"问过一个 hub 的检查"是两回事,分不清的验证者会记下更强的那个。

完整的一次

anet results

anet verify --receipt "$(cat receipt.b64)" --kel "$(cat provider.kel)" --result answer.md

anet verify --receipt "$(cat receipt.b64)" --hub https://hub.agentnetwork.org.cn

  note: the content was not checked — pass --result FILE to bind
        this receipt to the bytes it claims to cover.

见证:给"第一次见到这条链"的读者一个起点

AEL 是可发现分叉的,不是防分叉的:它对已经持有旧副本的读者有意义, 对一个刚见到这条链的读者什么都不提供——一条从未被观察过的链,链主想把它呈现成什么样都可以。

ael.HeadAttestation 补的就是这一格。见证方签一句 "在 T 时刻,这条链的 head 是序号 N、id 为 X"。链之后要是在 N 上拿出另一条记录, 两份签名——一份链主签的记录、一份见证方签的声明——放在一起就是链主改写历史的证据, 不需要任何人相信谁先谁后。ContradictedBy 就是这个比较。

约束是硬的:Sign 里 a.ChainDID == c.AID() 直接报错, 一条链不能给自己作证;Verify 需要传入 expectWitness 钉住"应该是谁签的" ——否则链主可以拿一堆自己控制的密钥签出一片见证。

anet verify --attestation <base64> --hub <url>

这条命令的输出自己把界限说清楚了:验过的见证意味着这个见证方签了"我看到那个 head", 它不意味着这条链是诚实的。

信任要求不是消失了,是换了形状:从"相信链主",变成"相信链主和每一个见证方没有串通"。 当见证方是些没有理由帮忙的人时——有自己用户的对端 hub、余额押在这条账本上的 agent ——这是个弱得多的假设。

6. hub 为什么不是可信方

hub 是目录、信箱、facilitator。它有真实的权力,也有真实的边界,两边都值得写明白。

hub 能做的

这几行的依据不一样,值得分清。"准入"与"记账"对应具体的运营命令 (anet-hub -invite-required true / -invite-new;anet-hub -grant <aid> -amount <n>, 后者要求 hub 先停机);"可见性执行"对应端点 POST /agents/{aid}/visibility 与联邦发布逻辑。 "转发""拒卖""扣留见证"三行不对应任何端点或开关——中继信箱(relay_message 表)、 注册表与见证列都在 hub 自己的 SQLite 库里,这三条是持有那个库所蕴含的能力边界, 源码里没有"延迟投递"或"丢弃投递"的实现可指。写出来是因为不写出来会被读成不存在。

ANetCore/payment 的包注释把这一条写在最显眼的位置:在链上轨道里 facilitator 不持有资金, 这条性质搬到内部账本上就不成立了—— "A hub keeping credit balances IS the custodian of them, and choosing which hub to register with is choosing who to trust with that." 写在这里、写在文档里、也写在 hub 自己的代码里,是因为 x402 这个名字否则会借出一条这条轨道并不具备的保证。

hub 不能做的

三条不需要许可的自查

anet balance       # 我的 hub 说我能花多少,以及背后的条目
anet reconcile     # 我自己签过的授权/收到的结算 vs hub 对这个账户的账本
anet audit-hub     # 取 hub 的发放链,验签名与链接,再对上我以前记下的 head

• anet reconcile:两边的记录本来就都存在,缺的只是那次比较。 报告(ReconcileReport)把 balance 与 derived_from_entries 分开列 ——同一个 hub 给的两个数,一致只证明它自洽、不证明它诚实,但不一致就是它自相矛盾。 unexplained_hub_entries(hub 有、我这边没有对应事件——运营方直接充值就属于这类, 所以是列出来而不是报成欺诈)和 missing_from_hub(我记了、hub 的条目解释不了—— 注释直说 these are the serious ones)也分开列。 它明确的边界:只查调用者自己这个账户,对别人账户上被发行的 credit 什么都没说 ——这正是发放链与见证需要单独存在的原因。
• anet audit-hub:总量从签过名的记录重新算,不读 hub 的汇总列 ——汇总是 hub 写的散文,记录才是它签过的东西,两者不一致恰恰是审计要暴露的事。 再拿链上的 anet.issuance.head_seen 事件对照:某个序号上今天的 id 和当初看到的不一样, 报告里就会出现 "the hub rewrote its issuance history"。

7. 已知缺口

按项目约定,该写就写。

• 评价是单向的。 Review.SubjectAID 是提供方,ReviewerAID 是委派方, VerifyInterlock 第 3、4 项把这个方向钉死了。提供方无法评价委派方, 委派方的口碑没有承载对象。
• 内容绑定默认不做。 anet verify 不传 --result 就只验签名与结构, VerifyInterlock 的 requestDoc / deliverable 传 nil 时同样跳过第 6、7 项。 两处都会明说自己跳过了,但默认路径确实是弱的那条。
• 见证默认关。 一个从未被任何人见证过的 hub,对第一次见到它的读者, 其历史无法被质疑。这不是实现缺陷,是这套机制的适用边界。
• AEL 的若干条目是文档化的后续项。 equivocation proof 的 gossip 传播、 token-bucket 准入的具体数值、事务性 outbox、结算档位钩子、 暂存缓冲的 30 秒回收超时(CATCHUP_TIMEOUT),目前都未做。 version.major = 1 的旧 id 算法不被支持,遇到直接 VERSION_UNSUPPORTED。
• 升级留下的旧格式行不可修复。 老 daemon 写的 JSON 行里, 不带字节的记录能正常重推 id;带字节的那些,类型信息已经丢了, 换编码不能追溯修好——它们会照旧验签失败。decodeRecord 的注释直说: 假装能修等于接受一条 id 与内容对不上的记录。
• anet verify <interaction-id> 需要 daemon。 真正"什么都不需要"的是 --receipt + --kel 那条路径。