*Transférer le titre original：Exploration du pont Ethereum canonique et du système de validation d'Eclipse

Aperçu de notre pont canonique

Eclipse se compose de trois couches :

1. Exécution : un fork du client Solana Labs (v1.17) pour l'exécution des transactions SVM
2. Règlement : Notre pont canonique définissant la règle du choix des fourchettes d'Eclipse existe sur Ethereum, où des preuves de fraude seront également soumises
3. Disponibilité des données : Eclipse publie les données nécessaires pour prouver les fraudes sous forme de blobs de données sur Celestia

Le schéma ci-dessous montre comment ces modules interagissent :

La suite de cet article se concentrera sur le pont Ethereum d'Eclipse, comme le montre le schéma. Blobstream transmettra les attestations signées par le validateur de Celestia pour certifier à Ethereum que les données d'un lot de machines à sous Eclipse ont été publiées correctement. Cela permet à Eclipse Bridge de vérifier les données fournies pour prouver les fraudes par rapport aux racines de données signées par Celestia. Dans la suite de cette section, nous présenterons les processus par lesquels :

1. les fonds sont déposés via notre pont,
2. des blocs de données contenant des lots de blocs d'Eclipse sont publiés sur Celestia,
3. les retraits via le pont sont gérés, et
4. des preuves de fraude sont générées dans le pire des cas.

Déposer via le pont Ethereum natif d'Eclipse

Le flux lorsqu'un utilisateur effectue un dépôt sur Eclipse via le pont Ethereum natif se résume comme suit :

1. Un utilisateur appelle le contrat Deposit Bridge d'Eclipse sur Ethereum
2. Depuis l'exécuteur SVM d'Eclipse [1], le relais [2] observe l'adresse de dépôt et de destination de l'utilisateur
3. Ensuite, le relais appelle le programme SVM Bridge, qui est chargé de transférer le dépôt d'un utilisateur vers l'adresse de destination applicable
4. Le relais vérifie la transaction de dépôt via un client zk-light (à implémenter)
5. Enfin, le bloc contenant la transaction de transfert après le dépôt suivante est finalisé et publié via un plugin Solana Geyser

Le schéma ci-dessous montre les interactions entre Ethereum, Celestia et le SVM Executor pendant le flux de dépôt décrit ci-dessus :

Publier les machines à sous d'Eclipse sur Celestia sous forme de data blobs

Le flux de publication de lots de machines à sous d'Eclipse vers Celestia sous forme de blocs de données est résumé ci-dessous :

1. L'exécuteur SVM publie chaque slot Eclipse dans la file d'attente des messages via Geyser
2. L'exécuteur SVM envoie des lots de machines à sous d'Eclipse à Celestia sous forme de blocs de données
3. Le kit de validation Celestia produit des engagements concernant les blocs de données soumis, qui peuvent être utilisés pour prouver l'inclusion d'une transaction sur la chaîne d'Eclipse par rapport à la racine des données
4. Les racines de données contenues dans chaque en-tête de bloc Celestia sont transmises au contrat de bridge d'Eclipse sur Ethereum via Blobstream

Le schéma ci-dessous de Celestia explique comment l'engagement des données d'un bloc Celestia donné est enregistré dans l'en-tête du bloc :

Retrait et envoi de preuves de fraude sur le pont Ethereum d'Eclipse

À l'instar des autres L2 qui utilisent des preuves de fraude (Arbitrum, Fuel, et bien d'autres), les retraits depuis Eclipse nécessitent une période de défi au cours de laquelle les vérificateurs peuvent soumettre des preuves de fraude en cas de transition d'état non valide :

1. À un rythme régulier, l'exécuteur de la SVM publie un engagement en faveur d'une époque (un nombre prédéterminé de lots) des machines à sous d'Eclipse sur Ethereum, ainsi que des garanties
2. Le contrat relais d'Eclipse effectue quelques vérifications de base pour s'assurer que les données publiées sont correctement formatées (décrites dans la section Fraud Proof Design)
3. Si le lot soumis passe ces contrôles de base, il existe une fenêtre prédéfinie pendant laquelle les vérificateurs peuvent publier des preuves de fraude au cas où l'engagement du lot impliquerait une transition d'état non valide
4. Si un vérificateur publie une preuve de fraude réussie, il obtient la garantie de l'exécuteur testamentaire, le lot publié est rejeté et l'état canonique de l'Eclipse L2 est rétabli jusqu'au dernier engagement de lot valide. Dans ce cas, la gouvernance d'Eclipse aurait la capacité d'élire un nouvel exécuteur testamentaire
5. Si la période de défi arrive à expiration sans preuve de fraude, l'exécuteur testamentaire récupère sa garantie et une récompense
6. Par conséquent, le contrat de bridge Eclipse permettra désormais de finaliser toutes les transactions de retrait incluses dans le lot finalisé

