Vers la fin du jeu de l'Ethereum L1, la feuille de route à preuves multiples de Taiko
TechFlow SélectionTechFlow Sélection
Vers la fin du jeu de l'Ethereum L1, la feuille de route à preuves multiples de Taiko
Taiko estime que les preuves multiples dans le ZK peuvent jeter les bases d'une diversité de nœuds SNARKed à venir dans la couche 1 d'Ethereum.
Dédié à des analyses Web3 approfondiesRédaction : Taiko
Traduction : Frank, Foresight News
Récemment, nous avons publié un article intitulé « Pourquoi le multi-prover est important », expliquant l'importance des preuves multiples (multi-proofs) et présentant SGX comme l'une des options possibles.
Cet article s'inspire de notre X Space avec Vitalik et de son billet de blog suivant Enshrined ZK-EVM, qui présente la feuille de route globale de Taiko sur les preuves multiples : son rapport avec la fingame d'Ethereum, notre vision et notre plan pour y parvenir.
Nous considérons que les multi-proofs dans le contexte du ZK peuvent se traduire par l'utilisation de multi-SNARKs + multi-client, c'est-à-dire plusieurs preuves ZK-SNARK pour valider différents nœuds Ethereum, posant ainsi les bases d'une diversité future de nœuds SNARKés au niveau L1 d'Ethereum.
Pour justifier simplement l'approche multi-proof, deux points doivent être mentionnés :
-
Les preuves multiples permettent de couvrir les vulnérabilités et risques inhérents aux implémentations de nœuds et aux systèmes de preuve. Ainsi, même si une preuve venait à être compromise, il serait peu probable qu'une autre preuve autorise exactement la même faille ;
-
La fingame d'Ethereum suppose l'utilisation de preuves à connaissance nulle (ZK) pour valider L1 ;
À l'image de la diversité des implémentations de nœuds sur Ethereum, méthode ayant déjà sauvé à plusieurs reprises le réseau d'un effondrement, cela démontre la nécessité d'une validation multiple des blocs L1. Dans les cas ZK comme non-ZK, cela implique d'utiliser plusieurs nœuds et différents systèmes de preuve.
Système Multi-Client et Fin du L1
Comme décrit par Vitalik dans son article « What might an "enshrined ZK-EVM" look like? », il existe deux approches pour un système multi-client : « ouvert » et « fermé ».
-
Dans un système multi-client fermé, un ensemble fixe de preuves est défini au sein du protocole et inscrit sur une « liste blanche » pour générer des preuves. Selon la classification de Vitalik, toutes les solutions ZK L2 sont fermées, car elles n'acceptent que leurs propres implémentations de preuve ;
-
Dans un système multi-client ouvert, les preuves sont placées « en dehors du bloc » et vérifiées indépendamment par chaque nœud ; tout utilisateur peut utiliser le nœud de son choix pour valider un bloc ;
Si un utilisateur souhaite vérifier un bloc, dans l’implémentation la plus simple, il exécute directement le nœud correspondant pour réexécuter le bloc, ou demande une preuve de validité à un Prover connu. Si un certain nombre de preuves conformes aux critères de la « liste blanche » sont reçues, le bloc est considéré comme valide. Mais que faire si aucune preuve à connaissance nulle (ZKP) conforme à la « liste blanche » n’est disponible, et que nous voulons éviter la réexécution ? Quel type de ZKP devrions-nous alors utiliser ?
Selon la vision de Vitalik, cette question doit être résolue hors-protocole via un consensus social (ou cryptoéconomique) :
Au niveau de la couche de consensus, nous ajoutons une règle de vérification : un bloc n’est accepté que si chaque modification d’état incluse a été prouvée valide. Cette preuve doit être un ZK-SNARK démontrant que la sérialisation des transaction_and_witness_blobs forme bien une séquence (Bloc, Témoignage), et que l’exécution du bloc à partir de pre_state_root et du témoignage (i) est correcte et (ii) produit le bon post_state_root. Potentiellement, un nœud peut choisir d’attendre M preuves sur N de types variés.
Imaginons un Builder honnête détenant un bloc de type 1 souhaitant en prouver la validité ; plusieurs solutions existent déjà au niveau L2, telles que Polygon, zkSync et Scroll.
Supposons que leurs ZK-EVM aient évolué jusqu’au type 1, soient réputées fiables et éprouvées en production. Le Builder choisira alors parmi ces systèmes de preuve disponibles, et ceux qui valident son bloc exécuteront le logiciel de vérification correspondant, idéalement en générant plusieurs types de preuves et en effectuant des vérifications croisées. Étant donné une spécification commune du L1, toute divergence entre validateurs transformera la validation du bloc en question de consensus, que le système ouvert réglera par accord collectif.
Les systèmes de preuve gagneront en influence en convainquant les utilisateurs de leur fiabilité, plutôt qu’en convaincant le processus de gouvernance du protocole.
Selon Vitalik, cela signifie que l’écosystème ZKP s’ouvre à un marché libre. Avec les bons incitations, les implémentations existantes de L2 pourraient concurrencer sur le marché des preuves L1.
Faisabilité de Taiko dans les preuves multiples
Dans le protocole Taiko, un Proposer doit trouver un Prover pour proposer un bloc, et le Prover désigné doit déposer des TKO comme garantie afin d’assurer la bonne livraison de la preuve. Le protocole Taiko ne précise pas comment le Proposer trouve ou rémunère le Prover : ils pourraient même se rencontrer en personne et payer en espèces.
Ainsi, notre chaîne d'approvisionnement fonctionne comme un marché libre, où le Proposer peut choisir n'importe quel Prover selon ses préférences.
Outre les avantages économiques, certaines caractéristiques techniques font de Taiko un choix idéal pour un système multi-client :
-
Taiko est un ZK-EVM de type 1, offrant deux avantages : premièrement, en matière de diversité d'exécution, les implémentations EVM existantes (comme Geth, Besu, Reth, etc.) peuvent être directement utilisées au niveau L2 ; deuxièmement, pour tester la faisabilité d'une conception basée sur L1, nous avons besoin d'un ZK-EVM standardisé permettant une validation multi-client ouverte, car les validateurs doivent parvenir à un consensus sur la même transformation. Dans ce cas, le ZK-EVM de type 1 est le meilleur choix, car il suit explicitement les spécifications d'Ethereum. Concernant la logique spécifique aux rollups, Vitalik a également mentionné comment modifier un ZK-EVM via des précompilations, et l'utilisation de celles-ci suffit à supporter la conception BBR (Based Booster Rollup) de Taiko ;
-
Taiko publie la disponibilité des données sur Ethereum, contrairement à certains L2 qui explorent des alternatives. Dès lors que les données sont publiées sur L1, Taiko peut facilement s'adapter à la proposition d'implémentation de Vitalik, qui introduit la ZKEVMClaimTransaction pour couvrir la transition d'état, la preuve et la disponibilité des données ;
Taiko fonctionne sur plusieurs systèmes de preuve, et son réseau test actuel prend déjà en charge le ZK-EVM du PSE, SGX et Reth. L'infrastructure est configurée pour s'adapter à plusieurs nœuds d'exécution et systèmes de preuve, comme discuté dans la dernière section. Sur cette base, Taiko structurera ses preuves à zéro connaissances autour d'une compilation modulaire.
Une feuille de route modulaire et ouverte
Modularité
Dans le contexte des preuves à zéro connaissances (ZKP), compte tenu du multi-client, Taiko utilise des compilateurs modernes pour obtenir des composants universels comme Risc-V ou WASM. Ces instructions sont ensuite converties en représentations arithmétiques adaptées à divers systèmes de preuve (AIR ou PIL), puis encodées via différents SNARKs sur les trajectoires arithmétisées.
En résumé, ce flux représente la méthode la plus viable dans un système multi-proof, car elle tire parti des avantages des deux côtés. Durant la compilation des nœuds, les compilateurs modernes offrent les bénéfices suivants :
-
Les mises à jour des nœuds sont indépendantes des circuits de preuve, car il n’est pas nécessaire d’implémenter de nouveaux circuits pour chaque EIP ou fork dur : seul le maintien à jour du code source est requis ;
-
Les optimisations de code sont obtenues gratuitement grâce à des chaînes d’outils comme LLVM ;
-
La compilation croisée favorise davantage de diversité ; dans l’exemple ci-dessus, Taiko compile Geth ou Reth vers les jeux d’instructions RISC-V ou WASM, offrant déjà quatre systèmes de preuve distincts ;
La compilation SNARK constitue un axe clé du développement futur de Taiko. Notez que cette approche n’est pas limitée à un seul protocole ZK lors de l’arithmétisation (PLONK, R1CS) ou du codage sur des backends comme Halo2, eSTARK ou Supernova. Contrairement aux ZK-VM/EVM monolithiques, qui implémentent un backend spécifique à un ZKP donné, l’adoption croisée de composants entre projets pousse l’ensemble de la pile technique vers une modularité accrue.
Étant donné la rapidité des avancées en recherche ZKP, la flexibilité prime sur l’implémentation immédiate des derniers résultats. Pour rester agile, Taiko collabore avec des projets comme Powdr Labs et Risc Zero pour développer des pipelines de compilation croisée et pousser à l’extrême la modularité.
Pour les lecteurs techniques, voici quelques avantages supplémentaires :
-
Nous pouvons optimiser le compilateur pour cibler différents backends, par exemple en privilégiant les portes de haut degré (high-degree gates) ou en utilisant davantage de paramètres de recherche ;
-
Des circuits accélérateurs comme les fonctions de hachage Keccak et Poseidon peuvent être implémentés sous forme de bibliothèques ;
-
Nous pouvons intégrer progressivement des fonctionnalités ZK (comme LogUp) dans le langage et activer le support backend correspondant ;
-
Intégrer de nouveaux frameworks ZK backend pour gagner en rapidité — dans de nombreux projets ZK orientés recherche, seules des preuves de concept sont développées en code, rendant leur usage en production difficile. En confiant au compilateur une partie cruciale du travail, nous pouvons appliquer facilement des frameworks encore à un stade précoce ;
-
Les circuits backend existants, comme les composants PSE ZK-EVM écrits en Halo2, peuvent toujours être réutilisés par appel direct ;
Grâce à ces collaborations, Taiko a déjà intégré zeth et le ZK-VM de Risc Zero dans son développement, et a développé un backend SGX supplémentaire. Les ingénieurs de Taiko intègreront également Powdr dans le système multi-proof, développeront le langage et les bibliothèques PIL, optimiseront la compilation, ajouteront davantage de backends et travailleront sur des accélérations de bas niveau. Au niveau matériel, la couche d'accélération ZK de Taiko (ZAL) vise à standardiser la collaboration entre les systèmes de preuve (Halo2, Arkworks, Risc Zero, Polygon, etc.) et les bibliothèques d'accélération (CPU, GPU, FPGA, etc.).
Ouverture
Plus il y a de nœuds, de systèmes de preuve et de backends intégrés, plus le système est ouvert. C’est pourquoi Taiko s’efforce de rassembler toute la communauté. L’équipe de Taiko entretient depuis longtemps des relations de collaboration avec d’autres projets, notamment avec le PSE sur le ZK-EVM et Risc Zero.
En construisant désormais une pile ZK plus modulaire, Taiko peut abstraire efficacement les API pour une meilleure accessibilité et intégration. Taiko agira comme une plateforme pour déployer des systèmes de preuve en production et les tester en conditions réelles sur la blockchain. Taiko invite sincèrement tous les projets à rejoindre cet effort commun pour améliorer la technologie ZK.
Stack Taiko
Une infrastructure scalable et flexible est essentielle au paradigme multi-proof de Taiko.
Les preuves de validité ZK proviennent du journal d’exécution (Execution Trace) du nœud et des preuves de stockage (Storage Proofs), utilisés pour construire les données-témoins (witnesses) et les entrées publiques. Il est important de noter que les witnesses sont spécifiques à chaque preuve, tandis que les entrées publiques sont liées au protocole. Disposer d’une infrastructure robuste pour générer les witnesses est crucial. Nous utilisons donc un hôte léger pour extraire le journal d’exécution depuis un multi-client, puis le convertir en plusieurs witnesses destinés aux différents systèmes de preuve.
Du côté preuve, cette architecture supporte à la fois les piles modulaires et monolithiques, tout en extrayant les mêmes entrées publiques depuis le nœud cible (actuellement Geth).
À l’avenir, si les formats de journaux d’état sont compatibles, Geth pourra être remplacé par un autre nœud dans le rôle de nœud Taiko. De plus, le nœud léger exécuté sur le système de preuve (actuellement Reth) pourra être remplacé par toute implémentation capable de compiler vers un langage d’assemblage compatible.
Points clés
-
Taiko considère que preuves multiples = multi-client + multi-SNARKs (ainsi que des environnements d’exécution sécurisés comme SGX) ;
-
Le protocole Taiko s’adapte parfaitement à un système multi-client grâce à une chaîne d’approvisionnement ouverte pour les preuves multiples, une exécution de type 1 et la publication de la disponibilité des données sur L1 ;
-
Taiko envisage une architecture multi-proof modulaire et ouverte, collaborant avec Powdr Labs pour tirer parti de la compilation croisée entre nœuds et ZKP, avec Risc Zero pour exécuter Taiko sur leur ZK-VM et TEEs, et continuera d’améliorer conjointement le projet ZK-EVM avec le PSE ;
-
L’infrastructure flexible de Taiko inclut à la fois des piles ZKP modulaires et monolithiques ;
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@taikoxyz
