Жорстка правда щодо: Люк хардфорк драма: Я не думаю, що є щось погане в тому, щоб створити _alternative_ клієнт, який синхронізується з останнім, найважчим chaintip за допомогою ZK, навіть якщо це означає не завантаження всього вмісту блоку... навіть якщо існує централізований консорціум (мультипідпис), який контролює, які частини ланцюга перевіряються через ZK і частини валідуються нормально Навіть якщо це означає, що _reference client_ (Core) застрягне під час синхронізації ланцюжка, якщо ЄДИНИМИ доступними даними у всій мережі були ті, які розмістив мій альтернативний клієнт Було б проблемою, якби *референтний клієнт* (або «переважна більшість-клієнт») прийняв це... Тому що, якщо переважна більшість мережі запустить його, це може призвести до ситуацій розколу ланцюга Це також може бути проблемою, якщо альтернативний клієнт, який використовує цей вузол, працює з іншими вузлами мережі, вдаючи, що у них є повні дані блокчейну, хоча насправді це не так, і з якоїсь причини намагається надати невпізнанні докази ZK замість фактичних даних tx нічого не підозрюючим колегам Це було б рівнозначно атаці затемнення, але у нас немає підстав вважати, що хтось планував або планував би щось подібне Насправді, такі вузли (якщо вони чесні), швидше за все, просто рекламують належний сервісний біт, який повідомляє вузлам синхронізації (IBD), що вони не мають усіх даних Так само, як це роблять обрізані вузли Core у мережі (біт сервісу: NODE_NETWORK_LIMITED == спосіб вашого вузла сказати «У мене немає всієї історії блоків... ти повинен бути рівним з кимось іншим, якщо хочеш зробити повну синхронізацію») Я не є експертом з механіки синхронізації Core, але я вважаю, що вузли Core вже віддають перевагу з'єднанням, які транслюють, що вони мають повні дані блокчейну, і виселяють/повертають обмежених пір, які не можуть обслуговувати повну історію Загалом, відповідальність клієнта Core завжди полягає в тому, щоб ротувати вузли та знаходити чесні з'єднання в мережі, мати стійкість до навмисно змагальних, а також ненавмисно змагальних ситуацій, схожих на атаки затемнень у мережі 🔸🔸🔸🔸 Тепер, коли ситуація стає неоднозначною, так це те, що я не тільки випустив/побудував/планував випустити цей альтернативний клієнт, але й публічно побоювався того, як еталонний клієнт ***гарантує смерть Bitcoin***, і я також вивчав юридичні шляхи для дестимулювання вузлів або майнінгових пулів від роботи Core. Я не знаю багато про цю останню (юридичну) частину, тому не буду про неї говорити. У будь-якому випадку, саме в цьому і полягає суть того, чому деякі люди скажуть, що те, що Люк планував, не було хардфорком цензури (і лише клієнтом хардфоркінгу в строгому технічному визначенні, тому що він може спровокувати розкол ланцюга за малоймовірних умов), тоді як інші спостерігають за нагнітанням страху/юридичним контекстом, який у сукупності малює досить мерзенну картину. Кінець.

і *які* порції валідуються нормально... друкарська помилка в першому абзаці

У випадку з вузлами, вищезазначене цілком може бути задумано як функція згоди, а не те, що всі вузли робили б за замовчуванням.