La vision 2030 d'Ethereum déplace le travail vers les preuves cryptographiques. Qui vérifie le résultat ?

La vision de Vitalik Buterin du 27 septembre décrit Ethereum passant d’un système dans lequel chaque vérificateur répète une grande partie du travail à un système où les données peuvent être échantillonnées et l’exécution vérifiée à l’aide de preuves compactes. Une partie, PeerDAS, a déjà été déployée. Le changement plus vaste de l’exécution reste en développement. Une preuve peut établir qu’un calcul a suivi des règles spécifiées, mais les utilisateurs ont toujours besoin de données, d’un moyen de soumettre des transactions et d’un protocole qui décide quel résultat devient final.

La question principale a deux réponses. Un prouveur produit une preuve cryptographique ; un vérificateur, potentiellement tout nœud validateur exécutant le logiciel concerné, vérifie cette preuve par rapport aux règles et aux entrées publiques. La feuille de route d’Ethereum pour un zkEVM de couche de base indique que la vérification devrait être bien moins coûteuse que la réexécution de chaque transaction. Mais décider si une preuve est solide ne suffit pas à déterminer si les données de transaction sont disponibles ou si un opérateur peut retenir la transaction d’un utilisateur.

L’essai de Buterin du 27 septembre, « The cryptographic world computer », présente la destination comme une combinaison d’une blockchain, de la confidentialité et de la vérification cryptographiques, et de composants décentralisés hors chaîne. Il oppose un ancien modèle de téléchargement et de réexécution à un modèle dans lequel les nœuds échantillonnent les données et vérifient les preuves. Il décrit d’autres changements possibles au consensus et à la construction des blocs. Il s’agit d’une vision technique personnelle, et non d’une spécification finale de mise à niveau ratifiée par toutes les équipes clientes d’Ethereum.

La distinction entre ce qui existe et ce qui est envisagé est importante. PeerDAS est arrivé avec Fusaka en décembre 2025, selon la mise à jour des priorités protocolaires de la Fondation Ethereum de février 2026. La Fondation indique que les validateurs échantillonnent désormais les données blob au lieu de les télécharger intégralement. Un passage à l’échelle du réseau vers la vérification de preuves d’exécution succinctes pour les blocs de la couche de base n’est pas décrit comme déjà déployé. Un lecteur qui entend qu’Ethereum « vérifiera les preuves en 2030 » devrait demander quelle preuve, quel calcul elle couvre et quels acteurs peuvent la tester indépendamment.

PeerDAS vérifie l’accès aux données, pas chaque calcul

L’élément déjà déployé est PeerDAS, ou échantillonnage de disponibilité des données pair à pair. Les rollups placent les données de transaction dans l’espace blob d’Ethereum afin que les autres participants puissent récupérer suffisamment d’informations pour reconstruire l’état et tenir un opérateur responsable des règles. L’ancienne approche consistant à faire télécharger chaque blob par chaque nœud rendrait les volumes de données plus importants coûteux pour les validateurs ordinaires. L’échantillonnage demande aux nœuds de vérifier de petits morceaux par rapport à des engagements cryptographiques, tandis que le réseau distribue suffisamment de morceaux codés pour la reconstruction.

L’explication d’Ethereum indique que les données blob étendues sont divisées en 128 colonnes. Un nœud ordinaire rejoint au moins 8 sous-réseaux de colonnes choisis aléatoirement. Huit divisé par 128 représente un seizième des données étendues. Le codage ajoute de la redondance, de sorte que cette quantité correspond à environ un huitième du volume de données original selon la description de la documentation. Les chiffres se réfèrent à la charge de travail de données d’un nœud par défaut, et non à l’affirmation qu’un seul nœud peut personnellement conserver tout l’historique de chaque rollup pour un huitième du coût.

Le codage de style Reed-Solomon produit des morceaux de données redondants, et les engagements cryptographiques aident un nœud à vérifier qu'un morceau échantillonné appartient à ce qui a été annoncé. L'échantillonnage fournit une garantie de disponibilité probabiliste à travers les nœuds participants. Il ne remplace pas la validation d'exécution. Un lot de transactions parfaitement disponible peut contenir une transition d'état invalide. De même, une preuve valide concernant une transition d'état ne suffit pas à permettre à un utilisateur de reconstruire un état de compte si les données nécessaires pour ce faire sont retenues en dehors des garanties de disponibilité.

