Décryptage : des wallets gelés sur Ethereum (Obviously, winter is coming …) #Parity #Multisig

Après The DAO qui a provoqué un fork, une deuxième erreur sur des smart-contracts fait trembler l’écosystème Ethereum. Un nouveau fork à prévoir ? Que faut-il conclure de tout cela ?

Une affaire de multisig

Sur Ethereum il existe des wallets “multisig” qui se présentent sous la forme de smart-contracts créés par ParityTech.io.

Un wallet multisig est un smart-contract qui permet de déboucler des transferts de tokens sous la condition que plusieurs parties prenantes signent la transaction. Nous pourrions entre autres le voir comme une solution de séquestre.

En raison de leurs fonctionnalités, les wallets multisig sont très utilisés dans le monde des ICO. C’est par exemple le cas dans l’ICO de Polkadot, qui s’élève à 92.000.000 de dollars. C’est pourquoi, en règle générale, un wallet multisig est plutôt bien fourni.

Cependant, il s’agit maintenant de la deuxième fois cette année que ParityTech publie sur son blog un billet de “Critical Security Alert”.

Le premier, le 17 juillet 2017 concernait une erreur de conception dans le smart-contract qui pouvait mener à la perte de tous les tokens stockés dans un wallet multisig. ParityTech était alors censé avoir fait les modifications nécessaires pour régler ce problème. Sauf que … le 7 novembre 2017, un utilisateur aurait découvert un bug qui cette fois-ci gèle tous les tokens se trouvant dans un smart-contract multisig. Ironie du sort, ce bug serait issu de la correction du bug du 17 juillet.

A partir de là, plusieurs questions se posent :

Qui est responsable de la situation ?

D’un point de vu légal la responsabilité de l’éditeur (ParityTech) n’est pas engagée en raison de la license GPL utilisée sur leur solution.

Ce programme est distribué dans l’espoir qu’il sera utile, mais SANS AUCUNE GARANTIE : sans même la garantie implicite de COMMERCIALISABILITÉ 16 ni d’ADÉQUATION À UN OBJECTIF PARTICULIER

(extrait issu de la licence GPL)

D’un point de vue plus pramatique, la responsabilité est portée autant par ParityTech que par les usagers. ParityTech reste l’expert sur la technologie Solidity et Ethereum. Il propose des solutions logicielles, nous pourrions remettre en question la qualité de l’organisation mise en place pour assurer la qualité du code. L’usager, lui, doit utiliser la technologie Ethereum en connaissance de cause : il s’agit d’une technologie encore en version instable et avec pour véritable point faible, les smart contracts. Il doit anticiper ce genre de situation. Les responsabilités sont donc partagées.

Cela remet-il en question la technologie blockchain et la cryptomonnaie ?

La réponse est évidente : non, mais cet incident n’aide pas à sa démocratisation. La technologie blockchain ne se limite pas au protocole Ethereum, ni même aux blockchains publiques. Sur Bitcoin, les bugs de cette envergure sont moins présents (cependant Bitcoin ne présente pas la fonctionnalité de smart contracts, simplement de scripts basiques). Les blockchains permissionnées seraient moins sujettes à ce genre de problématiques, étant données qu’il s’agit plutôt de blockchains avec une certaine confiance “sociale” : un consortium est établi entre des partis prenantes qui ont des intérêts communs et n’ont aucun intérêt à être malveillantes.

Par contre il reste évident qu’Ethereum va être mené à mal pendant un petit moment et que son cours va chuter durant un certain temps. A voir si ce problème va être résolu avec un hardfork ou bien grâce à la prochaine implémentation de Constantinople avec l’EIP156

Comment éviter ce genre de problème à nouveau ?

Tout réside dans la qualité du smartcontract : il est nécessaire de proposer des processus de rédaction et de révision du code plus rigoureux avant mise en production. Solidity n’est pas capable de réaliser des preuves formelles mais en utilisant des solutions comme celles décrites dans ce billet : le risque sera plus limité.