Trudna prawda dotycząca dramatu hardforka Luke'a: Nie sądzę, żeby było coś złego w budowaniu _alternatywnego_ klienta, który synchronizuje się z najnowszym, najcięższym chaintipem za pomocą ZK, nawet jeśli oznacza to, że nie pobiera się wszystkich treści bloków... nawet jeśli istnieje scentralizowany konsorcjum (multisig), które ma kontrolę nad tym, które części łańcucha są weryfikowane przez ZK, a które są weryfikowane normalnie. Nawet jeśli oznacza to, że _klient referencyjny_ (Core) utknie w synchronizacji łańcucha, jeśli JEDYNE dane dostępne w całej sieci będą tymi, które hostował mój alternatywny klient. Byłoby to problemem, jeśli *klient referencyjny* (lub "klient o ogromnej większości") przyjąłby to... ponieważ jeśli ogromna większość sieci by go uruchomiła, mogłoby to prowadzić do sytuacji rozdzielenia łańcucha. Mogłoby to również być problemem, jeśli alternatywny klient, który to przyjmuje, łączyłby się z innymi węzłami w sieci, udając, że mają pełne dane blockchain, podczas gdy w rzeczywistości ich nie mają, i próbowałby serwować nierozpoznawalne dowody ZK zamiast rzeczywistych danych transakcji nieświadomym węzłom z jakiegoś powodu. To byłoby równoznaczne z atakiem zaćmienia, ale nie mamy powodu, by wierzyć, że ktokolwiek planowałby coś takiego. W rzeczywistości takie węzły (jeśli są uczciwe) prawdopodobnie po prostu ogłaszałyby odpowiedni bit usługi, który informuje węzły synchronizujące (IBD), że nie mają wszystkich danych. Tak jak pruned Core nodes w sieci (bit usługi: NODE_NETWORK_LIMITED == sposób, w jaki twój węzeł mówi "Nie mam całej historii bloków... musisz połączyć się z kimś innym, jeśli chcesz zrobić pełną synchronizację"). Nie jestem ekspertem w mechanice synchronizacji Core, ale wierzę, że węzły Core już priorytetowo traktują połączenia, które ogłaszają, że mają pełne dane blockchain, i będą usuwać/rotować z ograniczonych węzłów, które nie mogą dostarczyć pełnej historii. Ogólnie rzecz biorąc, zawsze to klient Core jest odpowiedzialny za rotację węzłów i znajdowanie uczciwych połączeń w sieci, aby mieć opór przeciwko celowo wrogim, jak i niezamierzonym sytuacjom przypominającym atak zaćmienia w sieci. 🔸🔸🔸🔸 Teraz, gdzie sprawy stają się skomplikowane, to jeśli nie tylko wydałbym/zbudowałbym/zaplanowałbym wydanie tego alternatywnego klienta, ale także publicznie straszyłbym, jak klient referencyjny ***gwarantuje śmierć Bitcoina*** i badałbym również ścieżki prawne, aby zniechęcić węzły lub pule wydobywcze do uruchamiania Core. Nie wiem dużo o tej ostatniej (prawnej) części, więc nie będę się na ten temat wypowiadał. W każdym razie to jest sedno, dlaczego niektórzy ludzie powiedzą, że to, co Luke planował, nie było hardforkiem cenzurującym (a tylko klientem hardforkującym w ścisłej definicji technicznej, ponieważ może wywołać rozdzielenie łańcucha w mało prawdopodobnych warunkach), podczas gdy inni dostrzegają kontekst straszenia/prawny, który całościowo maluje dość niegodziwy obraz.

i *które* części są normalnie weryfikowane... literówka w pierwszym akapicie

W przypadku Knots, powyższe może być zamierzone jako funkcja opcjonalna, a nie coś, co wszystkie węzły robiłyby domyślnie.