La Fondation Ethereum a déclaré que Fusaka a permis une augmentation par huit de la capacité théorique de blobs. Le mot théorique compte : le débit soutenu réel dépend des augmentations de paramètres planifiées, des conditions du réseau et de l'utilisation des rollups. Crypto.news a expliqué comment les rollups utilisent la couche de données d'Ethereum. Le nouvel essai de Buterin traite PeerDAS comme la première étape visible vers un système qui vérifie plus et répète moins ; il ne doit pas être présenté comme la mise à niveau finale de preuve d'exécution.

Le prouveur fait le gros du travail ; les nœuds indépendants le vérifient

Dans un modèle d'exécution basé sur des preuves, quelqu'un doit encore exécuter les transactions et construire des preuves sur le résultat. Cette partie peut utiliser du matériel et des logiciels spécialisés coûteux. Une preuve succincte permet à un vérificateur de vérifier, à un coût bien moindre, que le changement d'état revendiqué suit le programme et les entrées engagés selon les règles du protocole. Une vérification mathématique n'exige pas que le vérificateur fasse confiance à l'entreprise de preuve simplement parce qu'elle a généré la preuve.

Il y a des conditions attachées à cette affirmation. Le vérificateur doit exécuter un système de preuve solide avec la bonne clé de vérification, les bonnes entrées publiques et les règles d'exécution convenues. Un circuit défectueux pourrait prouver parfaitement la mauvaise affirmation. Un bug dans l'implémentation d'un client pourrait accepter une preuve qu'il devrait rejeter. Une clé de mise à niveau qui peut modifier le code du vérificateur sans contrôles robustes pourrait affaiblir la garantie. Dans un protocole en direct, les implémentations indépendantes et l'examen comptent autant que la génération rapide de preuves.

La page de feuille de route zkEVM de la couche 1 d'Ethereum décrit un avenir dans lequel un nœud vérifie une preuve d'exécution de bloc au lieu de répéter chaque transaction. Son objectif déclaré est de réduire le coût en ressources de la vérification. Cela faciliterait la vérification des blocs par davantage de personnes si la vérification des preuves reste pratique sur du matériel accessible. Cela ne signifie pas que chaque foyer peut produire une preuve de bloc, ni que la production de preuves sera répartie uniformément.

Crypto.news a rapporté une compétition matérielle autour de la production de preuves. La distinction utile est entre qui peut générer une preuve à temps pour la chaîne et qui peut en vérifier une à moindre coût. La génération de preuves pourrait se concentrer parmi les entreprises disposant de matériel spécialisé sans automatiquement permettre à ces entreprises de falsifier une transition d'état valide. Elle pourrait néanmoins introduire une dépendance à la vivacité : si trop peu de parties peuvent produire des preuves assez rapidement, les blocs ou la finalité pourraient ralentir même lorsque le système de preuve reste mathématiquement solide. C'est un risque différent de celui de l'acceptation d'une preuve invalide.

La question de la vérification a donc une réponse humaine autant que mathématique. Les développeurs définissent le circuit, les chercheurs l'auditent, les équipes clientes l'implémentent, les opérateurs de nœuds exécutent les vérificateurs, et les participants décident d'accepter ou non les mises à niveau du protocole. Buterin peut proposer une direction. Il ne peut pas à lui seul rendre un futur vérificateur sécurisé ou obligatoire pour le réseau.

Trois promesses sont souvent regroupées dans le mot preuve

Prenons un utilisateur envoyant un paiement via un rollup. La transaction doit être incluse dans un lot ordonné. Les données du lot doivent être rendues disponibles selon le modèle choisi par le rollup. Enfin, le changement d'état résultant doit suivre ses règles. L'ordonnancement, la disponibilité et l'exactitude sont des promesses distinctes. Une preuve d'exactitude répond à la dernière pour un calcul spécifié. PeerDAS répond à la disponibilité des données de blobs d'Ethereum. Un séquenceur ou un mécanisme de construction de blocs influence quelles transactions sont incluses et dans quel ordre.

Crypto.news a examiné les séquenceurs comme un point de contrôle distinct. Une preuve parfaitement valide peut attester qu'un lot a été traité selon les règles même si son opérateur a exclu la transaction d'un client particulier. Un utilisateur peut disposer d'une voie de sortie ou d'inclusion forcée selon la conception de ce rollup, mais la preuve elle-même n'impose pas un accès équitable. Un séquenceur peut également réordonner les transactions tout en produisant une transition d'état valide. L'énoncé prouvé ne doit pas être confondu avec toutes les propriétés que les utilisateurs attendent d'un marché.

