Caio

SolanaRepro

SolanaRepro · Hackathon Solana & Cursor

Imagine que um bug aconteceu em uma transação real da Solana. A blockchain guarda o resultado, como um recibo, mas esse recibo nem sempre traz todo o contexto histórico que produziu o problema. Sem essas informações, uma tentativa de repetição pode parecer correta e ainda assim usar dados da hora errada. O SolanaRepro é uma infraestrutura open source de reprodução forense de transações Solana. Ele reúne as evidências disponíveis, registra a origem de cada dado, verifica se o contexto histórico é suficiente, reexecuta localmente os casos suportados e compara o novo resultado com a execução original da mainnet. O objetivo inicial é transformar incidentes reais em testes de regressão portáteis, para que equipes consigam detectar se o mesmo problema voltar no futuro. A principal diferença do projeto é saber quando não executar. Quando existem evidências suficientes, o caso pode ser classificado como EXACT dentro dos campos comparados. Quando falta estado histórico confiável, o sistema retorna UNSUPPORTED e explica o motivo. Ele nunca usa o estado atual fingindo que é o estado do passado. O MVP já está funcionando como ferramenta de linha de comando. Ele possui captura, inspeção, replay local, comparação, verificação, bundles portáteis, relatórios forenses em JSON e HTML e integração com CI. O suporte atual cobre transferências SOL, transferências SPL clássicas e falhas determinísticas. Casos ainda fora do limite, como ALT e CPI complexa, são recusados de forma explícita. A demo offline mostra os dois lados: uma transferência reproduzida como EXACT e uma transação histórica recusada como UNSUPPORTED por falta de evidência suficiente. O release candidate atual passou em 431 testes Node, 2 testes Rust e uma validação em checkout Windows limpo. O corpus demonstrável contém quatro reproduções EXACT e duas recusas seguras. Esses resultados são evidências do mantenedor e ainda não representam validação independente ou suporte universal. Os próximos passos são validar provedores de estado histórico, publicar um benchmark com 100 transações reais e tornar os bundles mais fáceis de compartilhar em pipelines de CI. Depois disso, o suporte será ampliado uma classe de transação por vez, sempre preservando o mesmo limite de confiança.