Rejoignez-Nous sur

Meilleures pratiques pour améliorer vos contrats Ethereum Smart

1*KXPrZkOvIFNd120SQXG9UA

News

Meilleures pratiques pour améliorer vos contrats Ethereum Smart

Tôt ou tard, la plupart des équipes d’ingénierie rencontreront des problèmes similaires lorsqu’elles tenteront de créer des contrats intelligents complexes et interactifs. À 57Blocks, nous avons construit plusieurs produits pour l’espace cryptographique et nous voulions que nos apprentissages aident l’écosystème à s’épanouir. Ci-dessous, nous décrivons les schémas de programmation des contrats Ethereum smart et les ressources publiques qui nous ont aidés à développer nos produits. Si vous êtes un ancien, notre discussion sur l’application novatrice du modèle de délégué par procuration vous sera peut-être utile.

1. Les motifs

Les modèles sont la conception de l'architecture et les meilleures pratiques de programmation. Comprendre les schémas nous aide non seulement à comprendre comment traiter un problème, mais aussi pourquoi nous devons le faire de manière donnée et à quel problème le schéma est conçu pour traiter. Cela nous aide à mieux comprendre la plateforme sur laquelle nous travaillons.

Les modèles suivants décrits sur https://fravoll.github.io/solidity-patterns/ couvrir la plupart des cas dans le développement quotidien.

Patterns comportementaux

  • Contrôle de garde: Assurez-vous que le comportement d'un contrat intelligent et ses paramètres d'entrée sont conformes aux attentes.
  • Machine d'état: Permet à un contrat de passer par différents états avec différentes fonctionnalités correspondantes exposées.
  • Oracle: Accéder aux données stockées en dehors de la blockchain.
  • Le hasard: Génère un nombre aléatoire d’un intervalle prédéfini dans l’environnement déterministe d’une blockchain.

Modèles de sécurité

Modèles d'évolutivité

  • Délégué par procuration: Introduisez la possibilité de mettre à niveau les contrats intelligents sans casser aucune dépendance.
  • Stockage éternel: Conservez le stockage du contrat après une mise à niveau du contrat intelligent.

Modèles économiques

  • Comparaison de l'égalité des cordes: Vérifiez l’égalité des deux chaînes fournies de manière à minimiser la consommation moyenne de gaz pour un grand nombre d’entrées différentes.
  • Emballage variable serré: Optimiser la consommation de gaz lors du stockage ou du chargement de variables de taille statique.
  • Mémoire Array Building: Regroupez et récupérez les données du stockage contractuel de manière à réduire la consommation de gaz.

Utilisation de délégués proxy pour mettre à jour les contrats intelligents

le Délégué par procuration pattern est conçu pour résoudre le problème de l’extensibilité des contrats intelligents. Cependant, nous avons trouvé une autre utilisation de ce modèle en développant Tokenpad. En utilisant ce modèle, nous avons pu économiser de l’essence lorsque plusieurs copies des mêmes contrats doivent être déployées dans la blockchain.

Tokenpad est une plateforme de syndication des investissements ICO. Les chefs de groupe peuvent créer des pools pour collecter des fonds pour les ICO. Un prospect déploie un contrat intelligent chaque fois qu'il souhaite créer un pool de syndication et le contrat intelligent contient tout le code permettant au pool de fonctionner. Dans la première version de Tokenpad, la création d’un pool coûtait environ 4 millions de gaz, soit 0,02 ETH pour un prix du gaz de 5 gwei. C'est le coût après que nous ayons déplacé tout le code dans les bibliothèques et que le contrat intelligent déployé par le responsable ne fasse que déléguer les appels à la bibliothèque. Il est toujours élevé compte tenu du prix de l'essence pouvant aller jusqu'à 20 gwei, 30 gwei, voire plus.

Avec le modèle Proxy Delegate, nous déployons plutôt une instance unique du contrat intelligent de pool de syndication dans la chaîne de blocs, ainsi que les autres éléments à déployer pour prendre en charge le produit. Lorsqu'un responsable souhaite créer un pool de syndication, nous créons une instance de proxy et la pointons vers la seule instance déjà déployée.

En utilisant le modèle de délégué par procuration, nous avons réduit nos coûts de gaz de plus de 60%, à environ 1,5 million!

La compréhension de ces modèles est un bon point de départ pour développer des contrats intelligents efficaces et sécurisés, mais nous n’avons pas besoin de tout recommencer pour mettre en œuvre tous ces modèles, nous pouvons utiliser des cadres et des bibliothèques pour nous aider à accélérer le développement tout en réduisant les erreurs.

2. Cadres et bibliothèques

Le framework et les bibliothèques sont des implémentations bien testées et réutilisables des patterns connus et des meilleures pratiques. Dans la section, nous présentons quelques cadres et bibliothèques que nous avons utilisés dans notre projet, ainsi que les modèles qu’ils fournissent et les problèmes qu’ils n’ont peut-être pas résolus.

OpenZeppelin

OpenZeppelin est une bibliothèque pour le développement sécurisé de contrats intelligents. Il fournit des implémentations de normes telles que ERC20 et ERC721, que vous pouvez déployer tel quel ou à adapter à vos besoins, ainsi que des composants Solidity pour la création de contrats personnalisés et de systèmes décentralisés plus complexes. Commander la page Github: https://github.com/OpenZeppelin/openzeppelin-solidity

OpenZepplin fournit quelques contrats / bibliothèques qui résolvent des problèmes courants. Voici quelques-unes des fonctionnalités les plus courantes et les plus utiles fournies par la structure utilisée dans notre projet.

math / SafeMath.sol– Protéger des débordements et des débordements. N'utilisez jamais d'opérateurs arithmétiques par défaut. Les opérateurs arithmétiques n'échouent pas en cas de dépassement ou de dépassement, qui peut être exploitable.

