“两个接口看到的区块高度不一样，风控说不能开提现”
主网暂停后，群里到处有人问恢复时间。真正值得基础设施服务商销售停下来的，是仍未解决的问题、不能重开的业务，以及等待报告签字的人。
重点监测信号
- 团队写出 RPC 高度不一致、索引数据对不上或回滚没有演练等仍未解决的问题
- 提现、充值、转账或发布仍被关闭，并写明恢复前必须满足的条件
- 风控、安全、钱包运营或发布负责人要看报告或测试结果后才签字
08:47，Telegram 里三个群几乎同时亮起来。
“主网停了，有 ETA 吗？”
“钱包是不是都要关充值提现？”
“我们两个 RPC 端点的区块高度不一致。风控拿不到一致性报告，就不开提现。”
先说明：本文出现的群聊、人物和工作场景，全部是虚构的代表性示例，不是任何客户或团队的原话。Ontology 的官方公告是真实来源，群聊只是用来演示销售可能看到什么。
前两条是合理的问题，但大概率仍是新闻问答：问恢复时间，问别人怎么做，答完就散了。第三条不一样。它写出了一个仍存在的问题——两个端点高度对不上；一个不能重开的业务——提现；还有一个等着看报告的人——风控。
如果你卖 RPC、节点运维、监控或钱包与交易所集成服务，这条消息才值得点进去读上下文。
先说结论
- “主网停了，有 ETA 吗？”只能说明大家关注同一事件，不等于有人要采购服务。
- “两个端点高度不一致，提现仍关闭，风控要报告”把故障、业务闸门和验收人放在了一起，可能形成具体工作。
- 恢复出块不等于每个 RPC、索引器、钱包或交易所都已就绪。每家公司都有自己的重开条件。
- 官方的 24 小时说法是附带成功条件的恢复目标，不是保证，也不能直接改写成客户的截止时间。
“重开前”三个字，会改变一条消息的意思
停链期间，群里大多数人都在问网络什么时候恢复。真正值得销售留意的，往往是“重开前”后面的内容：
“重开提现前，两个端点必须给出同一高度和区块哈希。”
“钱包重新开放发送前，手机端要跑完一笔测试交易。”
“升级进生产前，安全团队要现场看一次回滚演练。”
这些仍是虚构示例，但它们比“链什么时候恢复”多了一层公司内部的闸门。即使链重新出块，也有人要拿到证据、看完报告或测试通过后，才会让产品恢复正常。
两份公告，状态发生了变化
8 月 31 日 08:41 UTC，Ontology 发布初始暂停公告。主网立即暂停出块，暂停期间不处理链上交易，持续时间当时未定。公告同时写明：在那个时间点，尚未确认安全事件，也没有用户资产损失或受损迹象。
初始公告记录的是当时掌握的状态；它不能用来证明后续调查没有发现恶意活动。
9 月 1 日 04:54 UTC，Ontology 发布后续安全更新，确认发现了针对网络的恶意攻击活动，主网会在安全响应和网络升级期间继续暂停。同一份公告明确表示，用户资产没有受到影响。
后续公告改变了事件状态，但保留了用户资产未受影响的边界；公告没有公布最终技术根因或点名失败方。
恢复前的工作包括部署网络升级，验证网络完整性、共识和运行稳定性，完成测试，并协调第三方安全机构做进一步评估与验证。官方 X 摘要提到的“未来 24 小时”恢复目标，以所有安全检查、修复和升级程序成功完成为前提。
24 小时是附带完成条件的目标，不是确定重启时间，更不是群里每家公司的重开承诺。
这两份公告没有给出最终攻击路径，也没有说明某家供应商、某个组件或某个验证者失败。销售可以用它们讲清公共背景，不能用它们替客户诊断自己的系统。
真正值得看的是三个问题
什么仍然有问题
“主网暂停”描述的是公共事件。一个团队自己的问题会更具体：
“主 RPC 已到 18,420,510，备用端点还慢 17 个区块。”
RPC 是钱包或应用读取链上数据、发送交易所用的接口。两个端点高度不同，不一定说明某个供应商有故障，也不能证明客户要换服务商；它只是告诉销售，这个团队还没有拿到一致的链上视图。
其他虚构消息也可能是：“浏览器追上了，但充值余额和昨天的快照对不上”，或“节点升级包准备好了，但回滚从没演练过”。关键不是术语多，而是有人说出了哪件事还没完成。
什么业务不能重开
技术问题和业务动作连在一起，信号才会变硬：
“两个端点不一致，风控不开提现。”
“钱包能读余额了，但手机端发送交易还关着。”
链出块后，交易所可能继续观察一段稳定区块；钱包可能先开放余额查询，仍禁止发交易；索引器也可能要追块和对账。每家公司都有自己的重开顺序。
谁要签字
最后看谁说“可以开”：风控签一致性报告，安全团队见证回滚测试，钱包运营批准恢复发送，发布经理在 18:00 前要结果。
负责人出现，不代表发言人本人握有采购权，但至少告诉销售，结果要交给谁。当一条消息同时包含“两个 RPC 不一致”“提现继续关闭”“风控要报告”，它才可能从事件讨论变成一件要完成的工作。
只问一句，别把第一次联系变成审讯
如果两个 RPC 不一致，可以问：
“风控等的是一次高度和区块哈希对比，还是需要观察一段时间再开提现？”
如果交易所提到恢复后观察 200 个区块，可以问：
“200 个区块的规则已经定了、只缺报告，还是团队还在定什么异常会重新计数？”
如果节点升级没有做过回滚演练，可以问：
“现在缺的是安全测试环境，还是一份升级失败后回到旧状态的操作清单？”
这些都是虚构场景下的示例问法。它们只问工作卡在哪里，没有假装从一条群消息就知道正确区块高度，也没有承诺可以批准重开。继续沟通前，还要核实发言人身份、负责团队，以及外部供应商是否获准参与。
状态在变，别犯三个错误
不要把初始公告的“当时尚未确认事件”当成最终状态。后续公告已经确认了针对网络的恶意活动，只转发第一份公告会让你的信息落后。
不要把条件性的 24 小时目标写成客户必须遵守的截止时间。交易所可能等待更久，节点运营方可能更早要完成升级，钱包团队也可能有自己的发布窗口。
不要说用户资产已经损失，不要猜技术根因，也不要把责任推给某家供应商或验证者。所引官方更新明确用户资产未受影响，也没有公布足以支持这些结论的证据。
TOP Prospect 怎么找到那一句
同一个团队的关键信息不一定出现在同一个群。一条消息说“RPC 高度不一致”，一小时后，另一个获授权来源里有人说“风控还不开提现”，第三条又提到 16:00 前要报告。分开看像普通聊天，放回时间和上下文里，才可能看出它们是否描述同一个重开过程。
用户先选择自己有权监控的 Telegram 来源。在 TOP Prospect 里，链名只是起点，更值得保留的是“重开前”“风控签字”“高度不一致”“仍关闭”“没测回滚”“报告几点要”这些贴近工作的说法。系统可以保存命中消息、来源、时间和附近讨论，交给销售人工复核。
TOP Prospect 不能检查节点，不能判断哪个高度正确，不能认证升级结果，也不能验证发言人身份、采购权或外部供应商权限，更不会自动联系对方。
“主网停了，有 ETA 吗？”是一个问题。“两个 RPC 不一致，提现还关着，风控等报告”才是一件可能正在发生的工作。看到后者，停下来问缺的到底是什么。
常见问题
Ontology 第一次宣布暂停主网时，已经确认发生攻击了吗？
没有。初始公告称当时尚未确认安全事件；后续官方更新才确认发现了针对网络的恶意攻击活动。
Ontology 保证主网会在 24 小时内恢复吗？
没有。后续公告写的是条件性目标：所有安全检查、修复和升级程序成功完成后，争取在未来 24 小时内恢复。
TOP Prospect 能确认 RPC、验证节点、钱包或交易所已经可以重开吗？
不能。它只能保存获授权 Telegram 来源里的匹配消息与附近上下文。节点状态、身份、权限、验收结果和供应商准入都需要人工直接确认。
资料来源与延伸阅读
本文由 TOP Prospect 编辑部人工撰写。产品只处理用户明确授权接入的 Telegram 群消息；输出用于辅助销售人工判断，不代替人的决定，也不会自动联系群成员。
值得关注的潜在线索 Signal 是怎样被发现的
了解 Top商业线索怎样发现和整理值得核实的 Signal、保留 Telegram 原始上下文、去掉重复消息并安排查看顺序。是否跟进以及下一步做什么，仍由用户决定。
