Cardstack en Español -Contratos actualizables en Solidity — Parte 02/03

Registro

El siguiente componente del enfoque actualizable de cardstack, es el registro. El registro crea una buena abstracción sobre las direcciones reales de Ethereum para los contratos que participan en nuestro ecosistema. La idea es que solo necesitamos saber el “nombre” de un contrato, y consultar el registro de la versión más reciente del contrato que tiene un nombre particular.

Además, los contratos que necesitan usar el almacenamiento compartido no necesitan conocer la dirección del almacenamiento compartido; más bien, pueden declarar al registro su interés en utilizar un cubo de almacenamiento en particular (que también tiene un nombre), y el registro se ocupará de vincular el almacenamiento al contrato que haya declarado interés en usarlo.

Entonces, a un nivel realmente alto, es el registro el que está haciendo el trabajo de mantener un registro de las direcciones de todos los contratos en nuestro sistema y mapear los nombres de los contratos en las direcciones de los contratos.

registry.addStorage()

Después de implementar el contrato de almacenamiento, lo agregan al registro y asignan un nombre al contrato de almacenamiento, todo ello al llamar a la funciónregistry.addStorage(). De aquí en adelante, cuando los contratos se registran en el registro, pueden declarar su intención de usar el almacenamiento por su nombre. El registro es entonces responsable de resolver el nombre de almacenamiento en una dirección específica, así como otorgarle al contrato “permisos” para usar el almacenamiento (más sobre esto más adelante).

registry.registerContract()

Para los contratos que participan en el ecosistema y que no son contratos de almacenamiento, por ejemplo: El contrato de tokens, usan la función registry.registerContract() para agregarlos a nuestro registro. Sus bcontratos implementan una interfaz storable.sol, que tiene la siguiente declaración:

storable.sol

Como se puede observar, el nombre del libro mayor y el nombre de almacenamiento utilizados por el contrato del token se especifican en el constructor del contrato y luego se devuelven en la funciónstorable.solAdemás, el token de contrato implementa una interfaz configurable.sol,que declara una función configureFromStorage(). En esta función, está el registro para resolver los nombres de almacenamiento a direcciones reales:

CardstackToken.sol (snippet)

Y en este momento ya se tiene un token de contrato que está vinculado a los tokens de almacenamiento para los que ha declarado interés.

Entonces, un resumen rápido:

1. Se Agregó almacenamiento al registro y se asignó un nombre al almacenamiento.
2. Se creó un contrato (en este caso un contrato de token) que declara el interés en usar almacenamiento con un nombre específico.
3. Se registró un contrato con el registro, que luego resuelve los nombres del almacenamiento a direcciones específicas de Ethereum dentro del contrato que se registra.

upgradeContract()

La capacidad de actualizar un contrato queda expresada en la función upgradeContract(). Los parámetros de esta función son el nombre del contrato y la dirección del contrato “sucesor” (donde el contrato actual se convierte en el contrato predecesor).

El registro usará el mismo mecanismo que se aprovechó en el registro del contrato predecesor para descubrir el almacenamiento que el contrato sucesor ha declarado que está interesado en utilizar. El registro resuelve la dirección del almacenamiento en el contrato sucesor y vincula el almacenamiento dentro del contrato sucesor usando la función configureFromStorage().

Durante la operación de actualización, los permisos del contrato predecesor en el almacenamiento se revocan, de modo que ese contrato ya no puede manipular el almacenamiento. Del mismo modo, se otorgan los permisos del contrato sucesor sobre el almacenamiento, de modo que ese contrato puede manipular el almacenamiento. Además, el modificador,unlessUpgraded, evitará que se ejecuten las funciones de ese contrato predecesor y, en su lugar, hará que reviertan.

El contrato predecesor también adquiere una propiedad que apunta al contrato sucesor como resultado de la actualización del contrato del contrato, por lo que los clientes del contrato pueden descubrir la nueva dirección del actualizada. Finalmente, se emite un evento llamando a ContractUpgradedcuando se actualizan los contratos (así como un evento llamando aAddrChangedpara el soporte de resolución ENS EIP-137, más sobre esto más adelante).

■ Autor:

Hassan Abdel-Rahman

Developer at Cardstack

■ Primera Parte

Hemos publicado la primera parte de este artículo en:
https://medium.com/@rDieminger/cardstack-contratos-actualizables-en-solidity-parte-01-4a446a453c45

■ Tercera Parte

Hemos publicado la tercera parte de este artículo en:
https://medium.com/@rDieminger/cardstack-contratos-actualizables-en-solidity-parte-03-03-2944075d97a0

---

Para obtener más información sobre Cardstack y el próximo Token Generating Event (THE), visite visite el website de cardstack.com o lea el white paper.
También le invito a ver un corto vídeo en video intro

■ Si tiene preguntas puede usar el Telegram en ingles o el Telegram en español

Me ayudas?