Une Fork nommée Byzance, puis Constantinople et enfin Metropolis

Affiche publicitaire pour le film Metropolis (1927) de Fritz Lang

La Fondation Ethereum poursuit la feuille de route de développement d’Ethereum initialement établie lors du crowdfunding de 2014, à savoir un déploiement en plusieurs phases des différentes fonctionnalités du protocole. Ces phases sont appelées Frontier (l’alpha), Homestead (première version en production, c’est la version actuelle d’Ethereum), Metropolis (prochaine mise à jour majeure avec de nombreuses améliorations – pour la plupart invisibles à l’utilisateur) et enfin Serenity (implémentation de la preuve d’enjeu et de la fragmentation / sharding).

Comme souvent en matière de développement de projet innovant, les dates prévues pour le déploiement de ces étapes, mais aussi l’étendue exacte des fonctionnalités, ont largement évolué pendant la vie du projet. Depuis le déploiement de Homestead en mars 2016, le petit monde au courant du développement du protocole Ethereum attendait avec impatience le déploiement de Metropolis.

Las, les différents événements ayant émaillé la vie de la blockchain Ethereum fin 2016 – The DAO, le hack, le fork, les attaques DoS, les autres forks – ont largement perturbé le travail de l’équipe de développement, occupée à éteindre des incendies plus pressants. Ces imprévus, couplés aux habituels retards, découvertes, idées nouvelles, ont conduit à un large report de la date de lancement de Metropolis. Cette étape doit correspondre au lancement « grand public » du réseau avec tous les outils permettant d’utiliser facilement des dApps et d’en voir les avantages.

Depuis début juillet le développement d’Ethereum a connu une activité particulièrement intense en vue de la sortie de Metropolis. La Fondation a annoncé le 23 août dernier que le lancement de Métropolis était proche et que plusieurs fonctionnalités étaient déjà prêtes. En conséquence, Métropolis sera implémentée en deux fois avec une première hardfork nommée Byzantium et une seconde nommée Constantinople. Un choix de nom qui se veut un clin d’œil aux noms successifs d’Istanbul, l’une des plus grandes mégalopoles du continent européen. Deux dates sont envisagées pour l’avènement de Byzantium, au meilleur cas la fork aura lieu 22 Septembre au bloc 4 300 000 et au plus tard le 27 octobre au bloc 4 400 000.

Byzantium: est-ce le grand luxe?

Avec Byzantium ce n’est pas moins de 10 Ethereum Improvement Proposals (EIPs):

• 100 Change difficulty adjustment to target mean block time including uncles
• 140 REVERT instruction in the Ethereum Virtual Machine
• 196 Precompiled contracts for addition and scalar multiplication
• 197 Precompiled contracts for optimal Ate pairing check on the elliptic curve
• 198 Precompiled contract for bigint modular exponentiation
• 211 New opcodes: RETURNDATASIZE and RETURNDATACOPY
• 214 New opcode STATICCAL
• 649 Metropolis Difficulty Bomb Delay and Issuance Reduction
• 658 Embedding transaction return data in receipts
• 684  Prevent overwriting contracts #684

Byzantium apporte 3 évolutions majeures qui concernent l’anonymat (196, 197 et 198), la prévisibilité du Gas (140 et 211), la sécurité (190 et 214).

• La Chasse au Snark, les EIP 196, 197 et 198

Illustration du poème de Lewis Caroll “La Chasse au Snark” par Henry Holiday – La Leçon du Castor:“It felt that, in spite of all possible pains,// It had somehow contrived to lose count,// And the only thing now was to rack its poor brains// By reckoning up the amount.” “Il comprit qu’en dépit de ses vaillants efforts,// Il n’avait réussi qu’à embrouiller son compte,// Et qu’il allait falloir se creuser la cervelle// Pour, de tête, reconstituer le total.” *Traduction d’Henri Parisot.

Les zk-SNARKs (zero-knowledge Succinct Non-interactive ARgument of Knowledge) sont des outils cryptographiques utilisés sur la blockchain Zcash. Ce sont des preuves qu’un calcul a été effectué à partir d’un ensemble de paramètres sans révéler tous ces paramètres. Le créateur de Solidity Christian Reintwiessner résume les zk-SNARKs de la façon suivante:

“Ils permettent de vérifier l’intégrité des calculs sans avoir à les exécuter et sans avoir à regarder ce qui a été exécuté, ils n’apportent qu’une preuve que ce qui a été exécuté l’a été correctement.”

Il est possible d’utiliser ces preuves pour vérifier la validité d’une transaction dans une blockchain tout en protégeant l’anonymat des utilisateurs concernés par cette transaction. L’aspect succinct des zk-SNARKs trouve aussi des applications dans la réduction des coûts de vérification de l’exécution de smart-contracts complexes. Une garantie de l’intégrité du calcul est ainsi apportée sans surcharger la chaîne. Un travail conjoint des développeurs de Zcash et d’Ethereum a été consacré à porter ces outils dans Ethereum. Pour plus d’information, voir les 3 articles de Vitalik Buterin à ce sujet.

