Revelação de dados: Transferências na Solana estão mais lentas, será que os validadores estão a "fazer coisas"?

Autor: Carlos 、 Luke Leasure

Título original: Solana’s block-building wars

Compilação e organização: BitpushNews

5 de janeiro de 2026, JITO lançou uma ferramenta pública chamada IBRL Explorer, com o objetivo de medir o comportamento de validação de blocos na Solana e revelar o que antes era invisível na “jogada de timing” na construção de blocos.

Primeiro, precisamos entender alguns conceitos de estrutura de mercado da Solana. A Solana foi projetada como um sistema de processamento em fluxo: idealmente, enquanto um bloco está sendo construído, o líder transmite continuamente fragmentos de dados (ou seja, pequenos pacotes de dados). Essa abordagem visa minimizar o atraso na confirmação de transações (ou seja, o tempo entre o recebimento de uma transação por um validador e sua efetiva validação). No entanto, a continuidade do pipeline de transações da Solana depende de como os validadores montam seus blocos.

Jito define o comportamento ótimo de empacotamento de blocos do ponto de vista do validador: construção rápida, transmissão contínua e propagação precoce do estado. A pontuação IBRL de Jito é uma combinação ponderada desses três fatores:

• Slot Time (35%): se o bloco do validador for concluído dentro de um limite, ele recebe uma pontuação mais alta: se a troca de slot de outro validador for inferior a 550 ms, ou se o slot for contínuo (ou seja, o líder ainda está na rodada de slots) e for inferior a 380 ms.
• Empacotamento de transações não-votantes (40%): quando as transações estão distribuídas uniformemente entre os 64 ticks do slot (em vez de serem agrupadas nos últimos ticks, ou seja, “empacotamento com atraso”), o validador recebe uma recompensa de pontos. Essa é a variável mais controversa na pontuação IBRL, que será explicada em detalhes a seguir.
• Voto precoce (25%): quando pelo menos 90% das transações de voto são processadas nos primeiros 32 ticks, o validador recebe a pontuação máxima. Se os votos forem atrasados para uma parte posterior do bloco, a pontuação diminui.

O IBRL Explorer mostra que muitos validadores apresentam atrasos no empacotamento de transações não-votantes, e em alguns casos até aumentam o tempo do slot. Esse atraso no empacotamento adia a propagação do estado, aumenta a variância dos resultados de execução, prejudica o design em fluxo da Solana e reduz a latência da rede. O que você obtém não é um fluxo contínuo de dados, mas uma explosão pontual de dados.

Em um bloco ideal, como no exemplo de um validador da Helius, a maioria das transações de voto é processada na metade inicial do bloco (“propagação precoce do estado”), enquanto as transações não-votantes estão distribuídas de forma relativamente uniforme entre os 64 ticks do slot (“transmissão contínua”).

Em contraste, o atraso intencional no empacotamento fica evidente no exemplo do bloco da Galaxy abaixo, onde a maior parte das transações não-votantes foi agrupada nos últimos ticks do slot. Essa abordagem prioriza o valor de extração ao atrasar a mudança de estado até o último momento, ao invés de priorizar a saúde da rede.

Segundo Lucas Bruder, cofundador e CEO da Jito Labs, os validadores são incentivados a esperar até o último momento do slot para observar mais transações chegando, escolher aquelas com maior taxa de pagamento e maximizar suas recompensas.

Mas por que os usuários deveriam se importar? Embora maximizar lucros seja uma estratégia racional para um validador individual, esse comportamento introduz censura implícita, atrasos na propagação do estado e força o próximo líder a “correr atrás”, desacelerando toda a rede.

Mais importante, o atraso no empacotamento também está diretamente relacionado à emergente dinâmica de “pagamentos por fluxo de ordens” (PFOF) na Solana, como já abordado por Benedict Brady neste artigo. Como carteiras e aplicativos geralmente geram transações assinadas pré-roteadas (ou seja, ordens de mercado com limite de slippage), há opções valiosas embutidas na ordem, como “execução posterior”. Para o usuário, a melhor prática é vender essa opção de execução posterior para empresas de trading, enquanto a prática de extração de valor é realizar “ataques de sanduíche”. Em qualquer caso, há um incentivo para desacelerar a confirmação das transações, aumentando o valor da execução posterior — exatamente o que o atraso no empacotamento possibilita.

