钱包在支付页显示”这笔约合多少美元”,数据从哪来?现实里每家钱包各自对接不同行情源,接口形状五花八门。BIP-171 是 Luke Dashjr 在 2017 年 3 月写的解法:给”行情查询”这件小事定义一个公共接口,四种 GET 请求、JSON 返回、一行一个结果。提案状态 Closed,从未被服务商普遍采纳,但作为一份”最小接口设计”的样本,它比大多数商业文档都干净。
先定词。货币代码沿用 ISO 4217,超出三字符的可自造;比特币侧单位统一写 XBT,定义为一亿聪,哪怕界面显示用 BTC 或 mBTC,接口层一律换算成 XBT——提案里还留过一句FIXME,争论要不要直接用聪,可见定标准的难处就在这些单位细节。货币对令牌是不超过 255 字符的字符串;汇率定义为”一单位基准货币可换多少计价货币”,方向写死在文档里。传输是标准的 application/x-www-form-urlencoded GET,多条结果用换行符分隔(只许 LF 不许 CR),计费订阅可用标准 HTTP 认证,并且建议上 TLS 或 Linked Data Signatures,防中间人伪造报价。
四种模式各管一问。mode 为 list 时枚举服务器支持的货币对,可用 quote 和 base 参数过滤,参数值还能逗号分隔填多个,含义是”任一满足”;mode 为 info 查询某货币对的元信息;mode 为 rate 拿当前汇率,可一次问多个货币对,响应逐行对应;mode 为 history 拉历史序列,用 period 参数(如 hour、day)分档。合规要求只有一句:服务器至少要支持一个以 XBT 为基准或计价方的货币对。整套规范没有一个字段是多余的——它刻意维持”任何脚本用 curl 就能对接”的复杂度。
它为什么停摆?行情服务是有商业竞争的领域,接口标准化意味着比价成本下降、转换成本下降,服务商的动力天然不足;而钱包方各自签了商业协议,也没有统一诉求。加上 2017 年之后行情数据的主流入口转向交易所 API 与聚合预言机,预言机那一侧演化出了完全另一套”链上喂价”范式(带心跳、阈值与去重机制的链上合约接口),和 BIP-171 这种”链下 GET”根本不在一个世界。生态位被填满后,提案自然关闭。
但设计上的取舍仍然可复用。XBT 定死最小货币单位这一手,规避了”报价时小数位不同引发一分钱差错”的经典事故,和比特币协议内部一律用聪计数的纪律同构;“一行一个 JSON”的流式设计让慢速历史接口可以边生成边推送,比一大块 JSON 省内存;“任何参数可多值、语义为或”的约定,省掉了批量接口的另一套语法。反过来,它没解决的也要看清:报价的时戳与新鲜度、来源签名格式、失败与降级的错误语义,提案都只给了建议,这些恰恰是今天预言机领域花大力气标准化的部分。
常见误区有三。其一,以为 BIP-171 规定比特币价格本身:它只规范查询接口的形状,价格来自服务方自己的市场数据。其二,以为 XBT 是另一种币:它只是 1 BTC 的 ISO 风格代号,与聪严格等值。其三,把它和预言机混为一谈:预言机服务的是链上合约,数据要上链、要防伪、要防延迟操纵,BIP-171 服务的是链下客户端展示,信任模型完全不同。
快速问答。问:今天有没有事实标准?答:没有跨行业统一标准,主流做法是各交易所私有 REST 接口加聚合层,应用侧自己维护适配矩阵。问:自研钱包该参考它吗?答:作为接口形态的参考仍然好用,但生产使用要补上缓存、时戳与多源比对,这些正是提案留白处。
最后做一次横向盘点,把这份小接口放回它想解决的链条里。一个显示汇率的钱包从查询到展示要过五道关:选源(用哪家报价)、取数(接口形状)、换算(单位与小数位)、缓存(多久问一次)、兜底(源挂了显示什么)。BIP-171 只规范化了第二道关,并且刻意不碰其余四道——这种克制是它的优点也是它的极限:接口形状统一并不能自动带来数据可信,取数之后的每一步仍然各凭本事。今天的应用大体沿着同样的分工演化:行情源是商业合同与私有 API,换算与缓存逻辑在钱包内部,兜底策略在产品文档里。读懂这份提案的正确姿势,是把它当作”第二道关该长什么样”的一种参考答案,而不是一句”行业没有标准”的注脚。
风险提示:行情数据可能延迟或被操纵,展示用途也建议核对时间戳;本文不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。