链上的煤矿金丝雀：ERC-801 用一个 isAlive 函数传递坏消息

矿工会带一只金丝雀下井，鸟倒下的那一刻就是撤离信号。软件业借用这个意象造了警示金丝雀一词：公开声明我一切正常，若声明停止更新，请把沉默本身读成坏消息。ERC-801 把这套逻辑搬上链，给金丝雀合约定了个极简标准。它创建于 2017 年 12 月 16 日，仓库记录状态为 Stagnant，作者署名 ligi。

三个函数一个事件

接口小得可以背下来。isAlive 返回布尔值，语义是金丝雀是否被按时喂养过——喂了，还活着；getBlockOfDeath 返回它死在哪个区块，合约还活着时调用会直接抛错；getType 返回金丝雀的类型编号：1 是最朴素的纯接口实现，2 到 6 分别预留给了单一喂养者、单一喂养者加坏粮、多喂养者、必须全员喂养、物联网联动等扩展方向，具体规则当时的文本只写了待定占位。事件只有一个 RIP，在金丝雀死亡后的第一次合约调用时触发。

沉默怎么变成信号

标准本身不定义死亡，死亡藏在喂养节奏的实现里：合约逻辑规定每隔一段时间必须有人喂一次，超时没喂，isAlive 自动翻成否。于是坏消息的传递不需要任何一方主动宣布——声明方只要继续正常生活，信号就是活着；一旦他出事、被要求闭嘴或者跑路，喂养断供，链上状态自己变脸。相比让项目方写一句我们会按时披露，把信任锚定在你无法伪造的时间流逝上，被动信号的性质让作伪成本高得多。这也就是为什么标准的动机一栏设想它被保险合约、报警机器人、状态可视化面板直接调用。

为什么没能普及

类型表里的几个档位也透露出当年的想象空间。单一喂养者版就是最常见的模型：项目方定时喂一次，观察者盯 isAlive；带坏粮的变体在接口上预留了区分正常喂养与异常喂养的能力，相当于把喂养记录本身纳入可验证范围；多喂养者版要求凑齐多人签字才算活着，更接近理事会签名的场景；物联网联动版则设想由传感器数据直接喂养，让物理世界的事实成为声明的凭据。RIP 事件的设定同样讲究：死这件事发生时无需广播，下一个调用合约的人触发事件、日志落链，监控机器人各取所需。这套设计的内核是把死亡做成去中心化的被动广播——声明方既不能悄悄死，也不能悄悄活，两种状态都要留下统一的链上足迹。正因为接口承诺太干净，落地的难处也被照得清楚：干净信号需要有人长期按时喂养并支付成本，这恰是链上激励最难兑现的部分。

读到这里可以总结这份停摆标准真正教会读者的：一个可信信号的价值不在它宣称了什么，而在它不宣称时会发生什么。isAlive 的设计全部力气花在这句话上——沉默自动变成坏消息，因此喂养节奏就是信号寿命。你今天在链上见到的所有持续型承诺，定期授权轮换、每季度透明度更新、按期审计续约，都隐含同一只金丝雀：判断它值不值得信，永远先问喂养周期是多少、断供多久后信号翻脸、以及有没有独立的 isAlive 可以被任何人查询。三问有一个答不上，那份声明就没有按 ERC-801 的诚实程度工作。

这条路线最终没有长成基础设施，原因是多重的：喂养动作本身要付 Gas，长期持有喂gas 的耐心是个不现实的指望；现实需要监控的是复杂事实而非一只鸟的死活，储备金、审计、托管这些更值得盯的指标各自长出了更专门的标准；同时金丝雀语义暧昧，活着不等于没问题，很多误读发生在把信号当担保的地方。今天读 ERC-801，价值在于借它校准一个判断习惯：凡是依赖我会持续更新这类承诺的风险声明，都该问一句多久没更新算出事、谁来判定没更新、我用什么独立渠道复核——三个问题答不上的声明，接近于没有声明。本文为机制说明，不构成任何投资建议。