Melhores Práticas para Bibliotecas Essenciais

Repositórios Solana acumulam dezenas de crates e pacotes npm. Estas regras mantêm as dependências alinhadas com Agave 4.1.1, Anchor 0.32.1 e @solana/kit 7.0.0, enquanto reduzem o risco de cadeia de suprimentos e de auditoria.

Como Usar Esta Lista

• Execute durante o bootstrap do repositório e antes de cada atualização de programa mainnet.
• Aplique separadamente ao Cargo.toml on-chain, Rust off-chain e pacotes de cliente TS.
• Combine com cargo audit, npm audit e verificações de build verificáveis.

A - Alinhamento de Versão

• Fixe crates SDK alinhados com o validador. solana-program, solana-sdk e CLI 3.0.10 compartilham uma geração.
• Combine anchor-lang e Anchor CLI em 0.32.1. Evita desvios de IDL e macro.
• Fixe @solana/kit em 7.0.0 em todos os pacotes do monorepo. Evita duplicatas de majors em um único aplicativo.
• Documente Agave 4.1.1 em arquivos README/toolchain. Novos contribuidores reproduzem builds.
• Regenere clientes Codama quando a IDL mudar. CI falha em pastas geradas sujas.

B - Higiene de Dependência On-Chain

• Audite cargo tree para dependências std-only em programas. Quebra ou incha builds sBPF.
• Prefira crates SPL/MPL mantidos em vez de cópias vendidas. Receba patches de segurança.
• Minimize flags de features em anchor-lang. Cada feature pode expandir o tamanho do ELF.
• Registre o motivo da escolha de Pinocchio/Steel se pular Anchor. ADR para trilha de auditoria.
• Verifique as versões das crates MPL/CPI em relação aos IDs de programa implantados. Token-2022 vs SPL clássico diferem.

C - Bibliotecas de Cliente

• Não inicie novos aplicativos em @solana/web3.js v1. Use kit + Codama/gill.
• Mantenha locks Python solders/solana-py para bots. Envio reproduzível entre implantações.
• Separe constantes de ID de programa por cluster. Tabelas devnet/mainnet em um módulo.
• Use crates de ix oficiais @solana-program/* com kit. Menos layouts empacotados manualmente.
• Trate helpers DAS como específicos do provedor. Nem todos os URLs RPC implementam DAS.

D - Crates de Teste e Ferramentas

• Padronize em LiteSVM 0.6.x para testes unitários Rust. CI rápido com semântica compatível com Agave.
• Adicione testes de fumaça Bankrun ou do validador para lacunas de integração. Capture problemas apenas de RPC.
• Fixe Surfpool 0.12.0 para simulações de fork. Documente quando os testes de fork rodam em CI.
• Carregue blobs do programa SPL Token explicitamente em testes de harness. Evite falsos positivos.
• Rastreie testes de regressão de CU para instruções críticas de performance.

E - Cadeia de Suprimentos e Governança

• Habilite cargo deny ou equivalente para registros desconhecidos. Bloqueie crates com typosquatting.
• Revise mantenedores de novas crates MPL/comunitárias. Verifique a cadência de lançamento e a propriedade.
• Prefira crates usadas em templates de referência Anza/Anchor. Padrões testados em batalha.
• Registre o hash de build verificável com o artefato implantado. Corresponde ao fluxo solana-verify.
• Agende atualização trimestral de dependências com matriz de testes completa. Não atualizações de major apressadas.

FAQs

Relacionados

• solana-program & solana-sdk - crates principais
• @solana/kit, Codama & gill - stack TS
• Governança de Dependência e Crate - política da organização
• Visão Geral da Toolchain - pins de versão

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.