Design résistant aux fraudes

Dans cette dernière section, nous allons détailler la conception du système anti-fraude d'Eclipse, inspiré par Anatoly Yakovenko et John Adler. En général, pour toute preuve de fraude, un vérificateur doit :

1. Identifier une transaction contenant une transition d'état non valide
2. Fournissez les entrées de cette transaction avec la transition d'état non valide
3. Démontrez que la réexécution de cette transaction avec les entrées données donne une sortie qui n'est pas égale à celle qui a été validée sur la chaîne

Dans le cas d'Eclipse, (1) Celestia diffuse des lots de blocs publiés par l'exécuteur SVM d'Eclipse, ce qui permet de prouver l'inclusion des transactions via les témoins de Merkle. Pour (2), contrairement aux L2 basés sur EVM, qui publient une racine Merkle dans l'arbre des états global, pour des raisons de performances, Eclipse ne met pas à jour un arbre d'état global transaction par transaction, mais nous expliquerons comment nous garantissons l'exactitude des entrées plus en détail ci-dessous. Enfin, dans le cas de (3), le vérificateur d'Eclipse génère une preuve zk des résultats d'une transaction donnée, contrairement à l'approche de jeu de vérification interactive courante sur les L2 basés sur EVM.

Toutes les transactions Eclipse peuvent être représentées comme la prise d'une liste de comptes d'entrée, l'exécution d'une transaction et la production d'une liste des comptes de sortie qui en résultent :

Le point essentiel de notre conception anti-fraude est que pour l'exécution des transactions, chaque S_InputAccount doit toujours être le S_OutputAccount d'une transaction précédente. Cela nous permet de faire référence à la dernière transaction de la chaîne qui a produit un compte d'entrée donné au lieu de fournir un témoin Merkle à un arbre des états mondial. Grâce à notre conception, nous avons introduit d'autres types d'accusations de fraude, par exemple une référence à la non-validité de la transaction précédente ou au fait que le compte saisi a déjà été « dépensé » par une transaction ultérieure. Nous décrivons ce processus plus en détail ci-dessous :

Entrées des transactions publiées sur Celestia

