Gestión de cambios imprevistos en el desarrollo de contratos

Estoy leyendo aquí :

Administrador centralizado

Todas las dapps están completamente descentralizadas de forma predeterminada, pero eso no significa que no puedan tener algún tipo de administrador central, si así lo desea. Tal vez desee tener la capacidad de acuñar más monedas, tal vez desee prohibir que algunas personas usen su moneda. Puede agregar cualquiera de esas funciones, pero el problema es que solo puede agregarlas al principio , por lo que todos los poseedores de fichas siempre sabrán exactamente las reglas del juego antes de decidirse a poseer una.

(Énfasis mío)

¿Cuál es una mejor práctica para administrar los cambios que no prevé cuando inicia su dapp? Por ejemplo, suponga que solo emite 1000 cosas y luego encuentra un error, necesita aumentar a 1500, ¿cómo maneja esto?

Veo que este documento continúa con instrucciones para...

Casa de la Moneda Central

Suponga que desea cambiar la cantidad de monedas en circulación.

Pero suponga que no "solo los agregó al principio". ¿Ahora que? ¿Cómo cuadra esto con las afirmaciones anteriores y cómo maneja tales cambios?

Respuestas (1)

La idea básica es que su contrato debe respaldar todos los cambios que posiblemente desee realizar en el futuro. Entonces, si tiene algún número estático allí y no hay funcionalidad para cambiarlo, siempre permanecerá igual. Entonces, si tiene números que quizás desee cambiar en el futuro, agregue la funcionalidad para cambiarlos.

Sin embargo, esto no significa necesariamente que deba saber explícitamente qué partes desea cambiar en el futuro. Esto se debe a algo llamado contratos actualizables (consulte, por ejemplo, https://medium.com/quillhash/how-to-write-upgradable-smart-contracts-in-solidity-d8f1b95a0e9a ). Los contratos actualizables son solo un truco/patrón de diseño, pero debe agregar soporte para ellos al principio si desea utilizar este patrón.

Si se queda con un contrato que no se ajusta a sus propósitos y no puede extenderlo/modificarlo para que se adapte a sus propósitos, su única opción es redactar un nuevo contrato y, de alguna manera, migrar a todos para que usen el nuevo contrato. Dependiendo del tipo de contrato, esto puede ser algo entre imposible y trivial.

Gracias, esto es útil. ¿Es esta la versión mínima y más accesible de la idea de contratos actualizables que debo estudiar para su implementación?
¿"De alguna manera, la migración de todos para usar el nuevo contrato" posiblemente signifique, esencialmente, forjar su propio contrato? ¿Replicar los datos almacenados allí, sujetos a sus cambios, pero no puede eliminar la existencia del anterior?
Ese es un artículo algo avanzado sobre contratos actualizables. Estoy seguro de que también puede encontrar artículos más básicos si es necesario. Y sí, no puede eliminar el contrato anterior, por lo que debe hacer una bifurcación dura del anterior: migrar datos y hacer que todos usen el nuevo contrato
También puede usar contratos inteligentes actualizables "basados ​​​​en proxy / kernel" que le permitirán actualizar la funcionalidad al vincularse a un contrato diferente cuando necesite actualizar las cosas. Usted quiere que las partes afectadas "acuerden dichos cambios" antes de que entren en vigor. Consulte el proyecto Aragon o las fuentes del proyecto Blockbitsio para conocer algunas implementaciones que le permitirán migrar a una nueva funcionalidad.
Gestión de cambios imprevistos en el desarrollo de contratos
RespuestasAquíPolítica de privacidad1y, 0v