Erros de transação Solana: blockhash expirado e transações não incluídas

2026-08-24

Uma transação Solana pode ser descrita ao mesmo tempo em várias camadas. Uma mensagem descreve as instruções propostas e seu contexto, uma transação assinada leva a autorização para essa mensagem, uma resposta RPC informa o que um serviço aceitou ou observou, e um registro do cluster é evidência em um nível de commitment indicado. Essas camadas podem produzir frases de status diferentes sem se contradizerem. A leitura de uma mensagem de expiração ou de transação não incluída começa, portanto, pela identificação da camada que a produziu. Um tempo limite local, um erro RPC, uma resposta de status e um registro finalizado descrevem pontos diferentes de um caminho de envio, não uma conclusão universal sobre o estado resultante.

Diagrama dos estados de uma transação Solana, da mensagem ao resultado registrado

Status da transação e caminho de envio

Uma transação Solana contém instruções, assinaturas de contas que autorizam mudanças e um recent blockhash. Quando a rede processa a transação, ela trata suas instruções como uma unidade atômica: a falha de qualquer instrução impede que as mudanças de estado pretendidas sejam registradas juntas. Antes que esse resultado exista, a transação pode passar por etapas distintas de formação da mensagem, assinatura, retransmissão para um nó RPC, recebimento por participantes da rede, processamento e observação em um nível de commitment. Um rótulo de status só tem significado quando sua etapa está clara.

O método RPC sendTransaction informa a primeira assinatura da transação quando o serviço RPC aceita a carga assinada para retransmiti-la. A documentação oficial separa expressamente essa aceitação imediata do processamento ou da confirmação pelo cluster. Na conversa comum, dropped transaction costuma nomear a ausência de um registro posterior do cluster depois de um evento anterior relacionado ao envio. Não é um único status de consenso com uma causa fixa. A frase pode ser usada por um cliente, um serviço RPC ou um observador, e cada um pode estar se referindo a uma transição ausente diferente no caminho.

O papel de um blockhash

O recent blockhash em uma mensagem de transação é uma referência de atualidade fornecida pela rede. O método getLatestBlockhash retorna tanto um blockhash quanto lastValidBlockHeight, conectando essa referência a um limite de altura em vez de a uma duração de relógio garantida. Isso permite que o protocolo avalie se uma transação que carrega essa referência ainda está dentro da janela de processamento. O blockhash faz parte da mensagem avaliada, portanto pertence à identidade e ao contexto de validação da transação, e não a uma exibição posterior em um explorador.

Altura de bloco, avanço de slots e tempo decorrido estão relacionados, mas não devem ser tratados como relógios intercambiáveis. O parâmetro exato de idade de processamento, o número de slots descrito pela documentação e o tempo representado por esses slots dependem da versão relevante do protocolo e do software, além das condições da rede. Por isso, um recent blockhash é melhor entendido como uma janela de validade dependente de versão. O fato duradouro é a existência de um limite; uma duração exata não é uma promessa universal.

Expirado e não encontrado são diferentes

Expirado descreve um resultado de validade: o recent blockhash não pode mais ser usado para que uma transação seja processada sob as regras aplicáveis. Isso diz respeito à referência limitada no tempo da transação, não a um rótulo geral para cada retransmissão que falha ou registro ausente. Quando pessoas usam a frase de busca solana transaction expired, elas frequentemente nomeiam um resultado visível no cliente que corresponde a esse limite de ciclo de vida. A frase sozinha não identifica o que um nó RPC específico recebeu nem descreve um resultado de transferência separado.

Blockhash not found solana é uma frase de busca que costuma combinar uma cadeia exibida com o nome da rede. Uma mensagem real de blockhash-not-found pode expressar que um nó, em sua visão atual e no nível de commitment pertinente, não consegue resolver o hash referido para o contexto de validação relevante. Essa observação não é automaticamente idêntica à prova de que a última altura válida passou em todos os lugares. Estado do nó, commitment, versão da API, momento e redação do cliente podem mudar como a mesma condição ampla é apresentada, portanto as duas frases não devem ser reduzidas a um diagnóstico invariável.

Assinada, mas não incluída em um bloco

Uma assinatura é uma autorização para uma mensagem específica; ela não é um registro de que a mensagem alcançou um bloco. Da mesma forma, a aceitação de uma carga por um serviço RPC para retransmissão não é um registro de que o cluster a processou. Uma transação assinada pode, portanto, ser descrita como assinada e ainda não ter uma observação processada, confirmada ou finalizada. Essa lacuna por si só não revela se uma carga nunca foi recebida por um participante relevante, não foi mantida em um escopo de status visível ou se tornou inválida antes de poder ser processada.

