Lean Ethereum : la plus grande refonte d'Ethereum depuis The Merge

TL;DR

Le 4 juillet 2026, Vitalik a présenté Lean Ethereum comme la « troisième itération majeure » du protocole après The Merge, qui constitue une refonte susceptible de remplacer presque toutes les grandes briques du protocole en trois à quatre ans.

En pratique, Lean Ethereum ne représente pas une mise à jour unique, mais plutôt une trajectoire de long terme. Si l’on se fie à la Strawmap, le document de travail collectif publié par l’Ethereum Foundation en février dernier, 7 forks devraient composer la trajectoire d’Ethereum jusqu’en 2029.

Pour faire simple, l’idée centrale de Lean Ethereum est de simplifier en profondeur l’architecture du protocole. Après plus de dix ans d'accumulation technique, Ethereum cherche à reconstruire son cœur autour d'un nombre réduit de primitives cryptographiques, principalement fondées sur des fonctions de hachage et la vérification de preuves.

Parallèlement, les couches de consensus, de données et d'exécution seraient progressivement repensées afin de concilier finalité rapide, montée en charge, confidentialité et résistance aux ordinateurs quantiques.

Il faut comprendre que cette transition dépasse largement le cadre simple du remplacement des signatures. Effectivement, elle concerne les validateurs, les comptes, les engagements KZG des blobs ainsi que certains systèmes de preuve. Le défi quantique révèle ici une asymétrie avec Bitcoin, dans la mesure où Ethereum possède davantage de composants vulnérables, mais dispose aussi d’une capacité de coordination plus forte pour organiser leur remplacement.

Ainsi, la promesse de Lean Ethereum est autant ambitieuse que complexe, puisqu’elle consiste finalement à simplifier le protocole tout en y intégrant de nouvelles garanties de sécurité et de performance. Les primitives existent déjà en grande partie, mais leur intégration dans un réseau mondial, multi-clients et sécurisé en production demeure un défi conséquent. La Strawmap constitue ainsi un signal fort sur la direction à prendre pour Ethereum, mais encore faible sur le plan opérationnel.

---

De la Beam Chain à Lean Ethereum

L’origine de Lean Ethereum remonte à l’événement Devcon Bangkok, en novembre 2024, lorsque le chercheur Justin Drake présente la « Beam Chain », une refonte en profondeur de la couche de consensus d’Ethereum.

À cette époque, la Beacon Chain, lancée le 1er décembre 2020, reposait alors sur une architecture dont la spécification de base avait été figée cinq ans plus tôt. Les différents forks successifs l’ont progressivement faite évoluer sans remettre en cause ses fondations, tandis que les progrès de la recherche sur le consensus, le MEV et les preuves à divulgation nulle (ZK proofs) avaient progressivement fait apparaître de nouvelles possibilités.

La Beam Chain proposait justement de regrouper ces avancées dans une reconstruction cohérente, tout en résorbant une partie de la dette technique accumulée au fil des années.

Parmi les ruptures envisagées figurent entre autres un abaissement du minimum de staking de 32 à 1 ETH, des slots ramenés à quatre secondes et une finalité atteinte en trois slots avec la finalité en un seul slot comme horizon, et surtout l’intégration de signatures post-quantiques fondées sur des fonctions de hachage, compatibles avec une vérification efficace par preuves cryptographiques.

Le périmètre restait toutefois volontairement circonscrit. On se souvient que Justin Drake refusait alors l’appellation « Ethereum 3.0 », rappelant que la Beam Chain ne redessinait que la couche de consensus, et non la machine virtuelle ou la couche de données.

L'ambition s'élargit ensuite en juillet 2025, lorsqu'il étend cette démarche aux trois couches du protocole, consensus, données et exécution, chacune étant repensée depuis les premiers principes. À ce stade, deux objectifs structurent alors cette vision :

• Le premier, le « mode forteresse », consiste à faire d'Ethereum une infrastructure capable de survivre à tout, des États-nations aux ordinateurs quantiques.
• Le second, le « mode offensif », cherche à scaler simultanément le L1 et les blobs.

