Détails sur la visibilité des fonctions et le contrôle des permissions dans la sécurité des smart contracts Rust

robot
Création du résumé en cours

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é :

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 :

  • 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.
  • Récompense
  • Commentaire
  • Partager
Commentaire
0/400
Aucun commentaire
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)