Hacer Programas Inmutables

Revocar la autoridad de actualización hace que el bytecode del programa sea permanente en la cadena. Los usuarios ganan confianza en que la lógica no puede cambiar, pero pierdes la capacidad de corregir errores sin desplegar un nuevo ID de programa y migrar el estado.

Receta

Tarjeta de receta de referencia rápida - lista para copiar y pegar.

# Irreversible - confirma primero el ID del programa y el hash
solana program set-upgrade-authority <PROGRAM_ID> --final
solana program show <PROGRAM_ID> | grep Authority

Cuándo usar esto:

• Protocolo maduro que maximiza la confianza.
• Lanzamiento final post-auditoría sin cambios planificados.
• Requisito de la comunidad para contratos inmutables.
• Completar el cronograma de gobernanza para congelar el código.

Ejemplo de Trabajo

PROGRAM_ID=YourProgram1111111111111111111111111111111
 
# 1. Verificar que el hash coincide con la   atestación publicada
solana-verify get-program-hash "$PROGRAM_ID" --url mainnet-beta
# comparar con la   atestación del README
 
# 2. Confirmar la finalidad   del multisig (si aplica)
# propuesta de squads: "Revocar autoridad de actualización"
 
# 3. Revocar autoridad (FINAL)
solana program set-upgrade-authority "$PROGRAM_ID" --final
 
# 4. Confirmar inmutable
solana program show "$PROGRAM_ID"
# Authority: (none)

Lo que esto demuestra:

• --final establece la autoridad de actualización a nulo permanentemente.
• Ninguna instrucción puede actualizar ELF después de este punto.
• Los exploradores muestran el estado inmutable a los usuarios.

Inmersión Profunda

Cómo Funciona

• El cargador actualizable verifica la clave pública de autoridad en las instrucciones de actualización.
• La autoridad nula rechaza todas las futuras actualizaciones.
• El ID del programa y las direcciones visibles para el usuario siguen siendo válidos.
• La nueva lógica requiere un nuevo despliegue de programa + migración de estado.

Inmutable vs. Actualizable

Notas de bash

# No hay deshacer en la CLI - solo desplegar un nuevo programa si se encuentra un error
echo "Asegúrate de que los manuales de incidentes cubran la migración a un nuevo ID de programa"

Trampas

• Revocación prematura - Error descubierto después de la revocación. Solución: Período de prueba con actualizaciones solo por multisig antes de --final.
• ID de programa incorrecto - Revocar un despliegue no intencionado. Solución: Verificar triple la clave pública y la salida de program show.
• Bytecode no verificado - Mal código inmutable para siempre. Solución: solana-verify coincide antes de revocar.
• Asumir que la migración es fácil - Fondos de usuario vinculados a PDAs del programa antiguo. Solución: Planificar herramientas de migración antes del marketing de inmutabilidad.
• Patrones de proxy - Programa inmutable con delegado actualizable confunde a los usuarios. Solución: Documentar claramente la arquitectura.
• Revocación con billetera activa - Clave comprometida revoca temprano. Solución: Multisig ejecuta la revocación final.

Alternativas

Preguntas Frecuentes

Relacionado

• Actualizaciones de Programas - antes de la inmutabilidad
• Actualizaciones Controladas por Gobernanza - ruta multisig
• Builds Verificables - verificar primero
• Mejores Prácticas de Despliegue - política de autoridad

Versiones de Stack: Esta página fue 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, y LiteSVM 0.6.x.