- Polygon aplicou hard forks Austin e Kyoto sem avisar validadores previamente
- Falhas atingiam clientes Bor e Heimdall com risco de negação de serviço
- Equipe afirma que nenhuma vulnerabilidade chegou a ser explorada em produção
A equipe de desenvolvimento da Polygon revelou que corrigiu, em segredo, um conjunto de vulnerabilidades sérias nos clientes Bor e Heimdall antes de comunicar a comunidade. As correções foram entregues por meio de dois hard forks — Austin e Kyoto — ativados sem aviso prévio a usuários e validadores, prática incomum em redes públicas de grande porte.
O comunicado partiu do Validator’s Support Team da rede e detalhou brechas que iam de exaustão de recursos em validadores a falhas no processamento de checkpoints e milestones. Segundo o time, nenhuma delas foi explorada em produção, mas o potencial de dano justificava a correção silenciosa.
O primeiro hard fork, batizado de Austin, mirou duas vulnerabilidades de denial-of-service (DoS) no cliente Bor, responsável pela execução na camada 2. Nenhuma era problema de consenso, então a mainnet nunca correu risco de fork indesejado — mas o desempenho podia travar em blocos maliciosos.
O ponto mais delicado envolvia os chamados state-sync events, que são depósitos vindos da L1 do Ethereum. Esses eventos executam código de contrato como transações normais, só que o gás consumido não tinha teto rígido. Um bloco carregado com muitos desses eventos, ou um único evento propositalmente caro, podia congelar temporariamente o processamento da cadeia.
Austin ainda removeu o campo TxDependency da camada de rede. A intenção foi garantir que a execução paralela de transações não dependa de dicas dadas pelo produtor de bloco — algo que poderia ser manipulado por atores mal-intencionados para induzir erros.
- Leia também: Banco Central: trava de 24 horas reduz eficiência das stablecoins e pode atrasar Brasil, diz Fireblocks
Polygon: Kyoto reforça o Heimdall contra trabalho forçado
O segundo hard fork, Kyoto, concentrou o grosso das mudanças no Heimdall, cliente que cuida da camada de consenso e da comunicação com a L1. Antes do upgrade, certas transações podiam obrigar validadores a executar trabalho pesado e correlacionado, gerando lentidão em toda a rede.
Entre os ajustes estão um teto para a contagem de fee-coins, normalização do byte de recuperação em assinaturas de checkpoint, limitação da votação em milestones ao hash do bloco pai assinado e a criação não bloqueante de future-spans. O time chamou de mais grave o problema no decode aninhado de mensagens Any, que abria caminho permissionless para forçar processamento caro em todo o conjunto de validadores.
“O restante dos itens fortalece a finalidade dos checkpoints, a contabilidade dos milestones e a repetição de eventos da L1 contra pressão de recursos”, escreveu a equipe no fórum oficial da rede. Todas as correções, segundo o texto, foram validadas antes da ativação de cada hard fork.
A escolha de aplicar patches sem aviso prévio segue uma prática conhecida como silent patching, adotada por projetos como Bitcoin Core em situações críticas. A lógica é evitar que a divulgação da falha em janela aberta permita a exploração antes que validadores atualizem seus nós. O trade-off é claro: a comunidade fica sem informação sobre riscos aos quais esteve exposta.
