O que são Preconfirmations (Preconfs) na Solana?

O ciclo de vida de uma transação dentro do líder

A seguir, apresentamos uma análise deliberadamente específica do ciclo de vida da transação dentro do líder, no que diz respeito a preconfirmations e observabilidade. Para uma análise completa do ciclo de vida de uma transação na Solana, consulte nossa visão geral técnica da Solana Virtual Machine (SVM).

Antes do líder

Na Solana, as transações assinadas são enviadas diretamente ao produtor do bloco (ou seja, o líder) e aos próximos líderes. Elas chegam via QUIC, com a capacidade de conexão alocada por peso de stake. Por isso, transações encaminhadas por conexões com stake têm uma probabilidade muito maior de serem aceitas sob carga.

Nesse ponto, uma transação está visível apenas para o remetente e para o nó RPC ou serviço de envio de transações que a está encaminhando aos líderes atual e futuros. 

Nada sobre o destino da transação pode ser determinado nesse estágio. 

Estágio 1: ingestão e SigVerify

A Transaction Processing Unit (TPU) do líder recebe as transações de entrada como pacotes, desserializa-as, verifica suas assinaturas e descarta eventuais duplicatas. Sob carga intensa, pacotes malformados e transações de spam são descartados antes de consumirem mais recursos.

Uma transação que é ingerida e passa pela verificação de assinatura no estágio SigVerify é apenas uma candidata; milhares de transações candidatas chegam por slot, e muitas nunca entram em um bloco.

Não há observabilidade relevante nesse estágio, pois transmitir essas transações significaria transmitir ruído. 

Estágio 2: o agendador

A produção de blocos acontece no Banking Stage e, desde o Agave 1.18, seu núcleo é o agendador central: uma única thread de agendamento com uma visão global de todas as transações pendentes, que distribui o trabalho para um pool de workers de execução. A ideia é que uma única thread com contexto completo empacote blocos com muito menos conflitos de bloqueio do que n threads competindo de forma gananciosa por uma fila compartilhada.

Essencialmente, o agendador processa as transações em três etapas principais:

1. Buffering e priorização

As transações de entrada chegam ao componente receive and buffer do agendador, onde a prioridade e o custo de cada transação são calculados e inseridos em um contêiner ordenado por prioridade.

Nesse momento, uma transação ainda é apenas uma entre milhares de “possibilidades” que podem ser removidas se o buffer for preenchido por trabalhos de prioridade mais alta.

2. Agendamento 

O loop de controle no controller do agendador retira repetidamente do contêiner as transações de maior prioridade, verifica eventuais conflitos de bloqueio de contas e as agrupa em lotes para execução.

Desde o Agave 2.3, o algoritmo de agendamento fornecido é o greedy scheduler, que substituiu o design prio-graph anterior depois que testes demonstraram que a abordagem gananciosa empacotava blocos com menos overhead.

3. Distribuição 

O lote agendado é enviado por um canal a um worker de execução. Nesse ponto, o líder comprometeu recursos reais — uma thread de worker, bloqueios de contas e um lugar no bloco em construção — para essa transação específica.

Nesse momento, a transação ainda está pendente. O líder pretende executá-la, mas nada foi executado ainda. Portanto, não há resultado a relatar. Preconfirmations vêm uma etapa depois.

Como a arquitetura do agendador do Firedancer difere da arquitetura do Agave?

O Firedancer chega ao mesmo ponto usando uma arquitetura um pouco diferente. Em vez de threads que compartilham memória, o Firedancer executa tiles isolados conectados por filas de memória compartilhada, com sua lógica de agendamento localizada no pack tile. 

O pack tile mantém todas as transações pendentes, acompanha quais contas cada bank tile mantém no momento e seleciona transações sem conflitos que maximizam as taxas, agrupando-as em microblocos que são entregues aos bank tiles para execução. 

O mesmo repasse acontece: as transações selecionadas passam da lógica de empacotamento para as unidades de execução, onde seus resultados são determinados.

Estágio 3: execução

Os workers no Agave, ou os bank tiles no Firedancer, executam o lote agendado de transações no bank atual, carregando contas, executando programas e confirmando seus resultados.

É também nesse ponto que uma transação agendada pode falhar por vários motivos, incluindo fundos insuficientes, um erro de programa, uma verificação de slippage que causa uma reversão ou outras condições de runtime. De qualquer forma, o resultado agora existe apenas localmente, na máquina do líder.

É nesse momento que uma preconfirmation é emitida. O líder transmite cada transação no instante em que ela é executada, junto com seu status, antes de os resultados serem registrados em uma entrada e muito antes de qualquer dado do bloco sair da máquina.

