MultiversX lança Supernova na testnet antes do mainnet
A atualização desacopla o consenso da execução e afirma uma finalização em shard de 100–250 ms para DeFi sensível à latência.
A MultiversX lançou sua atualização "Supernova" na testnet, redesenhando a produção de blocos para que os validadores possam concordar sobre os blocos antes que as transações sejam executadas. A equipe está visando blocos de ~600 milissegundos e finalidade em shard de 100–250 milissegundos, com a ativação da mainnet esperada para 10 de setembro de 2026.
Supernova Chega à Testnet Com uma Mudança de Mainnet Esperada para 10 de Setembro
Supernova agora está ativa na testnet da MultiversX, com a mesma arquitetura também rodando na devnet, enquanto a rede avança em direção a um pipeline de execução assíncrona que é explicitamente projetado para manter o consenso em movimento mesmo quando a execução da transação ainda está se recuperando.
O cronograma declarado é apertado e específico. A Supernova tem produzido blocos de ~600 milissegundos na testnet e na devnet desde 20 de agosto, e a rede está trabalhando em direção a uma data de ativação da mainnet esperada para 10 de setembro de 2026.
A atualização é enquadrada como uma resposta a um teto de escalabilidade familiar para cadeias de alto desempenho: quando a execução da transação está no caminho crítico do consenso, a computação mais lenta se torna o carro de ritmo do sistema. A aposta da MultiversX é que a próxima mudança de passo na latência vem da mudança na ordem das operações, não apenas da otimização da propagação e da finalidade.
Consenso e Execução Desacoplados: As Metas de Latência e o Novo Problema de Validade
A mudança central da Supernova é mecânica: ela "desacopla o consenso da execução para que a rede possa concordar sobre os blocos antes de processar suas transações", deslocando a execução para fora do caminho crítico do consenso e para uma fase assíncrona que ocorre após os validadores já terem votado.
Antes da atualização, o fluxo era sequencial. Um proponente selecionava transações, as executava localmente e propunha um bloco com as transições de estado resultantes, então os validadores reexecutavam essas transações antes de votar.
Sob a Supernova, "O proponente seleciona transações e propõe o bloco sem executá-las primeiro," e "Os validadores verificam se a proposta segue as regras do protocolo e podem votar imediatamente, enquanto a execução continua assíncrona em segundo plano."
Essa reordenação é o que torna as metas de latência plausíveis em teoria. A saída da execução é "normalmente referenciada e notariada no cabeçalho do próximo bloco," o que significa que a execução fica atrás do consenso em cerca de um bloco, ou cerca de 600 milissegundos.
Na prática, a arquitetura visa uma cadência em pipeline onde o consenso pode continuar produzindo blocos de ~600 ms mesmo que a execução esteja um bloco atrás, em vez de forçar cada validador a terminar a mesma computação antes que o próximo bloco possa ser finalizado.
Para os construtores, a afirmação principal é que "a finalidade em shard chega assim que a prova está disponível, geralmente dentro da mesma rodada em cerca de 100–250 milissegundos," emparelhada com "condições de execução mais previsíveis." Os casos de uso-alvo são aqueles que se degradam rapidamente quando a latência se torna visível para o usuário, incluindo primitivos de DeFi de alta frequência e livros de ordens on-chain.
O problema é a questão da validade que a execução assíncrona introduz. Se a rede votar em um bloco antes da execução, uma transação que parecia válida no momento da proposta pode se tornar inválida quando a execução a alcançar, porque os nonces e saldos das contas podem ter sido consumidos por outras atividades pendentes.
Estado Virtual do Mempool, EIE e Pressão de Retorno: Como a Supernova Tenta Manter os Blocos Seguros e os Nós Sincronizados
A primeira linha de defesa da Supernova está na camada do proponente, através de um "estado virtual do mempool" que olha além do último estado executado e rastreia nonces pendentes, consumo de saldo esperado e transações já propostas, mas ainda não executadas ou finalizadas por meio de consenso.
O objetivo é dar aos proponentes uma visão prospectiva da atividade da conta para que possam evitar incluir transações que provavelmente falharão quando a execução se atualizar.
O design também adiciona dois estranguladores explícitos destinados a evitar que a longa cauda de hardware da rede fique para trás.
O Estimador de Inclusão de Resultados de Execução (EIE) limita quantos resultados de execução podem ser referenciados em um bloco com base no que "nós de especificação mínima podem processar com segurança", e a pressão de retorno automática reduz a capacidade do bloco se a execução ficar muito atrasada, dando ao sistema tempo para se atualizar.
Esses mecanismos também são onde a incerteza relevante para o mercado reside hoje. O material descreve o pipeline e suas salvaguardas, mas não fornece referências independentes, números de throughput ou dados de teste de estresse que mostrariam se blocos de ~600 ms persistem sob cargas de transações mais pesadas e complexas.
Também não detalha, além do estado virtual do mempool e dos estranguladores, como as falhas de execução pós-consenso e transações inválidas são tratadas operacionalmente em casos extremos.
Os próximos marcos concretos são procedimentais em vez de narrativos: confirmação ou revisão da data esperada de ativação da mainnet em 10 de setembro de 2026, produção sustentada de blocos de ~600 ms na testnet/devnet à medida que a carga e a complexidade das transações aumentam, e quaisquer métricas divulgadas mostrando com que frequência os limites do EIE ou as reduções de pressão de retorno são acionados sob estresse.
Minha Leitura: Esta é uma Aposta de UX/Construtor—Mas os Traders Devem Tratar os Números como Provisórios Até a Mainnet
A parte que a maioria das pessoas interpretará mal é a alegação de latência como uma garantia de desempenho finalizada.
O que realmente foi entregue é uma mudança arquitetônica que remove a execução do caminho crítico de consenso, e essa é uma escolha de design real com um precedente claro em cadeias de alto desempenho: você obtém uma cadência de blocos mais previsível à medida que a complexidade das transações aumenta, mas herda uma nova classe de problemas de validade e backlog que só aparecem sob carga desordenada e adversarial.
O limite que importa é se a testnet/devnet pode suportar blocos de ~600 ms enquanto os estranguladores permanecem principalmente em segundo plano, porque se o EIE e a pressão de retorno estiverem constantemente engajados, o pipeline ainda é "rápido" no papel, mas restrito na prática.
Isso se torna relevante para o mercado quando a data da mainnet é confirmada e a rede pode demonstrar um comportamento de baixa latência sustentada sem que o atraso de execução rotineiro se torne o limitador dominante.
