Tornando Programas Imutáveis
Revogar a autoridade de atualização torna o bytecode do programa permanente na chain. Os usuários ganham confiança de que a lógica não pode ser alterada, mas você perde a capacidade de corrigir bugs sem implantar um novo ID de programa e migrar o estado.
Receita
Cartão de receita de referência rápida - pronto para copiar e colar.
# Irreversível - confirme o ID do programa e o hash primeiro
solana program set-upgrade-authority <PROGRAM_ID> --final
solana program show <PROGRAM_ID> | grep AuthorityQuando usar isso:
- Protocolo maduro maximizando a confiança (trustlessness).
- Lançamento final pós-auditoria sem alterações planejadas.
- Requisito da comunidade para contratos imutáveis.
- Concluindo o cronograma de governança para congelar o código.
Exemplo de Trabalho
PROGRAM_ID=YourProgram1111111111111111111111111111111
# 1. Verifique se o hash corresponde à atestação publicada
solana-verify get-program-hash "$PROGRAM_ID" --url mainnet-beta
# compare com a atestação do README
# 2. Confirme a finalidade pretendida do multisig (se aplicável)
# proposta do squads: "Revogar autoridade de atualização"
# 3. Revogue a autoridade (FINAL)
solana program set-upgrade-authority "$PROGRAM_ID" --final
# 4. Confirme imutável
solana program show "$PROGRAM_ID"
# Authority: (none)O que isso demonstra:
--finaldefine a autoridade de atualização para nulo permanentemente.- Nenhuma instrução pode atualizar o ELF após este ponto.
- Exploradores mostram o status imutável aos usuários.
Mergulho Profundo
Como Funciona
- O upgradeable loader verifica a chave pública da autoridade nas instruções de atualização.
- Autoridade nula rejeita todas as atualizações futuras.
- O ID do programa e os endereços voltados para o usuário permanecem válidos.
- Nova lógica requer nova implantação de programa + migração de estado.
Imutável vs. Atualizável
| Aspecto | Imutável | Atualizável |
|---|---|---|
| Confiança | Estabilidade máxima do código | Risco de governança |
| Correção de bug | Novo programa + migrar | Implantar mesmo ID |
| Autoridade | Nenhuma | Multisig recomendado |
| Timing | Após auditoria + período de "bake" | Padrão de desenvolvimento padrão |
Notas do bash
# Não há como desfazer na CLI - apenas implante um novo programa se um bug for encontrado
echo "Certifique-se de que os playbooks de incidentes cubram a migração para um novo ID de programa"Armadilhas
- Revogação prematura - Bug descoberto após a revogação. Correção: Período de "bake" com atualizações apenas por multisig antes de
--final. - ID de programa errado - Revogação de implantação não intencional. Correção: Verifique triplamente a chave pública e a saída de
program show. - Bytecode não verificado - Código ruim imutável para sempre. Correção:
solana-verifypara corresponder antes da revogação. - Assumir que a migração é fácil - Fundos do usuário vinculados a PDAs de programas antigos. Correção: Planeje ferramentas de migração antes do marketing de imutabilidade.
- Padrões de proxy - Programa imutável com delegado atualizável confunde os usuários. Correção: Documente a arquitetura claramente.
- Revogação de hot wallet - Chave comprometida revoga cedo. Correção: Multisig executa a revogação final.
Alternativas
| Alternativa | Usar Quando | Não Usar Quando |
|---|---|---|
| Autoridade de atualização multisig | Janela de patch operacional | Marketing de imutabilidade absoluta |
| Timelock + governança | Supervisão da comunidade | Necessidade de correção de bug instantânea |
| Novo programa versionado | Alterações drásticas planejadas | Conveniência do mesmo ID |
FAQs
A imutabilidade pode ser revertida?
Não - permanente na chain. Apenas implante um novo programa com um novo ID.
Quando devemos revogar?
Após auditorias, período de "bake" de produção, publicação de hash verificável e voto de governança.
Imutável afeta contas?
Contas de propriedade do programa permanecem - apenas alterações de código são bloqueadas.
Imutabilidade parcial?
Não na chain - a autoridade existe ou é nula. Use multisig como um meio-termo prático.
Hash imutável + verificado?
Melhor prática - os usuários verificam o hash e depois veem a autoridade imutável no explorador.
Impacto no cliente?
Nenhum se o ID do programa não for alterado - os clientes continuam com a mesma chave pública.
Revogação final do Squads?
Crie uma proposta executando set-upgrade-authority --final via instrução multisig.
Teste em Devnet?
Pratique a revogação em um programa descartável na devnet antes da cerimônia principal.
Ângulo legal/de conformidade?
Declarações de imutabilidade devem corresponder ao campo de autoridade na chain - verifique em auditorias.
Emergência após revogação?
Implante o programa v2, instruções de migração, comunicação com o usuário - sem caminho de atualização na v1.
Relacionado
- Program Upgrades - antes da imutabilidade
- Governance-Gated Upgrades - caminho multisig
- Verifiable Builds - verifique primeiro
- Deployment Best Practices - política de autoridade
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.