La transformation d'Ethereum : L'avenir des preuves récursives STARK dans la prochaine décennie

Dans la prochaine décennie, Ethereum doit répondre à trois exigences : la sécurité post-quantique, la protection de la vie privée et l'évolutivité.

Rédigé par : _deanstef

Ethereum est à un tournant.

Sa première décennie a validé une hypothèse : les blockchains publiques peuvent soutenir à grande échelle des applications significatives. Les contrats intelligents, DeFi, stablecoins, appchains et tokenisation ont transformé Ethereum d'une plateforme de calcul décentralisée expérimentale en une couche de règlement d'une économie numérique en pleine croissance.

La deuxième décennie apporte des défis différents. Ethereum doit supporter des activités économiques sur lesquelles la société dépend réellement. Les stablecoins deviennent des rails de paiement, les actifs tokenisés sortent de la phase pilote, et les institutions construisent directement sur des rails publics.

Alors qu'Ethereum devient une infrastructure clé, il doit se renforcer pour les années à venir, devenant un système de calcul robuste, sécurisé, efficace et fonctionnant à l'échelle (décentralisée). Plus précisément, Ethereum doit :

• Résister à des menaces qui n'existent pas encore, en particulier les ordinateurs quantiques à cryptographie (CRQC).
• Avoir suffisamment de confidentialité pour répondre aux exigences de confidentialité des activités économiques réelles.
• Réaliser l'évolutivité sans renoncer à la neutralité, à l'ouverture et à la résistance à la censure qui l'ont initialement rendu possible.

La mission de la Fondation Ethereum a récemment clarifié cette vision à travers CROPS.

Ethereum doit « avant tout rester résistant à la censure, open source, privé et sécurisé ».

Avec la croissance de l'adoption, ces conditions ne deviendront pas moins importantes ; elles deviennent plutôt la base sur laquelle repose l'adoption. Deux d'entre elles - la confidentialité et la sécurité - se trouvent à la pointe de la recherche actuelle, ce qui n'est pas un hasard.

La strawmap d'Ethereum dessine une trajectoire évolutive progressive sur plusieurs années vers Lean Ethereum - une version qui repose sur des preuves cryptographiques simplifiées, étendant le réseau à 10K TPS et mettant à niveau vers des primitives post-quantiques, tout en ne renonçant pas à la redéfinition des protocoles décentralisés. Cette pile technologique est largement construite autour des STARKs (preuves de connaissance transparentes et évolutives). Un STARK est une preuve transparente basée sur le hachage, sans configuration de confiance ; il est à noter qu'il peut être agrégé, permettant de plier de nombreux calculs différents en une seule preuve.

Sur cette trajectoire, je vois trois grands piliers de recherche :

• Sécurité post-quantique omniprésente : se préparer à la CRQC pour chaque couche vulnérable aux attaques quantiques dans le protocole avant que la pression de migration n'arrive.
• Confidentialité programmable : fournir une confidentialité qui coexiste avec la vérifiabilité et la conformité, et l'intégrer dans l'infrastructure elle-même.
• Évolutivité : maintenir le consensus, la finalité et la vérification suffisamment efficaces pour que les deux premiers puissent être déployés sans compromettre les performances du réseau.

Les coûts cryptographiques des deux premiers sont plus élevés, et leur adoption dépend de la capacité du système à supporter cette complexité. La troisième voie est le liant. Les primitives post-quantiques et de confidentialité existent déjà, mais la question de recherche est comment les rendre utilisables à grande échelle. En fait, même les primitives post-quantiques et de confidentialité les plus optimisées seront plus lourdes que la cryptographie traditionnelle qu'elles remplacent, ce qui rend leur adoption dans un système complexe comme Ethereum difficile. Pour les rendre abordables, il n'y a qu'un seul levier : utiliser des preuves STARK pour des preuves récursives. Le reste de cet article se développera le long de cette chaîne.

Sécurité post-quantique

La transition vers un Ethereum post-quantique (PQ) doit couvrir chaque composant vulnérable aux attaques quantiques dans le protocole existant. Comme le résument la feuille de route de Vitalik et un récent article sur les risques quantiques de Nethermind, ces composants incluent les signatures ECDSA, les preuves de consensus BLS, les engagements KZG pour les blobs, et les SNARK basés sur des paires utilisés pour le règlement sur L1. Leur point commun est la difficulté du problème du logarithme discret sur les courbes elliptiques, que l'algorithme de Shor peut résoudre en temps polynomial sur un CRQC.

