Istanbul, le guide de la fork prévue début décembre

Annoncée et confirmée par la publication des versions 1.9.7 “Quad Kicker” du client Geth, 2.6.5 du client Parity et 1.3.4 du client Hyperledger Besu, la prochaine fork d’Ethereum est programmée pour le bloc numéro 9,069,000 soit, à priori, dans la journée du 4 décembre [édition : en réalité plutôt autour du 7 décembre à cause de la bombe de difficulté]

Cet article va faire le tour des 6 différentes EIPs (Ethereum Improvement Proposal) qui seront ainsi intégrées dans Ethereum. Le déploiement d’Istanbul va apporter :

• Un alignement du coût de certaines opérations machines avec leur difficulté d’exécution et une amélioration de la résilience d’Ethereum
• Des gains de performance pour les solutions de scalabilté qui exploitent des techniques cryptographiques basées sur les SNARKs et STARKs
• De l’interopérabilité entre Zcash et Ethereum
• De nouvelles fonctionnalités pour les contrats autonomes. 

En route vers les EIPs 152, 1108, 1344, 1884, 2028, 2200 !

Introduction: le processus de mise à jour d’Ethereum

Le protocole Ethereum est mis à jour par des forks dont le contenu est publiquement et librement discuté. Tout un chacun peut contribuer aux EIPs en suivant le processus de l’EIP-1. Une fois ajoutées au dossier github correspondant, les EIPs sont commentées et débattues par la communauté des développeurs et des utilisateurs jusqu’à l’atteinte d’un niveau de maturité puis sont mises à l’agenda des meetings bi-mensuels des Core Developers. Ces meetings sont diffusés en direct, sur des plateformes de streaming avec un forum ouvert, et la discussion est animée par des représentants des différents clients Ethereum en plus des initiateurs des EIPs à l’agenda. L’objet de ces meetings est avant tout la faisabilité technique et la priorisation des développements. Les EIPs sont ensuite implémentées par les développeurs des clients et la mise à jour est programmée sur le testnet Ropsten avant d’être diffusée sur le réseau principal d’Ethereum.

Une procédure guidée par l’échéance de la prochaine fork

Cette approche a prévalu jusqu’à aujourd’hui avec des EIPs implémentées et déployées en groupe à chaque fork. De nombreuses EIPs sont proposées et discutées en parallèle et avec des niveaux de finalisation variables tandis que l’échéance de la prochaine fork impose une cadence soutenue pour faire partie de la prochaine mise à jour. Cette approche a pu parfois limiter le temps nécessaire consacré à la revue des EIPs. 

Les futures forks tenteront une procédure nouvelle centrée sur les EIPs pour leur permettre de gagner en maturité indépendamment du calendrier des mises à jour. Les EIPs matures seront d’abord intégrées par des clients Ethereum, des développeurs ou la communauté, puis implémentées dans les clients principaux, puis testées et enfin acceptées c’est-à-dire mises au programme d’une future fork.

EIP 152 : Contrat précompilé pour la fonction de hachage BLAKE2

Cette EIP ajoute la fonction de hachage BLAKE2 ainsi que plusieurs de ses variantes aux opérations natives de la Machine Virtuelle Ethereum (EVM). Pour mémoire, chaque client Ethereum (Geth, Parity, Hyperledger Besu…) émule la même EVM dans laquelle sont exécutés les instructions machines (opcodes) contenus dans les transactions de la blockchain. Les opcodes sont le langage natif de l’EVM et contiennent aussi bien des instructions basiques comme ADD (addition), DIV (division), SSTORE (stockage) etc. que des instructions plus sophistiquées comme SHA3 pour la fonction de hachage keccak256.

Les contrats précompilés permettent d’étendre les fonctionnalités de l’EVM à partir d’opérations codées dans le langage d’écriture de chaque EVM. Par exemple la fonction de hachage SHA256, très répandue dans bitcoin, est disponible dans l’EVM de chaque client Ethereum via l’implémentation de référence dans le langage du client correspondant. Ainsi Parity utilise l’implémentation en Rust, Hyperledger Besu en Java et Geth en Go.  Ces implémentations sont référencées dans la blockchain à la même adresse dans chaque client. Pour la fonction SHA256 il s’agit de l’adresse 2 (0x0000000000000000000000000000000000000002), qui ne contient pas de code dans la blockchain mais, lorsque l’adresse 2 est invoquée par un contrat autonome, l’EVM l’interprète via l’implémentation locale du client.

Extrait des contrats précompilés en Go du client Geth 

Cette façon de procéder pour ajouter des fonctionnalités à l’EVM permet une grande flexibilité et les déploiements privés d’Ethereum peuvent à l’envie retirer ou ajouter des contrats précompilés.

Pour les utilisateurs d’Ethereum, chaque opération machine a un prix correspondant à sa difficulté d’exécution en termes de ressources informatiques. Ces contrats précompilés étant très optimisés et implémentés nativement dans les clients, leurs fonctionnalités sont très peu onéreuses. Il est néanmoins nécessaire pour invoquer un contrat précompilé d’utiliser (et donc de payer) l’opcode CALL qui déclenche l’appelle à un contrat, l’EIP-1109 (non finalisée) a ainsi pour but de simplifier encore ce fonctionnement et donc de baisser les coûts pour les utilisateurs.

L’ajout de BLAKE2 par l’EIP-152 rend disponible la fonction de hachage principale de ZCash et autres blockchains, comme Komodo, faisant usage de Equihash. Notons au passage que l’algorithme de minage Equihash a été développé par des chercheurs du centre SnT de l’Université du Luxembourg tandis que le français Jean-Philippe Aumasson faisait partie de l’équipe à l’origine de BLAKE2. 

