Guide de mise à niveau des smart contracts Rust

Les smart contracts, en tant que type de programme, peuvent inévitablement avoir des défauts. Même après de nombreux tests et audits, des vulnérabilités peuvent encore exister. Si elles sont exploitées par des attaquants, cela peut entraîner une perte d'actifs pour les utilisateurs, avec des conséquences graves. La correction des vulnérabilités nécessite souvent une mise à niveau du contrat. En outre, 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 nécessaire. Cet article présentera les méthodes de mise à niveau des contrats Rust.

Méthodes 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.

1. La structure des données du contrat n'a pas été modifiée

Si vous modifiez uniquement la logique du contrat sans toucher à la structure des données, vous pouvez utiliser directement la commande near deploy pour redéployer le nouveau code. Par exemple, ajouter une nouvelle fonction :

rouille #[near_bindgen] impl StatusMessage { Option { let account_id = env::signer_account_id(); self.records.insert(&account_id, &message); return self.records.get(&account_id); } }

Après redéploiement, les données de l'ancien contrat peuvent toujours être lues avec succès.

( 2. La structure des données de contrat a été modifiée

Si la structure de données d'origine a été modifiée, par exemple :

rouille #[near_bindgen] #[derive)BorshDeserialize, BorshSerialize###] pub struct StatusMessage { taglines: LookupMap<string, string="">, bios: LookupMap<string, string="">, }

Le redéploiement direct entraînera une erreur de désérialisation de l'état du contrat.

( 3. Utiliser la méthode Migrate pour mettre à niveau

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

rouille #) #[init###ignore_state[private]] 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 du déploiement :

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

Cela permettra de mettre à niveau le contrat avec succès et de migrer les anciennes données.

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

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

1. Contrôle des autorisations : la fonction de mise à niveau doit être une fonction only owner, afin de garantir qu'elle ne peut être appelée que par le propriétaire.

2. Il est recommandé de définir le propriétaire du contrat comme DAO, afin de gérer collectivement par le biais de propositions et de votes.

3. Ajoutez #[init)ignore_state)] avant la fonction de migration pour s'assurer que l'état n'est pas chargé avant l'exécution.

4. Supprimez la fonction de migration après la migration, assurez-vous qu'elle n'est appelée qu'une seule fois.

5. La nouvelle structure de données est initialisée lors de la migration.

En suivant les principes ci-dessus, il est possible de mettre à niveau et de maintenir les smart contracts en toute sécurité.

</string,></string,>