A Transação
Uma transação Solana não é um script de formato livre que você envia para um contrato inteligente.
É uma mensagem assinada e com limite de tempo que lista todas as contas que serão acessadas, todos os programas que serão chamados e todas as assinaturas necessárias - e então aplica todas as suas instruções ou nenhuma delas.
Transactions Basics mostra etapas concretas de construção e envio; Instruções e contas, Taxas prioritárias e Blockhashes & Expiry ampliam cada um em uma peça.
Esta página é a camada abaixo: o modelo único que faz com que essas páginas pareçam um sistema, em vez de uma lista de verificação de APIs.
Resumo
- Ideia principal: Uma transação é uma mensagem (instruções, metas de conta, blockhash recente ou nonce durável, pagador de taxa) mais assinaturas sobre essa mensagem, executada atomicamente pelo tempo de execução.
- Por que é importante: Quase todas as falhas de inclusão, taxa e "perda de transferência" são um mal-entendido sobre contas, vencimento ou mercados de taxas - e não sobre a lógica de negócios do programa.
- Conceitos principais: instrução, AccountMeta, signatário, pagador de taxas, blockhash recente, atomicidade, unidades de computação (CU), taxa de prioridade, transação versionada (v0), tabela de pesquisa de endereço (ALT), simulação.
- Quando usar: Projetar caminhos de envio do cliente, depurar quedas silenciosas versus erros na cadeia, escolher taxas somente básicas versus taxas prioritárias versus inclusão avançada ou ensinar como os pacotes Solana funcionam antes de escrever programas.
- Limitações/Compensações: Listas de contas explícitas e tempos de vida curtos compram agendamento paralelo e segurança de reprodução, ao custo de maior complexidade do cliente (atualizar blockhashes, definir orçamentos de CU, lidar com congestionamento local).
- Tópicos relacionados: Bloqueios de conta Sealevel, programa Compute Budget, nonces duráveis, dicas e pacotes Jito.
Fundações
Uma transação tem duas partes de nível superior: a mensagem (o que deve acontecer) e as assinaturas (quem autorizou aquela bytestring exata).
O runtime não inventa contas ou programas em seu nome; tudo o que uma instrução precisa já deve estar nomeado na mensagem.
Uma instrução é a menor unidade de trabalho: um program_id, uma lista de contas e um data opaco que o programa entende (geralmente 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 é uma AccountMeta: uma chave pública mais dois booleanos, is_signer e is_writable.
Esses sinalizadores não são dicas para documentação; eles são o bloqueio e a superfície de autoridade que o tempo de execução impõe antes da execução de qualquer bytecode do programa.
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 dados modificados e está bloqueada para gravação exclusiva durante a execução desta transação.
Contas que só são legíveis podem ser agendadas em paralelo com outras transações que também só as lêem; dois escritores na mesma conta argumentam.
O pagador da taxa normalmente é a primeira conta marcada como assinante obrigatório e deve possuir SOL (lamports) suficiente para cobrir as taxas de toda a transação.
Atomicidade significa que a lista completa de instruções foi bem-sucedida ou o estado do razão dessas instruções foi revertido; você não obtém "instrução 1 confirmada, instrução 2 falhou parcialmente aplicada".
A execução malsucedida ainda pode custar taxas, porque os validadores gastaram computação tentando realizar o trabalho - não tratam a falha como algo gratuito.
Uma analogia útil é um formulário de transferência bancária de várias etapas: cada número de conta é escrito antecipadamente no formulário, cada assinatura exigida está no mesmo papel, o formulário expira após um curto período de validade e o banco publica o pacote inteiro ou o rejeita - nunca deixa metade das linhas aplicadas.
Isso está mais próximo de Solana do que um "ligue para este contrato e deixe-o descobrir o armazenamento" em aberto.
Mecânica e interações
Construir e realizar uma transação é um ciclo fechado de composição, autorização, (opcionalmente) simulação, envio e confirmação - sempre contra uma nova vida útil.
compose message authorize decide
--------------- --------- ------
instructions[] ──► message ──► signatures[] ──► simulate? ──► send
account metas ▲ │
fee payer │ │ err / CU
recent blockhash ──────┘ ▼
(or durable nonce) adjust & rebuild
│
▼
RPC / leader
│
▼
execute atomically
(all ok or none)
Componha: Colete todas as instruções que seu fluxo precisa (transferência de sistema, token SPL, seu programa anchor, orçamento de computação e assim por diante) e unifique todas as contas que essas instruções exigem na lista de contas de mensagens com sinalizadores de signatário/graváveis corretos.
Vitalício: 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 - normalmente 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 uma mudança de blockhash, cargas idênticas poderiam ser reproduzidas para sempre; com um, as novas tentativas após a expiração devem ser reconstruídas e assinadas 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, lançamento agendado) - mesmo modelo de mensagens e assinaturas, mecanismo de vida útil diferente. Consulte Blockhashes e expiração.
Autorizar: Toda conta com is_signer: true deve contribuir com uma assinatura na mensagem serializada (carteira, chave de back-end, signatário de hardware).
A falta de uma assinatura obrigatória falha antes do trabalho significativo do programa; assinaturas extras desperdiçam taxa básica sem autoridade de compra que você não declarou.
Taxas: A taxa básica varia de acordo com o número de assinaturas na transação.
A taxa de prioridade opcional é definida incluindo instruções do programa Compute Budget: normalmente 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. Os detalhes estão em The Compute Budget Program e Taxas prioritárias.
Simular: a simulação RPC executa a transação em relação ao estado atual do banco sem confirmar, retornando erros, logs e, muitas vezes, unidades de computação consumidas.
Utilize simulação para comprovação (contas erradas, restrições falhadas, fundos insuficientes) e para dimensionar o limite de UC ligeiramente acima do consumo medido em vez de sempre solicitar o máximo.
Enviar e confirmar: O envio entrega os bytes assinados a um RPC (ou um caminho de destino especializado); os líderes ordenam e executam no Sealevel usando os bloqueios de conta declarados.
Seu cliente deve tratar "enviado" como algo diferente de "confirmado": atualize o blockhash e assine novamente no vencimento e prefira assinatura ou pesquisa de assinatura 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, os mercados de taxas locais se formam em torno de contas graváveis: dois swaps que lutam contra a mesma conta de pool não estão competindo igualmente com toda a cadeia - eles competem entre si pelo bloqueio de gravação dessa conta e pelas escolhas de empacotamento do líder.
Aumentar a taxa de prioridade ajuda quando você está faminto por inclusão; ele não corrige um sinalizador de signatário errado ou um blockhash expirado.
Considerações e aplicações avançadas
Mensagens legadas versus versionadas (v0) compartilham o mesmo modelo mental (instruções, contas, assinaturas, atomicidade), mas diferem em quantas contas você pode ajustar dentro do limite de tamanho serializado.
As transações legadas incorporam cada chave pública da conta na mensagem.
Transações versionadas (v0) podem fazer referência a tabelas de pesquisa de endereços (ALTs): tabelas de endereços em cadeia nas quais a mensagem é indexada, para que mais contas caibam sem repetir chaves completas de 32 bytes para cada entrada. Aprofundamento conceitual: Transações versionadas (v0) e Tabelas de pesquisa de endereços.
Use v0 + ALTs ao compor grandes gráficos de CPI (roteadores DeFi, swaps multi-hop, pipelines mint complexos); seja simples com menos contas quando não precisar do espaço.
Limites de CU orientados por simulação supere 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 na sua urgência e na concorrência observada.
Dicas e pacotes Jito são um caminho de inclusão avançado: você pode pagar uma gorjeta e/ou enviar um pacote atômico para inclusão com reconhecimento de MEV, ainda sob as mesmas instruções e regras de conta, mas por meio de infraestrutura especializada, em vez de apenas taxa de prioridade no caminho público. Mantenha isso conceitual até precisar dele - consulte Jito Tips & Bundles.| Estratégia | O que você paga | Força | Fraqueza | Melhor ajuste | |----------|-------------|----------|----------|----------| | Apenas taxa base | Custo base por assinatura | Mais barato; tudo bem quando a rede está silenciosa | Inclusão fácil de perder sob carga ou em contas quentes | Devnet, transferências de baixa contenção, administração não urgente | | Taxa de prioridade (Compute Budget) | Base + CU_preço × CU utilizado/limite | Funciona com RPC normal; urgência ajustável | Pagar a mais desperdiça SOL; pagamento insuficiente ainda cai | A maioria dos dapps de produção, moedas NFT, swaps de varejo | | Ponta Jito/pacotes | Dica (+ prioridade opcional) via caminho especializado | Pouso mais forte e pacotes atômicos multi-tx | Complexidade extra de operações; não é um substituto para txs corretos | Fluxos competitivos sensíveis a MEV, conjuntos atômicos de várias etapas |
Nenhuma dessas estratégias altera a atomicidade ou as regras do AccountMeta; eles só mudam o valor do seu lance para inclusão quando a mensagem é válida.
Os clientes em @solana/kit 7.0.0 devem preferir construtores de mensagens v0, pagadores de taxas explícitas e ajudantes vitalícios, e simulação antes dos caminhos de envio da mainnet.
Os programas no Anchor 0.32.1 ainda executam apenas as contas declaradas pelo cliente - as macros da estrutura geram dados de instruções e listas de contas, mas o modelo de tempo de execução acima continua sendo a fonte da verdade.
Equívocos comuns
- "Uma transação é apenas uma chamada para o meu programa." É uma mensagem com múltiplas instruções com uma lista global de contas, pagadores de taxas, tempo de vida e assinaturas; seu programa é um (ou mais) dos chamados, não o contêiner.
- "Se a lógica do programa estiver correta, a transação será concluída." Os programas corretos ainda falham quando os blockhashes expiram, os orçamentos da CU são muito baixos, as taxas não são competitivas ou as contas são sinalizadas incorretamente.
- "Gravável significa que o programa sempre pode escrever." Gravável apenas concede o bloqueio de tempo de execução; somente o programa proprietário pode alterar os dados da conta e sua instrução ainda deve passar por todas as restrições.
- "As novas tentativas podem reenviar os mesmos bytes assinados para sempre." Uma vez que o blockhash fica obsoleto, essas assinaturas autorizam uma mensagem expirada; reconstrua com um novo blockhash e assine novamente (a menos que use um design nonce durável).
- **"Taxa prioritária substitui simulação."**Taxa prioritária compra preferência de agendamento; a simulação captura falhas semânticas e dimensiona CU - você precisa de ambos sob carga real.
- "Mais contas sempre significam uma taxa maior." A taxa básica rastreia assinaturas, não a contagem de contas; a contagem de contas atinge limites de tamanho e bloqueia a contenção mais do que a taxa básica diretamente.
- "Sucesso parcial é possível se a última instrução falhar." Dentro de uma transação, a execução é atômica para a lista de instruções; projete fluxos de usuário de várias etapas como um único tx quando você precisar de tudo ou nada.
Perguntas frequentes
O que é uma transação Solana em uma frase?
Uma mensagem assinada listando instruções ordenadas e todas as contas que elas tocam, executadas atomicamente dentro de um curto período de vida definido por um blockhash recente (ou nonce durável).
Qual é a diferença entre uma mensagem e uma transação?
A mensagem é a intenção não assinada (contas, instruções, vitalício, pagador de taxas); a transação é aquela mensagem mais as assinaturas que a autorizam.
O que contém uma instrução?
Um ID de programa a ser invocado, uma lista ordenada de AccountMetas e uma matriz de bytes de dados de instrução para esse programa decodificar.
O que is_signer e is_writable realmente controlam?
is_signer requer uma assinatura correspondente (autoridade); is_writable permite mutação e usa um bloqueio de gravação usado para agendamento paralelo e segurança.
Quem paga as taxas e como é escolhido o pagador?
O pagador da taxa é um assinante obrigatório da mensagem (geralmente o primeiro), cujo saldo de lamports é debitado para taxas básicas e prioritárias para toda a transação.
Por que as transações precisam de um blockhash recente?
Ele torna cada mensagem única (proteção de repetição) 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 a 90 segundos.
O que acontece quando um blockhash expira?
Os validadores rejeitam ou descartam a transação por considerá-la muito antiga; você deve buscar um novo blockhash, reconstruir a mensagem se necessário, assinar novamente e reenviar.
Quando devo usar um nonce durável em vez de um blockhash recente?
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 atrasada - aceitando o mecanismo extra de conta nonce.As transações com falha são gratuitas?
Não. Ainda podem ser cobradas taxas pelo trabalho executado pela rede; trate a simulação como uma maneira barata de detectar falhas antes de pagar por um caminho de envio completo.
Qual a diferença entre as taxas básicas e as taxas prioritárias?
A taxa básica está vinculada às assinaturas da transação; a taxa de prioridade é um preço opcional da UC (via Compute Budget) que aumenta a competitividade da inclusão sob carga.
Por que definir o limite da unidade de cálculo e o preço da unidade de cálculo?
Limite a quantidade de computação que você permite (e alimenta o cálculo da taxa); o preço é o seu lance por UC - juntos eles definem quanto orçamento prioritário você coloca na mesa sem ultrapassar cegamente.
Qual problema as transações v0 versionadas e ALTs resolvem?
Eles permitem que as mensagens façam referência a contas por meio de tabelas de pesquisa na cadeia, de modo que grandes listas de contas caibam no limite de tamanho da transação sem incorporar todas as pubkeys completas inline.
Para que serve a simulação se eu já testei a unidade do meu programa?
A simulação verifica essa mensagem exata em relação ao estado atual do cluster - contas, saldos, CU e logs - que os testes de unidade em uma VM local não substituem totalmente para chegar ao devnet ou mainnet-beta.
Por que minha transferência só falha quando o mercado está movimentado?
Contas graváveis a quente criam contenção local; sob carga, taxas de prioridade baixa ou zero perdem corridas de empacotamento, mesmo quando os mesmos bytes são bem-sucedidos em períodos de silêncio.
As gorjetas do Jito substituem as taxas prioritárias?
Não como um substituto do modelo mental: gorjetas e pacotes são um caminho alternativo ou complementar para fluxos competitivos; sua mensagem ainda deve ser válida, assinada e contabilizada corretamente.
Relacionado
- Transactions Basics - criar, assinar e enviar padrões
- Instructions & Accounts - AccountMeta, IDs de programas e dados
- Transações versionadas (v0) - formato de mensagem v0
- Taxas prioritárias - mercados de taxas locais e preço CU
- O Programa de Orçamento Compute - setComputeUnitLimit e setComputeUnitPrice
- Blockhashes e Expiry - tempos de vida, novas tentativas e nonces duráveis
Versões 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.