La Fondation Ethereum se recentre sur la sécurité plutôt que sur la vitesse – fixe une règle stricte de 128 bits pour 2026

L'écosystème zkEVM a passé un an à optimiser la latence. Le temps de preuve pour un bloc Ethereum est passé de 16 minutes à 16 secondes, les coûts ont chuté de 45 fois, et les zkVM participants prouvent désormais 99 % des blocs du mainnet en moins de 10 secondes sur le matériel cible.

La Ethereum Foundation (EF) a déclaré victoire le 18 décembre : la preuve en temps réel fonctionne. Les goulots d'étranglement de performance sont éliminés. Maintenant, le vrai travail commence, car la vitesse sans solidité est un passif, pas un actif, et les mathématiques sous de nombreux zkEVM basés sur STARK se sont discrètement effondrées depuis des mois.

En juillet, l'EF a fixé un objectif formel pour la « preuve en temps réel » regroupant latence, matériel, énergie, ouverture et sécurité : prouver au moins 99 % des blocs du mainnet en 10 secondes, sur du matériel coûtant environ 100 000 $, fonctionnant avec 10 kilowatts, avec un code entièrement open-source, à une sécurité de 128 bits, et avec des tailles de preuve égales ou inférieures à 300 kilo-octets.

La publication du 18 décembre affirme que l'écosystème a atteint l'objectif de performance, tel que mesuré sur le site de benchmarking EthProofs.

Le temps réel est ici défini par rapport au temps de slot 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 la vivacité. »

L'EF pivote maintenant du débit vers 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 « gap de proximité » utilisées dans les tests de bas degré SNARK et STARK basés sur le hachage, ont été mathématiquement réfutées, réduisant la sécurité effective en bits des ensembles de paramètres qui en dépendaient.

L'EF affirme que la seule issue acceptable pour l'utilisation L1 est la « sécurité prouvable », et non la « sécurité en supposant que la conjecture X est vraie. »

Ils ont fixé la sécurité à 128 bits comme objectif, l'alignant avec les organismes de normalisation cryptographique grand public et la littérature académique sur les systèmes à longue durée de vie, ainsi qu'avec les calculs de records réels qui montrent que 128 bits est réalistement 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 tokens 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 à trois étapes

La publication présente une feuille de route claire avec trois jalons fermes. Premièrement, d'ici fin février 2026, chaque équipe zkEVM dans la course branche son système de preuve et ses circuits dans « soundcalc », un outil maintenu par l'EF qui calcule les estimations de sécurité basées sur les limites cryptanalytiques actuelles et les paramètres du schéma.

L'histoire ici est « règle commune ». Au lieu que chaque équipe cite sa propre sécurité en bits 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 au moins une sécurité prouvable de 100 bits via soundcalc, des preuves finales égales ou inférieures à 600 kilo-octets, et une explication publique compacte de l'architecture de récursion de chaque équipe avec un aperçu de pourquoi elle devrait être solide.

Cela revient discrètement sur l'exigence initiale de 128 bits pour le 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 : sécurité prouvable de 128 bits par soundcalc, preuves égales ou inférieures à 300 kilo-octets, plus un argument de sécurité formel pour la topologie de récursion. C'est là que cela devient moins une question d'ingénierie et plus une question de méthodes formelles et de preuves cryptographiques.

Leviers techniques

L'EF indique plusieurs outils concrets destinés à rendre l'objectif de 128 bits, inférieur à 300 kilo-octets réalisable. Ils mettent en avant WHIR, un nouveau test de proximité 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 schémas de style FRI au même niveau de sécurité.

Les benchmarks à sécurité de 128 bits montrent des preuves environ 1,95 fois plus petites et une vérification plusieurs fois plus rapide que les constructions de référence.

Ils font référence à « JaggedPCS », un ensemble de techniques pour éviter un remplissage excessif lors de l'encodage des traces en polynômes, ce qui permet aux prouveurs d'éviter le travail gaspillé tout en produisant des engagements succincts.