Le côté données est tout aussi facile à confondre. La documentation d'Ethereum sur les validiums décrit des systèmes qui utilisent des preuves de validité mais ne publient pas les données de transaction sur le réseau principal Ethereum. Leur exécution peut être correcte selon un vérificateur, mais une défaillance de disponibilité des données peut empêcher les utilisateurs de reconstruire l'état ou de retirer comme prévu. Un rollup Ethereum publiant suffisamment de données sur Ethereum a un modèle de disponibilité différent. Appeler les deux simplement « ZK » masque une différence critique dans la capacité d'un utilisateur à récupérer l'état d'un compte sans l'opérateur.

Le test le plus simple est une liste de contrôle mentale à trois colonnes. Demandez qui fait entrer une transaction dans le lot. Demandez où les données nécessaires pour reconstruire les soldes peuvent être récupérées. Demandez quel contrat ou nœud vérifie la preuve de l'exactitude de l'état. Si un projet ne répond qu'à la troisième, il n'a pas répondu aux deux premières. C'est pourquoi l'essai de Buterin parle de construction de blocs et de distribution des données du réseau aux côtés de la cryptographie, plutôt que de remplacer tout le système par une seule preuve magique.

La couche de base ne peut pas emprunter toutes les propriétés des rollups existants

Les rollups ZK soumettent déjà des preuves de validité à Ethereum selon leurs propres contrats et règles. La documentation d'Ethereum sur les rollups ZK décrit un opérateur créant une preuve pour un lot et un contrat vérificateur acceptant une nouvelle racine d'état seulement après vérification. C'est un précédent utile pour prouver le calcul. Cela ne signifie pas que la couche de base d'Ethereum a déjà transféré toute la validation d'exécution à de telles preuves.

La portée diffère. Un rollup prouve sa propre transition d'état sous sa propre machine virtuelle et son propre contrat, tandis qu'un vérificateur de la couche de base d'Ethereum devrait vérifier l'exécution des blocs du protocole d'une manière acceptée par les équipes clientes. Une inadéquation entre la logique personnalisée d'un rollup et les règles d'exécution du réseau principal Ethereum n'est pas un détail qu'un prouveur plus rapide peut écarter. Les systèmes de preuve doivent également rester robustes à travers les mises à niveau du protocole, les nouveaux types de transactions et les entrées adverses.

Une application peut externaliser son arithmétique vers un coprocesseur et fournir un résultat avec une preuve, mais la chaîne de base décide toujours d'accepter les entrées publiques, de stocker les engagements et de régler l'état résultant. Une application peut être en mesure de choisir sa propre conception de prouveur ; une règle de la couche de base nécessite une large coordination entre les clients et les validateurs. L'expression de Buterin « ordinateur mondial cryptographique » est utile comme direction architecturale, non comme une promesse qu'un seul service de preuve fera fonctionner tout Ethereum.

Il y a une contradiction apparente qui mérite d'être résolue. Si les nœuds cessent de réexécuter, comment quelqu'un trouve-t-il un bug dans le calcul prouvé ? Une réponse est que les développeurs peuvent exécuter une exécution complète indépendante et la comparer aux résultats de preuve pendant le développement et après le déploiement. Une autre est la multiplication des implémentations de preuve et des vérifications formelles des circuits. La conception exacte d'Ethereum n'a pas été finalisée. Un protocole qui réduit la réexécution requise n'interdit pas aux gens d'effectuer des vérifications supplémentaires ; il change ce que chaque nœud validateur ordinaire doit faire pour le consensus.

La mise à jour des priorités du protocole de septembre de la Fondation traite un zkEVM de couche 1 et la vérification formelle comme des chantiers majeurs. C'est la preuve d'une ingénierie active, pas d'une date de lancement fixée. La norme de sécurité est élevée car une erreur dans un système de preuve de la couche de base affecterait la fondation dont dépendent d'autres applications.

Les preuves peuvent améliorer la vérification tandis que le problème d'état s'aggrave

