L’écosystème zkEVM a passé un an à sprinter sur la latence. Le temps de preuve d’un bloc Ethereum est passé de 16 minutes à 16 secondes, les coûts ont été divisés par 45 et les zkVM participants prouvent désormais 99 % des blocs du réseau principal en moins de 10 secondes sur le matériel cible.
La Fondation Ethereum (EF) a déclaré la victoire le 18 décembre : des travaux de démonstration en temps réel ont été réalisés. Les goulots d’étranglement en matière de performances sont éliminés. Maintenant, le vrai travail commence, car la vitesse sans solidité est un handicap, pas un atout, et les calculs sous de nombreux zkEVM basés sur STARK échouent tranquillement depuis des mois.
En juillet, l’EF a fixé un objectif formel de « preuve en temps réel » qui regroupe la latence, le matériel, l’énergie, l’ouverture et la sécurité : prouver au moins 99 % des blocages du réseau principal en 10 secondes, sur du matériel qui coûte environ 100 000 $ et fonctionne dans les 10 kilowatts, avec un code entièrement open source, avec une sécurité de 128 bits et avec des tailles de preuve égales ou inférieures à 300 kilo-octets.
Le message du 18 décembre affirme que l’écosystème a atteint l’objectif de performance, tel que mesuré sur le site d’analyse comparative EthProofs.
Le temps réel est ici défini par rapport au temps de créneau de 12 secondes et à environ 1,5 seconde pour la propagation des blocs. La norme est essentiellement « les preuves sont prêtes assez rapidement pour que les validateurs puissent les vérifier sans rompre leur vivacité ».
L’EF passe désormais du débit à la solidité, et le pivot est brutal. De nombreux zkEVM basés sur STARK se sont appuyés sur des conjectures mathématiques non prouvées pour atteindre les niveaux de sécurité annoncés.
Au cours des derniers mois, certaines de ces conjectures, en particulier les hypothèses de « écart de proximité » utilisées dans les tests de faible degré SNARK et STARK basés sur le hachage, ont été mathématiquement brisées, mettant à mal la sécurité effective des bits des ensembles de paramètres qui en dépendaient.
L’EF affirme que la seule fin de partie acceptable pour l’utilisation de L1 est « la sécurité prouvable », et non « la sécurité en supposant que la conjecture X soit vraie ».
Ils ont fixé la sécurité de 128 bits comme objectif, en l’alignant sur les organismes de normalisation cryptographiques traditionnels et la littérature académique sur les systèmes à longue durée de vie, ainsi qu’avec des calculs record du monde réel qui montrent que 128 bits est hors de portée des attaquants.
L’accent mis sur la solidité plutôt que sur la vitesse reflète une différence qualitative.
Si quelqu’un peut falsifier une preuve zkEVM, il peut créer des jetons arbitraires ou réécrire l’état L1 et faire mentir le système, pas seulement vider un contrat.
Cela justifie ce que l’EF appelle une marge de sécurité « non négociable » pour tout zkEVM L1.
Feuille de route en trois étapes
Le message présente une feuille de route claire avec trois arrêts difficiles. Premièrement, d’ici fin février 2026, chaque équipe zkEVM participant à la course branche son système de preuve et ses circuits à « soundcalc », un outil maintenu par EF qui calcule les estimations de sécurité en fonction des limites cryptanalytiques actuelles et des paramètres du système.
L’histoire ici est celle du « dirigeant commun ». Au lieu que chaque équipe cite sa propre sécurité avec des hypothèses sur mesure, soundcalc devient le calculateur canonique et peut être mis à jour à mesure que de nouvelles attaques émergent.
Deuxièmement, « Glamsterdam » d’ici fin mai 2026 exige une sécurité prouvable d’au moins 100 bits via soundcalc, des preuves finales égales ou inférieures à 600 kilo-octets et une explication publique compacte de l’architecture de récursivité de chaque équipe avec un aperçu des raisons pour lesquelles elle devrait être solide.
Cela revient discrètement sur l’exigence initiale de 128 bits pour un déploiement précoce et traite 100 bits comme un objectif intermédiaire.
Troisièmement, « H-star » d’ici fin 2026 est la barre complète : une sécurité prouvable sur 128 bits par soundcalc, des preuves égales ou inférieures à 300 kilo-octets, plus un argument de sécurité formel pour la topologie de récursion. C’est là qu’il s’agit moins d’ingénierie que de méthodes formelles et de preuves cryptographiques.
Leviers techniques
L’EF souligne plusieurs outils concrets destinés à rendre réalisable l’objectif de 128 bits inférieur à 300 kilo-octets. Ils mettent en avant WHIR, un nouveau test de proximité de Reed-Solomon qui sert également de schéma d’engagement polynomial multilinéaire.
WHIR offre une sécurité post-quantique transparente et produit des preuves plus petites et une vérification plus rapide que celles des anciens systèmes de type FRI au même niveau de sécurité.
Les tests de sécurité sur 128 bits montrent des preuves environ 1,95 fois plus petites et une vérification plusieurs fois plus rapide que les constructions de base.
Ils font référence à « JaggedPCS », un ensemble de techniques permettant d’éviter un remplissage excessif lors de l’encodage de traces sous forme de polynômes, ce qui permet aux prouveurs d’éviter un travail inutile tout en produisant des engagements succincts.
Ils mentionnent le « grindage », qui consiste à rechercher par force brute le caractère aléatoire du protocole pour trouver des preuves moins chères ou plus petites tout en restant dans les limites de solidité, et la « topologie de récursivité bien structurée », c’est-à-dire des schémas en couches dans lesquels de nombreuses preuves plus petites sont regroupées en une seule preuve finale avec une solidité soigneusement argumentée.
Des astuces mathématiques polynomiales exotiques et de récursion sont utilisées pour réduire les preuves après avoir augmenté la sécurité jusqu’à 128 bits.
Des travaux indépendants comme Whirlaway utilisent WHIR pour construire des STARK multilinéaires avec une efficacité améliorée, et des constructions plus expérimentales d’engagement polynomial sont en cours de construction à partir de schémas de disponibilité des données.
Les calculs évoluent rapidement, mais ils s’éloignent également des hypothèses qui semblaient sûres il y a six mois.
Quels changements et les questions ouvertes
Si les preuves sont systématiquement prêtes dans les 10 secondes et restent inférieures à 300 kilo-octets, Ethereum peut augmenter la limite de gaz sans obliger les validateurs à réexécuter chaque transaction.
Les validateurs vérifieraient plutôt une petite preuve, permettant ainsi à la capacité de bloc d’augmenter tout en gardant un jalonnement réaliste. C’est pourquoi le précédent article en temps réel de l’EF associait explicitement la latence et la puissance à des budgets « d’essai à domicile » comme 10 kilowatts et des plates-formes inférieures à 100 000 $.
La combinaison de grandes marges de sécurité et de petites preuves est ce qui fait d’un « L1 zkEVM » une couche de règlement crédible. Si ces preuves sont à la fois rapides et sécurisées sur 128 bits, les L2 et les zk-rollups peuvent réutiliser les mêmes machines via des précompilations, et la distinction entre « rollup » et « exécution L1 » devient plus un choix de configuration qu’une frontière rigide.
La preuve en temps réel est actuellement une référence hors chaîne, et non une réalité en chaîne. Les chiffres de latence et de coût proviennent des configurations matérielles et des charges de travail organisées par EthProofs.
Il existe encore un écart entre cela et des milliers de validateurs indépendants qui exécutent réellement ces prouveurs chez eux. L’histoire de la sécurité est en pleine évolution. La seule raison pour laquelle soundcalc existe est que les paramètres de sécurité STARK et SNARK basés sur le hachage continuent d’évoluer à mesure que les conjectures sont réfutées.
Des résultats récents ont redessiné la frontière entre les régimes de paramètres « absolument sûrs », « hypothétiquement sûrs » et « absolument dangereux », ce qui signifie que les paramètres « 100 bits » actuels pourraient être à nouveau révisés à mesure que de nouvelles attaques apparaissent.
Il n’est pas clair si toutes les principales équipes zkEVM atteindront réellement une sécurité prouvable de 100 bits d’ici mai 2026 et de 128 bits d’ici décembre 2026 tout en restant sous les plafonds de taille de preuve, ou si certaines accepteront tranquillement des marges plus faibles, s’appuieront sur des hypothèses plus lourdes ou pousseront la vérification hors chaîne plus longtemps.
La partie la plus difficile n’est peut-être pas les mathématiques ou les GPU, mais la formalisation et l’audit des architectures de récursivité complètes.
L’EF admet que différents zkEVM composent souvent de nombreux circuits avec un « code de colle » substantiel entre eux, et qu’il est essentiel de documenter et de prouver la solidité de ces piles sur mesure.
Cela ouvre une longue période de travail pour des projets tels que Verified-zkEVM et des cadres de vérification formels, qui sont encore précoces et inégaux entre les écosystèmes.
Il y a un an, la question était de savoir si les zkEVM seraient suffisamment rapides. Cette question trouve une réponse.
La nouvelle question est de savoir s’ils peuvent prouver suffisamment solidement, à un niveau de sécurité qui ne dépend pas de conjectures qui pourraient se briser demain, avec des preuves suffisamment petites pour se propager à travers le réseau P2P d’Ethereum, et avec des architectures de récursion suffisamment formellement vérifiées pour ancrer des centaines de milliards de dollars.
Le sprint de la performance est terminé. La course à la sécurité vient de commencer.