Esse incentivo coloca a Solana em uma estrutura de mercado mais adversária às aplicações e usuários. Além disso, enfraquece garantias essenciais dos market makers, especialmente na reversão de blocos e na execução determinística, levando à ampliação do spread. Sem transmissão em fluxo contínuo, por mais que a lógica da aplicação seja excelente, o mercado em tempo real ainda parece distante na Solana.

Debate Temporal vs. Jito

Antes de aprofundar como a Solana pode resolver esse problema, é importante reconhecer que há um debate ativo sobre o que constitui uma “boa” construção de blocos. O principal contribuinte do Harmonic, Temporal, questiona o framework da Jito e a metodologia de pontuação IBRL. Sua crítica é que essa pontuação incorpora um conjunto de preferências de design específicas, que favorecem a abordagem de construção de blocos da Jito e, por padrão, fazem o Harmonic parecer pior, refletido na pontuação consistentemente mais baixa dos validadores que executam Harmonic.

Segundo o cofundador do Harmonic, seus blocos são construídos de forma contínua e sem atrasos, mas os fragmentos de dados só são liberados após cerca de 300 ms de leilão. Essa abordagem dá tempo suficiente para os construtores de blocos competirem e também permite que o resto da rede reprove os blocos do Harmonic. A visualização abaixo mostra um exemplo de um slot (391,822,619) de um validador que executa Harmonic, o Temporal Emerald.

Do ponto de vista de como o bloco se propaga (conforme ilustrado acima), a construção do Harmonic parece ocorrer de forma uniforme ao longo do tempo. Em outras palavras, os construtores continuam construindo blocos em paralelo, e as transações se concentram nos últimos ticks porque é o momento de resolução do leilão.

Nos últimos 30 dias, o Harmonic superou o Jito e o Firedancer em média e mediana de receita total por bloco (taxas prioritárias + gorjetas), trazendo recompensas maiores para validadores e stakers. A questão ainda pendente é se esse desempenho superior é resultado de uma jogada de timing, como descrito anteriormente, às custas dos usuários.

Fonte: https://reports.firedancer.io/

Múltiplos Proponentes Concomitantes (MCP) e BAM

Após apresentar os dois lados, uma coisa permanece clara: a transmissão contínua é fundamental.

A alegação do Harmonic não é que a transmissão em fluxo contínuo não seja importante, mas que a IBRL não captura como o Harmonic consegue isso, e pode classificar erroneamente seu mecanismo de leilão como uma “jogada de timing”. Ainda não tenho conhecimento técnico suficiente ou dados para formar uma opinião definitiva, mas a Solana já está desenvolvendo uma solução de protocolo para resolver incentivos na camada base.

Essa solução é a arquitetura de Múltiplos Proponentes Concomitantes (MCP), desenvolvida por Anatoly Yakovenko e Max Resnick. A motivação é simples: no modelo atual de líder único, um proponente controla a ordenação e pode agir mais tarde do que os demais, reforçando o atraso no empacotamento e a dinâmica de PFOF mencionada. O MCP elimina o monopólio do líder ao permitir que múltiplos proponentes construam candidatos a blocos de forma paralela e independente. Essa arquitetura impede que um líder único sufoque transações ou atrase a execução para extrair lucros.

Para isso, uma condição prévia é o lançamento do Alpenglow na mainnet. Previsto para 2026, a data ainda não está confirmada. Enquanto isso, o BAM da Jito pode impulsionar mudanças ao tornar a lógica de ordenação auditável. O BAM visa expandir o espaço de design microestrutural da Solana, permitindo aplicações que requerem controle mais refinado na ordenação, como ordens de cancelamento em plataformas de contratos perpétuos, além de ajudar a mitigar efeitos negativos de MEV externo, como ataques de sandwich. A seguir, uma visão geral da pipeline de transações do BAM.

O BAM (Agave-BAM) já é atualmente o terceiro maior cliente na Solana, com aproximadamente 12% do stake, atrás do Agave-Jito e do Frankendancer-Jito. Cerca de 205 validadores já estão rodando BAM, destacando sua rápida adoção na comunidade de validadores da Solana. Em comparação, o Harmonic ainda é relativamente pequeno, com pouco mais de 3% do stake e cerca de 20 validadores.

Vale acompanhar como a competição na construção de blocos evoluirá nos próximos meses e o que isso significa para a estrutura de mercado da Solana.