La Fondation Ethereum se recentre sur la sécurité plutôt que sur la vitesse, en appliquant une norme de 128 bits pour 2026.

L'écosystème zkEVM a connu une année d'accélération complète en termes de latence. Le temps de création de preuves pour un bloc Ethereum a diminué de 16 minutes à seulement 16 secondes ; le coût a été réduit de 45 fois ; et les zkVM participants peuvent désormais générer des preuves pour 99 % des blocs sur le mainnet en moins de 10 secondes lorsqu'ils fonctionnent sur du matériel cible.

Le 18/12, la Fondation Ethereum (EF) a officiellement déclaré la victoire : créer une preuve en temps réel a été rendu possible. Les goulets d'étranglement de performance de base ont été levés. Cependant, la phase plus difficile commence réellement, car la vitesse, si elle n'est pas accompagnée de solidité mathématique, deviendra un risque plutôt qu'un avantage. Plus préoccupant encore, la base mathématique de nombreux zkEVM basés sur STARK a silencieusement révélé des points de rupture au cours des derniers mois.

Objectif de “preuve en temps réel” et tournant en matière de sécurité

En juillet, EF a fixé un objectif officiel pour la “preuve en temps réel”, non seulement en matière de latence mais aussi en ce qui concerne le matériel, l'énergie, l'ouverture et la sécurité. Concrètement, le système doit prouver au moins 99 % des blocs mainnet dans un délai de 10 secondes, sur un matériel d'une valeur d'environ 100 000 USD, consommant pas plus de 10 kW d'électricité, utilisant entièrement un code source ouvert, atteignant un niveau de sécurité de 128 bits et une taille de preuve ne dépassant pas 300 kilooctets.

Le post du 18/12 affirme que l'écosystème a atteint cet objectif de performance, basé sur les données du site de benchmark EthProofs.

Le concept de “temps réel” ici est défini relativement au cycle de slot de 12 secondes d'Ethereum et aux environ de 1,5 seconde consacrées à la transmission de blocs. En d'autres termes, la preuve doit être prête suffisamment rapidement pour que le validateur puisse vérifier sans interrompre la liveness (liveness) du réseau.

Cependant, l'EF a rapidement changé son attention du débit à la solidité (soundness), et cette réorientation est rigoureuse. De nombreux zkEVM basés sur STARK ont atteint un niveau de sécurité publicitaire en s'appuyant sur des hypothèses mathématiques non prouvées.

Au cours des derniers mois, certaines de ces hypothèses, en particulier les hypothèses de “proximity gap” dans les tests de degré faible (low-degree tests) de SNARK et STARK basés sur les fonctions de hachage, ont été mathématiquement invalidées. Cela a considérablement diminué le niveau de sécurité réel des ensembles de paramètres qui en dépendaient.

EF souligne qu'avec L1, la seule destination acceptable est “sécurité prouvable”, et non “sécurité si l'hypothèse X est correcte”.

Le niveau de 128 bits a été choisi comme norme, correspondant aux organisations de normalisation cryptographique traditionnelles et aux documents académiques sur les systèmes de longue durée, ainsi que les records de calcul dans le monde réel montrant que 128 bits sont au-delà des capacités d'attaque pratiques.

La priorité donnée à la robustesse plutôt qu'à la vitesse reflète une différence de nature. Si un attaquant peut falsifier des preuves zkEVM, il ne pourrait pas seulement vider un contrat, mais il pourrait également frapper des tokens à sa guise, réécrire l'état L1 et faire mentir tout le système. Par conséquent, l'EF considère qu'une haute sécurité est une condition non négociable pour tout zkEVM utilisé sur L1.

Feuille de route en trois étapes

EF propose une feuille de route claire avec trois étapes obligatoires.

Tout d'abord, d'ici la fin février 2026, toutes les équipes zkEVM participantes doivent intégrer leur système de preuves et de circuits dans “soundcalc”, un outil maintenu par l'EF pour calculer le niveau de sécurité basé sur les limites d'analyse cryptographique actuelles et les paramètres de chaque schéma.

L'objectif est d'établir une “norme commune”. Au lieu que chaque équipe déclare elle-même son niveau de bit-sécurité basé sur ses propres hypothèses, soundcalc deviendra un outil standard, pouvant être mis à jour lorsque de nouvelles méthodes d'attaque apparaissent.

Deuxièmement, la jalon “Glamsterdam” à la fin du mois de mai 2026 exige d'atteindre au minimum 100-bit de sécurité pouvant être prouvée par soundcalc, la taille de la preuve ne dépassant pas 600 kilobytes, ainsi qu'une explication publique, concise sur l'architecture récursive et l'argumentation de base pour sa solidité.

Cela ajuste implicitement l'objectif initial de 128 bits pour la phase de déploiement précoce, considérant 100 bits comme un niveau intermédiaire.

Mardi, “H-star” à la fin de l'année 2026 sera une norme complète : sécurité 128 bits pouvant être prouvée par soundcalc, taille maximale de preuve de 300 kilobytes, et un argument de sécurité officiel pour toute la structure récursive. À ce stade, le défi n'est plus purement technique, mais penche fortement vers les méthodes formelles et la preuve cryptographique.

Les leviers techniques