Esse é o primeiro momento de todo o ciclo de vida em que o resultado de uma transação existe e pode ser relatado. Antes da execução, existe apenas um pool de candidatas pendentes, sem resultados para transmitir; depois dela, as informações já estão sendo empacotadas no bloco que avança rapidamente em direção ao restante da rede.

Portanto, a execução é o único ponto em que um sinal antecipado desse tipo pode existir. É por isso que cada preconfirmation carrega o resultado real da transação, e não uma previsão.

No entanto, uma preconfirmation não pode informar se o bloco que contém a transação se tornará canônico. Esse bloco ainda não foi fragmentado em shreds, propagado nem votado. 

Por esse motivo, preconfirmations são um sinal, não uma garantia.

Estágio 4: Proof of History e entradas

Os lotes executados são registrados no stream de Proof of History para produzir entradas, que são conjuntos de transações submetidos a hash e incorporados ao relógio verificável do líder. As entradas são o formato nativo do ledger, mas, nesse momento, existem apenas na máquina do líder.

A observabilidade é praticamente inexistente para qualquer pessoa fora do líder.

Vale observar que o Proof of History será removido com a atualização Alpenglow, já que Rotor e Votor eliminam a necessidade de um relógio descentralizado na Solana. O modelo de preconfirmation não será afetado: os líderes continuarão executando transações antes de disseminá-las. Portanto, o primeiro sinal observável continuará sendo o resultado da execução local do líder. 

Estágio 5: fragmentação em shreds e transmissão

As entradas são divididas em shreds, ou fragmentos do tamanho de uma MTU que recebem codificação de apagamento para tolerar perdas. Esses shreds são assinados e transmitidos pela árvore do Turbine ponderada por stake.

É nesse ponto que se abrem as comportas da observabilidade. Shreds são o primeiro artefato de um determinado bloco a sair da máquina do líder. É por isso que todos os outros produtos de dados antecipados na Solana, incluindo streams de shreds, começam aqui. Quem reconstrói transações a partir de shreds é rápido em relação aos níveis de compromisso RPC, mas está atrasado em relação a uma preconfirmation, pois o líder executou a transação antes de os shreds existirem. 

A partir daí, o processo continua com os validadores reproduzindo o bloco, votando e as transações avançando pelos níveis de compromisso processed, confirmed e finalized. 

Onde as preconfirmations se encontram na escala de latência?

Preconfirmations são o sinal mais rápido na Solana em comparação com todos os outros, incluindo shreds brutos e decodificados, LaserStream e outros métodos de streaming de dados. 

No entanto, preconfs são mais bem compreendidas como um degrau em uma escala de latência, na qual cada degrau troca alguma forma de integridade ou certeza por uma observação antecipada.

Do mais antigo para o mais recente:

Duas observações decorrem dessa tabela. 

Primeiro, todos esses sinais são complementares, e não substitutos diretos entre si.

Por exemplo, preconfirmations informam o que um líder acabou de executar antes que a rede saiba, enquanto uma mensagem do LaserStream indica o que aconteceu com todos os metadados.

Sistemas de produção normalmente precisam consumir ambos, agindo com base em preconfirmations e usando sinais posteriores para verificação.  

Segundo, a distância entre os degraus não é uniforme.

A passagem dos streams processed para os shreds economiza alguns milissegundos, enquanto a passagem dos shreds para as preconfirmations pula o restante do pipeline de produção do bloco (ou seja, registro de entradas, fragmentação em shreds e propagação), pois o ponto de observação muda do primeiro artefato público do bloco para resultados que existem apenas dentro do líder. 

Como resultado, preconfirmations são aproximadamente 5 a 50 milissegundos mais rápidas que shreds. 

O modelo de confiança das Preconfirmations: sinal, não garantia

Tudo o que uma preconfirmation promete pode ser resumido em uma única frase: o líder executou essa transação com esse resultado. Tudo o que uma preconf não promete decorre da mesma frase.

Uma transação executada ainda não é uma transação incluída. Isso significa que o bloco que a carrega ainda não foi fragmentado em shreds, propagado nem votado. Ainda é possível que esse bloco seja ignorado ou excluído por um fork antes de ser confirmado pela rede. Quase todas as transações preconfirmed são incluídas onchain com sucesso. No entanto, qualquer sistema que atue com base em preconfirmations precisa confirmar os resultados por meio de outras verificações de observabilidade antes de tratá-los como definitivos.

A cobertura também é parcial por definição. Preconfirmations existem apenas para slots cujo líder encaminha seu stream de transações agendadas à Helius. Portanto, a cobertura aumenta de acordo com a parcela do stake da rede que participa, e o stream não é necessariamente contínuo.