Ils mentionnent le « grinding », qui consiste à rechercher par force brute sur 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 une « topologie de récursion bien structurée », c'est-à-dire des schémas en couches dans lesquels de nombreuses preuves plus petites sont agrégées en une seule preuve finale avec une solidité soigneusement argumentée.

Des mathématiques polynomiales exotiques et des astuces de récursion sont utilisées pour réduire à nouveau les preuves après avoir augmenté la sécurité à 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 d'engagement polynomial plus expérimentales sont construites à partir de schémas de disponibilité des données.

Les mathématiques évoluent rapidement, mais elles s'éloignent également des hypothèses qui semblaient sûres il y a six mois.

Ce qui change et les questions ouvertes

Si les preuves sont systématiquement prêtes en 10 secondes et restent en dessous de 300 kilo-octets, Ethereum peut augmenter la limite de gas sans forcer les validateurs à ré-exécuter chaque transaction.

Les validateurs vérifieraient plutôt une petite preuve, permettant à la capacité des blocs de croître tout en gardant le staking à domicile réaliste. C'est pourquoi la publication antérieure en temps réel de l'EF liait explicitement la latence et la puissance aux budgets de « preuve à domicile » comme 10 kilowatts et des installations à moins de 100 000 $.

La combinaison de grandes marges de sécurité et de petites preuves est ce qui fait d'un « zkEVM L1 » une couche de règlement crédible. Si ces preuves sont à la fois rapides et prouvablement sécurisées à 128 bits, les L2 et les zk-rollups peuvent réutiliser la même machinerie 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 un benchmark off-chain, pas une réalité on-chain. Les chiffres de latence et de coût proviennent des configurations matérielles et des charges de travail organisées d'EthProofs.

Il existe toujours un écart entre cela et des milliers de validateurs indépendants exécutant réellement ces prouveurs à domicile. L'histoire de la sécurité est en flux. La raison d'être de soundcalc est que les paramètres de sécurité STARK et SNARK basés sur le hachage continuent de bouger à mesure que les conjectures sont réfutées.

Les résultats récents ont redessiné la ligne entre les régimes de paramètres « définitivement sûrs », « conjecturalement sûrs » et « définitivement non sûrs », ce qui signifie que les paramètres « 100 bits » d'aujourd'hui peuvent être révisés à nouveau à mesure que de nouvelles attaques émergent.

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 discrètement des marges plus faibles, s'appuieront sur des hypothèses plus lourdes, ou repousseront la vérification off-chain plus longtemps.

La partie la plus difficile pourrait ne pas être les mathématiques ou les GPU, mais la formalisation et l'audit des architectures de récursion complètes.

L'EF admet que différents zkEVM composent souvent de nombreux circuits avec un « code de liaison » substantiel entre eux, et que documenter et prouver la solidité de ces piles sur mesure est essentiel.

Cela ouvre une longue queue de travail pour des projets comme Verified-zkEVM et des cadres de vérification formelle, qui sont encore précoces et inégaux d'un écosystème à l'autre.

Il y a un an, la question était de savoir si les zkEVM pouvaient prouver assez rapidement. Cette question a trouvé sa réponse.
La nouvelle question est de savoir s'ils peuvent prouver de manière suffisamment solide, à un niveau de sécurité qui ne dépend pas de conjectures qui pourraient se rompre demain, avec des preuves suffisamment petites pour se propager à travers le réseau P2P d'Ethereum, et avec des architectures de récursion suffisamment vérifiées formellement pour ancrer des centaines de milliards de dollars.

Le sprint de performance est terminé. La course à la sécurité vient de commencer.

L'article Ethereum Foundation se recentre sur la sécurité plutôt que sur la vitesse – fixe une règle stricte de 128 bits pour 2026 est apparu en premier sur CryptoSlate.