Cómo salvaguardamos nuestros contratos inteligentes (y gobernanza)

Con base en los requisitos, creamos un marco que facilita todo el trabajo de gobernanza y procesos, mantiene todas las dependencias de los diferentes marcos utilizados y expone una interfaz para ser utilizada por todos los diferentes componentes del protocolo.

Basado en eso: el Dori El marco fue creado

El objetivo de la implementación era hacerlo lo más fácil de usar posible. Además, la automatización de todo el proceso fue un factor muy importante al construir Dori. Contiene muchas comprobaciones diferentes sobre los contratos en la forma y el formato correctos. También verifica cada contrato si se inicializó correctamente una vez que finalizó la implementación en .

A partir de hoy Dori ha implementado los siguientes métodos:

Implementar contratos Actualizar contratos Auditoría
– Propietario del contrato de auditoría
– Transacciones de billetera del propietario de auditoría
– Transacciones de billetera de actualización de auditoría
– Auditoría de actualizaciones de contratos Obtenga direcciones de contratos

Detalles pueden ser encontrados aqui:

Hagamos un flujo de muestra de implementación, actualización y auditoría juntos. Comenzamos con el primer paso, la implementación de los contratos en el repositorio de Keeper-Contracts.

Implementar contratos

Cada contrato se puede implementar de forma independiente o en combinación con el resto de los contratos como un paquete. En este caso, desplegamos solo el OceanToken del paquete Keeper-Contracts.

Para hacerlo simplemente haz:

$ npm run desplegar: desarrollo – OceanToken

Esto creará un conjunto de nuevas billeteras Multi Sig para la red dada (en caso de que no se conozcan billeteras Dori)

$ npm run deploy: desarrollo – OceanTokenUtilizando el 'desarrollo' de la red. Configuración de MultiSigWallets
Usando el desplegador multisig: 0xFc8cC71563D81Db00fCc4F96BD0c00Cb19B7773E
Uso de propietarios multigrado:
(
"0xFc5B252ec96De8F67A71fdf2cFB700cAF36246b8",
"0xF748bb8BC1eEb0A84fA2d894Bbbfc7D6c1c247d9",
"0x0163715C11edE95e485f52e3d497007ccca66941"
)
Carteras creadas:
(
{
"nombre": "mejorador",
"dirección": "0xEF2626Fe5810F83f417f4894FE56B52DB4535cdd"
},
{
"nombre": "propietario",
"dirección": "0x19c4059daC2c3637Ab601B6dE2Ccd549b43bdC8F"
}
)
en /Users/sebastian/projects/ocean/L1/keeper-contracts/wallets.json

Entonces lo hará registro el contrato en OpenZeppelin SDK / CLI, desplegar ellos a la y inicializar eso.

(ZosPackageFile) Creado zos.json
Comprobación del estado de implementación de los contratos: 'OceanToken'.
El contrato OceanToken no se implementa.
(LocalController) Agregando OceanToken
(ZosPackageFile) Actualizado zos.json
(NetworkAppController) Contrato de validación OceanToken
(NetworkAppController) Carga del contrato de OceanToken como OceanToken
(BaseSimpleProject) Implementación del contrato lógico para OceanToken
(ProxyAdmin) Implementación de un nuevo ProxyAdmin …
(ProxyAdmin) ProxyAdmin implementado en 0xDE319b65dB5e32b1ad8452c23B6B90c4b299C518
(BaseSimpleProject) Crear proxy para contrato lógico 0x9a221DA5bbdA64F43a71c4B21Bc067759b267974 e inicializar llamando a initialize con:
– _owner (dirección): "0x19c4059daC2c3637Ab601B6dE2Ccd549b43bdC8F"
– _initialMinter (dirección): "0xFc8cC71563D81Db00fCc4F96BD0c00Cb19B7773E"
(BaseSimpleProject) Instancia creada en 0xe689a4AC25145e0a8382485a92Fc836C9F045EBF
Contratos desplegados a los representantes:
{
"OceanToken": "0xe689a4AC25145e0a8382485a92Fc836C9F045EBF"
}
Renunciando al desplegador como minter inicial desde 0xFc8cC71563D81Db00fCc4F96BD0c00Cb19B7773E
Comprobación de la propiedad de los contratos desplegados.
El propietario del contrato OceanToken se establece en la billetera del propietario en 0x19c4059daC2c3637Ab601B6dE2Ccd549b43bdC8F
La propiedad está configurada correctamente.
Configuración de zos-admin en MultiSigWallet '0xEF2626Fe5810F83f417f4894FE56B52DB4535cdd'
(ProxyAdmin) Cambio de administrador para proxy 0xe689a4AC25145e0a8382485a92Fc836C9F045EBF a 0xEF2626Fe5810F83f417f4894FE56B52DB4535cdd …
(ProxyAdmin) Admin para proxy 0xe689a4AC25145e0a8382485a92Fc836C9F045EBF establecido en 0xEF2626Fe5810F83f417f4894FE56B52DB4535cdd
(ZosNetworkFile) Actualizado zos.dev-1573046330925.json
Exportar artefacto: OceanToken.development.json
Artefacto de contrato exportado: v0.12.7 de OceanToken en 0xe689a4AC25145e0a8382485a92Fc836C9F045EBF

Como se ve arriba del dirección del poder es 0xe689a4AC25145e0a8382485a92Fc836C9F045EBF.

Contratos desplegados a los representantes:
{
"OceanToken": "0xe689a4AC25145e0a8382485a92Fc836C9F045EBF"
}

Contratos de actualización

Una vez que se produce un cambio en el contrato, debe actualizarse.

Para hacerlo simplemente haz:

$ npm run mejorar: desarrollo – OceanToken

