厳しい真実: ルークのハードフォーク ドラマ: たとえすべてのブロックコンテンツをダウンロードしないことを意味するとしても、ZKを使用して最新の最も重いチェーンチップに同期する_alternative_クライアントを構築することに問題はないと思います...チェーンのどの部分がZKを通じて検証され、その部分が正常に検証されるかを制御できる中央集権型コンソーシアム(マルチシグ)があっても、 たとえそれが、ネットワーク全体で利用可能な唯一のデータが私の代替クライアントがホストしているデータである場合、_reference client_(コア)がチェーンの同期でスタックすることを意味するとしても *参照クライアント*(または「大多数クライアント」)がこれを採用した場合、問題になります...なぜなら、ネットワークの大部分がそれを実行すると、チェーンスプリットの状況につながる可能性があるためです また、これを採用する代替クライアントがネットワーク内の他のノードとピアリングし、実際にはブロックチェーンデータ全体を持っているかのように装い、何らかの理由で実際のtxデータの代わりに認識できないZK証明を無防備なピアに提供しようとした場合にも問題になる可能性があります それは日食攻撃に等しいでしょうが、誰かがそのようなことを計画した、または計画するつもりであると信じる理由はありません 実際には、そのようなノードは(正直であれば)すべてのデータを持っていないことを同期ノード(IBD)に通信する適切なサービスビットを単にアドバタイズする可能性があります ネットワーク上のプルーニングされたコアノードが行うのと同じように(サービスビット:NODE_NETWORK_LIMITED==ノードが「ブロック履歴全体を持っていません...完全な同期をしたい場合は、他の誰かとピアリングする必要があります」) 私はCoreの同期メカニズムの専門家ではありませんが、Coreノードはすでに完全なブロックチェーンデータを持っていることをブロードキャストする接続を優先し、完全な履歴を提供できない限られたピアから立ち退き/ローテーションすると思います 一般に、ピアをローテーションし、ネットワーク上で誠実な接続を見つけ、ネットワーク上の意図的に敵対的および意図せずに敵対的な日食攻撃のような状況に抵抗することは、常にコアクライアントの責任です 🔸🔸🔸🔸 さて、問題になるのは、私がこの代替クライアントをリリース/構築/リリースする予定であるだけでなく、リファレンスクライアントがビットコインの死を****保証する方法について公に恐怖を煽り、ノードやマイニングプールがコアを実行するのを抑制するための法的道筋を模索していた場合です。 私はこの後者の(法的な)部分についてあまり知らないので、それについては話しません。 とにかく、ルークが計画していたのは検閲ハードフォークではなかったと言う人もいる(そして、ありそうもない状況でチェーンスプリットを引き起こす可能性があるため、厳密な技術的定義ではハードフォーククライアントにすぎない)、そして、かなり邪悪な絵を包括的に描く恐怖を煽る/法的な文脈を観察する人もいます。 終わり。

そして*どの*部分が正常に検証されますか...最初の段落のタイプミス

Knotsの場合、上記はオプトイン機能として意図されている可能性が非常に高く、すべてのノードがデフォルトで行うことではありません。