Texte original : « Cadre de risque L2Bridge »
Auteur : bartek.eth
Vaibhav Chellani de Socket et moi souhaitions proposer une architecture de risque pour évaluer les profils de sécurité de différentes architectures de pont.
Comme pour divers cadres de risque L2, notre objectif global est d'être en mesure de « catégoriser » rapidement une solution dans une catégorie de solution spécifique présentant des caractéristiques similaires, et en même temps d'être en mesure de présenter aux utilisateurs de manière suffisamment détaillée comment ils utiliseront ces ponts. . Quelles sont les hypothèses de sécurité qui doivent être acceptées.
Nous nous concentrons principalement sur les ponts entre Ethereum et d'autres chaînes, car nous les aborderons bientôt sur l2beat.com (Note du traducteur : la colonne des ponts est maintenant en ligne), mais le raisonnement de base sur la sécurité de ces solutions s'applique également pour relier n'importe quelle chaîne. à une autre chaîne. À l’heure actuelle, nous recherchons les commentaires de la communauté au sens large sur ce cadre proposé.
Type de pont
Pour les utilisateurs finaux, le pontage d'actifs fait référence à la réception d'un dépôt d'un certain actif de la chaîne source et à l'envoi de cet actif à l'utilisateur sur la chaîne de destination.
Par exemple, un processus de transition typique est qu'Alice transfère des fonds vers le contrat de transition de la chaîne A, puis Alice reçoit des fonds du pont sur la chaîne B.
D'une manière générale, ce processus se déroule de deux manières :
Ponts de jetons basés sur la messagerie – Ces ponts permettent à la liquidité de circuler entre les chaînes sous forme de messagerie. Généralement, ils permettent à un actif d'être créé sur la chaîne cible après qu'il ait été verrouillé ou détruit sur la chaîne source. Exemples : pont Rollup, pont natif Polygon, Anyswap (anyCall) et réseau Axelar. Réseau de liquidité – Il existe également des ponts qui permettront de racheter une partie des actifs émis. Ils permettent aux utilisateurs de transférer des actifs vers d'autres chaînes, à condition que ces actifs aient été transférés au préalable via le « Message Bridge ». Exemples : Connecxt basé sur Nomad Bridge, Hop basé sur Hop Optimistic Bridge, certains autres HTLC (Hash Time-Lock Contract, hash time lock contract) et transferts conditionnels (tels que nova, etc.).
Sécurité des ponts de transmission de messages
Dans cette section, nous essaierons d'expliquer ces différentes manières de valider les messages cross-chain utilisés par plusieurs protocoles de pontage. Comme le montre la figure ci-dessus, le pontage de jetons exploite la sécurité du pontage de transmission de messages.
Le client léger vérifie la validité de l'état
Description : Un pont qui vérifie la validité de la transition d'état de la chaîne source sur la chaîne cible. Ce processus de vérification est mis en œuvre via une preuve à connaissance nulle (le processus de transition d'état s'accompagne de la génération d'une preuve zk) ou un système de preuve de fraude (permettant à des vérificateurs indépendants de contester la validité de la nouvelle racine d'état).
Exemple : Tous les Rollups sont des exemples ici, L1 vérifiera la transition d'état de L2 via FraudProof (preuve de fraude) ou ValidityProof (preuve de validité).
Consensus léger de vérification des clients
Description : Un pont qui vérifie le consensus de la chaîne source sur la chaîne cible. Cela dépend du mécanisme de consensus utilisé par la chaîne source et comprend généralement une vérification de la signature du quorum du comité de validation actuel, si la chaîne source utilise un protocole de consensus de proposition et de vote de type PBFT (tel que Tendermint, HotStuff, protocole Casper FFG). Alternativement, si la chaîne source utilise un protocole PoW ou un protocole PoS de style « chaîne la plus longue » (tel que Ouroboros, ETH 2.0 LMD Ghost, etc.), utilisez les règles de fork pertinentes pour vérifier la chaîne la plus longue.
Exemples : NEAR Rainbow bridging (en ignorant le composant optimiste lié à la complexité du processus de vérification du mécanisme de signature NEAR), le pont PoS de Polygon (vérifiant le consensus de la chaîne Heimdall) et Cosmos IBC (vérifiant la signature d'une autre chaîne Cosmos).
ensemble de validateurs externes
Description : Utiliser des validateurs externes comme pont vers la source de vérité, c'est-à-dire des validateurs qui forment un comité indépendant, plutôt que des validateurs sur les chaînes source et cible. Selon l'implémentation utilisée par ces validateurs, ils peuvent utiliser MultiSig (multi-signature), exécuter un algorithme de consensus (généralement celui de la proposition et de la classe de vote), utiliser un mécanisme de signature de seuil (TSS, mécanisme de signature de seuil) ou SGX, etc. ... quelle que soit la technologie qu'ils utilisent, ils relèvent de cette méthode de vérification.
Inconvénients : Wormmhole, Multichain, Axelar, DeBridge, Synapse, Stargate.
vérification optimiste
Description : Un pont avec une période de challenge (période de challenge, ndlr : désigne la période de temps pendant laquelle d'autres validateurs peuvent contester la validité du message du pont lorsqu'ils le trouvent invalide).
La partie honnête dans ce type de vérification évite d'inclure des informations frauduleuses pendant cette période. Il y a cependant plusieurs paramètres clés à considérer :
Durée de la période de défi : plus elle est longue, mieux c'est. Taille de l'ensemble de l'observateur : aucune autorisation requise > Autorisation requise
Composants : Hop Protocol, Connext Amarok, Across, Nomad Token Bridge.
Méthode d'authentification hybride
Description : Il existe une structure qui mélange les méthodes de vérification ci-dessus.
Sécurité du réseau de liquidité
En plus de l'envoi d'actifs à travers les chaînes, il existe une autre méthode : l'échange entre chaînes (swap). L'échange entre chaînes ne peut être effectué qu'en changeant de mains sans déplacer d'actifs à travers les chaînes. (Note du traducteur : lorsque les actifs d'une partie changent de mains, ils deviennent la propriété d'une autre partie, c'est-à-dire que le propriétaire des actifs change.)
Prenons un exemple simple : Alice sur la chaîne A souhaite transférer des actifs vers la chaîne B. Bob (fournisseur de liquidité, LP) possède déjà des actifs de même valeur sur la chaîne B. Il utilise ses actifs sur la chaîne B pour fournir des services d'échange pour le solde d'Alice sur la chaîne A et perçoit des frais de service. En fin de compte, Alice obtiendra l'actif sur la chaîne B et Bob obtiendra l'actif + les frais de service sur la chaîne A.
Cette partie décrit uniquement la sécurité du protocole « d'échange », c'est-à-dire la probabilité que le LP s'enfuie avec l'argent après avoir accepté votre dépôt sur la chaîne source. Ces actifs d’échange bénéficient de la sécurité du pont de transmission de messages qui les forge.
Il existe également d'autres moyens d'échanger des actifs :
HTLC : également connu sous le nom de contrat de verrouillage du temps de hachage, il peut être utilisé pour l'échange atomique d'actifs entre deux parties de la chaîne. Habituellement, seules deux étapes sont requises de la part de l'utilisateur : l'une consiste à verrouiller et l'autre à déverrouiller. Un scénario d'échec possible est que vos fonds soient bloqués pendant une période de « veille » fixe. Exemples : Connext NXTP, Liqualit. Transfert conditionnel : permet aux LP d'utiliser des ponts de messagerie raccourcis, ce qui leur permet de fournir immédiatement des fonds aux utilisateurs finaux et de recevoir des fonds du pont de messagerie chaque fois que les fonds sont pontés. En cas d'échec, s'il n'y a pas de LP pour fournir de la liquidité, le chemin lent sera activé. Exemples : Hop, Connext Amarok, MakerDAO Teleport. Validateur externe : permet aux utilisateurs de transférer des fonds vers un fournisseur de pont de confiance qui promet de débloquer les fonds vers une autre chaîne. Un scénario d’échec possible ici est que vos fonds seront perdus. Exemple : Binance
résistance à la censure
Nous examinerons les hypothèses de sécurité concernant la probabilité qu'un seul message envoyé par un pont soit censuré. Plus concrètement, nous explorerons également si un seul message (transfert de token) sera censuré ou ignoré par le pont, et si oui, quelles seront les conséquences sur les fonds de l'utilisateur (les fonds seront-ils restitués à l'utilisateur, ou seront-ils être "bloqué" (statut "Transfert en cours").
Solution typique :
Tirer parti de la résistance à la censure de la chaîne sous-jacente (par exemple, certains rollups) S'appuyer sur l'honnêteté de l'ensemble des validateurs
Défaut actif global
En termes d'échecs globaux de vivacité, nous examinerons les conséquences de la « désactivation » d'un pont. Par exemple, pour un pont utilisant un ensemble externe de validateurs, nous pourrions examiner la sécurité des fonds des utilisateurs dans le cas où ces validateurs seraient hors ligne pendant une période prolongée (peut-être indéfiniment). Les situations courantes pouvant survenir comprennent :
Activez le chemin lent : le mode par défaut est le chemin lent et vous ne perdrez pas de fonds : les utilisateurs peuvent miser pour participer au réseau, devenir validateur et gérer eux-mêmes les transactions de transfert bloquées. Geler : suspendre le système et ne peut pas s'exécuter jusqu'à ce que le système soit activé. L'opérateur du pont est en ligne.
Liquidité
Dans cette section, nous tenterons d’analyser la liquidité disponible sur l’actif relais. Le pont peut-il créer des actifs, nécessite-t-il des LP, les utilisateurs peuvent-ils toujours retirer ou transférer le montant de jetons de leur choix, ou sont-ils dépendants de LP externes et le pont peut « manquer de fonds ».
Sans restriction (le pont peut créer des jetons natifs/faisant autorité) Autorisé (la liquidité est fournie par l'opérateur du pont) Sans autorisation (n'importe quel LP peut fournir des liquidités)
Réflexions et mesures supplémentaires Mise à niveau Acteurs autorisés Volume de transfert au cours des dernières 24 heures Transferts uniques au cours des dernières 24 heures Liquidité disponible Jetons/blockchains pris en charge