Solana (SOL): Como Funcionam as Transações e os Validadores

Estado vive em contas

Cada pedaço de estado persistente da Solana é mantido em uma conta identificada por um endereço de 32 bytes. Uma conta registra lamports, dados, um programa proprietário e campos relacionados à execução. O proprietário é o programa autorizado a alterar os dados dessa conta; não é necessariamente o humano que controla uma chave de carteira.

Programas Solana são contas executáveis contendo bytecode sBPF. Um programa é geralmente tratado como sem estado porque o estado mutável do aplicativo vive em contas separadas fornecidas a cada instrução. Isso permite que o runtime veja quais contas uma transação lerá ou escreverá antes da execução e agende trabalho que não disputa o mesmo estado gravável.

Carteiras, contas de token e PDAs

Um endereço de carteira pode possuir SOL e autorizar transações, mas um saldo de token SPL normalmente reside em uma conta de token associada a uma cunhagem e proprietário. Um Endereço Derivado de Programa é deterministicamente derivado de um programa ID e sementes; o programa pode autorizar por ele através de regras de runtime, embora nenhuma chave privada exista para o endereço.

Antes de enviar um token, confirme a cunhagem, a conta de token de destino e o programa sendo invocado. Um ticker familiar ou rótulo de carteira não é prova de que uma cunhagem é canônica. Fechar, criar ou realocar contas também pode mover lamports, então o resumo da transação deve ser revisado além do valor do token em destaque.

Mensagem, assinaturas e instruções

A mensagem lista endereços de conta, um blockhash recente e instruções compiladas. Cada instrução nomeia um programa e identifica as contas que pode usar. Assinantes obrigatórios autorizam a mensagem, e transações versionadas podem usar tabelas de consulta de endereço para referenciar mais contas sem colocar cada endereço diretamente no pacote.

Atualidade e confirmação

Um blockhash recente impede que uma transação comum permaneça válida indefinidamente. Se expirar antes do processamento, a transação deve ser reconstruída e assinada novamente; retransmitir a assinatura antiga não cria uma transação nova. Fluxos de nonce durável existem para assinatura offline ou atrasada especializada e exigem tratamento separado.

Clientes RPC expõem níveis de comprometimento processado, confirmado e finalizado. Uma interface rápida pode mostrar resultados processados antes que um acordo mais forte do cluster seja alcançado. Depósitos, pontes e ações de aplicativos dependentes devem esperar o nível exigido por esse serviço e verificar a assinatura através de um RPC ou explorador atual.

Componentes base e de prioridade

Cada transação paga uma taxa base em SOL pelas assinaturas obrigatórias. O protocolo expressa SOL em lamports, e o valor base, portanto, depende do número de assinaturas, não do valor de um pagamento ou troca de token. Uma transação com falha pode consumir a taxa base porque a verificação de assinatura e a execução foram tentadas.

Uma taxa de priorização opcional é baseada no limite de unidade de computação solicitado e no preço de unidade de computação escolhido. O limite é um orçamento, não uma previsão de uso real, então defini-lo muito mais alto do que o necessário pode pagar a mais pelo componente de prioridade. As estimativas da carteira devem usar condições recentes e simulação de transação em vez de copiar uma taxa fixa de outro aplicativo.

Verificações operacionais

Mantenha SOL suficiente para a taxa, mesmo quando o ativo transferido for um token SPL. Revise quaisquer instruções de orçamento de computação, pois elas podem alterar o limite solicitado e o preço de prioridade. Também distinga taxas de transação de financiamento de conta, saldos relacionados a aluguel, impacto de preço de troca e cobranças de aplicativos; são custos separados, mesmo que uma carteira os resuma juntos.