Le contrat intelligent comme menace pour la sécurité du démarrage de la blockchain

Selon le site officiel , les contrats intelligents Ethereum sont exécutés "exactement comme programmé, sans possibilité d'interruption, de censure, de fraude ou d'interférence de tiers". Aujourd'hui, je vais essayer de savoir si tout est si rose en fait, après avoir examiné certains des problèmes auxquels les utilisateurs de contrats intelligents sont confrontés dans la pratique.

À la fin de l'article, je résume mes réflexions avec un bref guide pour la rédaction de contrats intelligents sécurisés.

Remarques

1. Cet article se concentrera uniquement sur les contrats intelligents Ethereum. La communauté a tacitement identifié les contrats intelligents avec les contrats intelligents Ethereum. Pendant ce temps, le premier est plus un concept, et le second est la mise en œuvre, et la question de savoir comment cette mise en œuvre répond au concept peut être discutée (ainsi que le concept de contrats intelligents et d'autres mises en œuvre possibles en principe). Ce sujet est complexe, sous-estimé et intéressant, mais ce n'est pas le sujet de cet article, je vais donc référer ceux qui sont intéressés par les travaux de Nick Szabo . Par conséquent, partout plus loin, où je dis «contrats intelligents», je veux dire en fait «contrats intelligents Ethereum».
2. L'article se concentrera uniquement sur le langage des contrats intelligents Solidity comme le plus populaire et pour l'utilisateur Ethereum en fait le seul pour le moment.

Problèmes de sécurité des contrats intelligents

Il s'agira en fin de compte des problèmes rencontrés par les développeurs de contrats intelligents, et non de la sécurité de la plateforme elle-même (bien qu'un peu à ce sujet). Nous divisons classiquement ces problèmes dans les types suivants:

1. problèmes dans le code de contrat intelligent;
2. problèmes dans le processus de développement;
3. problèmes de langue;
4. problèmes de concept.

1. Problèmes dans le code de contrat intelligent

Par problèmes dans le code d'un contrat intelligent, j'entends ici les problèmes qui sont résolus en modifiant le fichier .sol. C'est notamment:

• Constructions vulnérables connues (par exemple, rentrée ).
  Exemple de vie : rentrée, ou, plus largement, violation du modèle Checks-Effects-Interactions - même des vulnérabilités largement connues (et précédemment exploitées ) continuent d'être trouvées dans les nouveaux contrats.
• Constructions vulnérables de l'auteur (en particulier, erreurs dans la logique du code).
  Exemple de vie : un portefeuille MultiSig qui n'est en fait pas un MultiSig. Pour signer une transaction et transférer des fonds, vous avez besoin du nombre de signatures des propriétaires de portefeuille égal à required . Dans le même temps, pour modifier le required (par exemple, par un, afin de signer vous-même les transactions), seule la signature de l'un des propriétaires suffit:

• Mauvaise architecture.
  Exemple de vie : tentative d'implémentation d'un jeton, d'un portefeuille et d'un magasin de clés dans un même contrat. Le contrat s'avère trop compliqué, le code est difficile à maintenir, à auditer, à modifier. En conséquence, la sécurité en souffre également.
• Code de faible qualité.
  Exemple de vie : contrats avec différents retraits, sauts de ligne et espaces arbitraires. Le code est difficile à lire, ce qui signifie que la sécurité souffre à nouveau. Malgré le fait qu'il existe déjà des linters pour Solidity ( Solium , Solhit ).

Des problèmes dans le code entraînent directement des attaques et des pertes de fonds. La bonne nouvelle est que les problèmes de code peuvent être identifiés pendant le processus d'audit et résolus. Il est important de comprendre d'où ils viennent afin de les éviter à l'avenir. Par conséquent, nous passons au paragraphe suivant.

2. Problèmes dans le processus de développement

Les problèmes dans le code sont principalement dus à un processus de développement mal construit. Il semblerait que le développement de logiciels soit une activité de longue date avec des bonnes pratiques établies. Néanmoins, les jeunes du domaine des contrats intelligents, de l'argent disproportionné et du battage médiatique conduisent au fait que les gens pour une raison ou une autre négligent les procédures standard, ce qui entraîne souvent de graves problèmes. Parmi les plus typiques, il convient de mentionner:

• TK: La plupart des contrats intelligents Ethereum sont rédigés sans tâche technique. À quoi cela peut conduire, à expliquer inutilement.
• Calendrier: en moyenne, très peu de temps est consacré au développement, environ un mois. Un exemple extrême de ma pratique: le client a demandé au développeur de rédiger un contrat intelligent 3 jours avant l'ICO.
• Niveau développeur: beaucoup de gens viennent sur le terrain, y compris sans expérience en programmation.
• Comprendre l'écosystème: et même avec un fond, alors souvent les développeurs ne sont pas profondément plongés dans le sujet et ne comprennent pas les spécificités des contrats intelligents.
• Coût de développement: et pourtant, ceux qui rédigent des contrats intelligents sont peu nombreux; encore moins qui les écrivent bien. D'où le coût déraisonnablement élevé du développement.