Dans cette approche, la cryptographie fondée sur des fonctions de hachage devient la fondation commune de cette stratégie, avec l'ambition d'améliorer à la fois les performances du protocole et sa résistance quantique.

Finalement, cette vision va se formaliser au début de l’année 2026. Élaborée comme point de départ lors d’un atelier de l’Ethereum Foundation en janvier, puis rendue publique par EF Protocol le 25 février, la Strawmap structure ces ambitions de long terme autour de cinq axes : un L1 plus rapide, un L1 « gigagas » visant environ 10 000 TPS, une capacité « teragas » correspondant à environ 1 Go de données par seconde pour les Layer 2 et, théoriquement, 10 millions de TPS, avec enfin un Layer 1 post-quantique et intégrant nativement de la confidentialité.

Les trois piliers y apparaissent comme les versions modernisées des composants actuels : Lean Consensus y est présenté comme une « Beacon Chain 2.0 » et héritier du projet Beam Chain, tandis que Lean Data est décrite comme l’itération des « blobs 2.0 », et enfin Lean Execution comme une « EVM 2.0 ».

Le fil conducteur reste le même, c’est-à-dire réduire le nombre de primitives critiques et les interactions complexes que les différentes implémentations clientes doivent reproduire sans divergence.

Discord OAK

Analyses de marché, alphas, données et discussions, réunis au même endroit.

---

Les trois piliers

Concrètement, Lean Ethereum décline la refonte du protocole autour de trois couches, à savoir consensus, données et exécution. Chacune répond à des contraintes différentes, mais pour autant toutes convergent vers une même fondation cryptographique. Cette architecture structure la Strawmap et met en évidence les dépendances qui doivent guider le déploiement des différentes briques

Lean Consensus

Le premier pilier reprend la vision initialement présentée sous le nom de Beam Chain, désormais intégrée à Lean Consensus. Son objectif est d’abaisser le délai de finalité d’une quinzaine de minutes à quelques secondes.

La finalité en trois slots reste encore une étape de recherche, tandis que les travaux les plus récents explorent Minimmit, un mécanisme capable de finaliser un bloc après une seule vague de votes, potentiellement autour de huit secondes.

En contrepartie, le seuil théorique de tolérance aux validateurs défaillants ou malveillants serait abaissé d’environ 33 % à 17 %. Les slots pourraient, eux, être ramenés à quatre secondes.

Pour l’utilisateur, le bénéfice recherché est assez simple : une transaction serait considérée comme définitivement finalisée en quelques secondes, contre une quinzaine de minutes aujourd’hui. Le consensus resterait organisé autour d’un validateur proposant le bloc et d’autres l’attestant, mais avec des cycles plus courts et des votes agrégés afin de ne pas saturer le réseau.

En pratique, trois grands changements viendraient restructurer cette refonte : le remplacement des signatures BLS par des signatures post-quantiques, une dissociation plus nette du rôle de ceux qui proposent les blocs de ceux qui les attestent, et enfin l’abaissement potentiel du minimum de staking de 32 à 1 ETH afin d’élargir la participation directe au réseau.

Cette couche s'appuierait également sur une nouvelle génération de protocoles pair-à-pair, notamment Gossipsub v2, capable d'absorber des slots plus courts et un nombre de validateurs plus élevé.

Lean Data

Le deuxième pilier, présenté comme la version « 2.0 » des blobs, concerne la disponibilité des données publiées sur Ethereum par les rollups. Son objectif est de remplacer progressivement les engagements KZG par des mécanismes résistants au quantique, fondés sur des fonctions de hachage.

Concrètement, lorsqu'un utilisateur effectue une transaction sur un rollup, celle-ci est agrégée avec d'autres, exécutée hors d'Ethereum, puis les données nécessaires à sa vérification sont publiées dans un blob. Avec PeerDAS, chaque validateur n'a plus besoin de télécharger l'intégralité de ces données, puisque chacun n'en récupère qu'une fraction afin de vérifier que l'ensemble reste bien disponible.

