Boas Práticas de Programas Nativos
Código nativo possui todo check de segurança. Estas práticas mantêm programas pequenos, legíveis e resistentes a exploits comuns em Solana.
Como Usar Esta Lista
- Revise cada nova instruction contra a seção A antes do merge.
- Mantenha tabela de meta de conta na documentação do repo.
- Execute
cargo build-sbfe testes LiteSVM em CI.
A - Validação Explícita
- Documente ordem de contas em tabela por instruction. Clients e auditores compartilham uma fonte de verdade.
- Valide signers antes de mutações de data writable. Impede mudanças de state não autorizadas.
- Verifique PDAs com bumps canônicos armazenados on-chain. Bloqueia ataques de brute-force de seed.
- Rejeite pubkeys duplicadas em caminhos de token. Previne manipulação de saldo.
- Carregue sysvars via getters tipados, não contas passadas. Evita injeção de sysvar falso.
B - Estrutura e Clareza
- Uma função handler por variante de instruction. Simplifica auditorias e testes.
- Centralize parse + dispatch no módulo processor. Entrada única para bytes de instruction.
- Mantenha helpers puros quando possível. Testes unitários mais fáceis no host.
- Publique enum de código de erro correspondendo a valores on-chain. Clients decodificam falhas consistentemente.
- Versione schema de instruction com byte explícito. Suporta upgrades sem ambiguidade.
C - Deploy e Ops
- Fixe SDK solana-program na toolchain Agave 4.1.1. Builds reproduzíveis.
- Produza artefatos de build verificáveis. Usuários confiam no bytecode implantado.
- Snapshot de CU por instruction em testes. Detecção de regressão.
- Minimize dependências no crate do programa. Superfície de ataque e binário menores.
- Zere data no close; roteie rent deliberadamente. Previne ataques de revival.
FAQs
Time Anchor indo para nativo?
Geralmente apenas hot paths, não app inteiro.
Quantos revisores?
Pelo menos um revisor focado em segurança Solana.
IDL obrigatório?
Fortemente recomendado para clients.
Alvos de fuzz?
Parser de instruction e validador de conta.
Usar macros?
Macros internas pequenas OK; evite fluxo de controle oculto.
Layout de módulos?
instruction, processor, state, error padrão.
Clippy em SBF?
Execute em testes host cfg.
Documentar CPIs?
Liste programas callee e mudanças de privilégio.
Deploy imutável?
Escrutínio extra antes de queimar upgrade key.
Nativo + Token-2022?
Valide layouts de extensão explicitamente.
Surfpool local?
Ambiente dev padrão conforme manifest.
Open source?
Encorajado para auditabilidade.
Relacionado
- Validação Manual de Contas - Detalhes do checklist
- Boas Práticas de Rust para Solana - Hábitos de linguagem
- Auditoria de Segurança de Programas - Prep de auditoria
Versões do 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.