• Réajustement de la difficulté EIP 190

L’ajustement de la difficulté entre les blocs change afin de viser un rythme de création des blocs constants incluant les oncles (en anglais uncles ou ommen). Auparavant, une manipulation du rythme des oncles permettait d’augmenter artificiellement la difficulté.

• Nouvelle instruction pour l’Ethereum Virtual Machine (EVM): REVERT, EIP 140 (et 658)

Une interview du Dr. Greg Colvin sur l’EVM

Cette instruction (ou OPCODE) est en préparation depuis 1 an, il s’agit d’une instruction qui provoque une exception et stoppe l’exécution en cours sans consommer de gaz. Jusqu’à présent, lorsque l’on souhaite prévoir l’arrêt d’une exécution (par exemple lorsqu’une condition n’est pas remplie), la seule façon de procéder est de faire expirer la réserve de gaz d’une transaction. Une fois son gaz consommé une telle transaction est dite “out of gas”, l’état de l’EVM reste inchangé et les mineurs récupèrent les frais associés au traitement de cette transaction sans effet.

Cette façon de faire présente l’inconvénient majeur de faire occuper beaucoup de place dans les blocs à des transactions “invalidées”. Pour rappel un bloc sur ethereum a une taille définie par sa limite en gaz. En période de forte affluence sur le réseau, lors d’une ICO par exemple, de nombreuses transactions sont ainsi invalidées et saturent les blocs. Pour illustrer cette situation, durant l’ICO d’AdToken cette transaction est arrivée 2 blocs après l’ouverture, soit 2 blocs trop tard. Quelques centaines de blocs qui suivent le bloc #3933451 sont saturés. Notez au passage que les mineurs sont incités à traiter ces transactions invalides puisqu’ils récupèrent beaucoup d’éthers en frais de transaction. Grâce à REVERT il sera donc possible de prévoir dans son code cette exception pour permettre que sous certaines conditions l’exécution demandée s’arrête tout simplement sans que trop de gaz ne soit consommé.

En complément à REVERT, l’EIP 658 modifie le contenu du reçu des transactions (receipt) pour refléter le fait qu’avec REVERT il n’est plus clairement possible d’identifier à partir de la transaction traitée si son effet a modifié ou non l’état de la blockchain. En conséquence le champ actuellement obsolète “intermediate state root” du reçu sera remplacé par un statut 1 (succès) ou 0 (échec).

• Nouvelles instructions pour l’EVM: RETURNDATASIZE et RETURNDATACOPY, EIP 211 (et  206)

L’objectif de ces instructions est de permettre de manipuler des données de tailles arbitraires dans l’EVM. En effet, dans certaines situations, la taille des données que retourne une fonction ne peut pas être anticipée alors que l’EVM a besoin de prévoir la taille pour lui allouer la mémoire nécessaire avant de la manipuler. En pratique cela est d’ores et déjà possible en procédant en deux appels, le premier déterminant la taille et le second allouant la mémoire, ce qui est parfois très coûteux en gaz. Cette méthode sera donc possible en passant d’abord par RETURNDATASIZE puis RETURNDATACOPY. Le tout se comporte de façon similaire à CALLDATA, mettant le résultat dans un buffer avant de le copier.

• Nouvelle instruction STATICCALL EIP 214

Cette nouvelle instruction garantie qu’aucun modification de l’état n’aura lieu lors de l’appel d’un contrat vers un autre contrat. Cela permet notamment de se prémunir d’autant mieux contre le bug de “reentrancy” (exploité lors du hack de TheDAO).

• Retardement de la bombe de difficulté et réduction du rythme d’émission des éthers EIP 649

Sans aucun doute la discussion la plus controversée, cette EIP a généré un long débat plus ou moins technique et plus ou moins économique qu’il serait difficile de résumer. Le temps entre chaque bloc croit actuellement du fait de la bombe de difficulté, celle-ci augmente plus que la capacité de minage du réseau. Cette bombe diminue donc progressivement la capacité  d’Ethereum à traiter les transactions et devait inciter le réseau à passer en preuve d’enjeu (Proof of Stake).

Il faut avoir à l’esprit qu’un rythme moins soutenu de création de blocs a aussi pour conséquence une émission ralentie de nouveaux éthers. Dès lors il devient de moins en moins rentable de miner à valorisation de l’éther constant.

Cette EIP prévoit un recul de la bombe de difficulté de 16 à 17 mois pour retourner à un temps moyen entre les blocs de 14,4 secondes. De plus, afin de refléter la moindre émission de nouveaux éthers qui aurait eu lieu sans recul de la bombe, le nombre d’éthers créés par bloc sera baissé de 5 à 3.

A bit of Constantinople – James Webb 1894

Enfin, l’EPI 684 introduit l’impossibilité de déployer un contrat à une adresse où un autre contrat est déjà déployé. Un tel déploiement est aujourd’hui impossible (collision de hash) mais l’éventualité pourrait se présenter après les changements à venir dans Constantinople.