Melhores Práticas de Consenso
Escolhendo o compromisso certo para seu aplicativo.
Como Usar Esta Lista
- Revise antes do lançamento da mainnet e após incidentes
- Marque os itens por ciclo de lançamento
A - Fundamentos
- Fixar toolchain Agave 4.1.1. CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1 alinhados em CI.
- Usar @solana/kit 7.0.0 para novos clientes. Evite web3.js v1 para trabalho novo.
- Combinar cluster RPC, carteira e explorador. Prevenir erros falsos de "conta não encontrada".
B - Confiabilidade
- Confirmar em
confirmedoufinalized. Não trateprocessedcomo final. - Atualizar blockhash ao tentar novamente. Transações expiradas são descartadas silenciosamente.
- Simular e ler logs. Decodificar erros de programa antes de reenviar.
C - Economia e Segurança
- Orçar taxas de prioridade sob congestionamento. Mercados de taxas locais precisam de instruções de Compute Budget.
- Validar signatários e proprietários de contas. Restrições ausentes são vulnerabilidades críticas.
- Fechar contas não utilizadas para recuperar aluguel. Retornar lamports aos usuários quando o ciclo de vida terminar.
FAQs
Como isso se aplica no Agave 4.1.1?
O Agave 4.1.1 está em transição para o Alpenglow — trate os tempos de confirmação como dependentes da versão.
Qual versão do Solana CLI devo usar?
Use Solana CLI 3.0.10, que combina com Agave 4.1.1. Instale com agave-install init 4.1.1 (ou o arquivo de pin da sua equipe), depois verifique com solana --version e agave-install --version.
Devo usar @solana/kit ou web3.js?
Use @solana/kit 7.0.0 para novos métodos RPC tipados em TypeScript, superfície de API menor e exemplos nesta página já usam Kit. Mantenha web3.js apenas para bases de código legadas; migre chamadas RPC e construção de transações incrementalmente.
Qual nível de compromisso é recomendado?
Use confirmed para UX que tolera forks raros; use finalized antes de pagamentos irreversíveis ou mensagens de ponte. Reavalie os tempos limite durante a implantação do Alpenglow.
Como depuro falhas relacionadas?
Quando as transações desaparecem, verifique o nível de compromisso: confirmed não é finalized. Registre as transições de status durante a migração.
Isso funciona no devnet?
Sim — aponte o CLI e o RPC para https://api.devnet.solana.com. O comportamento corresponde ao mainnet; apenas os dados da conta e a economia diferem.
Como as unidades de computação afetam isso?
Mudanças de consenso raramente afetam CU — concentre-se na UX de confirmação e nas configurações de tempo limite.
Qual é o padrão do Anchor 0.32.1?
Padrões do Anchor 0.32.1 se aplicam quando você escreve programas on-chain: contas tipadas, guardas require!, e geração de IDL — use avm use 0.32.1 e anchor-lang = "0.32.1" em Cargo.toml.
Como testar com Surfpool 0.12.0?
Surfpool ajuda a testar scripts de polling do cliente contra estado forkado; ele não simula os internos de votação do validador.
O LiteSVM 0.6.x pode cobrir isso?
LiteSVM para lógica de programa; RPC do devnet para comportamento de finalidade durante a implantação do Alpenglow.
O que mudou na era Agave?
O cliente validador foi renomeado para Agave (4.1.1), o CLI 3.0.10 se alinha a ele, e o trabalho do Alpenglow está mudando a finalidade — fixe as versões e leia as notas de lançamento a cada atualização.
Onde encontro métodos RPC relacionados?
getSignatureStatuses em múltiplos compromissos; getVoteAccounts para saúde do validador.
Relacionado
- Veja páginas irmãs nesta seção para profundidade específica do tópico.
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.