Le cofondateur d'Ethereum, Vitalik Buterin, a soutenu l'EIP-8288 comme moyen proposé de prendre en charge la cryptographie complexe sans ajouter répétitivement de nouvelles fonctions de vérification à Ethereum, arguant que la majeure partie du travail cryptographique lourd devrait se dérouler en dehors du processus d'exécution principal du réseau.
Résumé
- Vitalik Buterin souhaite qu'Ethereum vérifie la cryptographie complexe au moyen de preuves agrégées plutôt que par des mises à niveau répétées du protocole.
- L'EIP-8288 propose de combiner des signatures cryptographiques et des preuves STARK avant que les validateurs Ethereum ne vérifient efficacement leur validité collective.
- La proposition pourrait prendre en charge des signatures de portefeuille résistantes aux ordinateurs quantiques sans nécessiter de précompilations Ethereum distinctes pour chaque type de signature.
- Les développeurs Ethereum n'ont pas approuvé l'EIP-8288, qui reste un brouillon nécessitant une mise en œuvre supplémentaire et un consensus réseau.
- Le système proposé garderait les grandes preuves en dehors des données de bloc tout en conservant les engagements de transaction pour la vérification.
Dans une série de publications du 19 octobre sur X, Buterin a soutenu que la machine virtuelle existante d'Ethereum et ses fonctions cryptographiques spécialisées ne conviennent pas pour prendre en charge chaque nouveau système de signature ou de preuve. Il a plutôt favorisé une conception qui permettrait aux utilisateurs de générer des preuves localement et de les soumettre via un mécanisme d'agrégation.
La proposition, l'EIP-8288, permettrait à Ethereum de vérifier que les opérations cryptographiques ont été effectuées correctement sans inclure chaque signature ou preuve originale dans un bloc.
Vitalik Buterin a décrit cette approche comme faisant partie de sa vision d'Ethereum en tant qu'ordinateur mondial cryptographique, où des calculs substantiels peuvent avoir lieu en dehors de la blockchain tandis que leurs résultats restent vérifiables.
La spécification reste un brouillon et n'a pas reçu d'approbation pour un déploiement sur le réseau principal d'Ethereum.
Vitalik Buterin veut moins de travail cryptographique à l'intérieur d'Ethereum
Les derniers commentaires de Vitalik Buterin portent sur la manière dont Ethereum gère les opérations cryptographiques qui nécessitent de grandes quantités de calcul ou de données.
Actuellement, les développeurs peuvent utiliser la machine virtuelle Ethereum, ou EVM, pour exécuter des contrats intelligents qui vérifient certaines déclarations cryptographiques.
Ethereum fournit des précompilations, qui sont des fonctions intégrées effectuant des calculs spécifiques plus efficacement que le code ordinaire de contrat intelligent.
Ces fonctions peuvent aider les développeurs à vérifier des signatures, des hachages et des preuves à divulgation nulle de connaissance.
Cependant, prendre en charge des méthodes cryptographiques supplémentaires directement via des précompilations peut nécessiter des modifications du protocole d'Ethereum.
Vitalik Buterin a soutenu qu'aucune des deux approches ne devrait devenir la solution par défaut pour chaque nouveau système cryptographique.
Sa préoccupation porte sur la quantité de données qui doivent être incluses dans les blocs Ethereum lorsque les applications soumettent de grandes signatures ou preuves cryptographiques pour vérification.
Dans la discussion du 19 octobre, il a estimé que même avec des améliorations telles que PeerDAS et blocks-in-blobs, le réseau ferait face à des limites pratiques d'environ 8 mégaoctets par seconde avant que des données supplémentaires ne deviennent difficiles à gérer.
L'estimation représente l'évaluation par Buterin des contraintes d'ingénierie futures, et non le débit de transactions actuellement mesuré d'Ethereum.
Il a décrit Ethereum comme un ordinateur mondial cryptographique dans lequel la blockchain ne devrait gérer que les informations nécessitant une exécution et une vérification partagées.
L'idée est cohérente avec ses travaux antérieurs sur la réduction de la quantité de calcul que chaque validateur Ethereum doit effectuer indépendamment.
En septembre, crypto.news a couvert sa vision d'un ordinateur cryptographique, qui décrivait la transition proposée d'Ethereum vers une vérification basée sur des preuves, la confidentialité et une gestion plus efficace des données.
Ses commentaires d'octobre portaient sur une proposition spécifique visant à faire fonctionner cette approche à travers différents systèmes cryptographiques.
L'EIP-8288 combinerait les preuves avant qu'elles n'atteignent Ethereum
Le mécanisme proposé est décrit dans l'EIP-8288, intitulé In-mempool signature and proof aggregation.
Buterin et le chercheur d'Ethereum Thomas Coratger ont créé la proposition le 3 juin 2026.
Selon la spécification officielle, le système permettrait aux transactions de déclarer quelles affirmations cryptographiques doivent être vérifiées sans inclure l'intégralité du matériel de preuve original dans le bloc final.
Ces déclarations identifieraient le schéma de vérification, un hachage représentant les données pertinentes et un hachage associé à la clé de vérification.
Le réseau utiliserait ces références pour relier les transactions aux preuves que les opérations requises ont été effectuées correctement.
Les utilisateurs généreraient des signatures ou des preuves cryptographiques en dehors de l'environnement d'exécution principal d'Ethereum.
La proposition permet à ces preuves d'être combinées de manière récursive, ce qui signifie qu'une preuve peut établir la validité de plusieurs preuves plus petites.
Au lieu de vérifier individuellement chaque signature originale et chaque STARK, Ethereum vérifierait une preuve agrégée couvrant les dépendances de transaction pertinentes.
Un STARK est une preuve cryptographique qui permet à quelqu'un de démontrer qu'un calcul a été effectué correctement sans exiger que chaque vérificateur répète l'intégralité du calcul.
Le système d'agrégation proposé utiliserait les outils Lean Ethereum pour générer et vérifier ces preuves.
L'EIP-8288 décrit un nouveau mode de cadre de transaction qui déclarerait les dépendances cryptographiques. La proposition s'appuie sur l'EIP-8141, qui introduit un cadre pour les transactions comportant plusieurs étapes d'exécution et de vérification.
Au niveau du bloc, un STARK récursif démontrerait que les dépendances déclarées ont été satisfaites.
Le système continuerait d'enregistrer les informations de transaction nécessaires et les engagements cryptographiques sur Ethereum.
Cependant, sa conception prévue éviterait de publier les grandes signatures et preuves originales en tant que calldata de transaction ordinaire.
La proposition n'est pas un plan visant à supprimer toutes les données de transaction de la blockchain ni à permettre aux applications de fonctionner sans enregistrements vérifiables.
Les signatures résistantes aux ordinateurs quantiques constituent une part majeure de la proposition
L'EIP-8288 inclut la prise en charge de signatures cryptographiques conçues pour résister aux attaques des futurs ordinateurs quantiques.
Ethereum s'appuie actuellement sur des systèmes de signature numérique établis pour l'authentification des comptes et le consensus de la blockchain.
Les développeurs recherchent des alternatives qui resteraient sécurisées si des ordinateurs quantiques suffisamment puissants devenaient disponibles.
Certaines signatures résistantes aux ordinateurs quantiques proposées sont beaucoup plus volumineuses que les signatures utilisées dans les transactions Ethereum conventionnelles.
Selon l'EIP-8288, les signatures basées sur le hachage à l'étude peuvent nécessiter environ 2 à 3 kilo-octets et un coût estimé de 150 000 à 200 000 de gas pour une vérification directe.
Les signatures basées sur les réseaux euclidiens présentent des défis comparables dans la discussion sur les coûts de la proposition.
Les preuves STARK peuvent nécessiter plus de 128 kilo-octets, certaines configurations atteignant environ 512 kilo-octets lorsqu'elles sont optimisées pour une génération rapide de preuves.
L'inclusion de grandes quantités de ce matériel directement dans les transactions pourrait créer des coûts substantiels en données et en exécution.
Vitalik Buterin a soutenu que les utilisateurs devraient pouvoir produire leurs signatures préférées localement et prouver leur validité par l'agrégation STARK.
Il a discuté de la possibilité d'utiliser la cryptographie basée sur les réseaux euclidiens pour les comptes et portefeuilles Ethereum si les hypothèses de sécurité pertinentes étaient établies.
Sa déclaration du 19 octobre faisait spécifiquement référence à la cryptographie qui pourrait être prouvée sûre contre les attaques liées à l'IA. Cette condition est distincte de la définition standard de la résistance aux attaques d'ordinateurs quantiques.
Un reportage antérieur sur la feuille de route d'Ethereum décrivait comment la résistance quantique et la confidentialité étaient devenues des priorités pour le développement futur du réseau.
La feuille de route comprend des modifications de la vérification des signatures et des systèmes cryptographiques soutenant le consensus et la disponibilité des données d'Ethereum.
L'EIP-8288 aborde une partie de ce travail en proposant une méthode commune pour vérifier plusieurs schémas cryptographiques.
L'agrégation récursive commencerait avant la production des blocs
Le processus proposé ne dépend pas uniquement d'un producteur de blocs collectant chaque signature et générant une preuve finale unique.
L'EIP-8288 décrit une agrégation récursive commençant dans le mempool d'Ethereum, où les transactions attendent avant d'être incluses dans les blocs.
Selon cette conception, les utilisateurs soumettraient des transactions accompagnées des preuves cryptographiques requises pour les autoriser.
Les participants au mempool pourraient valider les preuves soumises, combiner plusieurs preuves en une seule et transmettre le paquet résultant à d'autres participants.
La spécification décrit un intervalle d'agrégation de 1 000 millisecondes pour ce processus.
Les constructeurs de blocs collecteraient ensuite les transactions pertinentes et les preuves agrégées avant de construire un bloc Ethereum.
Un STARK récursif final couvrirait les dépendances associées aux transactions sélectionnées pour inclusion.
Le projet propose des limites techniques destinées à empêcher les utilisateurs malveillants de submerger le système d'agrégation avec des exigences de preuve excessives.
Par exemple, ses paramètres actuels autorisent jusqu'à 16 dépendances de signature spécifiées et une dépendance STARK par transaction.
La spécification aborde également la compatibilité avec FOCIL, un mécanisme d'inclusion de transactions proposé conçu pour rendre la censure plus difficile.
Une analyse d'Ethereum sur la vérification basée sur les preuves publiée en septembre examinait la distinction entre vérifier le résultat d'un calcul et garantir que les données sous-jacentes restent accessibles.
L'EIP-8288 aborde la vérification cryptographique tout en conservant les informations de transaction nécessaires pour identifier et valider les dépendances.
Sa conception introduit un travail supplémentaire pour les participants au mempool et les constructeurs de blocs, qui devraient générer, mettre à jour et combiner des preuves. La section sécurité de la proposition identifie la correction des circuits de preuve, des fonctions de hachage et de la vérification récursive comme des hypothèses nécessitant une évaluation minutieuse.
L'EIP-8288 reste un projet nécessitant l'approbation du réseau
Le dépôt officiel des propositions d'amélioration d'Ethereum classe l'EIP-8288 comme une proposition de norme à l'état de projet dans la catégorie core.
Sa mise en œuvre modifierait les règles de consensus d'Ethereum, car les blocs contenant le format de preuve récursive proposé ne seraient pas compris par les nœuds exécutant un logiciel sans la mise à jour.
La spécification identifie l'EIP-2718 et l'EIP-8141 comme dépendances. Plusieurs détails de mise en œuvre restent incomplets, notamment les paramètres associés à la clé de vérification agrégée et au hachage des dépendances.
L'implémentation de référence de la proposition est indiquée comme à venir. Les développeurs d'Ethereum devraient achever le travail technique, examiner les hypothèses de sécurité et s'accorder sur l'activation du réseau avant que la conception puisse être déployée. Le dépôt ne liste actuellement aucune date d'activation approuvée sur le mainnet pour l'EIP-8288.
Les cas de test existants de la proposition couvrent la vérification de signatures individuelles, les dépendances de preuves multiples, les preuves récursives invalides, l'agrégation dans le mempool et la compatibilité avec les listes d'inclusion de transactions.
Sa section de rétrocompatibilité indique que les transactions ordinaires sans les nouvelles trames de vérification cryptographique conserveraient leur comportement existant.
Les nœuds qui n'implémentent pas les nouvelles règles rejetteraient les transactions utilisant le mode de trame proposé et les blocs portant l'en-tête de preuve récursive.
La proposition exige donc une mise à niveau coordonnée du réseau avant que son système d'agrégation cryptographique puisse faire partie des règles du réseau principal d'Ethereum.
