A atualização do mainnet da Solana reduziu silenciosamente a latência de confirmação
A atualização do cluster v1.18.x da Solana e as alterações de recompensa SIMD-0123 reduziram a latência média de confirmação otimista de cerca de 480 ms para 240 ms. Veja o que mudou sob o capô.
Na noite de 18 de abril, o cluster mainnet-beta da Solana ultrapassou o limite de participação para o cliente v1.18.15 com pouco alarde e sem post de anúncio. Na manhã seguinte, os validadores que executavam o Jito-Solana relatavam tempos médios de confirmação otimista de cerca de 240 ms, uma queda da faixa de 460–500 ms que definia a Solana durante a maior parte de 2025. A mudança foi o resultado cumulativo de três propostas aprovadas — SIMD-0123 sobre distribuição de recompensas de bloco, SIMD-0096 sobre processamento de taxas de prioridade e um conjunto mais silencioso de correções para a contagem de créditos de voto do TowerBFT — implementadas sob uma única porta de funcionalidade. Ninguém realizou um evento de lançamento. O cluster simplesmente ficou mais rápido.
O que está em jogo é a parte da Solana que os usuários realmente sentem: não a capacidade teórica, mas a lacuna percebida entre clicar em uma troca no Jupiter e ver a confirmação. Para os ambientes DeFi que operam na rede — contratos perpétuos no Drift, o livro de ordens no Phoenix e os cofres de produtos estruturados na Adrastea — reduzir a janela de confirmação otimista altera a economia de formação de mercado. Para as carteiras, altera a promessa de UX. E para a economia de validadores, redefine quem ganha o que durante a congestão. O número principal, 240 ms, é a peça mais importante da notícia de infraestrutura da Solana do trimestre, e quase ninguém fora do Discord dos validadores notou (o regulador relevante em Portugal é a CMVM).
Duas confirmações, um cluster: por que o caminho importa
Antes da v1.18, os clientes da Solana expuseram dois caminhos de confirmação distintos. O primeiro, “confirmação otimista”, é ativado quando uma supermaioria de créditos de voto ponderados por participação chega a um determinado fork dentro do período de bloqueio do TowerBFT. O segundo, “fundamentado” (rooted), é ativado apenas quando esse fork está com profundidade de 32 slots e finalizado através do pipeline de consenso. A latência otimista é o que as carteiras mostram aos usuários; a latência fundamentada é o que as bridges e as exchanges aguardam. A documentação de consenso descreve ambos, mas a assimetria prática — a otimista é rápida e probabilística, a fundamentada é lenta e final — sempre foi a troca central de UX da Solana.
A linha v1.18 não alterou a arquitetura desses caminhos. Alterou a contenção em torno deles. As transações de voto na Solana partilham o mesmo planeador que as transações de usuário e, em um bloco congestionado, o líder historicamente teve que fazer escolhas difíceis sobre quais votos incluir. Votos tardios significam confirmação otimista atrasada. As alterações SIMD-0123, aprovadas no comportamento do cluster no slot 261.498.112, colocam a inclusão de votos antes das transações de taxa de prioridade no queue do planeador e reservam uma fatia fixa de computação do bloco para elas. O efeito, observável nos dashboards Dune em 48 horas, foi que a variância na latência de confirmação otimista colapsou.
Os números, antes e depois
| Métrica | v1.17.31 (Março 2026) | v1.18.15 (Maio 2026) | Alteração |
|---|---|---|---|
| Confirmação otimista, p50 | 478 ms | 241 ms | −49.6% |
| Confirmação otimista, p99 | 1.840 ms | 612 ms | −66.7% |
| Fundamentada (finalizada), p50 | 12.8 s | 12.6 s | estável |
| Taxa de inclusão de voto-tx por slot | 71% | 96% | +25 pp |
| Taxa de slot omitido, 7 dias | 4.8% | 3.1% | −1.7 pp |
Os dois números que importam são o colapso do p99 e a finalidade estável. O número p99 diz o que os 1% de usuários com pior experiência vivenciam — o trader que clicou em “confirmar” exatamente quando um lançamento do Pump.fun saturou o queue do líder. Reduzir isso de 1,8 segundos para menos de 700 ms remove a pior categoria de falha de UX na rede. O número de finalidade estável é o alívio: nada mudou no modelo de segurança. A confirmação fundamentada ainda é condicionada pela mesma disciplina de bloqueio de 32 slots que o TowerBFT usa desde 2020. A Solana ficou mais rápida na superfície e manteve-se a mesma no núcleo.
SIMD-0123 e a reescrita do planeador
O SIMD-0123 foi elaborado por engenheiros principais da Anza, a equipe que se desdobrou da Solana Labs em 2024, com revisão da equipe Jito. A proposta está no repositório solana-improvement-documents como uma especificação de 14 páginas e contém duas ideias estruturalmente separadas. A primeira é uma prioridade determinística para votos de consenso dentro do planeador da fase bancária. Os votos são marcados com um tipo de transação distinto e roteados por um pipeline paralelo; as transações de usuário não podem mais expulsá-los. A segunda é uma redistribuição de recompensas: uma parte das taxas de prioridade que antes acumulavam exclusivamente ao líder do bloco é agora redistribuída entre o conjunto de votos ativo, ponderada pela penalidade de atraso que cada validador evitou.
Essa segunda parte é a politicamente interessante. Os validadores da Solana gastaram dois anos argumentando sobre a captura de MEV e o papel do cliente de leilão da Jito, que agora opera em cerca de 92% da participação. O SIMD-0123 não abole o leilão. Altera o incentivo: líderes que atrasam a inclusão de votos para maximizar sua própria receita de taxas de prioridade agora perdem uma parte dessas taxas para validadores que votaram no tempo. Em efeito, a Solana introduziu uma penalidade suave para liderança egoísta sem tocar nas regras de consenso. É o tipo de mudança que exigiria um hard fork na Ethereum e um debate de seis meses com todos os desenvolvedores principais; na Solana, foi uma porta de funcionalidade que foi ativada numa quinta-feira.
Por que a equipe Firedancer foi importante, mesmo não tendo entregue
O Firedancer, a reescrita C++ da Jump Crypto do cliente de validador, não foi parte desta atualização. Sua implantação completa no mainnet permanece programada para o final de 2026 com o Frankendancer — um cliente híbrido que executa o stack de rede do Firedancer sobre o executor Rust — ativo em cerca de 4% da participação. Mas a existência do Firedancer mudou o que era politicamente possível no cliente Rust. Engenheiros da Anza falaram nas conferências Breakpoint sobre a pressão que um segundo cliente de alto desempenho impõe à implementação de referência: decisões do planeador que antes eram defendidas como “a única maneira que o Rust pode manter o ritmo” tornam-se mais difíceis de justificar quando um código paralelo C++ está sendo benchmarkado mais rápido.
A reescrita do planeador de votos que chegou na 1.18.15 copia diretamente a arquitetura da fase bancária do Firedancer, onde os pipelines de transações de voto e de usuário nunca foram acoplados desde o início. A Anza essencialmente retroportou o design mais limpo ao cliente Rust, ganhou a redução de latência e reduziu a lacuna que o Firedancer deveria abrir. Se isso atrasa a proposta de valor do Firedancer é agora um tópico de debate silencioso entre os operadores de validadores que falamos para esta peça, nenhum dos quais falou em registro. A dinâmica competitiva entre dois clientes de produção, no entanto, está produzindo uma rede mais rápida para os usuários finais, independentemente.
O que isso muda para ambientes DeFi
Reduzir a latência de confirmação otimista não é apenas mais agradável. Altera os parâmetros que os formadores de mercado incorporam em suas cotações. Um ambiente de perpétuos como o Drift, que depende de atualizações de oráculo chegarem dentro de uma janela estreita antes de liquidações serem acionadas, pode agora reduzir a margem de segurança que exige nessas impressões de oráculo. A equipe ainda não publicou um modelo de risco atualizado, mas o repositório relevante Drift-protocol mostra commits na última quinzena reduzindo o limite de estagnação do oráculo padrão de 25 slots para 12. O CLOB do Phoenix, que cruza ordens dentro de um único slot quando ambos os lados chegarem na mesma fase bancária, vê spreads menores porque seus formadores podem atualizar cotações duas vezes mais frequentemente sem perder certeza posicional.
- UX da carteira: Phantom e Solflare agora exibem “confirmado” em cerca de 250 ms após a submissão para a transação mediana.
- Economia de bridges: o conjunto de guardiões do Wormhole consulta slots finalizados, não confirmações otimistas, portanto a finalidade cross-chain permanece inalterada em ~14 s.
- Staking líquido: as fronteiras de época dos pools de participação da Marinade e Jito veem contabilidade de desvinculação mais estreita porque os créditos de voto acumulam mais previsivelmente.
- Infraestrutura de bots de trading: searchers que executam streams gRPC Helius ou Triton agora veem uma distribuição de latência mais plana, reduzindo o valor de máquinas co-localizadas.
A parte que os materiais de marketing não vão incluir
Existe um custo. Reservar computação do bloco para votos significa que há menos disponível para tudo o resto sob carga de pico. Durante o lançamento do token FORM em 22 de abril — o primeiro evento de congestão importante após a chegada da atualização — as taxas de chegada de transações de usuário caíram para cerca de 38% durante os primeiros 90 segundos do lançamento, contra uma figura histórica comparável de 52% durante o lançamento do GOAT no final de 2025. A prioridade determinística de votos funciona exatamente como projetada: quando a rede está saturada, os votos entram e as transações de usuário aguardam. Essa troca foi o ponto implícito do SIMD-0123 e não é inequivocamente boa para todos.
A outra consequência silenciosa é para o ranking de recompensas de validadores. A cláusula de redistribuição moviu cerca de 0,4% da receita semanal de taxas dos líderes do décimo superior (principalmente alinhados à Jito, principalmente executando forks otimizados da fase bancária) para o validador mediano. Esse é um número pequeno em termos absolutos e estrutural em termos relativos: é a primeira vez que o protocolo Solana usou seu próprio mecanismo de recompensa para penalizar comportamento que antes era apenas desaprovado. Esperamos que a próxima rodada de SIMDs — a lista de rascunhos públicos agora tem onze propostas em discussão ativa — estenda esse padrão. Para mais contexto sobre como a economia de validadores muda entre ciclos, nosso dashboard de mercado acompanha semanalmente a curva de rendimento ponderada por participação.
O que observar a seguir
Três coisas vale a pena acompanhar nas próximas duas épocas. A primeira é se o v1.18.15 mantém seus números de latência através de um evento de congestão sustentado de mais de duas horas; o lançamento do FORM foi um pico breve, não um teste de estresse. A segunda é o rascunho SIMD-0156, que propõe estender a ideia de prioridade do planeador de votos para transações de atualização de oráculo originadas dos programas Pyth e Switchboard — uma exclusão muito maior e mais politicamente carregada. A terceira é o roteiro do mainnet do Firedancer, agora que a lacuna entre ele e o cliente de referência diminuiu. A cultura de engenharia da Solana sempre foi disposta a entregar mudanças difíceis rapidamente; esta atualização é um lembrete que o roteiro da rede ainda é definido pelo que suas equipes principais podem aprovar, não pelo que seu departamento de marketing anuncia. Para traders que observam a implicação na liquidez, nosso rastreador de taxas de prioridade atualiza a cada slot, e a próxima chamada de desenvolvedores da Anza está no nosso calendário de eventos.