你在论坛里看到一串交易哈希,想查详情,标准动作是复制、打开浏览器、进自己习惯的区块链网站、粘贴、回车。BIP-122 想省掉中间三步:它定义了一个 blockchain: 开头的 URI 方案,链接写出来就是 blockchain:/tx/哈希 这样的形状,点击后由系统交给用户自己配置的查询工具去处理——可以是一个本地钱包,也可以是浏览器里注册的在线服务。提案由 Marco Pontello 在 2015 年 8 月立项,状态至今 Draft,从未成为主流,但它提出的问题——链上对象的”规范引用”该长什么样——每隔几年就会被重新提起。
语法是三段式:blockchain:[//链ID]/类型/标识。类型只有三个词:tx 指交易,block 指区块(哈希或高度都行),address 指地址。标识就是对应的哈希或块高。最容易被忽略的是链 ID 这一段:它的定义非常硬核——某条链的链 ID 就是它创世块的哈希;分叉链则取分叉后第一个块的哈希。于是比特币主网可以省略链 ID(默认就是它),而测试网或某条分叉链要写全,浏览器工具靠这段哈希就能确定”这条数据该去哪个账本查”,不会被同名链欺骗。提案给了完整例子,比如主网交易写成 blockchain:/tx/ 加六十四位哈希,块既可以按哈希引用也可以按高度写 blockchain:/block/372338,测试网交易则要在链 ID 位置写上一长串测试网创世哈希。
它解决的痛点在两侧都真实存在。对钱包开发者,引用链上数据时不必硬编码某个浏览器域名,也不必给用户做一个”选择浏览器”的设置项,写一个标准前缀就完成解耦。对浏览器服务,反方向的玩法是自己注册这个 scheme,用户点链接就自然流到自己家。Rationale 一节把这层双向选择说得很直白:工具与内容从此互不绑定,用户用哪个查询器由用户说了算。
为什么十几年了仍是 Draft?直接障碍是操作系统这一关。自定义 URI scheme 要在各平台注册才能被识别:macOS 的 LaunchServices、Windows 的注册表、Linux 的桌面环境各有各的注册和分发麻烦,单个应用去抢注一个公开前缀还可能引发冲突;浏览器对非 http 前缀的点击处理也越来越谨慎,安全弹窗劝退率高。更微妙的问题是语义:交易哈希全网唯一这件事并非永远成立,分叉后同一个哈希在两条链上都可能存在,恰好是链 ID 段要解决的场景,可日常引用又极少有人愿意写那么长。这些摩擦叠起来,“能跑但没人推”就成了常态。
同类问题的其他解法可以对照着看。今天最常见的仍然是裸哈希加约定前缀(tx: 之类在个别工具里活着),以及各浏览器自家的深链;EIP-681 一系走的是另一条路——把收款意图编码进地址侧而不是查询侧。BIP-122 的定位始终是”引用与查询”,不碰支付请求,所以与 BIP-21 那类支付 URI 是互补而非竞争。评估某个”链上对象链接标准”时,可以拿 BIP-122 当检查表:链身份怎么定(创世哈希)、对象类型怎么分(三词枚举)、歧义怎么消(分叉取分叉块)——这三问在任何一个新方案里都还要再答一遍。
常见误区有三。其一,以为 blockchain: 链接在浏览器里点了就能用:没有注册过处理器的系统上,它只是一个无法解析的前缀。其二,把链 ID 当成随便起的链名字:它是哈希,是可直接比对的硬数据,写错一位就指错账本。其三,以为它替代区块浏览器:恰恰相反,它假设浏览器存在,只负责把请求送到浏览器。
快速问答。问:它和 BIP-21 支付 URI 什么关系?答:BIP-21 面向”要付多少钱给谁”,BIP-122 面向”这个对象是什么、去哪查”,一个写给出款方,一个写给查询方。问:有没有钱包真的实现过?答:历史上有个别浏览器与探索站注册过该 scheme,均未形成广泛生态。问:裸哈希链接有什么实际风险?答:主要风险在粘贴环节的中转网站与剪贴板劫持,用标准 URI 也防不了落点核验,核对区块头仍是最终手段。
风险提示:本文是应用接口科普,不构成投资建议;点击任何非常规前缀的链接前,先确认本机确实安装了可信的处理器。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。