Carteiras e assinatura

Curiosidade

1. Por que uma transação Solana tem data de validade?
2. O que é exatamente que está sendo aprovado quando um usuário assina uma transação versionada?
3. Como uma única transação pode fazer referência a muito mais contas do que as listadas na íntegra?

Explorar

1. As chaves Solana são pares de chaves ed25519. A maioria das carteiras deriva essas chaves a partir de uma frase-semente BIP39, utilizando o caminho de derivação m/44’/501’/0’/0’. Esse padrão permite que os usuários recuperem toda a sua identidade em diferentes softwares compatíveis, desde que mantenham a frase mnemônica original de doze ou vinte e quatro palavras. A chave privada permanece local; a chave pública funciona na cadeia como o endereço da conta.
2. Uma transação lista instruções específicas e as contas afetadas por essas instruções. De forma crucial, ela inclui um hash de bloco recente. Esse hash atua como mecanismo de validade: se a transação não for processada dentro de aproximadamente 150 blocos, ou seja, em cerca de 60 a 90 segundos, o hash de bloco torna-se obsoleto e a rede rejeita a transação. Números únicos duráveis permitem que os usuários assinem transações que permaneçam válidas por períodos mais longos, utilizando um valor armazenado em uma conta especial de números únicos no lugar de um hash de bloco recente.
3. A assinatura aprova todas as instruções contidas na transação. Um payload malicioso pode transferir contas de token ou alterar suas configurações de autorização sem que o usuário tenha conhecimento dessas sub-instruções específicas. Carteiras como Phantom, Solflare e Backpack simulam essas transações para fornecer visualizações legíveis por humanos. No entanto, os usuários ainda podem aprovar instruções prejudiciais por meio da “assinatura cega”, na qual os dados brutos são aceitos sem verificação de sua intenção.
4. As transações versionadas introduzem tabelas de busca de endereços, permitindo que uma única transação faça referência a muitas contas por meio de índices, em vez de listar todos os endereços completos. Essa otimização reduz o tamanho em bytes das operações complexas que envolvem inúmeras cunhagens ou posições de tokens. O trade-off é a complexidade; entender os endereços resolvidos requer decodificar os índices da tabela com base no estado atual da conta referenciada.
5. Carteiras de hardware oferecem um ambiente isolado para assinaturas, com interface por USB ou códigos QR, a fim de proteger as chaves contra malware no sistema host. No entanto, a segurança depende da integridade do aplicativo host que cria e exibe os dados da transação. Se o host for comprometido, ele pode apresentar informações maliciosas enquanto o usuário assina algo que parece legítimo. Verificar todos os parâmetros diretamente na tela do dispositivo de hardware mitiga esse vetor de ataque específico.
6. Para inspecionar a estrutura de uma transação, abra um explorador de blocos da Solana e selecione qualquer transação recente que envolva uma operação em várias etapas. Expanda a seção “Instruções” para visualizar cada chamada de programa individualmente. Em seguida, examine a aba “Contas” para ver quais contas foram lidas ou escritas por cada instrução. Faça uma correlação dessas informações com os dados brutos para entender como a pré-visualização da simulação se relaciona com as mudanças reais de estado.

Fatos-chave

Exercício nove, seis, três, um

Verificação de fatos

Datas, números e afirmações verificados com as fontes publicadas listadas abaixo.

• Solana Documentation: Transactions and Durable Nonces
• Phantom Developer Documentation: Signing and Simulation
• BIP39: Mnemonic Code for Generating Deterministic Keys
• Solana Documentation: Versioned Transactions and Address Lookup Tables