{"id":39,"date":"2026-06-25T13:45:31","date_gmt":"2026-06-25T13:45:31","guid":{"rendered":"https:\/\/hoge.gg\/pt\/solanas-mainnet-upgrade-quietly-halved-confirmation-latency\/"},"modified":"2026-06-25T13:45:31","modified_gmt":"2026-06-25T13:45:31","slug":"solanas-mainnet-upgrade-quietly-halved-confirmation-latency","status":"publish","type":"post","link":"https:\/\/hoge.gg\/pt\/solanas-mainnet-upgrade-quietly-halved-confirmation-latency\/","title":{"rendered":"A atualiza\u00e7\u00e3o do mainnet da Solana reduziu silenciosamente a lat\u00eancia de confirma\u00e7\u00e3o"},"content":{"rendered":"\r\n

Na noite de 18 de abril, o cluster mainnet-beta da Solana ultrapassou o limite de participa\u00e7\u00e3o para o cliente v1.18.15<\/a> com pouco alarde e sem post de an\u00fancio. Na manh\u00e3 seguinte, os validadores que executavam o Jito-Solana<\/a> relatavam tempos m\u00e9dios de confirma\u00e7\u00e3o otimista de cerca de 240 ms, uma queda da faixa de 460\u2013500 ms que definia a Solana durante a maior parte de 2025. A mudan\u00e7a foi o resultado cumulativo de tr\u00eas propostas aprovadas — SIMD-0123 sobre distribui\u00e7\u00e3o de recompensas de bloco, SIMD-0096 sobre processamento de taxas de prioridade e um conjunto mais silencioso de corre\u00e7\u00f5es para a contagem de cr\u00e9ditos de voto do TowerBFT — implementadas sob uma \u00fanica porta de funcionalidade. Ningu\u00e9m realizou um evento de lan\u00e7amento. O cluster simplesmente ficou mais r\u00e1pido.<\/p>\r\n\r\n\r\n\r\n

O que est\u00e1 em jogo \u00e9 a parte da Solana que os usu\u00e1rios realmente sentem: n\u00e3o a capacidade te\u00f3rica, mas a lacuna percebida entre clicar em uma troca no Jupiter e ver a confirma\u00e7\u00e3o. Para os ambientes DeFi que operam na rede — contratos perp\u00e9tuos no Drift, o livro de ordens no Phoenix e os cofres de produtos estruturados na Adrastea — reduzir a janela de confirma\u00e7\u00e3o otimista altera a economia de forma\u00e7\u00e3o de mercado. Para as carteiras, altera a promessa de UX. E para a economia de validadores, redefine quem ganha o que durante a congest\u00e3o. O n\u00famero principal, 240 ms, \u00e9 a pe\u00e7a mais importante da not\u00edcia de infraestrutura da Solana do trimestre, e quase ningu\u00e9m fora do Discord dos validadores notou (o regulador relevante em Portugal \u00e9 a CMVM).<\/p>\r\n\r\n\r\n\r\n

Duas confirma\u00e7\u00f5es, um cluster: por que o caminho importa<\/h2>\r\n\r\n\r\n\r\n

Antes da v1.18, os clientes da Solana expuseram dois caminhos de confirma\u00e7\u00e3o distintos. O primeiro, “confirma\u00e7\u00e3o otimista”, \u00e9 ativado quando uma supermaioria de cr\u00e9ditos de voto ponderados por participa\u00e7\u00e3o chega a um determinado fork dentro do per\u00edodo de bloqueio do TowerBFT. O segundo, “fundamentado” (rooted), \u00e9 ativado apenas quando esse fork est\u00e1 com profundidade de 32 slots e finalizado atrav\u00e9s do pipeline de consenso. A lat\u00eancia otimista \u00e9 o que as carteiras mostram aos usu\u00e1rios; a lat\u00eancia fundamentada \u00e9 o que as bridges e as exchanges aguardam. A documenta\u00e7\u00e3o de consenso<\/a> descreve ambos, mas a assimetria pr\u00e1tica — a otimista \u00e9 r\u00e1pida e probabil\u00edstica, a fundamentada \u00e9 lenta e final — sempre foi a troca central de UX da Solana.<\/p>\r\n\r\n\r\n\r\n

A linha v1.18 n\u00e3o alterou a arquitetura desses caminhos. Alterou a conten\u00e7\u00e3o em torno deles. As transa\u00e7\u00f5es de voto na Solana partilham o mesmo planeador que as transa\u00e7\u00f5es de usu\u00e1rio e, em um bloco congestionado, o l\u00edder historicamente teve que fazer escolhas dif\u00edceis sobre quais votos incluir. Votos tardios significam confirma\u00e7\u00e3o otimista atrasada. As altera\u00e7\u00f5es SIMD-0123, aprovadas no comportamento do cluster no slot 261.498.112, colocam a inclus\u00e3o de votos antes das transa\u00e7\u00f5es de taxa de prioridade no queue do planeador e reservam uma fatia fixa de computa\u00e7\u00e3o do bloco para elas. O efeito, observ\u00e1vel nos dashboards Dune<\/a> em 48 horas, foi que a vari\u00e2ncia na lat\u00eancia de confirma\u00e7\u00e3o otimista colapsou.<\/p>\r\n\r\n\r\n\r\n

Os n\u00fameros, antes e depois<\/h2>\r\n\r\n\r\n\r\n
M\u00e9trica<\/th>v1.17.31 (Mar\u00e7o 2026)<\/th>v1.18.15 (Maio 2026)<\/th>Altera\u00e7\u00e3o<\/th><\/tr><\/thead>
Confirma\u00e7\u00e3o otimista, p50<\/td>478 ms<\/td>241 ms<\/td>−49.6%<\/td><\/tr>
Confirma\u00e7\u00e3o otimista, p99<\/td>1.840 ms<\/td>612 ms<\/td>−66.7%<\/td><\/tr>
Fundamentada (finalizada), p50<\/td>12.8 s<\/td>12.6 s<\/td>est\u00e1vel<\/td><\/tr>
Taxa de inclus\u00e3o de voto-tx por slot<\/td>71%<\/td>96%<\/td>+25 pp<\/td><\/tr>
Taxa de slot omitido, 7 dias<\/td>4.8%<\/td>3.1%<\/td>−1.7 pp<\/td><\/tr><\/tbody><\/table>
Medidas medianas de uma amostra de 200 validadores mainnet-beta, janelas semanais. Fontes: m\u00e9tricas do cluster solana.com, telemetria jito.network.<\/figcaption><\/figure>\r\n\r\n\r\n\r\n

Os dois n\u00fameros que importam s\u00e3o o colapso do p99 e a finalidade est\u00e1vel. O n\u00famero p99 diz o que os 1% de usu\u00e1rios com pior experi\u00eancia vivenciam — o trader que clicou em “confirmar” exatamente quando um lan\u00e7amento do Pump.fun saturou o queue do l\u00edder. Reduzir isso de 1,8 segundos para menos de 700 ms remove a pior categoria de falha de UX na rede. O n\u00famero de finalidade est\u00e1vel \u00e9 o al\u00edvio: nada mudou no modelo de seguran\u00e7a. A confirma\u00e7\u00e3o fundamentada ainda \u00e9 condicionada pela mesma disciplina de bloqueio de 32 slots que o TowerBFT usa desde 2020. A Solana ficou mais r\u00e1pida na superf\u00edcie e manteve-se a mesma no n\u00facleo.<\/p>\r\n\r\n\r\n\r\n

SIMD-0123 e a reescrita do planeador<\/h2>\r\n\r\n\r\n\r\n

O SIMD-0123 foi elaborado por engenheiros principais da Anza, a equipe que se desdobrou da Solana Labs em 2024, com revis\u00e3o da equipe Jito. A proposta est\u00e1 no reposit\u00f3rio solana-improvement-documents<\/a> como uma especifica\u00e7\u00e3o de 14 p\u00e1ginas e cont\u00e9m duas ideias estruturalmente separadas. A primeira \u00e9 uma prioridade determin\u00edstica para votos de consenso dentro do planeador da fase banc\u00e1ria. Os votos s\u00e3o marcados com um tipo de transa\u00e7\u00e3o distinto e roteados por um pipeline paralelo; as transa\u00e7\u00f5es de usu\u00e1rio n\u00e3o podem mais expuls\u00e1-los. A segunda \u00e9 uma redistribui\u00e7\u00e3o de recompensas: uma parte das taxas de prioridade que antes acumulavam exclusivamente ao l\u00edder do bloco \u00e9 agora redistribu\u00edda entre o conjunto de votos ativo, ponderada pela penalidade de atraso que cada validador evitou.<\/p>\r\n\r\n\r\n\r\n

Essa segunda parte \u00e9 a politicamente interessante. Os validadores da Solana gastaram dois anos argumentando sobre a captura de MEV e o papel do cliente de leil\u00e3o da Jito<\/a>, que agora opera em cerca de 92% da participa\u00e7\u00e3o. O SIMD-0123 n\u00e3o abole o leil\u00e3o. Altera o incentivo: l\u00edderes que atrasam a inclus\u00e3o de votos para maximizar sua pr\u00f3pria 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\u00e7a ego\u00edsta sem tocar nas regras de consenso. \u00c9 o tipo de mudan\u00e7a 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.<\/p>\r\n\r\n\r\n\r\n

Por que a equipe Firedancer foi importante, mesmo n\u00e3o tendo entregue<\/h2>\r\n\r\n\r\n\r\n

O Firedancer, a reescrita C++ da Jump Crypto do cliente de validador, n\u00e3o foi parte desta atualiza\u00e7\u00e3o. Sua implanta\u00e7\u00e3o completa no mainnet permanece programada para o final de 2026 com o Frankendancer — um cliente h\u00edbrido que executa o stack de rede do Firedancer sobre o executor Rust — ativo em cerca de 4% da participa\u00e7\u00e3o. Mas a exist\u00eancia do Firedancer mudou o que era politicamente poss\u00edvel no cliente Rust. Engenheiros da Anza falaram nas confer\u00eancias Breakpoint<\/a> sobre a press\u00e3o que um segundo cliente de alto desempenho imp\u00f5e \u00e0 implementa\u00e7\u00e3o de refer\u00eancia: decis\u00f5es do planeador que antes eram defendidas como “a \u00fanica maneira que o Rust pode manter o ritmo” tornam-se mais dif\u00edceis de justificar quando um c\u00f3digo paralelo C++ est\u00e1 sendo benchmarkado mais r\u00e1pido.<\/p>\r\n\r\n\r\n\r\n

A reescrita do planeador de votos que chegou na 1.18.15 copia diretamente a arquitetura da fase banc\u00e1ria do Firedancer, onde os pipelines de transa\u00e7\u00f5es de voto e de usu\u00e1rio nunca foram acoplados desde o in\u00edcio. A Anza essencialmente retroportou o design mais limpo ao cliente Rust, ganhou a redu\u00e7\u00e3o de lat\u00eancia e reduziu a lacuna que o Firedancer deveria abrir. Se isso atrasa a proposta de valor do Firedancer \u00e9 agora um t\u00f3pico de debate silencioso entre os operadores de validadores que falamos para esta pe\u00e7a, nenhum dos quais falou em registro. A din\u00e2mica competitiva entre dois clientes de produ\u00e7\u00e3o, no entanto, est\u00e1 produzindo uma rede mais r\u00e1pida para os usu\u00e1rios finais, independentemente.<\/p>\r\n\r\n\r\n\r\n

O que isso muda para ambientes DeFi<\/h2>\r\n\r\n\r\n\r\n

Reduzir a lat\u00eancia de confirma\u00e7\u00e3o otimista n\u00e3o \u00e9 apenas mais agrad\u00e1vel. Altera os par\u00e2metros que os formadores de mercado incorporam em suas cota\u00e7\u00f5es. Um ambiente de perp\u00e9tuos como o Drift, que depende de atualiza\u00e7\u00f5es de or\u00e1culo chegarem dentro de uma janela estreita antes de liquida\u00e7\u00f5es serem acionadas, pode agora reduzir a margem de seguran\u00e7a que exige nessas impress\u00f5es de or\u00e1culo. A equipe ainda n\u00e3o publicou um modelo de risco atualizado, mas o reposit\u00f3rio relevante Drift-protocol<\/a> mostra commits na \u00faltima quinzena reduzindo o limite de estagna\u00e7\u00e3o do or\u00e1culo padr\u00e3o de 25 slots para 12. O CLOB do Phoenix, que cruza ordens dentro de um \u00fanico slot quando ambos os lados chegarem na mesma fase banc\u00e1ria, v\u00ea spreads menores porque seus formadores podem atualizar cota\u00e7\u00f5es duas vezes mais frequentemente sem perder certeza posicional.<\/p>\r\n\r\n\r\n\r\n