Les alternatives candidates se répartissent sur un spectre :

• Les schémas de signature basés sur des réseaux (Lattice) (par exemple, ML-DSA, Falcon) maintiennent des signatures relativement petites, mais le coût de vérification sur la chaîne est élevé, dépassant un million de Gas, et leur théorie d'agrégation reste immature.
• Les schémas de signature basés sur le hachage dépendent uniquement de la sécurité de la fonction de hachage sous-jacente, mais au prix de la taille : la taille des signatures atteint plusieurs Ko, et aujourd'hui, le coût de vérification peut atteindre des centaines de milliers de Gas. Ils se divisent en variantes à état, comme XMSS, qui sont plus petites mais nécessitent que le signataire suive l'état de la clé ; et des variantes sans état, comme SPHINCS+, qui sont plus grandes, plus coûteuses à vérifier, mais ne nécessitent pas de gestion d'état.
• Les systèmes de preuve STARK reposent sur des fonctions de hachage dans le modèle des oracles aléatoires. Ils sont transparents, intrinsèquement post-quantiques, et ne nécessitent pas de configuration de confiance. Leur coût est la taille et le coût de vérification. Un STARK porte des milliers de hachages de chemins Merkle, donc la taille de chaque preuve atteint des dizaines à des centaines de Ko ; avec les prouveurs d'aujourd'hui, le coût de vérification sur la chaîne peut atteindre des millions d'unités de Gas, dépassant d'un ordre de grandeur le coût en Gas des SNARK basés sur des paires.

Dans l'ensemble, l'adoption des primitives PQ à différents niveaux du protocole Ethereum présente des défis majeurs liés à des signatures et des preuves plus grandes, à des vérifications plus coûteuses, et à des protocoles plus complexes :

Consensus

La taille de l'ensemble des validateurs d'Ethereum est dynamique, avec environ 1/32 des validateurs attestant à chaque slot. L'agrégation BLS compresse leurs votes sur la chaîne en aussi peu que 8 signatures de 96 octets, et c'est cette agrégation qui rend possible un ensemble de validateurs de cette taille. Cependant, face à un CRQC, la clé privée d'un validateur peut être dérivée de sa clé publique, permettant à un adversaire qui maîtrise la clé publique d'un validateur de falsifier ses preuves et de finaliser une chaîne invalide. Une alternative post-quantique naturelle est un schéma de hachage à état, comme XMSS, car le validateur peut gérer en toute sécurité son état de clé lorsqu'il signe le consensus. Cependant, XMSS ne peut pas s'agréger comme BLS ; avec environ un million de validateurs, chaque slot nécessiterait de porter environ 31 000 signatures PQ individuellement. En calculant environ 3 Ko par signature, la quantité de données par slot serait d'environ 90 Mo, plusieurs ordres de grandeur au-dessus des niveaux atteints par l'agrégation actuelle. Dans un scénario de finalité à un seul slot, la situation serait encore pire. Pour finaliser chaque bloc dans leurs slots respectifs, l'ensemble des validateurs devrait attester à chaque slot, produisant une quantité de données de signature atteignant des niveaux de Go.

### Comptes

Les comptes utilisateurs utilisent ECDSA pour l'authentification. Une fois qu'un compte initie une transaction, sa clé publique est exposée, permettant à un CRQC de récupérer la clé privée et de signer des transactions au nom du propriétaire, épuisant ainsi les fonds à volonté. Son remplacement est inévitable, mais les comptes externes (EOA) ne peuvent pas gérer l'état de signature comme les validateurs, donc ils nécessitent des schémas sans état, ce qui pousse le coût de vérification des signatures vers la couche d'exécution. Actuellement, il n'y a pas de gagnant clair. Le travail de l'EF se concentre sur le schéma de hachage sans état SPHINCS+, bien que des schémas basés sur des réseaux soient encore à l'étude, en grande partie en fonction des coûts de vérification. Le coût de vérification de SPHINCS+ sur EVM est élevé, c'est pourquoi certains travaux s'efforcent de rendre le schéma sans état lui-même moins cher : SPHINCS-minus est un vérificateur natif de keccak ; d'autres travaux contournent cela en utilisant l'abstraction des comptes pour faire tourner des clés à usage unique, permettant à chaque signature d'utiliser un schéma à usage unique beaucoup moins cher.

