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 AuthorityCuá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:
--finalestablece 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
| Aspecto | Inmutable | Actualizable |
|---|---|---|
| Confianza | Máxima estabilidad del código | Riesgo de gobernanza |
| Corrección de errores | Nuevo programa + migrar | Despliegue con el mismo ID |
| Autoridad | Ninguna | Se recomienda multisig |
| Momento | Después de auditoría + período de prueba | Patrón de desarrollo predeterminado |
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-verifycoincide 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
| Alternativa | Usar Cuando | No Usar Cuando |
|---|---|---|
| Autoridad de actualización multisig | Ventana de parcheo operativo | Marketing de inmutabilidad absoluta |
| Bloqueo de tiempo + gobernanza | Supervisión comunitaria | Necesidad de corrección de errores instantánea |
| Nuevo programa versionado | Cambios disruptivos planificados | Conveniencia del mismo ID |
Preguntas Frecuentes
¿Se puede revertir la inmutabilidad?
No - permanente en la cadena. Solo desplegar un nuevo programa con un nuevo ID.
¿Cuándo deberíamos revocar?
Después de auditorías, período de prueba de producción, publicación de hash verificable y voto de gobernanza.
¿Afecta la inmutabilidad a las cuentas?
Las cuentas propiedad del programa permanecen - solo se bloquean los cambios de código.
¿Inmutabilidad parcial?
No en la cadena - o existe autoridad o es nula. Usar multisig como un punto intermedio práctico.
¿Hash inmutable + verificado?
Mejor práctica - los usuarios verifican el hash y luego ven la autoridad inmutable en el explorador.
¿Impacto en el cliente?
Ninguno si el ID del programa no cambia - los clientes continúan con la misma clave pública.
¿Revocación final de Squads?
Crear una propuesta que ejecute set-upgrade-authority --final a través de una instrucción multisig.
¿Pruebas en Devnet?
Practicar la revocación en un programa desechable de devnet antes de la ceremonia de mainnet.
¿Ángulo legal/de cumplimiento?
Las declaraciones de inmutabilidad deben coincidir con el campo de autoridad en la cadena - verificar en auditorías.
¿Emergencia después de la revocación?
Desplegar programa v2, instrucciones de migración, comunicaciones al usuario - no hay ruta de actualización en v1.
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.