Cet article explorera la question du contrôle d'accès dans les smart contracts Rust sous deux aspects : la visibilité des méthodes de contrat et le contrôle d'accès aux fonctions privilégiées.
1. Visibilité des fonctions de contrat
Lors de la rédaction de smart contracts, en spécifiant la visibilité des fonctions, on peut contrôler qui peut appeler des fonctions spécifiques, protégeant ainsi les parties clés du contrat.
Prenons l'exemple d'un incident de sécurité survenu dans un échange le 18 juin 2020. En raison d'une mauvaise configuration des droits d'accès aux fonctions clés du contrat, les actifs des utilisateurs étaient en danger. Cet exemple souligne l'importance de bien définir la visibilité des fonctions des smart contracts.
Dans les smart contracts Rust, la visibilité des fonctions se divise principalement en plusieurs types :
pub fn : indique que cette méthode est publique, fait partie de l'interface du contrat et peut être appelée de l'extérieur par n'importe qui.
fn: Si pub n'est pas explicitement indiqué, cela signifie que cette fonction ne peut être appelée que par d'autres fonctions à l'intérieur du contrat.
pub(crate) fn: restreindre l'appel de la méthode à l'intérieur de la portée du crate.
Une autre façon de définir la méthode comme interne est de le faire dans un bloc de code impl Contract qui n'est pas annoté par #[near_bindgen].
Pour les fonctions de rappel, elles doivent être définies comme des propriétés publiques pour pouvoir être appelées par une fonction. De plus, il est nécessaire de s'assurer que la fonction de rappel ne peut pas être appelée à volonté, ce qui peut être réalisé en utilisant le macro #[private].
Il est important de noter que, par défaut, tout dans Rust est privé, à l'exception des sous-projets dans pub Trait et des variables dans pub Enum qui sont par défaut publiques.
2. Contrôle d'accès des fonctions privilégiées
En plus de la visibilité des fonctions, il est également nécessaire d'établir un mécanisme complet de liste blanche de contrôle d'accès au niveau sémantique. Certaines fonctions privilégiées (comme l'initialisation du contrat, l'activation/désactivation, etc.) ne peuvent être appelées que par le propriétaire du contrat.
Dans les smart contracts Rust, il est possible d'implémenter une fonctionnalité similaire au modificateur onlyOwner dans Solidity :
Cette méthode permet de réaliser un contrôle d'accès sur les fonctions privilégiées, garantissant que seuls les propriétaires de contrats peuvent exécuter complètement ces fonctions. Sur la base de ce principe, il est possible de mettre en place un mécanisme de liste blanche plus complexe pour réaliser un contrôle d'accès par groupes plus précis.
3. Autres méthodes de contrôle d'accès
En plus des méthodes mentionnées ci-dessus, il existe d'autres moyens de contrôle d'accès dans les smart contracts Rust, tels que le contrôle du moment des appels de contrat, le mécanisme d'appel multi-signatures et la mise en œuvre de la gouvernance (DAO), etc. Ces sujets seront abordés en détail dans de futurs articles.
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.
10 J'aime
Récompense
10
4
Partager
Commentaire
0/400
ProxyCollector
· Il y a 44m
Encore un piège de réglage des autorisations, ceux qui tombent dedans sont malchanceux.
Voir l'originalRépondre0
SelfRugger
· Il y a 13h
Encore un problème de permission qui m'ennuie.
Voir l'originalRépondre0
AllTalkLongTrader
· Il y a 13h
Hé hé, je revois ce trou de l'année dernière sur la plateforme d'échange.
Voir l'originalRépondre0
PermabullPete
· Il y a 14h
Les permissions n'ont pas été contrôlées, j'ai failli être à l'arrêt.
Contrôle d'accès des smart contracts Rust : visibilité des fonctions et pratiques d'accès privilégié
Contrôle d'accès dans les smart contracts Rust
Cet article explorera la question du contrôle d'accès dans les smart contracts Rust sous deux aspects : la visibilité des méthodes de contrat et le contrôle d'accès aux fonctions privilégiées.
1. Visibilité des fonctions de contrat
Lors de la rédaction de smart contracts, en spécifiant la visibilité des fonctions, on peut contrôler qui peut appeler des fonctions spécifiques, protégeant ainsi les parties clés du contrat.
Prenons l'exemple d'un incident de sécurité survenu dans un échange le 18 juin 2020. En raison d'une mauvaise configuration des droits d'accès aux fonctions clés du contrat, les actifs des utilisateurs étaient en danger. Cet exemple souligne l'importance de bien définir la visibilité des fonctions des smart contracts.
Dans les smart contracts Rust, la visibilité des fonctions se divise principalement en plusieurs types :
Une autre façon de définir la méthode comme interne est de le faire dans un bloc de code impl Contract qui n'est pas annoté par #[near_bindgen].
Pour les fonctions de rappel, elles doivent être définies comme des propriétés publiques pour pouvoir être appelées par une fonction. De plus, il est nécessaire de s'assurer que la fonction de rappel ne peut pas être appelée à volonté, ce qui peut être réalisé en utilisant le macro #[private].
Il est important de noter que, par défaut, tout dans Rust est privé, à l'exception des sous-projets dans pub Trait et des variables dans pub Enum qui sont par défaut publiques.
2. Contrôle d'accès des fonctions privilégiées
En plus de la visibilité des fonctions, il est également nécessaire d'établir un mécanisme complet de liste blanche de contrôle d'accès au niveau sémantique. Certaines fonctions privilégiées (comme l'initialisation du contrat, l'activation/désactivation, etc.) ne peuvent être appelées que par le propriétaire du contrat.
Dans les smart contracts Rust, il est possible d'implémenter une fonctionnalité similaire au modificateur onlyOwner dans Solidity :
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); }
Cette méthode permet de réaliser un contrôle d'accès sur les fonctions privilégiées, garantissant que seuls les propriétaires de contrats peuvent exécuter complètement ces fonctions. Sur la base de ce principe, il est possible de mettre en place un mécanisme de liste blanche plus complexe pour réaliser un contrôle d'accès par groupes plus précis.
3. Autres méthodes de contrôle d'accès
En plus des méthodes mentionnées ci-dessus, il existe d'autres moyens de contrôle d'accès dans les smart contracts Rust, tels que le contrôle du moment des appels de contrat, le mécanisme d'appel multi-signatures et la mise en œuvre de la gouvernance (DAO), etc. Ces sujets seront abordés en détail dans de futurs articles.