A Transação
Uma transação Solana não é um script de formato livre que você envia para um contrato inteligente.
//
Busque em todas as páginas da documentação
Uma transação Solana não é um script de formato livre que você envia para um contrato inteligente.
É uma mensagem assinada e com tempo limitado que lista todas as contas que ela tocará, todos os programas que ela chamará e todas as assinaturas necessárias - e então aplica todas as suas instruções ou nenhuma delas.
Noções Básicas de Transações mostra etapas concretas de construção e envio; Instruções e Contas, Taxas de Prioridade e Blockhashes e Expiração cada um se aprofunda em uma parte.
Esta página é a camada inferior: o modelo único que faz com que essas páginas pareçam um sistema, em vez de uma lista de verificação de APIs.
Uma transação tem duas partes de nível superior: a mensagem (o que deve acontecer) e as assinaturas (quem autorizou aquela string de bytes exata).
O runtime não inventa contas ou programas em seu nome; tudo o que uma instrução precisa deve já estar nomeado na mensagem.
Uma instrução é a menor unidade de trabalho: um program_id, uma lista de contas e data opaco que o programa entende (frequentemente um discriminador mais Borsh ou codificação personalizada).
Uma transação é uma lista ordenada de tais instruções que compartilham um pagador de taxa, um tempo de vida e um conjunto de assinaturas.
Cada entrada de conta é um AccountMeta: uma chave pública mais dois booleanos, is_signer e is_writable.
Essas flags não são dicas para documentação; elas são a superfície de bloqueio e autoridade que o runtime impõe antes que qualquer bytecode do programa seja executado.
is_signer significa que uma assinatura correspondente deve aparecer na transação (ou um caminho CPI válido assinado pelo programa para PDAs).
is_writable significa que a conta pode ter seus dados ou lamports mutados e está bloqueada para escrita exclusiva durante a execução desta transação.
Contas que são apenas legíveis podem ser agendadas em paralelo com outras transações que também apenas as leem; dois escritores na mesma conta entram em conflito.
O fee payer é tipicamente a primeira conta marcada como um signatário obrigatório e deve possuir SOL suficiente (lamports) para cobrir as taxas de toda a transação.
Atomicidade significa que a lista completa de instruções é bem-sucedida ou o estado do ledger dessas instruções é revertido; você não obtém "instrução 1 confirmada, instrução 2 falhou parcialmente aplicada".
A execução com falha ainda pode custar taxas, pois os validadores gastaram computação tentando realizar o trabalho - não trate a falha como gratuita.
Uma analogia útil é um formulário de transferência bancária de várias etapas: cada número de conta é escrito no formulário antecipadamente, cada assinatura necessária está no mesmo papel, o formulário expira após uma curta janela de validade e o banco publica todo o pacote ou o rejeita - nunca deixa metade das linhas aplicadas.
Isso está mais próximo de Solana do que um "chame este contrato e deixe-o descobrir o armazenamento" em aberto.
Construir e pousar uma transação é um loop fechado de compor, autorizar, (opcionalmente) simular, enviar e confirmar - sempre contra um tempo de vida fresco.
compor mensagem autorizar decidir
--------------- --------- ------
instruções[] ──► mensagem ──► assinaturas[] ──► simular? ──► enviar
metadados de conta ▲ │
pagador de taxa │ │ erro / CU
blockhash recente──────┘ ▼
(ou nonce durável) ajustar e reconstruir
│
▼
RPC / líder
│
▼
executar atomicamente
(tudo ok ou nada)Compor: Colete cada instrução que seu fluxo precisa (transferência do Sistema, SPL Token, seu programa Anchor, Compute Budget e assim por diante) e una todas as contas que essas instruções exigem na lista de contas da mensagem com flags corretas de signatário/gravável.
Tempo de vida: Anexe um blockhash recente de getLatestBlockhash (ou equivalente em @solana/kit 7.0.0) para que a mensagem seja única e válida apenas enquanto esse blockhash permanecer recente - tipicamente na ordem de 60-90 segundos, dependendo do tempo do cluster e de como a "altura do último bloco válido" é interpretada pelos clientes.
Sem um blockhash em mudança, cargas idênticas poderiam ser reexecutadas para sempre; com um, retentativas após a expiração devem reconstruir e assinar novamente com um novo hash.
Nonces duráveis são a alternativa quando você precisa de uma transação que pode permanecer sem assinatura ou não enviada por mais tempo do que uma janela de blockhash normal (multisig, assinatura offline, liberação agendada) - mesmo modelo de mensagem e assinaturas, mecanismo de tempo de vida diferente. Veja Blockhashes e Expiração.
Autorizar: Cada conta com is_signer: true deve contribuir com uma assinatura sobre a mensagem serializada (carteira, chave de backend, signatário de hardware).
A falta de uma assinatura obrigatória falha antes do trabalho significativo do programa; assinaturas extras desperdiçam a taxa base sem comprar autoridade que você não declarou.
Taxas: A taxa base escala com o número de assinaturas na transação.
A taxa de prioridade opcional é definida incluindo instruções do programa Compute Budget: tipicamente setComputeUnitLimit (quantas CUs você permite) e setComputeUnitPrice (microlamports por CU), então a prioridade rastreia aproximadamente CU_limit × CU_price mais o custo base da assinatura. Detalhes estão em O Programa Compute Budget e Taxas de Prioridade.
Simular: A simulação RPC executa a transação contra o estado atual do banco sem cometer, retornando erros, logs e, frequentemente, unidades de computação consumidas.
Use a simulação para preflight (contas erradas, restrições falhadas, fundos insuficientes) e para dimensionar o limite de CU ligeiramente acima do consumo medido em vez de sempre solicitar o máximo.
Enviar e confirmar: A submissão entrega os bytes assinados a um RPC (ou um caminho de pouso especializado); os líderes ordenam e executam sob Sealevel usando os bloqueios de conta declarados.
Seu cliente deve tratar "submetido" como distinto de "confirmado": atualize o blockhash e assine novamente na expiração, e prefira a assinatura de assinatura ou polling em um nível de compromisso que corresponda ao seu risco (confirmed para muitas ações do aplicativo, finalized para liquidação de alto valor).
Sob congestionamento, mercados de taxas locais se formam em torno de contas graváveis quentes: duas trocas lutando pela mesma conta de pool não estão competindo com toda a cadeia igualmente - elas competem entre si pela trava de escrita dessa conta e pelas escolhas de empacotamento do líder.
Aumentar a taxa de prioridade ajuda quando você está com pouca inclusão; não corrige um flag de signatário incorreto ou um blockhash expirado.
Mensagens legadas vs. versionadas (v0) compartilham o mesmo modelo mental - instruções, contas, assinaturas, atomicidade - mas diferem em quantas contas você pode encaixar dentro do limite de tamanho serializado.
Transações legadas incorporam cada chave pública de conta inline na mensagem.
Transações versionadas (v0) podem referenciar tabelas de pesquisa de endereços (ALTs): tabelas on-chain de endereços que a mensagem indexa, para que mais contas caibam sem repetir chaves completas de 32 bytes para cada entrada. Mergulho conceitual profundo: Transações Versionadas (v0) e Tabelas de Pesquisa de Endereços.
Use v0 + ALTs ao compor grandes grafos de CPI (roteadores DeFi, swaps multi-hop, pipelines de mint complexos); permaneça simples com menos contas quando não precisar do espaço.
Limites de CU orientados por simulação superam suposições estáticas: simule, leia CU consumido, defina o limite com uma pequena margem de segurança e, em seguida, defina o preço com base em sua urgência e concorrência observada.
Dicas e bundles Jito são um caminho de pouso avançado: você pode pagar uma dica e/ou enviar um bundle atômico para inclusão com reconhecimento de MEV, ainda sob as mesmas regras de instrução e conta, mas através de infraestrutura especializada em vez de apenas taxa de prioridade no caminho público. Mantenha isso conceitual até que você precise dele - veja Dicas e Bundles Jito.
| Estratégia | O que você paga | Força | Fraqueza | Melhor ajuste |
|---|---|---|---|---|
| Apenas taxa base | Custo base por assinatura | Mais barato; bom quando a rede está quieta | Fácil de perder inclusão sob carga ou em contas quentes | Devnet, transferências de baixa contenção, administração não urgente |
| Taxa de prioridade (Compute Budget) | Base + PreçoCU × CU usado/limite | Funciona com RPC normal; urgência ajustável | Pagar demais desperdiça SOL; pagar de menos ainda cai | Maioria dos dapps de produção, mints de NFT, swaps de varejo |
| Dica Jito / bundles | Dica (+ prioridade opcional) via caminho especializado | Pouso mais forte e bundles atômicos multi-tx | Complexidade operacional extra; não é um substituto para txs corretas | Fluxos competitivos sensíveis a MEV, conjuntos atômicos multi-etapas |
Nenhuma dessas estratégias altera a atomicidade ou as regras do AccountMeta; elas apenas mudam o quanto você licita pela inclusão assim que a mensagem for válida.
Clientes em @solana/kit 7.0.0 devem preferir construtores de mensagens v0, pagador de taxa explícito e helpers de tempo de vida, e simulação antes dos caminhos de envio da mainnet.
Programas em Anchor 0.32.1 ainda executam apenas as contas que o cliente declarou - macros de framework geram dados de instrução e listas de contas, mas o modelo de runtime acima continua sendo a fonte da verdade.
Uma mensagem assinada listando instruções ordenadas e todas as contas que elas tocam, executada atomicamente dentro de um curto tempo de vida definido por um blockhash recente (ou nonce durável).
A mensagem é a intenção não assinada (contas, instruções, tempo de vida, pagador de taxa); a transação é essa mensagem mais as assinaturas que a autorizam.
Um ID de programa a ser invocado, uma lista ordenada de AccountMetas e um array de bytes de dados de instrução para aquele programa decodificar.
is_signer requer uma assinatura correspondente (autoridade); is_writable permite mutação e obtém um bloqueio de escrita usado para agendamento paralelo e segurança.
O pagador de taxa é um signatário obrigatório na mensagem (comumente o primeiro) cujo saldo de lamports é debitado para taxas base e de prioridade para toda a transação.
Ele torna cada mensagem única (proteção contra replay) e limita por quanto tempo a carga assinada permanece válida, forçando os clientes a atualizar a intenção na ordem de aproximadamente 60-90 segundos.
Validadores rejeitam ou descartam a transação como muito antiga; você deve buscar um novo blockhash, reconstruir a mensagem se necessário, assinar novamente e reenviar.
Quando o processo de assinatura e envio não pode ser concluído dentro de uma janela normal de blockhash - assinatura offline, aprovação multipartidária ou liberação agendada - aceitando a maquinaria extra da conta nonce.
Não. Taxas ainda podem ser cobradas pelo trabalho que a rede realizou; trate a simulação como a maneira barata de capturar falhas antes de pagar por um caminho de envio completo.
A taxa base está ligada às assinaturas na transação; a taxa de prioridade é um preço opcional de CU (via Compute Budget) que aumenta a competitividade de inclusão sob carga.
O limite limita quanta computação você permite (e alimenta o cálculo da taxa); o preço é o seu lance por CU - juntos eles definem quanto orçamento de prioridade você coloca na mesa sem exagerar cegamente.
Eles permitem que as mensagens referenciem contas por meio de tabelas de pesquisa on-chain para que grandes listas de contas caibam no limite de tamanho da transação sem incorporar cada pubkey completa inline.
A simulação verifica esta mensagem exata contra o estado atual do cluster - contas, saldos, CU e logs - que testes de unidade em uma VM local não substituem totalmente para pousar em devnet ou mainnet-beta.
Contas graváveis quentes criam contenção local; sob carga, taxas de prioridade baixas ou zero perdem corridas de empacotamento, mesmo quando os mesmos bytes são bem-sucedidos em períodos de silêncio.
Não como um substituto do modelo mental: dicas e bundles são um caminho de pouso alternativo ou complementar para fluxos competitivos; sua mensagem ainda deve ser válida, assinada e corretamente contabilizada.
Versões da Stack: Esta página foi escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, anchor-lang 0.32.1, Rust 1.91.1, @solana/kit 7.0.0, Surfpool 0.12.0 e LiteSVM 0.6.x.
Revisado por Chris St. John·Última atualização: 15 de jul. de 2026