3. Problèmes de langue

Ajoute du goudron au langage de Solidity lui-même. Initialement, il a été créé davantage pour être rapidement maîtrisé par un grand nombre de personnes que pour faciliter l'écriture de contrats intelligents sécurisés. Voici quelques-unes de ses fonctionnalités qui interfèrent avec la sécurité:

• Héritage multiple, en using for , call / delegate call - tout cela démarre le code non pas de la source actuelle, ce qui signifie qu'il réduit la lisibilité et, par conséquent, la sécurité du code.
• Modèle de contrôles-effets-interactions - si les constructions qui violent le CEI sont dangereuses, alors pourquoi ne pas les interdire (et bien d'autres) simplement au niveau de la langue?
• En appelant un autre contrat, vous pouvez soudainement tomber dans sa fonction de repli avec des conséquences inattendues.

Il est clair que le projet Ethereum se développe et il est impossible de tout prendre en compte à l'avance. Mais au final, les développeurs sont obligés de se souvenir de nombreuses fonctionnalités et d'utiliser des béquilles pour sécuriser leur contrat intelligent.

4. Problèmes dans le concept

Cependant, le problème le plus grave est encore plus profond: beaucoup ne comprennent pas suffisamment pourquoi les contrats intelligents sont nécessaires, ce qu'ils peuvent, ce qu'ils ne peuvent pas et comment ils fonctionnent. Dans le pire des cas, cela conduit au fait que le contrat intelligent:

1. Pas intelligent:

   
   
   • Mal écrit - fait ce qui est écrit, mais pas ce qui est prévu.
   • Il est fortement lié au backend et / ou au frontend - et ce code n'est plus un contrat intelligent, il est exécuté de la manière habituelle, et son implémentation est complètement contrôlée par l'administrateur du serveur.
   
   

2. Pas un contrat:

   
   
   • Il n'enregistre pas les obligations des parties - par exemple, ICO vend ses jetons pour ETH, mais les jetons sont essentiellement des emballages de bonbons, car n'imposez à celui qui les a libérés, aucune restriction ou obligation.
   • Permet des changements unilatéraux - et il s'avère que l'une des parties peut modifier le contrat après sa signature.
     
     Exemple de vie : le propriétaire du contrat peut modifier arbitrairement la capitalisation, le taux et la durée de la vente de jetons:
     
     
   
   

3. Pas nécessaire:

   
   
   • Le contrat intelligent a été ajouté non pas parce qu'il était techniquement nécessaire, mais en essayant de comprendre quoi faire sur les contrats intelligents et de surfer sur une vague de battage publicitaire;
   • Nous avons essayé de comprendre comment lier des contrats intelligents à un produit existant.
     
     
   
   

Le contrat intelligent comme menace pour la sécurité du démarrage de la blockchain

Quel est le résultat? Ils voulaient que ce soit à la mode, sûr, blockchain, mais nous obtenons un code non pris en charge coûteux qui menace la sécurité et qui n'est pas du tout nécessaire. Nous voulions que nos contrats intelligents soient exécutés «exactement comme programmés, sans possibilité d'interruption, de censure, de fraude ou d'intervention de tiers», et finalement ils sont vraiment exécutés tels qu'ils sont écrits - ils ne sont écrits qu'avec vulnérabilité. Et il ne nous reste plus qu'à agiter une plume à nos moyens. Eh bien, ou pour faire un hard fork (discréditant ainsi l'idée originale elle-même) si les créateurs d'Ethereum ont perdu de l'argent en raison de la vulnérabilité.

Comment rédiger des contrats intelligents sécurisés

En fait, bien sûr, tout n'est pas si mal. J'exagère simplement pour essayer d'attirer l'attention sur certains points importants, à mon avis. En général, le domaine se développe, les gens apprennent, y compris la sécurité.

Si le lecteur décide de rédiger un contrat intelligent, je conseillerais:

• comprendre pourquoi un contrat intelligent est nécessaire (et s'il est nécessaire);
• recevoir du client ou écrire TK;
• calculer le temps;
• utiliser des outils de développement et de test ( Truffle , Remix , SmartCheck , Solhint ou Solium linter );
• écrire des tests;
• effectuer plusieurs audits indépendants et des primes de bogues;
• surveiller la sécurité des autres composantes du projet (site Web, Twitter, etc.).

En suivant ces recommandations simples, vous pouvez éviter la plupart des problèmes décrits ci-dessus (à partir d'un hard fork, cependant, cela ne sera toujours pas enregistré).

L'article a été créé en collaboration avec Eugene Marchenko ( eMarchenko ).