Como funcionam as transações no Solana?

Como cada taxa é paga ao executar uma transação, é importante entender como as transações funcionam. Uma transação é composta por três partes:

uma ou mais instruções
um array de contas para leitura ou escrita
uma ou mais assinaturas
blockhash recente ou nonce

Uma instrução é a menor lógica de execução no Solana. As instruções são uma chamada para atualizar o estado global do Solana. As instruções invocam programas que fazem chamadas ao runtime do Solana para atualizar o estado (por exemplo, chamar o token program para transferir tokens da sua conta para outra conta). Você pode pensar em uma instrução como uma chamada de função em um smart contract da Ethereum.

Uma diferença significativa entre Ethereum e Solana é o número de chamadas de função em uma única transação, devido ao número de instruções. Ter múltiplas instruções por transação beneficia os desenvolvedores, pois eles não precisam criar smart contracts personalizados para encadear funções em uma única transação. Cada instrução pode ser uma chamada de função separada, executada em ordem na transação. As transações são atômicas, o que significa que se qualquer uma dessas instruções falhar, toda a transação falhará, e você pagará apenas a taxa de transação. Isso é semelhante a uma transação falhar por não configurar o slippage correto na Ethereum.

Outra diferença importante a lembrar é o uso de um blockhash recente em vez de um nonce incremental para transações. Quando uma carteira deseja fazer uma transação, um blockhash recente será obtido do cluster para criar uma transação válida. Esse blockhash recente torna a transação válida apenas por 150 blocos após a recuperação do blockhash. Isso evita que assinaturas de transações de longa duração sejam executadas em uma data muito posterior.

Cross-Program Invocation (CPI)

Um Cross-Program Invocation (CPI) ocorre quando um programa Solana chama uma instrução em outro programa enquanto a transação original está sendo executada. O CPI é a principal forma pela qual os programas Solana se compõem entre si, mas o modelo de contas muda como você projeta o grafo de chamadas: a transação deve incluir todas as contas que toda a cadeia de CPI irá ler ou escrever antes do início da execução.

O receptor herda apenas os privilégios de assinante e de escrita que o chamador recebeu, e o receptor consome do mesmo orçamento de computação da transação. Use invoke quando todos os signatários necessários assinaram a transação original. Use invoke_signed quando o programa chamador precisar assinar por um de seus PDAs com seeds de assinante.

Níveis de confirmação

Leituras de RPC, assinaturas e lógica de confirmação de transações podem escolher um nível de commitment. Esta é a versão do Solana para decidir quantas confirmações de bloco da Ethereum aguardar, exceto que os níveis são explícitos:

processed: a visão processada mais recente do nó. Use apenas para UI otimista ou fluxos que tolerem reversão.
confirmed: um bloco votado por uma supermaioria do stake. Use como padrão para a maioria das confirmações em produção e status de transação voltado ao usuário.
finalized: o estado de confirmação mais forte. Use antes de ações off-chain irreversíveis, como pagamentos em moeda fiduciária, envio de mercadorias ou registros de liquidação final.

Se um método RPC aceita commitment e você o omitir, o padrão geralmente é finalized. Clientes em produção ainda devem definir o commitment explicitamente para que a latência da UI, o comportamento do indexador e a política de liquidação sejam deliberados.

Pagamentos de agentes