合约里也能发公告？ERC-1129 服务公告接口的机制与盲区

代币项目迁移合约、暂停铸造、冻结服务时，公告通常发在官网或社交媒体——中心化、可删改、难以追溯。2018 年 5 月 31 日创建的 ERC-1129 提出了一个方向：让公告直接进合约，用事件日志留痕。按 ercs 仓库记录，这份标准状态为 Stagnant，它当年把测试版部署在了已停用的 Ropsten 测试网上。

两个结构与发帖权限

标准定义两个结构体。Announcer 记录公告发布人：一个布尔的 allowedToPost 决定这个地址有没有发帖资格，一个 name 是人类可读的署名。Announcement 记录公告本身：作者署名 author、作者关联的以太坊地址 authorAddress、正文 post。发帖权限由合约所有者通过 givePostingPermission(地址, 布尔, 署名) 授予或收回；canPost 修饰符挡住没有权限的调用。也就是说，公告系统自带一个小型编辑部，谁能发言写进链上状态。

五个接口与两个事件

查询侧有两个函数：theNumberOfAnnouncements 返回当前公告数（标准注明这是可选项，也可以直接读计数变量）；readPosts(编号) 返回指定公告的正文与作者署名。写入侧：postAnnouncement(正文) 供有权限者发帖，必须触发 NewAnnouncement 事件，带作者与内容；removeAnnouncement(编号, 理由) 移除某条公告，同时重排映射避免空洞，并触发 RemovedAnnouncement 事件——事件里保留作者、原文、移除理由和移除人地址。留意“重排映射”这个细节：条目被删后编号会挪位，先看到的公告后来可能换了序号，靠编号引用公告的做法并不可靠。

设计缺口决定了它的命运

对照后来更成熟的链上声明类方案，ERC-1129 的短板一目了然：公告没有独立编号体系、没有内容哈希，也看不到时间戳字段——时间只能靠事件所在的区块间接推断；正文是自由字符串，无长度或格式约定；删帖合法且会留痕，但留痕依赖节点保留完整历史日志。合约能说明“这个合约的编辑部在某个区块写过什么”，不能说明项目团队的全部承诺，更不能替代合约地址核验——公告系统与真实合约之间没有任何强制绑定。

对今天的读者意味着什么

字段之外：权限、计数与一条已消失的测试链

把方法表读完，能拼出这个系统对“可信公告”的理解方式。公告作者不是地址的别名而是独立角色：Announcement 结构同时存署名字符串和关联地址 authorAddress，人读名字、程序读地址，两条线索并排上链。发帖权由合约所有者用 givePostingPermission 开关式授予或收回，署名字符串在授权那一刻一并登记。计数函数 theNumberOfAnnouncements 被标准自己标为可选——它承认公告数也可以从普通计数变量直接读，函数只是为界面提速的便利贴，这种“接口留余地”的写法在早期 ERC 里很常见。

事件是这份标准真正的承诺：新公告必须触发 NewAnnouncement，移除必须触发 RemovedAnnouncement，后者连移除人地址和理由字符串都要带上——标准建议理由字段用来告诉用户问题是解决了还是下一步是什么。它的测试网部署在 Ropsten 的一个公开合约地址上，而那条测试链早已退役，这个细节多少暗示了标准的寿命。今天重读它，最有用的产出是一套检查清单：看到“链上公告”，先问写进哪个合约、事件由哪个地址触发、那个地址有无发帖权记录，三问都通，公告才具备最低限度的链上可归属性。

它提醒我们：读到“链上可查的公告”时，先确认三件事——公告写进的是哪个合约、你查的事件日志来自不可篡改的节点还是缓存服务、以及署名地址与官方公布的合约所有者是否一致。这三问的成本远低于轻信。本文为机制说明，不构成任何投资建议。