A Zcash aplicou uma correção para uma falha de software grave que, em circunstâncias erradas, poderia ter permitido aos atacantes esvaziar uma quantidade significativa de ZEC de uma parte mais antiga da rede. O problema estava dentro do zcashd, o software do nó, e centrou-se em transações que envolvem o pool protegido legado Sprout. De acordo com o anúncio, os nós estavam a ignorar a verificação de provas nesses casos. É um tipo de bug que ganha atenção rapidamente em sistemas focados na privacidade, porque as verificações de provas não são um detalhe secundário. Fazem parte da maquinaria central que impede, desde logo, que transferências inválidas sejam aceites. Um bug num pool antigo, mas ainda um risco real A vulnerabilidade foi divulgada por Alex “Scalar” Sol a 23 de março, com o relatório público a ser lançado na terça-feira. A área afetada não era o principal caminho de privacidade em uso hoje, que a maioria dos utilizadores tem em mente, mas sim o pool Sprout mais antigo, que já foi descontinuado. Ainda assim, descontinuado não significa inofensivo. Se os fundos ainda estiverem lá, a superfície de ataque continua relevante. O que tornou a falha especialmente sensível foi a possibilidade de transações inválidas conseguirem passar uma etapa crítica de validação. Em termos práticos, isso poderia ter aberto a porta ao esvaziamento de fundos do pool sem que a rede detetasse o problema onde deveria detetá-lo. A Zcash diz que os fundos continuam seguros Por enquanto, a parte importante é esta. O bug foi corrigido antes de qualquer exploração conhecida, e a divulgação afirma que todos os fundos dos utilizadores continuam seguros. Isso deverá acalmar o pânico imediato, embora não apague a lição mais ampla. Componentes legados em sistemas de criptografia têm o hábito de continuar economicamente relevantes muito tempo depois de o ecossistema ter seguido em frente mentalmente. Pools antigos, lógica aposentada, caminhos de código descontinuados — essas coisas continuam a importar quando ativos reais permanecem ligados. Para a Zcash, o episódio tem menos a ver com danos visíveis e mais com o valor de detetar uma falha séria de validação antes de se transformar numa. Em segurança de blockchain, por vezes a história mais importante é o exploit que nunca chegou sequer a ter a oportunidade.