Journal de développement des smart contracts Rust (9) Mise à niveau du contrat

Les smart contracts sont essentiellement des programmes, et les défauts sont difficiles à éviter. Même les smart contracts ayant subi de nombreux tests et audits peuvent encore présenter des vulnérabilités. Une fois qu'une vulnérabilité de contrat est exploitée par un attaquant, cela peut entraîner des pertes d'actifs pour les utilisateurs, avec des conséquences graves. La correction des vulnérabilités nécessite généralement une mise à niveau du contrat. En plus de corriger les vulnérabilités, l'ajout de nouvelles fonctionnalités nécessite également une mise à niveau du contrat. Par conséquent, la capacité de mise à niveau des contrats est très importante. Cet article présentera les méthodes de mise à niveau des contrats Rust.

1. Méthodes courantes de mise à niveau des contrats Solidity

Les smart contracts d'Ethereum ont une immutabilité, une fois déployés, ils ne peuvent pas être modifiés. S'il y a des vulnérabilités dans le contrat ou si de nouvelles fonctionnalités sont nécessaires, il n'est possible que de déployer un nouveau contrat sur la blockchain.

Le défi auquel cette méthode fait face est qu'à chaque déploiement d'un contrat, une nouvelle adresse est attribuée. Tous les DApp utilisant ce contrat doivent modifier l'adresse du contrat pour s'adapter au nouveau contrat. De plus, l'état du contrat de l'ancienne version doit être migré vers la nouvelle version, et la migration de l'état des contrats complexes est lourde en travail et sujette à des erreurs.

Ainsi, une architecture séparant généralement les données et la logique est adoptée, les données étant conservées dans un contrat d'état ne traitant pas la logique, tandis que toute la logique est mise en œuvre dans un autre contrat logique. Ainsi, lors de la mise à niveau, il suffit de mettre à jour le contrat logique, sans avoir à se soucier de la migration de l'état.

Pour résoudre ce problème, un contrat proxy (Proxy Contract) peut être utilisé. Le contrat proxy est utilisé pour stocker des données et appelle le contrat logique A via deleGatecall, de sorte que les données lues et écrites par le contrat A soient stockées dans le contrat proxy. Lors de la mise à niveau, déployez un nouveau contrat B, puis envoyez une transaction pour faire pointer le contrat proxy vers le nouveau contrat logique B.

2. Méthodes courantes de mise à niveau des contrats NEAR

Prenons l'exemple du projet StatusMessage pour présenter les méthodes courantes de mise à niveau des contrats NEAR.

2.1 La structure de données du contrat n'a pas été modifiée

Si vous ne modifiez que la logique du contrat sans toucher à la structure des données, vous pouvez directement déployer le nouveau code avec near deploy. Les données dans l'ancien contrat peuvent être lues avec succès.

2.2 La structure de données du contrat a été modifiée

Si la structure de données du contrat est modifiée, le redéploiement direct entraînera une incapacité à désérialiser l'état du contrat. Cela est dû au fait que l'état du contrat est stocké de manière persistante sous forme de données sérialisées ; après le redéploiement, la structure de données dans le code a changé, mais l'état est resté le même, et la nouvelle structure de données ne peut pas correspondre à l'ancien état.

2.3 Migrer les smart contracts

NEAR propose la méthode Migrate pour aider à mettre à niveau les contrats. Ajoutez la méthode migrate dans le nouveau contrat :

rouille #[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)((, } }

Appel de la méthode migrate lors de la redéploiement du contrat :

déploiement près
--wasmFile target/wasm32-unknown-unknown/release/status_message.wasm
--initFunction 'migrate' \ --initArgs '{}' \ --accountId statusmessage.blocksec_upgrade.testnet

Cela permet de déployer avec succès un nouveau smart contract et de migrer les anciennes données.

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

3. Considérations de sécurité pour la mise à niveau des contrats

La mise à niveau de la sécurité des contrats doit d'abord prendre en compte le contrôle des permissions. En général, seuls les développeurs ou le DAO peuvent mettre à niveau le contrat. La fonction de mise à niveau doit être une fonction only owner, garantissant qu'elle ne peut être appelée que par le propriétaire.

Il est conseillé de définir le propriétaire du contrat comme un DAO, afin de gérer conjointement le contrat par le biais de propositions et de votes. Un compte personnel en tant que propriétaire entraînerait une forte centralisation du contrat, le propriétaire pouvant modifier librement les données du contrat, et il existe également un risque de perte de clé privée.

De plus, les développeurs peuvent prendre en compte les suggestions suivantes lors de la migration des contrats:

• Ajoutez #[init(ignore_state)] avant la fonction de migration pour vous assurer que l'état n'est pas chargé avant l'exécution de la fonction de migration.
• Supprimez la fonction de migration après la migration, assurez-vous que la fonction de migration n'est appelée qu'une seule fois.
• La nouvelle structure de données est initialisée lors de la migration.