Lean Data ne vise donc pas à modifier directement le parcours de l’utilisateur ou la finalité du Layer 1. Effectivement, son objectif est plutôt d’augmenter la capacité des rollups sans imposer à chaque validateur de télécharger davantage de données. Par ailleurs, si l’offre de blobspace progresse plus rapidement que la demande, cette capacité supplémentaire pourrait également réduire les coûts des Layer 2.

La disponibilité des données est centrale pour leur sécurité, puisque sans accès aux transactions publiées, un optimistic rollup ne peut plus être vérifié ou contesté correctement. Même un zk-rollup, dont la preuve garantit la validité du calcul, peut devenir inutilisable si personne ne peut reconstruire son état. Une défaillance de la disponibilité des données ne casserait donc pas nécessairement le consensus d’Ethereum, mais elle pourrait bloquer ou fragiliser les Layer 2 qui dépendent de ses blobs.

Aujourd'hui, KZG repose sur un trusted setup, une cérémonie initiale générant des paramètres publics à partir d'un secret censé être détruit. Sa sécurité dépend ensuite de la difficulté du problème du logarithme discret, qui empêche théoriquement de retrouver ce secret à partir des paramètres publiés.

Un ordinateur quantique suffisamment puissant pourrait néanmoins retrouver le secret caché derrière ce setup, puis fabriquer de fausses preuves faisant passer pour disponibles et reconstructibles des données qui ne le sont pas en réalité.

Dans ce scénario, les validateurs pourraient alors considérer un blob comme disponible alors que ses données seraient en réalité irrécupérables, ce qui permettrait notamment de bloquer les rollups concernés. Le papier de Google Quantum AI classe ce scénario parmi les attaques dites “on-setup”, c’est-à-dire qu’une fois créé, l’exploit resterait utilisable jusqu’au remplacement du trusted setup.

Cette transition impose néanmoins un compromis. Les constructions hash-based envisagées, notamment celles reposant sur des arbres de Merkle et des protocoles de type FRI, ne disposent pas nativement de la linéarité des engagements et des preuves KZG.

Or cette propriété facilite la reconstruction et l’échantillonnage bidimensionnel des données. En cela, sa disparition pourrait imposer soit un DAS moins efficace, soit des engagements et des preuves supplémentaires produits par les builders.

Pour les rollups utilisant déjà une autre couche de disponibilité des données, comme Celestia, Lean Data n'aurait pas d'effet direct puisqu'ils ne dépendent pas du blobspace d'Ethereum.

En revanche, cette évolution pourrait renforcer la compétitivité d'Ethereum face aux couches de disponibilité alternatives, en augmentant la capacité du blobspace, en réduisant potentiellement son coût si l'offre progresse plus vite que la demande, et en remplaçant KZG par un système d'engagement post-quantique.

Lean Execution

Le troisième pilier vise à remplacer progressivement la réexécution systématique des transactions par la vérification de preuves.

Aujourd’hui, chaque nœud complet, par l’intermédiaire de son client d’exécution, rejoue les transactions afin de vérifier le nouvel état. Dans un modèle fondé sur les zkEVM, des acteurs spécialisés exécuteraient le bloc et produiraient une ou plusieurs preuves de sa validité, que les autres nœuds pourraient vérifier à un coût inférieur à la réexécution complète qu’ils effectuent aujourd’hui.

À terme, l’exécution pourrait reposer sur des preuves récursives fondées sur les fonctions de hachage et sur une machine beaucoup plus simple, conçue dès le départ pour générer efficacement ces preuves. RISC-V figure parmi les options étudiées, tandis que l’écosystème Lean explore également une architecture encore plus minimale, spécifiquement adaptée aux preuves.

L’EVM pourrait alors devenir une couche de compatibilité fonctionnant au-dessus de cette nouvelle base, plutôt que le moteur d’exécution du protocole.

