G TRIP·GyID

架构

各部分如何协作

三个角色互相通信:Attester 持有轨迹,验证方计算统计量,依赖方提出问题。跨界流动的只有聚合值。

分层

Attester 端

设备侧 —— 持有轨迹的唯一副本

  • ▸ 在本机生成并保存身份密钥
  • ▸ 在离开设备之前把 GPS 量化成 H3
  • ▸ 逐条签名面包屑并维护本地链
  • ▸ 应答实时挑战、封装 epoch

Verifier 验证方

服务侧 —— 计算统计量,永远看不到坐标

  • ▸ 校验链规则、签名与顺序
  • ▸ 对量化后的网格运行临界性引擎
  • ▸ 通过 WebSocket 驱动主动验证
  • ▸ 按公开策略签发 PoH 证书

Relying Party 依赖方

任何需要确认「你是真人」的一方

  • ▸ 生成 nonce,向验证方索取证书
  • ▸ 用公开的验证方公钥校验证书签名
  • ▸ 只读取统计量——α、β、置信度、信任分

Anchor 锚定

公开存在性证明,刻意保持最小

  • ▸ 把「公钥 → DID 后缀」一次性登记
  • ▸ 存储 epoch Merkle 根,序号严格连续
  • ▸ 存储超过门槛的 handle 声明
  • ▸ 不发币、不存坐标、无代理合约

Workspace 结构

trip-core 协议数据结构、密码学、临界性引擎、锚定编码
trip-server 验证方 HTTP/WS 服务,内存存储
trip-cli(gyid) 命令行:身份、采集、验证、锚定、标定
gyid-shared CLI/网页/移动端共享的业务逻辑
gyid-wasm 浏览器 Attester 桥,由同一份 Rust 核心编译
gyid-web-astro 本站:门户、文档与在线控制台
contracts GeoTITRegistry.sol 及其编译/内存 EVM 工具链
gyid-android 原生 Android 采集端与验证客户端

验证方 API

POST /v1/evidence 提交一批已签名面包屑,服务端校验链规则
GET /v1/identity/:hex 某个 attester 的链头、面包屑数与唯一网格数
POST /v1/verify 创建绑定 RP nonce 的挑战(主动验证)
WS /v1/challenge 实时通道:下发挑战、上传应答
GET /v1/poh/:challenge_id 取回某个挑战已签发的证书
GET /v1/explorer 本验证方已知全部 attester 的聚合视图
GET /.well-known/verifier.json 验证方公钥、策略门槛与公开限制