Par rapport aux ponts multichaînes, les ponts multicouches offrent-ils des opportunités plus grandes ?
TechFlow SélectionTechFlow Sélection
Par rapport aux ponts multichaînes, les ponts multicouches offrent-ils des opportunités plus grandes ?
Lorsque nous choisissons un pont de chaîne, il y a toujours deux compromis : soit il est plus sécurisé, soit il est plus rapide et plus économique.
Dédié à des analyses Web3 approfondiesRédaction : Adam Cochran
Traduction : TechFlow intern
Concernant les ponts multichaînes, je pense qu'il existe deux solutions correctes :
1) Plus complexe et plus décentralisé — probablement plus proche du niveau natif du protocole.
2) Plus lent et plus coûteux.
Commençons par le point 2). Pourquoi les méthodes traditionnelles de paiement sont-elles lentes et coûteuses ? Parce que cela réduit les risques : de longs délais et des vérifications aléatoires permettent de limiter les fraudes, tandis que des frais plus élevés augmentent le coût des comportements malveillants.
Mais contrairement aux systèmes traditionnels de traitement des paiements, où la fraude ne représente qu'une petite partie du volume total des transactions, dans la cryptomonnaie, une seule erreur peut entraîner la perte de tous les fonds. Dans ce cas, notre seule option consiste donc à ajouter davantage de contrôles de sécurité, des délais pour les grosses transactions, des plafonds journaliers, etc. C’est une approche assez douloureuse, mais pratique.
Pour le point 1), presque tous les modèles imaginables reviennent à une question clé :
Vous avez besoin d’un moyen de lire sur différentes chaînes (problème de confiance), ou d’écrire sur différentes chaînes.
Cependant, cela signifie que nous pouvons améliorer un cas particulier : les L2.
Un vrai L2 écrit régulièrement sur Ethereum, ce qui signifie qu’il peut regrouper une série de transactions liées au pont. Imaginons donc un système ZKP dans ce modèle :
-
- Une commande burnForVoucher() existe dans le contrat du pont ;
-
- L’utilisateur brûle ses jetons et génère deux preuves : une prouvant que les jetons ont bien été brûlés, et une autre prouvant qu’ils n’ont pas encore été frappés ;
-
- Sur Arbitrum ou Optimism, l’utilisateur utilise la commande redeemForTokens() ;
-
- Le contrat vérifie que les jetons n’ont pas encore été frappés, ainsi que l’horodatage, qui doit être postérieur à la dernière écriture sur la chaîne principale (pour éviter les doubles dépenses) ;
-
- Les jetons sont envoyés à l’utilisateur ;
-
- Un petit frais Rollup est facturé à l’utilisateur ;
-
- Le L2 renvoie cette transaction individuellement sur le réseau principal et facture à l’utilisateur les frais correspondant à l’utilisation du pont durant l’intervalle précédent d’écriture ;
Il existe plusieurs façons d'ajouter des couches de sécurité supplémentaires, comme retenir les jetons jusqu'à la prochaine écriture du L2. Ce modèle nécessite un support spécifique du L2, mais il augmente considérablement le potentiel de ponts véritablement sécurisés.
Bien qu’il ne fonctionne que pour les L2 et non pour d'autres chaînes, la réalité est que lorsqu’on choisit un pont multichaîne, on fait toujours face à un compromis : soit plus de sécurité, soit plus de rapidité et de faible coût.
Mais si notre futur multichaîne n’est en réalité pas tant multichaîne que multi-niveaux, multi-shards — centré sur les L2 (véritables) — alors nous pouvons construire de meilleurs ponts capables de communiquer efficacement entre eux, car les L2 le font déjà. Cela représente probablement une énorme opportunité pour les équipes concentrées sur des domaines verticaux liés aux L2.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@adamscochran
