Comment définir le contrôle d'accès pour les contrats intelligents

Lorsque l'on cherche à distinguer Web2 et Web3, une valeur clé qui différencie les deux est le concept de propriété.

En termes simples, ce que vous créez est ce que vous possédez et que vous pouvez monétiser. Comme il se doit. Rien de moins, rien de plus. En fait, le jour où vous frappez votre premier NFT, c'est quand vous l'avez fait dans Web3 en tant que propriétaire, grâce à l'immuabilité de la blockchain. Au contraire, le sentiment d'être protégé n'a pas de prix.

En parlant de cela, ce concept de propriété est tout aussi important pour les contrats intelligents en ce qui concerne les fonctions accessibles et le changement d'état autorisé.

Votre premier regard sur la propriété avec les contrats intelligents

Alors, pourquoi est-il important que vous « possédiez » le contrat intelligent que vous avez écrit ?

Pensez-y : si vous possédiez un vélo, hésiteriez-vous à tenir des registres de propriété ? Juste au cas où quelqu'un l'aurait volé et utilisé à des fins néfastes ? Bien sûr que non.

C'est pour la même raison que vous voudriez prouver que vous êtes propriétaire d'un NFT ou d'un contrat intelligent. Eh bien, quelqu'un pourrait simplement obtenir un accès non autorisé et en bénéficier financièrement, n'est-ce pas ?

Disons que vous travaillez avec Dunzo et que vous avez rédigé ce contrat intelligent dans lequel vous pouvez définir le prix du colis plus les frais de livraison, ainsi que s'il a été payé ou non par l'acheteur.

Dans le scénario idéal, vous pouvez définir le nom de l'acheteur, le prix total du colis et de la livraison à un certain montant et définir setPackageDelivered sur true. Une fois que vous avez fini de livrer le colis, bien sûr.

Mais, comme nous le savons tous, rien ne se passe jamais comme prévu.

Maintenant, que se passerait-il si l'acheteur avait accès aux fonctions de contrat et avait la possibilité de réinitialiser la valeur packageDelivered sur false ou de modifier la valeur packageDeliveryPrice en une valeur inférieure ? Non seulement ils peuvent payer moins cher pour le produit, mais ils peuvent s'en tirer sans rien payer du tout.

De toute évidence, à part Dunzo, personne d'autre ne devrait avoir accès pour effectuer de telles modifications, et c'est pourquoi la configuration du contrôle d'accès est importante.

Pourquoi définir le bon contrôle d'accès dans un contrat intelligent est important

Maintenant, déployons ce contrat intelligent et voyons à quel point il est facile pour un intrus de modifier les valeurs des variables d'état.

Avec les fonctions setPrice et setPackageDelivered accessibles, n'importe qui peut apporter des modifications qui peuvent entraîner une perte financière pour la livraison Dunzo.

Si Dunzo avait fixé le prix d'origine de l'article à 5 ETH, le client peut désormais modifier cette valeur à 3 ETH. Bien sûr, puisque le client peut également accéder à la fonction setPackageDelivered et changer la valeur booléenne en false, il peut recevoir une autre livraison du même article. Donc, dans les deux cas, Dunzo risque de perdre de l'argent et pourrait même ne pas s'en rendre compte avant qu'il ne soit trop tard.

Par exemple, disons que le produit livré vaut 5 ETH, comme indiqué ci-dessous :

Lors du déploiement, personne d'autre que Dunzo ne devrait pouvoir modifier les termes du contrat. Pourtant, lorsque nous changeons d'adresse dans Remix et réinitialisons le prix à 3, cela est possible car aucune protection n'est en place.

Nous pouvons même changer le statut setPackageDelivered de true à false. Même si le colis a déjà été livré au client.

Comme vous pouvez le constater, il est important de faire la distinction entre le propriétaire et les autres utilisateurs pour ledit contrat intelligent. Examinons donc 4 correctifs qui définiront le contrôle d'accès approprié pour ce contrat intelligent et assureront ainsi sa sécurité.

4 façons de définir des contrôles d'accès en toute sécurité pour votre contrat intelligent

Alors, comment différencier le propriétaire des autres utilisateurs lors de la rédaction de contrats intelligents ?

De toute évidence, cela est nécessaire en raison de la perte financière qui peut être subie si elle est ignorée.

Méthode #1 : Utiliser une instruction require

Comme vous pouvez le voir dans le code ci-dessous, un nouveau propriétaire de variable d'état de type adresse a été ajouté avec une instruction 'require'. Dans le constructeur, la variable d'état du propriétaire stocke l'adresse utilisée lors du déploiement du contrat. Comme vous le savez, les constructeurs dans les contrats intelligents ne sont invoqués qu'une seule fois, de sorte que l'adresse ne peut pas être modifiée.

