Une transaction doit suivre le processus répétable « soumission → séquençage → confirmation du consensus → visibilité de l’état » avant d’être reconnue comme « confirmée » par d’autres chaînes, bridges ou applications dans un environnement multichaîne. Espresso Network (ESP) agit comme une couche de base partagée pour la confirmation et le règlement, recevant les blocs des séquenceurs de Rollup. Le réseau de validateurs utilise HotShot pour garantir une approbation BFT en quelques secondes, rendant les blocs confirmés par Espresso accessibles en aval.
Ce processus résout la problématique du séquençage des confirmations : les applications n’ont plus à attendre le règlement final sur Ethereum L1 pour obtenir une séquence vérifiable et une vue d’état ; le règlement L1 peut toujours suivre les règles du bridge. Comprendre à quel moment chaque étape est déclenchée et comment les confirmations sont relayées permet de clarifier les limites pour la lecture d’état cross-chain.
Quelles sont les conditions nécessaires pour qu’une transaction entre dans Espresso ?
Avant qu’une transaction n’emprunte le chemin de confirmation d’Espresso, le système concerné doit être prêt à l’intégration : l’environnement cible doit être connecté à Espresso ; un séquenceur autorisé (ou un équivalent) doit être en place ; la transaction doit être acceptée selon les règles d’exécution et de séquençage de l’environnement. Espresso ne remplace pas la couche d’exécution de chaque environnement, mais fournit une confirmation décentralisée pour la sortie du séquenceur.
| Élément de préparation |
Vérification principale |
Impact si non prêt |
| Intégration de l’environnement |
Le Rollup/l’application est-il intégré à Espresso ? |
Le bloc ne peut pas entrer dans la couche de confirmation |
| Séquenceur autorisé |
Un séquenceur est-il autorisé à soumettre des blocs à Espresso ? |
La soumission et la file d’attente ne peuvent pas démarrer |
| Acceptation de la transaction |
La transaction a-t-elle été acceptée selon les règles du mempool/séquençage ? |
Aucun bloc ne peut être soumis à confirmation |
| Consommateur en aval |
Les bridges, applications ou solvers sont-ils abonnés à la vue de confirmation ? |
Confirmation effectuée mais non lisible entre environnements |
Ce tableau montre que la confirmation de second niveau nécessite la combinaison « intégration + soumission autorisée + lecture en aval ». L’utilisateur constate généralement que « la transaction a été soumise à un Rollup », alors que le système doit inclure cette transaction dans un bloc destiné à Espresso.
Le processus débute lorsqu’un utilisateur ou une application soumet une transaction à un Rollup (ou autre environnement d’exécution). La transaction entre dans la file d’attente de l’environnement. Un séquenceur autorisé trie et regroupe les transactions en blocs ou lots selon les règles locales, puis les soumet à Espresso. Espresso reçoit le flux de blocs du séquenceur, et non les transactions individuelles des utilisateurs.
Pendant cette étape, l’interface peut afficher « reçu » ou « pré-confirmé » : il s’agit de retours du séquenceur du Rollup ; la confirmation Espresso n’a pas encore eu lieu. En interne, le séquenceur verrouille l’ordre des lots, génère un bloc à soumettre et l’envoie via l’interface d’intégration. Ce processus est répétable : les nouvelles transactions sont regroupées et soumises à mesure de leur arrivée.
Si le séquenceur est retardé, censuré ou ne soumet pas comme requis, la transaction reste dans la file d’attente locale et l’aval ne peut pas voir la Finalité Espresso. Le caractère centralisé ou non du séquençage est une problématique structurelle abordée dans la comparaison des couches de séquençage partagées ; ici, l’accent est mis sur « ce qui se passe après la soumission et comment la confirmation est obtenue ».
Une fois le bloc entré dans Espresso, le réseau de validateurs exécute le consensus HotShot : dans un cadre de Preuve d’enjeu (PoS) et de Tolérance aux fautes byzantines (BFT), il valide l’ordre des blocs et la disponibilité des données (DA). HotShot est conçu pour réagir rapidement : confirmer dès que les conditions réseau le permettent. Les sources publiques indiquent que la confirmation sur mainnet prend généralement quelques secondes.
La confirmation est déclenchée lorsque les validateurs ayant un poids suffisant votent pour le bloc proposé. Une fois le seuil atteint, le bloc devient confirmé par Espresso, avec sa séquence et son engagement finalisés au niveau consensus. L’exécution reste du ressort de chaque Rollup ou environnement applicatif, qui effectue la transition d’état pour la séquence confirmée ; Espresso n’exécute pas la logique métier.
| Étape du processus |
Condition de déclenchement |
Action du système |
Changement visible utilisateur/application |
| Soumission |
Le séquenceur regroupe et soumet un bloc |
Le bloc entre dans le chemin de confirmation Espresso |
Affiche souvent « en traitement/pré-confirmé » |
| Confirmation HotShot |
Les validateurs atteignent le seuil de vote BFT |
Le bloc atteint la Finalité Espresso |
La vue de confirmation Espresso est accessible |
| Lecture en aval |
Bridge/application abonné aux résultats de confirmation |
La logique cross-environnement avance selon la séquence de confirmation |
Les actions cross-chain sont déclenchées par l’état de confirmation |
| Règlement L1 (ultérieur) |
Selon les règles on-chain du bridge/contrat |
Lot correspondant soumis sur Ethereum L1, etc. |
Règlement final L1 effectué (délai plus long) |
Ce tableau distingue la « confirmation de second niveau » (par le consensus HotShot sur Espresso) et le « règlement final L1 ». Ce dernier peut continuer comme prévu, mais le protocole peut exiger que seuls les blocs validés par Espresso soient éligibles au règlement sur le L1 de bridging.
Figure 1. Chemin principal de confirmation Espresso : soumission utilisateur/application → regroupement par le séquenceur Rollup → confirmation par les validateurs HotShot → consommation de la Finalité par Rollup/bridge/application.
La participation des validateurs à la confirmation dépend du staking et des incitations du protocole ; le staking ESP et les frais de protocole expliquent le rôle d’ESP pour le staking des validateurs et le paiement des frais, essentiels au fonctionnement de la couche de confirmation, sans modifier la séquence décrite.
Après la confirmation HotShot, les blocs confirmés par Espresso deviennent interrogeables en quelques secondes. Les nœuds Rollup, soumetteurs de lots, composants de bridge, protocoles de messagerie, solvers et autres applications on-chain peuvent utiliser des services de requête ou des flux d’événements pour accéder à la séquence confirmée et à l’engagement d’état, mettant ainsi à jour leur « état confirmé » pour l’environnement.
Le relay ne signifie pas que les résultats d’exécution sont poussés à toutes les chaînes, mais qu’une source de vérité partagée et vérifiable est fournie : quiconque lit la confirmation en premier peut faire avancer la logique cross-environnement selon ses propres règles. Les contraintes du protocole garantissent que seuls les blocs validés par Espresso sont acceptés lors du règlement L1 de bridging, empêchant toute réécriture de la séquence confirmée par les séquenceurs. Pour les utilisateurs, cela signifie que les opérations cross-chain sont disponibles plus rapidement ; pour les systèmes, la couche de confirmation fournit des faits intermédiaires avant le règlement final L1.
En quoi cela diffère-t-il de « l’attente du règlement final Ethereum L1 » ?
En s’appuyant uniquement sur le règlement final Ethereum L1, les lots de Rollup doivent attendre la finalité L1 avant que les bridges et applications cross-chain ne considèrent l’état comme sécurisé : ce processus prend généralement plus de dix minutes. Le chemin Espresso permet la confirmation BFT en quelques secondes après la soumission du séquenceur, permettant à l’aval de lire plus tôt l’état de confirmation, le règlement L1 restant un ancrage de sécurité ultérieur.
| Dimension |
Chemin de confirmation Espresso |
Attente du seul règlement final Ethereum L1 |
| Entité de confirmation |
Réseau de validateurs HotShot (BFT) |
Finalité du consensus Ethereum L1 |
| Délai typique |
Quelques secondes |
Généralement plus de dix minutes |
| Quand l’aval peut lire |
Immédiatement après confirmation Espresso |
Généralement seulement après finalité L1 |
| Relation avec le séquenceur |
Chaque environnement conserve son séquenceur, validé par une couche décentralisée |
Les lots vont directement sur L1, au rythme du L1 |
| Contraintes d’ambiguïté |
Peut exiger que les lots de règlement correspondent à la confirmation Espresso |
Dépend des contrats L1 et des fenêtres de preuve |
Ce tableau met en évidence la différence entre « qui fournit en premier un engagement de séquence fiable » et « quand les bridges et applications initient des actions cross-environnement ». Espresso n’élimine pas le règlement L1 mais insère une couche de confirmation rapide et répétable entre les deux.
Figure 2. Chemin Espresso vs chemin de règlement L1 seul : à gauche, les bridges/applications lisent après la confirmation HotShot de second niveau ; à droite, les actions sont prises après la finalité L1.
Quels sont les risques et points de défaillance de ce processus ?
Des points de défaillance existent lors de la soumission, du consensus et de la consommation aval. Si le séquenceur censure, tombe en panne ou retarde la soumission, les transactions ne peuvent pas accéder à HotShot ; si le réseau de validateurs n’atteint pas le seuil de vote, la confirmation est retardée ou bloquée ; si l’aval ne s’abonne pas à la vue Espresso, la logique cross-chain peut continuer à suivre l’ancien calendrier, même si l’utilisateur voit un succès.
Les risques structurels incluent : la sécurité de la couche de confirmation dépend de la distribution du staking et des hypothèses BFT ; la Finalité Espresso et le règlement final L1 sont deux frontières de sécurité distinctes : si les applications assimilent la confirmation de second niveau à la finalité L1, elles risquent de mal calibrer les paramètres de bridging et de règlement ; des défauts d’intégration ou de requête peuvent entraîner des états « confirmés mais non lisibles ». Ces risques relèvent des limites du mécanisme, et non d’un conseil en investissement.
Résumé
La confirmation de second niveau sur Espresso Network est un processus répétable : les transactions sont acceptées par l’environnement Rollup, regroupées et soumises par un séquenceur autorisé ; les validateurs HotShot achèvent la confirmation BFT en quelques secondes ; les blocs confirmés par Espresso sont immédiatement accessibles pour la lecture par Rollup, bridge et application ; le règlement final L1 peut toujours suivre les règles de correspondance. L’analyse des déclencheurs et points de défaillance pour la soumission, la confirmation et le relay montre que la « Finalité de second niveau » est une conception de séquence de confirmation, et non un événement isolé.
FAQ
Qu’est-ce qu’Espresso Network ?
Espresso Network sert de couche de base partagée pour la confirmation et le règlement dans les environnements multichaînes et applicatifs. Chaque environnement conserve ses propres règles d’exécution et de séquençage ; après soumission des blocs à Espresso, les validateurs fournissent une Finalité rapide via HotShot, accessible aux autres chaînes et bridges.
Comment Espresso atteint-il la Finalité de second niveau ?
Après la soumission des blocs à Espresso par des séquenceurs autorisés, les validateurs exécutent le consensus HotShot, validant l’ordre des blocs et la disponibilité des données une fois le seuil BFT atteint. Les sources publiques indiquent des temps de confirmation de quelques secondes, permettant à l’aval de lire les vues de confirmation sans attendre le règlement final Ethereum L1.
Qu’est-ce que le consensus HotShot ?
HotShot est le protocole de consensus tolérant aux fautes byzantines utilisé par Espresso Network pour parvenir rapidement à un accord entre validateurs sur l’ordre et la disponibilité des blocs. Il est conçu pour une confirmation rapide lorsque les conditions réseau sont favorables, offrant la Finalité de second niveau pour les Rollups et applications, sans exécuter les transactions lui-même.
Comment Espresso améliore-t-il la vitesse de confirmation cross-chain ?
Les bridges cross-chain, protocoles de messagerie et solvers peuvent lire directement les blocs confirmés par Espresso pour obtenir des vues d’état confirmées des chaînes intégrées, sans attendre la clôture de la fenêtre de finalité L1. Grâce à l’avancement du séquençage de confirmation, les actions cross-environnement peuvent démarrer plus tôt, tandis que le protocole garantit que les lots de règlement on-chain correspondent à la confirmation Espresso.
Quels sont les risques liés à l’utilisation d’Espresso ?
Les principaux risques incluent l’échec ou la censure de la soumission par le séquenceur, le consensus des validateurs n’atteignant pas le seuil à temps, des erreurs dans les composants de requête et d’intégration, et la confusion entre la Finalité Espresso et le règlement final L1, ce qui peut conduire à des erreurs d’appréciation des frontières de sécurité. La couche de confirmation dépend également du staking et des hypothèses BFT ; une interruption à tout stade peut empêcher l’aboutissement du chemin de « confirmation de second niveau ».
