A Polygon Labs corrigiu várias falhas de segurança em sua rede proof-of-stake por meio de dois hard forks coordenados, incluindo uma vulnerabilidade que poderia ter forçado o conjunto completo de validadores a realizar processamento custoso a partir de uma única transação manipulada.
Resumo
- A Polygon corrigiu várias vulnerabilidades de segurança do PoS por meio dos hard forks Austin e Kyoto antes de divulgar publicamente as correções.
- O fork Austin fechou dois caminhos de negação de serviço, incluindo um que poderia permitir que um produtor de bloco malicioso derrubasse nós pares.
- O fork Kyoto corrigiu uma falha que poderia forçar o conjunto de validadores da Polygon a realizar processamento custoso a partir de uma única transação manipulada.
- A Polygon disse que nenhuma das vulnerabilidades foi explorada na mainnet, enquanto ambas as atualizações agora são obrigatórias para operadores de nós.
A Equipe de Suporte de Validadores da Polygon divulgou as correções em uma postagem no fórum em 27 de agosto, depois que os hard forks Austin e Kyoto já haviam sido testados e ativados. A equipe disse que as correções de segurança que afetam o consenso foram implantadas em privado, validadas na testnet Amoy e divulgadas somente depois que a frota da mainnet foi protegida.
As vulnerabilidades afetaram o Bor, o cliente de execução do Polygon PoS, e o Heimdall, que lida com a coordenação de validadores e outras funções de consenso. A Polygon disse que não encontrou evidências de que qualquer um dos problemas tenha sido explorado ou causado interrupção na mainnet.
Hard forks da Polygon fecham falhas de processamento de blocos
O hard fork Austin atualizou o Bor para a versão 2.10.0 e abordou dois caminhos de negação de serviço relacionados ao processamento de blocos.
Um envolvia eventos de sincronização de estado usados para depósitos de ponte L1-para-L2. Tais eventos podem executar código de contrato e pré-compilações, mas sua execução não estava sujeita a um limite efetivo de gás por bloco. Austin introduziu um limite sobre quanto gás os eventos de sincronização de estado podem consumir dentro de um bloco, impedindo que esgotem os recursos de processamento.
Uma fraqueza separada envolvia dados TxDependency usados durante o processamento de blocos. Um produtor de bloco malicioso poderia fornecer um campo de dados superdimensionado, potencialmente causando alocação excessiva de memória e derrubando nós pares que processam o bloco.
A Polygon descreveu ambos os problemas como vetores de negação de serviço no processamento de blocos, em vez de falhas de correção de consenso, e disse que nenhum deles causou interrupção conhecida antes da implantação das correções.
O hard fork Kyoto, que moveu o Heimdall para a versão 0.11.0, cobriu um grupo maior de correções de validação de entrada e endurecimento de consenso.
Entre elas, a Polygon identificou campos google.protobuf.Any profundamente aninhados como a vulnerabilidade mais grave do lote. As transações do Heimdall podem envolver mensagens dentro de campos Any, que por sua vez podem ser aninhados uns dentro dos outros.
Sem um limite de profundidade, um atacante poderia construir uma transação contendo campos profundamente aninhados a um custo relativamente baixo, enquanto forçaria cada validador que a processa a realizar um trabalho substancial de decodificação. A Polygon disse que a falha fornecia uma rota sem permissão para impor processamento custoso e coordenado em todo o conjunto de validadores.
Kyoto adicionou uma varredura em nível de byte que rejeita transações quando o aninhamento excede um limite definido. A verificação se aplica tanto na admissão ao mempool quanto no estágio de processamento de consenso, para que a mesma transação não possa ser aceita por um caminho e rejeitada por outro.
Outras correções do Heimdall cobriram contabilidade de marcos, processamento de checkpoints e replay de eventos L1. A criação de span futuro com falha agora pode degradar e tentar novamente no próximo limite, em vez de bloquear um commit de marco, enquanto novas chaves de replay abordam um caso extremo em que eventos L1 distintos poderiam colidir.
Nós mais antigos da Polygon caíram do consenso
Ambos os hard forks são obrigatórios para operadores que desejam permanecer na rede canônica Polygon PoS.
Bor v2.10.0 é necessário para todos os nós, enquanto Heimdall v0.11.0 se aplica a validadores e nós completos. A Polygon disse que operadores que executam versões anteriores às alturas de ativação já se separaram do consenso canônico e devem atualizar seu software para se juntar novamente à rede.
As mudanças foram entregues como atualizações binárias, o que significa que os operadores não precisam migrar estado, modificar a configuração de gênese ou realizar uma ressincronização completa. Nós que caíram do consenso podem atualizar e reverter para a altura apropriada antes do hard fork antes de alcançar a cadeia canônica.
A Polygon já usou hard forks anteriormente para resolver problemas que afetam sua infraestrutura PoS. Em setembro de 2025, os desenvolvedores executaram um hard fork depois que um bug de software causou atrasos na finalidade das transações de até 15 minutos.
O incidente anterior afetou a sincronização dos validadores e a finalidade rápida local, enquanto a produção de blocos e o checkpointing da Ethereum continuaram. As atualizações Bor e Heimdall foram implantadas para restaurar o processamento de marcos, a sincronização de estado e a finalização por consenso.
Um mês depois, a atualização da mainnet Rio introduziu validação stateless baseada em testemunhas e um modelo de Produtor de Blocos Eleito por Validadores, enquanto a Polygon continuava mudando a forma como sua rede PoS processa e verifica transações.
A Polygon continuou mudando sua infraestrutura PoS
O desempenho da rede permaneceu outro foco em 2026. Em maio, a crypto.news relatou anteriormente que a Polygon havia reduzido o tempo de bloco para uma média de 1,75 segundos, sua primeira redução no tempo de bloco desde o lançamento.
O engenheiro de software da Polygon, Lucca Martins, disse na época que a mudança elevou o throughput teórico para aproximadamente 3.260 transações por segundo e permitiu que a rede processasse cerca de 14% mais pagamentos por segundo. O trabalho fez parte do esforço da Polygon para suportar maiores volumes de transações de pagamentos com stablecoins e atividades de finanças descentralizadas.
As últimas correções de segurança chegaram depois que a Polygon concluiu a substituição de MATIC por POL como token nativo de gás e staking em sua rede PoS. A migração começou em setembro de 2024 como parte do roteiro Polygon 2.0, com MATIC mantido diretamente na Polygon PoS convertido para POL na proporção de um para um.
O plano original de MATIC para POL designou POL como o token usado para pagamentos de gás e staking, enquanto suas funções propostas deveriam se expandir à medida que a Polygon desenvolvesse sua arquitetura de staking e cadeias agregadas.
As mudanças se estenderam à própria Polygon Labs. Em julho, a empresa cortou outra rodada de empregos enquanto concluía a integração da exchange de criptomoedas Coinme. O CEO Marc Boiron disse que a reestruturação foi projetada para apoiar a lucratividade até 2027, enquanto a Polygon Labs avançava em direção a um modelo de negócios focado em pagamentos.
POL mostrou pouca reação positiva à divulgação de segurança. O token estava sendo negociado perto de US$ 0,09983 em 30 de agosto, queda de cerca de 2,3% nas últimas 24 horas e 6,8% em sete dias, de acordo com dados da CoinGecko fornecidos com o relatório. Seu preço permaneceu cerca de 60,8% menor do que um ano antes, dando ao token uma capitalização de mercado de aproximadamente US$ 1,07 bilhão.