Buterin cite l'accès à un très grand état partagé comme un problème non résolu particulièrement difficile. Crypto.news a examiné sa proposition distincte pour la mise à l'échelle du mempool basée sur des preuves, qui cible un goulot d'étranglement différent de l'exécution finale de l'état. Une preuve peut attester d'un calcul, mais le prouveur doit obtenir les informations dont dépend ce calcul : soldes, stockage des contrats et autre état des comptes. Si de nombreuses transactions touchent le même état en même temps, répartir le calcul sur plusieurs machines devient plus difficile. Un paiement depuis un compte et un échange touchant une pool de liquidité ne peuvent pas tous deux être finalisés à partir d'instantanés incohérents.

L'essai suggère que les applications peuvent placer l'ordonnancement et les changements d'état non commutatifs onchain tout en agrégeant d'autres calculs avant l'inclusion. Il s'agit d'une incitation architecturale, et non d'une règle contraignante pour les développeurs aujourd'hui. « Non commutatif » signifie que changer l'ordre change le résultat. Deux personnes achetant dans le même pool restreint peuvent obtenir des prix différents selon l'ordre dans lequel les transactions sont traitées. Aucune preuve ne rend ces deux ordres économiquement équivalents.

C'est un contrepoids utile à la promesse simpliste d'une mise à l'échelle gratuite. Le travail parallèle est plus facile lorsque les tâches peuvent être séparées en toute sécurité. L'état partagé crée des dépendances. Un prouveur peut exécuter rapidement de nombreux calculs indépendants et attendre néanmoins l'accès à un état contesté ou le choix d'ordonnancement d'un constructeur de blocs. Améliorer uniquement la vitesse de preuve ne résout pas la contention de base de données, la censure ni le coût de mise à disposition d'assez d'informations aux autres participants.

Selon Buterin, une couche intermédiaire décentralisée plus robuste pourrait traiter le travail en parallèle et, dans certains cas, protéger les métadonnées indiquant l'origine des requêtes. Une telle infrastructure pourrait améliorer les performances ou la confidentialité, mais elle devrait préciser comment les données sont distribuées, qui peut rejoindre le réseau et quelles défaillances disposent d'une voie de secours. La confidentialité du paiement d'un utilisateur n'est pas une conséquence automatique de l'utilisation d'une preuve de validité. Les entrées publiques, l'activité du portefeuille et les métadonnées réseau peuvent encore divulguer des informations, à moins qu'un système ne protège aussi ces éléments.

L'indépendance peut être mesurée avant le fork final

« N'importe qui peut vérifier » comporte des conditions pratiques. Un nœud ordinaire a besoin du code du vérificateur, des entrées publiques pertinentes, d'une connexion à l'état accepté de la chaîne et d'une capacité de traitement suffisante pour effectuer la vérification dans les limites de temps du protocole. Si une preuve prend quelques secondes à vérifier sur une machine modeste mais des heures à produire sur du matériel coûteux, le système peut atteindre une large vérification avec une production restreinte. Cela peut être un compromis d'ingénierie acceptable pour l'exactitude, à condition qu'une panne d'un producteur ne devienne pas un blocage permanent du règlement.

L'expérience est simple dans ses grandes lignes. Exécuter un logiciel de vérification provenant de plus d'une équipe cliente sur la même preuve de bloc valide et confirmer qu'ils l'acceptent. Fournir des entrées publiques modifiées et confirmer le rejet. Demander si des équipes de preuve distinctes peuvent produire des preuves acceptées pour les mêmes règles, à quelle vitesse elles peuvent le faire et quel matériel chacune nécessite. Répéter cela sur un réseau de test public sous forte charge en dirait plus sur l'état de préparation qu'une démonstration en laboratoire d'une seule preuve rapide. Les critères d'acceptation exacts d'Ethereum restent soumis au travail du protocole ; ce sont des questions observables, et non des seuils de réussite officiels.

La génération de preuves a un autre mode de défaillance qu'une vérification de validité ne peut pas détecter à elle seule. Un prouveur pourrait refuser de produire une preuve pour un bloc proposé. Un vérificateur ne peut pas accepter une preuve qui n'est pas arrivée. Une conception peut y remédier en autorisant plusieurs prouveurs indépendants, un chemin d'exécution de secours, un calendrier ajusté ou d'autres mécanismes. Le choix affectera la complexité, le coût et le délai de finalité. Les règles actuelles de la couche de base d'Ethereum ne devraient pas être décrites comme ayant sélectionné l'une de ces solutions futures simplement parce qu'une feuille de route indique que la vérification de preuve est un objectif.