L’ajout de nouvelles fonctions de hachage permet d’améliorer l’interopérabilité d’Ethereum avec les blockchains reposant sur ces fonctions. Il devient possible de vérifier le contenu d’un bloc d’une autre blockchain à l’intérieur d’Ethereum puis par exemple de déclencher des contrats de finance décentralisée.

EIP-1108: Réduction du coût des opérations (vérifications de couplage) sur la courbe elliptique alt_bn128 

Les courbes elliptiques ont des applications très importantes en cryptographie. Citons, par exemple, le principe de signature numérique ECDSA qui est très largement répandu en blockchain. Les courbes elliptiques sont aussi présentes dans les techniques d’obfuscation comme les ZK-SNARKs (cet article décrit succinctement leurs fonctionnements) qui font usage d’opérations arithmétiques sur ces courbes. Avec l’intégration de l’EIP-196 dans la fork Byzantium de novembre 2017 (voir l’article d’Ethereum-France sur le sujet), les opérations sur la courbe alt_bn128 ont été introduites dans un contrat précompilé et l’EIP-1108 vient réduire le coût de ces opérations. Depuis Byzantium de nouvelles implémentations très performantes de ces opérations sont disponibles notamment dans les librairies officielles de Go et Rust, en conséquence leur utilisation dans Ethereum seront moins onéreuses.

EIP 1344: Création d’un opcode spécifique pour le ChainID

Ethereum existe aussi bien dans des instanciations publiques que privées. Il est très simple de lancer sa propre version, il suffit de créer un bloc de départ (Genesis Block) et d’inviter des pairs à faire partie de ce réseau. Les réseaux ethereum alternatifs sont souvent conçus sur mesure pour répondre à des besoins spécifiques de leur participants et la personnalisation peut toucher l’ensemble du protocole, de la forme de consensus (PoA, PoS, IBFT, PoW, …) aux contrats précompilés, en passant par la distribution et les règles d’émission des éthers natifs de la blockchain. Le site ChainID.Network en référence plusieurs dizaines. Les wallets restent compatibles d’une instanciation à l’autre, il est d’ailleurs possible de se connecter à un n’importe quel réseau via MetaMask avec une adresse RPC:

Depuis novembre 2016 (fork Spurious Dragon et EIP-155) Ethereum possède un mécanisme de protection pour assurer qu’une transaction créée pour une certaine chaîne ne puisse pas être répliquée sur une autre chaîne ethereum. La signature d’une transaction s’applique ainsi sur un identifiant de la chaîne ou ChainID. L’EIP-1344 introduit la possibilité de consulter le ChainID à l’intérieur d’un contrat afin, entre autres, de permettre de nouveaux mécanismes pour les méthodes de scalabilité comme Plasma ou les Sidechains. Ces dernières communiquent souvent avec le réseau principal à l’aide de contrats servant de pont (par exemple Parity Bridge) qui vont pouvoir bénéficier de cet opcode pour vérifier la provenance d’une transaction d’une chaîne à l’autre.

EIP 1884: Changement de coûts des opcodes dont la difficulté d’exécution dépend de l’étendue de la structure des données

Comme évoqué plus haut, les opcodes ont un prix (exprimé en Gas) qui correspond à leur difficulté d’exécution en termes de ressources informatiques. Pour des opcodes qui impliquent des opérations de lecture cette difficulté d’exécution dépend de l’étendue de la structure des données à parcourir. Par exemple l’opcode SLOAD consulte une case mémoire dans l’état de l’EVM, cette opération est d’autant plus difficile que l’état de l’EVM est grand. Or l’état de l’EVM grossit à chaque bloc avec l’activité intense du réseau. L’EIP-1884 change le coûts des opcodes SLOAD de 200 à 800 gas, de BALANCE de 400 à 700 gas, et EXTCODEHASH de 400 à 700 gas. Enfin le nouvel opcode SELFBALANCE est créé avec un coût très faible (5 gas). L’opcode EXTCODEHASH renvoie le hash du code d’un contrat. L’opcode BALANCE renvoie le solde d’un compte tandis que SELFBALANCE renvoie le solde du contrat en cours d’exécution. 

EIP 2028: Réduction du coût en gas de l’inclusion de données dans les transactions

Cette EIP réduit le coût en gas de l’ajout de données dans une transaction de 68 gas par byte à 16 gas par byte. Le coût en gas se justifiait par des considérations sur les délais de transmission des données dans le réseau. Des travaux récents (Sompolinsky et Zohar puis Pass, Seeman et Shelat) ont amélioré la compréhension de ces délais et motivé ce changement qui offre des gains directs de scalabilité. En effet, les méthodes utilisant des opérations réalisées hors de la chaîne principale seront moins onéreuses. Cela concerne aussi bien les SNARKs et STARKs que les Sidechains et Plasma mais aussi les oracles! 

Une excellente nouvelle, en somme, et à laquelle ont largement œuvré les équipes de StarkWare dont le cofondateur (et co-auteur de cet EIP) Eli Ben Sasson sera présent à EthCC!

EIP 2200: Définition du coût net en gas de l’opcode SSTORE

L’opcode SSTORE est l’instruction utilisée par l’EVM pour enregistrer une information dans sa mémoire. Son coût d’exécution est différent selon qu’il faille créer une nouvelle case mémoire (20,000 gas), écraser une information existante par une nouvelle information (5,000 gas) ou supprimer la case mémoire (remboursement de 15,000 gas). Cette EIP optimise le fonctionnement de SSTORE et permettra par exemple de regrouper pour un coût moindre des transferts multiples de jetons ERC-20 

Que devez-vous faire d’ici le 4 décembre ?

Mettre à jour votre nœud et vous inscrire au meetup de débriefing de Devcon 5!