Жесткая правда о драме с хардфорком Люка: Я не думаю, что есть что-то плохое в создании _альтернативного_ клиента, который синхронизируется с последним, самым тяжелым чайнтипом с помощью ZK, даже если это означает, что не нужно загружать все содержимое блоков... даже если есть централизованный консорциум (мультиподпись), который контролирует, какие части цепи проверяются через ZK, а какие проверяются обычным образом. Даже если это означает, что _референсный клиент_ (Core) застрянет в синхронизации цепи, если ЕДИНСТВЫЕ данные, доступные в сети, будут теми, которые хостит мой альтернативный клиент. Это БЫЛО бы проблемой, если бы *референсный клиент* (или "клиент подавляющего большинства") принял это... потому что если подавляющее большинство сети будет его использовать, это может привести к ситуациям с разделением цепи. Это также может быть проблемой, если альтернативный клиент, который принимает это, соединяется с другими узлами в сети, притворяясь, что у них есть полные данные блокчейна, когда на самом деле их нет, и пытается предоставить нераспознаваемые ZK доказательства вместо фактических данных транзакций ничего не подозревающим пирами по какой-то причине. Это было бы равносильно атаке затмения, но у нас нет причин полагать, что кто-то планировал или планирует что-то подобное. На самом деле такие узлы (если честные) вероятно просто будут рекламировать правильный бит сервиса, который сообщает узлам, синхронизирующимся (IBD), что у них нет всех данных. Точно так же, как обрезанные узлы Core в сети делают (бит сервиса: NODE_NETWORK_LIMITED == ваш узел говорит: "У меня нет всей истории блоков... вам нужно соединиться с кем-то другим, если вы хотите сделать полную синхронизацию"). Я не эксперт по механике синхронизации Core, но я верю, что узлы Core уже приоритизируют соединения, которые транслируют, что у них есть полные данные блокчейна, и будут исключать/менять ограниченные пиры, которые не могут предоставить полную историю. В общем, всегда ответственность клиента Core заключается в том, чтобы менять пиры и находить честные соединения в сети, чтобы иметь сопротивление как намеренно враждебным, так и непреднамеренно враждебным ситуациям, похожим на атаки затмения в сети. 🔸🔸🔸🔸 Теперь, где все становится запутанным, так это если я не только выпустил/создал/планировал выпустить этот альтернативный клиент, но и публично сеял страх о том, как референсный клиент ***гарантирует смерть Биткойна***, и я также исследовал юридические пути, чтобы не поощрять узлы или майнинг-пулы к запуску Core. Я не знаю много о этой последней (юридической) части, поэтому не буду об этом говорить. В любом случае, вот суть того, почему некоторые люди скажут, что то, что планировал Люк, не было хардфорком цензуры (и только хардфоркающим клиентом в строгом техническом определении, потому что это может вызвать разделение цепи при маловероятных условиях), в то время как другие наблюдают за контекстом страха/юридическим контекстом, который всеобъемлюще рисует довольно зловещую картину. Конец.

и *какие* части обычно проверяются... опечатка в первом абзаце

В случае с Knots вышеупомянутое вполне может быть задумано как функция по выбору, а не как то, что все узлы будут делать по умолчанию.