À la refonte du moteur d’exécution s’ajoute celle de l’état qu’il manipule, que Vitalik présente comme probablement la partie la plus radicale du plan. Aujourd’hui, comptes, soldes, contrats et positions DeFi s’accumulent dans un même état que chaque nœud complet doit conserver et mettre à jour.

L’idée serait de contenir la croissance de cette couche tout en ajoutant de nouveaux types de stockage, plus contraints mais beaucoup plus extensibles, adaptés aux ERC-20, aux NFT et à une partie de la DeFi.

Dans le scénario évoqué pour 2030, Ethereum conserverait environ 2 To d'état classique, auxquels s'ajouteraient près de 100 To de ce nouveau stockage. Cette migration resterait facultative, mais les applications adaptées à cette nouvelle architecture pourraient voir le coût de certaines opérations divisé par plus de dix.

Enfin, la confidentialité devient elle aussi une contrainte transversale. Le mempool, les nouvelles structures d'état ainsi que les futurs composants du protocole devront être conçus dès l'origine pour accueillir des protocoles de confidentialité sans intermédiaire et résistants aux ordinateurs quantiques.

Un socle cryptographique commun

Les trois piliers convergent vers une même famille de primitives cryptographiques : des signatures fondées sur des fonctions de hachage pour remplacer les signatures BLS au consensus, des engagements du même type pour succéder à KZG dans la couche de données, et des zkVM fondées sur le hachage pour remplacer progressivement la réexécution des transactions par la simple vérification de preuves.

Pour les validateurs, la piste aujourd’hui privilégiée repose sur XMSS, un schéma qui organise des signatures à usage unique de type Winternitz au sein d’un arbre de Merkle. Ces signatures ne pouvant pas être agrégées directement comme les signatures BLS, elles seraient d'abord compressées à l'aide de preuves récursives avant d'être vérifiées par le protocole.

Le choix de la fonction de hachage reste toutefois ouvert. Poseidon2 a d’abord figuré parmi les principaux candidats en raison de son efficacité dans les circuits de preuve, mais les cryptanalyses récentes ont conduit les chercheurs à éviter toute dépendance à une fonction unique. L'approche privilégiée consiste désormais à concevoir une architecture suffisamment agile pour pouvoir remplacer une fonction de hachage par une autre si cela devenait nécessaire.

Dans les faits, cette vision réunit deux propriétés recherchées par Lean Ethereum. D'une part, elle ne repose plus sur les problèmes de logarithme discret vulnérables à l'algorithme de Shor. D'autre part, elle permet d'intégrer efficacement la vérification et l'agrégation des signatures au sein d'un même système de preuves.

Jusqu’où peut-on alléger le rôle des validateurs ?

Vitalik a esquissé une version plus radicale encore du consensus. Dans cette architecture, une grande partie des informations aujourd’hui conservées en permanence pour chaque validateur serait remplacée par des preuves périodiques produites par les validateurs eux-mêmes.

Concrètement, chaque validateur générerait régulièrement une preuve STARK attestant que l'évolution de son solde, compte tenu de sa participation au consensus, a bien été calculée depuis sa preuve précédente.

Cette approche pourrait réduire fortement la taille de l'état du consensus et permettre, en théorie, de supporter plusieurs millions de validateurs. Elle ne ferait toutefois pas disparaître tous les coûts dans la mesure où, avec un million de validateurs, les preuves quotidiennes représenteraient encore plus d'une centaine de STARKs par slot en moyenne, lesquelles devraient elles-mêmes être agrégées.

Cette proposition reste néanmoins exploratoire. Une approche intermédiaire consisterait à confier, à chaque slot, l'avancement de la blockchain à un comité aléatoire d'environ 256 validateurs, contre près de 30 000 appelés à attester aujourd'hui, tandis que l'ensemble du réseau continuerait de participer séparément au mécanisme de finalité.

