En résumé ;

• =nil; est un zkRollup shardé - un nouveau concept de L2 pour l'évolutivité dynamique et sécurisée d'Ethereum grâce à une exécution parallèle des transactions au niveau du protocole à travers les shards.
• Équipé de zkSharding, =nil; offre une mise à l'échelle horizontale sans compromettre les avantages d'une seule couche d'exécution, à savoir la liquidité unifiée et la sécurité économique.
• =nil; permet aux applications une pleine composabilité avec Ethereum grâce à un accès transparent et vérifiable aux données Ethereum.
• =nil; introduit un zkEVM de type 1 compilé avec zkLLVM.
• La génération rapide de preuves est garantie par la concurrence sur le marché ouvert à travers le =nil; Le marché des preuves - un marché de génération de preuves sans permission.

Introduction à zkSharding

Aujourd'hui, les solutions de couche 2 font un compromis entre la scalabilité et la fragmentation de l'état. Nous introduisons un design de couche 2 (L2), =nil;, qui repousse les limites de la scalabilité d'Ethereum sans compromettre les avantages d'un environnement d'exécution unifié. La solution combine un mécanisme de sharding dynamique avec un accès vérifiable aux données d'Ethereum, sécurisé par des technologies de connaissance nulle. Les éléments clés incluent:

• zkRollup avec Sharding : Le cœur de =nil; est un protocole de sharding probant, permettant une scalabilité horizontale sans compromettre la sécurité ou l'efficacité. Cette approche aborde certaines des limites actuelles de la scalabilité verticale (L3, L4, etc.), à savoir la fragmentation des données et de la liquidité.
• Accès direct aux données Ethereum : La possibilité d'appeler les données d'origine d'Ethereum depuis les applications de couche 2 nous permet de réutiliser les applications déjà déployées. L'accès direct aux données de L1 depuis L2 garantit un environnement plus unifié et homogène.

À travers zkSharding =nil; bénéficie des avantages des conceptions monolithiques et modulaires, y compris :

• Scalabilité

  • Aucune limitation de scalabilité car l'exécution est parallèle. Le débit est estimé à environ 60k transferts ERC-20 par seconde avec environ 400 nœuds.
  • Génération de preuves compétitive via le Proof Market offre la L1-finalité la plus rapide et les coûts de génération de preuves les moins chers.

• Environnement d'exécution unifié

  • L'environnement d'exécution unifié garantit l'absence de fragmentation de la sécurité/liquidité car chaque fragment est une partie de l'ensemble du cluster.
  • Réduction d'un besoin de migrer la liquidité depuis Ethereum car =nil; offre un accès transparent à ses données pour les applications en obligeant chaque validateur à conserver un état complet d'Ethereum comme partie du déploiement permettant aux applications d'accéder directement aux données depuis le zkEVM de =nil;.

• Sécurité

  • Transitions d'état sécurisées par zkEVM compilées via zkLLVM. Il fournit une sécurité vérifiable (par exemple, sécurité des contraintes) car le code est facilement inspectable puisque les circuits zkEVM sont compilés à partir d'une implémentation EVM utilisée en production dans un langage de haut niveau et non écrits manuellement.
  • Décentralisé dès le premier jour grâce à la génération de preuve décentralisée activée par =nil; Proof Market.

• Fonctionnalité

  • Un zkEVM de type 1, zkEVM entièrement équivalent au bytecode EVM compilé via zkLLVM.
  • Un environnement adapté aux applications ayant des exigences élevées en matière de temps, de mémoire et de complexité algorithmique en renforçant une cohérence à un seul fragment et en introduisant un regroupement d'applications par fragment pour réduire la latence. Les exemples incluent les échanges décentralisés, les marchés de preuves, les séquenceurs/constructeurs décentralisés, les applications à état partagé (alias mondes autonomes, etc.).

Évolutif, scalable et composable

Au niveau inférieur, l'état de =nil; est partitionné en shard primaire et plusieurs shards secondaires. Le rôle du shard principal est de synchroniser et consolider les données des shards secondaires. Il utilise Ethereum à la fois comme couche de disponibilité des données et comme vérificateur des preuves de transition d'état, similaire aux opérations typiques de zkRollups.

