Across V4 introduit une nouvelle architecture inter-chaînes améliorée.
Le système combine des intentions et des preuves à divulgation nulle de connaissance (ZKP) pour s'étendre à plus de chaînes, plus rapidement.
Voici le détail technique. 🧵
Auparavant, Across utilisait des "ponts canoniques" ou des adaptateurs spécifiques à la chaîne pour vérifier les messages du HubPool d'Ethereum.
Cela fonctionnait bien pour les L2 comme Arbitrum et Optimism, qui exposent l'état finalisé d'Ethereum.
Mais ce design était limitant…
Pour les chaînes non-EVM comme BSC, ce modèle ne fonctionne pas.
Il n'existe pas de moyen canonique de vérifier l'état d'Ethereum. Cela signifiait soit construire des adaptateurs personnalisés, soit ne pas prendre en charge ces chaînes du tout.
Aucune de ces solutions n'est optimale. Nous avons donc trouvé une meilleure façon d'utiliser les ZKPs.
Voici le processus :
Lorsque les relayeurs remplissent des ordres inter-chaînes, les transactions sont regroupées en paquets de remboursement des relayeurs, qui sont ensuite vérifiés par l'Oracle Optimiste de @UMAProtocol.
Cela se produit toujours sur le réseau principal d'Ethereum.
Une fois qu'un bundle est vérifié, le HubPool Across déclenche le processus de règlement.
Il écrit ensuite les hachages des messages de remboursement dans le contrat HubPoolStore dans des emplacements de stockage spécifiques.
Cet événement de stockage se produit également sur le réseau principal Ethereum.
Chaque hachage de message dans le contrat HubPoolStore correspond à une intention de rembourser un relayer sur une chaîne de destination.
Notez que les messages L1 → L2 peuvent représenter plusieurs remboursements (y compris des remplissages lents). Cela est dû au fait qu'ils sont des bundles racines.
Lorsque le contrat HubPoolStore écrit un hachage de message stocké, il émet un événement StoredCallData.
Cet événement contient le hachage du message et le slot de stockage.
L'événement + les données stockées forment l'ancre pour la vérification ZK en aval.
Un service appelé le finaliseur écoute ces événements.
Une fois qu'il détecte un nouveau, il initie un processus pour prouver que le hash du message a bien été écrit sur Ethereum.
Chaque message, pour lequel le hash est stocké, a un objectif qui peut être spécifique à sa chaîne.
Cette preuve permet d'exécuter le message en toute sécurité sur la chaîne de destination.
Mais la finalité d'Ethereum n'est pas instantanée.
Une fois que le finaliseur envoie les données à l'API ZK, l'API attend à travers la fenêtre de finalité d'Ethereum avant de générer une preuve.
Pour générer une preuve ZK valide, le comité de synchronisation d'Ethereum doit approuver un bloc finalisé spécifique.
Si le message a été inclus dans ce bloc ou avant, les signatures requises deviennent disponibles pour commencer à générer la preuve ZK.
Le finaliseur interroge l'API ZK pour générer une preuve qu'un hachage de message spécifique a été écrit dans un emplacement de stockage HubPoolStore connu dans un bloc Ethereum finalisé.
Cela permet une vérification sans confiance des remboursements des relayeurs sur n'importe quelle chaîne de destination.
L'API ZK prépare les entrées de preuve, y compris (mais sans s'y limiter) :
- En-têtes de balise finalisés
- Signatures du comité de synchronisation
- Preuves Merkle de stockage provenant de la couche d'exécution d'Ethereum
Ceci constitue la base pour générer la preuve.
Across déploie une pile générique sur les chaînes de destination :
- Un contrat Verifier (valide la preuve ZK)
- SP1Helios par @Succinct (stocke l'état finalisé d'Ethereum)
- Contrat UniversalSpokepool (vérifie l'authenticité des messages pendant l'exécution)
Une fois que la preuve ZK est vérifiée et que l'état est confirmé, executeMsg() peut exécuter en toute sécurité la charge utile sur la chaîne de destination.
Sans confiance. Sécurisé. Universel.
Cela signifie qu'Across n'a plus besoin d'adaptateurs personnalisés pour chaque chaîne.
Juste un pipeline qui fonctionne partout :
storeMsg() sur Ethereum → preuve ZK → executeMsg() sur n'importe quelle chaîne de destination qui peut vérifier la preuve SP1Helios.
Aucune hypothèse de confiance.
Aucun surcoût d'intégration.
Juste des Intentions + ZK.
Pourquoi est-ce un gros problème ?
Cela élargit considérablement la portée d'Across en débloquant le support pour des chaînes de longue traîne qui ne peuvent pas vérifier l'état d'Ethereum nativement et qui n'ont pas de ponts canoniques.
Cela rend l'intégration plus rapide, plus sûre et plus évolutive.
Across n'a pas besoin d'un pont canonique pour ces chaînes. Il lui suffit de pouvoir vérifier une preuve ZK de l'état d'Ethereum.
Cela réduit les frais d'intégration, évite le risque de pont centralisé et renforce le rôle d'Ethereum en tant que racine de la vérité inter-chaînes.
7,74 k
42
Le contenu de cette page est fourni par des tiers. Sauf indication contraire, OKX n’est pas l’auteur du ou des articles cités et ne revendique aucun droit d’auteur sur le contenu. Le contenu est fourni à titre d’information uniquement et ne représente pas les opinions d’OKX. Il ne s’agit pas d’une approbation de quelque nature que ce soit et ne doit pas être considéré comme un conseil en investissement ou une sollicitation d’achat ou de vente d’actifs numériques. Dans la mesure où l’IA générative est utilisée pour fournir des résumés ou d’autres informations, ce contenu généré par IA peut être inexact ou incohérent. Veuillez lire l’article associé pour obtenir davantage de détails et d’informations. OKX n’est pas responsable du contenu hébergé sur des sites tiers. La détention d’actifs numériques, y compris les stablecoins et les NFT, implique un niveau de risque élevé et leur valeur peut considérablement fluctuer. Examinez soigneusement votre situation financière pour déterminer si le trading ou la détention d’actifs numériques vous convient.