O que aconteceu

Quando se ouve "ataque", a imagem imediata é a de um cofre arrombado: alguém entrou e retirou o conteúdo. O que ocorreu aqui tem outra natureza — e compreender a diferença altera o que é possível fazer a partir dela.

Uma blockchain guarda dois elementos distintos: os tokens em si, que ficam registrados nos contratos inteligentes, e os registros que dizem a quem cada parte pertence. No incidente de abril, o ataque atingiu esses registros: números de saldo foram inflados artificialmente e usados para retirar valor que não correspondia a posições reais. O que se corrompeu foi o registro de titularidade. Por isso a referência do processo não é o registro posterior ao ataque, mas o snapshot anterior a ele.

O que está nos contratos inteligentes hoje, e o que estava antes do ataque, são duas informações públicas: a primeira é consultável no explorer da blockchain a qualquer momento; a segunda está gravada no snapshot, produzido por scripts públicos. Nenhuma das duas depende da palavra de quem desenvolve a tecnologia — as duas podem ser conferidas por qualquer pessoa, de forma independente. O que foi perdido foi a confiabilidade dos registros que apontavam quem tinha direito a quê.

Isso explica dois aspectos do processo. Primeiro, em que a recuperação se apoia: existe um retrato verificável do estado anterior ao ataque, e é contra ele que cada direito é reconstituído — não contra registros posteriores, que não são confiáveis. Segundo, por que ela é lenta e sequencial: cada reconstituição precisa ser provada contra esse retrato e confirmada on-chain, uma etapa por vez.

Sobre o limite disso, convém ser direto: a existência de uma referência verificável não é, por si, garantia de resultado. A recuperação é uma execução condicionada — cada etapa precisa se concretizar on-chain, e todas podem ser acompanhadas publicamente. É o que a lição 4 e a ponte final desta trilha demonstram.