#MultiversXPlansHardForkRecovery A Um bug de atomicidade no nível da VM empurrou a MultiversX para uma paralisação total da rede — agora o hard fork está sendo testado como caminho de recuperação.
• A MultiversX identificou a causa raiz como um problema de atomicidade no nível da VM envolvendo um erro de ordenação em um caso específico de borda.
• Os validadores interromperam a progressão da rede para conter o incidente e evitar impactos adicionais.
• A equipe preparou mudanças no código e está testando o procedimento de recuperação.
• A recuperação planejada é um hard fork coordenado a partir de um checkpoint previamente conhecido e considerado bom.
• Espera-se que os validadores ensaiem o procedimento no Testnet e no Devnet antes da recuperação no mainnet.
• Os usuários foram orientados a não enviar nem reenviar transações e a evitar depósitos e saques de EGLD/ESDT por meio de exchanges e bridges até o anúncio oficial de “tudo liberado”.
É aqui que acho que a história fica mais interessante.
O hard fork em si não é a parte que estou observando com mais atenção. O teste real é se a MultiversX consegue restaurar a rede de forma limpa, preservando o estado legítimo e removendo as alterações inválidas criadas pelo exploit.
Isso parece simples no papel. Não é.
Uma recuperação como esta precisa alinhar validadores, exchanges, bridges, provedores de infraestrutura e usuários em torno do mesmo estado da cadeia. Um único elo fraco pode transformar uma recuperação técnica em um problema operacional.
Por isso, estou menos interessado no título “hard fork chegando” e mais interessado em saber se o processo de recuperação realmente funciona sob condições reais e coordenadas.
Isso me diz muito mais sobre a resiliência da rede do que o anúncio de reinício em si.
Ainda tentando entender o que isso realmente muda.
• A MultiversX identificou a causa raiz como um problema de atomicidade no nível da VM envolvendo um erro de ordenação em um caso específico de borda.
• Os validadores interromperam a progressão da rede para conter o incidente e evitar impactos adicionais.
• A equipe preparou mudanças no código e está testando o procedimento de recuperação.
• A recuperação planejada é um hard fork coordenado a partir de um checkpoint previamente conhecido e considerado bom.
• Espera-se que os validadores ensaiem o procedimento no Testnet e no Devnet antes da recuperação no mainnet.
• Os usuários foram orientados a não enviar nem reenviar transações e a evitar depósitos e saques de EGLD/ESDT por meio de exchanges e bridges até o anúncio oficial de “tudo liberado”.
É aqui que acho que a história fica mais interessante.
O hard fork em si não é a parte que estou observando com mais atenção. O teste real é se a MultiversX consegue restaurar a rede de forma limpa, preservando o estado legítimo e removendo as alterações inválidas criadas pelo exploit.
Isso parece simples no papel. Não é.
Uma recuperação como esta precisa alinhar validadores, exchanges, bridges, provedores de infraestrutura e usuários em torno do mesmo estado da cadeia. Um único elo fraco pode transformar uma recuperação técnica em um problema operacional.
Por isso, estou menos interessado no título “hard fork chegando” e mais interessado em saber se o processo de recuperação realmente funciona sob condições reais e coordenadas.
Isso me diz muito mais sobre a resiliência da rede do que o anúncio de reinício em si.
Ainda tentando entender o que isso realmente muda.