Melhores Práticas de Blockchain

Hábitos de segurança em primeiro lugar para engenharia de blockchain em Rust - programas on-chain, carteiras e ferramentas de nó.

Como Usar Esta Lista

• Aplique A-B ao iniciar um novo programa ou pallet.
• Conclua C-D antes da implantação em mainnet e exposição ao tesouro.
• Revise E trimestralmente para higiene de dependências e chaves.

A - Qualidade do Código On-Chain

• Use aritmética checked_* para todos os valores de token. Nunca confie no wrapping em modo de release.
• Prefira padrões Anchor ou FRAME em vez de fatiamento bruto de bytes. Menos erros de desserialização.
• Mantenha as instruções pequenas e cientes do consumo de computação. Divida trabalhos pesados entre transações ou provadores off-chain.
• Retorne erros tipados, não panics. Panics abortam programas e confundem clientes.
• Documente o layout da conta e os invariantes em comentários de código. Auditores e você no futuro precisam da especificação.

B - Chaves e Ambientes

• Nunca compartilhe chaves entre devnet e mainnet. Carteiras descartáveis apenas para testes locais.
• Armazene chaves do tesouro em multisig ou HSM. Chaves de deployer "quentes" devem ter saldo mínimo.
• Fixe URLs de RPC por ambiente na configuração. Um endpoint errado assina contra um cluster não intencional.
• Verifique se o ID do programa corresponde ao hash do artefato auditado. Erros de implantação na cadeia de suprimentos acontecem.
• Rotacione segredos de CI e revogue chaves de deploy antigas após o lançamento.

C - Testes e Verificação

• Teste de integração de cada instrução e caminho de erro. Corresponda às expectativas do cliente IDL.
• Execute um validador local em CI para repositórios de programas. Capture regressões de deploy precocemente.
• Simulação antes de fluxos de envio voltados para o usuário. Exponha logs do programa na UI para falhas.
• Testes de propriedade em helpers de merkle e matemática. Bugs de off-by-one são comuns.
• Auditoria externa antes de TVL significativo. Nenhum substituto para revisão humana qualificada.

D - Operações

• Monitore as taxas de erro do programa e o uso de computação pós-implantação. Picos indicam ataque ou bug.
• Timelock ou multisig em atualizações. Usuários precisam de aviso antes que as mudanças de lógica ocorram.
• Playbook de incidentes: pause, comunique, corrija, verifique. Minutos importam em explorações.
• cargo audit e cargo deny no pipeline. Repositórios de cripto são alvos de alto valor.
• Registre pubkeys e assinaturas, nunca seeds ou chaves privadas.

E - Disciplina de Design

• Minimize o estado on-chain - armazene hashes, não dados em massa. Aluguel e provas de merkle escalam melhor.
• Prefira a composibilidade através de programas conhecidos (SPL, etc.). Reinventar padrões de token adiciona risco.
• Versionamento de SDKs de cliente com lançamentos de programas on-chain. IDL incompatível causa erros ao usuário.
• Documente a política de decimais e arredondamento na documentação voltada para o usuário. Tickets de suporte seguem confusão aqui.
• Assuma entradas adversárias em cada instrução pública. Validadores e bots enviarão bytes estranhos.

FAQs

Relacionados

• Segurança e Auditoria - lista de verificação pré-auditoria
• Programas Solana - padrões Anchor
• Carteiras e Gerenciamento de Chaves - níveis de chave
• Criptografia Aplicada - primitivas

Versões de Stack: Esta página foi escrita para Rust 1.97.0 (edição 2024), Tokio 1.x, Axum 0.8, serde 1.0, sqlx 0.8, clap 4, e Polars 0.46+.