Le principe rappelle celui d'Algorand, où de petits comités sont sélectionnés aléatoirement pour proposer et certifier les blocs. La comparaison a toutefois ses limites puisque dans cette architecture, le comité ne remplacerait pas l'ensemble des validateurs. Il servirait uniquement à faire progresser la blockchain à court terme, tandis que la finalité continuerait d'être assurée séparément par l'ensemble du réseau.

60 € de BTC offerts sur Bybit

Inscrivez-vous et déposez au moins 100 € dans les 4 jours pour recevoir le cadeau.

---

La migration post-quantique de la hiérarchie de confiance

Réduire Lean Ethereum à un simple remplacement de signatures serait trompeur. En réalité, la transition concerne une large partie de l’architecture cryptographique du protocole, chaque couche étant exposée à des risques différents.

Les signatures ECDSA des comptes et BLS utilisées par les validateurs reposent sur des courbes elliptiques, ce qui signifie qu’un ordinateur quantique exécutant l’algorithme de Shor pourrait dériver la clé privée à partir de la clé publique.

Les engagements KZG sont, eux, vulnérables à un double niveau : leur capacité à garantir qu'une preuve ne correspond qu'à un unique jeu de données, mais aussi le secret issu de leur trusted setup, qui pourrait être reconstitué. À cela s'ajoutent, à l'échelle de l'écosystème, les systèmes de preuve fondés sur des courbes elliptiques ainsi que les clés d'administration qui contrôlent certains Layer 2, bridges et contrats.

Vitalik identifie ainsi quatre grandes briques cryptographiques à remplacer : les signatures BLS utilisées par les validateurs, les engagements KZG, les signatures ECDSA des comptes et certains systèmes de preuve applicatifs.

Dans les faits, cette transition vers des alternatives post-quantiques doit être étalée sur plusieurs mises à jour. Les objectifs actuels visent l’achèvement des principales briques post-quantiques du Layer 1 vers 2029, tandis que la migration complète de la couche d’exécution et de l’écosystème devrait nécessiter plusieurs années supplémentaires.

Cette accélération s'explique également par l'évolution des estimations concernant les capacités des ordinateurs quantiques. Fin mars 2026, une étude de Google Quantum AI, coécrite notamment par Justin Drake et Dan Boneh, estimait qu'une courbe elliptique de 256 bits pourrait être compromise avec moins de 1 500 qubits logiques, soit moins de 500 000 qubits physiques dans l'architecture étudiée, un seuil environ vingt fois inférieur aux estimations précédentes.

D’ailleurs, Google s'est d'ailleurs fixé un objectif similaire à celui d’Ethereum, avec une migration de ses propres systèmes cryptographiques prévue à l'horizon 2029.

---

Ethereum et Bitcoin face au quantique : une asymétrie de coordination

Que ce soit pour Bitcoin ou pour Ethereum, la vulnérabilité fondamentale est commune : l’algorithme de Shor menace ECDSA et Schnorr sur Bitcoin de la même façon qu’ECDSA et BLS pèsent sur Ethereum. Pourtant, les deux réseaux n’exposent pas les mêmes composants et n’ont pas les mêmes difficultés de migration.

Dans le cas de Bitcoin, environ 6,7 millions de BTC se trouvent aujourd’hui dans des outputs dont la clé publique est déjà exposée, dont 1,7 million dans d’anciens scripts P2PK, en plus de ceux exposés via Taproot. À l’inverse, un utilisateur qui conserve ses BTC dans des outputs P2PKH ou P2WPKH sans réaliser de dépense évite l’exposition, mais cela ne sera plus le cas lorsqu’une dépense aura eu lieu.

Sur Ethereum, dès qu’un compte externe émet une transaction, sa clé publique devient durablement visible, sans possibilité de la masquer à nouveau à moins de tout simplement changer de compte. Parmi les 1 000 comptes les plus riches, ceux dont la clé publique est déjà visible concentrent à eux seuls environ 20,5 millions d’ETH, soit près de 17 % de l’offre totale.

Surtout, la vulnérabilité ne se concentre pas sur une seule catégorie d’actifs puisqu’elle traverse plusieurs couches du protocole et de son écosystème. Là où Bitcoin expose principalement certains UTXO et les transactions au moment de leur dépense, Ethereum fait face à une surface plus diffuse et plus systémique.

