Vous avez donc reçu une balle orange et vous détenez maintenant des BTC. Tant mieux pour vous, mieux vaut tard que jamais.
Puis, vous avez entendu l'adage sacré de ce secteur : pas vos clés, pas vos pièces. En plus des horreurs des divers tapis et hacks de CEX, vous avez finalement décidé d'assurer vous-même la garde de vos bitcoins.
Félicitations, vous êtes désormais maître de votre destin financier. Hourra, non ?
Vous vous rendez compte que les transactions sur Bitcoin sont stupidement coûteuses, si chères qu'elles font honte aux frais d'essence notoirement élevés d'Ethereum. Parce que contrairement à ces maudites baleines, vous n'avez pas 1 million de dollars de bitcoins à dépenser - chaque transaction que vous effectuez sur la chaîne principale vous touche de plein fouet.
Et maintenant ? Il doit bien y avoir une meilleure solution.
Quitter le nid
Lorsque vous détenez des bitcoins (BTC, la crypto-monnaie) en dehors de Bitcoin (mainchain, la blockchain), vous ne bénéficiez pas de la sécurité et de la protection de la mainchain, ce qui vous oblige à hériter des hypothèses de confiance de la chaîne ou de la couche sur laquelle vous vous trouvez, ainsi que du jeton représentatif de BTC que vous détenez (le cas échéant).
Malheureusement, c'est le compromis iBitnevitable que vous devrez faire - pour l'instant.
Cet article vise à fournir une vue d'ensemble des différentes approches et passerelles de mise à l'échelle qui existent, ainsi qu'à souligner les sacrifices de confiance que vous devrez encourir pour chacune d'entre elles. En outre, nous mettrons à nu les lacunes de chacune d'entre elles et expliquerons pourquoi il n'existe toujours pas de solution de mise à l'échelle de Bitcoin capable d'"exporter" BTC sans compromettre de manière significative la sécurité et la protection des utilisateurs de sa chaîne principale.
Les termes "bitcoin" et "chaîne principale" seront utilisés de manière interchangeable tout au long de ce document. Commençons.
Réseau Eclair
Lancé en janvier 2018, le Lightning Network constitue l'une des premières tentatives de mise à l'échelle de Bitcoin. À la base, le Lightning Network est constitué d'un réseau de canaux de paiement, où chaque canal de paiement est fondamentalement un contrat multisig 2 sur 2 (tirant parti des HTLC) entre deux parties sur Bitcoin.
Le fonctionnement du Lightning Network repose sur l'existence de plusieurs canaux de paiement qui maintiennent une connexion avec le pair auquel vous souhaitez envoyer vos bitcoins. Ainsi, même si vous n'avez pas de connexion directe avec Bob, tant que vous avez une connexion avec Alice (qui a une connexion avec Bob), vous pouvez initier un paiement à partir de votre nœud Lightning et payer Bob par l'intermédiaire d'Alice.
En théorie, vous pouvez effectuer des transactions avec n'importe qui, à condition que votre contrepartie partage au moins un pair mutuel (avec suffisamment de liquidités). D'où le "réseau" dans Lightning Network.
tldr
Lorsque Bob souhaite ouvrir un canal de paiement avec Alice, ils combinent leurs clés pour générer un contrat multisig 2 sur 2, qui servira d'adresse au canal. Ensuite, Bob diffuse deux transactions : sa transaction d'engagement (pour dépenser ses fonds vers son portefeuille de financement si Alice ne répond plus) et sa transaction de financement (Bob dépose ses bitcoins dans le contrat multisig 2 sur 2). De même, Alice diffuse également sa transaction d'engagement et sa transaction de financement. Il est important que la première transaction d'engagement soit signée par les deux parties avant que quiconque n'alimente le canal de paiement. Cela permet de s'assurer que les fonds ne seront pas bloqués dans le multisig au cas où l'une des parties serait hors ligne.
Une fois le canal de paiement établi, Bob et Alice sont libres de dépenser les bitcoins à l'intérieur du multisig autant de fois qu'ils le souhaitent et comme ils l'entendent. Lorsque vous "envoyez" des fonds, vous mettez en fait à jour la transaction d'engagement partagée que vous avez avec l'autre partie pour refléter le dernier état des soldes, en invalidant l'engagement précédent. La transaction d'engagement n'est jamais soumise à la chaîne lorsque le canal de paiement est encore actif et n'est connue que de Bob et Alice. La transaction d'engagement n'est publiée qu'à la fermeture du canal de paiement.
Lorsque Bob veut fermer un canal (et récupérer ses bitcoins sur la chaîne principale), il y a deux façons de le faire : de manière coopérative avec Alice ou de manière non coopérative (c'est-à-dire en forçant la fermeture). Dans le cas d'une fermeture coopérative (happy path), Bob et Alice se mettent tous deux d'accord sur leur part des soldes du multisig, et ils signent tous deux une nouvelle transaction qui renvoie immédiatement les fonds vers leurs portefeuilles respectifs.
Toutefois, dans un scénario de clôture forcée (chemin malheureux), Bob ou Alice peuvent ne pas être disponibles ou ne pas vouloir signer la transaction de clôture de manière coopérative. Dans ce cas, la partie à l'origine de la clôture forcée consacrera son solde à un contrat d'arbitrage, ce qui permettra à son homologue de le contester dans le délai CSV (période de litige). Si cette partie tente de "tricher" (en publiant une transaction d'engagement plus ancienne), son homologue publie simplement la transaction d'engagement la plus récente, réclamant les fonds de la partie tricheuse du contrat d'arbitrage pour elle-même.
[lightning.engineering] illustré : La demande de fermeture forcée de 8 BTC de Bob, qui a échoué
Pour illustrer cela, supposons que Bob et Alice aient un solde "réel" de 4 BTC et 6 BTC respectivement (le canal de paiement contient 10 bitcoins au total). Si Bob initie une fermeture forcée et prétend qu'il a 8 BTC dans le canal de paiement (en publiant une ancienne transaction d'engagement), Alice peut simplement publier la dernière transaction d'engagement et réclamer les 8 BTC de Bob dans le contrat d'arbitrage. Cela aura un effet dissuasif sur Bob, en garantissant que les parties n'ont pas besoin de se faire confiance lors de l'ouverture d'un canal Lightning.
pas votre nœud, pas vos pièces.
Le problème avec le Lightning Network, c'est que vous ne pouvez pas vous auto-déposer, sauf si vous gérez votre propre nœud Lightning. Sinon, vous devez déposer vos BTC dans un nœud Lightning de confiance afin d'utiliser le réseau, où vos bitcoins font partie de leur grand livre interne et où ils effectuent des transactions en votre nom. Si le nœud Lightning qui détient votre dépôt s'effondre, vos BTC s'envolent avec lui et vous n'avez aucun recours. C'est fondamentalement pire que de déposer vos bitcoins dans un CEX de confiance - je veux dire, au moins vous traitez avec Binance ou Coinbase !
Si vous décidez de gérer votre propre nœud Lightning, vous devrez être constamment en ligne pour surveiller les violations du canal par vos pairs. Bien que vous puissiez affecter des nœuds Watchtower pour vous aider à surveiller les violations (ils stockeront vos engagements générés sur chaque transaction que vous effectuez sur le canal de paiement pour contester les fermetures forcées frauduleuses en votre nom), vous en revenez essentiellement à faire confiance à des entités centralisées. Encore une fois, vous pourriez tout aussi bien faire confiance à Binance ou Coinbase plutôt qu'à une quelconque société de surveillance pour protéger vos bitcoins !
[Sam Aiken] illustré : la tour de guet LN en action
Comme si ce qui précède ne suffisait pas à vous décourager, si vous gérez votre propre nœud Lightning, vous devrez gérer manuellement la liquidité de votre propre nœud par rapport à celle de vos pairs. Par exemple, si un canal de paiement ne dispose que de 10 BTC au total, le solde maximum que chaque partie peut détenir entre elles est de 10 BTC. Si vous souhaitez effectuer une transaction avec une personne avec laquelle vous n'avez pas de connexion directe, vous devrez faire appel à d'autres nœuds Lightning qui ont des connexions avec vous et votre contrepartie, et qui disposent également de suffisamment de liquidités pour acheminer le paiement. Vous comprenez maintenant pourquoi la gestion de la liquidité est très lourde pour le gestionnaire de nœuds moyen.
Par conséquent, la plupart des nœuds Lightning s'en passent et se connectent à des nœuds de routage, qui sont des nœuds Lightning bien capitalisés (très probablement gérés par de grandes institutions) dédiés à l'acheminement des paiements. Ils se situent entre les nœuds Lightning en tant que canal intermédiaire, agissant comme un quasi-appareilleur de paiements à travers le réseau. Par conséquent, le réseau a tendance à se centraliser à cet égard - au moment de la rédaction de cet article, les 10 premiers nœuds Lightning représentent plus de 75 % de la capacité totale du réseau !
[LnRouter.app] Nœuds de foudre actifs, filtrés par capacité
Phoenix Wallet, développé par ACINQ, est une tentative de simplifier l'autodétention sur le Lightning Network pour l'utilisateur moyen. Lorsque vous téléchargez l'application Phoenix Wallet, votre téléphone devient automatiquement votre propre nœud Lightning. Pour simplifier la gestion des liquidités et l'acheminement des paiements, votre nœud Lightning se connectera au nœud ACINQ, qui servira de routeur pour vos paiements entrants et sortants.
Néanmoins, vous êtes toujours tenu d'être régulièrement en ligne et de surveiller les violations - sinon, vous êtes toujours à la merci de l'ACINQ. Aussi improbable que cela puisse paraître, si ACINQ tente de forcer la fermeture de votre canal avec un engagement obsolète, vous devrez vous connecter pour le contester et présenter l'engagement correct le plus récent. Sinon, vous risquez de perdre vos fonds au profit de l'ACINQ.
conclusion
Le Lightning Network est conçu pour les gestionnaires de nœuds. Dans le monde réel, cependant, tout le monde n'a pas besoin de gérer son propre nœud - ce n'est ni réaliste ni pratique.
Hélas, le Lightning Network n'a jamais été conçu pour le détenteur moyen de BTC qui n'est pas un geek. Le fait qu'il faille gérer un nœud pour rester autonome, associé à son cas d'utilisation restrictif en tant que réseau de paiement (non programmable pour débloquer nativement des cas d'utilisation plus riches tels que DeFi), relègue le protocole aux marges du véritable bitcoiner qui gère son propre nœud.
Pas votre nœud, pas vos pièces. Et ce n'est pas idéal pour l'utilisateur moyen.
Chaînes d'États
Le concept des Statechains s'inspire fortement des canaux de paiement de Lightning, car tous deux permettent des transactions hors chaîne illimitées qui seront finalement "réglées" sur Bitcoin à la clôture de la transaction.
tldr
Contrairement aux canaux Lightning (qui sont des multisigs 2 sur 2), l'adresse de dépôt UTXO d'une statechain est créée complètement hors chaîne par l'opérateur, qui est une entité de confiance qui génère des parts de clés à la fois pour elle-même et pour le propriétaire actuel de l'UTXO. Le propriétaire de l'UTXO qui souhaite lancer une statechain collabore avec l'opérateur (entité de confiance) pour créer une adresse où la clé publique correspondante est formée à partir des parts de clés du premier propriétaire et de l'opérateur. À partir de là, le propriétaire finance la statechain avec l'UTXO (ou des bitcoins), puis crée une transaction de sauvegarde (avec la coopération de l'opérateur), qui est un timelock qui permettra au propriétaire de réclamer unilatéralement son UTXO à son expiration.
[Nik/Coinmonks] Statechains en action : transfert de la propriété d'UTXO d'Alice à Bob
Si le propriétaire actuel souhaite transférer la propriété de l'UTXO à un nouveau propriétaire, il suffit à l'opérateur de générer à nouveau des parts de clé correspondant à la même adresse de dépôt et de supprimer la part de clé qu'il détient auprès de l'ancien propriétaire. Ensuite, le nouveau propriétaire crée une transaction de sauvegarde (avec la coopération de l'opérateur), mais avec un délai plus court. Chaque fois qu'une statechain change de mains, l'opérateur supprime la part de clé précédente et cosigne la transaction de sauvegarde du nouveau propriétaire, qui aura un timelock plus court que celui de l'ancien propriétaire, c'est-à-dire jusqu'à ce que le timelock ne puisse plus être raccourci (ce qui nécessite la création d'une nouvelle statechain pour le nouveau propriétaire).
Ainsi, l'ancien propriétaire ne peut pas retirer unilatéralement des fonds de la statechain à la place du nouveau propriétaire. En effet, pour quitter la statechain de manière coopérative (retrait instantané), l'ancien propriétaire a besoin que l'opérateur cosigne sa transaction de sortie (ce que l'opérateur ne peut plus faire, car il a supprimé sa part de clé précédente qui pouvait cosigner la transaction), sinon l'ancien propriétaire doit attendre l'expiration de son timelock avant de pouvoir soumettre sa transaction de sauvegarde. Néanmoins, même si l'opérateur se déconnecte lorsque le nouveau propriétaire veut quitter la statechain, il peut toujours soumettre sa transaction de sauvegarde et réclamer les fonds avant l'ancien propriétaire, car sa transaction de sauvegarde a un timelock plus court.
l'opérateur en qui nous avons confiance
Comme si cela n'était pas assez évident, l'opérateur est le seul point de défaillance des chaînes d'état. Les nouveaux propriétaires doivent être sûrs que l'opérateur a effectivement supprimé leur part de clé précédente et qu'il n'y aura pas de collusion pour réclamer des fonds au nom de l'ancien propriétaire. Étant donné que le serveur de l'opérateur est essentiellement une boîte fermée web2, le nouveau propriétaire n'a aucun moyen de vérifier la suppression de la part de clé précédente de l'opérateur (à moins qu'il ne soit lui-même l'opérateur).
Mercury Layer, un projet de statechain, vise à éliminer ce facteur de confiance. En utilisant une variante aveugle de Schnorr, l'opérateur Mercury n'a pas connaissance de la chaîne Bitcoin elle-même. Ainsi, l'opérateur n'a aucune idée de l'adresse de dépôt pour laquelle il cosigne, des détails des transactions de sauvegarde, ni des signatures qu'il génère. En supposant que le même opérateur gère plusieurs chaînes d'état, Mercury signera essentiellement à l'aveugle toutes les demandes de cosignature qui lui parviendront, sans savoir ce que cette signature permettra de faire. Cela permet d'éviter toute collusion sélective de la part de l'opérateur et de garantir que la génération des clés et la signature sont effectuées correctement sur son serveur, car il n'a aucune raison d'être malveillant (il ne sait pas ce qui est en jeu en raison de la signature aveugle).
[Ruben Somsen] l'opérateur signe des messages en aveugle - il ne sait pas s'il s'agit de transactions en bitcoins ou d'autre chose.
Malgré les efforts de Mercury, les statechains restent fondamentalement très limités. Vous ne pouvez "envoyer" que le montant exact de BTC que vous avez déposé sur la statechain, car les statechains, dans leur essence même, sont simplement un protocole de transfert de propriété d'adresse au lieu de faciliter les transferts UTXO comme le Lightning Network. En outre, si l'opérateur se déconnecte, tous les "envois" seront interrompus et vous devrez attendre l'expiration de votre long timelock avant de pouvoir réclamer vos fonds à Bitcoin par le biais d'une transaction de sauvegarde.
conclusion
Alors que les statechains offrent un " hack " astucieux pour transférer des UTXO en dépit du coût et des limites du bitcoin, elles restent inadaptées aux transferts d'UTXO à grande échelle et à haute fréquence de montants différents. Dans ce contexte, les statechains sont encore plus restrictives que le Lightning Network - en plus de ne pouvoir transférer que l'UTXO exact avec lequel vous avez financé la statechain, vous devez également faire face au même manque de programmabilité qui vous empêche de débloquer des cas d'utilisation plus riches autres que les paiements (i.e. DeFi).
En fin de compte, les statechains ne sont rien d'autre qu'un protocole de transfert de propriété d'adresse "hacky", où la confiance est minimisée. Je veux dire, au moins Lightning fonctionne réellement pour les coureurs de nœuds !
Statechains - amusant pour les développeurs, moins amusant pour tous les autres.
BTC de dépôt
Les solutions de dépôt de BTC (appelées "bitbanks" par les OG), bien qu'elles constituent une gifle idéologique pour les "vrais" bitcoiners, restent sans aucun doute l'un des moyens les plus sûrs (et aussi les plus pratiques) pour l'utilisateur moyen d'effectuer des transactions en bitcoins de manière peu coûteuse, rapide et raisonnablement sûre.
Les dépositaires de confiance en BTC sont pour la plupart parmi les plus anciennes institutions cryptographiques, et sont très appréciés dans l'industrie, et même dans TradFi.
tldr
Assez explicites, les solutions de BTC dépositaires impliquent généralement des entités réputées auxquelles les déposants font suffisamment confiance pour agir en tant que dépositaire de tous les bitcoins déposés auprès d'elles. Ensuite, elles frappent des jetons représentatifs sur différentes chaînes (et environnements), où chaque unité est garantie 1:1 par le montant des bitcoins détenus en réserve par le dépositaire (en théorie).
Comme ils vivent sur une chaîne moins chère et plus rapide que le bitcoin, ces jetons représentatifs de la BTC (par exemple, wBTC, cbBTC, etc.) permettent à leurs détenteurs de l'utiliser à travers DeFi, d'obtenir des rendements libellés en BTC et de réaliser des transactions entre eux dans un environnement d'exécution beaucoup plus rapide et moins coûteux.
dans le dépositaire auquel nous faisons confiance
[BitGo] BitGo : le dépositaire de confiance des wBTC
Il va sans dire que les utilisateurs de solutions de BTC en dépôt doivent faire entièrement confiance au dépositaire du jeton représentatif de BTC qu'ils détiennent. Différentes entités dépositaires porteraient avec elles différents niveaux de risque, c'est-à-dire selon l'interprétation du point de vue du détenteur.
Par exemple, un utilisateur sera plus enclin à utiliser le wBTC de BitGo s'il accorde de l'importance aux antécédents historiques, à la liquidité de l'échange et à son caractère OG. De même, les personnes situées à l'autre bout du spectre pourraient préférer détenir les cbBTC de Coinbase si elles mettent davantage l'accent sur la clarté des réglementations, la transparence et le respect de la procédure américaine et de l'État de droit. C'est un peu comme si quelqu'un devait choisir entre l'USDT de Tether et l'USDC de Circle pour son stablecoin de prédilection - ou bien si vous détenez les deux !
conclusion
Bien que les solutions de BTC en dépôt servent actuellement de passerelle utile pour les utilisateurs de BTC qui ne seraient pas en mesure de s'autodéposer, elles restent au mieux une solution palliative.
Lorsque vous détenez des wBTC, vous faites confiance à BitGo tout comme vous feriez confiance à un CEX lorsque vous y déposez des fonds. Il en va de même pour le cbBTC de Coinbase, le BBTC de Binance et de nombreux autres dépositaires de BTC.
Une sécurité opsec laxiste et une rencontre avec le puissant Lazare (espérons que ce ne sera pas le cas), et voilà vos bitcoins pour financer les bombes atomiques de Kim !
BTC fédéré
Imaginez wBTC, mais au lieu d'avoir seulement BitGo comme dépositaire, vous avez aussi Wintermute, ChorusOne, et d'autres institutions qui se joignent à la fête et se voient confier les clés du royaume.
Qu'y a-t-il de mieux qu'un seul gardien ? Un grand nombre d'entre eux !
tldr
Les ponts de BTC fédérés sont essentiellement des ponts de BTC collectifs. Ils impliquent plusieurs entités réputées formant un ensemble de signataires, où une majorité est nécessaire pour autoriser les transactions sur les bitcoins déposés détenus par ces entités.
L'idée est d'éliminer le risque d'un seul point de défaillance qui est présent dans les solutions de garde de BTC. Tout comme vous utiliseriez un portefeuille multisig plutôt qu'un EOA pour conserver la majeure partie de vos économies, l'idée est qu'en répartissant les privilèges de signature entre plusieurs entités de confiance, vous pouvez accorder moins de confiance à chaque signataire individuel.
Ainsi, pour compromettre un système de BTC fédéré (et voler les bitcoins qui y sont stockés), l'attaquant doit compromettre la majorité des entités faisant partie de l'ensemble des signataires. Il est difficile de compromettre Coinbase. Mais compromettre Coinbase, OKX, Wintermute et Fireblocks tout en restant indétecté est une entreprise ambitieuse pour tout attaquant potentiel.
multisigs et MPC
En simplifiant à l'extrême, il y a principalement deux façons de distribuer les privilèges de signature dans une configuration BTC fédérée - via des constructions multisig (multi-signature) et/ou MPC (calcul multi-parties). Je n'entrerai pas dans les détails de l'implémentation de chacun (c'est beaucoup), mais l'idée principale est que dans un multisig, l'adresse "partagée" est générée sur la chaîne et chaque signataire possède une clé privée totalement indépendante. Cela signifie que lorsqu'une transaction provenant de l'adresse partagée est signée collectivement par les signataires, la signature est enregistrée sur la chaîne.
Avec le MPC, l'adresse "partagée" est générée hors chaîne et chaque signataire possède une part de clé partielle. Lors de la signature d'une transaction onchain, les signataires calculent conjointement une signature en combinant leurs parts de clés. Du point de vue de la blockchain, il semblerait que la signature soit juste une signature standard provenant d'un seul signataire, alors qu'en fait elle est générée collectivement hors chaîne par l'ensemble des signataires dans le cadre de la construction MPC.
Bien sûr, il existe des nuances et des compromis entre chaque approche. Bien qu'il ne soit pas possible de les développer dans le cadre de cet article, je vous recommande de lire ce guide MPC vs. Multi-sig de Fireblocks si vous êtes un nerd qui veut plonger dans les détails et autres.
dans la fédération nous avons confiance
En théorie, tout cela semble très sûr. Vous avez les meilleures institutions cryptographiques, chacune avec sa propre réputation en jeu, qui protègent collectivement le pont fédéré de BTC. Qu'est-ce qui pourrait mal tourner ?
Vous voyez, moins de confiance ne veut pas dire pas de confiance. Dans le cas d'un pont BTC fédéré, la sélection des signataires est d'une importance capitale. La fédération doit comprendre un nombre suffisant de signataires, un seuil de majorité sûr (au moins deux tiers) et une répartition géographique suffisante. Sans oublier que chaque signataire doit déjà avoir une assez bonne réputation qu'il est prêt à protéger et qu'il a un intérêt direct dans le succès du pont fédéré.
En ce qui me concerne, parmi les institutions signataires d'au moins un pont fédéré en BTC actuellement en activité, il n'y en a honnêtement qu'une poignée à qui je confierais mes économies. Je croise les doigts pour que vous ayez Coinbase, qui est digne de confiance, puis probablement Galaxy, Wintermute et Fireblocks. Je ne dis pas que les autres institutions sont toutes nulles, mais leur confier 100 % de mes économies est une autre affaire.
En bref, il ne sert à rien d'avoir 15 signataires dans votre fédération, si 10 d'entre eux ne mettent pas en œuvre de bonnes pratiques de sécurité ou sont tout simplement douteux. Le problème est qu'il est plus facile à dire qu'à faire de trouver 15 signataires ayant une excellente réputation et une bonne sécurité opérationnelle, sans parler de 50 signataires.
Quand tout le monde prétend être digne de confiance et sûr ? Voilà, seuls quelques-uns le sont réellement !
Cela dit, je pense que les ponts BTC fédérés restent le meilleur moyen d'"exporter" des BTC vers d'autres chaînes (ou couches) qui ne font pas partie de la chaîne principale Bitcoin. Attendez-vous à ce que les cypherpunks se retournent dans leurs tombes, mais une fédération de signataires de qualité soigneusement sélectionnée serait dans la plupart des cas plus sûre que n'importe quelle alternative sans permission possible dans les circonstances actuelles.
Après tout, ce n'est pas pour rien que la plupart des représentations de BTC que l'on voit aujourd'hui s'appuient sur une fédération de signataires. Vous avez solvBTC, pumpBTC, Lombard's LBTC, Stacks' sBTC, Avalanche's BTC.b, Bitlayer's WBTC, Liquid's L-BTC, Merlin's MBTC - toutes ces représentations exigent que vous fassiez confiance à la fédération de signataires que chacune d'entre elles a respectivement créée. Mais comme il est difficile de trouver des signataires réellement dignes de confiance, ne soyez pas surpris de trouver de nombreux cas de chevauchement de signataires entre les fédérations, dans lesquels le même signataire se retrouve à faire partie de deux ou plusieurs configurations de pont. Par exemple, Cobo est signataire de solvBTC, pumpBTC et Merlin's MBTC. Ou encore Chorus.one, qui signe à la fois pour Lombard's LBTC et Stacks'sBTC.
Il arrive même que deux signataires d'une fédération fassent partie du même écosystème ou de la même entité. Par exemple, BTC.b d'Avalanche inclut Avascan et Ava Labs dans sa fédération de 8 signataires. En supposant un seuil de majorité de 5 sur 8 (le minimum nécessaire), il ne reste à l'attaquant "que" 3 signataires à corrompre ou à compromettre (et à menacer sérieusement la sécurité du pont BTC.b).
Lombard LBTC
À leur décharge, certains projets reconnaissent l'importance de l'opsec du signataire et ont pris des mesures pour minimiser ce vecteur d'attaque. Par exemple, Lombard utilise une approche à plusieurs niveaux de la sécurité en obligeant son consortium (ensemble de signataires) à utiliser CubeSigner, une plateforme de gestion des clés non conservatoire construite par Cubist et utilisant des enclaves Nitro scellées par HSM. En pratique, CubeSigner permet aux clés de rester dans un matériel sécurisé depuis la génération des adresses jusqu'à la signature des transactions - personne, pas même Cubist ou les signataires eux-mêmes, ne peut voir les clés, et encore moins des attaquants extérieurs pour les extraire.
Cependant, tout comme vous faites confiance à Ledger pour l'intégrité et l'incorruptibilité des portefeuilles matériels Ledger que vous avez chez vous, les détenteurs de LBTC de Lombard devraient également faire confiance à Cubist pour l'intégrité et l'incorruptibilité des instances CubeSigner gérées par les signataires du Consortium - sinon, nous en reviendrons à compter sur chaque signataire du Consortium pour qu'il ne bâcle pas son propre système opsec.
[Lombard] illustré : Architecture du Lombard LBTC
En outre, cela ne tient pas compte du risque d'une éventuelle collusion des signataires, aussi improbable qu'elle puisse paraître. Le fait est que si une majorité des signataires du Consortium Lombard s'entendent, ils pourront compromettre les BTC détenus par les adresses du Consortium et voler les fonds des utilisateurs.
conclusion
En tant qu'industrie, nous nous rendrions un mauvais service si nous nous contentions de la sélection de représentations BTC que nous avons aujourd'hui. C'est dur, mais il faut le dire : il n'y a aucun intérêt à Bitcoin (et en fait, à toute cette industrie) si seules quelques baleines choisies ayant les poches pour payer les frais de transaction de la chaîne principale sont les seules à pouvoir effectuer des transactions en BTC sans confiance. Toute cette notion de BTC en tant que monnaie saine sans confiance pour les masses cesserait d'exister lorsque le seul moyen réaliste pour la plupart des gens d'épargner, de dépenser et d'effectuer des transactions en BTC exigerait qu'ils fassent confiance à des entités gérées par des humains faillibles sous la juridiction de l'État.
Les ponts BTC fédérés ont en effet ouvert la voie à la détention et à la transaction de BTC de manière rapide et bon marché, tout en étant relativement sûrs par rapport à d'autres alternatives disponibles. Mais ils n'ont jamais été conçus comme la finalité de la mise à l'échelle de Bitcoin, mais plutôt comme un moyen de parvenir à une fin.
C'est déjà bien, mais ce n'est certainement pas la solution miracle dont l'industrie (et le marché) a désespérément besoin.
Porte-greffe rBTC
[Rootstock] Rootstock : l'une des solutions de mise à l'échelle OG de Bitcoin
Lancée en janvier 2018, Rootstock est la première sidechain Bitcoin et celle qui dure le plus longtemps. Elle s'appuie sur le merge-mining pour le consensus et utilise un pont BTC fédéré à double sens où le rBTC est également utilisé pour payer les frais de gaz sur Rootstock.
Le problème ? Le pont BTC fédéré de Rootstock n'a pas besoin d'une hypothèse de majorité honnête pour être sécurisé !
Maintenant que j'ai votre attention, plongeons dans le vif du sujet.
fusion-minage
La chaîne Rootstock utilise le merge-mining pour parvenir à un consensus. Contrairement aux chaînes PoS (où la proportion de vos actifs misés par rapport à l'ensemble des actifs misés représente votre pouvoir de vote), les chaînes merge-mined cherchent à tirer parti de la capacité de hachage qui est déjà utilisée pour miner Bitcoin en l'étendant à la validation de la chaîne Rootstock. Cela permet aux mineurs de Bitcoin de sécuriser simultanément Bitcoin et Rootstock avec la même infrastructure et la même consommation d'énergie, ce qui leur permet d'obtenir des récompenses minières des deux réseaux en dépensant la même somme. Si vous êtes plus familier avec le PoS, le merge-mining serait analogue au restaking - la même ressource (par exemple l'ETH) est utilisée pour sécuriser simultanément la chaîne PoS native (via les plateformes de liquid staking) et les réseaux PoS externes (en redémarrant votre LST pour sécuriser les réseaux de votre choix).
[Alexei Zamyatin] illustré : merge-mining
À l'heure où nous écrivons ces lignes, environ 80 % des mineurs de Bitcoin ont choisi de participer au processus de fusion-minage de Rootstock. Chaque PoW d'un bloc Rootstock héritera désormais d'environ 80 % de la puissance de hachage de Bitcoin !
Pour faciliter le débit de la chaîne, les blocs de Rootstock sont conçus pour être extraits plus rapidement que les blocs de Bitcoin (leur difficulté est donc inférieure à celle de Bitcoin). À ce jour, le temps de blocage moyen de Rootstock est d'environ 25 secondes, alors que celui de Bitcoin est de 10 minutes.
tldr
Pour intégrer le BTC à la chaîne, Rootstock a mis en place un type spécial d'installation de BTC fédéré qui s'accompagne d'une particularité matérielle. Les signataires doivent exécuter le module de sécurité matériel de Rootstock, appelé PowHSM. Le PowHSM est un dispositif inviolable chargé de stocker la clé du signataire qui fait partie du système multisig de la fédération. À l'instar de la mise en œuvre du CubeSigner de Lombard, le PowHSM est conçu pour garantir que les clés restent dans le matériel sécurisé de la génération à la signature - personne, pas même Rootstock ou les signataires eux-mêmes, ne peut voir les clés, et encore moins des attaquants extérieurs pour les extraire.
Le contrat Bridge sur Rootstock exécute Bitcoin SPV, ce qui lui donne une vue sur Bitcoin à partir de Rootstock, sans aucune confiance. Pour les transactions peg-in, les pegnatories attendent que le dépôt de BTC de l'utilisateur sur Bitcoin accumule 100 confirmations avant d'informer le Bridge, qui frappera alors rBTC pour l'utilisateur après vérification du dépôt de BTC de l'utilisateur (via Bitcoin SPV).
Pour les transactions de peg-out, le Bridge acceptera d'abord la demande de peg-out. Après 4000 confirmations de blocs (sur Rootstock), le Bridge construit la transaction Bitcoin peg-out correspondant à cette demande pour que les pegnatories la signent. Chaque PowHSM recevra alors cette commande (via Powpeg, c'est-à-dire les nœuds complets de Rootstock) et déclenchera la signature de la transaction par le pegnatory. Une fois qu'une majorité de pegnatories aura signé la transaction, le multisig Bitcoin de Rootstock libèrera le montant correspondant de BTC à l'adresse Bitcoin de l'utilisateur effectuant le retrait.
que les collusions soient condamnées
Ce qui distingue la mise en œuvre du pont BTC fédéré de Rootstock des autres, c'est qu'il ne nécessite pas une confiance majoritaire honnête de la part de son ensemble de signataires pour que son pont reste sécurisé. En d'autres termes, même si une majorité des signataires de Rootstock s'entendent, ils ne seront pas en mesure de compromettre le pont et de voler les fonds des utilisateurs.
Comment cela est-il possible ? La raison en est que Rootstock est capable de découpler la génération de transactions de la signature des transactions, et de l'associer à une signature sécurisée par HSM connectée à Powpeg.
À titre d'exemple, dans une construction multisig ou MPC typique, les signataires génèrent et signent des transactions. Si l'on prend l'exemple de Lombard, un utilisateur doit d'abord soumettre une demande de peg-out en interagissant sur la chaîne avec un contrat-pont Lombard. L'un des signataires de Lombard le récupère, puis génère la demande de l'utilisateur sous la forme d'une transaction Bitcoin avant de la proposer au Consortium pour approbation. Une fois la majorité approuvée, le multisig Bitcoin de Lombard libère le montant en BTC correspondant à l'utilisateur effectuant le retrait. Il faut s'attendre à ce que ce processus soit représentatif de tous les ponts BTC fédérés, à l'exception de quelques variations mineures (sans conséquence).
Ensuite, on remarque que le signataire Lombard est celui qui génère la transaction Bitcoin facilitant le peg-out de l'utilisateur. En cas de collusion entre les signataires majoritaires, le signataire (avec la bénédiction de la majorité) sera en mesure de proposer une transaction frauduleuse au consortium pour approbation par la majorité. C'est pourquoi les ponts BTC fédérés ont presque toujours impliqué une hypothèse de sécurité de majorité honnête - c'est-à-dire, jusqu'à Rootstock !
[IOV Labs] Illustration : architecture du Powpeg de Rootstock
Rootstock est unique en ce sens que les pegnatories ne génèrent pas de transactions Bitcoin correspondant à la demande de peg-out d'un utilisateur. En effet, c'est le contrat Bridge sur Rootstock qui crée la transaction Bitcoin pour l'utilisateur, laquelle est à son tour validée par les mineurs Bitcoin qui ont choisi de participer au processus de fusion-minage de la chaîne. Les pegnatories ne jouent aucun rôle dans la génération de la transaction - leur rôle consiste simplement à exécuter le PowHSM, qui se connecte à Powpeg et signera "automatiquement" la transaction déjà construite une fois qu'il l'aura reçue.
Pour visualiser, imaginez que vous visitez l'interface d'Uniswap pour effectuer un échange. Tout d'abord, votre portefeuille (c'est-à-dire Metamask) génère des données de transaction basées sur ce que vous avez l'intention de faire (par exemple, " échanger X ETH contre USDC "), qui s'affichent ensuite sur votre portefeuille matériel (c'est-à-dire Ledger) pour que vous puissiez les signer. Dans ce scénario, celui qui clique sur l'interface Uniswap est analogue à l'utilisateur effectuant le retrait, le portefeuille générant les données de la transaction est analogue au contrat Bridge sur Rootstock, et celui qui appuie sur les boutons physiques du portefeuille matériel est analogue au PowHSM fonctionnant en mode pegnatoire qui signe la transaction reçue.
dans le matériel auquel nous faisons confiance.
Rappelons que la blockchain Rootstock est maintenant fusionnée avec 80 % de la puissance de hachage de Bitcoin. Par conséquent, à moins que vous ne souhaitiez emprunter la voie la plus difficile et tenter de compromettre le pont rBTC en possédant >40 % de la puissance de hachage de Bitcoin et en la conservant pendant au moins 4000 blocs Rootstock (~28 heures), en tant qu'attaquant potentiel, vous feriez mieux de cibler l'intégrité de l'implémentation PowHSM de Rootstock à la place. Tout comme vous feriez confiance à Cubist pour annuler le risque opsec du signataire de Lombard, l'utilisateur devrait également faire confiance à Rootstock Labs pour s'assurer que le PowHSM géré par les pegnatoires ne comporte pas de bogues ou de portes dérobées pouvant être exploitées par Rootstock, un attaquant potentiel ou même les pegnatoires eux-mêmes.
Pour sa défense, Rootstock a pris des mesures pour réduire le degré de confiance que les utilisateurs doivent leur accorder en ouvrant le micrologiciel PowHSM. Cependant, comme le micrologiciel lui-même est mis en œuvre au-dessus de Ledger Nano S ou Intel SGX, les utilisateurs doivent toujours faire confiance à Ledger ou Intel (en tant que fabricants) sur leur parole que la puce Secure Element est effectivement sécurisée, et qu'ils n'introduiront pas de canaux secrets, de générateurs de nombres aléatoires biaisés, ou toute autre forme de porte dérobée sur leurs appareils.
conclusion
En s'appuyant sur la défense en profondeur (ou sécurité par couches), Rootstock a accompli ce que personne d'autre n'a fait : mettre en œuvre un pont BTC fédéré qui ne nécessite pas une hypothèse de majorité honnête pour la sécurité des fonds déposés par les utilisateurs.
Mais encore une fois, moins de confiance ne veut pas dire pas de confiance du tout. Vous devez toujours faire confiance à la composition de l'ensemble des 12 membres du pegnatoire de Rootstock, tout comme vous faites confiance aux ensembles de signataires d'autres ponts fédérés. Toutefois, dans le cas de Rootstock, étant donné que les pegnatories n'ont pas le pouvoir d'altérer les données de transaction (ils exécutent "simplement" le PowHSM), vous éliminez le risque de collusion avec une majorité honnête et vous ne faites confiance aux pegnatories "que" pour la vivacité. Cependant, dans le cas où une majorité de pegnatories sont hors ligne, vous courez le risque de voir vos fonds bloqués dans le multisig Bitcoin de Rootstock.
En outre, vous devez également faire confiance à la sécurité de l'implémentation PowHSM de Rootstock. Cela implique de s'assurer que les installations de microprogrammes sur les PowHSM sont effectuées correctement, et de faire confiance à Ledger et/ou Intel en ce qui concerne l'intégrité de leurs dispositifs.
[Rootstock] la vue d'ensemble : Le peg à deux voies fédéré de Rootstock et la chaîne principale de Bitcoin
Le pont rBTC de Rootstock est en effet une amélioration majeure des ponts BTC fédérés existants, mais le fait est qu'il nécessite toujours que l'utilisateur place un certain niveau de confiance dans certaines parties de la pile. Bien que je ne nie pas que la sécurité offerte par la configuration du pont fédéré de Rootstock est déjà plus que suffisante pour 99% des jetons et représentations existants, je m'écarte du sujet lorsqu'il s'agit de BTC - un pont minimisant la confiance n'est pas seulement préférable, mais c'est plutôt une condition préalable.
Rootstock mérite beaucoup de fleurs pour avoir (à mon avis) non seulement la meilleure implémentation de pont BTC fédéré, mais aussi le meilleur pont BTC global qui fonctionne actuellement - en équilibrant élégamment les besoins de sécurité et d'efficacité du capital dans sa conception.
Toutefois, le travail n'est pas terminé - pour l'instant.
BTC collatéralisé
Hormis Lightning, les ponts de BTC collatéralisés représentent l'un des seuls moyens connus d'"exporter" des BTC vers une chaîne ou une couche évolutive de manière réellement illimitée.
Aucune réputation n'est impliquée, aucune entité de confiance n'est nécessaire. Conçu pour être ouvert à tous, mais avec un minimum de confiance, les utilisateurs n'ont pas besoin de faire confiance à qui que ce soit.
Ici, l'argent liquide est littéralement roi.
tldr
L'idée est simple : pour chaque dollar de BTC déposé dans le pont de BTC collatéralisé, il y aurait au moins plus d'un dollar d'autres actifs qui le soutiendraient.
Qu'en est-il de la mise en œuvre ? Pas tant que ça !
Bien qu'il existe des variations mineures, nous pouvons principalement classer les ponts BTC collatéralisés en deux types de mise en œuvre : les passerelles de type CDP et les passerelles pondérées par les enjeux.
Interlay iBTC
CDP signifie collateralized debt position, popularisé par MakerDAO et que l'on retrouve principalement dans les projets de stablecoins décentralisés tels que le LUSD de Liquity et le DAI de MakerDAO lui-même. Pour frapper un jeton de dette (alias LUSD ou DAI), les utilisateurs doivent déposer un collatéral (c'est-à-dire wBTC, ETH) dépassant la valeur de la dette maximale autorisée de la position. Le ratio de collatéralisation dépendra de la volatilité et du risque perçus de l'actif collatéral - les actifs sûrs de premier ordre auront tendance à obtenir un ratio plus faible, tandis que les actifs à long terme nécessiteront un ratio de collatéralisation plus élevé pour compenser leur risque perçu. Si le ratio de collatéralisation tombe en dessous d'un certain seuil (c'est-à-dire 110 %), les coffres-forts seront liquidés et les détenteurs de positions risqueront de perdre l'intégralité de leur collatéral.
L'iBTC d'Interlay est un exemple de mise en œuvre d'un pont de BTC de type CDP, dans lequel chaque dollar de BTC transféré doit être soutenu par plus d'un dollar de garantie sur la chaîne de destination. Pour frapper l'iBTC, les coffreurs doivent d'abord déposer des garanties sur Interlay avant de déposer des BTC sur la chaîne principale. La quantité d'iBTC qui peut être frappée correspond à la valeur de la garantie du vaulter sur Interlay : si la garantie verrouillée vaut 160 $, les vaulters ne peuvent frapper que 100 $ d'iBTC sur Interlay(160% CR). Si la valeur du collatéral du vaulter tombe en dessous du ratio de liquidation, n'importe qui pourra brûler des iBTC pour racheter son collatéral avec une prime (110%), ce qui garantit que le système reste sain car les liquidateurs surveilleront constamment les coffres pour avoir une chance d'extraire des primes de liquidation.
[Interlay] illustré : Interlay iBTC
Pour échanger des iBTC contre des BTC sur Bitcoin, les utilisateurs soumettent d'abord une demande à un vaulter, qui traitera ensuite le retrait en envoyant le montant BTC correspondant à l'utilisateur à partir de son coffre-fort Bitcoin. Si le vaulter se déconnecte ou refuse simplement de racheter des BTC, l'utilisateur peut réclamer la garantie du vaulter correspondant à la valeur de son rachat d'iBTC, plus une certaine récompense pour "échec du rachat". De cette manière, les coffreurs sont incités à racheter des BTC pour l'utilisateur, de peur de risquer de payer une prime à l'utilisateur avec leur garantie bloquée sur Interlay.
Seuil tBTC
D'autre part, les passerelles pondérées par les enjeux sont essentiellement des passerelles BTC fédérées, mais au lieu de restreindre l'ensemble des signataires à quelques entités de confiance triées sur le volet, tout le monde peut participer en tant que signataire en attachant ses actifs à la passerelle (et en exécutant le logiciel requis pour fonctionner en tant que signataire pour la passerelle). Les privilèges de signature sont distribués via multisig et/ou MPC, en fonction des détails de mise en œuvre de chaque passerelle.
Examinons maintenant tBTC de Threshold, sans doute l'implémentation la plus importante du pont BTC pondéré par les enjeux. Threshold s'appuie sur le MPC pour générer l'adresse de dépôt Bitcoin de son pont, chacune étant composée de 100 signataires. Les signataires sont choisis par le biais d'un processus aléatoire (via Sortition Pool), où la probabilité qu'un signataire soit choisi comme signataire est égale au pourcentage de sa mise de 10 $T par rapport à l'ensemble des signataires - si vous avez misé 10 $T et que l'ensemble des signataires a misé 800 $T au total, votre chance d'être choisi comme signataire pour cette adresse de dépôt Bitcoin sera de 1,25 %. Si l'on suppose qu'il y a 100 signataires pour une adresse de dépôt Bitcoin, vous pouvez vous attendre à ce que votre nœud soit composé d'au moins un signataire de l'ensemble. De plus, comme Threshold utilise l'algorithme ECDSA de Threshold pour la génération et la signature des portefeuilles, 51 signataires sur 100 doivent coopérer pour transférer des fonds hors des adresses de dépôt Bitcoin de Threshold.
[Chaos Labs] illustré : Seuil tBTC
Tous les 14 jours, le pont génère une nouvelle adresse de dépôt Bitcoin pour les dépôts BTC des utilisateurs, sur la base de la composition actuelle du staking de Threshold. En plus de permettre aux nouveaux stakers de devenir signataires des futures adresses de dépôt Bitcoin de Threshold, cela permet également d'assurer la sécurité: même si une majorité corrompue devait constituer la composition du staking de Threshold, cela ne compromettrait que les nouvelles adresses de dépôt Bitcoin générées à partir de ce moment-là. En d'autres termes, si vous avez utilisé Threshold pour transférer vos BTC (et frapper des tBTC) avant que la majorité corrompue ne prenne le contrôle de la composition de l'enjeu, vos BTC resteront stockés en toute sécurité dans l'adresse de dépôt Bitcoin contrôlée par l'ensemble des signataires de la majorité honnête alors sécurisée.
iBTC - nous faisons confiance au collatéral
Les deux modèles de passerelle (CDP et stake-weighted) n'imposent pas un ensemble fermé d'entités privilégiées dans leur conception. L'identité et la réputation du signataire n'ont pas d'importance ici - la seule chose qui compte en ce qui concerne la sécurité de la passerelle, c'est la garantie qui est bloquée dans le système.
Dans le cas du pont de type CDP d'Interlay, les utilisateurs doivent faire confiance à la garantie qui couvre chaque iBTC. Si le pont accepte des actifs douteux comme garantie, il court le risque d'une sous-collatéralisation : les liquidateurs peuvent ne pas être motivés pour liquider les chambres fortes si la garantie qu'ils reçoivent en échange ne dispose pas d'un marché liquide ou d'une découverte de prix efficace. Pour illustrer ce point, imaginez que vous êtes un liquidateur et posez-vous la question suivante : êtes-vous prêt à liquider un coffre-fort en payant une prime de 10 % pour un memecoin dont la liquidité sur la chaîne est faible et dont le prix est susceptible de varier de 20 % d'une heure à l'autre ?
En tant qu'utilisateur, il est inévitable que vous deviez faire confiance au réseau d'oracles qui diffuse les prix des actifs collatéraux sur Interlay. Les oracles ne sont pas construits de la même manière - si certains disposent d'un échantillon important pour leurs sources de prix et mettent en œuvre des pratiques de sécurité robustes, d'autres peuvent être un peu plus suspects. En fait, le maillon faible s'est souvent avéré être l'oracle plutôt que le collatéral de la CDP ou la mise en œuvre de ses contrats intelligents !
tBTC - nous faisons confiance aux stakers
Naturellement, en tant que pont pondéré par les enjeux, les détenteurs de tBTC devraient avoir confiance dans le fait que la composition des enjeux en $T de Threshold reste décentralisée, et qu'aucune entité ou coalition ne sera en mesure d'atteindre plus de 51% des $T misés - aujourd'hui ou à l'avenir.
Bien que la sécurité à terme de Threshold limite les dommages aux seuls dépôts futurs de BTC après le point de compromission (composition du staking), vous ne pouvez pas savoir avec certitude quand cela se produit réellement. L'attaquant peut simplement répartir ses soldes en $T sur plusieurs adresses, ce qui donne l'impression que les soldes sont détenus par plusieurs parties alors qu'ils sont en fait contrôlés par la même entité. Ce problème est aggravé par l'incapacité de l'algorithme de signature sous-jacent de Threshold à identifier les signataires qui se comportent mal (du moins dans tBTC v1), ce qui permet aux attaquants potentiels de ne pas être détectés alors qu'ils se glissent lentement dans l'ensemble des signataires et finissent par former une majorité de mise. Ce qui précède préoccupe apparemment suffisamment Threshold pour qu'il ait décidé de lancer le pont avec un ensemble de signataires autorisés, dans lequel seules des entités réputées et approuvées sont autorisées à être signataires - faisant effectivement de Threshold, au moins dans sa forme actuelle, un pont BTC quasi-fédéré !
Mais pour les besoins de l'argumentation, supposons que le pont soit rendu sans permission - le jeton $T a atteint des milliards de capitalisation boursière, et il serait très improbable qu'un attaquant puisse accumuler des $T à hauteur de 51% de la composition de la mise en jeu du pont. Même dans cet état de "fin de partie", le pont est toujours limité par sa capacité : les dépôts de BTC des utilisateurs ne sont considérés comme économiquement sûrs que si l'ensemble des signataires risque de perdre plus en garanties que ce qu'ils pourraient gagner en volant les fonds des utilisateurs sur toutes les adresses de dépôt de Bitcoin qu'ils contrôlent collectivement.
Pour quantifier ce qui précède, imaginons un scénario dans lequel un total de 10 millions de dollars est mis en jeu sur Threshold. Toujours dans un souci de simplicité, supposons que l'ensemble des signataires reste inchangé tout au long du processus. Puisque vous avez besoin de 51 sur 100 pour la signature, vous pouvez dire que la sécurité économique du pont vaut 5,1 millions de dollars - c'est la valeur collatérale maximale disponible pour que Threshold puisse frapper les mauvais faiseurs d'enjeux. En théorie, une fois que la somme des dépôts en BTC des utilisateurs sur les adresses de dépôt en Bitcoin contrôlées a atteint un total de plus de 5,1 millions de dollars, il devient rentable pour les signataires de s'entendre et de siphonner les fonds des utilisateurs. Bien qu'en pratique, l'ensemble des signataires ne soit pas fixé sur plusieurs adresses de dépôt Bitcoin (pour tenir compte des nouveaux et des anciens signataires), la théorie du jeu reste valable : une majorité de signataires malhonnêtes est capable de compromettre le pont à condition que la valeur des dépôts en BTC des utilisateurs sur les adresses de dépôt Bitcoin contrôlées soit supérieure à la garantie mise en jeu qu'ils risquent de perdre.
conclusion
À l'exception de Lightning, seuls les ponts de BTC garantis peuvent prétendre à une véritable absence de permission. Malheureusement, ils comportent également un ensemble d'énigmes et d'hypothèses de confiance implicites qui existent en dehors du pont lui-même.
La sécurité des ponts de type CDP est fondamentalement liée à la composition du collatéral qu'ils acceptent pour garantir le pont. Si le pont se limite aux actifs de haute qualité (c'est-à-dire l'ETH), il devra alors rivaliser avec d'autres protocoles DeFi en termes de rendement pour attirer ces actifs : pourquoi un détenteur d'ETH déposerait-il chez vous, alors qu'il peut obtenir des rendements plus élevés sur d'autres protocoles ?
CDP-style bridges are also highly capital-inefficient — in the case of Interlay, at least $1.6 worth of collateral is needed in order to mint $1 worth of iBTC. You can only lower the collateralization ratio down to a certain threshold: set it too low (<110%), and you’re staring at a barrel of failed liquidations and the risk of the bridge failing due to being straddled by bad debt.
Il y a également la question de la sécurité de l'oracle. Pour que des liquidations ordonnées soient possibles, les passerelles de type CDP s'appuient sur des flux de prix robustes et précis provenant de l'oracle. Cela signifie que, par défaut, les utilisateurs doivent également faire confiance au réseau ou au fournisseur de l'oracle de la passerelle.
En ce qui concerne les passerelles pondérées par les enjeux, la distribution des enjeux est le facteur décisif - après tout, elle détermine qui fera partie de l'ensemble des signataires lors de la génération des nouvelles adresses de dépôt Bitcoin de la passerelle. Les utilisateurs doivent être convaincus que la distribution de la propriété du jeton de mise est suffisamment décentralisée pour qu'aucune entité ou coalition ne puisse atteindre la majorité - aujourd'hui et à l'avenir.
En outre, les ponts pondérés par les enjeux sont fondamentalement limités en capacité (même si c'est beaucoup mieux que les ponts de type CDP) - ils ne peuvent sécuriser économiquement les dépôts de BTC des utilisateurs qu'à hauteur de la valeur collatérale totale mise en jeu par une majorité potentielle de signataires malhonnêtes. Cela limite effectivement la quantité de BTC qui peut être stockée en toute sécurité sur les multiples adresses de dépôt du pont - en aucun cas la valeur totale des dépôts de BTC des utilisateurs sur ces adresses ne doit dépasser la valeur collatérale totale mise en jeu par la majorité des signataires qui les contrôlent.
Les représentations ne sont pas égales
La sortie de la chaîne principale s'accompagne de son lot de nuances. Il est vrai que les représentations de BTC en dehors de Bitcoin ne seront jamais aussi sûres que la détention de BTC sur la chaîne principale, mais parfois vous n'avez pas besoin d'autant de sécurité pour votre réserve de toute façon. Tout le monde ici n'est pas millionnaire, vous savez !
Bien que je pense que la plupart des couches et des ponts de mise à l'échelle de BTC qui sont discutés ci-dessus resteront raisonnablement sûrs dans un avenir prévisible, je pense qu'il est important qu'en tant qu'hébergeur de BTC autonome, vous soyez au moins conscient des choix qui s'offrent à vous sur le marché aujourd'hui. J'espère que, grâce à cet article, l'utilisateur moyen de BTC est désormais mieux informé sur les compromis de confiance qui existent lorsqu'il s'agit de naviguer dans différents environnements d'autodétention.
Pour notre prochain article de la série, nous allons explorer la découverte qui change la donne, à savoir BitVM, un paradigme informatique sur Bitcoin qui permet d'exécuter des programmes sur Bitcoin de manière optimiste. Cela signifie qu'il traite la plupart des calculs en dehors de la chaîne et qu'il n'est donc pas entravé par les limites de Bitcoin. Toutefois, si quelqu'un n'est pas d'accord avec le résultat, il peut soulever un litige sur la chaîne de Bitcoin. En cas de tricherie, la personne frauduleuse est démasquée et sanctionnée. Dans un premier temps, cela permettra pour la première fois de construire des ponts BTC à confiance réduite entre Bitcoin et des couches de mise à l'échelle externes. À l'avenir, BitVM pourrait même permettre de véritables rollups Bitcoin où les données de transaction sont stockées sur la blockchain Bitcoin.
La chaîne hybride de BOB fusionne les forces de la sécurité de Bitcoin et les outils de pointe d'EVM, héritant ainsi du meilleur des deux mondes. Première implémentation pratique de BitVM au monde, BOB sera le siège de transactions en bitcoins sûres et bon marché et de DeFi - voici le bitcoin natif, en dehors du bitcoin !
Cela semble trop beau pour être vrai ? Restez à l'écoute pour la deuxième partie - une plongée en profondeur dans la chaîne hybride de BOB, la passerelle vers Bitcoin DeFi.
Si vous pensez que j'ai oublié quelque chose qui mérite d'être mentionné, n'hésitez pas à me contacter sur X/Twitter - je suis toujours ouvert aux suggestions et aux commentaires. De plus, si vous avez trouvé cet article utile, les rediffusions et les likes sont très appréciés !