Désormais, lorsque vous appelez la fonction setPrice avec une valeur inférieure et une adresse différente, la transaction revient à l'état initial, un peu comme le message ci-dessous :

Comme vous pouvez le voir, la raison fournie par le contrat implique le message d'erreur que nous avons ajouté à l'instruction 'require'. Cela dit, personne d'autre que le propriétaire du contrat - Dunzo, dans ce cas - ne peut modifier les conditions de vente.

Méthode #2 : Utiliser un modificateur de fonction

Aussi simple que d'ajouter une instruction 'require' avec la bonne condition, un modificateur est un bloc de code que vous pouvez utiliser à plusieurs reprises. Cela a certainement beaucoup plus de sens que d'écrire de nombreuses instructions "require" pour une telle vérification.

Dans le code partagé précédemment, seule la fonction setPrice est protégée par une instruction 'require' mais rien n'a été fait pour la fonction setPackageDelivered ici. L'utilisation d'un modificateur devrait faire l'affaire, comme indiqué dans le code Solidity ci-dessous :

Maintenant, si vous essayez d'accéder aux fonctions setPrice ou setPackageDelivered, vous obtiendrez le même message d'erreur obtenu précédemment, et comme indiqué ci-dessous :

Méthode #3 : Propriétaire

Ce correctif nécessite que vous utilisiez le contrat intelligent Ownable fourni par OpenZeppelin. Tout d'abord, vous devez importer le contrat intelligent Ownable, puis ajouter le modificateur onlyOwner aux fonctions que vous souhaitez protéger. Ainsi, comme indiqué ci-dessous, les fonctions setPrice et setPackageDelivered ont le modificateur onlyOwner ci-dessous.

Désormais, étant donné que le contrat intelligent dunzoDelivery utilisera certaines des fonctions d'Ownable.sol, le "is Ownable" est également ajouté au nom du contrat.

Cela dit, il existe deux autres fonctions auxquelles on peut accéder lors de l'utilisation du contrat intelligent Ownable : renounceOwnership et transferOwnership. Bien que le compte utilisé pour déployer le contrat soit généralement considéré comme le propriétaire, cela peut être modifié à l'aide de ces fonctions.

En plus de voir l'adresse du propriétaire et les autres détails de l'accord, vous pouvez voir les fonctions renounceOwnership et transferOwnership à utiliser ci-dessous :

Comme prévu, lorsque vous essayez d'invoquer la fonction setPrice en utilisant une autre adresse, la transaction n'aboutira pas. Au lieu de cela, il revient à l'état d'origine, avec la raison indiquée ci-dessous :

L'utilisation du contrat intelligent Ownable est utile si vous n'avez besoin que d'un seul propriétaire parmi d'autres utilisateurs. Si vous recherchez plus de hiérarchie, le contrat intelligent AccessControl.sol doit être utilisé.

Méthode #4 : Contrôle d'accès

Ce dernier correctif nécessite que vous accédiez au contrat intelligent AccessControl par Open Zeppelin.

Pour commencer, vous devez ajouter le lien hypertexte Access Control à la déclaration d'importation ainsi que "is AccessControl" à la déclaration de contrat.

Comme mentionné précédemment, ce contrat intelligent vous permet d'ajouter un certain nombre de rôles au sein d'une hiérarchie et que vous devez déclarer, comme dans les deux premières lignes du contrat intelligent ci-dessous :

Dans ce contrat, il y a deux rôles à savoir Dunzo et Client. Désormais, lorsque vous déploierez le contrat, vous devrez attribuer les rôles déclarés susmentionnés auxdites adresses, afin de déterminer qui peut accéder à quoi. De plus, deux instructions 'require' ont été ajoutées aux fonctions setPrice et setPackageDelivered.

Comme vous pouvez le constater, seul le compte auquel le rôle Dunzo a été attribué pourra modifier les conditions de vente mentionnées lors du déploiement, mais aucun autre. Cela dit, vous pouvez attribuer un certain nombre de rôles avec différents niveaux d'accès aux fonctions d'un contrat intelligent à l'aide d'AccessControl.sol, tandis que Ownable.sol n'ira pas aussi loin.

Une note sur les autres correctifs de contrôle d'accès pour les contrats intelligents Ethereum

Désormais, ce ne sont pas les seules solutions disponibles pour mettre en œuvre le contrôle d'accès dans les contrats intelligents. RBAC.sol et WhitelistCrowdSale.sol étaient également disponibles dans le passé et peuvent également associer des rôles à des adresses, tout comme AccessControl.sol et Ownable.sol.

Donc, si vous souhaitez acquérir une compréhension approfondie de l'évolution de la mise en œuvre du contrôle d'accès, cela vaudra la peine de passer en revue le code de ces deux contrats intelligents également.

Également publié ici.

L'image principale de cet article a été générée parle générateur d'images AI de HackerNoon via l'invite "accès refusé à l'analyse biométrique".