A Polygon Labs ordenou aos operadores de nós que executam binários pré-hardfork que atualizem imediatamente, após a sua revisão de segurança de 27 de agosto ter confirmado que os nós Bor abaixo de v2.10.0 e os nós Heimdall abaixo de v0.11.0 já não seguem o consenso canónico. O Austin foi ativado no bloco 91.949.700 da mainnet no lado do cliente de execução, enquanto o Kyoto foi ativado na altura 51.533.000 a 18 de agosto às 10:10:31 UTC para a camada de consenso.
Por que razão importa
O Austin encerrou dois caminhos de exaustão de recursos no Bor. O primeiro limitou o gás que o Bor consome ao processar eventos de state-sync provenientes de depósitos da ponte L1-to-L2, uma vez que essas chamadas eram anteriormente executadas fora do teto de gás do bloco e podiam bloquear o processamento se chegassem eventos em número suficiente. O segundo removeu o campo de dados extra TxDependency do Bor após os investigadores terem demonstrado que um produtor podia inserir um blob excessivamente grande nesse campo e derrubar nós pares que processavam um bloco irmão. A Polygon afirmou que não observou perturbações na mainnet causadas pelo Austin e enquadrou as alterações como correções proativas.
A correção de maior severidade do Kyoto adicionou uma verificação de aninhamento ao nível do byte em mensagens google.protobuf.Any no Heimdall, encerrando um vetor no qual uma única transação barata podia forçar todos os validadores a gastar muitos recursos em decodificação. O Kyoto também limitou as listas de fee coins antes de uma validação O(n) (o Heimdall permite uma fee coin), normalizou os bytes de recuperação de assinaturas de checkpoint para que uma assinatura válida não possa falhar a recuperação na Ethereum, tornou idempotentes as mensagens repetidas de indisponibilidade do produtor, restringiu os votos do intervalo de milestones ao hash do progenitor assinado, impediu que criações falhadas de future-span bloqueassem o compromisso de milestones e tornou injetivas as chaves de repetição para eventos topup, clerk e stake em índices de registo fora do intervalo. Uma perturbação de RPC de cerca de uma hora anteriormente reportada ficou ligada a uma correção urgente do Heimdall neste mesmo caminho de código.
Impacto no mercado
Ambos os hardforks são simples atualizações binárias sem migração de estado nem alteração de génesis, pelo que os nós que atualizaram dentro do prazo não têm nada a fazer. Os operadores que já ultrapassaram a altura relevante num cliente mais antigo têm de instalar a versão aplicável, retroceder para um bloco pré-hardfork se necessário e ressincronizar sob a orientação da Polygon.
Perguntas frequentes
-
O que precisam de fazer os operadores de nós após os hardforks Austin e Kyoto?
Os operadores que executam Bor abaixo de v2.10.0 ou Heimdall abaixo de v0.11.0 têm de instalar a versão mais recente, retroceder para um bloco pré-hardfork se necessário e ressincronizar sob a orientação da Polygon. Os nós que já atualizaram dentro do prazo não precisam de qualquer ação.
-
Quando foram ativados o Austin e o Kyoto na mainnet Polygon PoS?
O Austin foi ativado no bloco 91.949.700 no lado do cliente de execução. O Kyoto foi ativado na altura 51.533.000 a 18 de agosto às 10:10:31 UTC para a camada de consenso. Ambas as alturas de ativação já foram ultrapassadas.
-
O que corrigiu o hardfork Austin na Polygon PoS?
O Austin limitou o gás que o Bor consome ao processar eventos de state-sync de depósitos da ponte L1-to-L2 e removeu o campo de dados extra TxDependency, que não tinha limite de tamanho e podia permitir a um produtor derrubar nós pares com um blob excessivamente grande. A Polygon classificou ambos como riscos de…
-
Qual foi a correção de maior severidade do Kyoto?
O Kyoto adicionou uma verificação de aninhamento ao nível do byte em mensagens google.protobuf.Any no Heimdall, encerrando um vetor onde uma única transação barata podia forçar todos os validadores a gastar muito em decodificação. Uma perturbação de RPC de cerca de uma hora anteriormente reportada ficou ligada a uma…
-
Estes hardforks exigem migração de estado ou ressincronização do zero?
Não. Ambos são simples atualizações binárias sem migração de estado nem alteração de génesis. Os nós que não tinham divergido não necessitam de ressincronização, embora os operadores que já ultrapassaram a altura relevante num cliente mais antigo tenham de retroceder e ressincronizar sob a orientação da Polygon.
Crypto News
WatcherGuru
WuBlockchain
CoinDesk