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

L'écosystème zkEVM a passé une année à sprinter sur la latence. Le temps de preuve pour un bloc Ethereum est passé de 16 minutes à 16 secondes, les coûts ont chuté d'un facteur 45, et les zkVMs participantes prouvent désormais 99% des blocs mainnet en moins de 10 secondes sur le matériel cible.

L'Ethereum Foundation (EF) a déclaré la victoire le 18 décembre : la preuve en temps réel fonctionne. Les goulets d'étranglement de performance sont levés. Maintenant, le vrai travail commence, car la vitesse sans solidité est un handicap, pas un atout, et les mathématiques sous-jacentes à de nombreux zkEVMs basés sur STARK se brisent silencieusement depuis des mois.

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

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

Ici, « en temps réel » est défini par rapport au temps de slot de 12 secondes et environ 1,5 seconde pour la propagation du bloc. La norme est essentiellement « les preuves sont prêtes assez rapidement pour que les validateurs puissent les vérifier sans compromettre la vivacité ».

L'EF pivote désormais du débit vers la solidité, et le pivot est franc. De nombreux zkEVMs 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 « proximity gap » utilisées dans les tests de faible degré SNARK et STARK basés sur le hash, ont été mathématiquement brisées, réduisant la sécurité effective en bits des ensembles de paramètres qui en dépendaient.

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

Ils fixent la sécurité à 128 bits comme objectif, l'alignant sur les organismes de normalisation crypto traditionnels et la littérature académique sur les systèmes à longue durée de vie, ainsi que sur les calculs record du monde réel qui montrent que 128 bits sont effectivement 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 forger une preuve zkEVM, il peut frapper 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 en trois étapes

Le post présente une feuille de route claire avec trois étapes clés. Premièrement, d'ici fin février 2026, chaque équipe zkEVM en lice connecte son système de preuve et ses circuits à « soundcalc », un outil maintenu par l'EF qui calcule les estimations de sécurité sur la base des limites cryptanalytiques actuelles et des paramètres du schéma.

L'idée ici est d'avoir une « règle commune ». Au lieu que chaque équipe annonce 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 apparaissent.

Deuxièmement, « Glamsterdam » d'ici fin mai 2026 exige au moins 100 bits de sécurité prouvable via soundcalc, des preuves finales de 600 kilooctets ou moins, et une explication publique concise de l'architecture de récursion de chaque équipe avec un schéma 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 : 128 bits de sécurité prouvable via soundcalc, des preuves de 300 kilooctets ou moins, 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 met en avant plusieurs outils concrets destinés à rendre l'objectif de 128 bits et moins de 300 kilooctets réalisable. Ils mettent en lumière WHIR, un nouveau test de proximité Reed-Solomon qui fait également office de schéma d'engagement polynômial multilinéraire.

WHIR offre une sécurité transparente, post-quantique et produit des preuves plus petites et une vérification plus rapide que les anciens schémas de type FRI au même niveau de sécurité.

Les benchmarks à 128 bits de sécurité 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 pour éviter un remplissage excessif lors de l'encodage des traces en polynômes, ce qui permet aux prouveurs d'éviter un travail inutile tout en produisant des engagements succincts.

Ils mentionnent le « grinding », qui consiste à rechercher de manière exhaustive dans l'aléa du protocole pour trouver des preuves moins coûteuses ou plus petites tout en restant dans les limites de la solidité, et la « topologie de récursion bien structurée », c'est-à-dire des schémas en couches dans lesquels de nombreuses petites preuves 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 la taille des preuves après avoir augmenté la sécurité à 128 bits.

Des travaux indépendants comme Whirlaway utilisent WHIR pour construire des STARKs multilinéraires avec une efficacité améliorée, et des constructions d'engagement polynômial plus expérimentales sont en cours de développement à partir de schémas de disponibilité des données.

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

Ce qui change et les questions ouvertes

Si les preuves sont constamment prêtes en moins de 10 secondes et restent sous les 300 kilooctets, Ethereum peut augmenter la limite de gas sans obliger les validateurs à réexécuter chaque transaction.

Les validateurs vérifieraient alors une petite preuve, permettant à la capacité des blocs de croître tout en maintenant le staking à domicile réaliste. C'est pourquoi le précédent post de l'EF sur le temps réel liait explicitement la latence et la puissance à des budgets de « home proving » comme 10 kilowatts et des machines à moins de 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 prouvablement sécurisées à 128 bits, les L2 et les zk-rollups peuvent réutiliser la même machinerie via des précompilés, et la distinction entre « rollup » et « exécution L1 » devient davantage 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 sélectionnées par EthProofs.

Il existe encore 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 évolution. Toute la raison d'être de soundcalc est que les paramètres de sécurité STARK et SNARK basés sur le hash évoluent à mesure que les conjectures sont réfutées.

Les résultats récents ont redéfini 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 pourraient être révisés à nouveau à mesure que de nouvelles attaques apparaissent.

Il n'est pas clair si toutes les grandes équipes zkEVM atteindront effectivement 100 bits de sécurité prouvable d'ici mai 2026 et 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 n'est peut-être pas 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 zkEVMs composent souvent de nombreux circuits avec un « glue code » substantiel entre eux, et que documenter et prouver la solidité de ces piles sur mesure est essentiel.

Cela ouvre une longue traîne de travail pour des projets comme Verified-zkEVM et des frameworks de vérification formelle, qui en sont encore à leurs débuts et sont inégaux selon les écosystèmes.

Il y a un an, la question était de savoir si les zkEVMs pouvaient prouver assez vite. Cette question est résolue.
La nouvelle question est de savoir s'ils peuvent prouver avec suffisamment de solidité, à un niveau de sécurité qui ne dépend pas de conjectures susceptibles de s'effondrer demain, avec des preuves suffisamment petites pour se propager sur 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é ne fait que commencer.

L'article Ethereum Foundation refocuses to security over speed – sets strict 128-bit rule for 2026 est apparu en premier sur CryptoSlate.