摘要

  • 2026 年 10 月 18 日查阅时，爱沙尼亚商业登记册中注册号 14476114 对应的页面显示名称为 Puzl Cloud OÜ，并在“Invalid names”一栏列出 GPU Computing OÜ。
  • 承载同一注册号 14476114 的 RIPE 组织对象仍写作 GPU Computing OU，最后修改时间为 2026 年 5 月 13 日。
  • 2026 年 10 月 18 日，自治系统 AS57063 宣告的仍是两周前的那两个前缀：213.5.72.0/24 与 2001:67c:f74::/48。

一个号码，两个名字，并不矛盾

爱沙尼亚商业登记册中注册号 14476114 的那条记录，读起来不像一份公司简介。就 2026 年 10 月 18 日取回的内容而言，爱沙尼亚商业登记册中注册号 14476114 的页面先给出一个名称 Puzl Cloud OÜ，括号内是注册号，再往下有一行字，其篇幅之短掩盖了分量：在“Invalid names”标题下，登记册列着 GPU Computing OÜ。直白地读，这是一个登记册在告诉读者：围绕这家法人流传的若干名称当中，哪一个属于过去，哪一个它已不再视为有效。

这是一句关于名称的、具体且可核对的陈述。它也恰恰是取回片段所确立的全部内容。完整商业登记摘录通常会显示的字段——登记是否有效、公司申报的活动代码、董事是谁——并不在保存下来的文本里，因此本文一概不予断言。对这个论证真正要紧的部分更窄，也更难辩驳：当被问及 14476114 时，登记册回答的是 Puzl Cloud OÜ，并把另一个名字标注出来。

RIPE 数据库对同一个问题给出不同回答。同日以 AS57063 查询，返回四个对象，其中之一是组织对象 ORG-GCO2-RIPE。其 org-name 属性仍写作 GPU Computing OU。国家为 EE，reg-nr 为 14476114，地址是塔林的 Tartu mnt 83-701。其最后修改时间为 2026 年 5 月 13 日，比查阅登记册页面早了约五个月，也比该对象 2020 年 12 月 9 日创建之时晚了五年多。完整响应见AS57063 的 RIPE 数据库记录。

两份文件描述的是同一家法人——注册号完全相同——却给出了不同的现行名称。两者都谈不上明显有错。登记对象记录的是资源授予，不是实时工商信息流；爱沙尼亚登记册记录的是法人，不是路由登记册。它们本就有权彼此不一致，而在这一天，它们确实不一致。

路由记录从来不以名称为键

没有漂移的那部分记录，正是承载流量的那部分。AS57063 的 aut-num 对象，as-name 为 PUZL-AS。它创建于 2021 年 11 月 2 日，最后修改于 2024 年 11 月 8 日。也就是说，自该对象存在之日起，运营方的路由身份就是一个源自“puzl”的字符串，而这份记录比组织对象的最近一次改动早两年半。

角色对象从更早的日期讲述了同一个故事。GCO8-RIPE 名为 GPU Computing OU，共用 Tartu mnt 地址，并带有位于 puzl.ee 域上的滥用报告邮箱——支撑联系层的是域名，而不是公司名称。它的创建时间与最后修改时间完全相同：2020 年 12 月 9 日，比组织对象创建晚一秒，这正是单次注册会话生成多个对象的样子。2020 这个年份值得记住。无论此后工商层面如何演变，基于域名的联系路径在 AS 号被授予之前就已经就位。

而这个 AS 号本身，在任何可见意义上都没有易主。2026 年 10 月 18 日，RIPEstat 的 as-overview 端点返回的持有者为“PUZL-AS GPU Computing OU”，announced 为 true——这个字符串读起来恰好就是 as-name 与 org-name 用空格连接，这正是汇总服务把手上两个字段拼接起来、而非解析现行法人名称时呈现出样子。该端点自身状态为 ok，响应未被缓存，查询窗口为 2026 年 10 月 18 日 16:00 UTC：AS57063 的 RIPEstat as-overview。

