A dura verdade sobre o drama do hardfork do Luke: Não acho que haja algo de errado em construir um cliente _alternativo_ que sincroniza com o mais recente e pesado chaintip por meio de ZK, mesmo que isso signifique não baixar todo o conteúdo dos blocos... nem mesmo se houver um consórcio centralizado (multisig) que tenha controle sobre quais partes da cadeia são validadas através de ZK e quais partes são validadas normalmente. Mesmo que isso signifique que o _cliente de referência_ (Core) ficaria preso sincronizando a cadeia se os ÚNICOS dados disponíveis em toda a rede fossem aqueles que meu cliente alternativo hospedasse. SERIA um problema se o *cliente de referência* (ou o "cliente da vasta maioria") adotasse isso... porque se a vasta maioria da rede o utilizasse, isso poderia levar a situações de divisão de cadeia. Isso também poderia ser um problema se o cliente alternativo que adota isso se conectasse a outros nós na rede, fazendo parecer que eles têm todos os dados da blockchain, quando na realidade não têm, e tentasse servir provas ZK não reconhecíveis em vez de dados de transação reais para pares desavisados por algum motivo. Isso seria equivalente a um ataque de eclipse, mas não temos razão para acreditar que alguém planejou ou planejaria algo desse tipo. Na realidade, tais nós (se honestos) provavelmente simplesmente anunciariam um bit de serviço adequado que comunica aos nós sincronizando (IBD) que não têm todos os dados. Assim como os nós Core podados na rede fazem (bit de serviço: NODE_NETWORK_LIMITED == a maneira do seu nó dizer "Eu não tenho todo o histórico de blocos... você precisa se conectar a outra pessoa se quiser fazer uma sincronização completa"). Não sou um especialista na mecânica de sincronização do Core, mas acredito que os nós Core já priorizam conexões que transmitem que têm todos os dados da blockchain e expulsarão/rotacionarão nós limitados que não podem fornecer todo o histórico. Em geral, é sempre responsabilidade do cliente Core rotacionar pares e encontrar conexões honestas na rede, para ter resistência contra situações intencionalmente adversariais, bem como contra situações de ataque de eclipse não intencionais na rede. 🔸🔸🔸🔸 Agora, onde as coisas ficam complicadas é se eu não apenas lançasse/construísse/planejasse lançar este cliente alternativo, mas também fizesse uma campanha de medo publicamente sobre como o cliente de referência ***garante a morte do Bitcoin*** e também estivesse explorando caminhos legais para desincentivar nós ou pools de mineração de rodar o Core. Não sei muito sobre esta última parte (legal), então não vou falar sobre isso. De qualquer forma, essa é a essência do porquê algumas pessoas dirão que o que Luke estava planejando não era um hardfork de censura (e apenas um cliente de hardfork em uma definição técnica estrita porque pode desencadear uma divisão de cadeia em condições improváveis), enquanto outros observam o contexto de medo/legal que pinta um quadro bastante nefasto.

e *quais* porções são validadas normalmente... erro de digitação no primeiro parágrafo

No caso dos Knots, o acima poderia muito bem ser intencionado como uma funcionalidade opcional, não algo que todos os nós fariam por padrão.