Les shards secondaires fonctionnent comme des "ouvriers", exécutant les transactions des utilisateurs. Ces shards maintiennent une liquidité et des données unifiées grâce à un protocole de messagerie inter-shard, éliminant toute fragmentation entre eux.

Chaque fragment est supervisé par un comité de validateurs. Il y a une rotation périodique de ces validateurs à travers les fragments. De plus, les mises à jour de l'état d'un fragment sont vérifiées sur le fragment principal en utilisant zkEVM.

Pour illustrer le flux de transaction de l'initiation par un utilisateur à la confirmation sur Ethereum, considérez les étapes suivantes :

• L'utilisateur signe une transaction (tx) et l'envoie sur le réseau.
• Les validateurs dans le fragment S, où se trouve le portefeuille de l'utilisateur, placent les transactions dans le mempool.
• Ces validateurs créent ensuite un nouveau bloc B(1/S)
• Le hachage de B(1/S) est enregistré sur le shard principal dans le bloc B(1/M)
• Une preuve de transition d'état pour B(1/S) est produite et vérifiée par le shard principal dans le bloc B(2/M)
• Une preuve de transition d'état pour B(2/M) est envoyée à Ethereum pour vérification et couplée avec les données nécessaires pour garantir la disponibilité des données.
• Une fois ce processus terminé, tx obtient confirmation par Ethereum.

Cet outline suppose que la transaction de l'utilisateur n'active pas le protocole de messagerie inter-shard. Cependant, dans ce cas, le flux de la transaction reste le même avec la différence qu'une transaction d'utilisateur peut déclencher la création de nouvelles transactions sur d'autres shards.

Avec tous les comptes étant répartis entre les fragments, cela peut sembler similaire au problème de fragmentation des données rencontré dans l'approche des rollups spécifiques à l'application. Cependant, la différence clé réside dans la manière dont la communication entre les fragments est gérée : elle est intégrée directement dans le protocole global, plutôt que d'être gérée par des ponts externes séparés.

Pour garantir la sécurité de chaque shard secondaire, son comité de validateurs est tenu de prouver ses transitions d'état au shard primaire pour s'assurer qu'aucune fraude n'a eu lieu au sein d'un groupe de validateurs plus petit. Chaque comité de validateurs de shard a des tâches supplémentaires au-delà de la maintenance du shard. Les validateurs sont responsables du suivi de types spécifiques d'événements, à savoir les messages entre shards, au sein des "shards proches". Les shards proches sont déterminés en fonction de la distance de Hamming dans les identifiants de shard.

zkEVM via zkLLVM : Type-1 Sécurisé, Vérifiable et Performant zkEVM

=nil;s zkEVM est un zkEVM de type 1 compilé avec zkLLVM. Pour comprendre les différences entre les zkEVM plus traditionnels et le zkEVM de =nil;, nous devons discuter des limitations associées au processus de définition de circuit qui sous-tend les zkEVM. Le circuit zkEVM est une partie critique, responsable de la preuve de transition d'état pour être considéré comme correct, étant généralement défini avec un zkDSL personnalisé ou simplement une bibliothèque. Cette méthode de définition de circuit soulève des problèmes liés à :

• Sécurité: Problèmesen raison de la taille d'un circuit et de la réplication manuelle de la logique EVM.
• Auditabilité : Limitéeauditabilitéetinspectabilitéen raison de la complexité et de la non-explicité des zkDSLs utilisés.
• Capacité de mise à niveau : Complexité de la maintenance et de la mise à niveau en raison des exigences de définition des contraintes manuelles. En cas de modification de l'EVM - la majorité des circuits zkEVM devraient être refaits et réaudités à partir de zéro.
• Compatibilité : La complexité de la mise en œuvre du circuit zkEVM bytecode-compatible réel (alias Type-1) se traduit souvent par des limitations pour les applications en raison des différences de comportement entre zkEVM et le comportement réel de l'EVM.

=nil; zkEVM adresse efficacement tous ces défis en étant :