### Rollups

Les Rollups se règlent en publiant des preuves de validité sur L1. La méthode de vérification la moins chère aujourd'hui est basée sur des SNARK : la preuve ne fait que quelques centaines d'octets, et le coût de vérification est d'environ 200 à 500k Gas. Les CRQC compromettront l'hypothèse de paire sur laquelle ils reposent, permettant aux attaquants de falsifier des preuves de validité pour des transitions d'état qui n'ont jamais eu lieu, que L1 accepterait, finalisant un état de rollup frauduleux et ses retraits associés. Cela rend également inefficaces de nombreuses astuces que les rollups utilisent pour maintenir des coûts bas, comme envelopper de grands STARK dans un petit SNARK final pour le règlement, car cet emballage extérieur est également basé sur des paires. Sans cela, les rollups devront vérifier directement les STARK sur L1, avec des coûts atteignant des millions d'unités de Gas, dépassant de plusieurs ordres de grandeur les SNARK. Maintenir l'abordabilité de la vérification STARK est actuellement une question de recherche ouverte.

### Disponibilité des données

Les blobs Ethereum utilisent des engagements KZG, un schéma d'engagement polynomial qui génère un engagement de 48 octets pour chaque blob de 128 Ko. KZG facilite l'échantillonnage de la disponibilité des données, car il fournit (i) une ouverture de taille constante, donc le coût de vérification de chaque échantillon est faible, (ii) linéaire, supportant l'échantillonnage 2D, et (iii) réparable, les codages corrompus pouvant être réparés sur la base du même engagement. Malheureusement, KZG est également basé sur des paires, donc un CRQC peut falsifier des ouvertures, faisant passer des données non disponibles pour des données disponibles. Les alternatives sécurisées quantiquement doivent provenir d'engagements basés sur le hachage, la question étant de savoir combien de garanties KZG peuvent être préservées. Les candidats post-quantiques existants font face à différents compromis en termes d'efficacité computationnelle et réseau, avec des tailles d'engagement plus grandes et des coûts de preuve et de vérification croissants. FRIDA est un schéma DAS transparent basé sur FRI, construit sur des codes Reed-Solomon 1D, dont l'échantillonneur teste la proximité avec le mot code. Son coût est la bande passante : les échantillons KZG n'ont besoin de transporter qu'une ouverture de taille constante, tandis que chaque échantillon FRIDA est accompagné d'une preuve de proximité complète, donc chaque échantillon est beaucoup plus grand. ZODA est une autre alternative pour le codage 2D, qui rend chaque ligne et colonne échantillonnée auto-certifiée, réalisant un lien précis avec les données engagées, mais cette garantie est échantillon par échantillon et locale (elle ne couvre que les positions interrogées par le nœud), et l'échantillonnage nécessite de télécharger toute la ligne et toute la colonne codées. La troisième méthode enveloppe le codage dans un STARK. L'idée est de prouver dans un zkVM que les données engagées sont un mot de code Reed-Solomon valide. Alors une preuve peut certifier précisément l'ensemble du codage - pas de proximité, pas échantillon par échantillon - et sans configuration de confiance. Le coût est le débit de preuve. La conception et les tests de référence leanDA de l'EF ont mesuré cette méthode : sur un CPU haut de gamme d'aujourd'hui, le débit est d'environ 0,9 MiB/s, atteignant parfois environ 1 MiB/s. La recherche actuelle s'efforce de rendre cela suffisamment rapide.

### Directions de recherche

Réduire l'écart dans l'adoption des primitives PQ sera un axe de recherche clé dans les années à venir. Nous pouvons résumer les travaux de recherche pertinents en trois directions inter-domaines :

Efficacité des protocoles, sur deux aspects :

