Journal de développement de smart contracts Rust (7) Sécurité des contrats : précision des calculs
Cet article présentera le contrôle des accès dans les smart contracts Rust sous deux angles :
Visibilité des méthodes d'accès/appel des contrats
Contrôle d'accès des fonctions privilégiées / Répartition des responsabilités
1. Visibilité des fonctions de contrat
Le contrôle de la visibilité des fonctions de contrat est essentiel pour protéger les parties critiques contre les erreurs d'opération. Prenons l'exemple de l'incident de sécurité de l'échange Bancor Network du 18 juin 2020, où le fait de définir par erreur une fonction de transfert clé comme publique a mis en péril les actifs de 590 000 dollars des utilisateurs.
Dans les smart contracts Rust, la visibilité des fonctions est principalement :
pub fn: fonction publique, peut être appelée depuis l'extérieur du contrat
fn: par défaut privé, ne peut être appelé que depuis l'intérieur du contrat
pub(crate) fn: limiter l'appel à l'intérieur de crate
Une autre façon de définir la méthode interne est de définir un bloc de code impl Contract indépendant, sans ajouter le modificateur #[near_bindgen].
Pour les fonctions de rappel, elles doivent être définies comme publiques mais doivent être limitées à des appels uniquement par le contrat lui-même. Vous pouvez utiliser le macro #[private] pour cela.
Rust par défaut rend tout privé, sauf les é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 complet de liste blanche de contrôle d'accès au niveau sémantique. Comme dans les contrats Ownable de Solidity, certaines fonctions privilégiées ne peuvent être appelées que par le propriétaire.
Dans un contrat Rust, il est possible de mettre en œuvre un Trait personnalisé :
Cela permet de contrôler l'accès aux fonctions privilégiées. Sur cette base, il est également possible de définir des listes blanches multi-utilisateurs ou plusieurs groupes de listes blanches.
3. Méthodes de contrôle d'accès supplémentaires
D'autres méthodes de contrôle d'accès incluent :
Contrôle du moment d'appel des smart contracts
Mécanisme d'appel multisignature des fonctions de contrat
Mise en œuvre de la gouvernance DAO
Ces contenus seront détaillés dans les articles suivants.
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Détails sur la visibilité des fonctions et le contrôle des permissions dans la sécurité des smart contracts Rust
Journal de développement de smart contracts Rust (7) Sécurité des contrats : précision des calculs
Cet article présentera le contrôle des accès dans les smart contracts Rust sous deux angles :
1. Visibilité des fonctions de contrat
Le contrôle de la visibilité des fonctions de contrat est essentiel pour protéger les parties critiques contre les erreurs d'opération. Prenons l'exemple de l'incident de sécurité de l'échange Bancor Network du 18 juin 2020, où le fait de définir par erreur une fonction de transfert clé comme publique a mis en péril les actifs de 590 000 dollars des utilisateurs.
Dans les smart contracts Rust, la visibilité des fonctions est principalement :
Une autre façon de définir la méthode interne est de définir un bloc de code impl Contract indépendant, sans ajouter le modificateur #[near_bindgen].
Pour les fonctions de rappel, elles doivent être définies comme publiques mais doivent être limitées à des appels uniquement par le contrat lui-même. Vous pouvez utiliser le macro #[private] pour cela.
Rust par défaut rend tout privé, sauf les é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 complet de liste blanche de contrôle d'accès au niveau sémantique. Comme dans les contrats Ownable de Solidity, certaines fonctions privilégiées ne peuvent être appelées que par le propriétaire.
Dans un contrat Rust, il est possible de mettre en œuvre un Trait personnalisé :
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 contrôler l'accès aux fonctions privilégiées. Sur cette base, il est également possible de définir des listes blanches multi-utilisateurs ou plusieurs groupes de listes blanches.
3. Méthodes de contrôle d'accès supplémentaires
D'autres méthodes de contrôle d'accès incluent :
Ces contenus seront détaillés dans les articles suivants.