L'indépendance signifie aussi qu'un utilisateur peut obtenir les informations nécessaires pour vérifier sa propre prétention sur des actifs. Une preuve qu'une racine d'état suit le code est puissante, mais un utilisateur qui ne peut pas reconstruire le chemin depuis les données de son compte jusqu'à cette racine dépend encore d'un intermédiaire pour une vérification pratique du solde. PeerDAS rend la disponibilité des données de blobs moins exigeante pour chaque nœud tout en s'appuyant sur la distribution et l'échantillonnage à travers le réseau. Les données d'application conservées ailleurs ont besoin de leurs propres garanties de disponibilité. Le vérificateur de preuve de la chaîne ne peut pas contraindre un opérateur externe à publier des enregistrements retenus.

Enfin, le programme vérifié doit être le programme que les utilisateurs croient qu'il est. Un hachage public du code du vérificateur, un processus de mise à niveau documenté et des tests indépendants du comportement du circuit permettent aux tiers de comparer la règle annoncée avec ce que les nœuds appliquent réellement. La vérification formelle peut réduire le risque d'une erreur logique, mais elle commence elle aussi par une spécification écrite par des humains. Le résultat vérifiable n'est pas « la cryptographie a résolu la confiance ». C'est qu'une affirmation spécifiée peut être indépendamment rejetée lorsque ses preuves sont invalides, sans que chaque nœud paie le coût total de sa production.

Hegota est un marqueur, pas une garantie de sortie en 2030

Buterin fait référence à Hegota, un fork prévu pour 2027, comme possiblement la dernière mise à niveau dont les composants seraient familiers à un observateur d'Ethereum de 2015. Les travaux ultérieurs dans son compte rendu impliqueraient des STARK récursifs, la vérification formelle, un consensus optimisé et la sécurité quantique. Crypto.news a rapporté l'objectif quantique distinct de 2029 comme objectif de planification. Ni l'essai ni une date cible ne prouvent que chaque composant proposé sera prêt et adopté dans les délais.

Les mises à niveau d'Ethereum nécessitent des spécifications, des implémentations clientes, des réseaux de test, des revues de sécurité et une coordination entre les participants. Une feuille de route indicative est une carte de recherche et de jalons candidats, pas une mise en œuvre onchain. On peut vérifier que PeerDAS est déployé en examinant la version Fusaka et les règles actuelles des nœuds. On ne peut pas vérifier un futur zkEVM général de couche de base en regardant la colonne bleue 2030 d'un essai. Les preuves arriveront d'abord dans les spécifications et tests publics, puis dans un plan de fork concret et une activation en production.

L'argument en faveur de l'approche de Buterin est solide. Si la vérification devient bon marché et que les données peuvent être échantillonnées en toute sécurité, davantage d'utilisateurs peuvent vérifier indépendamment un système plus vaste sans acheter des machines proportionnées à l'ensemble de ses calculs et données. Le défi est tout aussi réel : la pile de preuve doit être sécurisée, produite de manière compétitive et suffisamment rapide pour maintenir le système en vie, tandis que les données et l'ordonnancement restent accessibles. Un réseau avec une vérification bon marché mais un prouveur ou un séquenceur unique indispensable peut encore être fragile.

L'essai ne tranche pas qui construira chaque preuve ni quel système de preuve l'emportera. Il identifie un test qui compte pour les utilisateurs : un participant indépendant ordinaire peut-il rejeter un mauvais résultat, récupérer les données nécessaires pour connaître son propre état et soumettre une transaction malgré un opérateur unique ? Chaque réponse nécessite un mécanisme distinct. La vérification cryptographique est puissante précisément parce qu'elle peut être répétée par des personnes qui n'ont pas fait le gros du travail.

Ce qu'il faut surveiller

• Spécifications du zkEVM de couche 1. Recherchez un vérificateur concret, un format d'entrée public et des règles d'exécution acceptés par tous les clients.
• Diversité des prouveurs. De multiples implémentations indépendantes et des besoins matériels mesurés permettront de déterminer si la production de preuves présente un point d'étranglement unique.
• Mesures de PeerDAS. Vérifiez le débit des blobs et la bande passante des nœuds à mesure que les paramètres augmentent après le lancement de décembre 2025.
• Décisions sur Hegota. Une portée finale de fork importe davantage que les fonctionnalités candidates dans une feuille de route préliminaire.
• Garanties sur les données et l'ordonnancement. Examinez si les rollups et les futures conceptions de la couche de base préservent la reconstruction indépendante et l'inclusion des transactions.

FAQ