• Agrégation des signatures PQ. L'objectif est de regrouper de nombreuses grandes signatures PQ en une seule preuve, afin de maintenir des coûts bas sur le chemin critique du protocole (en particulier pour le consensus). Le leanVM de l'EF a déjà réussi à agréger XMSS à une vitesse d'environ 1 480 signatures par seconde en produisant des preuves de moins de 200 KiB, et ces preuves peuvent être recombinées de manière récursive, permettant ainsi une agrégation parallèle des signatures avant de les fusionner. La question ouverte est de savoir s'il est possible de concevoir un protocole qui reste viable tout en progressant vers la finalité à un seul slot (c'est-à-dire que l'ensemble des validateurs produit une preuve à chaque slot) et dans un temps de slot aussi court que possible ; de plus, qui générera ces preuves et quels seront les incitatifs correspondants.
• Validation des transactions. Les Frames (EIP-8141) permettent aux comptes d'apporter leur propre code pour autoriser les transactions, déplaçant la validation des signatures du niveau du protocole vers la logique personnalisée des comptes. La validation n'est plus liée à une signature ECDSA fixe, chaque compte peut choisir son propre schéma. Une direction à explorer est de savoir comment cette validation fonctionne : se fait-elle sur la chaîne via des précompilations définies pour chaque schéma, ou via des preuves post-quantiques et agrégables ? Cette dernière est explorée par l'EIP-8288, qui plie les preuves de signature de nombreuses transactions en une seule, permettant de maintenir la taille des preuves par bloc et la bande passante du mempool stables même avec une augmentation du nombre de transactions PQ.