propriété / propriétaire– Enregistrez l'adresse du créateur du contrat en tant que propriétaire et vérifiez si une adresse appelante est propriétaire ou non avec le modificateur onlyOwner. La propriété peut être transférée à d'autres adresses. Ceci est une application de la Modèle de restriction d'accès.

La mise en œuvre de Ownable présente un défaut de conception essentiel dont nous devons tenir compte: lorsque nous appelons transferOwnership pour transférer la propriété du contrat à une autre adresse, si cette adresse n'est pas une adresse valide ou une adresse avec une clé privée connue, nous perdons le contrôle. du contrat pour toujours. Une meilleure façon de gérer le transfert de propriété est de ne pas transférer la propriété immédiatement après la fin de la propriété, mais de permettre au propriétaire actuel de rester propriétaire jusqu'à ce que le nouveau propriétaire en revendique le droit de propriété. De cette façon, nous pouvons nous assurer que le contrat est toujours la propriété d'une adresse valide et éviter de transférer le propriétaire à une adresse qui est hors de notre contrôle.

cycle de vie / en pause– Fournit un mécanisme d'arrêt d'urgence. Arrête l'exécution du contrat dans des situations d'urgence afin de réduire les dommages. Ceci est une application de la Modèle d'arrêt d'urgence.

Si nous trouvions un bogue dans le contrat intelligent de production, nous pouvons suspendre ces contrats pour éviter l’exploitation de ce problème critique par une tierce partie avant que nous puissions les résoudre.

accès / rbac / RBAC– Contrôle d'accès basé sur les rôles. Une application du Modèle de restriction d'accès. RBAC est un moyen plus souple de gérer les contrôles d’accès que Ownable. Nous pouvons avoir plusieurs administrateurs, alors que Ownable ne permet qu’à un seul propriétaire d’avoir le contrôle du contrat.

jeton / ERC20– Les fichiers ici fournissent un ensemble de contrats implémentant des fonctionnalités de jeton ERC20 communes. Nous pouvons facilement créer un jeton ERC20 avec ces contrats de base en utilisant plusieurs héritages.

ZOS-LIB

zos-lib fournit une bibliothèque pour développer, déployer et exploiter des contrats intelligents pouvant être mis à niveau sur Ethereum et tous les autres blockchain alimentés par EVM et eWASM. Commander la page github: https://github.com/zeppelinos/zos

Evolutivité / Proxy– Implémentation proxy. Déléguer un appel vers un autre contrat avec un délégation déléguée de bas niveau.

Ce contrat met en œuvre le Modèle de délégué par procuration et résolu un problème critique que le modèle ne résout pas. Dans l'article de modèle de délégué proxy, il existe 2 variables de stockage déclarées dans le contrat de proxy qui peuvent facilement être écrasées par les variables de stockage définies par les contrats appelés à l'aide de delegatecall, ce qui entraîne une corruption des données. Cette implémentation utilise une technique appelée stockage non structuré pour éviter que les variables de stockage aient été écrasées accidentellement.

migrations / initialisable– Fournir l'initialisation en plus du constructeur. Utilisé conjointement avec Proxy pour initialiser le contrat car les constructeurs ne sont pas appelés dans ce cas.

3. Choisir entre les contrats et les bibliothèques

La chaîne de chaînes Ethereum a une limite de gaz en bloc. Si la taille du contrat est trop importante, le gaz requis pour déployer le contrat peut dépasser cette limite, entraînant l’échec du déploiement du contrat. Pour déployer avec succès des contrats volumineux et complexes, nous devons scinder le contrat et le déployer en plusieurs transactions. Il existe 2 façons de scinder le contrat:

Scinder un contrat en plusieurs contrats

Un gros contrat peut être scindé en plusieurs petits contrats. Vous pouvez ensuite passer ces adresses de contrat à un contrat d’appel tertiaire lors du déploiement pour les connecter ensemble.

Avantages:

  • Le contrat peut être assez petit pour être déployé
  • Il est possible de ne mettre à jour qu’une partie du code pour mettre à niveau l’ensemble de l’application ou pour corriger des bogues. Cela se fait en déployant une nouvelle version de l'un des contrats, puis en mettant à jour la référence dans le contrat appelant.

Les inconvénients:

  • L'expéditeur du message sera le contrat appelant et non l'adresse qui initie la transaction, ce qui peut être complexe à gérer

Scinder un contrat en plusieurs bibliothèques

Un contrat volumineux peut être fractionné en plusieurs bibliothèques, puis utiliser un seul contrat pour appeler ces bibliothèques.

Avantages:

  • Les bibliothèques peuvent être aussi petites que possible pour être déployées
  • Les bibliothèques peuvent être facilement réutilisées dans plusieurs contrats et ne doivent être déployées qu'une seule fois.
  • Aucun problème d’expéditeur de message, le code de la bibliothèque est exécuté dans le contexte du contrat.
  • Les bibliothèques peuvent être mises à niveau individuellement

Les inconvénients:

  • Chaque fois qu'une nouvelle version d'une bibliothèque est déployée, toutes les bibliothèques ou tous les contrats qui reposent sur cette bibliothèque devront également être déployés à nouveau, car les bibliothèques sont liées statiquement au moment du déploiement.



Traduction de l’article de Kevin Wang : Article Original

BlockBlog

Le Meilleur de l'Actualité Blockchain Francophone & Internationale | News, Guides, Avis & Tutoriels pour s'informer et démarrer facilement avec Bitcoin, les Crypto-Monnaies et le Blockchain. En Savoir Plus sur L'Équipe BlockBlog

Commenter cet Article

Commenter cet Article

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Plus dans News

Top
dolor mattis eget sed Phasellus ut efficitur. Donec