Os métodos de status JSON-RPC tornam explícitos os limites de uma observação. getSignatureStatuses retorna os status atuais das assinaturas fornecidas, e sua busca padrão é limitada a um cache recente de status, a menos que a busca do histórico de transações seja incluída. getTransaction retorna uma transação confirmada por assinatura ou null quando ela não é encontrada ou confirmada no commitment solicitado. Uma resposta null é, consequentemente, uma resposta com escopo definido, não uma declaração universal de que nenhum evento jamais existiu na visão retida de cada nó.

Diferenças entre observações de RPC, cliente e rede

Uma interface de cliente geralmente transforma vários sinais técnicos em uma frase curta para uma pessoa ler. Uma resposta RPC é, em vez disso, o relatório de um nó específico, com um slot de contexto, versão da API, configuração e commitment solicitado. Uma observação de rede se refere ao estado que o commitment relevante torna visível. Essas observações estão relacionadas, mas não são o mesmo objeto e não precisam se tornar visíveis no mesmo momento.

A dependência de versão importa em cada camada. Software de nó Solana, bibliotecas de cliente, configuração RPC, suporte a versões de transação, padrões de commitment, retenção de status e redação de interface podem evoluir. Uma interpretação sólida identifica, por isso, o observador e o escopo da observação antes de atribuir significado a um rótulo de erro. Ela não presume que uma frase de uma interface seja uma descrição transportável de cada nó, cada commitment ou cada versão de software.

Por que o reenvio repetido não é uma resposta universal

O reenvio repetido não é um único evento técnico. Ele pode significar retransmitir os mesmos bytes assinados, apresentar uma mensagem diferente ou criar uma mensagem posterior com contexto de validação diferente. Esses casos têm identificadores, momentos e possíveis efeitos de estado distintos. Uma transação que a rede já está considerando e uma transação posterior separada com intenção semelhante não se tornam intercambiáveis apenas porque expressam intenções parecidas. A repetição pode, assim, tornar mais difícil interpretar a relação entre uma assinatura visível, um registro de status e uma mudança de estado pretendida.

Pela mesma razão, uma prescrição genérica de nova tentativa misturaria recebimento, propagação, validação, execução e commitment em uma só ideia. A linguagem de expiração, por si só, não estabelece que uma mensagem posterior tenha a mesma identidade ou efeito de uma anterior. Em termos analíticos, a distinção importante é se a evidência disponível se refere à mesma mensagem de transação, a uma mensagem separada ou apenas a uma tentativa local de retransmitir dados. O assunto do artigo é essa distinção, não um procedimento para enviar outra transação.

Vocabulário estável de diagnóstico e limites de risco

Um vocabulário estável ajuda a manter as camadas separadas. Mensagem nomeia as instruções, contas, recent blockhash e outros dados que são autorizados. Assinatura identifica uma transação assinada para APIs orientadas a status. Envio nomeia um evento de retransmissão RPC, enquanto processamento, confirmação e finalização nomeiam níveis diferentes de observação da rede. Commitment é o limiar de visibilidade solicitado usado pelos métodos RPC. Expiração diz respeito à referência de atualidade, e dropped geralmente descreve um caminho observado incompleto, não um veredito de protocolo com um significado padronizado.

O limite desses termos é tão importante quanto suas definições. Um status técnico não estabelece propriedade de conta, intenção de remetente, saldo de ativos, conduta de serviço ou uma solução para um registro ausente. Ele também não transforma uma mensagem de cliente em prova do que cada validador ou sistema de retenção de dados observou. A linguagem de status é evidência sobre um caminho de processamento limitado, interpretada por uma versão, um observador, um commitment e um momento. Manter esse limite claro evita transformar um sinal estreito de rede em uma alegação mais ampla.

Leituras relacionadas

Outros artigos da Bitbase sobre este tema:

- MEV na Solana e ataques on-chain

- Kamino na Solana explicado

- Taxas e desempenho da Solana

Aviso: Este artigo é conteúdo educacional da Bitbase Academy, fornecido apenas para fins informativos. Não constitui aconselhamento de investimento, negociação, tributário ou financeiro. Criptoativos são voláteis; avalie seu próprio risco. Escrito em agosto de 2026; consulte as informações oficiais mais recentes.