Tout comme Bitcoin, Ethereum cherche des solutions pour augmenter le débit de transactions possibles sur sa blockchain. Le 17 octobre, la première brique d'une série d'améliorations sera posée avec la mise en place de Byzantium. Une opération de grande envergure.
Régulièrement, les protocoles des différentes crypto-monnaies évoluent, afin de faire place à de nouvelles fonctionnalités ou tout simplement pour fluidifier leur réseau. Le plus souvent, ces modifications se font de façon transparente, et requièrent simplement une mise à jour du client utilisé pour accéder à leur blockchain.
Un fork pour préparer l'avenir
La dernière opération de très grande envergure concernait Bitcoin, avec la mise en place de SegWit (voir notre analyse). Celle-ci a permis à la blockchain de gérer davantage de transactions tout en conservant la taille originale des blocs (1 Mo), avec un maximum théorique passant de 7 opérations par seconde à environ 11.
Un mouvement suffisant pour résoudre, au moins temporairement, les problèmes d'engorgement du réseau, qui avait provoqué une montée en flèche du coût des échanges. Au plus fort de la crise, effectuer une transaction en Bitcoin pouvait coûter plus de 5 dollars, contre environ 1,3 dollar aujourd'hui.
Le problème est moins prononcé avec Ethereum, le coût moyen d'une transaction est passé de 0,005 dollar début 2017 à environ 0,35 dollar aujourd'hui. Cette augmentation est due en partie à l'accroissement de la difficulté du minage, qui ralentit le rythme de sortie des blocs. Une situation qui empire de jour en jour et peut causer d'ici quelques mois de sérieux problèmes fonctionnels.
Heureusement, un hard-fork, prévu de longue date, doit donner un peu d'air au réseau avant de mettre en place une solution plus radicale.
De Metropolis à Byzantium
Depuis son lancement en août 2015, la blockchain d'Ethereum suit une feuille de route (roadmap) clairement définie. La première version répondait au nom de Frontier et ne regroupait que des fonctionnalités de base : le minage, le suivi des transactions et les smart contracts.
Quelques mois plus tard est arrivée Homestead, une version plus stable, capable de supporter des applications décentralisées ou « dApps ». Un concept très large, regroupant plusieurs catégories d'applications, que le créateur d'Ethereum résume dans ce billet de blog.
Le 17 octobre, au moment de l'émission du bloc numéro 4 370 000, un troisième palier sera atteint, avec la mise à jour Metropolis. Elle se fera en deux temps. D'abord, avec une première vague d'améliorations nommée Byzantium, puis avec Constantinople dans un second temps, très certainement l'an prochain.
Byzance et une rustine pour repousser l'Âge de glace
Au total, Byzantium comprend dix Ethereum Improvement Proposals (EIP) chacune devant résoudre un problème particulier. Parmi elle, l'EIP 649 doit avoir certaines des conséquences les plus visibles. Elle modifie l'algorithme « Ice Age », qui détermine la difficulté avec laquelle les blocs sont minés.
Pour la plupart des crypto-monnaies, la courbe de difficulté suit linéairement celle du hashrate, c'est-à-dire de la puissance de calcul totale mise en œuvre par les mineurs. Dans le cas d'Ethereum, la croissance est exponentielle. Depuis avril dernier, la difficulté augmente plus rapidement que le hashrate, causant un allongement progressif du temps écoulé entre chaque bloc. Or, en passant moins de blocs dans une même fenêtre de temps, la capacité du réseau diminue mécaniquement.
Ce comportement est volontaire. Ethereum a en effet vocation à basculer d'un système de validation par preuve de travail (PoW) à un système par preuve d'enjeu (PoS). L'objectif est ici d'assurer une transition en douceur entre les deux modes de fonctionnement, en incitant les acteurs du réseau à passer de l'un à l'autre. Le problème est que la mise en place de la PoS demande plus de temps que prévu, et qu'en attendant, la difficulté continue de grimper.
Pour limiter les dégâts, l'EIP 649 propose de reculer de 18 mois la date de « l'Âge de glace », la date à laquelle la difficulté devient telle que le réseau ne peut plus fonctionner. Sans cette modification, on estime que des problèmes fonctionnels causés par la hausse de la difficulté apparaitront dès le printemps prochain et le réseau sera complètement figé courant 2021
Ce serait alors la deuxième fois qu'une telle rustine est appliquée, la première remontant au déploiement d'Homestead en 2016.
Une petite touche de zCash
Les EIP 198, 212 et 213 sont elles aussi très intéressantes. Elles permettent l'utilisation d'opérations cryptographiques complexes, telles que RSA, au sein d'un smart contract ou encore « le déploiement de contrats précompilés sur certaines courbes elliptiques ».
Si vu ainsi il n'y a pas de quoi sauter au plafond, ces trois EIP permettent en fait l'utilisation de zk-SNARK, un système permettant de cacher les détails des transactions ou des contrats tout en en permettant leur validation (zero knowledge proof). Ce principe a été développé par l'équipe derrière zCash (voir notre analyse de zCash).
Seul inconvénient : les transactions forgées en utilisant ce principe (qui reste optionnel) sont plus lourdes et nécessitent donc davantage de « gas » pour être traitées par le réseau et seront donc plus coûteuses à émettre.
Des contrats plus légers et plus sûrs
Trois EIP (206, 211 et 214) concernent directement les smart contracts et autorisent de nouveaux types d'opérations en leur sein. La première, REVERT, fournit une méthode pour arrêter l'exécution d'un contrat et pour annuler un changement d'état. Cette manipulation est déjà possible, à condition de bidouiller, ce qui peut être source d'erreurs et fait gonfler inutilement la taille du contrat. Par ailleurs, la fonction permet aussi de renvoyer une raison pour son déclenchement.
La deuxième ajoute deux instructions RETURNDATASIZE et RETURNDATACOPY, pour récupérer la taille d'une donnée ou son contenu plus simplement. Enfin, l'EIP 214 ajoute l'instruction STATICCALL qui permet de faire appel à un autre contrat, sans que celui-ci puisse forcer de changement d'état dans le contrat actuel. C'est ce type de vulnérabilité qui était en jeu dans le fameux piratage de The DAO, à 50 millions de dollars.
Minage, performances et clients légers
Du côté des clients, plusieurs améliorations ciblent les variantes dites « légères », qui ne téléchargent pas l'ensemble de la blockchain pour fonctionner. Via l'EIP 98, certains calculs nécessaires pour forger les transactions seront allégés, ce afin de faciliter l'utilisation d'Ethereum sur les appareils mobiles par exemple.
Les clients légers pourront aussi vérifier l'exécution d'un contrat (EIP 658), ce qui n'est pas encore possible nativement. Cette opération réclame aujourd'hui d'accéder à l'ensemble de la blockchain, il est donc nécessaire de passer par un service tiers qui effectue la vérification à la place du client léger, ce qui n'est pas idéal.
Enfin, les mineurs profiteront d'une meilleure gestion des blocs orphelins (qui sont appelés « oncles » par les adeptes d'Ethereum). Les blocs orphelins sont créés lorsque deux mineurs trouvent un bloc à quelques instants d'intervalle. Pendant un certain temps, ces deux blocs coexistent en attendant que le réseau détermine lequel est valide.
Actuellement, seul le bloc valide renferme une récompense. Pour rendre la tâche plus équitable, les oncles renfermeront eux aussi une petite récompense, plus faible. Le calcul de la difficulté est également revu à la marge afin d'éviter qu'un afflux soudain d'oncles ne provoque une surinflation.
En route pour Constantinople
La prochaine étape ne devrait pas arriver avant l'an prochain. La mise à jour Constantinople devra remplir deux objectifs principaux : lisser tous les petits bugs introduits avec Byzantium, et mettre en place une blockchain hybride tenant compte à la fois de l'actuelle PoW et de la future PoS.
Il sera alors intéressant de voir comment la communauté accueillera ce changement crucial, mais prévu de longue date. Pour l'heure, l'adoption de Byzantium ne semble pas particulièrement poser de problème, plus de 70 % des nœuds du réseau étant déjà prêts à accueillir la mise à jour.
