Ethereum promet depuis des années de faire tourner ses clients sans stocker des centaines de gigaoctets d’état. La solution technique derrière cette promesse porte un nom qui prête à confusion avec l’existant : l’arbre de Verkle. Pendant que l’arbre de Merkle sécurise Bitcoin, Git, IPFS et la transparence des certificats depuis des décennies, son cousin plus jeune promet des preuves jusqu’à 23 fois plus légères. Mais en septembre 2026, ce cousin n’a toujours pas mis un pied sur le mainnet Ethereum, et la feuille de route a changé de direction. Ce comparatif détaille la structure, les preuves de performance, les coûts réels et l’état d’avancement des deux technologies, pour aider les équipes techniques à choisir la bonne base cryptographique pour leurs projets.
Cette question s’inscrit dans le fil plus large de notre couverture de la cryptographie : le sujet dépasse largement le seul cas d’Ethereum. Toute équipe qui conçoit une base de données distribuée, un système de preuve d’inclusion ou un protocole de synchronisation doit un jour trancher entre la simplicité éprouvée du hachage et la compacité séduisante des engagements vectoriels. Les deux approches ne s’excluent pas nécessairement, mais elles imposent des compromis très différents en matière de confiance, de calcul et de résistance aux futures attaques quantiques, ce qui justifie de les comparer point par point plutôt que de trancher sur la seule promesse marketing d’un chiffre de réduction.
Qu’est-ce qu’un arbre de Merkle ?
Ralph Merkle a déposé le concept dans un brevet en 1979, à une époque où personne ne pensait encore aux blockchains. L’idée d’origine visait déjà un problème très concret : authentifier une grande quantité de données sans avoir à les transmettre ou à les stocker intégralement. Un arbre de Merkle est une structure de données authentifiée basée sur le hachage. Chaque nœud parent contient le hachage de la concaténation de ses deux enfants, jusqu’à obtenir une racine unique qui engage cryptographiquement l’ensemble des données. Pour prouver qu’une feuille appartient à l’arbre, il suffit de fournir la valeur de la feuille, puis le hachage voisin à chaque niveau de l’arbre jusqu’à la racine. Pour un arbre binaire équilibré contenant n feuilles, une preuve nécessite environ log2(n) hachages. Avec des empreintes de 32 octets, une preuve pour 2^20 feuilles (soit un peu plus d’un million d’éléments) pèse environ 640 octets avant sérialisation.
L’état d’Ethereum ne repose pas sur un simple arbre binaire mais sur un Merkle Patricia Trie, une variante qui combine chemins hachés, nœuds de branche et nœuds d’extension pour représenter comptes et emplacements de stockage. Cette complexité supplémentaire alourdit les preuves : un bloc peut toucher de nombreuses entrées d’état, et chaque chemin expose plusieurs encodages de nœuds. C’est précisément ce goulot d’étranglement que l’arbre de Verkle cherche à résoudre.
Qu’est-ce qu’un arbre de Verkle ?
Verkle est un mot-valise formé de « vector commitment » (engagement vectoriel) et de « Merkle tree ». L’idée reste proche de l’arbre de Merkle, mais chaque nœud interne, au lieu de stocker un simple hachage de ses enfants, contient un engagement cryptographique sur un vecteur de valeurs. Un nœud peut ainsi engager 256 enfants ou plus au lieu de seulement deux, ce qui réduit fortement la profondeur de l’arbre et donc le nombre d’éléments à fournir dans une preuve.
Dans la conception proposée pour Ethereum, une clé de 32 octets se divise en un « stem » de 31 octets et un suffixe d’un octet, ce qui permet à un nœud d’extension de représenter jusqu’à 256 enfants indexés par suffixe. La différence fondamentale avec Merkle tient à l’agrégation : là où une preuve Merkle fournit un hachage frère à chaque niveau parcouru, une preuve Verkle fournit des ouvertures d’engagement vectoriel capables d’authentifier plusieurs valeurs liées avec beaucoup moins de données répétées. Deux familles d’engagements polynomiaux sont utilisées dans les implémentations étudiées : KZG (Kate-Zaverucha-Goldberg) et IPA (Inner Product Argument), chacune avec ses propres compromis détaillés plus bas.
Arbre de Merkle vs arbre de Verkle : le tableau comparatif
Le tableau suivant résume les différences structurelles entre les deux approches, sur la base des spécifications publiées par Ethereum.org et des travaux de recherche cités dans cet article.
| Propriété | Arbre de Merkle | Arbre de Verkle |
|---|---|---|
| Origine | Ralph Merkle, brevet de 1979 | Recherche Ethereum, concept popularisé à partir de 2018 |
| Brique cryptographique | Fonction de hachage (SHA-256, Keccak, BLAKE3…) | Engagement vectoriel sur courbe elliptique (KZG ou IPA) |
| Contenu d’une preuve | Hachages des nœuds frères à chaque niveau | Ouvertures d’engagements polynomiaux |
| Facteur de branchement typique | 2 pour un arbre binaire, variable pour un Patricia Trie | Jusqu’à 256 enfants par nœud |
| Taille de preuve pour un compte Ethereum | ≈ 3 Ko (Merkle Patricia Trie) | ≈ 200 octets |
| Témoin pour 1 000 feuilles | ≈ 3,5 Mo (estimation Ethereum.org) | ≈ 150 Ko (estimation Ethereum.org) |
| Cérémonie de confiance requise | Non | Oui pour KZG, non pour IPA |
| Résistance post-quantique de l’engagement | Oui, dépend uniquement du hachage | Non, repose sur le logarithme discret elliptique |
| Statut sur le mainnet Ethereum (28 sept. 2026) | En production depuis 2015 | Testnets uniquement, non déployé |
| Direction 2026 privilégiée par Ethereum | Arbre binaire de hachage + preuves STARK (EIP-7864) | Toujours listé comme fonctionnalité possible, sans date ferme |
| Maturité d’implémentation | Des décennies d’audits en production | Bibliothèques expérimentales, benchmarks académiques |
| Complexité d’implémentation client | Faible à modérée | Élevée, nécessite arithmétique sur courbes et gestion de preuves |
La taille des preuves, l’argument central de Verkle
L’argument de vente de l’arbre de Verkle tient en un chiffre : la réduction de la taille des témoins nécessaires pour valider un bloc sans stocker tout l’état. Selon la page de documentation officielle d’Ethereum.org consacrée à la validation sans état, un témoin Merkle Patricia Trie pour 1 000 feuilles pèse environ 3,5 Mo, contre environ 150 Ko pour l’équivalent Verkle, soit une réduction d’environ 23 fois. Pour une preuve de compte isolée, l’écart passe de 3 Ko à 200 octets, soit une division par 10 à 20 selon la source consultée.
Sur un jeu de données à l’échelle du milliard d’entrées, la documentation Ethereum et l’académie Bit2Me convergent vers une estimation simplifiée : un arbre de Merkle produirait des preuves de plusieurs kilo-octets par élément, quand l’équivalent Verkle resterait sous les 150 octets. Ces chiffres dépendent fortement de la largeur de l’arbre, du schéma d’engagement retenu et de la sérialisation utilisée, ce qui explique pourquoi ils sont présentés comme des ordres de grandeur représentatifs plutôt que des constantes universelles du protocole.
| Scénario | Preuve côté Merkle | Preuve côté Verkle | Réduction approximative |
|---|---|---|---|
| Preuve de compte Ethereum | ≈ 3 Ko | ≈ 200 octets | 10 à 20x |
| Témoin pour 1 000 feuilles/comptes | ≈ 3,5 Mo | ≈ 150 Ko | ≈ 23x |
| Élément dans un jeu d’un milliard d’entrées | Plusieurs Ko (estimation simplifiée) | < 150 octets | Un ordre de grandeur |
| Élément d’engagement KZG isolé | N/A | ≈ 48 octets (point de courbe) | – |
| Preuve IPA sans cérémonie de confiance | N/A | Plusieurs points de 32 octets, croissance en 2·log2(n) | – |
La formulation la plus défendable, reprise des sources Ethereum.org et Spark, tient en une phrase : l’arbre de Verkle peut réduire la taille des témoins de type état Ethereum d’environ 90 % ou plus par rapport à l’arbre de Merkle actuel, mais la comparaison exacte dépend toujours du scénario d’accès mesuré.
Benchmarks : génération et vérification des preuves
La preuve de performance la plus solide disponible en 2025-2026 provient d’un papier académique publié en avril 2025 et intitulé Towards Stateless Clients in Ethereum: Benchmarking Verkle Trees and Binary Merkle Trees with SNARKs. Ses résultats sont qualitatifs mais éclairants pour comparer les deux approches sur un même banc d’essai.
| Indicateur mesuré | Arbre de Merkle habillé en SNARK | Arbre de Verkle |
|---|---|---|
| Génération de la preuve | Lente | De l’ordre de quelques secondes |
| Vérification de la preuve | Constante et rapide | De l’ordre de quelques secondes dans l’implémentation testée |
| Taille de la preuve produite | Variable selon le SNARK enveloppant | De l’ordre du mégaoctet dans la configuration testée |
Ce résultat surprend souvent les développeurs qui n’ont retenu que les chiffres de taille de témoin cités plus haut. Un témoin Verkle peut être minuscule une fois calculé, mais le calcul lui-même, quand il passe par une couche SNARK pour la validation stateless, reste coûteux dans l’implémentation testée par les chercheurs. À l’inverse, les arbres de Merkle habillés en SNARK souffrent d’une génération de preuve lente, tout en conservant une vérification rapide et constante, un héritage direct des propriétés bien connues des systèmes de preuve à vérification succincte. Aucune des deux sources ne fournit de chiffre universel du type « la vérification Verkle prend X millisecondes contre Y pour Merkle », et tout article technique sérieux devrait éviter de généraliser un résultat mesuré sur une seule implémentation.
Deux autres sources complètent ce tableau. Le dépôt GitHub jsign/vkt-proof-bench mesure spécifiquement les performances de génération et de vérification pour les preuves Verkle basées sur des arguments à produit interne (multiproofs et IPA), tandis que la page officielle de performance de l’équipe Keccak documente les débits comparatifs des fonctions de hachage utilisées dans les constructions Merkle classiques. Ensemble, ces trois sources, le papier académique, le dépôt de benchmarks et la documentation Ethereum.org, donnent une image cohérente : Verkle gagne nettement sur la taille, Merkle garde l’avantage sur la simplicité et la rapidité brute de vérification quand aucune couche SNARK n’est ajoutée.
Une précaution méthodologique s’impose pour quiconque cite ces chiffres. La base de mesures eBACS/SUPERCOP, référence académique pour les fonctions de hachage candidates à SHA-3, publie ses résultats sous forme de premier quartile, médiane et troisième quartile plutôt que sous la forme d’une valeur unique, précisément parce que les débits varient fortement d’une machine et d’une implémentation à l’autre. La même prudence s’applique aux benchmarks Verkle : un chiffre de « X secondes par preuve » n’a de sens que rapporté au processeur, à la bibliothèque cryptographique et à la taille du vecteur engagé utilisés lors du test.
Coûts d’implémentation et d’exploitation
Comparer le « prix » de deux structures de données cryptographiques ne se fait pas en euros mais en charge de calcul, en stockage et en risque d’audit. Voici comment les deux approches se comparent sur les postes qui pèsent réellement sur le budget d’une équipe d’infrastructure blockchain.
| Poste de coût | Arbre de Merkle (+ direction STARK 2026) | Arbre de Verkle (KZG ou IPA) |
|---|---|---|
| Cérémonie de confiance | Aucune | Requise pour KZG, aucune pour IPA |
| Coût de calcul par preuve | Élevé quand un SNARK enveloppe la structure | De l’ordre de quelques secondes par preuve dans le benchmark testé |
| Coût de vérification | Rapide et constant | De l’ordre de quelques secondes dans le benchmark testé |
| Stockage côté client (témoin) | Élevé, plusieurs Ko à Mo par accès | Réduit de 10 à 23 fois selon le scénario |
| Maturité et coût d’audit | Faible, des décennies de retours en production | Élevé, conception plus récente nécessitant des audits supplémentaires |
| Risque de migration pour un protocole existant | Nul, structure déjà en place | Élevé, changement de structure d’état et repricing du gas |
Le poste le plus souvent sous-estimé est la cérémonie de confiance. Un engagement KZG nécessite une chaîne de référence structurée générée une fois pour toutes, avec une hypothèse de sécurité forte : au moins un participant doit avoir détruit son secret. Une variante IPA évite cette contrainte, au prix de preuves un peu plus grandes qui croissent de façon logarithmique avec la taille du vecteur engagé. Ce choix technique a un coût organisationnel réel, distinct du coût purement algorithmique mesuré en mégaoctets ou en secondes de calcul.
Un dernier poste de coût, rarement chiffré mais bien réel, concerne le recrutement et la formation. Implémenter et auditer un arbre de Merkle demande une compétence répandue : la manipulation de fonctions de hachage figure dans le socle de base de toute formation en cryptographie appliquée. Auditer un schéma d’engagement KZG ou IPA exige en revanche une expertise en arithmétique de courbes elliptiques et en couplages bilinéaires, un profil plus rare et donc plus coûteux à recruter ou à faire monter en compétence sur un projet critique.
Où en est Ethereum en 2026 sur les arbres de Verkle ?
La feuille de route publique d’Ethereum, mise à jour au 24 septembre 2026, décrit toujours les arbres de Verkle comme une technologie liée à la validation sans état. Des testnets Verkle tournent, mais un travail client important reste nécessaire avant tout déploiement en production. Le statut le plus honnête à ce jour se résume ainsi : non déployé sur le mainnet, non clairement abandonné comme piste de recherche, mais retardé comme implémentation immédiate de The Verge au profit d’une direction concurrente.
Cette direction concurrente porte un nom précis : EIP-7864, qui propose un arbre binaire unifié combiné à des preuves ZK, en particulier de type STARK. Selon plusieurs analyses publiées en 2026, dont celle de Kucoin sur la feuille de route Ethereum, l’état vérifié par zero-knowledge remplacerait le Merkle Patricia Trie classique, et le hachage Keccak-256 actuellement utilisé serait remplacé par une fonction algébrique adaptée aux preuves, comme Poseidon ou Poseidon2 (un chantier que nous détaillons dans notre article sur l’abandon de Poseidon par Ethereum au profit de BLAKE3). Cette transition reste une direction de conception documentée, pas un fait accompli sur le mainnet.
Le raisonnement derrière ce pivot tient en un mot : le post-quantique. Les engagements Verkle basés sur courbes elliptiques, qu’ils utilisent KZG ou IPA, restent exposés à un ordinateur quantique suffisamment puissant. Un arbre binaire combiné à des preuves STARK repose sur des hypothèses essentiellement fondées sur le hachage, jugées plus compatibles avec un futur post-quantique. Une mise à jour ultérieure de 2026, surnommée Hegotá et prévue pour le second semestre selon les analyses de Galaxy Research, continue de lister les arbres de Verkle comme une fonctionnalité possible, sans date ferme, aux côtés de FOCIL et de l’abstraction de compte native.
Ce glissement de calendrier n’a rien d’inhabituel pour un changement aussi profond de la structure d’état. D’anciennes feuilles de route indépendantes tablaient sur un déploiement Verkle en testnet dès le troisième trimestre 2025, suivi d’une bascule mainnet et d’une première phase d’exécution sans état dès la fin de la même année. La réalité de septembre 2026 montre un calendrier plus prudent : les testnets existent bien, mais la priorité protocolaire s’est déplacée vers une conception jugée plus pérenne sur le plan cryptographique, quitte à repousser encore la date de mise en production.
Cas d’usage réels aujourd’hui
L’arbre de Merkle n’a pas attendu Ethereum pour prouver sa valeur, et il continue d’équiper des systèmes que des milliards d’utilisateurs croisent chaque jour sans le savoir.
- Bitcoin calcule une racine de Merkle pour chaque bloc, ce qui permet de vérifier qu’une transaction fait partie d’un bloc sans télécharger toutes les transactions.
- Ethereum utilise historiquement un Merkle Patricia Trie pour l’état des comptes, le stockage des contrats et les racines de bloc, une conception antérieure à toute discussion sur Verkle.
- La transparence des certificats (Certificate Transparency) repose sur des arbres de hachage Merkle en ajout seul pour prouver l’inclusion et la cohérence d’un journal public de certificats TLS.
- Git organise sa base d’objets comme un graphe orienté acyclique adressé par hachage, une parenté directe avec la logique Merkle.
- IPFS adresse son contenu via des structures de type Merkle-DAG, où chaque bloc de données référence ses enfants par leur hachage.
- Apache Cassandra utilise des arbres de Merkle pour la réparation anti-entropie entre répliques.
- Amazon DynamoDB s’est appuyé sur des techniques de synchronisation et de réconciliation inspirées des arbres de Merkle.
Côté Verkle, l’activité documentée reste concentrée sur la recherche. Les testnets Ethereum constituent le terrain d’expérimentation principal, complétés par du matériel pédagogique comme celui disponible sur Verkle.info, ainsi que par des dépôts de code expérimentaux et des dépôts de benchmarks, à l’image de jsign/vkt-proof-bench ou de pranavjangir/verkle-trees-cpp sur GitHub. Certaines affirmations selon lesquelles Polkadot utiliserait des arbres de Verkle en production méritent d’être nuancées : l’écosystème a exploré les engagements vectoriels et les techniques de preuve d’état, sans que cela n’établisse un déploiement de production confirmé à ce jour.
Exemple concret : à quoi ressemble une vérification de preuve
Pour rendre la différence tangible, voici la logique de vérification d’une preuve Merkle classique sous forme de pseudocode. Le vérifieur ne reçoit jamais l’arbre entier, seulement la feuille, son index et la liste des hachages frères jusqu’à la racine.
function verifierPreuveMerkle(feuille, index, hachagesFreres, racineAttendue) {
let hachageCourant = hash(feuille);
for (const frere of hachagesFreres) {
if (index % 2 === 0) {
hachageCourant = hash(hachageCourant + frere);
} else {
hachageCourant = hash(frere + hachageCourant);
}
index = Math.floor(index / 2);
}
return hachageCourant === racineAttendue;
}Une vérification Verkle suit la même intention (prouver qu’une valeur appartient à l’état engagé par la racine) mais remplace la boucle de hachages frères par l’ouverture d’un engagement polynomial. Le vérifieur reçoit l’engagement du nœud, la valeur revendiquée à une position donnée et une preuve d’ouverture (KZG ou IPA), puis exécute une vérification cryptographique sur courbe elliptique au lieu d’une simple concaténation suivie d’un hachage. La complexité de code augmente sensiblement, ce qui explique pourquoi la plupart des équipes s’appuient sur des bibliothèques spécialisées plutôt que de réimplémenter ce calcul elles-mêmes.
Hypothèses cryptographiques : hachage contre engagements polynomiaux
La sécurité d’un arbre de Merkle repose entièrement sur la fonction de hachage choisie : résistance aux collisions, résistance à la seconde préimage et résistance à la préimage selon l’usage. Pour un hachage de 256 bits comme SHA-256 ou Keccak-256, ces propriétés sont considérées comme solides à l’échelle classique, avec des marges de sécurité bien documentées par des décennies d’analyse publique. Notre tutoriel sur l’implémentation d’un arbre de Merkle avec BLAKE3 détaille concrètement comment choisir et implémenter cette brique de hachage.
KZG : preuves compactes, confiance requise
Les engagements KZG reposent sur la sécurité d’un groupe de courbe elliptique, l’hypothèse du logarithme discret, des couplages bilinéaires et une chaîne de référence structurée issue d’une cérémonie de confiance. Un engagement KZG tient en un point de courbe compact, généralement 48 octets, et supporte des ouvertures de taille constante, ce qui explique la compacité extrême des preuves Verkle basées sur ce schéma.
IPA : pas de cérémonie, preuves plus grandes
Les engagements de type argument à produit interne évitent la cérémonie de confiance propre à KZG, mais reposent toujours sur des hypothèses de logarithme discret et sur des opérations de groupe elliptique. Leur taille de preuve croît de façon logarithmique avec la dimension du vecteur engagé, ce qui reste compact sans atteindre la constance de KZG. Le modèle de confiance diffère donc fondamentalement, mais la dépendance à la courbe elliptique persiste dans les deux cas.
Résistance post-quantique : l’angle mort de Verkle
Oui, les engagements Verkle basés sur courbe elliptique sont vulnérables en principe à un ordinateur quantique suffisamment puissant. La faiblesse ne vient pas de la structure arborescente elle-même, qui reste un simple mécanisme d’agrégation, mais des schémas KZG et IPA sous-jacents, qui dépendent tous deux de l’hypothèse du logarithme discret sur courbe elliptique. Un algorithme de Shor exécuté sur un ordinateur quantique suffisamment large casserait cette hypothèse, le même type de menace que nous détaillons dans notre comparatif ML-KEM vs RSA/ECDH pour TLS 1.3.
Les arbres de Merkle basés sur le hachage s’en sortent structurellement mieux face à cette menace. L’algorithme de Grover offre une accélération quadratique pour la recherche de préimage, ce qui réduit approximativement la sécurité de 2^256 à 2^128, un niveau encore jugé confortable pour les décennies à venir avec des paramètres bien choisis. C’est précisément cette différence d’exposition qui a pesé dans la décision d’Ethereum de privilégier un arbre binaire combiné à des preuves STARK plutôt qu’un déploiement Verkle généralisé : les preuves STARK reposent principalement sur des fonctions de hachage et des composants de preuve interactive algébrique, plutôt que sur un logarithme discret elliptique (voir notre comparatif zk-SNARK vs zk-STARK pour le détail de ces familles de preuves).
Le compromis se résume en trois lignes. Verkle avec KZG offre des preuves très compactes, au prix d’une cérémonie de confiance et d’une exposition post-quantique. Verkle avec IPA évite la cérémonie de confiance, mais conserve la même exposition et des preuves plus grandes. Merkle combiné à des preuves STARK reste davantage orienté hachage et donc mieux positionné pour le post-quantique, au prix d’une génération de preuve potentiellement coûteuse et d’une complexité d’ingénierie non négligeable.
Guide de migration pour une équipe technique
Aucune équipe ne migre un système de production vers Verkle du jour au lendemain, d’autant qu’Ethereum lui-même n’a pas encore franchi ce cap sur son mainnet. La bonne nouvelle, c’est que le protocole sert justement de cas d’école : chaque étape de sa propre feuille de route, des testnets à la coexistence hybride en passant par le repricing du gas, offre un modèle réutilisable pour n’importe quel système propriétaire qui voudrait suivre la même trajectoire sans répéter les mêmes erreurs. Voici la démarche que suivent les équipes qui évaluent sérieusement une transition vers des structures d’état sans état (stateless).
- Auditer l’usage actuel de votre trie ou de votre arbre de Merkle : quels access patterns génèrent les témoins les plus lourds ?
- Mesurer la taille réelle des témoins produits par votre charge de travail, plutôt que de vous fier aux ratios génériques cités dans cet article.
- Tester vos structures de données sur un testnet ou un devnet Verkle existant avant tout engagement de calendrier.
- Comparer le coût de calcul d’une preuve Verkle sur votre matériel avec le coût actuel de vérification Merkle, en particulier si une couche SNARK ou STARK s’ajoute par-dessus.
- Choisir entre KZG et IPA en fonction de votre tolérance à une cérémonie de confiance et de votre budget de taille de preuve.
- Prévoir une période de transition hybride, où l’ancien et le nouveau format d’état coexistent, comme Ethereum l’envisage pour son propre changement d’état.
- Anticiper un repricing du gas ou des ressources de calcul associées à la nouvelle structure, car les coûts actuels sont calibrés sur l’arbre existant.
- Mettre à jour les clients et outils tiers qui inspectent directement l’état, un point qu’Ethereum identifie lui-même comme un chantier de travail client substantiel encore ouvert.
Avantages et inconvénients
Arbre de Merkle
- Simple à implémenter et à auditer, avec des décennies de retour d’expérience en production.
- Ne dépend que d’une fonction de hachage, donc mieux positionné face à la menace quantique.
- Aucune cérémonie de confiance requise.
- Preuves et témoins plus volumineux pour les accès à grande échelle ou multiples.
- Le Merkle Patricia Trie d’Ethereum ajoute une complexité d’encodage qui alourdit encore les témoins.
Arbre de Verkle
- Témoins jusqu’à 23 fois plus légers pour des scénarios de type état Ethereum.
- Facteur de branchement large, donc profondeur d’arbre réduite.
- Ouvre la voie à des clients réellement sans état.
- Repose sur des hypothèses de courbe elliptique vulnérables au calcul quantique.
- KZG impose une cérémonie de confiance, IPA produit des preuves plus grandes.
- Génération de preuve mesurée de l’ordre de la seconde dans le benchmark académique disponible, un coût non négligeable selon le cas d’usage.
- Encore au stade testnet sur Ethereum, sans date de déploiement mainnet confirmée.
5 recommandations selon votre cas d’usage
- Journal d’audit ou registre en ajout seul (transparence des certificats, journalisation) : restez sur un arbre de Merkle classique, la structure a fait ses preuves et ne nécessite pas de preuves d’ouverture compactes.
- Synchronisation entre répliques de base de données (type Cassandra ou DynamoDB) : l’arbre de Merkle reste le standard, aucun avantage pratique à migrer vers Verkle pour ce cas d’usage.
- Système de fichiers distribué ou stockage adressé par contenu (type IPFS) : conservez une structure Merkle-DAG, la compacité de preuve n’est pas le facteur limitant ici.
- Rollup ou zkEVM cherchant à réduire la taille de ses témoins de preuve : testez dès maintenant les engagements vectoriels sur un devnet, mais prévoyez un plan de repli basé sur le hachage compte tenu de l’incertitude post-quantique.
- Nouveau protocole conçu en 2026 avec un horizon de sécurité à long terme : privilégiez une direction arbre binaire plus preuves STARK plutôt qu’un engagement ferme sur KZG ou IPA, en cohérence avec le pivot documenté d’Ethereum.
- Client léger ou portefeuille mobile visant une vérification minimale : suivez de près les testnets Verkle et EIP-7864, mais ne bâtissez pas une dépendance de production sur une technologie encore non déployée sur le mainnet Ethereum.
Ce que dit l’écosystème Ethereum
La documentation officielle d’Ethereum reste la source la plus directe pour comprendre l’intention derrière les arbres de Verkle. Sur son blog, l’Ethereum Foundation résume la logique de la structure ainsi : “Verkle trees are a commitment scheme that works similar to a Merkle tree, but has much smaller witnesses.” (source). En clair, l’objectif n’a jamais été de remplacer la logique d’authentification de Merkle, mais de réduire drastiquement le poids des témoins qu’elle produit.
La documentation de la feuille de route officielle va plus loin sur la finalité du projet : “Verkle trees are a critical step on the path to stateless Ethereum clients.” (source). Elle précise également ce que recouvre concrètement l’idée de client sans état : “Stateless clients are ones that do not have to store the entire state database in order to validate incoming blocks.” (source). Ethereum.org décrit aussi le résultat final attendu pour l’utilisateur d’un nœud : “With Verkle trees there is no need to have the state stored on your hard drive; everything you need to verify a block is contained within the block itself.” (source).
Un point mérite d’être rappelé pour ne pas opposer les deux structures comme de simples rivales : la logique de preuve d’inclusion vient bien de Merkle. Dans un billet plus ancien sur l’état de l’Ethereum sans état, l’Ethereum Foundation décrivait déjà cette propriété fondatrice : “The only way to generate a state root is by computing it from each individual piece of the state, and two states that are identical can be easily proven so by comparing the root hash and the hashes that led to it (a Merkle proof).” (source). Verkle ne renie donc pas Merkle, il en optimise l’implémentation pour un cas d’usage précis : la validation de bloc sans état complet.
Verdict : quelle structure choisir en 2026 ?
Pour la quasi-totalité des cas d’usage actuels, l’arbre de Merkle reste le bon choix. Il est simple, audité depuis des décennies, gratuit en cérémonie de confiance et structurellement plus résistant à la menace quantique. Rien ne justifie de le remplacer dans un système de contrôle de version, une base de données distribuée ou un journal d’audit.
L’arbre de Verkle garde un intérêt réel et documenté : une réduction de la taille des témoins pouvant atteindre 23 fois sur des scénarios de type état Ethereum, ce qui change la donne pour des clients réellement sans état. Mais au 28 septembre 2026, cette technologie reste au stade testnet, sans date de mainnet confirmée, et la feuille de route Ethereum elle-même penche désormais vers un arbre binaire combiné à des preuves STARK plutôt que vers un déploiement Verkle généralisé, en grande partie à cause de l’exposition post-quantique des engagements sur courbe elliptique. La meilleure formulation reste la plus honnête : l’arbre de Verkle est une piste de recherche Ethereum importante, ni pleinement déployée, ni définitivement abandonnée. Les équipes qui construisent aujourd’hui devraient suivre son évolution sans y bâtir de dépendance de production.
Concrètement, cela donne trois règles simples. Premièrement, si votre système fonctionne déjà avec un arbre de Merkle et n’a pas de problème de taille de témoin, ne touchez à rien. Deuxièmement, si vous concevez un nouveau protocole avec un horizon de dix ans ou plus, privilégiez une base essentiellement fondée sur le hachage plutôt qu’un engagement de courbe elliptique, quitte à sacrifier un peu de compacité de preuve. Troisièmement, si la taille des témoins est votre goulot d’étranglement immédiat, comme c’est le cas pour un client léger ou un rollup, expérimentez avec KZG ou IPA dès maintenant sur un environnement de test, tout en gardant un œil sur la direction finale que prendra Ethereum lui-même.
Questions fréquentes
Qu’est-ce qu’un arbre de Verkle en une phrase ?
C’est une structure proche d’un arbre de Merkle, mais où chaque nœud engage un vecteur de valeurs via un engagement cryptographique sur courbe elliptique, ce qui permet de produire des preuves beaucoup plus compactes.
Ethereum a-t-il déjà déployé les arbres de Verkle en 2026 ?
Non. Au 28 septembre 2026, les arbres de Verkle tournent uniquement sur des testnets. La feuille de route officielle privilégie désormais une direction concurrente basée sur un arbre binaire et des preuves STARK, documentée sous EIP-7864.
Pourquoi les preuves Verkle sont-elles plus petites que les preuves Merkle ?
Parce qu’un nœud Verkle peut engager jusqu’à 256 enfants au lieu de deux, ce qui réduit la profondeur de l’arbre et le nombre d’éléments à transmettre pour prouver l’appartenance d’une valeur.
Les arbres de Verkle sont-ils vulnérables à l’informatique quantique ?
Oui, en principe. Les schémas d’engagement KZG et IPA utilisés reposent sur le logarithme discret sur courbe elliptique, une hypothèse que l’algorithme de Shor casserait sur un ordinateur quantique suffisamment puissant. Les arbres de Merkle, basés sur le hachage, résistent structurellement mieux à cette menace.
Quelle est la différence entre un engagement KZG et un engagement IPA ?
KZG produit des preuves de taille constante, autour de 48 octets par élément, mais nécessite une cérémonie de confiance initiale. IPA évite cette cérémonie, au prix de preuves qui croissent de façon logarithmique avec la taille du vecteur engagé.
Bitcoin utilise-t-il un arbre de Merkle ou de Verkle ?
Bitcoin utilise un arbre de Merkle pour regrouper les transactions de chaque bloc sous une racine unique. Aucune discussion sérieuse ne propose actuellement de migrer Bitcoin vers une structure Verkle.
Faut-il migrer un projet existant vers les arbres de Verkle dès maintenant ?
Dans la grande majorité des cas, non. Ethereum lui-même n’a pas encore déployé cette structure sur son mainnet et privilégie désormais une autre direction technique. Il est raisonnable de suivre les testnets et les publications EIP, sans engager une migration de production tant que le protocole de référence n’a pas tranché.
Quelle taille de témoin économise réellement un arbre de Verkle ?
Selon les estimations publiées par Ethereum.org, un témoin pour 1 000 feuilles passe d’environ 3,5 Mo avec un Merkle Patricia Trie à environ 150 Ko avec un arbre de Verkle, soit une réduction d’environ 23 fois pour ce scénario précis.
Qu’est-ce que EIP-7864 et remplace-t-il vraiment Verkle ?
EIP-7864 propose une structure d’état unifiée sous forme d’arbre binaire, combinée à des preuves de type ZK ou STARK. Les analyses publiées en 2026 le présentent comme la direction désormais privilégiée par Ethereum pour la validation sans état, plutôt qu’un déploiement Verkle généralisé, notamment parce qu’elle repose davantage sur le hachage que sur des engagements de courbe elliptique.
