Melhores Práticas do Modelo de Conta
Projete layouts de conta que escalam, permanecem seguros e minimizam custos de aluguel (rent) e computação (CU) no Agave 4.1.1.
Como Usar Esta Lista
- Aplique A antes de escrever sua primeira struct
#[account] - Revise B antes da auditoria de segurança de lançamento na mainnet
- Use C ao otimizar CU e rent em escala
A - Design do Layout
- Uma entidade lógica por conta. Fragmentar o estado do usuário entre PDAs, não em uma conta de mapa global.
- Use
InitSpace+max_lenpara campos variáveis. Nunca adivinhe tamanhos de String/Vec no Anchor 0.32.1. - Inclua um byte de
versionquando o esquema for evoluir. Alterações de campos somente anexáveis evitam quebras de desserialização. - Dimensionar contas para máximos realistas, não infinitos. Rent e CU escalam com bytes.
B - Segurança
- Toda conta
mutpossui verificações de proprietário + autoridade.Account<T>,has_one,seeds, ouconstraintexplícito. - Evite
UncheckedAccountsem restrições. Trate como culpado até provar que é válido. - Valide se os signatários correspondem às autoridades armazenadas.
Signer+has_onejuntos, não um sozinho. - Feche contas quando o ciclo de vida terminar. Retorne o rent aos usuários; evite "ralos" de lamport órfãos.
- Nunca aceite contas de vítima apenas pela chave pública. O atacante passa contas de outros se as restrições estiverem ausentes.
C - Operações
- Consulte
getMinimumBalanceForRentExemptionnos clientes. Não codifique embutido os lamports de rent. - Use
realloccom moderação e plano de migração. Prefira novos tipos de conta para alterações que quebram a compatibilidade. - Emita eventos na criação/fechamento. Indexadores dependem de sinais de ciclo de vida.
- Documente as seeds do PDA no IDL/documentação. A derivação do cliente deve corresponder exatamente às
seedsna cadeia. - Filtre
getProgramAccountspelo discriminador. Reduz a carga útil do RPC e o trabalho de decodificação do cliente.
FAQs
Qual é o pior erro no modelo de conta?
Falta de validação de proprietário/autoridade em contas graváveis - leva a vulnerabilidades de drenagem.
Quando devo usar zero-copy?
Contas maiores que alguns KB lidas/escritas frequentemente. Meça a CU antes de migrar.
Quantos PDAs por usuário são normais?
Um por objeto lógico (posição, pedido, cofre). Evite dezenas por ação para limitar o custo de UX do rent.
Os protocolos devem subsidiar a criação de contas?
Sim, para integração sem atritos quando o rent excede a tolerância do usuário - orce o tesouro de acordo.
Como auditar restrições de conta?
Mapeie cada instrução para cada conta mut; liste as verificações de tempo de execução aplicadas.
O `init_if_needed` é seguro?
Somente com seeds fortes e verificações de autoridade - caso contrário, os atacantes inicializam em nome da vítima.
Que espaço devo alocar para strings?
#[max_len(N)] no campo; InitSpace inclui 4 + N no total.
Posso compartilhar uma conta entre programas?
Apenas um programa proprietário. Compartilhe dados via CPI ou passagem somente leitura, não propriedade dupla.
Como lidar com migração de conta?
Novo PDA + instrução de cópia + desativar tipo antigo. Nunca reordene campos Borsh existentes.
A configuração global deve ser um PDA?
Sim - o singleton seeds = [b"config"] é o padrão para parâmetros de protocolo.
E a compressão de conta?
Use para conjuntos de dados massivos de baixa mutabilidade (cNFTs). Não para estado DeFi "quente".
Como o LiteSVM 0.6.x ajuda nos testes de conta?
Testes locais rápidos para init/close/realloc sem a sobrecarga do validador completo.
Relacionados
- Noções Básicas do Modelo de Conta - padrões práticos
- Propriedade e Permissões de Conta - regras de segurança
- Contas de Dados e Layout - orientação de dimensionamento
Versões da 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.