• Sécurisé : Un circuit doit être automatiquement généré à partir du même code de haut niveau utilisé dans les nœuds Ethereum réellement en production pour garantir qu'aucune différence d'algorithme n'est présente.
• Auditable: Un circuit doit être représenté dans un langage de programmation de haut niveau (alias C++ ou Rust) qui doit être écrit de manière à être facilement lisible par un développeur moyen.
• Upgradeable: Un circuit doit être défini de telle manière que tout changement au sein de l'EVM soit facilement traduisible/compilable en un circuit zkEVM prouvant/définissant exactement le même comportement. Aucune nécessité de recompilation complète ou de ré-audit ne devrait découler d'une telle mise à niveau.
• Compatible avec le bytecode (alias Type-1) : La compilation des circuits à partir de langages de haut niveau apporte une compatibilité totale avec le bytecode et le comportement de l'EVM, réduisant considérablement le temps de mise sur le marché des applications EVM et le temps/efforts de développement nécessaires pour atteindre une telle compatibilité.

zkEVM compilé via zkLLVM est sécurisé par conception, en tirant parti d'evmone pour garantir une cohérence totale avec l'EVM utilisé en production sur Ethereum. Le zkLLVM (C++ ou Rust) se compile automatiquement en circuit, ce qui signifie que les erreurs humaines sont éliminées du processus de définition du circuit.

De plus, parce que =nil; zkEVM est compilé via zkLLVM, il est naturellement plus flexible (et donc, à l'épreuve du futur) que les circuits définis manuellement car il est facilement ajustable et la génération de circuits est automatique. Il est également plus auditable, ce qui signifie que sa sécurité ne se fait pas au détriment de l'inclusion des derniers EIP ajoutés à Ethereum.

zkRollup avec la sécurité et la disponibilité des données d'Ethereum

Comme le fragment principal et les fragments secondaires diffèrent en ce qui concerne leurs tâches dédiées - les fragments secondaires se concentrent sur le traitement des transactions tandis que le fragment principal se concentre sur la synchronisation des données - ils ont des approches différentes de la disponibilité des données (DA), ce qui aide à récupérer les données d'état dans des situations d'urgence. Cela signifie :

• La shard principale utilise Ethereum comme son DA.
• Les shards secondaires ont la possibilité d'utiliser Ethereum ou de choisir de ne pas avoir un DA distinct.

Cet arrangement est établi en lançant deux types de shards au début : ceux avec une solution DA externe distincte et ceux sans. Dans les phases suivantes, seuls les shards de la même catégorie DA peuvent être fusionnés. Cela signifie que lors de sa création, chaque compte doit être associé à une catégorie DA spécifique.

De plus, ce cadre peut être étendu pour inclure d'autres types de DA.

Accès transparent aux données Ethereum

Un de nos objectifs principaux est d'optimiser la composabilité des applications et d'éviter la fragmentation de la liquidité, donc naturellement l'approche zkSharding serait incomplète sans un accès sans confiance à l'état d'Éthereum. Cela signifie =nil; offre une pleine composabilité et une intégration transparente avec Éthereum grâce au module Data Provider.

Le fournisseur de données fonctionne de manière indépendante du stockage des données du shard, synchronise ses informations avec une base de données externe et injecte l'empreinte digitale d'Éthereum de l'état de la dernière base de données surveillée (représentée par le hachage de bloc d'Éthereum) dans le bloc du shard. L'état le plus récent de cette base de données reçoit une validation du module de confirmation, qui utilise un zkBridge avec la preuve de consensus Casper FFG d'Éthereum.

Qu'est-ce qui suit :

=nil; et zkSharding sont le fruit des produits que la Fondation =nil; a développés au cours des 4 dernières années. Son objectif est d'être la première solution composable, évolutive et universelle de couche 2 zkRollup pour Ethereum. Nous sommes impatients de partager plus de détails sur la mise en œuvre au cours des prochains mois. Assurez-vous de suivre notre Twitter pour rester informé de nos progrès !

Pour les personnes techniquement inclinées, nous avons développé un manuel séparé et completqui explore en détail zkSharding. Ce manuel est votre passerelle pour comprendre les subtilités de cette approche, équipé de tous les détails techniques et préliminaires dont vous avez besoin.

Plongez maintenant dans notre introduction technique et participez à la conversation surDiscordetTelegram. Explorons ensemble les possibilités illimitées du zkSharding !

Avertissement：

1. Cet article est reproduit à partir de [nil.foundation]. Tous les droits d'auteur appartiennent à l'auteur original [nil.foundation]. If there are objections to this reprint, please contact the Apprendre Gateéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité: Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, il est interdit de copier, distribuer ou plagier les articles traduits.