Se os serviços precisarem de cobertura contínua como garantia absoluta, devem considerar recorrer ao LaserStream ou ao Shred Delivery quando houver lacunas.

Como preconfirmations são emitidas após a execução, um assinante vê resultados que já foram decididos, e não um fluxo de ordens pendentes esperando para ser explorado. Isso significa que a oportunidade de se antecipar a essa transação dentro do bloco já se encerrou. Essa é a diferença crucial entre vender visibilidade antecipada e vazar o fluxo de ordens antes do agendamento: a primeira permite que os assinantes reajam mais rápido que o restante da rede, enquanto a segunda permitiria que agissem contra as próprias transações transmitidas. Preconfirmations são estritamente o primeiro caso.

O sinal é transparente sobre o que representa: não há compromisso econômico garantindo uma preconfirmation, nem existe essa alegação. O líder informa seus resultados locais, mas não coloca nada em stake para garantir seu cumprimento. Para as estratégias atendidas por preconfirmations, essa é a escolha correta.

Um bot de liquidação, por exemplo, não precisa de uma promessa infalível, sujeita a slashing, de que uma transação será incluída; ele precisa saber o resultado de uma determinada transação alguns milissegundos antes dos concorrentes.

Como funcionam as Helius Preconfirmations?

Helius Preconfirmations são entregues por uma única assinatura WebSocket. Um cliente pode se conectar ao nosso endpoint Gatekeeper (ou seja, wss://beta.helius-rpc.com) e enviar uma solicitação preconfSubscribe:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "preconfSubscribe",
  "params": [
    {
      "failed": false,
      "regionInclude": ["ewr", "fra"],
      "accountInclude": ["TARGET_WALLET_ADDRESS"],
      "accountExclude": [],
      "accountRequired": []
    }
  ]
}

Os filtros são aplicados no servidor por conta (ou seja, inclusão, exclusão e obrigatória), região e status, com suporte a tabelas de pesquisa (LUTs). Assim, o assinante recebe e paga apenas pelas transações agendadas relevantes para sua estratégia. 

Como preconfirmations são emitidas após a execução, o filtro de status opera sobre resultados reais: failed: false, o que significa que transações com falha nunca são transmitidas nem cobradas.

A precificação é baseada em créditos, como em outras assinaturas WebSocket da Helius: 10 créditos por mensagem, com uma mensagem por transação transmitida, disponível nos planos Professional e superiores. 

A partir daí, cada transação agendada que corresponde aos filtros chega como um frame binário compacto. Ou seja, um cabeçalho fixo de 18 bytes contendo a versão da transação, o slot em que ela está agendada, o índice da transação dentro do slot e seu status, seguido pelos bytes completos da transação. 

O formato é deliberadamente simples, pois um cabeçalho fixo pode ser decodificado em nanossegundos, sem a necessidade de analisar JSON no caminho crítico. O único JSON necessário nessa troca é a confirmação da assinatura, por conveniência. 

Uma preconfirmation é apenas metade de uma operação. Ver uma transação primeiro só importa se a resposta chegar primeiro. Por isso, também lançamos o Sender Max, o nível de maior desempenho do Helius Sender.

O Sender Max encaminha um envio (ou seja, uma única transação ou um bundle atômico de até quatro transações) por todos os caminhos de alta velocidade disponíveis e o insere em um buffer de gorjetas prioritárias que favorece as maiores gorjetas. A gorjeta mínima é de 0,001 SOL.

Receba sinais com preconfSubscribe e inclua transações com Sender Max.  

O que você pode criar com preconfirmations?

Qualquer estratégia cujo lucro diminui a cada milissegundo entre o momento em que uma transação é decidida e o momento em que é observada se beneficia de preconfs. Isso inclui, entre outros, os seguintes casos de uso: 

Sniping

A criação de novos pools e os lançamentos de tokens ficam visíveis no instante em que a transação de implantação é executada dentro do líder. Um sniper que consome preconfirmations reage enquanto os observadores de shreds ainda aguardam a chegada dos primeiros fragmentos do bloco. 

Copy trading

As movimentações de uma carteira-alvo aparecem no stream de preconfirmation no momento em que o líder as executa. Filtrar pelo endereço de um alvo usando accountInclude transforma o stream em um feed de espelhamento específico, oferecendo insights sobre as movimentações antes de outros copy traders.

Liquidações

Uma atualização de oráculo que deixa uma posição insolvente pode ser identificada no momento em que é executada. O bot de liquidação que a detecta nesse ponto aciona um pipeline inteiro antes de outro que esteja monitorando shreds ou um compromisso processed. Isso torna preconfirmations extremamente importantes para atividades de liquidação.

