闪电节点的名片:node_announcement 里的别名、颜色与地址 图 1
闪电节点的名片:node_announcement 里的别名、颜色与地址 · 图 1

节点在地图上立一块牌子

闪电网络里,通道公告(channel_announcement)说明”哪两个节点之间有一条边”,而节点公告(node_announcement)回答的是”这个节点本身长什么样、在哪里听得见”。一条公告的结构是:先放签名与特性字段,然后是时间戳、节点公钥、三个字节的颜色、三十二字节的别名,最后是一段可选的地址列表。别名必须是合法 UTF-8 字符串,多余尾部补零;颜色按红绿蓝各一字节排列——规范原文甚至带着冷幽默地说,这些字段”让运营者可以给节点配上黑色之类的颜色、配上 IRATEMONK 之类的酷名字”,地图工具里的彩色点就源自此。

地址段是一串”类型加数据”的描述符:类型一表示 IPv4 加端口,类型二表示 IPv6,类型三已废弃(曾用于 Tor v2 隐藏服务),类型四是 Tor v3 服务——其编码把三十二字节 Ed25519 公钥、两字节校验和与版本字节拼在一起,校验和取自 sha3(“onion checksum” 拼接公钥与版本) 的前两字节;类型五是 DNS 域名,要求 ASCII 字符,非 ASCII 必须用 Punycode 编码。节点 SHOULD 为每个愿意接受入站连接公网地址各给一条描述符。

闪电节点的名片:node_announcement 里的别名、颜色与地址 图 2
闪电节点的名片:node_announcement 里的别名、颜色与地址 · 图 2

改名片的规则与它的攻击面

同一节点换名片只能朝前不能朝后:时间戳必须大于此前任何一条公告,签名则是对签名域之后全部报文内容做双重 SHA-256 后,用节点私钥产出。这意味着任何实现若同时跑两个进程抢发公告,旧的那条永远排在新的一般之后被处理,网络以时间戳定新旧。

规范还专门写了一段安全提醒:别名是用户自定义文本,构成一条潜在注入通道——无论是渲染到网页、塞进数据库还是走脚本上下文,显示前都应消毒。换句话说,一张名片的颜值字段可能携带跨站脚本,钱包与区块浏览器类工具必须像处理任何用户输入一样处理它。

地图与路由是两条数据线

读节点公告时要把它放回整张图里。闪电的拓扑信息分三层:channel_announcement 声明边存在并锚定到链上出资,channel_update 给出这条边的方向性参数(费率、锁定时间、可转额度上下限),node_announcement 才补上节点自身的样貌与地址。三者独立生效、各自更新,所以地图工具完全能画出一条还没有名片的边——支付路由本身也主要消费前两层,节点公告缺席不等于这枚节点不可达,只是连接它时得靠别的途径拿到地址(比如早前建过通道留下的记录)。反过来,一张光鲜的名片也不能替代边的合法性:所有公告都要过验签与链上核验,虚构的出资立刻现形。

由此得到一条日常判断线:看到节点”从地图消失”,先分清是哪层数据过期。时间戳驱动的新旧替换意味着任何一条公告只有更大的时间戳才压得过旧的;若某个节点的两个进程误发旧公告,网络会照规则接受较大时间戳那条,看起来就像”名片回滚了”。钱包与区块浏览器类工具应在展示前处理缓存的新旧比对——显示层出错时,链上和图上的事实并没有变。

快速问答

问:不发 node_announcement 的节点收不到付款吗? 答:不是。公告只是可选的自我展示;不开公告的节点照样能建通道,只是在公开的节点地图上缺少一张名片。

问:为什么我看到同一个节点的公告被更新,别名却变不了? 答:更新合法,但时间戳必须更大且重新签名;若你的工具缓存了旧记录且没做时间戳比对,就会停在旧名片上——这是显示层问题,不是网络不接受更新。

问:Tor-only 节点在地址字段里放什么? 答:放类型四的 onion 服务描述符;若实现用内存 DNS 记录发现过主机名,也可能带类型五条目。

风险提示:闪电节点运营涉及资金与路由风险,展示信息亦可能被滥用,请遵守当地法规;本文不构成投资建议。