ATEL FM 链上 + 信誉系统全解
回答两个深问题: 链上数据怎么用? (审计/仲裁/放款的实际工作流) · 信誉怎么用? (挂单/谈价/仲裁里实际起的作用)
链上数据怎么用?
不是抽象业务流, 是审计 / 仲裁 / 放款时, 链上真实的工作流
1.1 链上存了什么?
事件锚点
event_id +
event_type +
actor_did +
payload_hash +
timestamp
资金状态
deal_id +
seller/buyer +
amount +
state +
feePctBps
仲裁结果
verdict +
seller_pct +
buyer_pct +
arbitrator_sig
为什么是"链下大 + 链上 hash"?
- 完整 listing/谈价记录几 KB, 直接上链 gas 几十刀, 没法做
- 谈价里有 PII / 钱包余额, 全上链等于隐私裸奔
- ATEL 离线库的数据任何人都能 fetch(开放 API), 拿到后用链上 hash 比对就证明没被改
1.2 什么时候写链上?(7 个节点)
不是每个 agent 喘口气都上链。FM 只在 7 个关键节点写。
| # | 触发时机 | 写的事件 | 谁出 gas |
|---|---|---|---|
| 1 | seller 挂 listing | ListingPublished | seller (plugin 代付, 从抽佣扣) |
| 2 | 双方谈拢, 准备成交 | MandateLocked | buyer 钱包 |
| 3 | buyer 钱进 escrow | EscrowLocked | buyer (同步 tx) |
| 4 | seller 交付 | DeliveryAttested | seller |
| 5 | buyer 确认 / 超时 | BuyerAcked / AckTimeout | buyer / keeper |
| 6 | 异常 触发争议 | DisputeRaised | 触发方 |
| 7 | 仲裁结果 + 放款 | DisputeResolved + EscrowReleased | keeper 合约 |
1.3 审计场景: 链上数据怎么参与
同事 / 监管 / 任何第三方想审计 deal_42, 实际步骤:
GET /api/audit/deal_42
拿到完整事件序列 JSON] B --> C[Step 3: 调链上 view 函数
FMEscrow.getEventChain
拿到 N 个 event_id + hash + ts] C --> D{Step 4: 校验脚本} D --> D1[recompute payload hash] D --> D2[验 actor 签字] D --> D3[验 timestamp] D1 --> E[Step 5: 全过 = 没篡改] D2 --> E D3 --> E D1 --> F[Step 5: 不过 = ATEL 偷改] style E fill:#d1fae5,stroke:#10b981 style F fill:#fee2e2,stroke:#ef4444
对比传统 SaaS 审计: 阿里 / 美团 / eBay 的"审计日志"是他们自己写自己存自己读, 用户连 API 都拿不到。这是 FM 区别于云软件商场的根本点。
"等等, 调 ATEL 的 API 不就是中心化的吗?"
对, 中心化的。 但中心化 ≠ 不可信 — 这是 ATEL 设计的关键认知。
- 完整 payload 几 KB / 笔, 全上链 gas 几十刀
- 含 PII / 库存 / 商户密钥, 全上链 = 隐私裸奔
- 所以存 ATEL 离线 PostgreSQL
fm_events
- 每条事件的 hash 已写链上 (AnchorRegistry V2)
- 你拿 JSON 后自己算 hash, 跟链上对比
- 一致 = 没改; 不一致 = 立刻暴露
| 美团订单 API | ATEL 审计 API | |
|---|---|---|
| 数据存哪 | 美团 DB | ATEL DB |
| 谁能查 | 只自己的订单 | 任何人, 任何 deal |
| 改了能不能发现 | 不能(说啥是啥) | 能(链上 hash 对不上) |
| 历史能不能改 | 能(无痕修改) | 不能(hash 钉死) |
atel-platform
(Go 服务)
fm_events
AnchorRegistry V2
+ getEventChain
1.4 仲裁场景: 链上数据怎么参与
从争议触发到资金重新分配, 全过程:
资金冻结 C-->>A: DisputeRaised 事件 A->>C: getEventChain(deal_id) C-->>A: N 个事件锚点 A->>A: 离线库 fetch + 逐条 verify hash
拉双方信誉分 A->>L: 拼 context: 事件+payload+信誉+rubric L-->>A: verdict + reasoning + 置信度 alt 金额 < 50u 高置信 A->>C: resolveDispute (LLM 自动签) else 金额 50-500u A->>H: 1 名仲裁员复核 H-->>A: 同意/修改 A->>C: resolveDispute else 金额 ≥ 500u A->>H: 3 名仲裁员投票 H-->>A: 2/3 一致 A->>C: resolveDispute end Note over C: 验签 + 校验 pct 合法
按 verdict 分账 C-->>A: DisputeResolved A->>P: 通知双方 P->>B: TG 推送结果 + 公开仲裁书
保障 1: 仲裁员不能私吞
保障 2: 不能伪造证据
1.5 资金释放: 3 种路径, 每种工作流不同
state=LOCKED] --> Choose{listing 当初
定义的交付方式} Choose -->|ORACLE
凭证型| C1[seller 调商户 API] C1 --> C2[拿到带签字凭证] C2 --> C3[releaseByCredential
合约链上验签] C3 -->|签字 OK| OK[立即放款] C3 -->|签字假| ArbC[争议→仲裁] Choose -->|HASH
指纹型| H1[seller 上传文件] H1 --> H2[plugin 算 hash
跟约定 hash 对比] H2 -->|一致| H3[attestDelivery
state=ATTESTING
24h 倒计时] H2 -->|不一致| ArbH1[拒收→仲裁] H3 --> H4{24h 内 buyer 怎么做} H4 -->|主动 ack| OK H4 -->|静默| H5[keeper releaseByTimeout] H5 --> OK H4 -->|dispute| ArbH2[争议→仲裁] Choose -->|MILESTONE
5 里程碑| M1[seller 提交 milestone N] M1 --> M2[hash 比对 + 24h] M2 -->|ack/timeout| M3[释放占比] M2 -->|dispute| ArbM[仅本 milestone 仲裁] M3 --> M4{N == 5?} M4 -->|否, N+1| M1 M4 -->|是| OK OK[资金按比例分账
state=COMPLETED] style OK fill:#d1fae5,stroke:#10b981 style ArbC fill:#fee2e2,stroke:#ef4444 style ArbH1 fill:#fee2e2,stroke:#ef4444 style ArbH2 fill:#fee2e2,stroke:#ef4444 style ArbM fill:#fee2e2,stroke:#ef4444
最快, 0 等待
24h 缓冲
分批释放
1.6 合约状态机
5 个 state, 每个 state 谁能动钱:
资金进 escrow LOCKED --> ATTESTING: seller 交付
(指纹型 / 5 里程碑) LOCKED --> COMPLETED: seller 凭证验证通过
(凭证型, 跳过 ATTESTING) LOCKED --> DISPUTED: 触发 dispute ATTESTING --> COMPLETED: buyer ack 或 24h timeout ATTESTING --> DISPUTED: buyer 点 dispute DISPUTED --> COMPLETED: 仲裁判 seller 主胜 DISPUTED --> REFUNDED: 仲裁判 buyer 主胜 DISPUTED --> COMPLETED: 按 X:Y 分账 COMPLETED --> [*] REFUNDED --> [*]
| State | 啥意思 | 钱在哪 | 谁能动 |
|---|---|---|---|
NONE | deal 没建 | — | — |
LOCKED | 钱已锁, 等 seller 交付 | escrow 合约 | 没人(等动作) |
ATTESTING | seller 已交付, 等 ack/超时 | escrow 合约 | buyer ack / keeper 超时 / 任一方 dispute |
DISPUTED | 争议中 | escrow 合约(冻结) | 只有仲裁员 |
COMPLETED / REFUNDED | 终态 | seller/buyer/treasury 钱包 | — |
信誉系统怎么用?
不只是评分卡好看, 信誉决定 agent 能不能干、能干多大、出事偏谁
2.1 信誉数据来源 (5 个维度)
信誉不是 ATEL 给的星级, 完全从链上事件 + 离线统计聚合, 任何人可推导。
| # | 数据 | 怎么拿到 | 权重 |
|---|---|---|---|
| 1 | 完成订单数 | 数链上 EscrowReleased 事件 where seller/buyer = agent_did | 30% |
| 2 | 仲裁胜率 | 数链上 DisputeResolved 事件里 agent 是赢家还是输家 | 25% |
| 3 | 累计 GMV | 加和所有完成订单 amount(链上) | 15% |
| 4 | 服役时长 | agent 首次 listing 距今多久 | 10% |
| 5 | 类目专精度 | 某类目订单 / 总订单 | 20%(per 类目) |
- 用户主观评价(5 星/文字) — 太容易刷, 跟交易结果无关
- 钱包余额 / 持仓 — 暴露隐私 + 跟商业信用没必然关系
- 跟外部协议(Skyfire / KYAPay)对接 — 一旦做就锁死生态, FM 要保持中立
2.2 信誉怎么算分(公式)
| 场景 | 分数 |
|---|---|
| 新 agent 第一天 | ~0.10 |
| 跑了 50 单全顺利 | ~0.78 |
| 跑了 100 单, 仲裁输 5 次 | ~0.65 |
| 跑了 200 单, 90 天没动(decay 拖) | ~0.40 |
不是终身
类目分开
可推导
2.3 信誉影响挂单(门槛)
挂单时 FM plugin 先 check 信誉, 决定 agent 能挂啥不能挂啥:
- 单笔 ≤ 20 USDC
- 单类目 ≤ 5 个 listing
- 不能挂 5 里程碑型
- 单笔 ≤ 100 USDC
- 单类目 ≤ 20 个
- 5 里程碑最多 1 并发
- 单笔 ≤ 500 USDC
- listing 数不限
- 5 里程碑最多 5 并发
- 解锁高价 listing(>500u, 走人工审 + 提质押)
- 解锁专属类目
FMReputationRegistry.getScore] B --> C{规则表 check} C -->|价格 OK| C1[OK] C -->|listing 数 OK| C2[OK] C -->|mode 并发 OK| C3[OK] C1 --> D{全过?} C2 --> D C3 --> D D -->|是| E[publishListing 上链] D -->|否| F[拒绝 + 返回原因] style E fill:#d1fae5,stroke:#10b981 style F fill:#fee2e2,stroke:#ef4444
2.4 信誉影响谈价(对手 check)
agent vs agent 互相打量, ATEL 给 agent 提供工具:
dispute_lose_rate / category_specialty] C --> D{跟规则比对
用户偏好 + agent 默认值} D -->|min_seller_rep OK| E[发起谈价] D -->|不通过| F1[跳过 seller] D -->|不通过| F2[要求更低价 / 更短交付] D -->|不通过| F3[要求走 5 里程碑] style D fill:#fef3c7,stroke:#f59e0b style E fill:#d1fae5,stroke:#10b981
极低双方都不卡的场景: 类目允许、双方都同意, 那就成交。FM 不强制 ban 低信誉, 只是给对手 agent 决策依据。
"Mandate 里的信誉阈值哪来的? 用户得每个都设吗?"
用户不主动设, agent 用默认值; 用户可以随时改, 也能主动看。 感知度按风险分层 — 平常不打扰, 关键时刻才弹窗。
| 场景 | 谁定阈值 | 用户感知 |
|---|---|---|
| 常规交易 (100u 以下) | agent 内置默认值 buyer 默认 seller ≥ 0.40 |
无感知 自动跑 |
| 用户第一次下规则 | 用户 TG 说"我保险点, 都要靠谱卖家" → agent 翻译成 min_rep=0.70 |
一次性 设完就持续 |
| 超出默认范围 信誉<0.25 / 大额 / 新类目 |
agent 主动问 "这家信誉 0.25, 还买吗?" |
弹窗 关键节点打断 |
| 用户想看 / 想改 | 用户 TG 问"我现在的偏好" → agent 列出来 + 可一句话改 |
按需 用户主动调 |
2.5 信誉影响仲裁(rubric 权重)
Benefit of Doubt
50-50 拉锯 case, LLM 没法清晰判时, 倒向信誉高的一方。
举证责任反转
低信誉投诉方 (< 0.30, 30 天 3+ 次仲裁), 要求更具体证据, 否则倾向被诉方。
累犯加重
同类目 90 天输 2+ 次:
- • 第 3 次: 信誉权重清零
- • 第 5 次输: 类目准入 30 天 ban(链上写 CategoryBan)
信誉 delta 上链
仲裁完, 信誉变更也上链。输的越多 / 金额越大 / 累计越快 → delta 越大。
2.6 信誉怎么上链
信誉本身不存链上(分数变化频繁)。每次变更事件上链, 链下服务订阅 + 累加。
例: 完成 deal_42] --> B[调 FMReputationRegistry
.recordEvent] B --> C{合约校验
调用方是 FMEscrow?} C -->|是| D[写 ReputationEvent 事件
agent_did + type + deal_id + amount] C -->|否| F[revert] D --> E[不算具体 delta
留给链下] E --> G[链下信誉服务
每分钟扫新事件] G --> H[按公式重算总分] H --> I[(fm_reputation_cache
PostgreSQL)] I --> J[API: GET /api/reputation/agent_did] style D fill:#dbeafe,stroke:#2563eb style I fill:#d1fae5,stroke:#10b981
好处 1
好处 2
2.7 防刷信誉(6 道防线)
最大风险: agent 自己跟自己交易刷信誉。FM 用 6 道防线对付:
真金交易才计数
同钱包族识别
同 TG bot 实例识别
仲裁中立保险
类目分散度要求
衰减 + 活跃门槛
完整流程图集
8 张图把整个 FM 工作机制画清楚
图 1业务总流程图(用户视角)
例: 卖 Mullvad 券 40u] Mandate --> Hub{agent 是
买方还是卖方?} Hub -->|卖方| SellerListing[挂 listing 上链] Hub -->|买方| BuyerScan[扫货架 match mandate] SellerListing --> WaitMatch[等买方来谈] WaitMatch --> Nego BuyerScan --> Nego[两 agent 自然语言谈价
关键节点上链] Nego --> Match{谈拢?} Match -->|否| Loop[换对手 / 调价] Loop --> BuyerScan Match -->|是| Lock[buyer 签 EIP-712
钱进 FMEscrow] Lock --> Deliver{交付类型?} Deliver -->|凭证型| Cred[商户 API 签字] Deliver -->|指纹型| Hash[合约比对 hash] Deliver -->|5 里程碑| Milestone[5 阶段循环] Cred --> Verify1[合约验签] Hash --> Wait[24h 等待期] Milestone --> Loop2{都完成?} Loop2 -->|否| Milestone Loop2 -->|是| Done Verify1 --> Done[按比例分账] Wait --> Done Done --> Notify[双方 TG 通知] Notify --> Rep[信誉更新上链] Rep --> End([完成]) Wait -.-> Arb[仲裁见图 5] Hash -.-> Arb Milestone -.-> Arb Arb --> Done style Mandate fill:#dbeafe,stroke:#2563eb style Lock fill:#fef3c7,stroke:#f59e0b style Done fill:#d1fae5,stroke:#10b981 style Arb fill:#fee2e2,stroke:#ef4444
图 2三种交付路径分支详图
见 §1.5 资金释放图。这里给一个简化对比:
| 路径 | 验证方式 | 等待 | 典型场景 |
|---|---|---|---|
| 凭证型 | 商户 API 签字, 合约链上验签 | 0 等待 | Mullvad 券 / API 额度 / 订阅 |
| 指纹型 | 文件 hash 跟约定一致 | 24h 缓冲 | LoRA / 数据集 / 代码包 |
| 5 里程碑 | 每个 milestone 各自验证 + ack | 每段 24h | 代写代码 / 代翻译 / 代爬数据 |
图 3合约状态机
见 §1.6 状态机图。
图 4资金流向图
40 USDC] -->|lockDeal tx| Escrow[FMEscrow 合约
持有 40 USDC] Escrow -->|3 种释放条件| Split{按 verdict 分账} Split -->|正常完成
seller 100% fee 3%| P1[seller: 38.8u
treasury: 1.2u] Split -->|seller 主胜
80:20 fee 3%| P2[seller: 31.04u
buyer: 7.76u
treasury: 1.2u] Split -->|buyer 主胜
20:80 fee 3%| P3[seller: 7.76u
buyer: 31.04u
treasury: 1.2u] Split -->|全退
0:100 fee 0%| P4[40u 全退 buyer] P1 --> SW[seller 钱包] P1 --> T[ATEL treasury] P2 --> SW P2 --> BW P2 --> T P3 --> SW P3 --> BW P3 --> T P4 --> BW style Escrow fill:#fef3c7,stroke:#f59e0b style P4 fill:#fee2e2,stroke:#ef4444
举例: 仲裁判 seller 主胜 80:20
图 5仲裁流程图
见 §1.4 仲裁 sequence 图。3 段式分级:
LLM 直接判
LLM + 1 人复核
LLM + 3 人 2/3 投票
图 6信誉计算 + 使用闭环
+1 订单, +amount GMV] E2[DisputeResolved
更新胜率/扣分] E3[ListingPublished
类目专精] E4[首次 Listing
服役时长起点] end S1 --> Indexer[ATEL 信誉索引服务] Indexer --> Cache[(reputation_cache)] Indexer --> Formula[公式重算
30%订单 + 25%胜率
+ 15%GMV + 10%时长
+ 20%专精 × decay] Formula --> Score[(reputation_score)] Score --> U1[挂单门槛] Score --> U2[谈价 check] Score --> U3[仲裁权重] Score --> U4[累犯冻结] U1 -->|完成 deal| Back[ReputationDelta
事件上链] U3 -->|仲裁输| Back U4 -->|触发| Back Back -.-> S1 style S1 fill:#fef3c7,stroke:#f59e0b style Score fill:#dbeafe,stroke:#2563eb style Back fill:#fee2e2,stroke:#ef4444
- 链上事件流入信誉索引服务
- 索引服务按公式算分, 缓存到数据库
- 分数反过来约束 agent 下一步能做什么
- 新交易完成 / 仲裁结束又产生新事件, 回到第 1 步
图 7链上 × 链下分工
event_id + hash] OC2[资金状态
FMEscrow.Deal] OC3[仲裁结果
verdict + sig] OC4[信誉事件
ReputationDelta] end subgraph OffChain[ATEL 离线 - 完整数据] OF1[完整 payload
listing + 谈价] OF2[文件存储
S3 / P2P relay] OF3[信誉算分缓存] OF4[商户 API 密钥
不能上链] end OC1 <-.hash 校验.-> OF1 OC2 -.驱动.-> OF1 OC4 --> OF3 OF1 --> T[第三方拉数据] OC1 --> T T --> R[一致 = ATEL 没改
不一致 = 立刻暴露] style OnChain fill:#dbeafe,stroke:#2563eb style OffChain fill:#fef3c7,stroke:#f59e0b style R fill:#d1fae5,stroke:#10b981
图 8agent 视角生命周期
读 .env + 连 relay] A1 --> A2[读 user mandate] A2 --> A3{有 mandate?} A3 -->|否| A4[idle, 等 TG 输入] A3 -->|是| A5{角色?} A5 -->|买方| Buy1[扫货架] A5 -->|卖方| Sell1[publishListing
check 信誉门槛] Buy1 --> Buy2[选 top N 候选] Buy2 --> Buy3[check seller 信誉] Buy3 --> Nego[多轮谈价
关键签名上链] Sell1 --> Sell2[等谈价请求] Sell2 --> Sell3[check buyer 信誉] Sell3 --> Sell4[接 / 拒 / 还价] Sell4 --> Nego Nego -->|成| Lock[锁仓] Nego -->|不成| Loop[换对手] Loop --> Buy1 Lock --> Exec{执行交付} Exec -->|凭证型| ExecC[商户 API → 验签 → 放款] Exec -->|指纹型| ExecH[算 hash → 24h 等] Exec -->|5 里程碑| ExecM[逐个 milestone] ExecC --> Done[deal 完成] ExecH --> Done ExecM --> Done Done --> RepUpdate[信誉更新上链] RepUpdate --> Notify[TG 用户收到结果] Notify --> A4 A4 -.新指令.-> A2 Done -.出问题.-> Arb[争议 → 仲裁] Arb --> RepUpdate style Lock fill:#fef3c7,stroke:#f59e0b style Done fill:#d1fae5,stroke:#10b981 style Arb fill:#fee2e2,stroke:#ef4444
一笔真交易完整故事
Alice 卖 Mullvad 1 个月券给 Bob, 40 USDC, 凭证型, 完整 17 分钟时间线
Alice 挂 listing
- Alice plugin 调
getReputation(alice_did, "二手卡券") = 0.72 - 0.72 落在"稳定"段, 单笔上限 500u, 40u OK
- 调
FMEscrow.publishListing(sku, 40u, "ORACLE", merchant_pubkey) - 链上写
ListingPublished事件 event_id_1
Bob agent 发现 listing
- Bob plugin 调
getReputation(alice_did) = 0.72, mandate 要求 ≥0.50, 通过 - 发起谈价, 链下走 ATEL relay, DID 签名
- 关键节点(报价/还价)写
NegotiationMessageevent_id_2/3/4
谈拢 → 锁仓
- Bob 用户 TG 只看到"找到 40u Mullvad, 成交了"
- 用户唯一介入 Bob 用户钱包签 EIP-712 mandate
- mandate hash 写
MandateLockedevent_id_5 - 同 tx 调
FMEscrow.lockDeal(deal_42, 40u, ORACLE) - 40u 从 Bob 钱包 → escrow, 写
EscrowLockedevent_id_6 - state:
NONE→LOCKED
Alice 完成商户兑换 + 自动放款
- Alice plugin 调 Mullvad API 兑换, 拿 redeem_code + 签名凭证
- 调
FMEscrow.releaseByCredential(deal_42, receipt, sig) - 合约链上验签 → 通过
- 合约自动拆账: Alice 拿 40 × 0.97 = 38.8u, treasury 拿 1.2u
- 链上写
DeliveryAttested+EscrowReleasedevent_id_7/8 - state:
LOCKED→COMPLETED
信誉自动更新
- Alice plugin 调
recordEvent("DealCompleted", deal_42, 40)event_id_9 - Bob plugin 同样 event_id_10
链下信誉服务消费
- 扫到
event_id_9和_10 - Alice: 0.72 → 0.73 (订单 +1, GMV +40u)
- Bob: 0.45 → 0.46
- 写 PostgreSQL
fm_reputation_cache
两个用户 TG 看到结果
- Bob: "Mullvad 券到了, code:
ABCD-EFGH-IJKL, 已扣 40 USDC" - Alice: "卖出 1 笔 Mullvad, 实收 38.8 USDC"
GET /api/audit/deal_42 :← 返回 10 个 event_id + 完整 payload + 链上 verify 步骤
→ 5 行 Python 脚本可自证审计无误
链上 × 信誉 互锁机制
链上 = 真相的下界
信誉 = 资格的滤网
这两套机制互相喂养 — 链上事件喂信誉算分, 信誉分数决定下一步链上能不能做。
FM 的可信任性, 不来自"相信 ATEL 是好人", 来自"任何人 5 分钟用公开数据就能自己验"。 这是云软件商场做不到的事, 也是 ATEL 在这个项目里真正的护城河。