Par conséquent, Bitcoin a donc moins de briques cryptographiques à remplacer, mais doit encore parvenir à un accord sur la méthode et sur le sort des BTC qui ne migreront jamais. Les BIP-360 et BIP-361 proposent déjà des voies de transition, mais demeurent à ce stade de simples brouillons.

Ethereum possède davantage de composants vulnérables, mais a l’avantage d’avoir déjà intégré leur remplacement à une feuille de route coordonnée. En cela, l’avantage potentiel d’Ethereum sur ce terrain ne tient donc pas à une moindre exposition, mais plutôt à sa capacité à organiser la transition.

---

Glamsterdam : les premières briques de Lean Ethereum

La prochaine mise à jour du réseau Ethereum, Glamsterdam, attendue au second semestre 2026, ne livre ni Lean Consensus, ni une exécution entièrement fondée sur les STARKs, ni la cryptographie post-quantique. Elle prépare néanmoins le protocole au changement d’échelle recherché par Lean Ethereum

En pratique, deux propositions structurent ce fork. La première, EIP-7732, intègre directement au protocole la séparation entre proposeur et constructeur de blocs, une tâche aujourd’hui largement assurée par MEV-Boost et des relais externes.

En dissociant plus proprement la construction du bloc de sa validation tout en allongeant la fenêtre de propagation de deux à environ neuf secondes, ePBS permet d’absorber des blocs plus lourds sans ralentir le consensus. Ce dernier constitue une brique préparatoire pour Lean Ethereum, qui vise à augmenter fortement le débit tout en conservant des slots courts et une finalité rapide.

La seconde, EIP-7928, ajoute à chaque bloc une carte explicite des comptes et des portions d’état consultés ou modifiés. Grâce à cela, les nœuds peuvent alors précharger les données nécessaires et traiter en parallèle les transactions indépendantes. Les résultats finaux inclus dans cette liste permettent également certaines mises à jour de l’état sans qu’ils aient besoin de prendre en compte l’ensemble des transactions.

Cette structure prépare donc l’exécution parallèle et la réduction progressive de la réexécution visées par Lean Execution. Avec les repricings et les optimisations des clients, Glamsterdam doit ouvrir la voie à un relèvement du gas limit de 60 millions aujourd’hui vers environ 200 millions par bloc.

Glamsterdam prépare donc la capacité, la parallélisation et un pipeline de blocs plus scalable, tout en réduisant la dépendance aux relais. Le fork suivant, Hegotá, accueillera FOCIL, un mécanisme qui permet à plusieurs validateurs de contribuer simultanément aux transactions devant être incluses dans un bloc afin de renforcer la résistance à la censure. Initialement envisagé pour Glamsterdam, FOCIL en a été retiré pour maintenir un périmètre de test maîtrisable.

Selon Vitalik, ce fork sera probablement le dernier présentant un caractère encore largement « pré-Lean ». Ainsi, à partir du fork suivant, provisoirement nommé I*, les mises à jour devraient adopter beaucoup plus directement cette architecture.

Note : I désigne le premier fork pleinement orienté Lean après Hegotá. L* correspondrait, plusieurs mises à jour plus tard, au déploiement groupé de Lean Consensus.*

---

Le vrai risque : l’intégration

En réalité, la principale fragilité de Lean Ethereum ne réside pas dans un grand fork monolithique, mais plutôt dans un graphe de dépendances. Certaines briques ne pourront être livrées que lorsque les primitives cryptographiques, les zkVM, le réseau pair-à-pair et plusieurs implémentations clientes auront simultanément atteint un niveau de maturité suffisant. Un retard sur l’un de ces fronts peut donc se propager aux autres.

La couche de consensus constitue un cas particulier : alors que la refonte s’étale sur sept forks, plusieurs composantes majeures de Lean Consensus pourraient être regroupées dans un fork dédié, provisoirement désigné L*, concentrant davantage le risque sur une même échéance.