Efficacité cryptographique. Réduire la taille et le coût de validation des signatures PQ elles-mêmes ; par exemple, le coût de validation de SPHINCS-minus sur l'EVM est d'environ 94k Gas. Idéalement, la communauté de recherche devrait concevoir des signatures favorables aux zk, permettant une preuve efficace dans le zkVM (l'EF travaille dans cette direction avec leanSPHINCS).

Infrastructure de preuve. Le coût de preuve des primitives PQ est principalement déterminé par les opérations de hachage sous-jacentes. Les fonctions de hachage standard de preuve (comme Keccak, SHA) ne sont pas des opérations natives et doivent être arithmétiquement adaptées, ce qui entraîne des frais de calcul. Deux voies sont explorées : des hachages favorables aux SNARK, comme Poseidon (rapides mais moins éprouvés en pratique), et des systèmes de preuve traitant directement les opérations non natives, permettant ainsi de prouver la cryptographie standard sans simulation de champ coûteuse. Pour ce dernier, les progrès de recherche sont rapides, avec des travaux récents comme Zinc+ et les engagements modulaires sur les entiers.

Les primitives post-quantiques existent déjà, mais elles ont des tailles de données plus importantes et des coûts de validation plus élevés. L'objectif de recherche est de les rendre pratiques au niveau du protocole actuel. Par exemple, rendre publiques des signatures très volumineuses dans le mempool obligerait chaque client à stocker et à valider une quantité exponentielle de données, et valider ces signatures coûterait plus de Gas, ce qui imposerait un fardeau tant aux utilisateurs qu'aux validateurs. Les technologies clés se concentrent sur les preuves STARK, qui peuvent être efficacement agrégées, réduisant les frais de données et la complexité de validation de O(n) à O(1). Les clients ne traitent et ne valident plus n signatures PQ différentes, mais ne gèrent qu'une seule preuve agrégée. C'est précisément cette même propriété qui débloque l'évolutivité, et c'est ce dont nous allons discuter ensuite.

Confidentialité programmable

Ethereum est construit sur une transparence totale, mais avec la finance mondiale sur la chaîne, la confidentialité devient non négociable, ce qui n'est pas encore réalisé aujourd'hui. Les solutions existantes présentent des lacunes sur deux fronts. Certaines manquent de la programmabilité nécessaire pour les cas d'utilisation institutionnels, où une forte confidentialité doit coexister avec une conformité prouvable, car pour les institutions, les deux sont complémentaires et non opposés. D'autres sont trop lourdes et difficiles à adopter : mauvaise expérience utilisateur, coûts plus élevés, et parfois nécessitent des hypothèses de confiance supplémentaires.

Les pools de confidentialité orientés consommateur, comme RAILGUN et Privacy Pools, apportent de la confidentialité aux portefeuilles ordinaires ; tandis que les plateformes orientées entreprise, comme Paladin, apportent une confidentialité programmable et conforme pour les institutions. Mais il n'existe actuellement aucune solution qui soit à la fois de niveau institutionnel et aussi facile à utiliser qu'un portefeuille ordinaire ; de plus, l'utilisation de l'un ou l'autre implique toujours de traiter des états hors chaîne (comme les arbres Merkle, les invalidateurs et les clés cryptographiques) et de générer des preuves à connaissance nulle pour chaque opération. La feuille de route de la confidentialité de Vitalik et celle de pcaversaccio résument bien les directions de recherche en matière de confidentialité existantes sur Ethereum. Ces directions peuvent être regroupées en quatre dimensions de niveau supérieur :

Utilisabilité

Il y a deux problèmes ici. Premièrement, construire une transaction de confidentialité devrait se sentir aussi simple que d'envoyer une transaction ordinaire, mais aujourd'hui, cela nécessite des transactions spécialement construites, un état hors chaîne à suivre, et des preuves à connaissance nulle à générer. Deuxièmement, cela devrait être peu coûteux, mais un transfert de confidentialité embarque un SNARK, ce qui signifie qu'il transporte plus de données et a un coût de validation plus élevé qu'un transfert public, et une fois que l'on ajoute des signatures et des preuves post-quantiques, cet écart ne fera que se creuser. Des cadres standardisés comme Kohaku et Paladin, capables de cacher cette complexité, commencent à résoudre le premier problème, bien que les deux soient encore à un stade précoce et en développement actif. La clé du second problème réside dans l'agrégation des preuves (proposition pour l'EIP-8288), une méthode économiquement efficace pour combiner les preuves de nombreuses transactions en une seule et répartir le coût de validation.

Fiabilité et résistance à la censure

Aujourd'hui, de nombreux protocoles de confidentialité dépendent de relais (relayers) pour soumettre des transactions au nom des utilisateurs, ce qui constitue un intermédiaire de confiance capable de censurer, retarder ou dé-anonymiser. Éliminer cette dépendance est l'objectif. Les transactions Frame (EIP-8141) sont une pierre angulaire : elles découpent « qui autorise la transaction » et « qui paie le Gas, comment cela s'exécute », permettant ainsi à l'entité payante d'être différente de celle qui signe, et les dépenses de confidentialité n'ont plus besoin d'un compte bien approvisionné lié à une identité pour être mises sur la chaîne. Deux parties complémentaires comblent cette lacune. Les nombres aléatoires avec clé EIP-8250 fournissent un domaine de nombres aléatoires indépendant, de sorte que les opérations de confidentialité du même expéditeur ne se chevauchent pas ; les racines récentes (EIP-8272) permettent aux transactions de déclarer la racine Merkle sur laquelle leur preuve est basée, garantissant ainsi que les preuves restent valides à mesure que l'arbre progresse. Ensemble, elles fournissent une référence de validation stable et interne au protocole pour les transactions de confidentialité, de sorte que leur validité ne dépend pas d'un état en rapide évolution, et que quiconque peut vérifier de manière asynchrone. Quant à la liste d'inclusion obligatoire FOCIL (EIP-7805), les inclusions peuvent vérifier indépendamment la validité de la transaction et demander son inclusion, offrant ainsi des garanties de résistance à la censure que les méthodes basées sur des relais ne peuvent pas fournir.

Récupération des données

Lire est aussi difficile que d'écrire. L'état privé (plus techniquement, les notes cryptées utilisées par les protocoles de confidentialité) n'indique pas en clair le destinataire, de sorte que le client doit scanner et stocker une grande quantité de données juste pour trouver les paiements qu'il a reçus ; et chaque fois qu'une requête est faite à l'RPC, cela révèle quelles données il recherche, et donc à qui ces données appartiennent. Le même principe sans intermédiaire s'applique. La récupération d'informations privées (PIR) permettra aux clients de lire à partir de l'RPC sans révéler la requête, tandis que les solutions de détection de messages involontaires leur permettront de trouver leurs notes sans avoir à scanner tout le contenu. Cependant, les compromis en termes d'efficacité et la maturité limitée rendent l'adoption de ces solutions un domaine de recherche actif.

Confidentialité intégrée au protocole

La direction la plus ambitieuse est d'intégrer les transferts de confidentialité dans le protocole lui-même, en intégrant dès le départ des contraintes de conception PQ, de sorte que les soldes de confidentialité ne soient pas exposés au risque de « collecter d'abord, déchiffrer ensuite ». Les défis sont considérables - de la reconstruction de toute la pile cryptographique sur la base de PQ (engagements, invalidateurs, encapsulation de clés, signatures) à la génération de preuves sur des portefeuilles matériels - ces défis sont bien résumés dans la transition vers un ETH privé natif post-quantique.

Comme pour la sécurité post-quantique, toutes les quatre directions dépendent de preuves et d'agrégations peu coûteuses, et une fois que les contraintes PQ sont appliquées, chacune d'elles devient plus difficile. La confidentialité devient une capacité de l'infrastructure elle-même, plutôt qu'une application ajoutée a posteriori au niveau supérieur.

Problèmes et troisième pilier

Ces deux piliers partagent une caractéristique épineuse commune : ils sont coûteux sur le plan cryptographique.

1. Les signatures PQ sont plus grandes et plus coûteuses que les schémas de courbes elliptiques qu'elles remplacent.
2. Les protocoles de confidentialité dépendent d'une preuve lourde de bout en bout, ce qui augmente la complexité et le coût pour les utilisateurs.

Si déployés à l'échelle du protocole, les deux augmenteraient le coût de validation pour chaque nœud sur le réseau.

La même réponse émerge encore et encore. Les signatures post-quantiques sont intégrées dans des STARK récursifs, la disponibilité des données sécurisées par des quantiques les encapsule dans un STARK, les transferts de confidentialité regroupent leurs preuves dans un autre STARK, tandis que les rollups se règlent déjà de cette manière. La question récurrente est : comment pouvons-nous nous permettre une cryptographie plus forte ? Cette question se résume chaque fois à une question plus ciblée :

À quel coût et avec quelle efficacité pouvons-nous agréger et valider les STARK ?

Élargir la couche de base

La feuille de route centrée sur les rollups a déplacé l'exécution hors de L1, permettant à Ethereum de se concentrer sur le consensus, le règlement et la disponibilité des données. Mais l'évolutivité ne peut pas s'arrêter à la couche 2. Chaque rollup hérite de tout ce que la couche de base fournit : son consensus, sa finalité, sa validation et sa disponibilité des données, donc améliorer la couche de base, c'est améliorer tout ce qui est construit dessus.

Nous nous concentrons sur l'élargissement le long de deux axes : l'exécution et le consensus *, et sur ces deux points, le levier décisif est le même. Les preuves récursives et l'agrégation peuvent représenter un grand nombre de preuves, ou un grand nombre de vérifications cryptographiques coûteuses, sous la forme d'une seule preuve concise. Parce que les STARK peuvent vérifier d'autres STARK, ces agrégations peuvent être combinées à l'infini ; et parce que la récursivité plie chaque niveau en vérifications de taille fixe, le coût de validation de la preuve finale n'augmente presque pas avec le nombre de preuves qu'elle plie, de sorte que chaque nœud n'a besoin de vérifier qu'une seule preuve, et non des milliers.

Exécution

L'exécution consiste à traiter plus de transactions en moins de temps. L'agrégation des preuves permet aux clients d'exécution de compresser la validation d'un grand nombre de transactions en une seule STARK, et ces transactions n'ont pas besoin d'appartenir au même type. La validation des signatures post-quantiques, les transferts de confidentialité et le règlement des rollups peuvent tous être intégrés dans la même agrégation. C'est pourquoi les transactions Frame - qui permettent aux comptes de définir leur propre logique de validation des transactions, plutôt que d'avoir des signatures codées en dur - sont cruciales pour la couche d'exécution lorsqu'elles sont combinées avec l'agrégation des preuves. Chaque transaction déclare les vérifications requises comme une obligation via Frame, et le constructeur traite l'ensemble du lot dans un STARK récursif, plutôt que de laisser chaque nœud valider chaque vérification en ligne. Le type Frame proposé pour les signatures PQ et l'agrégation STARK (EIP-8288) rend cela concret, le coût étant « uniquement payé par le constructeur et le mempool, et non par tous les nœuds de validation » ; la même idée permet également de maintenir la bande passante du mempool constante à mesure que le volume des preuves augmente.

Consensus

Le consensus lui-même contient plusieurs problèmes, et STARK aide à chacun d'eux.

Débit

Générer des blocs plus grands sans augmenter le coût de validation. Une fois que les validateurs vérifient la preuve de validité, au lieu de réexécuter le bloc, le constructeur peut publier une preuve valide tout en retenant les données sous-jacentes, garantissant ainsi explicitement la disponibilité des données. La direction des blocks-in-blobs emballe les transactions dans un blob, les validateurs échantillonnent la disponibilité au lieu de télécharger la charge complète ; le STARK du proposeur vise à prouver que le bloc a été correctement exécuté et codé fidèlement. Ainsi, le coût de validation s'étend avec la preuve, et non avec la taille du bloc.

Temps de Slot

Réduire l'intervalle entre les blocs en découplant la chaîne disponible du mécanisme de finalité. Un petit comité échantillonné de manière aléatoire génère continuellement des blocs sur le chemin critique, comme le montre la couche LMD-GHOST rapide de plusieurs centaines de validateurs et le design de consensus découplé ; tandis que l'ensemble complet des validateurs termine la finalité en parallèle en dehors du chemin critique. Moins de validateurs impliqués à chaque étape signifie moins d'agrégation STARK sur le chemin chaud et un temps de slot plus court.

Finalité

Réduire le temps de finalité d'environ seize minutes aujourd'hui, par exemple par une finalité à un tour, en retirant un tour de vote du chemin critique.

Ces trois éléments sont en conflit avec les exigences PQ. Une fois que les attestations se tournent vers des signatures basées sur des hachages qui ne peuvent pas être agrégées comme BLS, toute amélioration mentionnée ci-dessus deviendra extrêmement difficile à réaliser dans un budget de bande passante raisonnable.

STARK devient à nouveau une solution : compresser et agréger les preuves de l'ensemble des validateurs dans le temps de slot cible. Le design de chaîne minimaliste pousse la même technologie à l'état de consensus lui-même : faire en sorte que chaque validateur prouve son solde et son état, réduisant l'état de chaque validateur à quelques octets, est un chemin vers des millions de validateurs.

C'est précisément là que le STARK récursif devient la base sous-jacente du protocole. Combiner ces éléments - agrégation d'exécution, preuve de blocks-in-blobs et preuve post-quantique agrégée - est la direction dans laquelle la recherche doit avancer.

* Le troisième axe est l'extension de la couche de données, mais cela est strictement lié aux travaux de recherche PQ DA.

Aperçu de l'avenir

La feuille de route est incertaine, la recherche n'est jamais linéaire. Mais certaines dépendances semblent solides.

L'agrégation STARK rend une cryptographie plus forte abordable. Une cryptographie plus forte rend la sécurité post-quantique et les transactions privées pratiques sur Ethereum. Ainsi, Ethereum devient une infrastructure utilisable pour des activités économiques réelles, sans sacrifier son ouverture. Cependant, il n'y a aucune garantie que ces primitives plus fortes deviennent pratiques.

La capacité d'agrégation STARK à soutenir Ethereum dépend de quelques questions spécifiques et encore ouvertes :

• Agrégation de signatures hétérogènes. Prouver et combiner différentes signatures PQ dans la même agrégation, par exemple en agrégeant des signatures basées sur des hachages et des signatures basées sur des grilles dans le même STARK. La couche de compte ne sélectionnera pas une seule solution, donc l'agrégation doit être indépendante de la solution spécifique.
• Prouver efficacement les hachages. Le coût de preuve est dominé par le hachage sous-jacent, et le débit est encore loin des exigences. Ce compromis réside dans le fait que prouver des hachages éprouvés sur le terrain (comme Keccak et SHA) sur des domaines non natifs entraîne des frais arithmétiques ; tandis que les hachages favorables aux zk (comme Poseidon2) ont un coût de preuve faible, mais sont moins soumis à l'analyse cryptographique.
• Agrégation inter-domaines. Plier différents types de STARK dans une preuve récursive - de la vérification de signatures PQ, des transferts privés à la transition d'état de rollup - permet à l'ensemble de la pile de partager la même validation.
• Adapter l'agrégation au consensus. Faire face aux exigences temporelles du consensus : agréger l'ensemble des validateurs dans un seul slot, avec un temps de slot qui se réduit continuellement, et trouver le meilleur équilibre entre la taille du comité, la longueur du slot et la finalité.
• Préparation du protocole. S'assurer que l'infrastructure supportant ces agrégations existe à la fois au niveau de la mempool (par exemple en utilisant Frame et EIP-8288) et au niveau du consensus : à l'échelle de millions de validateurs, la preuve STARK de la signature PQ de chaque validateur doit également être agrégée, tout comme les signatures BLS d'aujourd'hui.
• Bien aligner les incitations. L'agrégation ne fait que transférer le coût, elle ne l'élimine pas : le travail de preuve est concentré sur les constructeurs de blocs, ce qui soulève des questions réelles sur les incitations et la centralisation.

Construire cette infrastructure n'est pas une tâche secondaire, mais une tâche principale. Les primitives existent déjà, et les transformer en quelque chose qui peut réellement fonctionner comme protocole, avant que la pression de migration ne nous force à faire face à cette question, est ce dont nous avons besoin dans les années à venir.