我们强烈建议运行 etclabscore/core-geth 的 Argos (v1.12.23)，切勿切换到
ethereumclassic/core-geth v1.13.0。
2026-09-14，一个名为 ethereumclassic/core-geth 的仓库发布了标记为 v1.13.0 的版本，也就是流氓版本。不久之后，X 上的 @ETC_Network 账号将其作为「Ethereum Classic 安全更新」发布，并告诉节点运营者迁移。同样的文字出现在 CoinMarketCap 的 Ethereum Classic 社区动态中，矿池也收到了来自 ethereumclassic.com 地址的邮件通知，而这并不是社区的域名。
社区网站 ethereumclassic.org 没有更新，长期维护的 core-geth 代码库 etclabscore/core-geth 也没有更新。这个流氓版本没有通知任何一位现有的 core-geth 维护者，也没有经过他们的审查。它是通过绕开社区公开发布流程的社交渠道推送出去的。
在混乱之中，少数矿池运营者的节点短暂切换到了这个流氓版本。它们此后已经切换回 etclabscore/core-geth。
绝大多数节点运营者所运行的、持续维护的客户端位于 etclabscore/core-geth，截至 2026-09-16，其当前版本是 Argos (v1.12.23)。我们强烈建议节点运营者不要切换到 ethereumclassic/core-geth。流氓版本中没有任何内容修复了该版本中的漏洞，与其宣称的相反。
我们分析了流氓分叉的提交历史、发布说明和文档。本文就是我们的发现，附有链接，你可以自行核实。
事件
首先，看看到底发生了什么。
关于 Core-Geth
Core-geth 是 Ethereum Classic 网络中大多数节点运行的 Go 客户端。自 2020 年 2 月起它一直位于 etclabscore/core-geth，有超过 300 个 star 和接近 200 个分叉，其提交历史从最初的 ETC Labs 作者一路延续到今天维护它的 Diego。网络运行过的每一个 core-geth 版本都来自那里，目前 etcnodes.org 上可达的 ETC 节点中超过 90% 运行这个代码库。
那里的版本在版本号之外还带有希腊语名字。今年到目前为止有三个。2026-03-18 的 Aegis (v1.12.21) 从 go-ethereum 回移了 p2p 握手加固。十天后的 Hermes (v1.12.22) 带来了其余的密码学回移。2026-08-14 的 Argos (v1.12.23) 回移了 go-ethereum 的延迟 p2p 消息解码。截至 2026-09-16，Argos 是当前版本，如果节点运营者使用 core-geth，这就是我们建议运行的版本。其他客户端也可用，包括 Nethermind、Besu 和 Getc。
流氓发布
在 56 小时内，96 个提交，新增 13,422 行、删除 3,977 行，被直接推送到一个分叉的 main 分支，没有任何人审查，然后被公开宣布为 Ethereum Classic 主要客户端的新版本。
这个流氓分叉 ethereumclassic/core-geth 于 2024-12-21 从 etclabscore 分叉而来，位于同时托管 ECIP 和网站的社区 GitHub 组织之下。没有人提议，没有人审查，也没有询问过客户端的任何维护者。一个拥有组织权限、却没有任何区块链客户端贡献记录的人点了一下分叉，从那一刻起，一个挂着项目名字的仓库就存在了，任何人都可以指向它。它沉寂了二十个月，直到上周末。
上周末发生了以下事情。这是以 UTC 计的时间线，取自标签和提交日志。
| 时间 | 事件 |
|---|---|
| 2026-09-12 07:19 | 标记流氓 v1.13.0-rc1（自 2026-09-03 上次活动以来新增 28 个提交） |
| 2026-09-12 至 2026-09-14 | rc2 到 rc7（新增 62 个提交） |
| 2026-09-14 15:06 | 流氓 v1.13.0 发布为稳定版（自 rc7 以来新增 5 个提交） |
| 2026-09-15 05:36 | @ETC_Network 发布迁移号召（新增 1 个提交，开启 v1.13.1 周期） |
一个周末里 96 个提交、修改 17,399 行代码，七个候选版本，一个稳定标签，第二天早上就是公告。这些提交背后没有审查者，也没有任何拉取请求，全部直接推送到 main。一个人写了改动，一个人打了标签，第二天早上整个网络就被告知去安装。如此大量的改动，没有给任何其他人阅读的时间，在任何软件中都是问题。而在一个决定节点跟随哪条链、与哪些节点通信的客户端中，并且被推送给掌握算力的运营者，这是一场潜在的灾难。
我们能找到的最贴切的类比，是一个业余擦窗工在飞行途中决定更换客机驾驶舱的窗户。乘客在机上，没有咨询工程师，没有地面检查，还通过广播愉快地宣布旧窗户不安全。Ethereum Classic 承载着超过十亿美元属于他人的价值，而这位业余擦窗工乐于拿它去赌。
@ETC_Network 不是个人账号。它是两个社区 X 账号之一，四年来发到它上面的每一条帖子都经过公开的拉取请求，任何人都可以在发送前后阅读。这一条没有。它是由掌握密码的人直接发布的，而在那时，公开流程早已被锁在门外。
危机化解
2Miners 是按算力计最大的 Ethereum Classic 矿池之一，其状态页列出了它的每一个 ETC 节点及各自报告的客户端版本。2026-09-15 12:09 UTC，其中四个节点报告运行流氓 CoreGeth v1.13.0。十一小时后的 23:35 UTC，它们全部回到了 v1.12.23，也就是 Argos。
所有大型 ETC 矿池现在都已安全地运行 Argos。这就是被化解的危机。危机之所以化解，是因为运营者在信任之前先向维护者核实了信息，我们赞赏他们的专业。
然而，似乎仍有一些节点停留在流氓版本上。2026-09-15 07:33 UTC，etcnodes.org 显示有十一个节点运行流氓 v1.13.0。
到 2026-09-16，数量是十个。其中三个是流氓分叉自己的引导节点，IP 地址与提交 eb0cb35a 硬编码的完全一致。如果其余节点中有一个是你的，请切换回 Argos。如果你是矿池或节点运营者，想就此事与真人交流，请写信至 [email protected]。
代码
现在来看看流氓版本包含了什么，以及安全声明为何站不住脚。
三天一万三千行
以下是流氓分叉自己的提交统计对改动规模的说明，用 GitHub API 统计了它与 etclabscore master 之间相差的 203 个提交。
| 区间 | 提交数 | 新增行数 | 删除行数 | 其中 Go 代码 |
|---|---|---|---|---|
| 全部分歧 | 203 | 32,916 | 33,078 | +11,606 / -2,435 |
| 2026-09-12 至 2026-09-14 | 96 | 13,422 | 3,977 | +4,205 / -1,225 |
| 仅 2026-09-14 | 56 | 9,458 | 2,737 |
作为对比，持续维护的客户端在八月发布的 Argos，是 Diego 的两个拉取请求，经过了多位人类审查者的审查。
以下是 GitHub 显示的流氓分叉 main 分支提交日志，共六屏，从 2026-09-15 的顶部一直回溯到 2024 年来自 etclabscore 的最后几个提交。从左到右、从上到下阅读。从头到尾只有一个提交者。
想想审查这个周末的差异需要什么。以太坊客户端中超过四千行的新 Go 代码，涉及 ethash 缓存、p2p 发现层、链配置和标志处理。共识软件有一个属性让它区别于其他所有软件。一个 bug 不会让你的进程崩溃，它会把你从网络上分叉出去，而如果足够多的算力运行着同一个 bug，整个网络就会跟着你一起分叉。这就是为什么客户端团队会让改动经过审查，然后是测试网，然后是运营者运行数周的候选版本，最后才是稳定标签。Mordor 就是为此而存在的。ECIP 流程也是。
这些在这里都没有发生。没有任何人审查过任何东西。每个候选版本只持续了几个小时，这连一个 Mordor 节点完成同步都不够，更不用说触发边缘情况了。而构建用来自检的共识测试固件，在同一个周末被迁移到了同一作者控制的仓库。
然后，整件事被作为紧急安全更新宣布给矿池。矿池掌握着决定哪条链是 Ethereum Classic 的算力。在一个星期天，要求它们迁移到一个带有未经测试的链选择改动和一组新引导节点、背后没有任何审查的客户端，把网络置于风险之中。
安全声明
流氓 v1.13.0 的发布说明是这样开头的。
每一个运行
v1.12.x版本的节点都应该升级。每一个
v1.12.x版本都带有未修补的安全问题，其中一个已于 2026 年 3 月被用于攻击 Ethereum Classic 的引导节点。
看看那条横幅的第一步。
1. 升级，并更改你跟踪版本的位置。 版本从
ethereumclassic/core-geth发布。跟踪原仓库的节点将看不到 v1.13.0。
运营者应对这类要求保持高度怀疑，并问问自己，为什么一个安全修复会要求任何人更改所跟踪的仓库。一旦运营者的工具开始跟踪流氓分叉，原维护者的每一个版本都将无人看见。这是一个夺取步骤，披着安全步骤的外衣。
这也是社会工程中最古老的把戏。快行动，别思考，做这一件事。一个警报表情，一串 CVE 列表，一条你的节点不安全的警告，而第一条指令就是交出控制权的那一条。紧迫感是诱饵，版本来源是调包。
流氓版本列出了七个标识符，声称它们在 etclabscore/core-geth 中未被修补。为免存疑，这里将每一个与持续维护的客户端所交付的代码逐一对照，任何人都可以核实这一声称是假的。
- CVE-2026-22862，过短的 ECIES 密文导致 RLPx 握手崩溃。已在 Aegis (v1.12.21) 中由提交 6d4968db 修复。
crypto/ecies/ecies.go第 296 行拒绝任何短于公钥、MAC 加一个 AES 块的密文。 - CVE-2026-26315，ECIES 无效曲线预言机泄露节点密钥位。已在 Aegis 中由提交 34894227 修复，并在 Hermes (v1.12.22) 中由 46bba8df 添加了回归测试。
crypto/ecies/ecies.go第 127 行在 ECDH 步骤之前拒绝任何不在曲线上的远端公钥。 - CVE-2026-26314，secp256k1 坐标超出域范围。已在 Hermes 中由提交 0ebf4922 修复。两个曲线实现，
crypto/secp256k1/curve.go第 95 行和crypto/signature_nocgo.go第 172 行，都在曲线检查之前拒绝等于或大于域素数的坐标。 - CVE-2025-24883，
UnmarshalPubkey接受曲线外的公钥。已在 Hermes 中由提交 ae6bad2d 修复。crypto/crypto.go第 181 行检查IsOnCurve，否则返回错误。 - CVE-2026-26313，构造的 p2p 消息导致内存耗尽。在 Hermes 中由提交 7940b281 缓解，并在 Argos (v1.12.23) 中由拉取请求 699 以上游方式修复，后者回移了 go-ethereum 的延迟消息解码，使任何消息在其大小和条目数被检查之前都不会被实例化。
- CVE-2026-22868，KZG 证明验证拒绝服务。不适用。KZG 证明属于 blob 交易，而 blob 交易只存在于以太坊的 Cancun 升级之后。Ethereum Classic 没有激活 Cancun，也没有 blob 交易，所以对等节点没有任何证明可发。
- GraphQL 查询深度，未分配 CVE。不是关键 bug，且默认未启用。GraphQL 只在使用
--graphql标志时启动，用于特定的应用场景，即私有部署在与 p2p 层不同的信任假设下查询自己的节点。任何能发送深层 GraphQL 查询的人，都已经拥有运营者主动授予的访问权限。p2p 或共识路径中没有任何部分涉及它。
七个中的五个已在 2026 年 3 月到 8 月之间按编号在持续维护的客户端中修复，另外两个触及不到用于 p2p 的 Ethereum Classic 节点。流氓分叉自己的 2026 年 3 月审计文档，位于 docs/audits/2026-03-security-audit.md，对此心知肚明。它将 v1.12.21 和 v1.12.22 描述为「仅 CVE 回移」。这等于承认这些 CVE 已在上游修补。
core-geth 的维护者 Diego 检查了流氓客户端差异中剩下的部分。v1.12.23 中没有任何可利用的缺陷是流氓 v1.13.0 修复的。即便真有一个，正确的处理方式是私下向维护者披露，而不是突然向矿池宣布一个竞争版本。
流氓客户端交付了什么
剥去版本号更新和重新生成的文档，这个「安全版本」就是几处关于节点如何选择链、如何寻找对等节点、如何选定网络的行为改动，外加把代码自身的测试向量和依赖迁移到同一作者控制的仓库。这些都没有真正修复 Argos 中的任何漏洞。与这个所谓的安全更新捆绑在一起的，是以下对 core-geth 运行方式的改动：
重新启用 MESS
提交 a7fd45b8，params/config_classic.go 第 83 行，删除了 ECBP1100DeactivateFBlock: big.NewInt(19_250_000)，并用一段十七行的注释取而代之，论证「这是客户端自己的决定」。同一个提交对 Mordor 做了同样的事。一行被删除的代码，就为每一个安装此版本的节点重新打开了 MESS。
网络曾以相反的方式、公开地、出于充分的理由做出过这个决定。MESS 于 2020 年作为链选择的临时补丁加入，当时以太坊的工作量证明算力远超 ETC，租用多数算力很便宜。随着以太坊在 2022 年转向权益证明，这一威胁随之消失，ECIP-1110 在一个月的讨论之后于 Spiral 区块关闭了 MESS。那个讨论串里最有力的论点，恰恰针对我们现在所处的局面。
我们真的不希望只有一部分节点运行 MESS（最坏的情况是五五开），因为那会有永久链分裂的风险。
Core-geth 是唯一实现过 MESS 的 ETC 客户端。在一个客户端中重新打开它，而 Besu、Nethermind 和 Getc 以正常方式权衡竞争链，会把网络分成两群可能偏好不同分叉的节点。这被推送给了矿工和矿池，也就是最糟糕的地方。矿池不是旁观者，它生产区块。如果矿池运行 MESS 而其他所有人不运行，那么第一次出现两条链竞争时，矿池就可能继续挖网络其他部分拒绝的那条链，矿工的奖励随之而去，而如果 MESS 一侧的算力足够多，分裂就不会愈合。
劫持节点发现
提交 eb0cb35a，params/bootnodes_classic.go 第 42 行，将 DNS 树的签名密钥从 etclabscore 维护者自 2020 年起持有的 AJE62Q… 换成了 APDLRZ…，并硬编码了三个新的引导节点 IP。同一文件中的代码注释承认，这三个域名「由单一 DNS 账户提供服务，因此在一个区域故障时，不同的名字是唯一可用的冗余；它们不是独立的提供商」。提交 c0b5857 随后删除了 OldClassicDNSNetwork1 和 OldClassicDNSNetwork2，也就是 blockd.info 和 etcdisco.net 的树，并在 cmd/utils/flags.go 第 2260 行将它们移除。此后，运行此版本的节点只能通过一个人运营的基础设施寻找对等节点。
这些树来自第二个仓库，ethereumclassic/discv4-dns-lists，由同一账号于 2026-08-28 在社区组织下创建，同样没有征询任何人。它将节点列表发布到三个域名，ethereumclassic.net、ethclassic.net 和 ethereumclassic.network，全部在同一个 Cloudflare 账户上，其 README 承认「单一 Cloudflare 账户的问题会一次性移除所有路径」。发布说明只说「节点发现使用本项目的 DNS 树」。无论是发布说明还是迁移指南，都没有提及这个仓库、这些域名，或谁持有签名密钥。按照升级指南操作的运营者，无从得知自己节点眼中的网络正被交给一个他们从未听说过的 DNS 账户。
重新定义网络标志
提交 c3b911f，cmd/utils/flags.go 第 169 至 198 行，将 --mainnet 改为表示「Ethereum Classic 主网，与 —classic 相同」，将 --ethereum、--sepolia 和 --holesky 移入弃用类别，用法文字为「拒绝启动」，并在第 1236 行更改了引导节点的选择逻辑，使 params.ClassicBootnodes 仅在链为 Classic 时使用，否则为空。不带任何标志运行，现在意味着 Ethereum Classic。
迁移测试向量与依赖
提交 693d8e41，.gitmodules 第 8 行，将 ETC 共识测试固件从 etclabscore/tests 改为 fukuii-project/archive-reference-material。提交 ed99f029，go.mod 第 184 至 190 行，添加了从同一仓库构建 OpenRPC 模块的 replace 指令。fukuii-project 组织创建于 2026 年 7 月，正是流氓分叉自己的提交把构建指向了那里。Fukuii 是一个新的 Ethereum Classic 客户端，与 core-geth 无关，流氓分叉的 README 将其称为 core-geth 的继任者。你的构建用来验证共识的向量，现在与代码来自同一个地方。
强制轮换密钥
迁移指南将轮换 P2P 节点密钥列为「必需步骤」，引用的是 CVE-2026-26315，而持续维护的客户端已于三月在 Aegis 中修复了它。
节点密钥是节点在点对点网络上的身份来源。它的公开部分是 enode ID，其他节点记住它，矿池和交易所把它固定在静态对等节点列表里，发现树也记录它。轮换它会让节点变成陌生人。每一个对等节点都会忘记它，每一条以它命名的静态对等连接都会断开，节点会从发现机制重新构建自己眼中的网络，而在这个版本上，这意味着流氓分叉的引导节点和 DNS 树。所声称的理由，即重复握手泄露密钥，已由 Aegis 在三月关闭。运行 Aegis、Hermes 或 Argos 的节点没有任何轮换的必要。
README 用自己的话说明了 MESS 的决定。
流氓分叉是氛围编码的
流氓分叉附带了 CLAUDE.md、AGENTS.md 和 .github/copilot-instructions.md，其中有一张表格说明「共识规则、链配置、密码学」应使用哪一档模型。三月的全部 27 个拉取请求都以「Generated with Claude Code」结尾。而且没有人类能在一个周末里为一个 Go 客户端写出 96 个提交，其中三十个是重新生成文档，提交信息还以「Verified rather than assumed」和「Calibrated by」收尾。
问题不在于智能体工具本身。我们自己显然也在使用这些工具，尤其是在非关键的应用中。问题在于，在大量改动被直接推送到一个承载超过十亿美元价值的网络的生产环境之前，没有任何有经验的人类审查者参与其中。一个智能体会以你要求的任何速度，生产出看似合理、注释完善、描述自信的共识规则改动，而它不会知道其中哪一个会分裂网络。在这样的代码上使用 LLM 并验证其产出是有正确方法的，但每一种方法都需要时间和对细节的专注。
捐赠地址
README 的结尾请求矿池、交易所、ETF 发行方、硬件制造商和大额持有者资助这项工作，通过 [email protected]，或者「在任何 EVM 链上」向这个地址转账。
我们在 ETC 上查了这个地址。它不是多签，也不是合约。它是一个普通账户，里面有大约四个 ETC，以及超过 2,500 笔转出交易，这是日常钱包的样子，而不是项目金库的样子。添加它的提交，2026-09-14 的 71c90b93，还顺便加了一个复制按钮。
想想这个地址挂在什么东西上。Core-geth 是 go-ethereum，是数百人十三年的工作，加上 multi-geth，加上 ETC Labs、ETCDEV 和 Cooperative 的工程师六年来让它跟随这条链的工作，加上让它在 2026 年持续得到修补的维护者。流氓分叉在这之上加了一个人几天的氛围编码提交，其中大多是文档。然后它把 Ethereum Classic 的名字挂在前面，一条告诉运营者他们不安全的警告横幅，以及底部一个带复制按钮的钱包地址，收件人是资助这个网络的矿池、交易所和硬件制造商。
想象一座国家公园。它不属于任何人，也属于每一个人。步道、桥梁和路标是志愿者和护林员几十年来修建和维护的，其中大多数人的名字无人记得。现在想象有人在某个周末现身，用公园自己的字体在入口钉上一块新招牌，告诉游客旧的路不安全，然后摆出一个写着自己银行账户的募捐箱。公园从来不是他们可以出售的，至于该如何称呼这样一个募捐箱，我们留给读者自己判断。
同一份 README 宣称流氓分叉「从此是 Core-Geth 的正典之家」，称 v1.13 为「Core-Geth 的最后一个发布系列」，并说 core-geth 将被同一批人的 Scala 客户端 Fukuii 取代。它还声称一家名为 Ethereum Classic DAO LLC 的怀俄明公司「接替了 ETC Cooperative」，而同一个人正是这家公司的两名组织成员之一。
接下来
最后，运营者应该运行什么，以及组织维护者应该改变什么。
该怎么做
我们强烈建议不要运行来自 ethereumclassic/core-geth 的 v1.13.0。我们建议你继续运行一直以来并持续在 etclabscore/core-geth 维护的客户端。当前版本是 Argos (v1.12.23)，Docker Hub 上的 etclabscore/core-geth 镜像也可用。下载前请核对任何链接中的组织名。如果一条 ETC 的「安全更新」通过邮件或社交媒体而非维护者到来，请去问维护者，并请保持警惕。
如果你已经把节点迁移到了流氓 v1.13.0，请迁回。链数据双向兼容。如果你按流氓分叉的指示轮换了节点密钥，请恢复原来的密钥，并检查你的 MESS 设置是否符合你的意图。
我们还建议不要只运行 core-geth。Ethereum Classic 有多个客户端，包括 Nethermind、Besu 和 Getc，而一个大部分算力都运行同一个客户端的网络，无论那个客户端是哪一个，都存在单点故障。
致组织维护者的请求
致 ethereumclassic GitHub 组织的管理员和维护者。你们代表一个没有其他所有者的网络托管着这个命名空间，你们是其社区资产的管理者，有责任确保这些资产不被滥用、不将网络置于风险之中。这个周末，组织下的一个仓库被用来让大型矿业运营者运行未经审查、氛围编码、启用了 MESS 的共识软件。对网络的严重损害，包括链分裂，万幸得以避免，我们相信你们理解本可能发生的事情意味着什么。
这次事件已经损害了项目的声誉，并在技术上将其置于风险之中，也表明无论现行制度是什么，它都存在漏洞。归根结底，决定谁对哪些仓库拥有什么权限是组织管理员的责任，需要进行一次认真的审查和调查，以确保这种事不再发生。
我们请求如下：
- 收紧组织的安全。今天，任何一个成员都可以在
ethereumclassic下创建仓库，随意命名，并从中发布版本，无需任何人审查。这就是一个只有一名贡献者的分叉和一个新的引导节点仓库在一个周末里被当作官方客户端呈现给矿池的方式。在组织下创建仓库应当需要提案和审查，就像 ECIP 或网站改动那样。交付软件的仓库应当写明维护者，保护默认分支，并在合并前要求审查。 - 更进一步，
ethereumclassic组织不应再用于任何额外的代码仓库，而应保持纯信息性。一个供社区整理信息的中立聚集地，这正是 ECIP、网站和社区通话已经是的样子。出于我们在三月的网站拉取请求中阐述的理由，每个客户端都应当位于其自己维护者的组织之下。这次事件正是我们提出那个论点的完美例证，也是我们庆幸那个拉取请求没有被强行通过的原因。 - 移除或归档
ethereumclassic/core-geth仓库，并在其 README 中放置一条横幅，警告它不是任何意义上的官方客户端，也不是被认真维护的客户端。如果有人想维护一个 core-geth 的分叉，这应当受到鼓励，但他们应当在自己的组织下进行，并以公开的记录赢得用户，就像其他每一个客户端那样。允许一个人在零讨论的情况下自封为官方 core-geth 仓库的维护者，是 Ethereum Classic 的对立面。至少需要有分支保护，以及某种决定什么可以进入该仓库的流程，而且它不应被赋予官方的名分。 - 考虑移除或撤销那些对网络安全表现出鲁莽漠视的个人的权限。组织成员身份意味着被授予权利，也随之被授予责任，而这个周末展示了权利被行使、责任却未被履行时会发生什么。当一个流氓行为者多次打破社会规范而不受任何后果时，这只会助长这类行为。正是同一个人，编辑并隐藏了 Olympia ECIP 讨论中的批评评论，以自封的「合规锁定」阻挠 ECIP-1120 拉取请求数周直到其他维护者批准，并重写了追溯至 2023 年的 Ethereum Classic 社区通话档案的标题和正文，还在同一天将重写推送到了生产环境。
- 保持响应并负起责任。组织维护者需要对此类事件作出回应，了解网络上实际发生的事情，并保持中立、公正的管理方式。遗憾的是，一些现任组织管理员近来一直没有回应，这使得对此类重要事件的及时响应变得困难。再说一次，这些角色伴随着责任，我们认为随着项目的推进，期望这些责任得到履行并不过分。
我们认为这些请求既不具争议性也不过分，希望所有 ethereumclassic GitHub 组织管理员认真考虑。
没有任何官方
ethereumclassic.org 的每一个页面底部都有一条免责声明。
本网站的内容由用户生成，仅供参考。请勿将任何内容理解为对任何产品或服务的背书。Ethereum Classic 中「没有任何官方」。 请始终自行研究，并记住：不要信任，去验证！
这不只是一条免责声明，网站解释了原因。和比特币一样，ETC 没有官方的开发者、维护者或领袖。没有官方的标志、网站、会议或客户端。没有人可以声称代表这个网络，所以没有任何官方的东西可以被夺取或关停，也没有一个可以被占据的最高席位。
另一面是，没有办法阻止任何人声称它，而时不时就会有人这么做。一个「Core-Geth 的正典之家」。一份署名「Ethereum Classic 核心开发者」的审计。一封来自 ethereumclassic.com 的安全更新。一个让协议金库将资金转向 Ethereum Classic DAO LLC 的提案。每一个都是在一个没有官方的项目里自称官方，而每一个都在你查清背后是谁的那一刻土崩瓦解。这类声称应当被认清为它们的本质，即社会攻击；一种让你误以为某人代表着他们无法代表之物的企图。
etclabscore 仓库也不是官方的 core-geth。但它有一位有 ETC 客户端开发经验的活跃维护者，有六年的公开历史，有目前网络绝大多数节点自主选择运行的版本。这份记录是 ETC 世界里唯一存在的权威，也是你可以亲自验证的那种。
每当有人使用「Ethereum Classic」这个名字，请仔细想想他们在声称什么。他们的措辞是否让人觉得他们代表着一个没有领袖的去中心化项目？这个声称本身说得通吗？
这就是我们叫 Classix 的原因。不声称，不玩把戏，只有对赛博正义的狂热渴望。
……还有，朋友们，请记住：不要信任，去验证。
事件记录
一些运营 ETC 基础设施的机构是受监管实体，负有自身的事件管理义务。为了他们，也为了留下记录，以下是按那种格式整理的本次事件。
- 发生了什么。一个挂着社区 GitHub 名字、未经审查的客户端版本，于 2026-09-14 和 2026-09-15 通过社区 X 账号、CoinMarketCap 社区动态和直接邮件，被作为紧急安全更新宣布给节点运营者和矿池。
- 可能原因。
ethereumclassicGitHub 组织允许单个成员创建挂着项目名字的仓库并从中发布版本，无需任何审查；社区 X 账号的凭据被持有在公开发布流程之外。 - 直接影响。少数矿池节点运行了该版本不到十二小时。没有丢失区块，没有发生重组，没有资金受到影响，没有服务中断。仍有十个节点报告运行该版本，其中三个是该版本自己的引导节点。
- 受影响系统。core-geth 客户端、其节点发现，以及任何安装了该版本的节点上的链选择设置。
- 相关第三方。GitHub、X、CoinMarketCap、作为该版本发现树 DNS 提供商的 Cloudflare，以及收到通知的矿池。
- 分类。严重性高，影响低。按「关键服务受影响」标准它构成重大事件，因为该版本改变了绝大多数网络运行的客户端的共识行为；按「声誉影响」标准亦然。按受影响交易、持续时间、数据丢失和经济影响标准则不构成，这些均为零。
- 报告。本文兼作初始通报与中期报告，于公告后 48 小时内发布。如果剩余节点得到核实、组织维护者作出回应，或出现任何实质性变化，本文将随之更新。
- 根本原因与后续。根本原因是社区组织缺乏审查控制，详见上一节。后续行动是向组织维护者提出的五项请求，以及建议运营者运行不止一种客户端。