En principe, les fondations technologiques existent déjà, les STARKs et les signatures fondées sur des fonctions de hachage sont déjà fonctionnelles. Le problème repose plutôt sur leur intégration dans un protocole mondial, multi-client et soumis à de fortes contraintes : preuves en temps réel, récursion à grande échelle, agrégation massive de signatures, slots plus courts et un coût matériel qui doit rester compatible avec la décentralisation.

L’écart se joue désormais moins sur la vitesse brute (les zkVM de tête prouvent déjà 99 % des blocs en moins de dix secondes) que sur la fiabilité et l’accessibilité du système : il faut des preuves suffisamment sûres, compactes, faciles à vérifier et produites sur du matériel qui ne réserve pas cette fonction à quelques acteurs spécialisés. C’est ce qui justifie les étapes intermédiaires évoquées plus haut : clients ZK optionnels, preuves indépendantes et agrégation progressive hors chaîne.

Cette ambition intervient enfin au moment où l’Ethereum Foundation resserre ses moyens. Rappelons que son budget pour l’année 2026 a été réduit d’environ 40 % et que 54 postes ont été supprimés dans la foulée. Vitalik a affirmé que les ambitions techniques de la Strawmap restaient intactes, mais la question de la capacité d’exécution gagne en légitimité.

Aussi, cette tension alimente un désaccord public sur le calendrier. Dankrad Feist, ancien chercheur à l’Ethereum Foundation (désormais chez Tempo), juge par exemple l’horizon de trois à quatre ans trop lent et appelle à déployer tout cela en un an seulement, notamment grâce aux LLM.

D’ailleurs, sur ce point, la Strawmap précise explicitement que ses échéances reposent sur une hypothèse de développement principalement humain, ce qu’un processus accéléré par l’IA pourrait comprimer.

---

Ethereum et Solana : deux refontes, deux philosophies

Le 16 juillet, Solana a publié une première version alpha d’Agave 4.3, la branche qui doit amorcer le passage des validateurs vers Alpenglow, la refonte profonde de son système de consensus. Au moment où Ethereum formalise Lean, l’autre grand Layer 1 généraliste cherche donc lui aussi à reconstruire ses fondations, mais selon une logique très différente.

Pour contextualiser, rappelons que Solana et Ethereum sont nés de choix presque opposés. Effectivement, Solana a été conçue pour concentrer l’exécution, la disponibilité des données et le consensus sur un Layer 1 très performant, tout cela en s’appuyant sur des machines plus puissantes et une montée en charge verticale.

Au contraire, Ethereum a davantage cherché à préserver le solo staking sur du matériel relativement accessible, en privilégiant la diversité des clients et la neutralité crédible du protocole tout en déportant une part significative de l’exécution vers les rollups.

Finalement, les deux réseaux cherchent désormais à corriger les limites de leur architecture initiale. Avec Alpenglow, Solana remplace son consensus historique et retire notamment son Proof of History ainsi que les votes publiés directement dans les blocs dans l’optique de simplifier le protocole et de réduire fortement la latence. Ethereum, à travers Lean, cherche à augmenter la capacité et la vitesse du Layer 1, mais par la compression cryptographique en remplaçant progressivement la réexécution par la vérification de preuves.

Ainsi, l’objectif de Lean Ethereum est d’obtenir une finalité rapide, davantage de capacité et une meilleure expérience utilisateur sans augmenter proportionnellement les exigences matérielles imposées aux validateurs, tout en ajoutant des briques de confidentialité et de résistance quantique.

Au final, le véritable défi se trouvera surtout au niveau de la capacité d’exécution. Lean doit résorber une partie de la dette technique accumulée en dix ans, tout en ajoutant temporairement de nouvelles dépendances, au moment où l’Ethereum Foundation fonctionne avec 54 collaborateurs de moins.

Devenir Premium

Débloquez l'ensemble de nos analyses et obtenez l'info utile, au bon moment.