Taiko pense que plusieurs preuves dans ZK peuvent jeter les bases de la diversité des nœuds SNARKed dans Ethereum L1 à l’avenir.
Texte sélectionné : Taiko
Compilé par : Frank, Foresight News
Il n’y a pas si longtemps, nous avons partagé un article détaillé intitulé “Pourquoi le multi-preuve est important”, expliquant l’importance des multi-preuves (Multi-Proofs) et considérant SGX comme l’une des options pour les multi-preuves.
Cet article a été inspiré par notre travail avec Vitalik sur X Space et son article de blog ultérieur sur la feuille de route globale de Taiko pour la multi-épreuve : son rapport avec la phase finale d’Ethereum, quelle est notre vision et où nous irons. Comment y parvenir.
Nous pensons que la multi-preuve dans ZK peut être transformée en l’utilisation de multi-SNARK + multi-client, c’est-à-dire en utilisant plusieurs ZK-SNARK pour prouver une variété de nœuds Ethereum différents, ce qui fournira une diversité de nœuds SNARK dans Ethereum L1 dans l’avenir. Poser les fondations.
Pour fournir une justification très simple à des preuves multiples, nous devons mentionner deux points :
- Plusieurs preuves peuvent couvrir les vulnérabilités et les risques dans les implémentations de nœuds et les systèmes de preuves, donc en cas de vulnérabilité, même si une preuve est compromise, d’autres preuves sont moins susceptibles de permettre d’exploiter exactement la même vulnérabilité ;
- La fin du jeu d’Ethereum est de supposer que la preuve de connaissance nulle (ZL) est utilisée pour vérifier L1 ;
Semblable à la mise en œuvre multi-nœuds d’Ethereum, cette approche a évité l’effondrement du réseau à plusieurs reprises, prouvant que les blocs L1 nécessitent une approche multi-vérification. Pour les scénarios ZK et non-ZK, cela signifie utiliser plusieurs nœuds et différents systèmes de preuve.
Système multi-client et fin de partie L1
Comme Vitalik le décrit dans son article « À quoi pourrait ressembler un « ZK-EVM consacré » ? », il existe deux approches des systèmes multi-clients : « ouvert » et « fermé ».
- Dans un système multi-client fermé, un ensemble fixe de preuves est connu dans le protocole et est inclus dans la « liste blanche » pour générer des preuves. Selon la classification de Vitalik, tous les ZK L2 sont fermés car ils n’acceptent que les preuves de leur propre implémentation ;
- Dans un système multi-client ouvert, la preuve est placée “à l’extérieur du bloc” et vérifiée par chaque nœud séparément. Tout utilisateur peut utiliser n’importe quel nœud qu’il souhaite pour vérifier le bloc ;
Si l’utilisateur a besoin de vérifier un certain bloc, l’implémentation la plus simple consiste à exécuter directement le nœud correspondant pour réexécuter le bloc, ou à demander un certificat de validité à un prouveur connu. Si un certain nombre de certificats répondant aux critères de la « liste blanche » sont reçus, le blocage est considéré comme légitime. Cependant, s’il n’existe pas de preuve à connaissance nulle (ZKP) répondant aux critères de la « liste blanche » et que nous voulons éviter une réexécution, quelle preuve à connaissance zéro devrions-nous utiliser ?
Selon la vision de Vitalik, ce problème est résolu par un consensus social (ou cryptoéconomique) en dehors du protocole :
Sur la couche consensus, nous avons ajouté une règle de validation : un nœud n’acceptera un bloc que s’il a vu une preuve valide pour chaque changement d’état dans le bloc. La preuve doit être une preuve ZK-SNARK, utilisée pour prouver que la connexion de transaction_and_witness_blobs est la sérialisation de paires (Block, Witness), et l’exécution du bloc basée sur pre_state_root et Witness (i) est valide et (ii) affiche le post_state_root correct. Potentiellement, les nœuds pourraient choisir d’attendre plusieurs types de preuves M-of-N.
Imaginez qu’un constructeur honnête dispose d’un bloc de type 1 qu’il souhaite valider ; la couche L2 propose déjà plusieurs options, telles que Polygon, ZkSync et Scroll.
En supposant que leurs ZK-EVM ont été développés pour le type 1 et sont réputés et testés au combat, alors le constructeur choisira parmi ces systèmes de preuve disponibles, et la personne validant son bloc exécutera le logiciel de vérification correspondant, et enfin c’est bon pour créer plusieurs types de preuves et les vérifier plusieurs fois. Étant donné la même spécification de chaîne L1, si un validateur n’est pas d’accord, la vérification des blocs devient une question de consensus et le système ouvert parviendra à la cohérence des résultats de vérification grâce au consensus.
Les systèmes de preuve gagneront en influence en convainquant les utilisateurs de leur faire confiance, et non en convaincant le processus de gouvernance du protocole.
Selon Vitalik, cela signifie que l’écosystème ZKP s’ouvre à la commercialisation directe. S’il existe des incitations, les implémentations L2 existantes peuvent rivaliser sur le marché de la certification L1.
La faisabilité de Taiko dans plusieurs preuves
Dans le protocole Taiko, le proposant doit trouver un prouveur pour proposer un bloc, et le prouveur désigné déposera TKO en guise de dépôt pour s’assurer qu’il n’y a aucun problème avec la preuve qu’il délivre. L’accord Taiko ne précise pas comment le proposant trouve et rémunère le prouveur, ils pourraient donc même se rencontrer en personne et échanger en espèces.
Notre chaîne d’approvisionnement fonctionne donc comme un marché libre et les proposants peuvent choisir n’importe quel prouveur de leur choix.
En plus des avantages économiques, certaines caractéristiques techniques rendent Taiko idéal pour les systèmes multi-clients :
- Taiko est un ZK-EVM de type 1 avec deux avantages : premièrement, en termes de diversité d’exécution, les implémentations EVM existantes (telles que Geth, Besu, Reth, etc.) peuvent être directement appliquées à L2 ; deuxièmement, pour les tests basés sur Pour la faisabilité de la conception L1, nous avons besoin d’un ZK-EVM standardisé pour une vérification multi-client ouverte, car les vérificateurs doivent parvenir à un consensus et vérifier les résultats sur la base de la même transformation. Dans ce cas, le ZK-EVM de type 1 serait le choix le plus approprié car il suit explicitement la spécification Ethereum. Concernant la logique spécifique du Rollup, Vitalik a également mentionné comment modifier ZK-EVM via la prise en charge de la pré-compilation, et l’utilisation de ces pré-compilations est suffisante pour prendre en charge la conception BBR (Based Booster Rollup) de Taiko ;
- Taiko publie la disponibilité des données sur Ethereum, contrairement à certains L2 qui explorent des options alternatives de disponibilité des données. Tant que les données sont publiées sur L1, Taiko peut facilement s’adapter à la proposition d’implémentation de Vitalik, qui introduit ZKEVMClaimTransaction pour couvrir les transitions d’état, les attestations et la disponibilité des données ;
Taiko fonctionne sur plusieurs systèmes de preuve et le réseau de test existant prend déjà en charge ZK-EVM, SGX et Reth de PSE. L’infrastructure est configurée pour accueillir plusieurs nœuds d’exécution et systèmes d’attestation, qui seront abordés dans la dernière section. En s’appuyant sur cette infrastructure, Taiko se concentrera sur la compilation modulaire en termes de preuves à connaissance nulle.
Une feuille de route modulaire et ouverte
Modularité
Taiko exploite des compilateurs modernes pour des composants courants tels que Risc-V ou WASM en pensant au multi-client dans le contexte des Zero-Knowledge Proofs (ZKP). Ces instructions sont ensuite converties en représentations arithmétiques pour différents systèmes de preuve (AIR ou PIL), et enfin les traces d’exécution arithmétique sont codées à l’aide de différents SNARK.
En bref, ce processus constitue l’approche la plus réalisable dans un système multi-preuves car il tire parti du meilleur des deux mondes. Pendant le processus de compilation des nœuds, les compilateurs modernes nous apportent les avantages suivants :
- Les mises à niveau des nœuds sont indépendantes de la preuve car il n’est pas nécessaire d’implémenter des circuits pour les derniers EIP ou hard forks, il suffit de garder le code source à jour ;
- L’optimisation du code peut être obtenue gratuitement à partir de chaînes d’outils comme LLVM ;
- La compilation croisée produit plus de diversité ; en prenant l’exemple ci-dessus comme exemple, Taiko a compilé Geth ou Reth dans le jeu d’instructions RICS-V ou WASM et dispose déjà de quatre jeux de certificats ;
La compilation SNARKs est au centre du développement futur de Taiko. Veuillez noter que lors du codage de méthodes arithmétiques telles que PLONK et R1CS avec des backends tels que Halo2, eSTARK ou Supernova, elles ne sont pas limitées à un seul protocole ZK ; tandis que le ZK-VM/EVM monolithique effectue des implémentations backend pour des ZKP spécifiques. À mesure que de plus en plus de projets adoptent les composants des autres pour améliorer les performances, la pile technologique globale deviendra probablement modulaire.
Étant donné que le domaine de recherche du ZKP se développe rapidement, la flexibilité est plus importante que la mise en œuvre directe des derniers résultats. Pour maintenir la flexibilité, collaborez sur des projets comme Powdr Labs et Risc Zero pour travailler sur des pipelines de compilation croisée et les rendre aussi modulaires que possible.
Pour les lecteurs férus de technologie, voici les avantages spécifiques :
- Nous pouvons optimiser le compilateur pour différents objectifs back-end, comme favoriser les « portes de haut degré » ou utiliser davantage de paramètres de recherche ;
- Les circuits d’accélération comme les fonctions de hachage Keccak et Poséidon peuvent être implémentés sous forme de bibliothèques ;
- Nous pouvons progressivement ajouter des fonctionnalités ZK (telles que LogUp) au langage et activer la prise en charge backend correspondante ;
- Intégrez le nouveau framework backend ZK pour devenir plus rapide. Dans certains projets ZK axés sur la recherche, seules les preuves de concept sont développées sous forme de code, ce qui les rend difficiles à utiliser dans des environnements de production. En laissant le compilateur faire le gros du travail, nous pouvons facilement appliquer les frameworks des étapes précédentes ;
- Les circuits back-end existants, tels que le composant PSE ZK-EVM écrit dans Halo2, peuvent toujours être réutilisés via des appels directs ;
Dans un effort de collaboration, Taiko a intégré Zeth et ZK-VM de Risc Zero pendant le développement et a développé un backend SGX supplémentaire pour celui-ci. Les ingénieurs de Taiko intégreront également Powdr dans des systèmes multi-épreuves, développeront le langage et les bibliothèques PIL, optimiseront la compilation, ajouteront davantage de backends et effectueront une accélération générale de bas niveau. Au niveau matériel, la Zero-Knowledge Acceleration Layer (ZAL) de Taiko vise à normaliser la relation collaborative 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 vous avez de nœuds, de systèmes de preuve et de backends intégrés, meilleure est l’ouverture, c’est pourquoi Taiko s’efforce de rassembler l’ensemble de la communauté. L’équipe Taiko a une longue histoire de collaboration avec d’autres projets, par exemple avec PSE sur ZK-EVM. et Risc Zero coopèrent.
Désormais, en créant une pile ZK plus modulaire, Taiko peut efficacement extraire l’API pour une meilleure ubiquité et intégration. Taiko servira de plate-forme pour expédier des systèmes de preuve en production et pour des tests en direct en chaîne. Taiko invite sincèrement tous les projets à se joindre à la création d’une meilleure technologie sans connaissance.
Pile Taiko
Une infrastructure évolutive et flexible est essentielle au paradigme multi-épreuve de Taiko.
La source de la preuve de validité ZK est le journal d’état du nœud (ution Trace) et les preuves de stockage (Storage Proofs), qui sont utilisées pour construire les données des témoins (témoins) et les entrées publiques. Notez que les témoins sont spécifiques à la preuve, tandis que les contributions du public sont spécifiques au protocole. Il est important de disposer d’une infrastructure solide pour gérer la génération de témoins. Par conséquent, nous utilisons un hôte léger pour effectuer des journaux d’état à partir de Multi-Client et les convertir en divers témoins à fournir au système de certification correspondant.
Du côté de la preuve, la conception prend en charge les piles modulaires et monolithiques, tandis que nous extrayons les mêmes entrées communes du nœud cible (actuellement Geth).
À l’avenir, Geth en tant que nœud Taiko pourra être remplacé par un autre nœud si le format du journal d’état est compatible. De plus, les nœuds légers exécutés sur le système de preuve (actuellement Reth) peuvent également être remplacés par toute implémentation compilée dans un langage assembleur acceptable.
Points clés
- Taiko croit aux preuves multiples = Multi-Client + plusieurs SNARK (et TEE comme SGX) ;
- Le protocole Taiko est très adapté aux systèmes multi-clients car il dispose d’une chaîne d’approvisionnement ouverte multi-épreuves avec exécution de type 1 et publie la disponibilité des données sur L1 ;
- Taiko envisage une architecture multi-épreuves modulaire et ouverte, travaillant avec Powdr Labs pour tirer parti de la compilation croisée de Node et ZKP, et travaillant avec Risc Zero pour implémenter l’exécution de Taiko sur leurs ZK-VM et TEE, Taiko Nous continuerons également travailler avec PSE pour améliorer le projet ZK-EVM ;
- L’infrastructure flexible de Taiko comprend des piles ZKP modulaires et monolithiques ;