只扫过这一层表面的读者，会同时看到这个 AS 号与两个名字，却看不到任何分歧。矛盾只在下一层可见，藏在承载这两个名字的两份源文件里。

两个前缀，一处被明说的盲区

同日可见的运行足迹很小、很稳定，与两周前完全一致。announced-prefixes 端点对 AS57063 返回的正好是两个前缀：IPv4 前缀 213.5.72.0/24 与 IPv6 前缀 2001:67c:f74::/48。两者都只有一条从 2026 年 10 月 4 日到 2026 年 10 月 18 日的连续时间线，响应的 latest_time 为 2026 年 10 月 18 日 16:00 UTC。细节见RIPEstat 的 announced-prefixes 响应。

两个前缀是真实观察，也是有边界的观察，而这个边界由服务自己写明。响应中附有一条提示信息，说明结果会排除可见度极低的路由，具体指被少于十个 RIS 全量对等体看到的路由。这句话作用很大。它意味着“两个前缀”是连接良好的观测点所能看到的景象，而不是某张网络可能经由更细路径宣告的全部清单。把两个前缀当作运营方全部地址空间的人，是越过了同一份文件里写着的提醒。

这些前缀究竟承担什么角色——213.5.72.0/24 承载的是客户流量、内部基础设施，还是服务边缘——并不由一次宣告确立。全局表中的前缀只是在陈述某个源可被到达，仅此而已。

文件无法回答的那个问题

源头授权是顺理成章的下一问，也正是失败的那一问。2026 年 10 月 18 日，RIPEstat 针对 AS57063 的 RPKI 校验端点没有返回任何可用的响应正文；保存下来的响应记录为一次失败取回、摘录为空，不含任何裁决：RIPEstat RPKI 校验响应。

这一点值得说清，因为很容易把两件不同的事混为一谈。一个没有给出结果的校验服务，对“前缀是否已签名”什么都没有说。它说的是：答案没读到。把读不到的端点当成未签名的前缀，或当成干净的前缀，都是在朝读者偏好的方向编造事实。诚实的表述是：截至 2026 年 10 月 18 日，AS57063 的源头授权仍未被读到；而能够定论的那份文件——一份列出覆盖 213.5.72.0/24 与 2001:67c:f74::/48 的资源证书的校验结果——并未取得。

还有一条线索悬着。aut-num 带有一个 sponsoring-org 属性，指向 ORG-SDNS7-RIPE，而本文并未查阅该组织对象。授予记录上出现赞助组织，是关于该资源如何取得的结构性事实，也是比名称字段更能解释一次授予的东西。它的存在有据可查；它的身份则没有。

这种不一致究竟代价何在

容易得出的结论是有人失职。文件并不支持这一点，而一个更平淡的解释更贴合它们。登记对象只在运营方有理由改动时才被改动：更换维护者、更改地址、申请资源。而公司更名是向商业登记机关申报的理由，那是一项带规费和期限的法定义务。这项义务并不产生“去改动一个当时没人读其名称字段的 RIR 对象”的责任。名称字段被搁置是默认状态，不是一项决定。

这种默认状态的代价不由运营方承担，而由下游每一个把名称当作键的人承担。一份供应商台账若登记者一家名字带 GPU 字样的公司，并按该名称去查，就找不到那条工商记录，因为登记册回答的是另一个名字。交易对手若以商号筛查签约主体，就对不上 RIPE 组织对象，因为号码在、名字不在。以公司名称搭建的竞争者地图，会多出一条，或者一条都没有。

便宜的做法并不光鲜，也不依赖任何未读到的文件：以注册号和 AS 号作为记录的键——两者都熬过了更名——并把名称存为带日期的观察，而非标识符：该实体在某日核查时名为 X。号码是稳定的，代码是稳定的，两个前缀至少在所观察的两周内保持不变。名称是会动的那个字段，应当被视为整行里最不具权威性的一列——包括本刊自己的名录条目BTW 关于 AS GPU Computing OU 的名录条目，它继承了更名前的名称，与登记对象所携带的完全一致。