Market making e propAMMs

O fluxo de entrada visível no momento da execução oferece aos propAMMs e a outros sistemas de cotação uma vantagem para reajustar preços ou remover cotações desatualizadas antes que o fluxo se torne público. 

Em todos os casos, preconfirmations mudam o ponto de reação da estratégia de “depois que a rede descobre” para “no momento em que o líder executa”.

Ganhe encaminhando Preconfirmations

A cobertura de preconfirmation é um efeito de rede, com os validadores no lado da oferta. Qualquer validador pode encaminhar seu stream para a Helius e obter receita por isso, transformando um subproduto da produção de blocos em uma fonte de renda que existe independentemente de o validador monetizar sua posição de outras formas.

Quanto maior o stake participante, mais ampla será a cobertura. Validadores interessados em participar podem entrar em contato conosco e encontrar mais informações em nossa documentação sobre preconfirmations para validadores. 

Qual é a diferença entre preconfs da Ethereum e preconfs da Solana?

Preconfirmations da Ethereum são compromissos de proponentes que garantem que uma transação será incluída em um bloco futuro, enquanto preconfirmations da Solana são sinais de transações onchain em tempo real para transações que acabaram de ser executadas localmente pelo líder do bloco atual. As primeiras tratam de saber com antecedência, enquanto as segundas tratam de ver com antecedência.

Preconfirmations da Ethereum

Na Ethereum, preconfirmations — geralmente chamadas de based preconfs na literatura de pesquisa, em um design apresentado pela primeira vez por Justin Drake em 2023 — são compromissos de inclusão. Um proponente promete, antes de seu slot, que uma transação será incluída em um bloco futuro, com essa promessa respaldada por um mecanismo econômico, como slashing. 

Existem várias implementações em produção: 

• MEV-Commit da Primev, um marketplace em que carteiras, searchers e protocolos de intenção fazem ofertas a provedores de execução (ou seja, construtores de blocos e sequenciadores) em troca de compromissos
• ETHGas, uma rede de preconfirmation com garantia econômica
• Bolt da Chainbound, que oferece compromissos de proponentes sem permissão e compatíveis com MEV-Boost

O mais importante é que preconfirmations da Ethereum são:

• Sobre sua própria transação
• Emitidas antes da execução
• Otimizadas para certeza

Preconfirmations da Ethereum garantem que sua transação será incluída antes que isso realmente aconteça.

A Ethereum precisa desse mecanismo devido à forma como seus blocos são construídos. A maioria dos proponentes leiloa a construção do bloco no último momento por meio do MEV-Boost. Portanto, nada sobre um bloco pode ser prometido de forma confiável antes que esse leilão seja concluído. A Solana, porém, nunca teve essa lacuna. A programação dos líderes é conhecida antecipadamente, não há mempool e um único líder recebe, ordena, executa e transmite continuamente seu bloco durante o slot. O sinal antecipado que a Ethereum precisa fabricar com uma estrutura econômica existe nativamente no pipeline de produção de blocos da Solana; só precisava ser exposto.

Preconfirmations da Solana

Preconfirmations da Solana são sinais onchain em tempo real, e não uma promessa futura: o líder informa as transações que já executou antes que elas sejam propagadas para o restante da rede.

O mais importante é que preconfirmations da Solana são:

• Inclusivas de transações de todos
• Emitidas após a execução
• Otimizadas para latência

Preconfirmations da Solana permitem que você veja transações executadas alguns milissegundos antes de serem observadas por toda a rede por meio de shreds ou solicitações RPC nos níveis de compromisso padrão.

O equivalente mais próximo na Solana à preconfirmation de reserva de espaço em bloco da Ethereum é o marketplace de unidades de computação da Raiku para Ahead-of-Time (AOT) Transactions, que permite que aplicações reservem inclusão garantida em blocos futuros.

Conclusão

Toda transação na Solana passa por um único momento em que seu destino muda de desconhecido para decidido: o instante em que o líder a executa. Preconfirmations representam esse momento, transmitido antes que o restante da rede possa vê-lo. Elas ficam acima dos shreds na escala de latência porque observam os resultados da execução do líder, e não os artefatos públicos do bloco. Preconfirmations são um sinal, não uma garantia, pois um bloco só é considerado canônico quando a rede o confirma.

Para sistemas sensíveis à latência — snipers, copy traders, liquidadores, market makers e searchers —, assine com preconfSubscribe, filtre as contas relevantes, responda aos sinais com Sender Max e verifique os resultados por meio das verificações de compromisso padrão.

A referência completa da assinatura, o formato das mensagens e os exemplos de integração estão disponíveis em nossa documentação sobre preconfirmations.