Adevăr dur re: Drama hardfork a lui Luke: Nu cred că este ceva în neregulă cu construirea unui client _alternativ_ care se sincronizează cu cel mai recent și mai greu vârf de lanț prin intermediul ZK, chiar dacă asta înseamnă să nu descărcați tot conținutul blocului... nici măcar dacă există un consorțiu centralizat (multisig) care are control asupra porțiunilor lanțului care sunt validate prin ZK și porțiunile sunt validate în mod normal Chiar dacă asta înseamnă că _reference client_ (Core) s-ar bloca sincronizând lanțul dacă SINGURELE date disponibile în întreaga rețea ar fi cele găzduite de clientul meu alternativ Ar fi o problemă dacă *clientul de referință* (sau "clientul-marea majoritate") ar adopta acest lucru... pentru că dacă marea majoritate a rețelei ar rula, ar putea duce la situații de divizare a lanțului Ar putea fi, de asemenea, o problemă dacă clientul alternativ care adoptă acest lucru se asociază cu alte noduri din rețea, pozând ca și cum ar avea toate datele blockchain, când în realitate nu au, și ar încerca să servească dovezi ZK de nerecunoscut în loc de date tx reale colegilor nebănuiți dintr-un motiv oarecare Asta ar echivala cu un atac de eclipsă, dar nu avem niciun motiv să credem că cineva a plănuit sau ar plănui ceva de genul acesta În realitate, astfel de noduri (dacă sunt sincere) ar face probabil pur și simplu publicitate unui bit de serviciu adecvat care comunică nodurilor de sincronizare (IBD) că nu au toate datele La fel ca nodurile Core tăiate din rețea (service bit: NODE_NETWORK_LIMITED == modul nodului tău de a spune "Nu am întregul istoric al blocurilor... trebuie să te uiți cu altcineva dacă vrei să faci o sincronizare completă") Nu sunt un expert în mecanica de sincronizare a Core, dar cred că nodurile Core acordă deja prioritate conexiunilor care transmit că au datele complete ale blockchain-ului și vor evacua/roti din colegii limitați care nu pot servi întreaga istorie În general, este întotdeauna responsabilitatea clientului Core să rotească colegii și să găsească conexiuni oneste în rețea, să aibă rezistență împotriva situațiilor de tip eclipsă în rețea 🔸🔸🔸🔸 Acum, unde lucrurile devin păroase este dacă nu numai că am lansat/construit/planificat să lansez acest client alternativ, dar m-am și teamit public despre modul în care clientul de referință ***garantează moartea Bitcoin*** și am explorat, de asemenea, căi legale pentru a descuraja nodurile sau pool-urile de minerit de la rularea Core. Nu știu prea multe despre această ultimă parte (legală), așa că nu voi vorbi despre ea. Oricum, aceasta este esența motivului pentru care unii oameni vor spune că ceea ce plănuia Luke nu a fost un hardfork de cenzură (și doar un client hardforking într-o definiție tehnică strictă, deoarece poate declanșa o divizare a lanțului în condiții improbabile), în timp ce alții observă contextul legal/de alarmă care pictează o imagine destul de nefastă. Capăt.

și *care* porțiuni sunt validate în mod normal... greșeală de scriere în primul paragraf

În cazul nodurilor, cele de mai sus ar putea fi foarte bine concepute ca o caracteristică de înscriere, nu ceva ce toate nodurile ar face în mod implicit.