Journal de développement de contrats intelligents en Rust (7) Sécurité des contrats : contrôle des permissions

Cet article présentera le contrôle d'accès dans les smart contracts Rust sous deux angles :

1. Visibilité des méthodes de contrat d'accès/appel
2. Contrôle d'accès des fonctions privilégiées / Répartition des responsabilités

1. Visibilité des fonctions de contrat

La configuration de la visibilité des fonctions de contrat est essentielle pour protéger les parties critiques contre les accès ou manipulations accidentels. Prenons l'exemple de l'incident de sécurité de l'échange Bancor Network en juin 2020, où la fonction de transfert clé a été malencontreusement définie comme public, mettant ainsi les actifs des utilisateurs en danger.

Dans les smart contracts Rust, la visibilité des fonctions se divise principalement en plusieurs types :

• pub fn: fonction publique, peut être appelée depuis l'extérieur du contrat
• fn: ne peut être appelé que dans le contrat
• pub(crate) fn: limiter les appels à l'intérieur de crate

Une autre façon de définir la méthode internal est de définir un bloc de code impl Contract indépendant, sans utiliser le modificateur #[near_bindgen].

Pour la fonction de rappel, elle doit être définie comme publique mais s'assurer qu'elle ne peut être appelée que par le contrat lui-même. Vous pouvez utiliser le macro #[private] pour réaliser cette fonctionnalité.

Il faut noter que par défaut, tout est privé dans Rust, à l'exception des éléments dans pub Trait et pub Enum.

2. Contrôle d'accès des fonctions privilégiées

En plus de la visibilité des fonctions, il est nécessaire d'établir un mécanisme de liste blanche de contrôle d'accès complet au niveau sémantique. Similar à la fonction "onlyOwner" dans Solidity, certaines fonctions clés ne peuvent être appelées que par le propriétaire du contrat.

Dans les contrats Rust, il est possible de mettre en œuvre des Trait personnalisés similaires :

rouille pub trait Ownable { fn assert_owner(&self) { assert_eq!(env::predecessor_account_id(), self.get_owner()); } AccountId; fn set_owner(&mut self, owner: AccountId); }

Cela permet de réaliser le contrôle d'accès aux fonctions privilégiées, en veillant à ce que seul le propriétaire du contrat puisse les appeler. Sur la base de ce principe, il est également possible de configurer des listes blanches multi-utilisateurs plus complexes ou plusieurs listes blanches, afin de mettre en œuvre un contrôle d'accès par groupe plus fin.

3. Autres méthodes de contrôle d'accès

Il existe également d'autres méthodes de contrôle d'accès, telles que :

• Contrôle du moment d'appel des contrats
• Mécanisme d'appel multi-signature des fonctions de contrat
• Gouvernance(DAO) de réalisation

Ces contenus seront présentés dans les journaux de culture des smart contracts ultérieurs.