Re: on vit une époque formidable

Un peu plus de détails.

Le contrat qui a été supprimé était le suivant : x863df6bfa4469f3ead0be8f9f2aae51c91a907b4. Tout le code important se trouve dans le contrat WalletLibrary.

On remarque notamment qu'il y a une méthode initMultiOwned, qui prend un tableau de propriétaires initiaux. Cette méthode utilise le modificateur only_uninitialized, pour empêcher de l'appeler plus d'une fois :

modifier only_uninitialized { if (m_numOwners > 0) throw; _; }

Sauf que dans le cas présent initMultiOwned (ou initWallet, qui l'appelle) n'avait jamais été appelé par les dev de Parity. Du coup devops199 l'a appellé, devenant propriétaire du contrat, et l'a détruit.

À ce niveau là c'est même plus une faille de sécu, c'est une porte d'entrée. Commentaire d'un des gars de Parity : ça a été déployé à la rache, on a pas vu.

À noter qu'il existe un mécanisme dans Solidity (le compilateur vers le bytecode Ethereum utilisé) pour empêcher un contrat de disposer d'un espace mémoire (et en faire uniquement une bibliothèque donc). Il aurait fallu le définir ainsi : library WalletLibrary is WalletEvent { ... } au lieu d'utiliser contract.

Pourquoi ça n'a pas été fait ? Bonne question. J'ai l'impression qu'une library ne peut pas déclencher de paiement, alors qu'ici WalletLibrary en fait, mais je ne suis pas sûr de moi.

Et comment on se sort de cette situation ? On ne s'en sort pas. Par définition, la blockchain ne peut pas être altérée. Ou alors il faut faire un nouvel hard fork, ce que certaines personnes semblent réclamer. Mais ça veut dire que le machin n'est quand même pas très stable...

En fait tout cela me fait m'interroger sur le concept même d'Ethereum. La blockchain c'est cool pour enregistrer des données statiques comme des transactions, mais pour du code ? Par son concept même, on en pourra jamais mettre à jour le code. Il faut donc être sacrément sûr de son code pour commencer à l'utiliser, parce qu'on ne pourra alors plus le changer. Et même si on prouve le code à 100%, on n'est pas à l'abri d'une erreur humaine (ici, oublier d'appeler une méthode d'initialisation).

Il y a des idées pour pouvoir mettre à jour du code, à base de proxy où on peut mettre à jour la véritable adresse du code. Mais ça implique soit de faire confiance au gars qui gère le proxy pour ne pas changer l'adresse de la lib n'importe comment, soit que chacun déploie son propre proxy. Et qu'en cas de mise à jour, chacun aille changer l'adresse dans son proxy. Ça peut être géré par le client (comme Parity qui publie déjà des contrats sans qu'on ait besoin d'y comprendre quelque chose) mais ça me semble quand même laborieux.

Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.