Incidents associés
L'un des objectifs de conception d'Ethereum était de simplifier la spécification de la couche consensus. C'est un objectif noble, car il facilite la réimplémentation de la plate-forme pour différents langages de programmation et contraintes. Mais même si le sous-ensemble minimum d'instructions qui permet aux contrats intelligents complets de Turing est inférieur à 10, Ethereum ne s'est pas limité à un tel jeu d'instructions minimal, pour plusieurs raisons : (a) cela réduit considérablement les performances (b) cela rend le code compilé difficile à Audit. Ethereum a donc environ 100 opcodes différents. Cependant, il semble que par souci de minimisation, l'opcode CALL ait été surchargé de deux fonctions : appeler une méthode d'un autre contrat et envoyer de l'éther. Mais la sémantique de ces deux fonctions et les contextes dans lesquels chacune de ces fonctions est utilisée sont très différents. Ce manque d'éducation a été l'un des facteurs qui a également conduit au piratage DAO. Il est intéressant de noter qu'indirectement, la VM fournit déjà un moyen d'envoyer de l'éther sans appeler aucune fonction, en créant un contrat temporaire et en utilisant l'opcode suicide, mais avec un coût en gaz beaucoup plus élevé. Cette option conduit à la simple conclusion que la VM devrait offrir un opcode SEND qui n'appelle aucun code, réduisant ainsi la complexité des couches supérieures. On peut affirmer que limiter la quantité de gaz offerte pour l'appel à 2300 gaz a pour effet secondaire qu'aucun autre CALL ne peut être effectué, donc c'est sûr. Cet argument est faux si l'on considère que la VM peut ultérieurement subir des hard-forks qui peuvent : réduire le coût d'une opération CALL, ou permettre à des contrats de payer son gaz. Donc, fondamentalement, cette solution est à courte vue, cache le vrai problème à l'utilisateur et empêche les améliorations futures. Chez RSK, nous avons implémenté un simple opcode SEND qui n'appelle aucun code dans le contrat de destination.