关于Luke硬分叉戏剧的严峻真相： 我认为构建一个通过ZK同步到最新、最重的链顶的_替代_客户端没有任何问题，即使这意味着不下载所有区块内容……即使有一个集中式财团（多重签名）控制着通过ZK验证链的哪些部分，以及哪些部分正常验证。 即使这意味着_参考客户端_（Core）会在整个网络中唯一可用的数据是我的替代客户端所托管的数据时，卡在同步链上。 如果*参考客户端*（或“绝大多数客户端”）采用了这个，那将是一个问题……因为如果绝大多数网络运行它，可能会导致链分裂的情况。 如果采用这个的替代客户端与网络中的其他节点对等，假装他们拥有完整的区块链数据，而实际上并没有，并试图向毫无防备的对等节点提供不可识别的ZK证明以代替实际的交易数据，那也可能是个问题。 这将等同于一次日蚀攻击，但我们没有理由相信有人计划或会计划这样的事情。 实际上，这样的节点（如果诚实）可能会简单地宣传一个适当的服务位，向同步（IBD）的节点传达他们没有所有数据。 就像网络上的修剪Core节点一样（服务位：NODE_NETWORK_LIMITED == 你的节点在说“我没有完整的区块历史……如果你想进行完整同步，你得与其他人对等”）。 我不是Core同步机制的专家，但我相信Core节点已经优先连接那些广播他们拥有完整区块链数据的节点，并会驱逐/轮换出无法提供完整历史的有限对等节点。 一般来说，Core客户端始终有责任轮换对等节点，并在网络上找到诚实的连接，以抵御故意对抗以及无意对抗的日蚀攻击类情况。 🔸🔸🔸🔸 现在，事情变得棘手的是，如果我不仅发布/构建/计划发布这个替代客户端，而且我还公开散布恐慌，关于参考客户端***保证比特币的死亡***，并且我还在探索法律途径以使节点或矿池不再运行Core。 我对这后者（法律）部分了解不多，所以我不会对此发表意见。 无论如何，这就是为什么有些人会说Luke计划的不是一个审查硬分叉（仅在严格的技术定义下是一个硬分叉客户端，因为它在不太可能的条件下可以触发链分裂），而其他人则观察到恐慌/法律背景，这全面描绘了一个相当邪恶的图景。 结束。

以及*哪些*部分是正常验证的……第一段有错字

在 Knots 的情况下，上述内容很可能被视为一个可选功能，而不是所有节点默认会执行的操作。