Esta voluntad cambiar la implementación del contrato en el poder dado. Como podemos ver aquí, no se han creado billeteras, pero las existentes se han utilizado para enviar la transacción de actualización.

$ npm run upgrade: desarrollo – OceanTokenUsando la red 'development'.wallets.json ya existe en /Users/sebastian/projects/ocean/L1/keeper-contracts/wallets.json. Cargando
Cargando la billetera 'actualizador' en '0xEF2626Fe5810F83f417f4894FE56B52DB4535cdd'
Cargando la billetera 'propietario' en '0x19c4059daC2c3637Ab601B6dE2Ccd549b43bdC8F'

Ahora Dori agregará el contrato nuevamente al OpenZeppelin SDK / CLI. Durante una actualización, Dori comprobar si el poder de los contratos existe o no. Si el contrato no existe, lo hará no intente actualizar.

(ZosPackageFile) Creado zos.json
Comprobación del estado de implementación de los contratos: 'OceanToken'.
El contrato OceanToken se implementa.
(LocalController) Agregando OceanToken
(ZosPackageFile) Actualizado zos.json
(NetworkAppController) Contrato de validación OceanToken
(NetworkAppController) Carga del contrato de OceanToken como OceanToken
(BaseSimpleProject) Implementación del contrato lógico para OceanToken
Cargando la billetera 'actualizador' en '0xEF2626Fe5810F83f417f4894FE56B52DB4535cdd'
Actualización de contrato: OceanToken con OceanToken
Proxy de actualización: 0xe689a4AC25145e0a8382485a92Fc836C9F045EBF con implementación: 0x21F26270bA7492867605BaB67ce45a561b838743
Envío de la transacción contra el contrato: '0xe689a4AC25145e0a8382485a92Fc836C9F045EBF' a través de '0xEF2626Fe5810F83f417f4894FE56B52DB4535cdd' de la cuenta: '0xFc5B252ec96De8F67A71fdf2AFb6c24
Transacción enviada: '0' de la cuenta: '0xFc5B252ec96De8F67A71fdf2cFB700cAF36246b8'
Contrato actualizado: OceanToken
Actualización del artefacto del contrato: OceanToken con el ABI de OceanToken
Tareas creadas:
{
"OceanToken": 0
}
apruebe en la billetera: '0xEF2626Fe5810F83f417f4894FE56B52DB4535cdd'

En este punto Dori ha creado una nueva transacción (ID 0) en el Billetera Multi Sig Upgrader en la dirección 0xEF2626Fe5810F83f417f4894FE56B52DB4535cdd.

Si ahora abrimos el IU de billetera y cargue la billetera en la dirección dada. Podemos ver que se requieren al menos dos confirmaciones para activar la actualización (ver Fig. 2).

Fig.2: Descripción general de la billetera

Si hacemos clic en el nombre de la billetera y miramos los detalles de la billetera, encontramos la transacción con el ID 0 nuevamente (ver Fig. 3). También ya tiene una confirmación!

Este es ? # 1!

Fig.3: Detalle de billetera

Ahora otro dueño de la billetera puede confirmar esta transacción Una vez que se recopilan suficientes confirmaciones (en este caso 2, como se mencionó anteriormente). los la transacción se ejecutará y la actualización será ser activado (ver Fig. 4).

Este es ? # 2!

Fig. 4: Transacción ejecutada

¡Acabamos de ejecutar un proceso de seguridad de grado militar para actualizar un contrato inteligente!

Contratos de auditoria

Todo lo anterior puede ser rastreado por DoriFuncionalidad de auditoría:

Para hacerlo simplemente haz:

$ npm run audit: desarrollo – OceanToken

La funcionalidad de auditoría cargará las instancias del Carteras Multi Sig otra vez. Serán utilizados para la auditoría.

$ npm run audit: development – OceanTokenUsando el 'desarrollo' de la red. Cargando la billetera 'actualizador' en '0xEF2626Fe5810F83f417f4894FE56B52DB4535cdd'
Cargando la billetera 'propietario' en '0x19c4059daC2c3637Ab601B6dE2Ccd549b43bdC8F'

Luego comprueba si el Monedero del propietario se asigna como propietario correctamente. También verifica las transacciones dentro de la billetera del propietario. No interactuamos con la billetera del propietario en este flujo. Por lo tanto, está vacío.

================================================== ===========
Auditoría de propiedad del contrato
================================================== =========== Propietario Wallet: 0x19c4059daC2c3637Ab601B6dE2Ccd549b43bdC8FOwner del contrato OceanToken, se establece en el propietario wallet en 0x19c4059daC2c3637Ab601B6dE2Ccd549b43bdC8F ======================= ======================================
Auditoría de transacciones de propietarios
================================================== =========== Monedero del propietario: 0x19c4059daC2c3637Ab601B6dE2Ccd549b43bdC8F

Por fin auditará el Actualizar transacciones. Encontramos nuestra transacción con el ID 0 aquí también. Como podemos ver, la transacción ha sido aprobado por dos propietarios y fue ejecutado correctamente. ¡Bien hecho!

================================================== ===========
Auditoría de transacciones de actualización
================================================== =========== Monedero de actualización: 0xEF2626Fe5810F83f417f4894FE56B52DB4535cdd ID de transacción: 0
Destino: 0xe689a4AC25145e0a8382485a92Fc836C9F045EBF
Contrato: OceanToken
Los datos son `upgradeTo` call: true
Confirmado desde: 0xFc5B252ec96De8F67A71fdf2cFB700cAF36246b8, 0x0163715C11edE95e485f52e3d497007ccca66941
Ejecutado: verdadero

A %d blogueros les gusta esto: