Une chronologie de toutes les étapes majeures, des forks et des mises à jour de la chaîne de blocs Ethereum.
Les forks se produisent lorsque des mises à jour ou des modifications techniques majeures doivent être apportées au réseau – ils découlent généralement des propositions d'amélioration d'Ethereum (EIP) et modifient les « règles » du protocole.
Lorsque des mises à jour sont nécessaires dans un logiciel traditionnel contrôlé de manière centralisée, l'entreprise publie simplement une nouvelle version pour l'utilisateur final. Les chaînes de blocs fonctionnent différemment car il n'y a pas de propriété centrale. Les clients Ethereum doivent mettre à jour leurs logiciels pour implémenter les nouvelles règles du fork. De plus, les créateurs de blocs (les mineurs dans un monde de preuve de travail (PoW), les validateurs dans un monde de preuve d'enjeu (PoS)) et les nœuds doivent créer des blocs et les valider selon les nouvelles règles. En savoir plus sur les mécanismes de consensus
Ces changements de règles peuvent créer une scission temporaire du réseau. De nouveaux blocs pourraient être produits selon les nouvelles règles ou les anciennes. Les forks sont généralement convenus à l'avance afin que les clients adoptent les changements à l'unisson et que le fork avec les mises à jour devienne la chaîne principale. Cependant, dans de rares cas, des désaccords sur les forks peuvent entraîner une scission permanente du réseau – notamment la création d'Ethereum Classic avec le fork DAO.
Le logiciel qui sous-tend Ethereum est composé de deux moitiés, connues sous le nom de et de .
Nommage des mises à jour d'exécution
Depuis 2021, les mises à jour de la couche d'exécution sont nommées d'après les noms des villes des précédents lieux de la Devcon et de la Devconnect (opens in a new tab) par ordre chronologique :
| Nom de la mise à jour | Année de la Devcon(nect) | Numéro de la Devcon | Date de la mise à jour |
|---|---|---|---|
| Berlin | 2014 | 0 | 15 avr. 2021 |
| London | 2015 | I | 5 août 2021 |
| Shanghai | 2016 | II | 12 avr. 2023 |
| Cancun | 2017 | III | 13 mars 2024 |
| Prague | 2018 | IV | 7 mai 2025 |
| Osaka | 2019 | V | 3 déc. 2025 |
| Amsterdam | 2022 | Devconnect | À déterminer - Suivante |
| Bogotá | 2022 | VI | À déterminer |
| Istanbul | 2023 | Devconnect | À déterminer |
| Bangkok | 2024 | VII | À déterminer |
| Buenos Aires | 2025 | Devconnect | À déterminer |
| Mumbai | 2026 | VIII | À déterminer |
Nommage des mises à jour de consensus
Depuis le lancement de la , les mises à jour de la couche de consensus portent le nom d'étoiles célestes commençant par des lettres qui se succèdent par ordre alphabétique :
| Nom de la mise à jour | Date de la mise à jour |
|---|---|
| Genèse de la chaîne balise | 1 déc. 2020 |
| Altair (opens in a new tab) | 27 oct. 2021 |
| Bellatrix (opens in a new tab) | 6 sept. 2022 |
| Capella (opens in a new tab) | 12 avr. 2023 |
| Deneb (opens in a new tab) | 13 mars 2024 |
| Electra (opens in a new tab) | 7 mai 2025 |
| Fulu (opens in a new tab) | 3 déc. 2025 |
| Gloas (opens in a new tab) | À déterminer - Suivante |
| Heze (opens in a new tab) | À déterminer |
Nommage combiné
Les mises à jour d'exécution et de consensus ont d'abord été déployées à des moments différents, mais après La Fusion en 2022, elles ont été déployées simultanément. De ce fait, des termes familiers sont apparus pour simplifier les références à ces mises à jour en utilisant un seul terme conjoint. Cela a commencé avec la mise à jour Shanghai-Capella, communément appelée « Shapella », et se poursuit avec les mises à jour ultérieures.
| Mise à jour d'exécution | Mise à jour de consensus | Nom court |
|---|---|---|
| Shanghai | Capella | « Shapella » |
| Cancun | Deneb | « Dencun » |
| Prague | Electra | « Pectra » |
| Osaka | Fulu | « Fusaka » |
| Amsterdam | Gloas | « Glamsterdam » |
| Bogotá | Heze | « Hegotá » |
Passez directement aux informations concernant certaines des mises à jour passées particulièrement importantes : La chaîne balise ; La Fusion ; et l'EIP-1559
Vous recherchez les futures mises à jour du protocole ? Découvrez les prochaines mises à jour sur la feuille de route d'Ethereum.
2025
Fulu-Osaka ("Fusaka")
Plus d'informations sur Fusaka
Prague-Electra ("Pectra")
La mise à jour Prague-Electra ("Pectra") a inclus plusieurs améliorations au protocole Ethereum visant à améliorer l'expérience pour tous les utilisateurs, les réseaux de couche 2 (l2), les stakers et les opérateurs de nœuds.
Le staking a bénéficié d'une mise à jour avec des comptes de validateur à composition, et un meilleur contrôle sur les fonds mis en jeu en utilisant l'adresse de retrait d'exécution. L'EIP-7251 a augmenté le solde effectif maximum pour un seul validateur à 2048, améliorant l'efficacité du capital pour les stakers. L'EIP-7002 a permis à un compte d'exécution de déclencher en toute sécurité des actions de validateur, y compris la sortie, ou le retrait de portions des fonds, améliorant l'expérience pour les stakers d'ETH, tout en aidant à renforcer la responsabilité des opérateurs de nœuds.
D'autres parties de la mise à jour se sont concentrées sur l'amélioration de l'expérience pour les utilisateurs réguliers. L'EIP-7702 a apporté la capacité pour un compte régulier qui n'est pas un contrat intelligent () d'exécuter du code similaire à un contrat intelligent. Cela a débloqué de nouvelles fonctionnalités illimitées pour les comptes Ethereum traditionnels, telles que le traitement par lots des transactions, la prise en charge du gaz, l'authentification alternative, les contrôles de dépenses programmables, les mécanismes de récupération de compte et plus encore.
Meilleure expérience utilisateur :
- EIP-7702 - Définir le code de compte EOA
- EIP-7691 - Augmentation du débit des blobs
- EIP-7623 - Augmenter le coût des données d'appel
- EIP-7840 - Ajouter la planification des blobs aux fichiers de configuration de la couche d'exécution (EL)
Meilleure expérience de staking :
- EIP-7251 - Augmenter le
MAX_EFFECTIVE_BALANCE - EIP-7002 - Sorties déclenchables par la couche d'exécution
- EIP-7685 - Requêtes de couche d'exécution à usage général
- EIP-6110 - Fournir les dépôts de validateur onchain
Améliorations de l'efficacité et de la sécurité du protocole :
- Pectra.wtf (opens in a new tab)
- Comment Pectra va améliorer l'expérience de staking (opens in a new tab)
- Lire les spécifications de la mise à jour Electra (opens in a new tab)
- FAQ sur Prague-Electra ("Pectra")
2024
Cancun-Deneb (« Dencun »)
Résumé de Cancun
La mise à jour Cancun contient un ensemble d'améliorations de l'exécution d'Ethereum visant à améliorer la scalabilité, en tandem avec les mises à jour de consensus Deneb.
Cela inclut notamment l'EIP-4844, connu sous le nom de proto-danksharding, qui réduit considérablement le coût de stockage des données pour les rollup de couche 2. Ceci est réalisé grâce à l'introduction de « blobs » de données qui permettent aux rollup de publier des données sur le Réseau principal pendant une courte période. Il en résulte des frais de transaction nettement inférieurs pour les utilisateurs des rollup de couche 2.
- EIP-1153 - Codes d'opération de stockage transitoire
- EIP-4788 - Racine de bloc phare dans l'EVM
- EIP-4844 - Transactions de blob de fragment (proto-danksharding)
- EIP-5656 -
MCOPY- Instruction de copie de mémoire - EIP-6780 -
SELFDESTRUCTuniquement dans la même transaction - EIP-7516 - Code d'opération
BLOBBASEFEE
- Rollup de couche 2
- Proto-danksharding
- Danksharding
- Lire les spécifications de la mise à jour Cancun (opens in a new tab)
Résumé de Deneb
La mise à jour Deneb contient un ensemble d'améliorations du consensus d'Ethereum visant à améliorer la scalabilité. Cette mise à jour intervient en tandem avec les mises à jour d'exécution Cancun pour activer le proto-danksharding (EIP-4844), ainsi que d'autres améliorations de la chaîne balise.
Les « messages de sortie volontaire » signés et prégénérés n'expirent plus, donnant ainsi plus de contrôle aux utilisateurs effectuant du staking de leurs fonds avec un opérateur de nœud tiers. Avec ce message de sortie signé, les stakers peuvent déléguer l'opération du nœud tout en conservant la possibilité de sortir en toute sécurité et de retirer leurs fonds à tout moment, sans avoir besoin de demander la permission à quiconque.
L'EIP-7514 apporte un resserrement de l'émission d'ETH en plafonnant le taux de « churn » auquel les validateurs peuvent rejoindre le réseau à huit (8) par époque. Étant donné que l'émission d'ETH est proportionnelle au total d'ETH en staking, limiter le nombre de validateurs rejoignant le réseau plafonne le taux de croissance des ETH nouvellement émis, tout en réduisant les exigences matérielles pour les opérateurs de nœuds, ce qui favorise la décentralisation.
- Lire les spécifications de la mise à jour Deneb (opens in a new tab)
- FAQ sur Cancun-Deneb (« Dencun »)
2023
Shanghai-Capella ("Shapella")
Résumé de Shanghai
La mise à jour Shanghai a apporté les retraits de staking à la couche d'exécution. En tandem avec la mise à jour Capella, cela a permis aux blocs d'accepter les opérations de retrait, ce qui permet aux stakers de retirer leurs ETH de la chaîne balise vers la couche d'exécution.
Résumé de Capella
La mise à jour Capella était la troisième mise à jour majeure de la couche de consensus (chaîne balise) et a activé les retraits de staking. Capella s'est produite de manière synchrone avec la mise à jour de la couche d'exécution, Shanghai, et a activé la fonctionnalité de retrait de staking.
Cette mise à jour de la couche de consensus a apporté la possibilité aux stakers qui n'avaient pas fourni d'identifiants de retrait lors de leur dépôt initial de le faire, permettant ainsi les retraits.
La mise à jour a également fourni une fonctionnalité de balayage automatique des comptes, qui traite en continu les comptes de validateur pour tout paiement de récompenses disponible ou retrait complet.
- En savoir plus sur les retraits de staking.
- Lire les spécifications de la mise à jour Capella (opens in a new tab)
2022
Paris (La Fusion)
Résumé
La mise à jour Paris a été déclenchée lorsque la chaîne de blocs à preuve de travail (PoW) a dépassé une de 58750000000000000000000. Cela s'est produit au bloc 15537393 le 15 septembre 2022, déclenchant la mise à jour Paris au bloc suivant. Paris était la transition de La Fusion - sa caractéristique principale était la désactivation de l'algorithme de minage à preuve de travail et de la logique de consensus associée, pour passer à la preuve d'enjeu (PoS). Paris elle-même était une mise à jour des clients d'exécution (équivalente à Bellatrix sur la couche de consensus) qui leur a permis de recevoir des instructions de leurs clients de consensus connectés. Cela a nécessité l'activation d'un nouvel ensemble de méthodes d'API internes, collectivement connues sous le nom d'API Engine (opens in a new tab). Il s'agissait sans doute de la mise à jour la plus importante de l'histoire d'Ethereum depuis Homestead !
Bellatrix
Résumé
La mise à jour Bellatrix était la deuxième mise à jour programmée pour la chaîne balise, préparant la chaîne pour La Fusion. Elle porte les pénalités des validateurs à leurs valeurs maximales en cas d'inactivité et d'infractions passibles de réduction. Bellatrix inclut également une mise à jour des règles de choix de fork pour préparer la chaîne à La Fusion et à la transition du dernier bloc à preuve de travail au premier bloc à preuve d'enjeu. Cela implique d'informer les clients de consensus de la de 58750000000000000000000.
Gray Glacier
Résumé
La mise à jour du réseau Gray Glacier a repoussé la de trois mois. C'est le seul changement introduit dans cette mise à jour, et il est de nature similaire aux mises à jour Arrow Glacier et Muir Glacier. Des changements similaires ont été effectués lors des mises à jour du réseau Byzantium, Constantinople et London.
- EIP-5133 – retarde la bombe de difficulté jusqu'en septembre 2022
2021
Arrow Glacier
Résumé
La mise à jour du réseau Arrow Glacier a repoussé la de plusieurs mois. Il s'agit du seul changement introduit par cette mise à jour, qui est de nature similaire à la mise à jour Muir Glacier. Des changements similaires ont été effectués lors des mises à jour du réseau Byzantium, Constantinople et London.
- Blog de la Fondation Ethereum - Annonce de la mise à jour Arrow Glacier (opens in a new tab)
- Ethereum Cat Herders - Mise à jour Ethereum Arrow Glacier (opens in a new tab)
- EIP-4345 – repousse la bombe de difficulté jusqu'en juin 2022
Altair
Résumé
La mise à jour Altair a été la première mise à jour programmée pour la chaîne balise. Elle a ajouté la prise en charge des « comités de synchronisation » (sync committees) — permettant les clients légers, et a augmenté les pénalités d'inactivité des validateurs et de réduction (slashing) à mesure que le développement progressait vers La Fusion.
Fait amusant !
Altair a été la première mise à jour majeure du réseau à avoir une heure de déploiement exacte. Toutes les mises à jour précédentes étaient basées sur un numéro de bloc déclaré sur la chaîne de preuve de travail (PoW), où les temps de bloc varient. La chaîne balise ne nécessite pas de résoudre une preuve de travail, et fonctionne plutôt sur un système d'époques basé sur le temps, composé de 32 « créneaux » (slots) de douze secondes pendant lesquels les validateurs peuvent proposer des blocs. C'est pourquoi nous savions exactement quand nous atteindrions l'époque 74 240 et qu'Altair serait activée !
London
Résumé
La mise à jour London a introduit l'EIP-1559 (opens in a new tab), qui a réformé le marché des frais de transaction, ainsi que des modifications sur la façon dont les remboursements de gaz sont gérés et le calendrier de l'.
Qu'était la mise à jour London / EIP-1559 ?
Avant la mise à jour London, Ethereum avait des blocs de taille fixe. En période de forte demande sur le réseau, ces blocs fonctionnaient à pleine capacité. Par conséquent, les utilisateurs devaient souvent attendre que la demande diminue pour être inclus dans un bloc, ce qui entraînait une mauvaise expérience utilisateur. La mise à jour London a introduit des blocs de taille variable sur Ethereum.
La façon dont les frais de transaction sur le réseau Ethereum étaient calculés a changé avec la mise à jour London d'août 2021. Avant la mise à jour London, les frais étaient calculés sans séparer les frais de base et de priority, comme suit :
Disons qu'Alice devait payer 1 ETH à Bob. Dans la transaction, la limite de gaz est de 21 000 unités, et le prix du gaz est de 200 gwei.
Les frais totaux auraient été de : Gas units (limit) * Gas price per unit soit 21,000 * 200 = 4,200,000 gwei ou 0,0042 ETH
L'implémentation de l'EIP-1559 (opens in a new tab) dans la mise à jour London a rendu le mécanisme des frais de transaction plus complexe, mais a rendu les frais de gaz plus prévisibles, ce qui a permis d'obtenir un marché des frais de transaction plus efficace. Les utilisateurs peuvent soumettre des transactions avec un maxFeePerGas correspondant au montant qu'ils sont prêts à payer pour que la transaction soit exécutée, sachant qu'ils ne paieront pas plus que le prix du marché pour le gaz (baseFeePerGas), et se verront rembourser tout excédent, moins leurs frais de priorité (tip).
Cette vidéo explique l'EIP-1559 et les avantages qu'il apporte : Explication de l'EIP-1559 (opens in a new tab)
- Êtes-vous un développeur d'application décentralisée (dapp) ? Assurez-vous de mettre à jour vos bibliothèques et vos outils. (opens in a new tab)
- Lire l'annonce de la Fondation Ethereum (opens in a new tab)
- Lire les explications des Ethereum Cat Herders (opens in a new tab)
Berlin
Résumé
La mise à jour Berlin a optimisé le coût en gaz pour certaines actions de l'EVM, et augmente la prise en charge de multiples types de transactions.
- Lire l'annonce de la Fondation Ethereum (opens in a new tab)
- Lire les explications des Ethereum Cat Herders (opens in a new tab)
2020
Genèse de la chaîne balise
Résumé
La chaîne balise nécessitait 16 384 dépôts de 32 ETH stakés pour être lancée en toute sécurité. Cela s'est produit le 27 novembre, et la chaîne balise a commencé à produire des blocs le 1er décembre 2020.
Lire l'annonce de la Fondation Ethereum (opens in a new tab)
La chaîne balise
Déploiement du contrat de dépôt de staking
Résumé
Le contrat de dépôt de staking a introduit le dans l'écosystème Ethereum. Bien qu'il s'agisse d'un contrat du , il a eu un impact direct sur le calendrier de lancement de la chaîne balise, une importante mise à jour d'Ethereum.
Lire l'annonce de la Fondation Ethereum (opens in a new tab)
Staking
Muir Glacier
Résumé
Le fork Muir Glacier a retardé la . L'augmentation de la difficulté des blocs du mécanisme de consensus par preuve de travail (PoW) menaçait de dégrader l'utilisabilité d'Ethereum en augmentant les temps d'attente pour l'envoi de transactions et l'utilisation des dapps.
- Lire l'annonce de la Fondation Ethereum (opens in a new tab)
- Lire les explications des Ethereum Cat Herders (opens in a new tab)
- EIP-2384 – retarde la bombe de difficulté de 4 000 000 de blocs supplémentaires, soit environ 611 jours.
2019
Istanbul
Résumé
Le fork Istanbul :
- A optimisé le coût en de certaines actions dans l'EVM.
- A amélioré la résilience face aux attaques par déni de service.
- A rendu les solutions de mise à l'échelle de couche 2 basées sur les SNARK et les STARK plus performantes.
- A permis à Ethereum et Zcash d'interopérer.
- A permis aux contrats d'introduire des fonctions plus créatives.
Lire l'annonce de la Fondation Ethereum (opens in a new tab)
- EIP-152 – permet à Ethereum de fonctionner avec des monnaies préservant la confidentialité comme Zcash.
- EIP-1108 – cryptographie moins chère pour améliorer les coûts en .
- EIP-1344 – protège Ethereum contre les attaques par rejeu en ajoutant le code d'opération
CHAINID. - EIP-1884 – optimisation des prix en gaz des codes d'opération en fonction de la consommation.
- EIP-2028 – réduit le coût des données d'appel pour permettre plus de données dans les blocs – bénéfique pour la mise à l'échelle de couche 2.
- EIP-2200 – autres modifications du prix en gaz des codes d'opération.
Constantinople
Résumé
Le fork Constantinople :
- A réduit les récompenses de minage de bloc de 3 à 2 ETH.
- S'est assuré que la chaîne de blocs ne gèle pas avant que la preuve d'enjeu (PoS) ne soit implémentée.
- A optimisé le coût en de certaines actions dans l'EVM.
- A ajouté la capacité d'interagir avec des adresses qui n'ont pas encore été créées.
Lire l'annonce de la Fondation Ethereum (opens in a new tab)
- EIP-145 – optimise le coût de certaines actions onchain.
- EIP-1014 – vous permet d'interagir avec des adresses qui n'ont pas encore été créées.
- EIP-1052 – introduit l'instruction
EXTCODEHASHpour récupérer le hash du code d'un autre contrat. - EIP-1234 – s'assure que la chaîne de blocs ne gèle pas avant la preuve d'enjeu (PoS) et réduit la récompense de bloc de 3 à 2 ETH.
2017
Byzantium
Résumé
Le fork Byzantium :
- A réduit les récompenses de minage de bloc de 5 à 3 ETH.
- A retardé la d'un an.
- A ajouté la possibilité d'effectuer des appels ne modifiant pas l'état vers d'autres contrats.
- A ajouté certaines méthodes de cryptographie pour permettre la mise à l'échelle de couche 2.
Lire l'annonce de la Fondation Ethereum (opens in a new tab)
- EIP-140 – ajoute le code d'opération
REVERT. - EIP-658 – champ d'état ajouté aux reçus de transaction pour indiquer le succès ou l'échec.
- EIP-196 – ajoute la courbe elliptique et la multiplication scalaire pour permettre les ZK-Snarks.
- EIP-197 – ajoute la courbe elliptique et la multiplication scalaire pour permettre les ZK-Snarks.
- EIP-198 – active la vérification de signature RSA.
- EIP-211 – ajoute la prise en charge des valeurs de retour de longueur variable.
- EIP-214 – ajoute le code d'opération
STATICCALL, permettant des appels ne modifiant pas l'état vers d'autres contrats. - EIP-100 – modifie la formule d'ajustement de la difficulté.
- EIP-649 – retarde la d'un an et réduit la récompense de bloc de 5 à 3 ETH.
2016
Spurious Dragon
Résumé
Le fork Spurious Dragon a été la deuxième réponse aux attaques par déni de service (DoS) sur le réseau (septembre/octobre 2016), comprenant :
- l'ajustement de la tarification des codes d'opération pour prévenir de futures attaques sur le réseau.
- le désengorgement de l'état de la chaîne de blocs.
- l'ajout d'une protection contre les attaques par rejeu.
Lire l'annonce de la Fondation Ethereum (opens in a new tab)
- EIP-155 – empêche les transactions d'une chaîne Ethereum d'être rediffusées sur une chaîne alternative, par exemple une transaction d'un réseau de test rejouée sur la chaîne Ethereum principale.
- EIP-160 – ajuste les prix du code d'opération
EXP– rend plus difficile le ralentissement du réseau via des opérations de contrat coûteuses en calcul. - EIP-161 – permet la suppression des comptes vides ajoutés via les attaques DOS.
- EIP-170 – modifie la taille maximale du code qu'un contrat sur la chaîne de blocs peut avoir – à 24576 octets.
Tangerine Whistle
Résumé
Le fork Tangerine Whistle a été la première réponse aux attaques par déni de service (DoS) sur le réseau (septembre/octobre 2016), comprenant :
- la résolution des problèmes urgents de santé du réseau concernant les codes d'opération sous-évalués.
Lire l'annonce de la Fondation Ethereum (opens in a new tab)
- EIP-150 – augmente les coûts en gaz des codes d'opération pouvant être utilisés dans des attaques de spam.
- EIP-158 – réduit la taille de l'état en supprimant un grand nombre de comptes vides qui ont été placés dans l'état à très bas coût en raison de failles dans les versions antérieures du protocole Ethereum.
Fork DAO
Résumé
Le fork DAO a été réalisé en réponse à l'attaque de la DAO de 2016 (opens in a new tab) au cours de laquelle un contrat non sécurisé a été vidé de plus de 3,6 millions d'ETH lors d'un piratage. Le fork a déplacé les fonds du contrat défectueux vers un nouveau contrat (opens in a new tab) doté d'une seule fonction : le retrait. Toute personne ayant perdu des fonds pouvait retirer 1 ETH pour chaque 100 jetons DAO présents dans son portefeuille.
Cette ligne de conduite a été soumise au vote de la communauté Ethereum. Tout détenteur d'ETH pouvait voter via une transaction sur une plateforme de vote (opens in a new tab). La décision de procéder au fork a recueilli plus de 85 % des voix.
Certains mineurs ont refusé le fork car l'incident de la DAO n'était pas un défaut du protocole. Ils ont par la suite formé Ethereum Classic (opens in a new tab).
Lire l'annonce de la Fondation Ethereum (opens in a new tab)
Homestead
Résumé
Le fork Homestead était tourné vers l'avenir. Il comprenait plusieurs modifications du protocole et un changement de mise en réseau qui a donné à Ethereum la capacité d'effectuer d'autres mises à jour du réseau.
Lire l'annonce de la Fondation Ethereum (opens in a new tab)
2015
Dégel de Frontier
Résumé
Le fork de dégel de Frontier a levé la limite de 5 000 par et a fixé le prix du gaz par défaut à 51 . Cela a permis d'effectuer des transactions – les transactions nécessitent 21 000 gaz. La a été introduite pour garantir un futur hard fork vers la .
- Lire l'annonce de la Fondation Ethereum (opens in a new tab)
- Lire la mise à jour 1 du protocole Ethereum (opens in a new tab)
Frontier
Résumé
Frontier était une implémentation opérationnelle, mais minimaliste, du projet Ethereum. Elle a fait suite à la phase de test réussie d'Olympic. Elle était destinée aux utilisateurs techniques, en particulier aux développeurs. Les avaient une limite de de 5 000. Cette période de « dégel » a permis aux mineurs de démarrer leurs opérations et aux premiers adoptants d'installer leurs clients sans avoir à se précipiter.
Lire l'annonce de la Fondation Ethereum (opens in a new tab)
2014
Vente d'ether
L'ether a été officiellement mis en vente pendant 42 jours. Il était possible d'en acheter avec du BTC.
Lire l'annonce de la Fondation Ethereum (opens in a new tab)
Publication du Livre jaune
Le Livre jaune, rédigé par le Dr Gavin Wood, est une définition technique du protocole Ethereum.
Consulter le Livre jaune (opens in a new tab)
2013
Publication du livre blanc
Le document introductif, publié en 2013 par Vitalik Buterin, le fondateur d'Ethereum, avant le lancement du projet en 2015.
Livre blanc
Dernière mise à jour de la page : 6 juin 2026
