---
title: "Arbre Verkle"
description: "Un arbre Verkle associe un arbre large à des engagements vectoriels pour produire des témoins d'état compacts, avec des compromis cryptographiques, de preuve et de migration."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Arbre Verkle
> À des fins éducatives uniquement ; ceci ne constitue pas un conseil en investissement. Tout investissement peut entraîner des pertes.
## Réponse directe
Un arbre Verkle est un arbre clé-valeur authentifié dont les nœuds internes utilisent des engagements vectoriels. Comme un arbre de Merkle, il lie de nombreuses valeurs à une racine ; contrairement à un arbre de hachage ordinaire, il prouve un enfant à une position sans fournir tous ses voisins.
Cela autorise une forte ramification et l'agrégation d'ouvertures pour plusieurs clés, réduisant le témoin par rapport à un Merkle-Patricia Trie. Le témoin contient toujours les valeurs d'exécution et la preuve de leur lien avec la racine authentifiée. « Sans état » ne signifie pas que personne ne stocke l'état ni que le consensus disparaît. Au 2026-08-22, la feuille de route Ethereum mentionnait encore des testnets et du travail client ; EIP-6800 était Stagnant.
## Fonctionnement
Le protocole fixe les encodages déterministes, le schéma d'engagement et les règles des nœuds vides. Chaque nœud engage un vecteur ordonné d'enfants ; le prouveur ouvre la position utile à chaque niveau, et un multiproof agrège les ouvertures et chemins partagés. Le vérificateur confronte clés, valeurs, engagements et preuve à une racine fiable.
Dans EIP-6800, une clé de 32-byte contient un stem de 31-byte et un suffix de 1-byte, et les nœuds ont une largeur de 256. Les valeurs de même stem partagent du matériel. Cette disposition est propre à la proposition : plus de largeur raccourcit les chemins mais exige arithmétique elliptique et précalculs.
## Exemple
Supposons qu'un stem de 31-byte regroupe 256 suffix. Si un bloc lit 2 valeurs de ce stem, il réutilise le chemin et agrège les ouvertures au lieu de transporter 2 jeux de hachages voisins Merkle. Les deux clés et valeurs, la preuve et la racine choisie restent à vérifier.
Modifier une valeur actualise son engagement et les ancêtres jusqu'à la racine. Une preuve de l'ancienne racine ne prouve pas la nouvelle. Le gain dépend des accès : compact ne signifie ni bande passante ou coût nul, ni disponibilité garantie.
## Risques
Des erreurs de dérivation, ordre des octets, liaison de position, séparation de domaines, validation de points, conversion scalaire ou distinction vide-zéro compromettent la sécurité. Vecteurs de test et interopérabilité sont indispensables.
Les petites preuves ne résolvent ni disponibilité ni vivacité : retenir une valeur empêche l'exécution, et une mauvaise racine ou finality accepte un faux historique. Produire les preuves peut aussi devenir un goulot ou point de censure.
Migrer change disposition, synchronisation, formats, bases, comptabilité Gas et preuves historiques. Proposition ou devnet ne démontrent pas la maturité. Les engagements elliptiques considérés ne sont généralement pas post-quantum secure.
## Idées reçues
### Idée reçue 1: seulement un Merkle avec plus d’enfants
La différence décisive est d'ouvrir un enfant par engagement vectoriel sans lister tous ses voisins.
### Idée reçue 2: toute preuve a une taille totale constante
Les ouvertures s'agrègent, mais le témoin croît avec valeurs, chemins et métadonnées.
### Idée reçue 3: sans état signifie que personne ne stocke l’état
Seul le vérificateur évite la copie complète ; quelqu'un doit conserver ou reconstruire et livrer les données.
### Idée reçue 4: Ethereum mainnet utilise déjà Verkle
Les sources portent sur recherche et testnets ; à la date vérifiée, EIP-6800 était Stagnant.
## Sujets connexes
- [Arbre de Merkle](/fr/crypto/merkle-tree/)
- [Client léger](/fr/crypto/light-client/)
- [Racine d’état](/fr/crypto/state-root/)
- [Ethereum](/fr/crypto/ethereum/)
- [Disponibilité des données](/fr/crypto/data-availability/)
## Sources
- [Verkle Trees](https://math.mit.edu/research/highschool/primes/materials/2018/Kuszmaul.pdf) - MIT PRIMES (consulté: 2026-08-22)
- [EIP-6800: Ethereum state using a unified verkle tree](https://eips.ethereum.org/EIPS/eip-6800) - Ethereum Improvement Proposals (consulté: 2026-08-22)
- [Verkle tree structure](https://blog.ethereum.org/2021/12/02/verkle-tree-structure) - Ethereum Foundation (consulté: 2026-08-22)
- [Verkle trees](https://ethereum.org/roadmap/verkle-trees/) - Ethereum.org (consulté: 2026-08-22)
Source: https://wiki.fcontext.com/fr/crypto/verkle-tree/index.mdx