不用合约的广播站：ERC-2848 自发送交易里藏消息

项目方公告发在社交平台，账号会被盗，消息会被删。有没有一种公告，链上身份签名、谁也删不掉、人人可验证？ERC-2848 的答案朴素到反直觉：给自己发一笔零值转账，把消息的指纹塞进交易的 data 字段。标准名叫 My Own Messages，简称 MOM，创建于 2020 年 8 月 2 日，作者 Giuseppe Bertone，仓库记录状态为 Stagnant，不依赖任何智能合约。

一笔合法消息长什么样

规则写成三行：to 必须等于签名者自己的地址——这是自发送，零转账成本；value 必须是 0 wei；data 至少两字节，第一字节是操作码，其后按操作码规定的参数排布。所有参数都被视为必填：缺一个或格式不合，客户端必须把这笔交易整个忽略，并且不得把它记为无效 MOM 交易——标准甚至要求客户端不要费心解析不合格的样本，因为解析他人塞来的数据本身就是攻击面。消息正文不进链，链上只刻内容的 multihash；正文放 IPFS、Swarm 或 HTTP 服务器，客户端 SHOULD 支持多来源取件，但若从 HTTP 服务器下载，必须把字节重新哈希、与声明的 multihash 比对。默认内容类型定为 text/markdown，用别的类型要在界面上明确告警。

反垃圾与反诈骗的设计取舍

Motivation 一节把两类痛点写得很细：不想依赖会被黑的社交网络，也不想给骗子留缝。取舍是明确的——消息要付费上链，贵不贵另说，免费刷屏做不到；任何人都可以给任何人写，但接收方不主动监听就收不到，骚扰面被收窄；没有合约地址要记，也就没有假冒合约可指。代价则是带宽与检索：要读完某个地址的发言，客户端得扫它的历史交易，没有二级索引可用。

对今天的用处

客户端的行为规范同样用词强硬，这些条款拼出 MOM 的防噪骨架。读取端必须为每个受关注的地址维护一份更新后的消息列表，应当能在用户要求时回放完整历史；下载端应当允许用户自选取件来源，在常见内容寻址网络与 HTTP 服务器之间选择，而从 HTTP 取回的内容必须对照 multihash 重算校验——也就是说内容可以从任何服务器拿，真伪却只由哈希说了算。默认正文类型钉死为 UTF-8 无 BOM 的 Markdown 文本，消息若声明其他内容类型，客户端处理时必须向用户亮出警告，默认设置本身也应当告知用户。这些条款的共同气质是把不留余地写进协议：没有可选参数，没有半合法消息，解析不了的不算 MOM 交易而是垃圾。这套宁可窄而不容错的性格，和后来链上元数据普遍的宽容读取形成有趣对照，也解释了为什么做 MOM 客户端容易、让所有人共用同一份消息视图难——规则越硬，各家的合法实现反而越难互相兼容。

这套思路也解释了为什么 MOM 没能长成一条大众协议：它把成本、验证、去信任三条都押在了极窄的实现上，用户要的就是一个开箱即用的消息板，而标准给的是一个要自己懂 multihash 的零件包。今天的读者仍能用它的校验逻辑做一件事：把项目方的公告当作一份 MOM 消息对待——要求公告给出内容哈希、给出上链公证交易、给出取件地址，然后自己重算哈希；三样齐了，哪怕你根本不认识项目方，这份公告与那条链上交易的对应关系也是你自己挣来的，而不是别人告诉你的。

MOM 停在 Stagnant，没有形成客户端生态，但它示范的模式没有死：用自转账交易给一份链下内容做时间戳公证，是零合约依赖的轻量公告方案。项目方今天仍常用一笔自转账给快照哈希或迁移公告签名留证——读这类公告时，套用 MOM 的思路核验三步：交易确实由项目金库或团队地址发到它自己，value 为零，data 或日志里的哈希与官方说明一致。反过来也要清醒：链上写得出哈希，不等于内容发布方值得信任——验证回答的是这份公告与这条交易有关，不是这条交易背后的决定正确。本文为机制说明，不构成任何投资建议。