1. Données de transaction (publiées par le séquenceur)
2. Les données de transaction (publiées par l'exécuteur de la SVM) qui contiennent les informations suivantes :
   1. Nombre de transactions [3]
   2. Emplacement des données de transaction dans l'espace de noms Celestia
   3. Hash du compte [4] pour chaque saisie, le nombre de transactions étant attribué à chaque
   4. Liste des sysvars utilisés et valeur de chacune, avec le nombre de transactions correspondant à chacune (le cas échéant) [5]
   5. Sortie de la transaction, si la transaction a été réussie ; sinon, un indicateur indiquant que la transaction a échoué (soit parce qu'elle n'a pas pu être analysée, soit parce qu'elle n'a pas pu être exécutée)

Engagements par lots publiés sur The Ethereum Bridge

De plus, les engagements des lots de données de transactions publiés sur Celestia sont transmis au contrat Ethereum. Les engagements sont les suivants :

1. L'espace de noms Celestia où se trouvent les données de transaction de la dernière transaction incluse dans le lot
2. L'espace de noms Celestia où se trouvent les données d'exécution [6] de toutes les transactions incluses
3. Une liste des dépôts, des retraits et des annulations, chacun étant accompagné du nombre de transactions de la transaction Eclipse associée

Critères pour un lot non valide

Comme expliqué plus haut, un lot peut être considéré comme incorrect de plusieurs manières :

1. L'un des emplacements de l'espace de noms Celestia lié est mal formé ou ne pointe pas vers des données du type requis
2. Il y a une transaction sur Celestia sans aucune donnée d'exécution associée, ce qui peut être dû à deux raisons :
   1. La transaction, qui devait être la plus récente du lot, n'est associée à aucune donnée d'exécution.
      1. Dans ce cas, un vérificateur vérifie que c'est bien le cas et le contrat de bridge Ethereum vérifie que la dernière entrée de la liste des données d'exécution ne correspond pas aux bonnes données de transaction
   2. Les données d'exécution d'une autre transaction sont manquantes
      1. Un vérificateur publie l'espace de noms Celestia où se trouvent les données de transaction de la transaction incriminée et des transactions précédentes et suivantes dans l'ordre qui a été exécuté avec succès. Ensuite, le contrat-relais vérifie que cette transaction a été ignorée
3. Les données d'exécution d'une transaction sont incorrectes, ce qui peut être dû à ce qui suit :
   1. Le nombre de transactions associé au hachage d'un compte ou à Sysvar ne produit pas le résultat revendiqué.
      1. Dans ce cas, un vérificateur publie l'emplacement des données d'exécution de la transaction en question dans l'espace de noms Celestia avec le décompte correspondant, et le contrat de passerelle vérifie que la valeur donnée est incorrecte.
   2. Le nombre de transactions associé au hash ou au sysvar d'un compte est obsolète
      1. Un vérificateur publie l'emplacement des données d'exécution d'une nouvelle transaction dans l'espace de noms Celestia, en modifiant la valeur en question, et le contrat de passerelle vérifie qu'il s'agit bien d'une transaction plus récente.
   3. Le résultat de la transaction est incorrect, ou la transaction utilise une entrée qui n'est pas répertoriée :
      1. Dans ce cas, une preuve ZK attestant de la bonne exécution de la transaction ou une preuve ZK indiquant que la transaction utilise une entrée qui n'est pas répertoriée est nécessaire. Cela peut être obtenu de deux manières :
         1. Un vérificateur publie la preuve, ou
         2. Un vérificateur publie l'index de la transaction prétendument frauduleuse, et le contrat de bridge Eclipse l'utilise pour demander un zk-proof à Bonsai de RISC Zero
   4. Il y a eu un dépôt d'Ethereum il y a plus de N lots, mais il n'y a aucun dépôt correspondant dans la liste des transactions (inclus dans l'engagement par lots inscrit au contrat relais) pour les N derniers lots. Sinon, il y a un dépôt dans la liste des transactions sans aucune transaction de dépôt Ethereum associée, ou la transaction existe mais a déjà été incluse dans un autre lot Eclipse
      1. Dans tous ces cas, le contrat-relais peut déterminer que cela s'est produit et considérer un tel lot comme non valide
   5. Un dépôt ou un retrait est effectué sans aucune inscription correspondante dans la liste des transactions
      1. Dans ce cas, un vérificateur publie l'emplacement des données d'exécution données dans l'espace de noms Celestia, et le contrat de passerelle vérifie ce fait pour considérer la transaction comme non valide
   6. Il y a un dépôt ou un retrait dans la liste des transactions dont la transaction Eclipse associée n'effectue pas l'action attendue ou dont le nombre de transactions ne se situe pas dans la fourchette de transactions attendue. Dans ce cas, l'une des situations suivantes se produirait :
      1. Le pont déterminerait automatiquement que c'est le cas et refuserait le lot correspondant
      2. Un vérificateur remarque la transition d'état non valide et publie la preuve de la transaction incriminée, qui est ensuite vérifiée par le contrat-relais

Si un lot d'engagements s'avère incorrect, le contrat de relais Eclipse ramènera le pont à celui du dernier engagement de lot dont la véracité est prouvée. Notez que les transactions ne sont jamais supprimées de la chaîne, même en cas de fraude. Seul l'engagement doit donc être recalculé.

Réflexions d'adieu

Cet article avait pour but de fournir un guide de haut niveau sur le pont Eclipse qui minimise la confiance sur Ethereum et d'expliquer en détail notre conception anti-fraude. Compte tenu de la nature modulaire de notre L2 et de la naissance de notre infrastructure technologique, nous continuerons à publier des articles et de la documentation sur différents aspects d'Eclipse dans les semaines à venir.

Pour participer à Eclipse Testnet, veuillez suivre nos instructions ici. Vous pouvez nous contacter sur Twitter ou Discord pour toute question spécifique concernant notre Testnet, notre bridge ou pour des questions techniques.

Notes de bas de page

[1] : Le nœud qui calcule les résultats des transactions SVM et applique le résultat final au nouvel état d'Eclipse

[2] : Un opérateur qui transmet les événements en chaîne entre Ethereum et Eclipse

[3] : Notez que c'est l'exécuteur qui publie ceci, et non le séquenceur. S'il était inclus dans les données publiées par le séquenceur, cela ne ferait que compliquer le compte, empêchant ainsi l'exécuteur de faire son travail correctement. Cela pourrait être compensé par la conception anti-fraude, mais cela ajouterait de la complexité. Le deuxième avantage du fait que seul l'exécuteur testamentaire publie le décompte est que cela permet de transférer facilement les annulations de transactions sur Celestia, si vous le souhaitez.

[4] : Les comptes SVM peuvent être représentés par un hash unique. La seule façon de modifier ce hash est par le biais d'une transaction.

[5] : Pour ce faire sans trop de hachage, nous effectuerons un suivi de chaque programme exécuté afin de savoir quelles parties de chaque sysvar utilisée sont réellement consultées. C'est possible, mais il faudra modifier l'interpréteur BPF de Solana.

[6] : Cela inclut les données relatives aux tentatives de transactions qui n'ont pas abouti.

Avertissement：

1. Cet article est repris de [[mirror]. Tous les droits d'auteur appartiennent à l'auteur original [Eclipse]. En cas d'objection à cette réimpression, contactez l'équipe de Gate Learn, elle s'en occupera rapidement.
2. Avertissement en matière de responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent en aucun cas un conseil d'investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, de distribuer ou de plagier les articles traduits.