Sécurité des smart contracts Rust : explication du contrôle d'accès et de la visibilité des fonctions

robot
Création du résumé en cours

Journal de développement des contrats intelligents Rust (7) Sécurité des contrats : contrôle d'accès

Cet article présentera le contrôle des autorisations dans les contrats intelligents Rust sous deux aspects :

  1. Visibilité des méthodes contractuelles
  2. Contrôle d'accès des fonctions privilèges

1. Visibilité de la fonction de contrat

Il est essentiel de configurer correctement la visibilité des fonctions des contrats pour protéger la sécurité des contrats. Prenons l'exemple de l'incident de la bourse Bancor Network en juin 2020, où la définition erronée de la fonction de transfert clé en tant que publique a mis en péril les actifs des utilisateurs.

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

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

De plus, les méthodes définies dans les blocs impl qui ne sont pas décorés avec #[near_bindgen] sont internes.

Pour les fonctions de rappel, elles doivent être définies comme publiques mais doivent également faire l'objet d'une vérification de l'appelant, ce qui peut être réalisé en utilisant le macro #[private].

Il convient de noter que tout dans Rust est privé par défaut, à l’exception des éléments dans pub trait et pub enum.

2. Contrôle d'accès des fonctions privilèges

En plus de définir la visibilité des fonctions, il est nécessaire de mettre en place un mécanisme de liste blanche de contrôle d'accès. Semblable au modificateur onlyOwner dans Solidity, il est possible de définir des fonctions privilégiées qui ne peuvent être appelées que par le propriétaire.

Dans Rust, cela peut être réalisé en définissant des traits personnalisés:

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 un contrôle d'accès de base pour le propriétaire. Cela peut être étendu à une liste blanche multi-utilisateurs ou à plusieurs listes blanches, permettant un contrôle d'accès plus précis.

!

!

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.
  • Récompense
  • 6
  • Partager
Commentaire
0/400
ser_we_are_ngmivip
· Il y a 2h
C'est difficile à comprendre, je m'en vais.
Voir l'originalRépondre0
NFT_Therapyvip
· 07-17 01:06
Le contrôle d'accès est nécessaire ! Sinon, le contrat pourrait être exploité et ce serait la fin.
Voir l'originalRépondre0
PonziDetectorvip
· 07-17 01:05
Rust yyds le plus dur
Voir l'originalRépondre0
MetaMuskRatvip
· 07-17 01:02
Encore un avec des droits d'administration, je me sauve, je me sauve.
Voir l'originalRépondre0
ser_we_are_earlyvip
· 07-17 00:46
Simple et brutal, c'est juste ajouter un contrôle d'accès.
Voir l'originalRépondre0
MemeEchoervip
· 07-17 00:40
En regardant, on devient fatigué. Est-ce que quelqu'un a vraiment étudié ?
Voir l'originalRépondre0
  • Épingler
Trader les cryptos partout et à tout moment
qrCode
Scan pour télécharger Gate app
Communauté
Français (Afrique)
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)