Écrit par : Recherche sur les chakras
En plus de la solution d'expansion native mentionnée dans le premier volume, une autre voie d'expansion pour Bitcoin utilise une couche de protocole supplémentaire au-dessus de Bitcoin, appelée couche 2. Les deux points les plus critiques de la solution de couche 2 sont le pont bidirectionnel sécurisé et l’héritage de la sécurité consensuelle de Bitcoin.
Chaîne latérale
L'origine du concept de sidechain remonte à « Enabling Blockchain Innovations with Pegged Sidechain » soumis par blockStream en 2014. Il s'agit d'un plan d'expansion relativement simple.
principe de fonctionnement
La chaîne latérale est une blockchain qui fonctionne de manière totalement indépendante de la chaîne principale. Elle possède son propre protocole de consensus et peut être utilisée comme terrain d'essai pour l'innovation de la chaîne principale. Lorsqu'un incident malin se produit dans la chaîne latérale, les dommages sont totalement limités à la chaîne latérale elle-même et n'ont aucun impact sur la chaîne principale. La chaîne latérale peut utiliser un protocole de consensus TPS plus élevé pour augmenter les capacités de programmation sur la chaîne et améliorer le BTC.
La chaîne latérale peut réaliser le transfert de Bitcoin entre différentes blockchains via une fixation bidirectionnelle ou unidirectionnelle. Bien sûr, en fait, BTC ne peut rester que sur le réseau Bitcoin, nous avons donc besoin d'un mécanisme d'ancrage pour créer la chaîne latérale. Le BTC dans la chaîne est connecté au BTC dans le réseau Bitcoin.
L'ancrage unidirectionnel oblige les utilisateurs à envoyer du BTC sur le réseau principal à une adresse indisponible pour destruction, puis le nombre correspondant de BTC sera obtenu sur la chaîne latérale, mais le processus ne peut pas être inversé. L'ancrage bidirectionnel est une nouvelle mise à niveau de l'ancrage unidirectionnel, permettant au BTC de se déplacer entre la chaîne principale et les chaînes latérales. Au lieu de l'envoyer à une adresse indisponible pour destruction, l'ancrage bidirectionnel verrouillera BTC via des scripts de contrôle tels que la multi-signature et créera de nouveaux BTC sur la chaîne latérale. Lorsque l'utilisateur souhaite revenir au réseau principal, le BTC sur la chaîne latérale sera brûlé et le B TC initialement verrouillé sera libéré sur le réseau principal.
La mise en œuvre d'un ancrage unidirectionnel est beaucoup plus simple que celle d'un ancrage bidirectionnel, car il n'est pas nécessaire de gérer l'état concerné sur le réseau Bitcoin, mais les actifs de la chaîne latérale générés par l'ancrage unidirectionnel peuvent être sans valeur en raison de la absence de mécanisme d'ancrage inversé.
Il existe différentes solutions et différents niveaux de sécurité pour la vérification des transactions de verrouillage sur la chaîne principale et des transactions de destruction sur la chaîne latérale. Le plus simple consiste à utiliser une vérification externe par des participants multi-signatures, mais le risque de centralisation est élevé. Une meilleure option consiste à utiliser SPV Proof pour réaliser une vérification décentralisée. Bien entendu, étant donné que le réseau principal Bitcoin ne dispose pas des capacités de programmation nécessaires, la vérification SPV ne peut pas être effectuée et d'autres méthodes ne peuvent être choisies que, généralement une conservation multi-signatures.
Questions et idées
Il y a deux problèmes principaux pour lesquels les chaînes latérales sont critiquées :
La dépendance des actifs inter-chaînes vis-à-vis des vérificateurs : étant donné que le réseau principal Bitcoin n'est pas encore en mesure de mettre en œuvre des contrats intelligents, il est impossible de gérer le transfert d'actifs entre chaînes via une logique de contrat sans confiance lors du retour de la chaîne latérale vers Bitcoin. , il faut s'appuyer sur un groupe de vérificateurs. Pour mener à bien l'opération, il y a une hypothèse de confiance et il y a un risque de fraude.
La chaîne latérale ne peut pas hériter de la sécurité de la chaîne principale : la chaîne latérale fonctionne de manière totalement indépendante du réseau principal et ne peut pas hériter de la sécurité du réseau principal. Des événements tels qu'une réorganisation de bloc malveillante peuvent survenir.
À cet égard, les idées de chaînes latérales incluent le recours à l'autorité (type d'alliance), le recours à la sécurité économique (PoS), le recours aux mineurs décentralisés de Bitcoin (Merged Mining), le recours aux modules de sécurité matériels (HSM), la conservation des fonds et la chaîne latérale. sur Bitcoin Différents rôles peuvent être responsables de la production de blocs de la chaîne, introduisant ainsi des mécanismes de sécurité plus complexes.
Présentation du cas
Liquide
La première forme de chaîne latérale est la chaîne latérale d'alliance, dans laquelle plusieurs entités sélectionnées à l'avance servent de vérificateurs et sont responsables de la garde des principaux fonds du réseau et de la production de blocs de la chaîne latérale.
Liquid est le représentant de la chaîne latérale de l'alliance, avec 15 participants servant de vérificateurs. La méthode de gestion des clés privées n'est pas divulguée et 11 signatures sont requises pour la vérification. Les blocs de la chaîne latérale Liquid sont également gérés conjointement par 15 participants. La chaîne d'alliance avec un faible nombre de nœuds peut atteindre un TPS plus élevé et atteindre les objectifs d'expansion. Le principal champ d'application est DeFi.
L’approche de la chaîne latérale de l’alliance présente d’importants risques de sécurité centralisés.
Porte-greffe (RSK)
RSK dispose également de 15 nœuds servant de dépositaires de fonds sur le réseau principal, et seules 8 signatures sont nécessaires pour la vérification. La différence avec Liquid est que la clé multi-signature est gérée par le module de sécurité matériel HSM et que l'instruction de retrait est signée conformément au consensus PoW pour empêcher le vérificateur détenant la clé de manipuler directement les fonds bloqués.
En termes de consensus sur la chaîne latérale, RSK utilise Merged Mining pour utiliser la puissance de calcul du réseau principal afin d'assurer la sécurité des transactions sur la chaîne latérale. Lorsque la proportion de puissance de calcul minière fusionnée dans le réseau principal est élevée, elle peut mieux empêcher le côté. chaîne d'être compromise. Attaque de double fleur. RSK a apporté des améliorations à Merged Mining pour garantir la sécurité des chaînes latérales avec de faibles taux de hachage. Il adopte une méthode sensible au fork pour effectuer une intervention consensuelle hors chaîne sur le comportement du fork et réduire la probabilité de double dépense.
Cependant, Merged Mining modifie les incitations des mineurs et intensifie les risques de MEV, ce qui pourrait à terme déstabiliser le système. À long terme, Merged Mining pourrait accroître la centralisation du minage.
Piles
Stacks ancre l'historique de la chaîne Stacks au Bitcoin en soumettant le hachage de bloc de la chaîne latérale au bloc Bitcoin. Il a la même finalité que Bitcoin. Le fork de Stacks ne peut être provoqué que par le fork de Bitcoin. résister aux doubles dépenses.
sBTC introduit un nouveau jeton STX et un modèle d'incitation, utilisant une approche de pont de jalonnement qui autorise jusqu'à 150 validateurs du réseau principal. Dans ce que l'on appelle le pont de jalonnement, les validateurs doivent miser des jetons STX pour obtenir l'autorisation d'approuver les dépôts et les retraits. La sécurité du pont de gage dépend fortement de la valeur des actifs gagés. Lorsque la valeur des actifs gagés fluctue violemment, la sécurité inter-chaînes BTC est facilement endommagée. Si la valeur des actifs promis est inférieure à la valeur des actifs inter-chaînes, le validateur est incité à faire le mal.
Certaines propositions de sidechain sont également largement discutées au sein de la communauté.
Chaîne de transmission
Celle qui a le plus retenu l'attention est Drivechain proposée par Paul Sztorc en 2015. Les technologies clés du plan se sont vu attribuer le BIP 300 (mécanisme de fixation) et le BIP 301 (exploitation minière fusionnée à l'aveugle). BIP 300 définit en détail la logique de l'ajout d'une nouvelle chaîne latérale. L'activation d'une nouvelle chaîne latérale est similaire à l'activation d'un soft fork via les signaux des mineurs. Le BIP 301 permet aux mineurs de Bitcoin de devenir des producteurs de blocs sidechain sans vérifier le contenu spécifique de la transaction.
Les mineurs de Bitcoin sont également chargés d'approuver les transactions de retrait. Les mineurs doivent d'abord créer une sortie OP_RETURN dans la transaction coinbase du bloc qu'ils ont extrait pour proposer une transaction de retrait. Après cela, chaque mineur peut voter sur la proposition. peut voter pour ou contre la proposition à tout moment. Une fois qu'une transaction de retrait dépasse le seuil (13 150 blocs), la transaction de retrait est officiellement exécutée et confirmée par la chaîne principale Bitcoin.
En fait, les mineurs ont un contrôle total sur les fonds sur Drivechain. Si les fonds sont volés, les utilisateurs ne peuvent se sauver que via l'UASF (soft fork activé par l'utilisateur), mais il est très difficile de parvenir à un consensus. De plus, la position unique des mineurs dans Drivechain exacerbe les risques MEV, comme cela a déjà été démontré dans Ethereum.
Chaîne spatiale
Spacechain a adopté une approche différente, en utilisant le Perpetual 1 way peg (P1WP). Les utilisateurs brûlent du BTC pour obtenir des jetons sur Spacechain, ignorant directement le problème de la sécurité des fonds. Ce jeton ne peut être utilisé que pour mettre aux enchères de l'espace de bloc sur la chaîne spatiale et n'a aucune fonction de stockage de valeur.
Pour garantir la sécurité de la chaîne latérale, Spacechain adopte l'exploitation minière par fusion aveugle. D'autres utilisateurs utilisent ANYPREVOUT (APO) pour soumissionner publiquement pour le droit de construire des blocs. Les mineurs de Bitcoin n'ont qu'à valider l'en-tête du bloc Spacechain dans le bloc sans le vérifier. bloc de chaîne latérale. Cependant, le lancement de Spacechain nécessite le soutien de Covanent, et la communauté Bitcoin discute toujours de la nécessité d'un soft fork pour ajouter l'opcode Covanent.
En général, Spacechain peut réaliser une chaîne latérale avec les mêmes propriétés de décentralisation et de résistance à la censure que Bitcoin et plus de programmabilité grâce à la fonction d'enchères pour des blocs sur Bitcoin.
Chaîne logicielle
Softchain est une proposition de chaîne latérale 2wp proposée par l'auteur de Spacechain Ruben Somsen. Elle utilise le mécanisme de consensus PoW FP pour assurer la sécurité de la chaîne latérale. Dans des circonstances normales, le nœud complet de Bitcoin n'a besoin que de télécharger l'en-tête de bloc de la softchain et de vérifier la preuve de travail. Lorsqu'un fork se produit, téléchargez le bloc orphelin et l'engagement défini UTXO correspondant pour vérifier la validité du bloc.
Pour le mécanisme 2wp, lors du peg-in, une transaction de dépôt est créée sur la chaîne principale, et la transaction de la chaîne principale est référencée sur la softchain pour obtenir des fonds lors du peg-out, une transaction de retrait est créée sur la softchain, et la transaction est créée. la transaction est référencée sur la chaîne principale pour récupérer les fonds BTC, et le processus de retrait doit attendre une longue période de contestation avant de pouvoir être terminé. Les mécanismes spécifiques de peg-in et peg-out nécessitent un support soft fork, c'est pourquoi la solution s'appelle Softchain.
La solution Softchain impose des coûts de vérification supplémentaires sur tous les nœuds du réseau principal Bitcoin. La répartition du consensus de Softchain peut affecter la réalisation du consensus du réseau principal et devenir un moyen possible d'attaque sur le réseau principal Bitcoin.
Réseau Lightning
Le Lightning Network a publié un livre blanc en 2015 et a été officiellement lancé en 2018. En tant que protocole de paiement p2p de couche 2 sur Bitcoin, il vise à transférer un grand nombre de transactions de faible montant et à haute fréquence vers un traitement hors chaîne. Pendant longtemps, elle a été considérée comme la technologie la plus avancée du réseau Bitcoin. Un plan d’expansion prometteur.
module de base
La mise en œuvre de Lightning Network est indissociable de plusieurs modules importants de Bitcoin, qui assurent ensemble la sécurité des transactions Lightning Network.
La première est la transaction pré-signée. Les transactions pré-signées ne sont devenues sécurisées et disponibles qu'après la mise à niveau de SegWit. SegWit sépare les signatures du reste des données de transaction, résolvant ainsi des problèmes tels que les dépendances circulaires potentielles, la falsification de transactions par des tiers et la falsification de transactions par des tiers. La sécurité informatique sous la chaîne Lightning Network est garantie par l'engagement irrévocable donné par l'autre partie, et cet engagement se concrétise au travers de transactions pré-signées. Après avoir reçu la transaction pré-signée donnée par l'autre partie, l'utilisateur peut diffuser la transaction à la chaîne à tout moment pour achever la réalisation de la promesse.
La deuxième est la multi-signature. Les transferts fréquents de fonds hors chaîne entre deux parties nécessitent un transporteur. Ce transporteur exige que les deux parties conservent certains droits de contrôle, des signatures multiples sont donc généralement utilisées, ce qui garantit le transfert de fonds. doit être effectuée avec le consentement mutuel des deux parties.
Cependant, la multi-signature 2/2 entraînera des problèmes de vivacité, c'est-à-dire que si l'autre partie ne coopère pas, l'utilisateur ne pourra transférer aucun actif depuis l'adresse multi-signature, ce qui entraînera la perte des fonds d'origine. Les verrouillages temporels peuvent résoudre le problème de vivacité. En signant à l'avance un contrat avec un verrouillage temporel pour restituer les fonds, cela peut garantir que même si une partie devient inactive, l'autre partie peut récupérer les fonds initiaux.
Enfin, il existe le hash lock, qui permet de connecter plusieurs canaux d'état et de construire un réseau. L'image originale du hachage sera utilisée comme support de communication pour coordonner le bon fonctionnement de plusieurs entités.
Exécuter le processus
canal bidirectionnel
Les deux parties utilisant le réseau Lightning pour effectuer des transactions doivent d'abord ouvrir un canal de paiement bidirectionnel sur Bitcoin. Les deux parties peuvent effectuer n'importe quel nombre de transactions hors chaîne. Une fois toutes les transactions terminées, le dernier statut sera soumis à la chaîne Bitcoin. pour finaliser le règlement et fermer l'allée des paiements.
Plus précisément, la mise en œuvre de canaux de paiement implique les étapes clés suivantes :
Créez une adresse multi-signature. Les deux parties du canal doivent d'abord créer une adresse multi-signature 2 sur 2 comme adresse de verrouillage des fonds du canal. Chaque partie détient une clé privée de signature et fournit sa propre clé publique.
Initialisez le canal. Les deux parties diffusent une transaction sur la chaîne et verrouillent une certaine quantité de Bitcoin dans l'adresse multi-signature comme fonds initiaux de la chaîne. Cette transaction est appelée transaction « ancre » du canal.
Mettre à jour l'état de la chaîne. Lors d'un paiement au sein du canal, les deux parties mettent à jour le statut du canal en échangeant des transactions pré-signées. Chaque mise à jour générera une nouvelle « transaction d'engagement », représentant l'état actuel de l'allocation des fonds. L'opération d'engagement comporte deux sorties, correspondant aux parts de fonds des deux parties.
Diffusez le dernier statut. Chacune des parties à la chaîne peut diffuser à tout moment la dernière transaction d'engagement sur la blockchain pour retirer sa part des fonds. Afin d'empêcher l'autre partie de diffuser l'ancien statut, chaque transaction d'engagement est associée à une « transaction de punition ». Si l'autre partie triche, vous pouvez obtenir tous les fonds de l'autre partie.
Fermez la chaîne. Lorsque deux parties décident de fermer un canal, elles peuvent coopérer pour générer une « transaction de règlement » qui diffuse le statut final de distribution des fonds à la blockchain. De cette manière, les fonds bloqués dans l’adresse multi-signature sont restitués aux adresses personnelles des deux parties.
Arbitrage en chaîne. Si les deux parties ne parviennent pas à un accord lors de la fermeture de la chaîne, chaque partie peut diffuser unilatéralement la dernière transaction d'engagement et lancer le processus d'arbitrage en chaîne. S'il n'y a pas d'objection dans un certain délai (par exemple 1 jour), les fonds seront envoyés aux deux parties en fonction de la répartition de la transaction engagée.
réseau de paiement
Les canaux de paiement peuvent être connectés les uns aux autres pour former un réseau prenant en charge le routage multi-sauts, mis en œuvre via HTLC. HTLC utilise le verrouillage par hachage comme condition directe et le paiement par signature avec verrouillage temporel comme condition de sauvegarde. Les utilisateurs peuvent interagir autour de l'image originale hachée avant l'expiration du verrouillage temporel.
Lorsqu'il n'y a pas de canal direct entre deux utilisateurs, le paiement peut être effectué à l'aide du HTLC entre routeurs. La préimage de hachage R joue un rôle clé dans l’ensemble du processus, garantissant l’atomicité du paiement. Dans le même temps, le verrouillage temporel de HTLC est amené à diminuer au fur et à mesure, garantissant que chaque saut dispose de suffisamment de temps pour traiter et transférer le paiement.
Problèmes
Essentiellement, le Lightning Network contourne l'hypothèse de confiance externe du pontage des actifs via les canaux d'état p2p, tout en utilisant des scripts de verrouillage temporel pour fournir la garantie ultime des actifs et assurer une protection contre les pannes. Lorsque l'autre partie perd son activité et ne coopère pas, un retrait unilatéral peut être réalisé. Par conséquent, le réseau Lightning présente une grande valeur dans les scénarios de paiement, mais il présente également de nombreuses limites, notamment :
Limite de capacité du canal. La capacité du canal de paiement dans Lightning Network est limitée par les fonds bloqués initiaux et ne peut pas prendre en charge des paiements importants dépassant la capacité du canal. Cela peut limiter certains scénarios d'application, tels que le commerce des matières premières.
En ligne et synchronisé. Afin de recevoir et de transférer les paiements en temps opportun, les nœuds Lightning Network doivent rester en ligne. Si un nœud est hors ligne pendant une longue période, il peut manquer certaines mises à jour de l'état du canal, ce qui entraînera une désynchronisation de l'état. Cela peut constituer un défi pour les utilisateurs individuels et les appareils mobiles, et augmente également le coût des opérations des nœuds.
Gestion des liquidités. L'efficacité du routage du Lightning Network repose sur la distribution de liquidité des canaux. Si les fonds sont inégalement répartis, certains modes de paiement peuvent échouer, affectant l'expérience utilisateur. La gestion de l'équilibre de liquidité du canal nécessite certains coûts techniques et financiers.
Violation de la vie privée. Afin de trouver les chemins de paiement disponibles, l’algorithme de routage du Lightning Network nécessite un certain niveau de connaissance de la capacité du canal et des informations de connectivité. Cela peut révéler la confidentialité de certains utilisateurs, comme la distribution des fonds, les contreparties, etc. L'ouverture et la fermeture des canaux de paiement peuvent également révéler des informations sur les participants concernés.
RVB
L'idée originale du protocole RGB a été inspirée par les concepts de vérification côté client et de scellement unique proposés par Peter Todd. Il a été proposé par Giacomo Zucco en 2016. Il s'agit d'un protocole Bitcoin de deuxième couche évolutif et préservant la confidentialité. .
idée principale
Validation client
Le processus de vérification de la blockchain consiste à diffuser à tous les blocs composés de transactions, permettant à chaque nœud de calculer les transactions dans le bloc et de terminer la vérification. Cela crée en fait un bien public, c'est-à-dire que les nœuds du réseau aident chaque individu qui soumet une transaction à effectuer une vérification complète, et les utilisateurs fournissent du BTC comme frais de traitement pour les inciter à aider à la vérification. La vérification côté client est plus centrée sur l'individu. La vérification de l'état n'est pas effectuée globalement, mais est vérifiée par les individus participant à des transitions d'état spécifiques. Seules les parties qui génèrent la transaction vérifient la validité de la transition d'état. Cela améliore considérablement la confidentialité et réduit également. la charge sur les nœuds et améliore l’évolutivité.
Joint jetable
Il existe un danger caché dans la transition d'état point à point. Si les utilisateurs ne peuvent pas collecter l'historique complet des transitions d'état, ils peuvent être fraudés et dépenser deux fois. Un scellement jetable est proposé pour résoudre ce problème. Il utilise un objet spécial qui ne peut être utilisé qu'une seule fois pour garantir qu'il n'y aura pas de double dépense et améliorer la sécurité. L'UTXO de Bitcoin est l'objet scellé unique le plus approprié, garanti par le mécanisme de consensus de Bitcoin et la puissance de calcul de l'ensemble du réseau, afin que les actifs RVB puissent hériter de la sécurité de Bitcoin.
Promesse cryptographique
Le sceau unique doit être combiné à l'engagement de chiffrement pour garantir que l'utilisateur connaît la transition d'état et éviter l'apparition d'attaques à double dépense. Le soi-disant engagement consiste à informer les autres que quelque chose s'est produit et ne peut pas être modifié ultérieurement, mais il n'est pas nécessaire d'exposer des événements spécifiques jusqu'au moment où une vérification est requise. Nous pouvons utiliser une fonction de hachage pour prendre un engagement. En RGB, le contenu de l'engagement est la transition d'état Grâce à la dépense d'UTXO, le destinataire de l'actif RGB recevra le signal de transition d'état, puis vérifiera l'engagement par rapport aux données spécifiques transmises hors chaîne par le dépensier. l'actif.
processus de travail
RGB utilise le consensus de Bitcoin pour garantir la sécurité des doubles dépenses et la résistance à la censure, et toutes les vérifications des transferts d'État sont transférées hors chaîne et ne sont vérifiées que par le client qui accepte le paiement.
Pour l'émetteur des actifs RGB, un contrat RGB doit être créé en lançant une transaction, et l'engagement des informations spécifiques sera stocké dans le script OP_RETURN d'une certaine condition de dépense dans la transaction Taproot.
Lorsque le détenteur d'un actif RVB souhaite dépenser, il doit obtenir les informations pertinentes du destinataire de l'actif, créer une transaction RVB, valider les détails de la transaction RVB et placer la valeur d'engagement dans l'UTXO spécifié par le destinataire de l'actif. , et émettez une transaction qui dépense l'UTXO d'origine et crée l'UTXO spécifié par le destinataire. Lorsque le destinataire de l'actif constate que l'UTXO qui stockait initialement l'actif RGB est dépensé, il peut vérifier la validité de la transaction RGB grâce à l'engagement dans la transaction Bitcoin. Une fois la vérification valide, il estime avoir bien reçu l'actif. Actif RVB.
Pour le destinataire des actifs RGB, le payeur doit fournir l'état initial et les règles de transition d'état du contrat, les transactions Bitcoin utilisées pour chaque transfert, les transactions RGB engagées par chaque échange Bitcoin et la validité de chaque transaction Bitcoin. vérifié par le client du destinataire sur la base de ces données, vérifie la validité de la transaction RGB. Parmi eux, l'UTXO de Bitcoin est utilisé comme conteneur pour sauvegarder l'état du contrat RVB. L'historique des transferts de chaque contrat RVB peut être exprimé sous forme de graphique acyclique dirigé. Le destinataire de l'actif RVB ne peut obtenir que les informations relatives au RVB. actif qu’il détient et ne peut pas accéder aux autres succursales.
Avantages et inconvénients
Vérification légère
Par rapport à la vérification complète de la blockchain, le protocole RGB réduit considérablement le coût de la vérification. Les utilisateurs n'ont pas besoin de parcourir tous les blocs historiques pour obtenir le dernier statut, mais doivent uniquement synchroniser les enregistrements historiques liés aux actifs qu'ils reçoivent pour vérifier. l’efficacité de la transaction.
Cette vérification légère facilite les transactions peer-to-peer, éliminant ainsi le besoin de fournisseurs de services centralisés et augmentant le niveau de décentralisation.
Évolutivité
Le protocole RGB n'hérite de la sécurité du Bitcoin que grâce à l'engagement d'un hachage. Grâce aux scripts Taproot, il n'y a presque aucune consommation d'espace supplémentaire sur la chaîne Bitcoin, ce qui rend possible une programmabilité complexe des actifs. En raison de l'utilisation d'UTXO comme conteneur, le protocole RVB a une concurrence naturelle. Les actifs RVB sur différentes branches de transfert ne se bloqueront pas et pourront être dépensés en même temps.
Confidentialité
Contrairement aux protocoles généraux, seul le destinataire des actifs RGB peut obtenir le statut de transfert historique des actifs RGB. Une fois la dépense terminée, le statut de transfert futur ne peut pas être obtenu, ce qui garantit considérablement la confidentialité des utilisateurs. Il n’y a aucune corrélation entre la transaction d’actifs RGB et le transfert de Bitcoin UTXO, et d’autres ne peuvent pas obtenir de traces de transactions RGB sur la chaîne Bitcoin.
En outre, RGB prend également en charge les dépenses aveugles, et le payeur ne peut pas savoir dans quel UTXO les actifs RGB seront payés, ce qui améliore encore la confidentialité et renforce la résistance à la censure.
insuffisant
Lorsque les actifs RVB changent de mains plusieurs fois, les nouveaux utilisateurs qui reçoivent des actifs seront obligés de vérifier un long historique de transfert, ce qui entraînera une charge de vérification plus lourde, le temps de vérification peut être plus long et la possibilité de confirmer rapidement est perdue. Pour les nœuds qui restent en cours d'exécution dans la blockchain, puisque le dernier statut est toujours synchronisé, le temps nécessaire pour recevoir le transfert rapide du statut de vérification de la nouvelle zone est limité à chaque fois.
La communauté discute de la possibilité de réutiliser les calculs historiques, et la preuve récursive ZK a la possibilité de réaliser une vérification constante de l'état de temps et de taille.
Cumul
Aperçu
Rollup est la meilleure solution d'expansion à laquelle l'écosystème Ethereum est parvenu après des années d'exploration, des chaînes d'État à Plasma et enfin à Rollup.
Rollup est une blockchain indépendante qui collecte les transactions en dehors de la chaîne Bitcoin, regroupe plusieurs transactions dans un lot et l'exécute, et soumet les données et les engagements de statut de ce lot à la chaîne principale, réalisant le traitement des transactions hors chaîne et les mises à jour de statut. Afin d'obtenir une expansion maximale, Rollup utilise généralement un séquenceur centralisé à ce stade pour améliorer l'efficacité d'exécution sans perdre la sécurité, car la sécurité est garantie par la vérification des transitions d'état du Rollup sur la chaîne principale.
À mesure que la solution Rollup de l’écosystème Ethereum mûrit, l’écosystème Bitcoin a également commencé à expérimenter Rollup. Cependant, la différence la plus critique entre Bitcoin et Ethereum est le manque de capacités de programmation et l’incapacité d’effectuer les calculs nécessaires pour créer un Rollup sur la chaîne. Cela fait que les gens essaient actuellement uniquement de mettre en œuvre un Rollup souverain et un OP Rollup.
Classification
Selon les différentes méthodes de vérification du transfert d'état, le Rollup peut être divisé en deux grandes catégories, le Rollup optimiste et le Rollup de validité (ZK Rollup).
Optimistic Rollup adopte une méthode de vérification optimiste. Pendant la période de litige après la soumission de chaque lot de transactions, n'importe qui peut vérifier les données hors chaîne, soulever des objections aux lots de transactions problématiques, soumettre des preuves de fraude à la chaîne principale et perdre le séquenceur. S'il n'y a aucune preuve de fraude valable après la période de contestation, le lot de transactions est considéré comme valide et la mise à jour du statut est confirmée sur la chaîne principale.
Validity Rollup utilise Validity Proof pour terminer la vérification, et Sequencer utilise un algorithme de preuve sans connaissance pour générer une preuve de validité concise pour chaque lot de transactions, prouvant que le transfert d'état du lot est correct. Chaque mise à jour doit soumettre le lot de transactions à. la chaîne principale. Preuve de validité, la chaîne principale vérifie la preuve puis comprend et confirme la mise à jour du statut.
L’avantage d’Optimistic Rollup est qu’il est relativement simple à mettre en œuvre et nécessite moins de modifications de la chaîne principale. Mais la confirmation des transactions prend plus de temps (en fonction du délai d'opposition) et nécessite une plus grande disponibilité des données. Les transactions Validity Rollup sont confirmées rapidement, ne dépendent pas de périodes d'objection et les données de transaction peuvent rester privées, mais la génération et la vérification de preuves sans connaissance nécessitent une surcharge de calcul élevée.
Celestia a également proposé le concept d'un rollup souverain. Les données de transaction du rollup sont publiées sur une blockchain de couche DA dédiée, qui est responsable de la disponibilité des données, et le rollup souverain lui-même est responsable de l'exécution et du règlement.
Explorer et discuter
Le rollup sur Bitcoin en est encore à ses débuts. En raison des différences entre le modèle comptable et le langage de programmation d'Ethereum, il est difficile de copier directement l'expérience pratique d'Ethereum. La communauté Bitcoin explore activement des solutions innovantes.
Cumul de souveraineté
Le 5 mars 2023, Rollkit a été annoncé comme le premier framework prenant en charge les rollups souverains Bitcoin. Les constructeurs de rollups souverains peuvent publier des données de disponibilité sur Bitcoin via Rollkit.
Rollkit s'inspire des Ordinaux et publie des données via des transactions Taproot. Une transaction Taproot standard via le pool de mémoire public peut contenir jusqu'à 390 Ko de données, et une transaction Taproot non standard émise directement par un mineur peut contenir près de 4 Mo de données arbitraires.
Le travail réel de Rollkit est de fournir une interface permettant au Rollup souverain de lire et d'écrire des données sur Bitcoin, de fournir des services middleware aux clients et de transformer Bitcoin en une couche DA.
L’idée d’un rollup souverain a suscité beaucoup de scepticisme, de nombreux opposants affirmant qu’un rollup souverain sur Bitcoin n’est rien de plus que l’utilisation de Bitcoin comme tableau d’affichage et est totalement incapable d’hériter de la sécurité de Bitcoin. En fait, si vous soumettez uniquement les données de transaction à Bitcoin, vous ne pouvez qu'améliorer la vivacité, c'est-à-dire que tous les utilisateurs peuvent obtenir les données correspondantes pour vérification via Bitcoin, mais la sécurité ne peut être définie que par le Rollup souverain lui-même et ne peut pas être héritée. De plus, l’espace de bloc est limité sur Bitcoin, et soumettre des données de transaction complètes n’est peut-être pas une bonne décision.
Cumul OP et cumul de validité
Bien que de nombreux projets Bitcoin de deuxième couche s'appellent eux-mêmes ZK Rollup, qui est essentiellement plus proche d'un OP Rollup, mais implique la technologie Validity Proof dans le processus, les capacités de programmation de Bitcoin ne sont pas encore suffisantes pour prendre en charge la vérification directe de Validity Proof.
Actuellement, l'ensemble des opcodes de Bitcoin est très limité et ne peut même pas calculer directement la multiplication. La vérification de la preuve de validité nécessite l'expansion des opcodes et repose également fortement sur la mise en œuvre de contrats récursifs. Ceux qui sont actuellement discutés dans la communauté incluent OP_CAT, OP_CHECKSIG, OP_TXHASH etc. Bien sûr, si nous pouvions ajouter directement un OP_VERIFY_ZKP, nous n'aurions peut-être pas besoin d'autres modifications, mais c'est évidemment peu probable. De plus, les limitations sur la taille de la pile entravent également les efforts visant à vérifier la preuve de validité dans les scripts Bitcoin, et de nombreuses tentatives sont à l'étude.
Alors, comment fonctionne la preuve de validité ? La plupart des projets publient les données déclarées et la preuve de validité des lots de transactions sur Bitcoin sous forme d'inscriptions et utilisent BitVM pour une vérification optimiste. BitVM Bridge remplace ici la solution multi-signature traditionnelle. L'opérateur de pont formera une alliance de N personnes pour planifier les dépôts des utilisateurs. Avant que les utilisateurs n'effectuent un dépôt, l'alliance devra pré-signer l'UTXO à générer pour garantir que le dépôt ne peut être légalement collecté que par l'opérateur. Après avoir obtenu la pré-signature, BTC sera verrouillé sur une adresse Taproot multi-signature N/N.
Lorsqu'un utilisateur émet une demande de retrait, Rollup enverra la preuve de validité avec la racine de retrait à la chaîne Bitcoin. L'opérateur répondra d'abord aux besoins de retrait de l'utilisateur de sa propre poche, puis vérifiera la validité via le contrat BitVM. Si chaque Opérateur estime que le certificat est valide, l'Opérateur sera remboursé par signature multiple ; tant que quelqu'un pense qu'il y a fraude, un processus de contestation sera effectué et la mauvaise partie sera éliminée.
Ce processus est en fait le même que celui d'OP Rollup. L'hypothèse de confiance est 1/N. Tant qu'un vérificateur est honnête, le protocole est sûr.
Cependant, des difficultés peuvent survenir lors de la mise en œuvre technique de cette solution. Dans le projet OP Rollup d'Ethereum, Arbitrum est développé depuis de nombreuses années et la preuve de fraude actuelle est toujours soumise par des nœuds autorisés ; Optimism n'a annoncé que récemment qu'il prenait en charge la preuve de fraude, ce qui montre à quel point il est difficile à mettre en œuvre.
Quant à l'opération pré-signée dans le pont BitVM, avec le support de Bitcoin Covanent, elle peut être mise en œuvre plus efficacement, ce qui attend toujours le consensus de la communauté.
En termes d'attributs de sécurité, en soumettant le hachage du bloc Rollup à Bitcoin, la résistance à la réorganisation et aux doubles dépenses est obtenue, et l'utilisation du pont optimiste apporte une hypothèse de sécurité 1/N. Cependant, la résistance à la censure du pont peut toujours. attendre un développement ultérieur s'améliorer.
Conclusion : la couche 2 n'est pas une panacée
En examinant autant de solutions de couche 2, nous pouvons facilement constater que chaque solution est limitée dans les tâches qu'elle peut accomplir. Sous certaines hypothèses de confiance, les effets que la couche 2 peut produire dépendent largement de la couche 1, c'est-à-dire des capacités natives de Bitcoin.
Sans les mises à niveau de SegWit et les verrous temporels, le réseau Lightning ne peut pas être construit avec succès ; sans les mises à niveau de Taproot, les engagements RVB ne peuvent pas être soumis avec succès ; sans OP_CAT et autres Covanent, le cumul de validité sur Bitcoin ne peut pas être construit avec succès...
De nombreux Bitcoin Maxi pensent que Bitcoin ne devrait jamais être modifié et que de nouvelles fonctionnalités ne devraient pas être ajoutées. Tous les défauts devraient être résolus par la couche 2. Ceci est impossible. Nous avons besoin d’une couche 1 plus puissante pour créer une couche 2 plus sécurisée, efficace et évolutive.
Dans le prochain article, nous présenterons les tentatives visant à améliorer la programmabilité sur Bitcoin, alors restez à l’écoute.