Uno de los principales beneficios de es su inmutabilidad. Proporcionar un registro de datos inmutable, con marca de tiempo e inolvidable. En la cadena de bloques Ethereum, los contratos inteligentes, a menudo programados en Solidity, se almacenan en la cadena de bloques y, por lo tanto, son inmutables. Un contrato inteligente puede modificar su almacenamiento como parte de una transacción, con el nuevo estado del contrato actualizado almacenado en la cadena de bloques. Sin embargo, el contrato en sí no puede modificarse.
Esta inmutabilidad de los contratos inteligentes significa que, a diferencia de otros códigos, los contratos no pueden actualizarse ni actualizarse. Por lo tanto, la práctica común de actualización y actualización de software no se puede aplicar a un contrato inteligente per se.
Naturalmente, los errores, las mejoras y los requisitos cambiantes necesitarían alguna forma de modificar la recopilación de contratos que comprenden una aplicación . Dicha aplicación puede ser una aplicación pura o una aplicación web y más combinada, comúnmente llamada Dapp (aplicación descentralizada).
¿Lógica para siempre inmutable?
En general, se han propuesto tres enfoques para la actualización del contrato. El artículo Consideraciones esenciales de diseño para Ethereum ÐApps (1): contratos inteligentes actualizables resume bien estos enfoques. En la práctica, todos estos enfoques deben tomarse juntos, ya sea con codificación manual o en la construcción de un marco de actualización de contrato inteligente.
Modularización de contratos
Tanto para la actualización como para seguir las buenas prácticas de ingeniería de software, separe los datos y la lógica de un contrato.
Para cada contrato importante, divida la lógica del contrato, tanto la lógica comercial como la autorización (en forma de modificadores de acceso) en contratos separados.
Tal enfoque permitiría una actualización separada de los datos y la lógica.
Migración de datos
Extraiga los datos del contrato anterior, escríbalos en el nuevo contrato y simplemente olvide el contrato anterior.
Tal enfoque requiere detener el antiguo contrato con una función de interruptor de circuito. Sin embargo, este enfoque es claramente problemático para un Dapp, como cerrar un servidor de aplicaciones web ordinario, deja a los usuarios colgados sin la funcionalidad.
Envuelva el contrato con un proxy
Cada contrato inteligente está envuelto por un proxy para actualizaciones. Por lo tanto, siempre implementamos dos contratos. El primer contrato es un simple contenedor o "proxy" con el que los usuarios interactúan directamente y se encarga de reenviar las transacciones hacia y desde el segundo contrato, que contiene la lógica. El concepto clave a entender es que el contrato lógico puede reemplazarse mientras el proxy o el punto de acceso nunca cambian. Ambos contratos siguen siendo inmutables en el sentido de que su código no se puede cambiar, pero el contrato lógico simplemente puede ser cambiado por otro contrato. Por lo tanto, el contenedor puede apuntar a una implementación lógica diferente y al hacerlo, el software se "actualiza".
El patrón básico tomado de Consideraciones de diseño esenciales para Ethereum ÐApps (1): contratos inteligentes actualizables es:
retransmisión de contrato {
abordar la versión pública actual;
dirección del propietario público;
modificador onlyOwner () {
require (msg.sender == propietario);
_;
}
relé de función (dirección initAddr) {
currentVersion = initAddr;
propietario = msg.sender; // este propietario puede ser otro contrato con multisig, no un solo propietario de contrato
}
función changeContract (address newVersion) public
onlyOwner ()
{
currentVersion = newVersion;
}
función () {
require (currentVersion.delegatecall (msg.data));
}
}
El patrón proxy ha sido generalmente aceptado por la comunidad como una solución generalmente aplicable.
ZeppelinOS es una plataforma para desarrollar, implementar y operar proyectos de contratos inteligentes en Ethereum y cualquier otra cadena de bloques impulsada por EVM y eWASM.
El patrón de actualizaciones de ZeppelinOS generaliza la idea del envoltorio de proxy para ser una parte integral de un marco de desarrollo completo, que incluye una variación del conocido Truffle Framework reescrito para admitir la capacidad de actualización.
La idea básica es:
Usuario —- tx —> Proxy ———-> Implementation_v0
El |
————> Implementation_v1
El |
————> Implementation_v2
Reenvío de proxy
El reenvío de las llamadas del proxy al contrato se realiza de la siguiente manera:
asamblea {
let ptr: = mload (0x40) // (1) copia datos de llamadas entrantes
calldatacopy (ptr, 0, calldatasize) // (2) desvío de llamada al contrato lógico
resultado let: = delegatecall (gas, _impl, ptr, calldatasize, 0, 0)
let size: = returndatasize // (3) recupera datos devueltos
returndatacopy (ptr, 0, size) // (4) reenviar datos de retorno a la persona que llama
resultado del cambio
caso 0 {revertir (ptr, tamaño)}
predeterminado {return (ptr, size)}
}
Este código se puede colocar en la función alternativa de un proxy y reenviará cualquier llamada a cualquier función con cualquier conjunto de parámetros al contrato lógico sin que sea necesario saber nada en particular de la interfaz del contrato lógico.
Estructurando Almacenamiento
Usar una llamada delegada significa que la llamada se ejecuta en el contexto del contrato de representación. Por lo tanto, ZeppelinOS usa una novela almacenamiento no estructurado enfoque para asegurarse de que el almacenamiento del contrato de implementación no anule el almacenamiento del contrato proxy.
Se sugieren precauciones especiales en términos de diseño de almacenamiento para asegurarse de que sea posible una actualización.
Hacia arriba y hacia adelante
2key Network es una red de referencia basada en destinada a recompensar a los referidos a través de contratos inteligentes. Las referencias progresan a través de la red gracias a las personas que las comparten a través de sus navegadores habituales. Por lo tanto, 2key genera enlaces firmados criptográficamente fuera de la cadena, que se propagan entre los usuarios sin llegar a la cadena de bloques. Tras la conversión, un usuario envía el enlace firmado al contrato inteligente. El contrato inteligente premia a la cadena de referencias como se representa en el enlace firmado. El iniciador de la campaña despliega el contrato inteligente por campaña de referencia, depositando una recompensa de referencia, como una cantidad de criptomoneda, de la cual el contrato inteligente luego pagará a los referentes.
Contratos persistentes vs efímeros
La colección de 2key Network de contratos inteligentes se divide en dos partes:
Contratos persistentes: Estos contratos administran todo el ecosistema y sirven como singletons: cada uno solo tiene una instancia activa implementada y sirve a toda la red en un momento dado. Esto incluye el token 2KEY Contrato economico que es un contrato basado en ERC20, como se especifica en el Estándar de Token ERC20, el Contrato de gobierno 2key, modelado a partir del conocido Cómo construir una DEMOCRACIA en la guía de Ethereum. Otros contratos únicos en la red incluyen el contratos de intercambio de fondos de liquidez, la contratos del congreso, el usuario y la reputación contrato de registro y otros. Todos estos, excepto el contrato económico en sí, requieren actualización para soportar un ciclo de vida de software viable, a medida que evolucionan las funcionalidades y optimizaciones de la red.Contratos efímeros: El contrato de una campaña está destinado a la duración de la campaña y eso es todo. En cuanto a negocios, una campaña implementa una lógica previamente acordada que no va a cambiar. Sin embargo, dicho contrato incluirá referencias y, por lo tanto, convocatorias a los contratos permanentes.
Actualice los contratos persistentes
Se puede proyectar cómo pueden evolucionar los tipos de contratos ERC20 y los contratos de gobernanza, y construir mecanismos especiales de actualización en estos. Pero, a medida que 2key Network desarrolla nuevos mecanismos de incentivos económicos para ser implementados en su modelo de reputación y modelo de incentivos, es difícil prever que los contratos correspondientes evolucionarán. Además, a medida que la red madura, sus mecanismos de gobernanza deberían estar más distribuidos. En general, para soportar una evolución viable para la red, los singletons deben soportar la capacidad de actualización.
En consecuencia, estamos implementando una nueva modificación sobre el patrón de proxy como nuestro mecanismo para la actualización de los contratos persistentes. En las próximas publicaciones compartiremos más en profundidad cómo funciona el esquema de actualización de 2key y cómo se combina con una nueva tubería de CICD para contratos inteligentes para actualizar el paquete npm de protocolo de 2key utilizado por los nodos del navegador de 2key.
Lanza lo efímero después de usarlo
Los contratos de campaña se crean de nuevo por campaña y, como parte del proceso de conversión, crea contratos de custodia para mantener temporalmente los activos simbólicos adquiridos por los convertidores.
Examinando toda la colección de contratos en torno a una campaña, todos estos se implementan desde nuestro Dapp para una campaña. Por lo tanto, dado que, en términos comerciales, esta colección de contratos implementados por campaña no puede cambiar, no tenemos la necesidad de actualizar esta colección.
Estos contratos efímeros siguen siendo viables mientras están activos, luego archivados. Las nuevas versiones de contrato para contratos pueden servir para campañas futuras, pero como el ciclo de vida de una campaña es limitado, no necesita actualización por sí mismo. Los contratos de campaña contienen referencias e interactúan con los contratos persistentes de la red, pero esto será una referencia a los proxies correspondientes, que les permiten contactar siempre con la lógica de red persistente actualizada.
Creemos que la red 2key dividida en contratos persistentes y efímeros es un buen enfoque de diseño para Dapps en general y especialmente para Dapps maduros y escalables. Esta división entre un núcleo de red persistente y contratos efímeros transitorios es una práctica novedosa que ni siquiera se encuentra en el software ordinario. Es claramente distinto del conocido enfoque core vs plugins.
