Le lancement de Berlin, deuxième étape de la mise à niveau d’Istanbul, devrait avoir lieu à un moment donné en 2020. Les développeurs principaux d’Ethereum ont divisé Istanbul en deux phases, car deux des EIP à discuter nécessitent des tests et un développement approfondis avant leur lancement. À l’heure actuelle, les développeurs principaux ont approuvé et élevé deux EIP au statut accepté. Il y a deux autres EIP proposés qui pourraient être prêts à temps pour Berlin.

Accepté EIP-2315 implémente des sous-routines simples pour l’EVM qui pourraient réduire les coûts du gaz et faciliter l’analyse des états EIP 2537 (qui a remplacé EIP-1962) implémente une courbe BLS unique pour faciliter le déploiement et la gestion des contrats de cumul et des zk-SNARKs/STARKs

Proposé EIP-2046 réduit le coût du gaz pour les appels statiques effectués vers des contrats précompilés EIP-2565 réévaluera le prix du précompilation ModExp (EIP-198) pour permettre une vérification plus rentable des signatures RSA, des fonctions de retard vérifiables (VDF) et des contrôles de primalité, entre autres fonctions

Istanbul Phase II exclut notamment tout EIP lié à la bombe de difficulté (c’est-à-dire l'« ère glaciaire » d’Ethereum). Les principaux développeurs ont conclu, « il n’y a pas de raison majeure de le faire maintenant » parce que la bombe de difficulté n’est nécessaire qu’une fois qu’Ethereum 2.0 et son mécanisme de consensus Proof-of-Stake (PoS) sont activés. Négliger un EIP de l’ère glaciaire pour l’instant évite également tout retard supplémentaire dans la phase de développement de Berlin.

Les développeurs principaux et la grande communauté Ethereum excluent également l’EIP-1057, la proposition du désormais tristement célèbre ProgPoW (abréviation de Progressive Proof-of-Work). Il visait à modifier l’algorithme de hachage d’Ethereum pour combler l’écart d’efficacité des performances entre le matériel minier généralisé et spécialisé (également connu sous le nom d’ASIC). Alors que les mineurs de GPU et certains développeurs de base étaient favorables à la proposition, de nombreux membres de la communauté s’y opposaient avec véhémence. Par conséquent, toutes les parties conviennent qu’un href= » « n’inclut pas ProgPoW/a dans les forks à venir car aucun changement de protocole ne vaut la peine de déclencher une scission du réseau

Pour en savoir plus: Feuille de calcul des EIP de Berlin

EIP-1559 a été écrit par Vitalik Buterin et Eric Conner, entre autres. Il vise à remplacer le modèle de frais « enchères au premier prix » d’Ethereum par des frais de réseau de base qui pourraient changer en fonction de la demande du réseau. L’objectif est de créer un marché des frais plus efficace et de simplifier le processus de paiement du gaz pour les logiciels des clients et des applications, éliminant ainsi la possibilité pour les utilisateurs de payer des frais de gaz inutilement élevés. L’EIP-1559 propose également de brûler les frais de réseau de base pour aider à maintenir ces frais bas et l’inflation de l’ETH sous contrôle.

La phase 1 introduira 64 chaînes de partitions indépendantes dans le réseau ETH 2.0. Les chaînes de partitions n’exécuteront pas d’état ou ne garderont pas de trace des soldes de compte, car la phase vise uniquement à tester la construction et la validité des chaînes de partitions avec la chaîne de balises. L’ETH 1.0 continuera à fonctionner en parallèle avec l’ETH 2.0 tout au long de cette phase.

Une proposition de fusion du réseau Ethereum actuel avec Ethereum 2.0 introduite pour la première fois par Vitalik Buterin. La proposition vise à supprimer la chaîne de preuve de travail (PoW) en déplaçant tout sur la chaîne Beacon selon un calendrier accéléré. Cette fusion accélérée nécessite des clients sans état sur Ethereum 1.x, ce qui éliminerait la nécessité pour la plupart des nœuds de stocker l’état entier.

La phase finale de Serenity ajoutera toutes les fonctionnalités aux chaînes de partitions, leur permettant d’exécuter des transactions et de maintenir les soldes des comptes. Il introduit également la machine virtuelle eWASM, qui remplacera l’EVM.

Olympic était la dernière preuve de concept d’Ethereum publiée avant le lancement du réseau principal. Son objectif déclaré était de récompenser les participants pour avoir testé les limites de la conception d’Ethereum en « spammant le réseau avec des transactions et en faisant des choses folles avec l’État ». L’événement comprenait un concours qui offrait un pool de 25 000 ETH (un href = « ~ 0,03% de l’offre initiale d’Ethereum / a) pour les meilleurs mineurs et développeurs participants. Un large engagement testnet a mis au jour des bogues critiques et des optimisations simples dans le système en direct que l’équipe principale a pu identifier et résoudre avant le réseau principal. Les développeurs principaux d’Ethereum ont déprécié Olympic lorsque Frontier a été lancé en faveur de Mordon, le réseau de test public équivalent à Frontier.

Frontier a marqué la sortie officielle 1.0 du réseau principal Ethereum et a introduit une série de nouvelles caractéristiques, notamment une récompense de bloc, une limite de bloc de gaz temporaire et des contrats Canary. Le lancement de Frontier a permis aux mineurs de commencer à recevoir de véritables ETH en récompense de leurs efforts, la subvention initiale du bloc étant composée de cinq ETH par bloc valide. La version 1.0 comportait également une limite de gaz codée en dur de 5000 gaz par bloc pour éviter tout problème avec l’installation du nœud. La limite de gaz n’a duré que quelques jours après le lancement avant d’être automatiquement supprimée. Pour éviter les fourches à chaîne indésirables, Frontier contenait également des contrats Canary. Les contrats Canary ont donné aux développeurs principaux d’Ethereum la possibilité d’arrêter des opérations ou des transactions spécifiques avant qu’un mineur ne s’égare dans une chaîne orpheline. Ces contrats signifiaient que l’exécution finale des transactions restait centralisée dans les premières étapes d’Ethereum.

Homestead a été le premier hard fork prévu d’Ethereum et a eu lieu au numéro de bloc 1,150,000. La mise à niveau a supprimé les contrats Canary utilisés dans Frontier, éliminant ainsi le processus centralisé d’exécution des transactions, et a introduit les contrats intelligents Solidity maintenant largement utilisés. Il comprenait également le portefeuille Mist (maintenant obsolète), la première interface utilisateur (UI) pour stocker et traiter des jetons, ainsi que pour écrire et déployer des contrats intelligents.

En outre, Homestead a été l’une des premières implémentations d’un href= » « Ethereum Improvement Proposals (EIP)/a, et la mise à niveau a introduit trois nouveaux EIP lors de l’activation: Le PIE-2 (qui comprenait les sous-propositions EIP 2.1-2.4) a assuré la conformité ACID (tout ou rien) pour les déploiements contractuels et a aidé à stabiliser les temps de blocage. EIP-7 a ajouté l’opcode DELETECALL Logiciel client équipé EIP-8 avec la capacité de s’adapter aux futures mises à jour du protocole réseau

Le hard fork Spurious Dragon s’est activé au bloc 2 675 000, qui est arrivé le 22 novembre 2019. La mise à niveau a introduit quatre modifications de code : EIP-155 offrait une protection contre les attaques par relecture EIP-160 augmente le prix de l’opcode EXP pour rendre plus difficile le ralentissement du réseau avec des opérations à forte intensité de calcul EIP-161 permet de supprimer un grand nombre de comptes vides pour réduire la taille de l’état de la blockchain EIP-170 fixe une limite pour la taille de code qu’un contrat intelligent peut contenir afin d’éviter les attaques répétitives sur de gros morceaux de code

Byzance était la première phase de la mise à niveau proposée de Metropolis et a été activée au bloc 4 370 000. Le hard fork Byzantium comprenait neuf EIP, avec EIP-100, EIP-658 et EIP-649, introduisant les modifications de code les plus importantes. L’EIP-100 a ajusté la formule de difficulté pour stabiliser le taux d’émission des EPF EIP-658 a ajouté un nouveau champ aux reçus de transaction pour indiquer la réussite ou l’échec EIP-649 a retardé d’un an la bombe de difficulté (c’est-à-dire l'«ère glaciaire » d’Ethereum) et a réduit la subvention de bloc de cinq à trois ETH Des détails sur les EIP Byzance restants sont disponibles ici.

Constantinople, la deuxième phase de Metropolis, devait initialement être mise en service au bloc 7 080 000 (16 janvier 2019). Mais le 15 janvier 2019, la société d’audit de sécurité ChainSecurity a découvert une vulnérabilité dans l’un des EIP acceptés qui permettrait une attaque de rentrée (c’est-à-dire la possibilité pour un attaquant de voler des fonds utilisateur similaires au piratage DAO). Les principaux développeurs d’Ethereum et certains projets en cours d’exécution sur le réseau ont voté pour retarder Constantinople jusqu’à ce que les développeurs comblent la faille de sécurité.

Après un mois de retard, Constantinople et son patch de sécurité, St. Petersburg, a été mis en service au bloc 7 280 000, introduisant cinq nouveaux changements de code sur le réseau: EIP-145 a ajouté des instructions de décalage Bitwise à l’EVM, rendant l’exécution des changements dans les contrats intelligents beaucoup moins chère EIP-1052 vérification accélérée des contrats inter-intelligents (les contrats intelligents peuvent se vérifier mutuellement via un hachage plutôt que l’ensemble du code) EIP-1014 a amélioré les intégrations de canaux d’état pour faciliter la connexion aux solutions de mise à l’échelle hors chaîne EIP-1283 a réduit les coûts d’exécution de plusieurs mises à jour au sein d’une seule transaction (alias l’opcode SSTORE) EIP-1234 a retardé la bombe de difficulté d’une autre année et a réduit la récompense minière de trois à deux ETH par bloc (la réduction est également connue sous le nom de « Thirdening »)

La première phase d’Istanbul devrait s’activer au bloc 9 069 000, près de deux mois après son lancement initialement prévu (Oct. 16, 2019). La phase I d’Istanbul a l’intention d’introduire six nouveaux EIP lors de l’activation pour aider à optimiser les coûts de calcul de l’opcode, améliorer la sécurité des attaques par déni de service et améliorer les performances des solutions de couche 2 en utilisant un href= » « ZK-SNARKs/a ou un href= » « ZK-STARKs/a, entre autres avancées. Les PEI acceptés comprennent : EIP-152 ajoute la possibilité de vérifier les échanges atomiques Zcash-à-Ethereum EIP-1108 réduit les coûts des ZK-SNARK L’EIP-1344 améliore la capacité des contrats intelligents, en particulier ceux utilisés par les solutions de couche 2, pour suivre la chaîne de base correcte lors d’une fourche dure EIP-1844 restructure les coûts d’une machine virtuelle (EVM) / a spécifique à href = " " Ethereum pour dissuader les attaques de spamming et pour faire correspondre chaque opération avec son niveau de calcul requis EIP-2028 réduit le coût de l’appel de données dans les transactions et les frais associés aux ZK-SNARK et ZK-STARK L’EIP-2200 modifie le coût du stockage dans l’EVM et permet aux contrats intelligents de générer des fonctions plus créatives

La fourche dure Muir Glacier s’est activée au bloc 9 200 000, qui est arrivé le 2 janvier 2020. La mise à niveau n’incluait que l’EIP-2384, qui a retardé la « bombe de difficulté » inhérente à Ethereum de 4 000 000 de blocs supplémentaires (environ 611 jours) pour éviter que les temps de blocage n’augmentent (et que la convivialité ne chute). L’arrivée abrupte de Muir Glacier, moins d’un mois après Istanbul, a marqué la troisième fois que les développeurs principaux d’Ethereum ont choisi de retarder la bombe de difficulté (alias Ice Age).

Pour en savoir plus: Mise à niveau d’Ethereum Muir Glacier par les éleveurs de chats Ethereum

Serenity Phase 0 marque la transition initiale d’Ethereum vers Ethereum 2.0. Cette phase initiale introduira la Beacon Chain, qui servira d’épine dorsale à l’architecture réseau partitionnée d’Ethereum 2.0. Contrairement à la blockchain actuelle proof-of-work (PoW) d’Ethereum, la Beacon Chain utilisera Casper FFG, une variante spécifique de Proof-of-Stake (PoS), et un système de validateurs pour confirmer les transactions et inhiber les attaques Sybil.

Les développeurs principaux d’Ethereum ont divisé la mise à niveau Serenity en trois phases pour optimiser le processus de développement et limiter les risques de déploiement. Les spécifications de cette première phase comprennent : Beacon Chain est le cœur du système Ethereum 2.0; il gère le protocole PoS pour lui-même et toutes les chaînes de fragments individuelles. La chaîne Beacon utilisera Casper the Friendly Finality Gadget (Casper FFG) pour assurer la finalité de la transaction. Fork Choice permet aux clients des validateurs de sélectionner automatiquement la bonne chaîne lorsque la fourche Phase 0 Serenity est lancée Le contrat de dépôt permet aux parties prenantes d’Ethereum de transférer des fonds de l’ETH 1.0 vers l’ETH 2.0 et de revendiquer des droits à un rôle de validateur sur la nouvelle chaîne PoS Honest Validator dicte le comportement attendu d’un « validateur honnête et les spécifications de réduction des charges par rapport à la phase 0 de l’ETH 2.0 »

Il est essentiel de noter que le lancement de la phase 0 ne remplacera pas immédiatement Ethereum 1.0 (également connu sous le nom d’Ethereum 1.x). Les deux chaînes coexisteront au moins jusqu’à ce que Serenity Phase 1.5 arrive, ce qui marque le moment où la chaîne Ethereum actuelle fusionnera dans le système Ethereum 2.0 un fragment au sein du réseau. La gestion parallèle des chaînes existantes et futures peut entraîner une augmentation de l’inflation de l’ETH, car les deux chaînes frapperont simultanément de nouveaux jetons.