EF indique une série d'outils visant à réaliser l'objectif 128 bits avec une preuve de moins de 300 kilobytes. En particulier, WHIR, un nouveau test de proximité Reed–Solomon, sert également de schéma d'engagement polynomial multilinéal (multilinear polynomial commitment).

WHIR fournit une sécurité transparente, post-quantique, générant des preuves plus petites et vérifiant plus rapidement que les schémas FRI traditionnels au même niveau de sécurité. Le benchmark à 128 bits montre que la taille des preuves chute d'environ 1,95 fois, tandis que la vitesse de vérification est beaucoup plus rapide par rapport à l'architecture de base.

EF mentionne également JaggedPCS, un ensemble de techniques permettant d'éviter le remplissage (padding) superflu lors de l'encodage de la trace en polynôme, permettant au prouveur de réduire le gaspillage de calcul tout en maintenant un engagement concis.

En outre, il y a le “grinding”, c'est-à-dire la recherche par force brute dans l'espace aléatoire du protocole pour obtenir une preuve moins coûteuse ou plus petite tout en restant dans les limites de sécurité, ainsi que des architectures récursives conçues de manière rigoureuse, où plusieurs petites preuves sont agrégées en une preuve finale avec des arguments solides.

Les techniques de calcul polynomial et de récursivité de plus en plus complexes sont utilisées pour réduire les preuves après avoir élevé le niveau de sécurité à 128 bits.

Des recherches indépendantes comme Whirlaway utilisent WHIR pour construire des STARKs multilinéaires plus efficaces, tandis que d'autres structures de compromis polynomiales expérimentales sont en cours de développement à partir de schémas de disponibilité des données.

Les mathématiques progressent très rapidement, mais en même temps, elles s'éloignent des hypothèses qui étaient considérées comme sûres il y a seulement quelques mois.

Qu'est-ce qui a changé et les questions laissées en suspens

Si la preuve est toujours prête dans les 10 secondes et que sa taille est inférieure à 300 kilobytes, Ethereum peut augmenter la limite de gaz sans obliger le validateurs à réexécuter l'intégralité de la transaction. Au lieu de cela, ils doivent simplement vérifier une petite preuve, ce qui permet d'augmenter la capacité des blocs tout en maintenant la possibilité de staking à domicile.

C'est la raison pour laquelle l'EF dans les articles précédents a lié de manière étroite le retard et l'énergie avec le budget “home proving” comme 10 kW et le matériel de moins de 100 000 USD.

La combinaison d'une grande sécurité et de preuves légères est ce qui fait d'un “L1 zkEVM” une couche de paiement fiable. Si ces preuves sont à la fois rapides et atteignent une sécurité de 128 bits pouvant être prouvée, les L2 et zk-rollup peuvent réutiliser le même mécanisme via le precompile, rendant la frontière entre “rollup” et “exécution L1” plus flexible, basée sur la configuration plutôt que sur une séparation rigide.

Actuellement, la preuve en temps réel n'existe que sous forme de benchmark hors chaîne. Les données sur la latence et les coûts proviennent de configurations matérielles et de charges de travail sélectionnées sur EthProofs. L'écart entre cela et le fait que des milliers de validateurs indépendants exécutent réellement le prouveur à domicile reste encore considérable.

L'histoire de la sécurité n'est pas encore résolue. La raison de la création de soundcalc est que les paramètres de sécurité de STARK et SNARK sont basés sur des fonctions de hachage qui changent continuellement lorsque les hypothèses sont réfutées. Les résultats récents ont redessiné les frontières entre « certainement sûr », « sûr par hypothèse » et « certainement non sûr », ce qui signifie que les configurations « 100 bits » d'aujourd'hui pourraient devoir être ajustées à l'avenir.

Il n'est pas encore clair si toutes les grandes équipes zkEVM pourront atteindre 100 bits d'ici mai 2026 et 128 bits d'ici la fin de 2026 tout en respectant la limite de taille des preuves, ou si certaines accepteront une marge de sécurité inférieure, s'appuyant sur des hypothèses plus lourdes, ou prolongeront la vérification hors chaîne.

Le plus grand défi ne réside peut-être pas dans les mathématiques ou le GPU, mais dans la formalisation et l'audit de l'ensemble de l'architecture récursive. EF reconnaît que les zkEVM associent souvent de nombreux circuits avec une quantité considérable de “glue code”, et que la documentation ainsi que la preuve de la solidité de ces stacks personnalisés sont essentielles.

Cela ouvre une longue voie pour des projets tels que Verified-zkEVM et des frameworks de vérification formelle, qui en sont encore à un stade précoce et qui ne sont pas uniformes entre les écosystèmes.

Il y a un an, la grande question était de savoir si le zkEVM pouvait prouver sa rapidité. Cette question a trouvé une réponse.

Maintenant, la question est de savoir si elles peuvent prouver qu'elles sont suffisamment solides, à un niveau de sécurité qui ne dépend pas d'hypothèses pouvant s'effondrer demain, avec une preuve suffisamment petite pour se propager sur le réseau P2P d'Ethereum, et avec une architecture récursive vérifiée sous une forme suffisamment rigoureuse pour ancrer des centaines de milliards de dollars de valeur.

La course à la performance est terminée.

La course à la sécurité ne fait que commencer.

Vương Tiễn