jakiro
Auteur: Chakra; Traduction: 0xjs @ Bitchain Vision
Il existe plusieurs chemins pour l’expansion du bitcoin, et la première partie de notre série a décrit l’un des chemins « Solution d’extension native de Bitcoin», Un autre chemin consiste à établir une couche supplémentaire de protocoles au-dessus du bitcoin, appelé couche 2. L’aspect le plus critique de la solution à 2 couches est le pont bidirectionnel de sécurité et l’héritage de la sécurité du consensus Bitcoin.
Chaîne latérale
Le concept de laasque remonte à 2014, lorsque Blockstream a soumis «en utilisant des effectifs accrochés pour réaliser l’innovation de la blockchain».Il représente une méthode de mise à l’échelle relativement basique.
Comment faire fonctionner la chaîne latérale
Sidechain est une blockchain qui fonctionne indépendamment de la chaîne principale, avec son propre protocole consensuel et peut servir de site de test pour l’innovation de la chaîne principale.Lorsque des événements indésirables se produisent sur la chaîne latérale, les dommages sont complètement limités à la chaîne latérale elle-même sans aucun impact sur la chaîne principale.Les échecs peuvent adopter des protocoles de consensus avec des TP plus élevés (transactions par seconde), améliorer la programmabilité sur chaîne et favoriser l’amélioration des capacités de BTC.
Sidechain peut réaliser le transfert de Bitcoin entre différentes blockchains à travers une cheville bidirectionnelle ou unidirectionnelle.Mais en réalité, BTC ne peut résider que sur le réseau principal du Bitcoin, donc un mécanisme d’ancrage est nécessaire pour connecter BTC sur la chaîne latérale avec BTC sur le réseau principal Bitcoin.
Le crochet à sens unique oblige l’utilisateur à envoyer BTC du réseau principal à une adresse indisponible pour la destruction, puis à jeter une quantité égale de BTC sur la chaîne latérale, mais ce processus est irréversible.Les crochets bidirectionnels sont une amélioration des crochets à sens unique qui permettent à BTC de se déplacer d’avant en arrière entre la chaîne principale et la chaîne latérale.Le crochet bidirectionnel n’est pas détruit en envoyant une adresse indisponible, mais en verrouillant le BTC à travers plusieurs signatures ou autres scripts de contrôle, en jetant un nouveau BTC sur la ligne de redimension.Lorsqu’un utilisateur souhaite revenir au réseau principal, le BTC sur la chaîne latérale sera détruit et le BTC verrouillé à l’origine sera publié sur le réseau principal.
La mise en œuvre d’une PEG unidirectionnelle est beaucoup plus simple qu’un PEG bidirectionnel, car il ne nécessite pas de gestion de l’état pertinent sur le réseau principal Bitcoin.Cependant, les actifs Sidechain créés à travers des crochets à sens unique peuvent être sans valeur car ils n’ont pas le mécanisme d’ancrage inversé.
Il existe différentes solutions et niveaux de sécurité pour les transactions verrouillées sur la chaîne principale et détruire les transactions sur la chaîne latérale.Le moyen le plus simple est d’effectuer une vérification externe par le biais de participants multi-signatures, mais cela présente un risque élevé de centralisation.Une meilleure option consiste à utiliser la preuve SPV pour une vérification décentralisée.Cependant, comme le Bitcoin MainNet n’a pas les capacités de programmation nécessaires et ne peut pas effectuer de vérification SPV, d’autres méthodes doivent être utilisées, généralement un hébergement multi-signature.
Problèmes et méthodes
Les principales critiques des chaînes latérales comprennent:
1. Vérificateur de dépendance des actifs transversaux: Étant donné que le réseau principal de Bitcoin ne peut toujours pas mettre en œuvre des contrats intelligents, le transfert d’actifs transversaux ne peut pas être géré via la logique des contrats sans confiance.Le retour des actifs des échecs au bitcoin nécessite de s’appuyer sur un ensemble de validateurs, d’introduire des hypothèses de confiance et des risques de fraude.
2. Les échecs ne peuvent pas hériter de la sécurité de la chaîne principale: parce que les effectifs fonctionnent complètement indépendamment du réseau principal, ils ne peuvent pas hériter de la sécurité du réseau principal, ce qui peut entraîner une réorganisation de blocs malveillants.
Pour résoudre ces problèmes, le Sidechain adopte des méthodes, notamment en s’appuyant sur les institutions faisant autorité (fédérales), la sécurité économique (POS), les mineurs de bitcoin décentralisés (mine de fusion) et les modules de sécurité matérielle (HSM).La garde des fonds sur le bitcoin et la production de blocs sur les échelons peuvent être gérées par différents rôles, introduisant des mécanismes de sécurité plus complexes.
Étude de cas
Liquide
L’une des premières formes de latérales est une échelle fédérée, qui s’appuie sur un groupe d’entités présélectionné en tant que validateurs, responsable des actifs de garde sur le réseau principal et générant des blocs sur la chaîne de côté.
Liquid est un exemple classique d’une chaîne de côté fédérale avec 15 participants agissant en tant que validateurs.La gestion des clés privées n’est pas divulguée publiquement et la vérification nécessite 11 des 15 signatures.La production de blocs sur la chaîne de touche liquide est également maintenue par ces 15 participants.Le nombre de nœuds dans cette fédération est plus petit et donc un volume de transaction plus élevé par seconde (TPS) pour atteindre les objectifs d’évolutivité, et sa zone d’application principale est défi.
Cependant, le modèle fédéral de laasque à la main présente des risques de sécurité centralisés importants.
Rogottock (RSK)
RSK est également géré par 15 nœuds qui hébergent les principaux fonds du réseau et seulement 8 signatures sont nécessaires pour la vérification.Contrairement à Liquid, les clés multi-signatures de RSK sont gérées par le module de sécurité matérielle (HSM), et les instructions de crochet sont signées en fonction de la preuve de travail (POW), empêchant les vérificateurs ayant un accès clé pour manipuler directement les fonds de garde.
En termes de consensus de la chaîne latérale, RSK adopte la fusion de l’exploitation et utilise la puissance de calcul du réseau principal pour garantir la sécurité des transactions de chaîne latérale. Dépensant l’attaque des chaînes latérales.RSK s’est amélioré sur la base de l’exploitation de fusion et, grâce à la perception de la fourche, une intervention consensuelle hors chaîne est effectuée sur le comportement de la fourche, garantissant ainsi la sécurité des chaînes latérales sous un faible pouvoir de calcul et réduisant la possibilité d’attaques à double dépense.
Cependant, l’exploitation de fusion a changé le mécanisme d’incitation des mineurs, exacerbant le risque de valeur extractible des mineurs (MEV) et sapant potentiellement la stabilité du système.Au fil du temps, l’extraction de fusion peut exacerber la centralisation de l’exploitation minière.
Piles
Stacks réalise la même finalité que Bitcoin en soumettant la valeur de hachage de son bloc d’accueil dans le bloc Bitcoin et en ancrant son historique de chaîne à Bitcoin.Ce n’est que lorsque Bitcoin lui-même Fork est la fourche dans les piles, améliorant ainsi sa résistance aux attaques de paiement à double dépenses.
SBTC présente un nouveau jeton et un modèle d’incitation qui utilise un pont de jalonnement qui permet jusqu’à 150 validateurs MainNet.Les vérificateurs doivent engager des jetons STX pour obtenir la permission d’approuver les dépôts et les retraits.La sécurité du pont de gage dépend dans une large mesure de la valeur des actifs promis, ce qui présente un risque pour la sécurité transversale du BTC pendant une période de fluctuation substantielle du prix des actifs promis.
D’autres propositions de Sidechain sont actuellement en cours de discussion dans la communauté.
Drivechain
Le plus notable d’entre eux est la proposition DriveChain proposée par Paul Sztorc en 2015, qui alloue les technologies clés au BIP 300 (mécanisme de crochet) et BIP 301 (exploitation de fusion aveugle).BIP 300 définit la logique de l’ajout de nouvelles échecs, similaires à l’activation de nouvelles échecs à travers des signaux de mineurs (tels que des fourches souples).Le BIP 301 permet aux mineurs de Bitcoin de devenir des producteurs de blocs de latéraux sans vérifier les détails spécifiques de la transaction.
Les mineurs de Bitcoin sont également chargés d’approuver les transactions de retrait.Ils lancent des propositions de retrait en créant une sortie OP_return dans la transaction Coinbase du bloc qu’ils ont extrait.D’autres mineurs peuvent ensuite voter sur la proposition en le soutenant ou en s’opposant à chaque bloc qu’ils exploitent.Une fois que la transaction de retrait dépasse le seuil (13 150 blocs), il est exécuté et confirmé sur la chaîne principale Bitcoin.
En fait, les mineurs ont un contrôle complet sur les fonds sur DriveChain.Si les fonds sont volés, les utilisateurs ne peuvent que se sauver via l’activation des utilisateurs Soft Forks (UASF), ce qui est difficile à atteindre un consensus.De plus, la position unique des mineurs dans DriveChain augmente le risque de MEV, qui a été prouvé dans Ethereum.
Spacechain
Spacechain adopte une approche différente, en utilisant une PEG permanente à sens unique (P1WP), où les utilisateurs détruisent BTC pour obtenir des jetons sur SpaceChain, en contournant complètement les problèmes de sécurité des fonds.Ces jetons ne sont utilisés que pour soumissionner pour un espace de bloc sur SpaceChain et n’ont aucun magasin de capacités de valeur.
Pour garantir la sécurité des chaînes latérales, SpaceChain utilise l’exploitation de fusion aveugle et les utilisateurs utilisent AnyPrevout (APO) pour enchérir publiquement pour le droit de construire des blocs.Les mineurs de Bitcoin soumettent simplement les en-têtes de blocs de spacechain dans leurs blocs sans vérifier les blocs Sidechain.Cependant, le lancement de SpaceChain nécessite le soutien de Bitcoin pour les alliances, et la communauté Bitcoin discute toujours de savoir s’il est nécessaire d’effectuer une fourche douce pour ajouter des opcodes d’alliance.
Dans l’ensemble, l’objectif de SpaceChain est d’atteindre les mêmes échecs décentralisés et résistants aux censureurs que le bitcoin, tout en améliorant la programmabilité à travers ses capacités d’enchères en bloc.
Chaîne de soft
Softchain est une autre proposition de crochet bidirectionnelle (2WP) proposée par Ruben Somsen, qui utilise le mécanisme de consensus POW FP pour protéger les échelons.Dans des circonstances normales, le nœud Bitcoin complet n’a besoin que de télécharger l’en-tête du bloc Softchain pour vérifier la preuve de travail.Si une forking se produit, ils téléchargent des blocs orphelins et le jeu UTXO correspondant promet de vérifier la validité du bloc.
Pour le mécanisme 2WP, lors du transfert vers le lien, une transaction de dépôt sera créée sur la chaîne principale et SoftChain se référera à cette transaction en chaîne principale pour obtenir des fonds; et la chaîne principale citera cette transaction pour récupérer BTC après une période de défi plus longue.Les mécanismes spécifiques de transfert-in et de transfert-out nécessitent une prise en charge de la fourche souple, de sorte que la proposition a été nommée Softchain.
La proposition de SoftChain ajoute des coûts de vérification supplémentaires aux nœuds complets du Bitcoin MainNet, et le consensus divisé dans Softchain peut affecter le consensus sur le MainNet et former un éventuel vecteur d’attaque pour Bitcoin.
Réseau de foudre
Le livre blanc du Lightning Network a été publié en 2015 et a été officiellement lancé en 2018. En tant que protocole de paiement de la couche 2 pour le réseau Bitcoin, il vise à transférer un grand nombre de transactions à petite fréquence à petite échelle au traitement hors chaîne .
Modules de base
La mise en œuvre du réseau Lightning repose sur plusieurs modules importants au sein de Bitcoin, qui garantissent conjointement la sécurité des transactions en ligne.
Tout d’abord, il y a une transaction pré-signature.Ces transactions deviennent sûres à utiliser après les mises à niveau SEGWIT.SEGWIT sépare les signatures des autres données de transaction, résolvant des problèmes potentiels tels que l’évolutivité des transactions, la falsification des transactions tierces et secondaires.La sécurité des calculs hors chaîne dans le réseau Lightning est garanti par un engagement irrévocable fourni par la contrepartie, qui est exécuté par le biais de transactions pré-signature.Une fois que les utilisateurs ont reçu une transaction pré-signée de leurs contreparties, ils peuvent le diffuser à la blockchain à tout moment pour respecter leurs engagements.
Ensuite, il est multi-signature.Les transferts de fonds hors chaîne fréquents entre les deux parties nécessitent un support contrôlé par les deux parties, de sorte que plusieurs signatures sont nécessaires et le schéma 2 sur 2 est généralement utilisé.Cela garantit que le transfert de fonds ne peut être effectué qu’avec le consentement des deux parties.
Cependant, 2 plusieurs signatures multi-2 peuvent provoquer des problèmes d’activité, et si une partie ne coopère pas, l’autre partie ne peut transférer aucun fonds de l’adresse multi-signature, entraînant la perte des fonds d’origine.Les verrous de temps peuvent résoudre le problème d’activité;
Enfin, un verrouillage de hachage est utilisé pour connecter plusieurs canaux d’état pour former un effet réseau.La préimation du hachage agit comme un moyen de communication pour coordonner l’opération correcte entre plusieurs entités.
Processus de fonctionnement
Canal à double sens
Pour utiliser le réseau Lightning pour les transactions, les deux parties doivent d’abord ouvrir un canal de paiement bidirectionnel sur Bitcoin.Ils peuvent effectuer un nombre illimité de transactions hors chaîne et soumettre le dernier statut à la blockchain Bitcoin pour le règlement et la fermeture du canal de paiement une fois toutes les transactions terminées.
Plus précisément, la mise en œuvre du canal de paiement implique les étapes clés suivantes:
1. Créez une adresse multi-signature.Les deux parties doivent d’abord créer une adresse multi-2 sur 2 pour servir de verrouillage de fonds de la chaîne.Chaque partie détient la clé privée pour la signature et fournit sa propre clé publique.
2. Initialisez le canal.Les deux parties diffusent une transaction sur la chaîne, verrouillant une certaine quantité de bitcoin dans une adresse multi-signature en tant que fonds initial du canal.Cette transaction est appelée la transaction « ancre » du canal.
3. Mettre à jour l’état du canal.Lorsque les paiements sont effectués dans le canal, les deux parties échangent des transactions pré-signées pour mettre à jour l’état du canal.Chaque mise à jour génère une nouvelle «transaction d’engagement» qui représente l’allocation actuelle des fonds.Il y a deux résultats pour la transaction promise, qui correspondent à la part en capital des deux parties.
4. diffuser le dernier statut.L’une ou l’autre des parties peut diffuser les dernières transactions d’engagement auprès de la blockchain à tout moment pour retirer leur part de fonds.Pour empêcher l’autre partie de diffuser un État obsolète, chaque transaction promise est accompagnée d’une « transaction de punition » correspondante.
5. Fermez le canal.Lorsque les deux parties décident de fermer la chaîne, elles peuvent collaborer pour générer des «transactions de règlement» et diffuser la répartition finale des fonds à la blockchain.Cela libère des fonds verrouillés dans l’adresse multi-signature aux adresses personnelles des deux parties.
6. Arbitrage en chaîne.Si les deux parties ne peuvent pas s’entendre sur la fermeture du canal, l’une ou l’autre des parties peut diffuser unilatéralement la dernière transaction engagée pour lancer un processus d’arbitrage en chaîne.S’il n’y a pas de litige sur une certaine période de temps (par exemple un jour), les fonds seront distribués aux deux parties en fonction de la distribution de la transaction promise.
Réseau de paiement
En utilisant HTLC (contrat de verrouillage de temps de hachage), les canaux de paiement peuvent être interconnectés pour former un réseau qui prend en charge le routage multi-HOP.HTLC prend le verrouillage du hachage en tant que condition directe et le paiement de la signature du verrouillage du temps en tant que condition de secours, permettant aux utilisateurs d’interagir en fonction de l’image hachée avant l’expiration du verrouillage de l’heure.
Lorsqu’il n’y a pas de canal direct entre deux utilisateurs, le paiement peut être terminé à l’aide de HTLC sur le chemin de routage.Dans le processus, l’avatar R du hachage joue un rôle crucial pour assurer l’atomicité du paiement.De plus, le verrouillage du temps dans HTLC devrait réduire le long de l’itinéraire, garantissant que chaque saut a suffisamment de temps pour traiter et transmettre les paiements.
Problèmes existants
Fondamentalement, le réseau Lightning contourne l’hypothèse de confiance externe de pontage des actifs via des canaux d’état point à point, tout en utilisant des scripts de verrouillage temporel pour fournir une protection ultime pour les actifs et la protection des échecs.Cela permet une sortie unilatérale si la contrepartie perd l’activité et ne coopère pas.Par conséquent, Lightning Network est très pratique dans les scénarios de paiement, mais il a également plusieurs limitations, notamment:
1. Limite de capacité du canal: La capacité du canal de paiement dans le réseau Lightning est limitée par les fonds verrouillés initiaux et ne peut pas soutenir les paiements dépassant la capacité du canal.Cela peut limiter certains cas d’utilisation, tels que le trading des matières premières.
2. Exigences en ligne et synchronisation: Afin de recevoir et de transmettre les paiements en temps opportun, les nœuds du réseau Lightning doivent rester en ligne.Si le nœud est hors ligne pendant longtemps, il peut manquer certaines mises à jour d’état de canal, ce qui entraîne un synchronisation.Cela peut être un défi pour les utilisateurs individuels et les appareils mobiles et augmentera également les coûts d’exploitation des nœuds.
3. Gestion de la mobilité: l’efficacité de routage du réseau de foudre dépend de la distribution de liquidité entre les canaux.Si les fonds sont inégalement distribués, certains chemins de paiement peuvent devenir invalides, affectant l’expérience utilisateur.Le solde des canaux de gestion des liquidités nécessite certaines ressources techniques et financières.
4. Problème de confidentialité: Afin de trouver un chemin de paiement réalisable, l’algorithme de routage de Lightning Network doit comprendre un certain niveau de capacité de canal et d’informations de connexion, qui peuvent révéler la confidentialité des utilisateurs, telles que l’allocation de fonds et la contrepartie.L’ouverture et la clôture des canaux de paiement peuvent également exposer des informations sur les participants.
RVB
Le concept original du protocole RVB a été inspiré par l’idée de Peter Todd de vérification des clients et de scellage unique.Il a été proposé par Giacomo Zucco en 2016 et est un protocole Bitcoin Layer 2 évolutif et protégant la confidentialité.
Concept de base
Vérification du client
Le processus de vérification dans la blockchain implique des blocs de diffusion composés de transactions à l’ensemble du réseau, permettant à chaque nœud de calculer et de vérifier les transactions dans ces blocs.Cela crée efficacement un intérêt public où les nœuds du réseau aident chaque individu à soumettre une transaction pour vérification, et l’utilisateur fournit BTC en tant que frais de transaction en tant que récompense pour la vérification.La vérification du client est plus centrée sur l’individu et la vérification de l’État n’est pas effectuée à l’échelle mondiale, mais est réalisée par des personnes participant à une transition d’état spécifique.Seules les parties qui génèrent des transactions peuvent vérifier la légitimité de ces transitions d’état, améliorant ainsi considérablement la confidentialité, réduisant les charges de nœuds et améliorant l’évolutivité.
Sceau jetable
Les transitions d’état point à point sont en danger, et si l’historique de transition de l’état complet n’est pas accessible, les utilisateurs peuvent être frauduleux, ce qui entraîne des dépenses doubles.Le joint jetable est proposé pour résoudre ce problème.En utilisant des objets spéciaux qui ne peuvent être utilisés qu’une seule fois, ils s’assurent qu’aucun double paiement ne se produit, améliorant ainsi la sécurité.Le modèle UTXO de Bitcoin (Sortie de transaction inutilisés) est le formulaire de scellement unique le plus approprié, protégé par le mécanisme de consensus Bitcoin et la puissance de calcul du hachage du réseau, permettant aux actifs RVB d’hériter des caractéristiques de sécurité de Bitcoin.
Promesse de chiffrement
L’étanchéité unique doit être combinée avec des engagements de cryptage pour garantir que les utilisateurs ont une compréhension claire des transitions de l’État et empêcher les attaques de double paiement.L’engagement à informer les autres que quelque chose s’est produit et ne peut pas être modifié plus tard, et aucun détail spécifique ne sera divulgué jusqu’à ce que la vérification soit nécessaire.Cela peut être fait en utilisant une fonction de hachage.Dans RVB, le contenu promis est une transition d’état qui signale le destinataire de l’actif RVB grâce aux dépenses d’UTXO.Le destinataire de l’actif vérifie ensuite l’engagement en fonction des données spécifiques transmises hors chaîne par le dépensier des actifs.
Flux de travail
RVB utilise le consensus Bitcoin pour garantir la sécurité des paiements et la résistance à la censure, tandis que toutes les tâches de vérification de la transition de l’État sont confiées hors de la chaîne et ne sont effectuées que par le client recevant des paiements.
Pour les émetteurs des actifs RVB, la création d’un contrat RVB consiste à lancer une transaction dans laquelle un engagement à des informations spécifiques est stocké dans un script OP_return dans les conditions de transaction de tapoot.
Lorsque les détenteurs d’un actif RVB souhaitent le dépenser, ils doivent obtenir des informations pertinentes du destinataire des actifs, créer une transaction RVB et soumettre des détails de la transaction.La promesse est ensuite placée dans l’UTXO spécifiée par le destinataire de l’actif et une transaction est émise pour dépenser l’UTXO d’origine et créer le nouvel UTXO spécifié par le récepteur.Lorsque les bénéficiaires d’actifs remarquent que les actifs RVB UTXOS ont été dépensés, ils peuvent vérifier la validité des transactions RVB par le biais d’engagements dans les transactions Bitcoin.Une fois la vérification valide, ils peuvent confirmer en toute confiance la réception des actifs RVB.
Pour les destinataires des actifs RVB, le payeur doit fournir des preuves de l’état initial et des règles de transition de l’État du contrat, chaque transaction Bitcoin utilisée dans le transfert, la transaction RVB soumise pour chaque transaction Bitcoin et la validité de chaque transaction Bitcoin.Le client du destinataire utilise ces données pour vérifier la validité des transactions RVB.Dans cette configuration, UTXO de Bitcoin agit comme un conteneur pour détenir l’état du contrat RVB.L’historique de transfert de chaque contrat RVB peut être représenté comme un graphique acyclique dirigé (DAG), et le destinataire d’un actif RVB ne peut accéder qu’à l’histoire liée aux actifs qu’il détient et ne peut accéder à aucune autre succursale.
Pour les avantages et les inconvénients
Vérification légère
Par rapport à la vérification complète requise par la blockchain, le protocole RVB réduit considérablement le coût de vérification. la transaction.
Cette vérification légère facilite les transactions entre pairs et réduit davantage la dépendance à l’égard des fournisseurs de services centralisés, améliorant la décentralisation.
Évolutivité
Le protocole RVB ne nécessite qu’un engagement de hachage à hériter de la sécurité du bitcoin et utilise des scripts de tapoot pour consommer presque aucun espace de bloc Bitcoin supplémentaire.Cela rend possible la programmation d’actifs complexe.En utilisant UTXO comme conteneur, le protocole RVB prend naturellement la concurrence;
confidentialité
Contrairement aux protocoles typiques, seul le destinataire d’un actif RVB peut accéder à l’historique des transferts d’actifs.Une fois utilisés, ils n’ont pas accès à l’historique des transfert futurs, assurant ainsi grandement la confidentialité des utilisateurs.Les transactions des actifs RVB ne sont pas associées au transfert de Bitcoin UTXO, de sorte que le personnel externe ne peut pas suivre les transactions RVB sur la blockchain Bitcoin.
De plus, RVB prend en charge la production aveugle, ce qui signifie que le payeur n’est pas en mesure de déterminer quels actifs RVB paient, améliorant davantage la confidentialité et la résistance à la censure.
défaut
Lorsque les actifs RVB modifient plusieurs fois les mains, les nouveaux bénéficiaires d’actifs peuvent faire face à des charges de vérification considérables pour vérifier l’historique de transfert long, ce qui peut entraîner des temps de vérification plus longs et perdre la possibilité de confirmer rapidement les transactions.Pour les nœuds fonctionnant dans la blockchain, car ils sont toujours synchronisés avec le dernier état, le temps nécessaire pour vérifier la transition de l’état après avoir reçu un nouveau bloc est réellement limité.
La communauté discute de la possibilité de réutiliser des calculs historiques, tandis que les preuves ZK récursives peuvent mettre en œuvre du temps et de la taille constants de la validation de l’État.
Rouleau
Aperçu
Rollup est la meilleure solution d’extension pour l’écosystème Ethereum.
Rollup est une blockchain autonome qui collecte les transactions à partir de la chaîne Bitcoin, lance plusieurs transactions, exécute ces transactions et soumet les données par lots et les engagements d’état envers la chaîne principale.Cela implémente le traitement des transactions hors chaîne et la mise à jour de l’état.Pour maximiser l’évolutivité, Rollup utilise généralement un trieur centralisé pour améliorer l’efficacité de l’exécution à ce stade sans compromettre la sécurité, car la sécurité est assurée par la vérification de la chaîne principale des transitions de l’état Rollup.
À mesure que la solution de rouleau de l’écosystème Ethereum devient plus mature, l’écosystème Bitcoin a également commencé à explorer les rouleaux.Cependant, une différence clé entre Bitcoin et Ethereum est le manque de capacités de programmation pour effectuer les calculs nécessaires pour construire des rouleaux sur chaîne.Actuellement, il est principalement déterminé à réaliser des rouleaux souverains et des rouleaux OP.
Classification
Les rouleaux peuvent être divisés en deux catégories: les rouleaux optimistes (rouleaux optimistes) et les rouleaux valides (Rollups ZK), la principale différence réside dans la méthode de vérification de la transition d’état.
Optimiste Rollup adopte une méthode de vérification optimiste. .Si aucune preuve erronée valide n’est soumise pendant la période de litige, le lot de transaction est jugé valide et la mise à jour de l’état est confirmée sur la chaîne principale.
La validité Rollup est validée à l’aide d’une preuve de validité.Séquenceur utilise l’algorithme de preuve à connaissance zéro pour générer une preuve de validité concise pour chaque lot de transactions, prouvant que la transition d’état du lot est correcte.Chaque mise à jour nécessite de soumettre la preuve de validité du lot de transaction à la chaîne principale, qui vérifiera immédiatement la preuve et confirmera la mise à jour de l’état.
L’avantage du Rollup optimiste est qu’il est relativement simple et a peu de modifications sur la chaîne principale, mais l’inconvénient est que le temps de confirmation des transactions est long (selon la période de litige) et a des exigences élevées pour la disponibilité des données.L’avantage de la validité est que la vitesse de confirmation des transactions est rapide et n’est pas affectée par la période de litige.
Celestia a également proposé le concept de Rollup souverain, où les données de transaction de Rollup sont publiées sur une blockchain de couche de disponibilité de données (DA) dédiée, qui est responsable de la disponibilité des données, tandis que Sovereign Rollup lui-même est responsable de l’exécution et du règlement.
Explorer et discuter
Les Rollups basés sur Bitcoin en sont encore à leurs débuts.
Rouleau souverain
Le 5 mars 2023, Rollkit a annoncé que c’était le premier cadre pour soutenir les rollups de souveraineté de Bitcoin.Les constructeurs de rouleaux souverains peuvent utiliser Rollkit pour publier des données de disponibilité sur Bitcoin.
Rollkit a été inspiré par les ordinaux à utiliser les transactions de tapoot pour publier des données.Les transactions de tapoot conformes aux normes de pool de mémoire publique peuvent contenir jusqu’à 390 Ko de données, tandis que les transactions de tapoot non standard publiées directement par les mineurs peuvent contenir près de 4 Mo de données arbitraires.
Rollkit fournit essentiellement une interface pour la lecture et l’écriture de données sur Bitcoin, fournissant un service middleware qui transforme Bitcoin en une couche DA.
L’idée de Rollup souverain a rencontré un grand doute.De nombreux critiques affirment que la souveraineté basée sur le bitcoin utilise simplement Bitcoin comme babillard et ne peut pas hériter de la sécurité du bitcoin.En fait, si les données de transaction sont soumises uniquement à Bitcoin, cela n’augmentera l’activité – garantir que tous les utilisateurs peuvent accéder et vérifier les données pertinentes via Bitcoin.Cependant, la sécurité ne peut être définie que par le rouleau souverain elle-même et ne peut pas être héritée.De plus, l’espace de blocage sur Bitcoin est extrêmement précieux, et la soumission des données de transaction complètes peut ne pas être une bonne décision.
OP Rollup and Validity Rollup
Alors que de nombreux projets Bitcoin Layer2 prétendent être des rouleaux ZK, ils sont essentiellement plus proches des Rollups OP, impliquant une technologie de preuve de validité.Mais les capacités de programmation actuelles de Bitcoin ne sont pas suffisantes pour prendre en charge la vérification de la preuve de validité directe.
Actuellement, l’ensemble d’opcode de Bitcoin est très limité et il est impossible de calculer directement la multiplication.La communauté discute activement des options, notamment OP_CAT, OP_CHECKSIG, OP_TXHASH et d’autres options.Idéalement, l’ajout d’op_verify_zkp pourrait résoudre le problème sans aucune modification supplémentaire, mais cela est peu probable.De plus, les limitations de la taille de la pile ont également entravé les efforts pour vérifier la preuve de validité dans les scripts Bitcoin, et de nombreuses explorations sont en cours.
Alors, comment fonctionne la preuve de validité?La plupart des projets publient des différences déclarées et des preuves de validité des transactions en vrac à Bitcoin au format INSCRIR et utilisent BitVM pour une vérification optimiste.Dans ce programme, l’exploitant du pont agit comme un gouvernement fédéral, gérant les dépôts des utilisateurs.Avant qu’un utilisateur ne dépose, le gouvernement fédéral pré-signe UTXO pour s’assurer que le dépôt ne peut être collecté légalement que par l’opérateur.Après avoir obtenu la pré-signature, le BTC est verrouillé dans l’adresse de tapoot N / N multi-signature.
Lorsqu’un utilisateur demande un retrait, Rollup envoie la racine de retrait avec une preuve de validité à la chaîne Bitcoin.L’opérateur paie initialement de sa poche pour répondre aux besoins de retrait de l’utilisateur, puis le contrat Bitvm vérifie la validité.Si chaque opérateur estime que la preuve est valable, il remboursera l’argent à l’opérateur par plusieurs signatures;
Ce processus est essentiellement le même que OP Rollup, où la confiance suppose 1 / N – le protocole est sécurisé tant qu’un vérificateur est honnête.Quant à la preuve de validité, son objectif n’est pas de faciliter la vérification du réseau Bitcoin, mais de faciliter la vérification pour chaque nœud.
Cependant, la mise en œuvre technique de cette solution peut faire face à des défis.
Avec le soutien de Bitcoin Covenant, les opérations de pré-signature dans le pont Bitvm peuvent être exécutées plus efficacement et la communauté doit encore atteindre un consensus.
Du point de vue des attributs de sécurité, en soumettant un hachage de blocage à Rollup à Bitcoin, Bitcoin gagne la possibilité de résister à la restructuration et aux dépenses doubles, tandis que le pont optimiste apporte l’hypothèse de sécurité 1 / n.La capacité optimiste du pont à résister à la censure devrait également être encore améliorée.
Conclusion: La couche 2 n’est pas une pilule magique
Lorsque nous regardons diverses solutions à 2 couches, il est évident que chaque solution a ses limites.L’efficacité de la couche 2 dépend dans une large mesure de la capacité de la couche 1 (c’est-à-dire du bitcoin) sous une hypothèse spécifique de confiance.
Sans les mises à niveau SEGWIT et les verrous de temps, le réseau Lightning n’a pas pu être établi avec succès;
De nombreux plus grands bitcoins croient que le bitcoin ne devrait jamais être modifié, de nouvelles fonctionnalités ne doivent pas être ajoutées et tous les défauts doivent être résolus avec une solution à 2 couches.Cependant, c’est impossible; le niveau 2 n’est pas une pilule magique.Nous avons besoin d’une couche 1 plus puissante pour construire une couche 2 plus sûre, plus efficace et plus évolutive.
Dans notre prochain article, nous explorerons les tentatives pour améliorer la programmabilité Bitcoin.
