Explicação do Endereço de Carteira Solana: Formato, Segurança e Erros Comuns

Um endereço de carteira Solana é um valor de 32 bytes exibido como uma string codificada em base58 que os usuários copiam para carteiras e exploradores para enviar ou receber SOL e tokens.

Fundamentos do Formato de Endereço Solana

Os endereços de conta Solana são valores de 32 bytes exibidos como strings codificadas em base58. Essas strings não possuem prefixo fixo e não contêm checksum embutido, o que diferencia o formato de muitos outros esquemas de endereços de blockchain.

A codificação base58 na Solana utiliza um alfabeto que deliberadamente exclui os caracteres 0, O, I e l. A omissão reduz a ambiguidade visual quando os endereços são lidos ou copiados. Como o comprimento da codificação varia conforme o conteúdo dos bytes, as strings válidas variam de 32 a 44 caracteres, embora a grande maioria dos endereços tenha 43 ou 44 caracteres.

A representação compacta suporta tanto chaves públicas on-curve derivadas de pares de chaves Ed25519 quanto endereços derivados de programa off-curve. Em ambos os casos, as mesmas regras de base58 se aplicam, então os usuários veem apenas a string codificada final, independentemente de como os 32 bytes subjacentes foram gerados. Essa apresentação uniforme mantém as interfaces de carteiras e os exploradores de blocos consistentes em toda a rede.

Como não há checksum, cada caractere importa. Uma única substituição ou omissão produz um endereço de aparência totalmente válida que pode pertencer a outra conta. O intervalo de comprimento e as restrições do alfabeto servem, portanto, como as principais dicas visuais que os usuários utilizam ao verificar endereços antes de enviar fundos.

Chaves Públicas On-Curve e Endereços Derivados de Programa

Os endereços de par de chaves Ed25519 na Solana vêm de pares de chaves criptográficas padrão. Esses endereços on-curve suportam controle direto por chave privada, permitindo que os usuários assinem transações e gerenciem ativos por meio de carteiras comuns.

Os endereços derivados de programa (PDAs) seguem um modelo diferente. Eles são gerados deterministicamente a partir de um ID de programa e um conjunto de seeds, posicionando-os fora da curva Ed25519. Não existe chave privada para um PDA, portanto o controle passa inteiramente para o programa que o criou.

A diferença de controle determina os padrões de uso. Endereços on-curve são adequados para holdings pessoais, onde um proprietário deve manter autoridade de assinatura. Os PDAs servem a funções em nível de contrato, como escrow ou contas de token, onde o programa aplica a lógica e assina sem expor chaves a terceiros.

As carteiras rejeitam importações de PDA porque nenhum par de chaves corresponde ao endereço. Os desenvolvedores, portanto, escolhem endereços on-curve para fundos de usuários e PDAs quando é necessária autoridade programática, evitando ativos bloqueados ou tentativas de assinatura falhas decorrentes de tipos de endereço incompatíveis.

Geração e Validação de Endereços Solana

Os endereços Solana são formados deterministicamente a partir de pares de chaves Ed25519 ou seeds. Uma carteira cria um par de chaves e codifica sua chave pública de 32 bytes em base58, produzindo a string de endereço final. As frases-semente seguem caminhos de derivação padrão para recriar o mesmo par de chaves e endereço em qualquer dispositivo compatível.

A codificação base58 utiliza o alfabeto 123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz. Esse conjunto exclui 0, O, I e l para limitar a confusão visual. Os endereços codificados válidos variam de 32 a 44 caracteres, sendo 43–44 os mais comuns.

A validação requer duas verificações. Primeiro, confirme que cada caractere pertence ao alfabeto base58. Segundo, decodifique a string e verifique se o resultado equivale exatamente a 32 bytes. Como os endereços Solana não possuem checksum embutido, essas etapas sozinhas confirmam a correção estrutural antes de qualquer uso on-chain.

