Boas Práticas de PDAs no Anchor
Uso determinístico e validado de PDAs no programa e nos clients.
Como usar esta lista
- Aplique a cada nova PDA introduzida em um programa.
- Compartilhe constantes de seed entre Rust e TypeScript.
- Teste derivação no teste Anchor e no client kit.
A - Derivação
- Documente seeds na documentação do IDL ou módulo de constantes compartilhado - clients devem corresponder byte a byte.
- Armazene bump canônico no init - referencie em instruções posteriores.
- Use constraints Account tipadas - não UncheckedAccount para PDAs.
- Mantenha seeds mínimas - arrays longos de seeds custam CU.
B - Assinatura e CPIs
- Use ctx.bumps ou bump armazenado nos signers de CPI - nunca adivinhe bump.
- Separe PDAs de treasury por mercado - limite blast radius.
- Verifique mint/ATA authority correspondendo à PDA - em todo CPI de token.
FAQs
Qual versão do Anchor é assumida?
0.32.1 em toda esta seção.
Uma PDA pode ser Signer na struct accounts?
Não. Use constraints seeds e assinatura em CPI.
Onde o bump é armazenado?
No campo da sua struct de conta, definido na inicialização.
Como os clientes derivam PDAs?
Use @solana/kit 7.0.0 com bytes de seed correspondentes.
Qual program id é usado para PDAs?
O endereço declare_id do seu programa Anchor.
As seeds incluem bump?
Não no array seeds; bump é parâmetro separado para find_program_address.
Como depurar falhas de PDA?
Compare chaves logadas; verifique seeds e program id no client.
PDAs são rent-exempt?
Sim quando mantêm dados; financie com payer no init.
Uma PDA pode assinar múltiplos CPIs em uma ix?
Sim com as mesmas signer seeds para cada CPI.
O que ler em seguida?
Veja os links em Relacionados para tópicos mais profundos sobre boas práticas de PDAs.
Relacionados
- PDAs no Anchor - introdução
- Erros comuns de PDA - lista de auditoria
- Assinatura com PDAs - assinatura em CPI
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.