Diario de desarrollo de contratos inteligentes en Rust (9) Actualización del contrato

Los contratos inteligentes son esencialmente programas, y las fallas son difíciles de evitar. Incluso los contratos inteligentes que han sido sometidos a numerosas pruebas y auditorías pueden tener vulnerabilidades. Una vez que un atacante explota una vulnerabilidad del contrato, puede resultar en la pérdida de activos de los usuarios, con consecuencias graves. La corrección de vulnerabilidades generalmente requiere la actualización del contrato. Además de corregir vulnerabilidades, agregar nuevas funciones también requiere la actualización del contrato. Por lo tanto, la capacidad de actualización del contrato es muy importante. Este artículo presentará las formas de actualización de contratos en Rust.

1. Formas comunes de actualización de contratos Solidity

Los contratos inteligentes de Ethereum tienen inmutabilidad, una vez desplegados no se pueden cambiar. Si hay vulnerabilidades en el contrato o se necesitan nuevas funciones, solo se puede desplegar un nuevo contrato en la blockchain.

El desafío al que se enfrenta este enfoque es que se asigna una nueva dirección cada vez que se despliega un contrato. Todas las DApps que utilizan ese contrato necesitan modificar la dirección del contrato para adaptarse al nuevo contrato. Además, el estado del contrato de la versión anterior debe ser migrado a la nueva versión, y la migración del estado de contratos complejos es laboriosa y propensa a errores.

Por lo tanto, generalmente se utiliza una arquitectura que separa los datos de la lógica, guardando los datos en un contrato de estado que no maneja la lógica, mientras que toda la lógica se implementa en otro contrato lógico. De esta manera, al actualizar, solo es necesario actualizar el contrato lógico, sin necesidad de considerar la migración de estado.

Para resolver este problema, se puede utilizar un contrato proxy (Proxy Contract). El contrato proxy se utiliza para almacenar datos y llama al contrato lógico A mediante deleGatecall, de modo que los datos leídos y escritos por el contrato A se almacenan en el contrato proxy. Al actualizar, se despliega un nuevo contrato B y luego se envía una transacción para que el contrato proxy apunte al nuevo contrato lógico B.

2. Métodos comunes para la actualización de contratos en NEAR

Tomando como ejemplo el proyecto StatusMessage, se presentan los métodos comunes de actualización de contratos NEAR.

2.1 La estructura de datos del contrato no ha sido modificada

Si solo se modifica la lógica del contrato sin involucrar cambios en la estructura de datos, se puede usar directamente near deploy para desplegar el nuevo código. Los datos en el contrato antiguo se pueden leer con éxito.

2.2 La estructura de datos del contrato ha sido modificada

Si se modifica la estructura de datos del contrato, volver a desplegarlo directamente provocará que no se pueda deserializar el estado del contrato. Esto se debe a que el estado del contrato se almacena de forma persistente en forma de datos serializados; después del nuevo despliegue, la estructura de datos en el código ha cambiado, pero el estado no, y la nueva estructura de datos no puede coincidir con el antiguo estado.

2.3 Migrar contratos inteligentes

NEAR proporciona el método Migrate para ayudar a actualizar los contratos. Agrega el método migrate en el nuevo contrato:

óxido #[private] #[init(ignore_state)] Self { let old_state: OldStatusMessage = env::state_read().expect('failed'); Self { taglines: old_state.records, bios: LookupMap::new(b'b'.to_vec)((, } }

Al llamar al método migrate al redeplegar el contrato:

cerca de implementar
--wasmFile target/wasm32-unknown-unknown/release/status_message.wasm
--initFunction 'migrate' \ --initArgs '{}' \ --accountId statusmessage.blocksec_upgrade.testnet

De esta manera, se puede implementar con éxito un nuevo contrato y migrar los datos antiguos.

![])https://img-cdn.gateio.im/webp-social/moments-73f5e5195fa71f1f25f5d35ba1e8b8ec.webp)

3. Consideraciones de seguridad para la actualización de contratos

La actualización de la seguridad del contrato debe considerar primero el control de acceso; generalmente, los contratos solo pueden ser actualizados por el desarrollador o la DAO. La función de actualización debe ser una función only owner, asegurando que solo el owner pueda llamarla.

Se sugiere establecer el owner del contrato como un DAO, para gestionar conjuntamente el contrato a través de propuestas y votaciones. Una cuenta personal como owner llevaría a una alta centralización del contrato, el owner podría modificar los datos del contrato a su antojo, además de existir el riesgo de pérdida de la clave privada.

Además, los desarrolladores al realizar la migración de contratos, pueden considerar las siguientes recomendaciones:

• Añadir #[init(ignore_state)] antes de la función de migración para asegurarse de que no se cargue el estado antes de ejecutar la función de migración.
• Eliminar la función de migración después de que se complete la migración, asegurando que la función de migración solo se llame una vez.
• La nueva estructura de datos se inicializa al completar la migración.