Detalles del plan de actualización de contratos inteligentes Rust

Los contratos inteligentes son esencialmente programas, y no están exentos de defectos. A pesar de las numerosas pruebas y auditorías, pueden surgir vulnerabilidades. Una vez que son explotadas por un atacante, pueden causar pérdidas de activos a los usuarios, lo que puede tener consecuencias graves. Por lo tanto, la capacidad de actualización de los contratos es muy necesaria, principalmente para la corrección de vulnerabilidades y la adición de nuevas características. Este artículo presentará los métodos comunes de actualización de contratos en Rust.

Plan de actualización de contratos de Ethereum

Los contratos inteligentes de Ethereum tienen inmutabilidad y no se pueden modificar una vez desplegados. Para solucionar vulnerabilidades o agregar nuevas funciones, la práctica común es volver a desplegar un nuevo contrato. Sin embargo, esto provoca un cambio en la dirección del contrato, lo que requiere modificar todas las DApps que utilizan ese contrato. Además, también es necesario migrar los datos de estado del contrato antiguo, lo que implica un gran esfuerzo y es propenso a errores.

Para ello, se suele utilizar una arquitectura que separa los datos de la lógica: los datos se almacenan en contratos inteligentes, y toda la lógica se implementa en otro contrato lógico. Al actualizar, solo es necesario actualizar el contrato lógico, sin necesidad de migrar los datos de estado.

En la implementación específica, se puede utilizar el contrato proxy (Proxy Contract). El contrato proxy almacena datos y llama al contrato lógico A a través de deleGatecall. Durante la actualización, solo es necesario desplegar un nuevo contrato lógico B y luego hacer que el contrato proxy apunte a B.

Plan de actualización de contratos inteligentes de NEAR

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

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 near deploy para redeplegar el nuevo código. Los datos originales aún se pueden acceder normalmente.

la estructura de datos del contrato ha sido modificada

Si se modifica la estructura de datos del contrato, volver a desplegarlo directamente provocará que la nueva y la antigua estructura de datos no coincidan, lo que impedirá el acceso normal a los datos.

utiliza el método Migrate para actualizar

NEAR proporciona el método Migrate para ayudar a actualizar contratos. Agregue 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)((, } }

Llamar al método migrate al desplegar:

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

De esta manera, se puede migrar con éxito los datos de contratos antiguos a la nueva estructura.

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

Consideraciones de seguridad para la actualización de contratos

1. Control de permisos: la función de actualización debe ser una función only owner, que solo puede ser llamada por el owner.

2. Se recomienda establecer el owner como DAO, gestionando el contrato a través de propuestas y votaciones.

3. Agregar #[init(ignore_state)] antes de la función de migración, asegurando que no se cargue el estado antes de la ejecución.

4. Eliminar la función de migración después de que se complete la migración, asegurándose de que solo se llame una vez.

5. La nueva estructura de datos se inicializa durante la migración.

El uso razonable de estas propuestas de actualización puede permitir una actualización y mantenimiento flexibles de los contratos inteligentes, garantizando al mismo tiempo la seguridad.