Intervenant : Vitalik Buterin
Compilé par : Yuliya, PANews
Bonjour à tous ! Bienvenue à ETHShanghai 2026. Aujourd'hui, je souhaite discuter avec vous d'un sujet technique assez complexe qui est crucial pour l'avenir d'Ethereum—il peut permettre à Ethereum d'atteindre une scalabilité extrêmement élevée tout en équilibrant la confidentialité et la décentralisation, et les trois peuvent être réalisés simultanément. Cette proposition est très susceptible de véritablement changer l'architecture de fonctionnement de nombreux composants de la blockchain. Elle peut changer beaucoup de choses, mais de manière inattendue, sa mise en œuvre effective dans l'Ethereum existant n'est pas trop difficile. Il s'agit de l'EIP-8288 : Signature récursive et agrégation.
Point de douleur central : L'irréconciliabilité de la sécurité, de la confidentialité et de la scalabilité
Aujourd'hui, je souhaite me concentrer sur plusieurs problèmes majeurs qui préoccupent beaucoup tout le monde : la sécurité quantique, la confidentialité et la scalabilité. Actuellement, un gros problème est que la sécurité quantique et la confidentialité entrent toutes deux en conflit majeur avec la scalabilité :
Une transaction Ethereum normale consomme actuellement environ 21 000 gas ; vérifier indépendamment une signature ECDSA (environ 65 octets) prend environ 4 000 gas.
Si on la remplace par des signatures résistantes aux attaques quantiques (quel que soit le type de schéma de signature post-quantique), la consommation de gas sera approximativement entre 100 000 et 300 000 gas, selon la taille des paramètres choisis (par exemple, s'il doit être compatible avec les scénarios de portefeuille blockchain). Mais quel que soit le choix, le coût sera plusieurs fois supérieur à celui des transactions actuelles—les signatures résistantes aux attaques quantiques sont volumineuses et coûteuses.
Le deuxième problème : les preuves pour les protocoles de confidentialité sont également volumineuses et coûteuses. Si quelqu'un a utilisé un protocole de confidentialité basé sur la technologie à connaissance nulle (ZK), il saura que sur Ethereum, de telles opérations coûtent au moins environ 350 000 gas. Parce que beaucoup de ces protocoles ne sont pas conçus de manière très efficace, parfois le coût réel peut même atteindre environ 1 million de gas—c'est très cher. Aujourd'hui, une transaction normale peut coûter seulement quelques centimes, tandis que de telles transactions peuvent coûter 20 centimes, voire deux dollars.
Un problème plus grave est le suivant : si vous voulez à la fois la sécurité quantique et la confidentialité, vous devez utiliser des preuves STARK pour remplacer les schémas précédents. Cependant, une preuve STARK consomme environ 8 millions de gas, et très probablement plus. Cela signifie que si nous laissons maintenant tout le monde commencer à utiliser des transactions « résistantes aux attaques quantiques + confidentialité », la capacité de traitement originale d'Ethereum d'environ 25 TPS chutera à environ 0,25 TPS, perdant presque toute utilisabilité.
Un autre problème est le suivant : les gens peuvent également souhaiter prendre en charge des schémas cryptographiques personnalisés. Par exemple, passer des courbes elliptiques actuelles à la cryptographie sur réseaux euclidiens future. Le problème est que chaque fois que vous voulez prendre en charge de tels nouveaux schémas, cela augmente la taille du protocole lui-même et nécessite davantage de fichiers de précalcul (volumineux, coûteux). Et si vous ne prenez pas en charge nativement ces schémas dans l'EVM, ou si vous n'avez pas les fichiers de précalcul correspondants, alors vérifier une telle signature sur la chaîne consommera une quantité très importante de gas.
En d'autres termes, tous nos objectifs en matière de sécurité et de confidentialité entravent en réalité la scalabilité, du moins sous l'architecture actuelle.
Solution centrale : Déplacer le calcul d'agrégation en amont dans le mempool
Alors, comment résoudre ce problème ? C'est le mécanisme central mis en œuvre par l'EIP-8288.
L'idée centrale est la suivante : au lieu de mettre directement toutes ces signatures et toutes ces preuves STARK (ces objets énormes et structurellement complexes) sur la chaîne, nous les gardons hors chaîne et effectuons l'agrégation à l'intérieur du mempool.
Concrètement : lorsqu'un utilisateur envoie une transaction, il y a un groupe de nœuds dans le mempool, et ces nœuds travaillent déjà avant que la transaction ne soit incluse dans un bloc. Ce que font ces nœuds s'appelle « l'agrégation »—ils remplacent un grand nombre de signatures et de preuves par une seule preuve, qui peut vérifier que toutes ces signatures et preuves existent réellement et sont valides.
Donc du point de vue de l'utilisateur : l'utilisateur envoie une transaction, et avec la transaction il envoie aussi cet énorme objet (signature/preuve), mais cet énorme objet lui-même ne va jamais réellement on-chain. Ce qui va réellement on-chain n'est qu'une seule preuve STARK, utilisée pour vérifier que toutes les signatures et toutes les preuves contenues dans toutes les transactions des utilisateurs existent réellement et sont valides.
Ce mécanisme est construit au-dessus d'EIP-8141 (abstraction de compte native), qui sera introduit dans le prochain hard fork. EIP-8141 condense près d'une décennie de recherche de la communauté Ethereum dans le domaine de l'abstraction de compte. Il permet à chaque transaction de déclarer directement et précisément de manière explicite ses composants constitutifs, ses spécifications de signature et ses algorithmes de vérification, donnant aux transactions une programmabilité plus forte et une structure typée.
Dans EIP-8288, nous avons ajouté un nouveau type de frame, qui peut être compris comme une « dépendance ». Il existe au total deux types de dépendances : l'une correspond aux signatures, et l'autre correspond aux preuves (STARK). Contrairement au modèle actuel où les signatures sont directement intégrées dans le corps de la transaction, sous le nouveau mécanisme la transaction elle-même ne contient qu'une déclaration abstraite indiquant de quel type de signature et de preuve la transaction dépend. Lorsque la transaction est diffusée, bien que les données complètes soient envoyées avec elle, ce qui est finalement écrit dans le bloc n'est que la micro-structure de frame portant les dépendances. Les données occupées par chaque dépendance ne sont que de 96 octets, et la plupart sont même aussi faibles que 65 octets. Le reste des énormes entités cryptographiques est absorbé et agrégé à l'intérieur du mempool, et n'apparaît finalement sur le registre de la blockchain que sous la forme d'une seule preuve.
Sous cette architecture, chaque nœud du mempool écoute en permanence un support de données appelé « enveloppe ». Une seule enveloppe peut encapsuler plusieurs transactions et leurs preuves accompagnantes.
Les nœuds utilisent une période de temps fixe comme fenêtre, collectent en continu tous les objets enveloppes observés durant cette période, effectuent un calcul d'agrégation local, puis le diffusent. Lors de la diffusion, toutes les preuves indépendantes initialement discrètes ont été remplacées par une preuve agrégée globale, qui couvre mathématiquement de manière rigoureuse la validité de toutes les signatures sous-jacentes de ce lot.
Cela montre qu'avant que les nœuds d'emballage de blocs n'exécutent formellement les mises à jour d'état, le réseau Ethereum a déjà achevé la grande majorité du calcul de vérification de haute intensité au stade du mempool dans la couche non-consensus.
Essence architecturale : le « sharding spécialisé »
Une façon de comprendre ce mécanisme est de le voir comme une sorte de sharding spécialisé. Son idée est la suivante : nous pouvons isoler les parties extrêmement coûteuses du calcul impliquant des quantités extrêmement importantes de données, et laisser l'ensemble du réseau distribué traiter cette partie du calcul en parallèle de manière très lâche et non structurée.
Cette approche n'est pas fragile ; au contraire, elle est très robuste — n'importe quel nœud peut prendre en charge n'importe quelle portion de ce travail. Ce que nous faisons essentiellement, c'est diviser chaque transaction en deux parties :
Une partie explique « ce que fait cette transaction, comment elle interagit avec l'état, et comment elle interagit avec d'autres transactions » ;
L'autre partie est la partie énorme et coûteuse de cette transaction — c'est-à-dire le travail de vérification pur.
En isolant spécifiquement par sharding et en détachant la charge de vérification, la charge utile de données que la couche de consensus de la chaîne principale exige finalement que tous les nœuds de vérification du réseau supportent conjointement est strictement compressée dans une plage extrêmement réduite de 100 à 300 Ko par bloc. Cette surcharge ne représente qu'environ le double du volume de données actuel des blocs Ethereum, et à mesure que le débit global du réseau s'étend linéairement, la proportion de cette surcharge constante dans la charge totale du réseau continuera d'être diluée.
Essentiellement, ce que nous faisons, c'est : déplacer le travail loin des validateurs, et même loin des nœuds qui emballent les blocs, en poussant cette partie du travail vers ces nœuds hors chaîne situés entre « l'utilisateur envoie une transaction » et « le nœud qui emballe le bloc inclut réellement la transaction dans le bloc ».
Qu'est-ce que cela signifie pour Ethereum ?
D'un point de vue technique, cela signifie qu'Ethereum met à l'échelle de manière hyper-spécialisée une classe spécifique de calcul. Je pense que c'est aussi une tendance que nous verrons de plus en plus à mesure qu'Ethereum continue de se développer.
Ethereum, né il y a dix ans, s'est concentré sur le calcul entièrement général, mais manquait aussi complètement d'évolutivité. Donc ce que nous faisons maintenant, c'est diviser le calcul en différents types, puis rendre spécifiquement extrêmement évolutifs les types de calcul qui sont « naturellement plus adaptés à la mise à l'échelle » — nous construisons ces « petits outils » plus spécialisés pour accomplir cela.
En même temps, nous rendons également plus petites et plus faciles à gérer les computations qui doivent être traitées d'une manière moins efficace. L'EIP-8288 est précisément l'hyper-mise à l'échelle de deux types d'objets : la « vérification de signature » et la « vérification de preuve à divulgation nulle de connaissance ».
Un autre point intéressant est le suivant : je sais que beaucoup de personnes sont depuis longtemps curieuses de savoir quand Ethereum passera à RISC-V—car comparé à l'approche actuelle, RISC-V ou un autre jeu d'instructions plus moderne est bien plus efficace, et aussi beaucoup plus simple. Et l'EIP-8288 est très susceptible de devenir le premier scénario sur Ethereum qui introduit véritablement RISC-V (ou un jeu d'instructions similaire). La raison est que l'EIP-8288 permet aux utilisateurs de soumettre des preuves, et lorsque les utilisateurs soumettent des preuves, ils doivent utiliser un certain langage pour exprimer les affirmations qu'ils vérifient—RISC-V est exactement ce langage.
C'est-à-dire que la logique de vérification exprimée en RISC-V n'a besoin d'être exécutée que comme un seul calcul physique localement sur le client de l'utilisateur : l'utilisateur génère la preuve correspondante (dans les scénarios de confidentialité, il s'agit d'un ZK-STARK), puis la pousse immédiatement dans le mempool ; le premier nœud relais qui suit la compressera immédiatement de manière récursive avec des centaines ou des milliers de preuves similaires à travers le réseau en une seule entité.
Cela équivaut également à diviser l'ensemble du calcul en deux grandes catégories :
Une catégorie est celle des « dépendances »—c'est-à-dire les parties qui doivent être garanties correctes pour que la transaction soit valide ;
L'autre catégorie est la « logique métier »—c'est-à-dire ce que la transaction elle-même fait réellement.
La logique métier peut donc devenir plus légère et plus propre, ce qui signifie également que la partie de la logique de construction de blocs qui dépend de l'ordonnancement des transactions deviendra également plus simple. Et la partie « dépendances » peut être traitée en parallèle à une échelle extrêmement grande, avec presque aucun besoin de changements majeurs dans l'expérience de développement des développeurs Ethereum.
La valeur pratique pour les développeurs, les utilisateurs et la couche 2
Pour quiconque construit des applications on-chain, la signification centrale de tout cela est : les opérations les plus coûteuses aujourd'hui deviendront beaucoup moins chères.
La surcharge d'exécution des transactions résistantes aux attaques quantiques sera compressée à un niveau presque négligeable ;
Les applications préservant la confidentialité construites sur zk-SNARK/STARK échapperont aux contraintes des frais de Gas élevés, se généraliseront à un coût abordable et bénéficieront nativement d'une résistance quantique.
Au-delà des scénarios de confidentialité, l'efficacité d'application de zk-SNARK dans la mise à l'échelle (en particulier la couche 2) connaîtra un saut qualitatif. Actuellement, de nombreux ZK-Rollups, afin d'amortir le coût élevé en Gas de la publication des preuves d'état sur le réseau principal, sont souvent contraints d'allonger le cycle de soumission, réglant par lots à des fréquences de dix minutes ou même d'une heure. Cela limite sévèrement la vitesse de confirmation finale pendant les périodes de faible activité transactionnelle du réseau.
Actuellement, de nombreux ZK-Rollups, afin d'amortir le coût élevé en Gas de la publication des preuves d'état sur le réseau principal, sont souvent contraints d'allonger le cycle de soumission, réglant par lots à des fréquences de dix minutes ou même d'une heure. Cela limite sévèrement la vitesse de confirmation finale pendant les périodes de faible activité transactionnelle du réseau.
L'évolution finale : pousser complètement le calcul vers la périphérie
Enfin, s'il y a d'autres calculs que vous souhaitez effectuer mais qui sont trop coûteux à exécuter à l'intérieur de l'EVM, j'espère que nous pourrons véritablement commencer à changer de direction—ne plus faire porter directement par le protocole Ethereum lui-même tous les calculs que tout le monde souhaite effectuer, mais plutôt encourager les utilisateurs à accomplir cette partie du calcul localement sur leurs clients, puis à publier une preuve, afin que cette preuve soit vérifiée sur Ethereum.
Essentiellement, il s'agit de mettre à l'échelle Ethereum en déplaçant le calcul hors du « centre » de la chaîne et en le poussant vers la « périphérie ». Le résultat est le suivant : les choses qui sont les plus coûteuses sur Ethereum aujourd'hui (diverses formes de sécurité, diverses formes de confidentialité et diverses formes de compatibilité avec des applications externes) ne sont pas faites par les gens aujourd'hui parce qu'elles sont trop coûteuses, et à l'avenir elles deviendront toutes beaucoup moins chères et véritablement utilisables par tout le monde.
J'espère que ce n'est que la première étape pour transformer Ethereum, depuis l'architecture qu'il a presque utilisée depuis sa naissance, en une nouvelle architecture complètement différente et encore plus puissante — une nouvelle architecture qui combine véritablement deux choses : d'une part, l'idée très simple de la blockchain primitive de Satoshi Nakamoto ; d'autre part, la technologie cryptographique extrêmement puissante et extrêmement moderne que nous n'avons cessé d'accumuler depuis lors.
Participation à l'écosystème et progrès de la mise en œuvre
Actuellement, l'exploration précoce et la validation d'ingénierie autour de cette approche sont menées intensivement, et la communauté technique peut déjà participer à la construction à partir de multiples points d'entrée :
Modèles de simulation au niveau du réseau : des outils de simulation précoces pour la topologie du mempool et les mécanismes de propagation par agrégation ont été ouverts ;
Exploitation du testnet : le testnet EIP-8141 prenant en charge la forme de transaction par cadre a été mis en test ;
Concours d'optimisation d'algorithmes : des concours d'algorithmes spéciaux pour la communauté des développeurs sont en cours, axés sur la mise en œuvre efficace du système de preuve sous-jacent ;
Mise en œuvre et vérification du code : la base de code prototype sous-jacente a pris forme, pour que les développeurs de l'écosystème réalisent des implémentations clientes indépendantes et une vérification formelle.
Un grand nombre de pièces techniques sous-jacentes sont rapidement complétées. Les développeurs sont invités à participer en profondeur à ce processus technique et à aider cette architecture révolutionnaire à devenir un standard de réalité sur le réseau principal Ethereum dès que possible.
