sequencer example l2

Exemple de documentation de cumul

Ce référentiel contient un exemple de rollup qui s'intègre à Espresso Sequencer. L'exemple de cumul représente un simple magasin de comptes clé/valeur qui reçoit les transactions commandées d'Espresso, les exécute dans la VM de cumul et publie des preuves d'état fictives sur un contrat intelligent L1 (Ethereum). Le cumul contient une API simple pour soumettre des transactions et interroger les soldes des comptes.

Introduction

Espresso repose sur HotShot, un réseau qui parvient à un consensus sur des lots de transactions cumulées. À un niveau élevé, un rollup est une solution de mise à l'échelle L1 qui effectue des calculs coûteux hors chaîne. Dans le cas de zkRollups, un prouveur soumet périodiquement des points de contrôle d'état de cumul ainsi que des preuves par lots de validité de transaction au L1. L'exemple illustré ici est un zkRollup simulé. Pour en savoir plus sur les rollups Espresso, lisez nos documents

Exécution de l'exemple

Conditions préalables

Assurez-vous que docker est installé sur votre système.

Pour les distributions Linux, suivez les instructions officielles de votre distribution Linux ou consultez les instructions officielles du Docker.

Exécution de l'exemple de cumul sur le séquenceur Espresso

Nous devons d’abord démarrer un réseau local Espresso Sequencer.

 git clone https://github.com/EspressoSystems/espresso-sequencer
cd espresso-sequencer
docker compose pull
docker compose up -d --wait

Une fois cette opération terminée, déployez l’exemple de rollup, il peut être exécuté de manière native.

Pour exécuter nativement, une chaîne d’outils Rust est requise. Nous fournissons un shell nix pour installer toutes les dépendances. Nix peut être installé via le nix-installer. Une fois installé, exécutez ce qui suit à la racine du projet :

 nix develop
just dev-demo

Interagir avec la démo

Après avoir exécuté just dev-demo , vous pourrez voir new state event après quelques minutes.

1. Alice signe une transaction transférant des jetons de cumul à Bob. Alice envoie cette transaction au Rollup via le point de terminaison submit de l'API du rollup. Si Alice craint la censure, elle peut envoyer sa transaction directement au séquenceur.
2. Le serveur API de rollup transmet la transaction au séquenceur. La transaction est étiquetée avec l'ID d'espace de noms unique du cumul afin que le cumul puisse identifier ses propres transactions à l'étape 4.
3. Le réseau séquenceur traite la transaction, pour finalement l'inclure dans un bloc. Un nœud séquenceur soumet le nouvel état au contrat Light Client sur L1, qui vérifie qu'un consensus a été atteint sur le nouvel état.
4. Le service exécuteur reçoit une notification du nouvel état via un abonnement à un service de requête fourni par un nœud séquenceur.
5. L'exécuteur écoute également les en-têtes du nouveau bloc séquencé sur le réseau hotshot. Il récupère ensuite la preuve de l'espace de noms, le vid common et le hachage de bloc.
6. L'exécuteur traite ensuite les transactions en effectuant les étapes suivantes :
   • L'exécuteur applique les transactions à l'état de la VM. Avant l'application, chaque transaction est validée et les transactions invalides sont rejetées (un véritable cumul inclurait éventuellement des preuves d'invalidité de la transaction). Dans notre cas, le bloc contient une seule transaction d'Alice à Bob. Étant donné que la transaction contient une signature valide et qu'Alice dispose d'un solde suffisant, la transaction est appliquée avec succès et les soldes sont mis à jour.
   • Après l'application de la transaction, l'exécuteur met à jour l'état de la VM avec le nouvel engagement de bloc et l'engagement d'état précédent.
   • L'exécuteur calcule un nouvel engagement d'état et génère une fausse preuve que l'état a été mis à jour correctement par rapport à l'engagement du bloc HotShot.
7. L'exécuteur testamentaire publie la preuve au contrat rollup.
8. Le contrat de cumul vérifie la preuve en interrogeant le dernier engagement de bloc certifié du contrat de séquenceur. Remarque : Dans notre implémentation actuelle, nous n'effectuons pas beaucoup de vérification dans le contrat. À des fins de production, le contrat de cumul devra effectuer des vérifications supplémentaires auprès de l'état du client léger.
9. Bob interroge son solde à l'aide de l'API rollup et constate qu'il a reçu de nouveaux jetons. S'il s'agissait d'un véritable cumul, un Bob potentiellement méfiant pourrait vérifier son solde par rapport à l'engagement de l'état du contrat de cumul (l'exemple n'inclut pas cette fonctionnalité actuellement).

Architecture de cumul

État de cumul

L'état de l'exemple de cumul est le suivant :

• Comptes : un mappage des adresses ECDSA (style EVM) avec les soldes d'un jeton factice.
• Block Hash : hash du bloc de consensus hotshot le plus récent.
• Engagement d’état précédent : un engagement cryptographique sur l’état du rollup avant l’étape d’exécution la plus récente.
• VM : Informations sur la VM de Rollup. Pour l’instant, il s’agit d’une simple pièce d’identité.

Exécuteur

L'exécuteur est un service chargé de souscrire au nouvel état publié dans le contrat client léger L1, d'appliquer les transactions à l'état de cumul et de soumettre des preuves simulées au contrat de cumul. Les cumuls séparent souvent les rôles d'exécuteur et de prouveur en deux services distincts, mais cet exemple les combine par souci de simplicité.

API de cumul

L'API de cumul est une API REST qui inclut un point de terminaison submit et query .

Contrat cumulatif

Le contrat de cumul stocke l’engagement d’état de cumul le plus récent. Le contrat met à jour l'engagement de l'État lorsqu'il reçoit de l'exécuteur une preuve de transition d'état valide.

Espresso

Dans cet exemple, nous avons utilisé quelques composants Espresso comme décrit ci-dessous. Plus d'informations peuvent être trouvées dans la documentation

Client léger

Le client léger est un contrat intelligent qui vérifie l'intégrité de l'état du cumul. Le code du contrat peut être trouvé ici

Réseau Espresso

Nous avons géré un réseau expresso en utilisant les images docker du séquenceur expresso. Le réseau utilise hotshot pour parvenir à un consensus sur l'état du cumul. L'architecture peut être trouvée ici

Coup de chaud

Espresso Network utilise HotShot pour parvenir à un consensus sur l'état du cumul.