Salut à tous, dans l'écosystème Ethereum actuel, que ce soit avec les Optimistic Rollups ou les ZK Rollups, on maintient un système de validation sur des chaînes personnalisées qui est extrêmement lourd et à haut risque. Chaque correction de bug dans la machine virtuelle de base nécessite un long et dangereux processus de mise à jour de la gouvernance décentralisée.
Récemment, un projet révolutionnaire a émergé sur le forum de recherche Ethereum (ethresear.ch) : il propose de généraliser l'EIP-8025 et d'introduire un nouvel EIP pour ajouter une primitive de "Vérification de Preuve Native" au niveau de la couche de base d'Ethereum.
Si cette proposition est mise en œuvre, les futurs Rollup n'auront plus besoin de déployer des contrats intelligents de validation complexes on-chain, mais pourront directement "profiter" de l'infrastructure de validation de la couche de consensus d'Ethereum (CL). Cela réduira non seulement considérablement le code redondant sur le réseau principal d'Ethereum, mais élèvera également la sécurité et la logique de mise à niveau des Ethereum L2 à des niveaux sans précédent.
Cet article vous décompose la logique centrale de cette proposition technique, son mécanisme de mise en œuvre et ses implications profondes pour l'avenir de la piste d'évolutivité.
1. Analyse des points de douleur : le "talon d'Achille" actuel du système de validation des Rollup
Dans le paradigme d'évolutivité actuel, chaque Ethereum L2 est comme un "royaume" indépendant, se battant chacun de leur côté, ayant construit une infrastructure de validation extrêmement complexe sur L1.
Des contrats complexes sur la chaîne : Les ZK Rollup doivent déployer des contrats de validation pour zkVM spécifiques (machine virtuelle à connaissance nulle), des adaptateurs et des planificateurs ; les Optimistic Rollup nécessitent de déployer de vastes machines virtuelles pour la preuve de fraude et la logique de jugement des litiges.
Coûts de maintenance élevés et risques de sécurité : Ces contrats sont maintenus indépendamment par leurs équipes respectives. Si un bug est découvert dans le système de preuves ou la machine virtuelle sous-jacente, l'équipe de développement doit exécuter une mise à jour du contrat via une signature multiple personnalisée (Multi-sig) ou un vote DAO.
Efficacité répétitive dans l'écosystème : Il existe une grande quantité de duplication dans l'écosystème Ethereum, où différents projets maintiennent des bibliothèques de code de validation similaires, consommant non seulement d'énormes frais de gaz, mais amplifiant également l'exposition à la sécurité dans tout le réseau.
Prenons l'exemple d'un Rollup utilisant une architecture "multi-preuves (Multi-proof)" ; pour atteindre un niveau de sécurité optimal, il pourrait être nécessaire de déployer jusqu'à six contrats sur L1 (y compris des validateurs zkVM d'origine provenant de différents fournisseurs, des adaptateurs personnalisés, un planificateur de multi-preuves, etc.). Toute mise à niveau dans l'une des étapes serait un véritable cauchemar, où tirer un seul fil entraînerait un enchevêtrement de conséquences.
2. La rupture clé : généralisation de l'EIP-8025, introduction de primitives de validation générales
L'EIP-8025 a été conçu à l'origine pour la statelessness (absence d'état) d'Ethereum L1, introduisant une infrastructure de vérification des preuves zkVM au niveau de la couche de consensus (CL). Cependant, le design initial était trop "égoïste", servant uniquement à la vérification de charges d'exécution spécifiques au réseau principal d'Ethereum.
L'astuce de la nouvelle proposition est la suivante : puisque la couche de consensus a déjà un moteur de preuves, un protocole de diffusion et une logique de validation, pourquoi ne pas l'ouvrir à tous les contrats intelligents ?
Cette proposition réalise cet objectif par deux changements fondamentaux :
Généralisation complète du moteur de validation de la couche de consensus (CL)
Proposition de détacher la partie liée à la logique spécifique d'Ethereum dans l'EIP-8025, afin de rendre l'infrastructure de vérification des preuves sous-jacente "indépendante des programmes spécifiques (Program-agnostic)".
Le nouveau conteneur de preuve est divisé en deux dimensions clés :
Type d'identifiant backend (Backend Type) : Sert à indiquer à la couche de consensus quel type de système de preuves sous-jacent doit être utilisé (par exemple, un type de zkVM spécifique).
Hachage de programme (Program Hash) : Sert à identifier de manière unique le programme client spécifique en cours d'exécution.
Ainsi, le moteur de validation de la couche de consensus agit comme une "prise universelle" ; tout Rollup, même les protocoles de confidentialité ou les processeurs zk, peuvent se connecter à ce réseau de validation tant qu'ils fournissent la bonne prise (identifiant backend et hachage de programme).
2. Nouvelle "Transaction à preuve porteuse (Proof-carrying Transaction)"
Pour permettre aux contrats intelligents de la couche d'application de percevoir et d'utiliser les résultats de validation de la couche de consensus, la proposition introduit un tout nouveau type de transaction ainsi que trois nouveaux codes d'opération (Opcode) associés :
Réforme au niveau de la transaction : Le nouveau corps de transaction contient une liste de preuves supplémentaires (enregistrant le hachage du programme et le type de backend) ainsi qu'un hachage de sortie publique.
Réduction de la charge au niveau des contrats intelligents : La proposition ajoute trois opcodes qui ne nécessitent pas de calculs cryptographiques complexes (respectivement utilisés pour lire le hachage du programme, le hachage de sortie publique et le nombre de preuves).
Restructuration des flux de travail : Lorsque ce type de transaction à preuve porteuse se propage dans le pool de mémoire, les nœuds du réseau et les constructeurs de blocs seront responsables d'exécuter les lourdes vérifications mathématiques en arrière-plan. Une fois la transaction empaquetée dans un bloc, le contrat intelligent n'a qu'à appeler les nouveaux opcodes mentionnés ci-dessus pour confirmer de manière "légère" si la preuve est valide.
3. Transition de paradigme : "Publication du client" remplace la "gouvernance on-chain"
L'introduction de ce mécanisme entraînera un changement architectural fondamental.
Dans le passé, si la bibliothèque de base zkVM utilisée par le Rollup rencontrait une faille de sécurité, l'équipe du Rollup devait se précipiter pour proposer une mise à jour, en suivant le processus de gouvernance on-chain pour mettre à niveau le contrat de validation sur L1.
Dans le paradigme de "validation de preuve native", tout le travail de validation lourd est déchargé sur le logiciel client d'Ethereum L1 (comme Geth, Nethermind, etc.). Lorsque le zkVM de base nécessite une réparation, l'équipe de développement du client d'Ethereum n'a qu'à publier une nouvelle version du logiciel. Après la mise à jour du logiciel du nœud Ethereum, le bug est naturellement corrigé.
C'est comme si le système d'exploitation mettait à jour les correctifs de sécurité sous-jacents, tous les logiciels qui s'exécutent en haut en bénéficieraient automatiquement, sans que chaque développeur de logiciel ait à réécrire son code. Le Rollup réalise véritablement l'héritage du mécanisme de mise à niveau de sécurité d'Ethereum L1.
Quatrième, les implications profondes pour la piste L2
Selon les estimations brutes dans la proposition, si ce mécanisme natif est adopté, les principaux Rollups actuels (y compris l'évolutivité optimiste basée sur WASM ou MIPS, ainsi que l'évolutivité de validité basée sur divers zkVM) pourraient éliminer entre 20 % et 50 % du code logique de base on-chain.
Le complexe empilement de validateurs de plusieurs milliers de lignes pourra être réduit à un simple contrat "boîte de réception (Inbox)". Ce contrat n'a qu'à utiliser les nouveaux opcodes pour vérifier si le nombre de preuves est conforme et si le hachage du programme est dans sa liste blanche pour confirmer.
En même temps, ce mécanisme résout élégamment le problème de l'orchestration des "multi-preuves (Multi-proof)". Les preuves de différents backends peuvent être empaquetées au niveau de la couche de transaction et validées en parallèle par la couche sous-jacente, les contrats intelligents n'ayant plus besoin d'écrire du code en "pâtes italiennes" pour coordonner plusieurs systèmes de preuves.
Conclusion : Passer des "contrats on-chain personnalisés" se battant chacun de leur côté vers des "primitives natives de la couche de consensus" est le chemin inévitable pour la maturation et la modularisation de l'écosystème Ethereum.
Bien que cette proposition nécessite encore des discussions sur des détails tels que "la garantie de stabilité du hachage du programme (c'est-à-dire comment effectuer la maintenance de code de base de manière régulière sans changer l'identifiant on-chain)", la direction qu'elle indique - rendre les Rollups plus légers, plus sûrs et plus étroitement liés à la couche de consensus de base d'Ethereum L1 - offre sans aucun doute une solution futuriste très imaginative pour la piste d'évolutivité, qui est actuellement enlisée dans une impasse de gouvernance et une inflation du code.
⚠️ 【Avertissement】Le contenu de cet article ne vise qu'à expliciter la technologie de base et le modèle économique, et ne constitue pas un conseil en investissement. Les transactions sur les dérivés cryptographiques comportent des risques élevés, veuillez toujours évaluer votre capacité à supporter le risque et prendre des décisions prudentes.
🌹 Si vous avez aimé cette analyse approfondie, n'hésitez pas à aimer, suivre, commenter et partager ! Votre soutien est notre plus grande motivation pour continuer à produire du contenu.
