En novembre 2017, une faille dans le code source de Parity, un des principaux logiciels clients Ethereum, a entraîné la perte d’environ 500 000 ethers, l’équivalent de 355 millions d’euros à date d’écriture de l’article. Afin de résoudre le problème, certains développeurs ont proposé un changement majeur dans le protocole Ethereum : la possibilité de rendre certaines transactions réversibles. Une proposition qui divise la communauté, comme ce fut le cas lors de l’affaire The DAO, survenue en 2016.
Rappel au sujet de l’affaire TheDAO :
Le but de cette organisation autonome décentralisée bâtie sur Ethereum, via un smart contract, était de permettre à ses membres de proposer et financer toutes sortes de projets grâce à un mécanisme de gouvernance original. Le code du smart contract régissant cette organisation étant public, n’importe qui possédant les compétences techniques requises pouvait l’auditer.
Malheureusement, la faille de sécurité présente au niveau de la fonction split du protocole, qui permettait à tout utilisateur de se séparer de ses DAO tokens et de récupérer son investissement en ethers, assorti d’éventuels bénéfices, était beaucoup plus intéressante financièrement à exploiter qu’à signaler; elle permit à un pirate informatique de siphonner une bonne partie des fonds levés par le projet. Le dilemme qui se posa à la communauté fut alors celui-ci : fallait-il permettre aux investisseurs de récupérer leurs fonds dérobés, via la réécriture de la blockchain, ou fallait-il laisser le registre des transactions intact et laisser le hacker disposer des fonds volés ? Ce débat divisa la communauté en deux parties, le camp du laisser-faire et les partisans d’un hard fork. Ceux qui ne souhaitaient pas modifier le protocole de telle sorte à revenir en arrière sur l’état du registre se regroupèrent autour d’Ethereum Classic, qui conserva la blockchain dans son état post-hack; mais la majorité de la communauté opta pour une résolution du problème via le hard fork.
Bien évidemment, une telle décision remit en cause le principe d’immutabilité de la blockchain : il fut tacitement entendu qu’il s’agissait là d’une mesure exceptionnelle à la hauteur des sommes en jeu. Cependant, il fallait observer à juste titre que le fait qu’un petit groupe de développeurs puisse inciter les nœuds du réseau à modifier le registre des transactions posait des problèmes d’équité entre les participants, et soulevait la question du degré de décentralisation de ce réseau de consensus distribué.
De plus, où placer le curseur ? À partir de quelle somme en jeu, à partir de quel degré d’erreur est-il nécessaire d’intervenir de la sorte ? La question se pose à nouveau depuis novembre dernier, lorsqu’une faille dans le smart contract gérant la librairie du logiciel client Parity permit à un développeur amateur de smart contracts de “tuer” accidentellement le contrat correspondant.
Faille de Parity : plus de 500 000 ethers gelés
Le 6 novembre 2017, un développeur débutant sur le réseau Ethereum, sous le pseudonyme de devops199, fit toute une série d’expérimentations pour tenter de devenir propriétaire de plusieurs smart contracts – sans mauvaise intention aucune, d’après ses déclarations. Une fois propriétaire des smart contracts ciblés, il lança plusieurs commandes, dont la fonction “kill”, qui permet de détruire un contrat présent sur la blockchain. Sa manœuvre lui permit de détruire les librairies de code du portefeuille multi-signatures de Parity, gelant 513 774.16 ethers.
“Je pensais que ces commandes allaient échouer, car Parity est une très grosse entreprise, dirigée par de brillants cerveaux”, déclara-t-il tout penaud.
Malheureusement, même après qu’une première faille dans le code de Parity a permis durant l’été 2017 à un hacker de détourner 150 000 ethers, l’équipe n’avait pas corrigé tous les problèmes posés par leur client Ethereum : il était possible de transformer la librairie de Parity (contenant tout le code nécessaire pour communiquer avec les portefeuilles multi-signatures des utilisateurs) en un portefeuille multi-signatures tout simple. Le smart contract régissant cette librairie n’ayant pas été initialisé, devops199 put en devenir le propriétaire via l’appel de la fonction initWallet. Et seul le propriétaire d’un smart contract peut appeler la fonction kill, qui détruit purement et simplement le contrat correspondant. Ainsi, il est désormais impossible pour le smart contract de Parity de communiquer avec les différents portefeuilles multi-signatures concernés (tous les multi-sigs déployés après le 20 juillet) : les ethers correspondants sont ainsi gelés.
Il faut ajouter que le créateur de Parity n’est autre que Gavin Wood, l’un des co-fondateurs du réseau Ethereum. Il est également le créateur de Polkadot, un projet ayant pour ambition de connecter de multiples blockchains entre elles, dont l’ICO permit de lever l’équivalent de $145 millions en ethers, fonds également gelés, à l’instar d’Iconomi (plateforme de gestion d’actifs numériques). Comme on dit de façon vulgaire, ça la fout mal.
Pour réparer de telles erreurs, une amélioration – ou plutôt devrions-nous dire une modification – du protocole Ethereum a été proposée.
Ethereum Improvment Proposal 867 : Standardized Ethereum Recovery Proposal
Le but de l’EIP 867, tel que décrit par Dan Phifer, James Levy et Reuben Youngblom, est d’implémenter une procédure standard permettant à la communauté Ethereum de modifier l’état de la blockchain dans le cas où des fonds sont perdus, à la suite d’une erreur de programmation. Cette procédure est appelée ERP, pour Ethereum Recovery Proposal. La méthode est la suivante :
- Chaque ERP devra suivre certains standards afin de pouvoir être approuvée. Cette sous-classe d’EIP aura pour but de proposer un changement d’état “irrégulier” de la blockchain, afin de recouvrir des fonds qui sont inaccessibles en utilisant le protocole standard.
- Un ensemble d’actions correctives pouvant être interprétées par les logiciels clients Ethereum est proposé au réseau.
- Des directives sont adressées à l’attention des équipes développant les logiciels clients afin que ces actions correctives puissent être lues, interprétées et appliquées à un bloc spécifique. Ces actions seront limitées afin de maximiser le niveau de sécurité.
Structure d’un ERP :
- Préambule : l’en-tête devra contenir des métadonnées au sujet de l’ERP, comme son numéro, un titre décrivant le problème adressé et les vraies identités de chaque auteur.
- Résumé basique : une explication compréhensible de l’ERP.
- Description détaillée : description lisible des actions correctives proposées et des critères utilisés pour déterminer les actions proposées.
- Justification : description concise des raisons pour lesquelles les actions correctives sont à la fois raisonnables et peu susceptibles d’être contestées par une des parties directement concernées.
- Script de vérification : un script lisible par la machine virtuelle générant l’objet du changement d’état. Il doit implémenter clairement la logique de sélection et de génération d’actions décrites dans la description, de façon à ce que les auditeurs puissent générer de nouveau indépendamment un objet de changement d’état identique.
- L’objet du changement d’état : spécifications de l’ensemble des changements d’états proposés.
- Appendice (en option).
Processus d’approbation d’un ERP :
Le délai minimal entre la soumission d’un ERP et son adoption par les logiciels clients devra être de 30 jours. Si l’ERP concerne de nombreuses adresses Ethereum, ce délai devrait être revu à la hausse. Il est nécessaire afin que les auditeurs puissent avoir le temps de réviser le code, de l’annoter, et empêcher toute modification de dernière minute.
Lorsque l’ERP est publié, le processus d’approbation commence. L’auteur est encouragé à recueillir le feedback des parties concernées par le problème à traiter, ainsi que celui de “personnes ou organisations impliquées historiquement dans la communauté Ethereum, non-affectées par le problème, mais pouvant servir d’arbitres impartiaux”.
Les ERP recevant un fort soutien de la part de ces deux groupes ont le plus de chances de réussir. Le premier groupe, bien que non-objectif, doit apporter son soutien pour démontrer que la solution proposée au problème convient à toutes les parties. Le second groupe doit s’assurer que le script proposé est correct et adresse bien le problème considéré, et que les personnes/organisations représentant les parties affectées sont “représentatives”.
L’absence de retours négatifs ne suffit pas pour qu’un ERP soit approuvé : il doit recueillir le soutien explicite des deux groupes sus-cités. Il est de la responsabilité de l’auteur de l’ERP de chercher ce soutien et la communauté doit veiller à ce que le processus soit objectif et opportun.
L’auteur devra demander, lorsqu’il estime que le soutien nécessaire est atteint, une révision de l’ERP par les éditeurs (il s’agit des personnes en charge de la relecture et correction des EIP, voir l’EIP 1) , qui le signaleront “accepté” ou “rejeté”.
Une fois l’ERP marqué comme “accepté”, le bloc auquel le changement sera implémenté sera fixé par la coordination des développeurs des logiciels clients. Une fois ce bloc choisi, il sera publié dans l’ERP et les développeurs des logiciels clients Ethereum implémenteront cette version finale dans leurs applications respectives. Bien évidemment, tout ERP sera en premier lieu déployé sur le réseau de test avant d’être implémenté sur le mainnet.
Le débat quant à l’immutabilité de la blockchain refait surface
Dans la crypto-communauté, deux écoles s’opposent :
- L’école du “Code is Law” : cette expression, le Code fait Loi, signifie que seul le programme informatique, la machine, a la primauté sur l’état du registre. Le code, une fois déployé, ne pourra pas être réinterprété. Si l’être humain, qui est faillible, commet une erreur, il ne doit pas pouvoir revenir en arrière et modifier l’état du registre à son avantage. Il ne doit pas être capable de modifier des transactions a posteriori, ce qui garantit la stricte immutabilité de la blockchain, et place donc le code au-dessus de l’Homme. Cela rend le code très résistant à la corruption mais fragile face à l’erreur.
- L’école du “code au service de l’humain” : l’intention des parties prime sur le texte. Le réseau Ethereum étant en phase de développement et d’expérimentation, et les smart contracts étant difficiles à coder, à auditer et à vérifier formellement, il faut pouvoir pallier aux défaillances des programmeurs si ces derniers commettent des erreurs qui sont dommageables pour les utilisateurs, et donc pour la viabilité de l’écosystème. Le code informatique n’est qu’un processus au service de l’Homme, et ce dernier doit pouvoir en garder le contrôle. Cependant, il est difficile de savoir qui peut prendre la décision de réécrire la blockchain et dans quel cas de figure. C’est un système plus souple, mais qui court le risque d’être biaisé.
Le premier problème posé par l’EIP 867 est évident : cette proposition vise à rendre certaines transactions réversibles, ce qui est à l’opposé du fonctionnement traditionnel d’une blockchain ouverte et résistante à la censure. Cela pourrait poser un énorme problème de confiance envers le réseau Ethereum. Chaque développeur doit veiller à auditer son code; en cas d’erreur, il doit assumer, même si des fonds d’une valeur très importante sont perdus.
Le deuxième problème concerne la vision originelle, libertarienne, des blockchains ouvertes : en théorie, aucun gouvernement ne devrait pouvoir interférer sur leur fonctionnement. Mais s’il devient possible, dans certains cas, de changer l’état de la blockchain à la demande de certaines entités, cela ouvre la porte aux pressions étatiques. Les gouvernements pourraient forcer certains développeurs à modifier l’état du registre, et la propriété essentielle de résistance à la censure ne sera plus assurée.
Cependant, comme dans le cas TheDAO, il y a des arguments en faveur d’offrir la possibilité de réparer des erreurs générées par les nombreux développeurs travaillant sur le réseau Ethereum :
- Le fait qu’une communauté telle qu’Ethereum puisse répondre aux attaques répétées des hackers, protéger la propriété privée et résoudre des erreurs de programmation causant de graves préjudices financiers aux utilisateurs du réseau, grâce à l’ordre spontané, est un message fort, prouvant que ces méthodes nouvelles de gouvernance sont viables et efficaces.
- Si les méthodes employées pour rendre certaines transactions réversibles dans le but de défendre l’intérêt général et consolider la communauté n’engendrent pas d’affaiblissement du niveau de sécurité du réseau (par exemple en n’augmentant pas son niveau de centralisation politique, ce qui est loin d’être prouvé), la notion d’organisation autonome décentralisée prendra du sens et ce sera une démonstration par l’exemple qu’un système auto-adaptatif complexe, composé de millions d’individus ne se faisant pas confiance a priori, peut tout à fait se passer de structures étatiques pour s’organiser brillamment et résoudre avec élégance et flexibilité les litiges et les conflits.
Pour l’instant, la communauté Ethereum s’est engluée dans la controverse et l’EIP 867 n’a pas obtenu le soutien nécessaire à son déploiement; le développeur Yoichi Hirai, bien connu, s’est récemment retiré du cercle des éditeurs, pensant que cette proposition va à l’encontre du droit pénal japonais et de la philosophie d’Ethereum.
Commentaires