Busque em todas as páginas da documentação
Aterrissar uma transação significa que um líder a inclui em um bloco enquanto seu blockhash recente ainda é válido, para que a assinatura passe de "desconhecida" para um status confirmado que você pode exibir na UX do produto.
Esta página é o mapa conceitual para Taxas de Prioridade e Otimização de Transações - por que transações travam, como o preço e os limites de CU interagem, como clientes tentam novamente com segurança, quando ALTs e Jito ajudam, e como as escolhas de montagem moldam os mercados de taxas locais no Agave 4.1.1.
Um cliente constrói uma mensagem (instruções, metadados de conta, pagador de taxas, blockhash recente), assina-a e envia a transação de rede via RPC ou um block engine. O nó pode executar a simulação de preflight, depois encaminha o pacote para líderes futuros.
Landing é a inclusão em um bloco produzido. Confirmação é o quão longe esse bloco progrediu em votos (processed → confirmed → finalized). O sucesso do produto quase sempre significa "aterrissou e teve sucesso no compromisso escolhido", não "RPC aceitou o envio".
sendTransaction retornando uma assinatura apenas prova que o nó aceitou o caminho de submissão. A assinatura pode permanecer desconhecida para sempre se o pacote nunca ganhar um slot antes que o blockhash expire (~150 slots, frequentemente cerca de um minuto de tempo real).
| Resultado | O que você observa | Causa típica |
|---|---|---|
| Nunca incluída | Status desconhecido / nulo após espera | Subprecificado, descartado, blockhash expirado, pacote oversized, peer ruim |
| Incluída, programa falhou | Assinatura encontrada, meta.err definido | Lógica, contas, CU excedido durante a execução |
| Incluída, sucesso | Status no compromisso escolhido, sem erro | Caminho saudável |
Apenas a primeira linha é um problema puro de landing. O orçamento de CU ainda é importante tanto para a economia de landing (preço × limite) quanto para a segunda linha (falha de execução após inclusão).
As taxas têm duas camadas. Uma taxa base cobre assinaturas. Uma taxa de prioridade é definida com instruções do Compute Budget: definir limite de unidade de computação e definir preço da unidade de computação (microLamports por CU). Lamports de prioridade escalam aproximadamente com preço × limite / 1_000_000. Líderes usam sinais de taxa quando muitas transações competem pela capacidade do bloco e pelos bloqueios de conta.
Essa competição é frequentemente local: contas quentes (um cofre de mint, pool popular, configuração compartilhada) criam um mercado de taxas local para transações que escrevem nessas chaves, mesmo quando o resto da rede está quieto.
Líderes têm capacidade finita por slot. Sob carga, eles preferem trabalho de maior valor. Sua transação também compete com a validade do blockhash: após lastValidBlockHeight, validadores rejeitam a mensagem.
Caminhos comuns de descarte:
Trate a taxa de landing (envios que chegam a confirmed sem esgotar reconstruções) e o tempo p95 até a confirmação como métricas do produto.
Use getRecentPrioritizationFees (opcionalmente escopado para contas que sua transação bloqueia) ou uma API de taxas do provedor. Mire um percentil: p50 para tranquilidade, p75 para UX padrão, p90 para mints e outras contenções. Aplique um pequeno fator de segurança e um teto rígido para que picos de taxas não drenem os usuários.
priority_fee_lamports ≈ (microLamports_per_CU × compute_unit_limit) / 1_000_000
total_user_fee ≈ base_signature_fee + priority_fee_lamports (+ optional tip)Preço e limite se multiplicam. Um limite de CU inchado com um preço agressivo paga demais; um limite apertado com um preço alto ainda falha se a execução exceder o limite após a inclusão. Corrija o limite a partir da medição primeiro, depois licite o preço para inclusão.
Orçamentos padrão não são ajustados para sua rota. Simule a transação totalmente montada, leia unitsConsumed e defina SetComputeUnitLimit para aproximadamente consumido × 1.1–1.2 de margem para variação de estado.
Em pilhas da era Agave 4.1.1, os tetos de CU por transação são finitos. Uma simulação que falha é um problema de correção; uma simulação que tem sucesso com alto consumo é um sinal de taxa e risco. Testes locais (Anchor 0.32.1, LiteSVM, Surfpool) perfilam CU em desenvolvimento; os percentis de taxa na mainnet ainda precisam de amostras RPC ao vivo.
Duas operações diferentes:
getLatestBlockhash, nova mensagem e novas assinaturas (identidade de transação diferente).Prefira o controle da aplicação: frequentemente maxRetries baixo ou zero no RPC, depois seu loop espera pela confirmação, retransmite a mesma forma de rede até a expiração da altura e só então reconstrói com um blockhash e amostra de taxa novos. Monitore lastValidBlockHeight e pare de retransmitir após passar. Nonces duráveis substituem blockhashes recentes de curta duração para fluxos lentos de múltiplos signatários.
A idempotência importa: se a primeira tentativa ainda puder aterrissar tarde, uma segunda reconstrução pode executar em duplicidade, a menos que o caminho do programa seja seguro para novas tentativas.
Transações v0 versionadas mais tabelas de consulta de endereço substituem muitas chaves de 32 bytes por índices de 1 byte em uma tabela on-chain. Isso encolhe os pacotes para que swaps multi-hop e montagens multi-instrução permaneçam sob os limites de tamanho que os líderes propagarão.
Ciclo de vida: criar → estender com chaves públicas estáveis → esperar ativação (~1 slot) → compilar v0 com lookups → opcionalmente congelar. Clientes usando @solana/kit 7.0.0 buscam a ALT antes da compilação para que os índices correspondam à ordem on-chain. ALTs não aumentam a prioridade por si só; elas removem um motivo estrutural de descarte e liberam espaço para instruções de orçamento e gorjeta.
Jito block engines aceitam pacotes: transações ordenadas que aterrissam juntas atomicamente, tipicamente com uma transferência de gorjeta. Use-os quando a ordem e a atomicidade importam (mint + gorjeta, caminhos multi-perna) ou quando a exposição ao mempool público é inaceitável para fluxos de alto valor.
Pacotes complementam as taxas de prioridade nativas; eles não substituem limites de CU corretos ou blockhashes válidos. Mercados de gorjetas têm sua própria curva de custo - reserve para janelas de contenção e rotas de alto valor.
A ordem das instruções faz parte da confiabilidade de landing e eficiência de taxas:
Compile com a versão de mensagem correta, conjunto completo de signatários e conjunto mínimo de contas graváveis. Marcar contas graváveis em excesso aumenta a contenção de bloqueio e pode piorar o mercado de taxas local em que você está licitando. Simule a forma final de rede antes do envio na mainnet.
buscar blockhash + amostras de taxa (+ contas ALT)
→ prefixar limite de CU + preço → instruções principais (+ gorjeta opcional)
→ compilar v0 com ALTs → assinar → simular
→ enviar (RPC e/ou Jito) → esperar compromisso
desconhecido & hash válido → reenviar mesmos bytes
expirado / tempo esgotado → reconstruir (novo hash, taxas, assinar)
aterrissado + erro → corrigir programa/contas (não tentar cegamente)
aterrissado + ok → concluídoMercados de taxas locais se formam em torno de contas graváveis disputadas. Amostrar taxas de priorização com as contas que sua rota bloqueia frequentemente supera amostras globais vazias quando o congestionamento é específico do caminho. Mantenha perfis de taxa por template (transferência vs swap vs mint) com pisos, percentis e tetos separados.
SWQoS e RPC privado melhoram a chance de os pacotes chegarem aos líderes. Eles se combinam com a política de taxas; não a substituem. Caminhos de envio em produção geralmente querem um nível pago e envio de caminho duplo para rotas críticas (RPC mais block engine).
UX de custo: exiba a taxa de prioridade SOL estimada de preço × limite, mais a taxa base e a gorjeta opcional. Limite os multiplicadores durante picos. Use feature flags para percentis agressivos para que você possa decair fora de pico sem uma crise de implantação.
Medição: registre assinatura, id da rota, microLamports, limite de CU, unidades consumidas (sim e meta aterrisada), lamports de gorjeta, tentativas e tempo até a confirmação. A taxa de landing e a taxa por confirmação bem-sucedida orientam a escolha do percentil.
| Situação | Prefira |
|---|---|
| Mainnet tranquila, ix simples | Preço de CU modesto, nova tentativa padrão |
| Contas quentes compartilhadas | Amostras de taxa escopadas por conta, percentil mais alto |
| Listas grandes de contas | Trabalho de manutenção v0 + ALT |
| Multi-tx atômico ou dia de mint | Política de pacote Jito + gorjeta |
| Assinatura multisig / lenta | Nonce durável |
| Simulação falha | Corrigir programa ou contas antes de aumentar taxas |
Ressalva devnet: mercados de taxas e taxas de descarte não correspondem à mainnet. Valide a montagem, ativação de ALT e máquinas de estado de nova tentativa na devnet; valide percentis de taxa e SLOs de landing com pequenas sondas na mainnet.
Um líder incluiu sua transação em um bloco antes que seu blockhash recente se tornasse inválido, para que a assinatura seja detectável on-chain (sucesso ou erro do programa).
Landing é inclusão. Confirmação é quantos validadores votaram naquele bloco (processed, confirmed, finalized). A UX geralmente espera por pelo menos confirmed.
A simulação verifica a execução contra um snapshot do banco de dados. Ela não reserva capacidade do líder, vence um leilão de taxas ou garante a propagação do pacote antes da expiração do blockhash.
O preço da unidade de computação é microLamports por CU. A taxa de prioridade paga escala com esse preço vezes o limite de unidade de computação que você solicita (taxas de assinatura base são separadas).
Monte a transação real, simule-a, leia unitsConsumed, adicione cerca de 10–20% de margem e defina SetComputeUnitLimit. Detalhes em Estimando Unidades de Computação.
Comece em torno de p75 com um multiplicador pequeno e um teto rígido para UX normal; aumente para p90 para mints e janelas quentes; meça a taxa de landing e ajuste. Veja Definindo Taxas de Prioridade.
Reenvie a mesma transação assinada enquanto lastValidBlockHeight ainda estiver à frente. Reconstrua e assine novamente quando o hash expirar ou você precisar alterar taxas ou instruções. Veja Novas Tentativas e Gerenciamento de Blockhash.
Se a transação for incluída e falhar durante a execução, as taxas de inclusão ainda se aplicam. Transações descartadas que nunca aterrissam não pagam nada on-chain.
Quando as listas de contas tornam as mensagens legadas muito grandes ou não deixam espaço para instruções de orçamento e gorjeta. Use compilação v0 com ALTs mantidas. Veja Tabelas de Consulta de Endereço na Prática.
Quando você precisa de ordenação atômica de múltiplas transações, incentivos de inclusão mais fortes via gorjetas, ou menor exposição ao mempool público para fluxos de alto valor. Veja Pacotes Jito.
Pressão de taxas concentrada em transações que bloqueiam as mesmas contas graváveis quentes (pools, mints, cofres compartilhados), que pode superar as médias globais tranquilas. Amostre taxas com essas contas quando possível.
Orçamento de computação primeiro, depois configuração de conta, depois instruções principais de negócios, depois gorjetas opcionais ou limpeza. Padrões completos em Montagem de Transações.
skipPreflight: true pode reduzir a latência, mas envia mais transações fadadas ao fracasso. Prefira preflight ativado para carteiras de usuário; o skip seletivo é para caminhos especializados de baixa latência que já simularam offline.
Não. Elas aumentam a probabilidade de inclusão sob contenção. Bugs de programa, exaustão de CU, contas ruins, blockhashes expirados e falhas de caminho ainda impedem o sucesso.
Anchor 0.32.1 molda programas on-chain e clientes orientados por IDL; @solana/kit 7.0.0 constrói, assina, simula e envia transações versionadas. Nenhum remove a necessidade de política de taxas, CU, blockhash e confirmação.
Versões da stack: Esta página foi escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1 e @solana/kit 7.0.0.
Revisado por Chris St. John·Última atualização: 15 de jul. de 2026