Solía tratar a "inmutable" como una reafirmación. Se despliega código, las reglas quedan corregidas, nadie se mete. Luego te sientas con un contrato que tiene que vivir veinte años. En ese lapso surge un bug, cambia una ley, hay que corregir un error. El código inmutable no se puede parchear. La funcionalidad se convierte en la trampa.
Así que los equipos agregan silenciosamente capacidad de actualización: claves de administrador, una votación de gobernanza que puede reemplazar la lógica. Y ahora has reintroducido exactamente lo que la inmutabilidad pretendía matar: alguien que puede reescribir las reglas de tu activo después de que lo compraste. Inmutable y actualizable son opuestos, y un activo regulado de larga duración parece necesitar ambos.
Lo que significa que la pregunta honesta nunca fue "¿es inmutable?". Es "¿quién puede cambiar el código y verás venir ese cambio?" Una clave de administrador silenciosa es una puerta trasera con estética.
Aquí es donde una cadena como @Dusk debe tener cuidado. Las reglas que viven dentro del activo solo ayudan si los cambios están acotados, versionados y son visibles: una enmienda conforme a la ley, no un intercambio mediante una clave oculta. La cadena debe hacer imposible ocultar quién cambió qué.
Me mantengo escéptico. La mayoría de los contratos "actualizables" se apoyan en multisigs frágiles; una sola concesión puede volverlo todo vulnerable. Y una gobernanza lo bastante lenta como para ser segura puede ser demasiado lenta para un bug que está sangrando activamente.
¿Quién lo necesita? Los emisores de activos que sobreviven a su primer códigobase. Lo que lo mata: claves ocultas, o una gobernanza demasiado lenta para un incendio.
Vale la pena vigilarlo. La pregunta real es quién sostiene el bolígrafo.
$DUSK #dusk
Así que los equipos agregan silenciosamente capacidad de actualización: claves de administrador, una votación de gobernanza que puede reemplazar la lógica. Y ahora has reintroducido exactamente lo que la inmutabilidad pretendía matar: alguien que puede reescribir las reglas de tu activo después de que lo compraste. Inmutable y actualizable son opuestos, y un activo regulado de larga duración parece necesitar ambos.
Lo que significa que la pregunta honesta nunca fue "¿es inmutable?". Es "¿quién puede cambiar el código y verás venir ese cambio?" Una clave de administrador silenciosa es una puerta trasera con estética.
Aquí es donde una cadena como @Dusk debe tener cuidado. Las reglas que viven dentro del activo solo ayudan si los cambios están acotados, versionados y son visibles: una enmienda conforme a la ley, no un intercambio mediante una clave oculta. La cadena debe hacer imposible ocultar quién cambió qué.
Me mantengo escéptico. La mayoría de los contratos "actualizables" se apoyan en multisigs frágiles; una sola concesión puede volverlo todo vulnerable. Y una gobernanza lo bastante lenta como para ser segura puede ser demasiado lenta para un bug que está sangrando activamente.
¿Quién lo necesita? Los emisores de activos que sobreviven a su primer códigobase. Lo que lo mata: claves ocultas, o una gobernanza demasiado lenta para un incendio.
Vale la pena vigilarlo. La pregunta real es quién sostiene el bolígrafo.
$DUSK #dusk