Ataques de Envenenamento de Endereço e Erros de Usuário

Os ataques de envenenamento de endereço funcionam inserindo endereços visualmente semelhantes no histórico de transações de um usuário. Os atacantes geram endereços Solana que correspondem aos primeiros quatro a seis caracteres ou aos últimos quatro a seis caracteres de um destinatário conhecido e então iniciam pequenas transferências ou interações que posicionam a entrada envenenada diretamente acima ou abaixo dos registros legítimos.

Como os endereços Solana são strings base58 longas sem checksums embutidos, muitos usuários verificam apenas o prefixo ou sufixo visível ao confirmar um destino. Esse hábito de correspondência parcial permite que um único caractere diferente no meio da string passe despercebido, direcionando os fundos para o atacante.

Hábitos de verificação concretos eliminam a dependência de correspondências parciais. Sempre copie o endereço completo de uma fonte verificada e cole-o em um campo de texto separado para comparação lado a lado. Rotule contatos recorrentes dentro da carteira para que seleções futuras exibam um nome em vez de caracteres brutos. Para transferências acima de um limite pessoal, envie primeiro um valor mínimo de teste e confirme o recebimento em um explorador antes de liberar o valor total. Quando a parte receptora fornece um código QR, escaneie-o diretamente em vez de transcrever caracteres manualmente. Carteiras de hardware que exibem o endereço completo na tela oferecem uma camada de verificação independente que contorna a área de transferência do dispositivo host.

Essas etapas alongam o processo de confirmação em apenas alguns segundos, mas fecham o principal vetor usado pelos atacantes. A verificação consistente da string completa evita perdas decorrentes do formato de endereço da Solana e de atalhos baseados em histórico.

Taxas, Limites de Transação e Comparação de Endereços

Toda transação Solana incorre em uma taxa base fixa de 5.000 lamports por assinatura, com metade queimada e metade paga ao líder do bloco, além de qualquer taxa de priorização opcional. Essa estrutura por assinatura afeta diretamente como endereços on-curve e endereços derivados de programa são usados dentro de uma única transação.

O formato de transação V1 elevou o tamanho máximo serializado para 4.096 bytes. O limite maior permite até 64 contas em alguns casos e incorpora detalhes de unidades de computação e taxas diretamente na mensagem, reduzindo o número de assinaturas necessárias para operações complexas que antes exigiam múltiplas transações.

Como os PDAs não podem assinar, os desenvolvedores frequentemente os roteiam por meio de signatários on-curve. O limite de 4.096 bytes do V1 permite que mais contas caibam em uma única transação, reduzindo o total de assinaturas e, portanto, a taxa base agregada quando ambos os tipos de endereço aparecem juntos.

FAQ

Qual deve ser o comprimento de um endereço Solana para ser válido?

Os endereços Solana codificados em base58 variam de 32 a 44 caracteres, embora 43–44 caracteres sejam os mais comuns para chaves públicas e PDAs de 32 bytes.

Um endereço derivado de programa pode receber tokens como uma carteira normal?

Os PDAs funcionam como contas, mas não possuem chaves privadas, portanto não podem assinar transferências; os programas os controlam de forma determinística.

Como os usuários identificam ataques de envenenamento de endereço na Solana?

Sempre verifique a string de endereço completa em vez de corresponder apenas aos primeiros ou últimos caracteres exibidos no histórico de transações.

Qual taxa se aplica a cada transação Solana?

É cobrada uma taxa base de exatamente 5.000 lamports por assinatura, com 50% queimados e 50% pagos ao líder do bloco.

Qual é o tamanho máximo de dados para uma conta Solana?

As contas suportam até 10 MiB de dados de acordo com as especificações atuais da rede.

Quando a verificação de identidade pode ser aplicada durante uma swap na Solana?

A Xgram não exige KYC para a maioria das swaps; no entanto, transações sinalizadas por procedimentos de conformidade podem acionar análise adicional e verificação de identidade.