Les problèmes du « triangle impossible » que sont la sécurité, la décentralisation et l’évolutivité sur le réseau principal Bitcoin sont devenus plus importants.
Écrit par :****@tmel0211
Traduction : Blockchain vernaculaire
Dans l’engouement autour des inscriptions FOMO, j’ai rencontré de « vrais » développeurs Bitcoin. Étonnamment, ils n’ont pas fait preuve d’un enthousiasme excessif ni parlé de perturber Ethereum avec Bitcoin Layer 2 comme on pourrait s’y attendre.
Au lieu de cela, il semble y avoir un consensus : l’écosystème Bitcoin a du potentiel, mais il sera différent du paradigme Lego de DeFi d’Ethereum. Voyons ensuite comment l’écosystème Bitcoin devrait être mis en œuvre sur la base d’un raisonnement technique.
En effet, cette nouvelle manière d’émettre des actifs, comme les inscriptions, a ramené de nombreuses personnes à l’ère des ICO en 2017 et ravivé l’enthousiasme. Cette vague d'abonnements a apporté de nouveaux utilisateurs, de nouveaux scénarios d'application et des fonds supplémentaires. Dans une certaine mesure, il est logique d’appeler cela une course haussière du Bitcoin.
Par la suite, diverses directions telles que les chaînes latérales, Lightning Network, Taproot Assets, RGB, BitVM, etc. ont été remplies de « prétendants » de la couche 2 orthodoxe de Bitcoin. Ils ont souvent affirmé haut et fort qu'ils copieraient tout ce qui concerne Ethereum dans l'écosystème Bitcoin, provoquant troubles.Une petite sensation.
Tout comme la nature non durable du boom de l’émission d’actifs ICO, alors que la vague de FOMO s’apaise, le marché des inscriptions est également impatient d’inaugurer une nouvelle tendance Bitcoin Layer 2.
Il n’y a rien de mal à avoir de telles ambitions. Cependant, si vous souhaitez reproduire le gameplay diversifié de l’écosystème Ethereum dans Bitcoin, cela n’est pas réalisable. L’écosystème Bitcoin doit explorer une voie d’atterrissage cohérente avec ses caractéristiques inhérentes.
La logique fondamentale est que les caractéristiques natives de la chaîne Bitcoin imposent des capacités de calcul et de vérification « limitées ». Même la capacité de stockage des adresses Taproot de SegWit a été contestée par des attaques de poussière.
Une puissance de calcul limitée signifie qu'une logique de transaction plus complexe doit être mise en œuvre hors chaîne. Par exemple, bitVM envisage un calcul complet de Turing basé sur des circuits hors chaîne et des portes logiques en chaîne (0, 1), et est implémenté sur la base du concept optimiste Rollup. Même si l’idée était ambitieuse et que la logique technique était logique, l’effort d’ingénierie requis n’était pas pratique.
Les capacités de vérification limitées rendent Bitcoin plus adapté au règlement d’actifs qu’à la vérification d’État mondiale. Les fonctionnalités de signature Schnorr et de structure de données MAST des nœuds Bitcoin offrent actuellement certaines capacités de vérification. Cependant, Schnorr ne regroupe que plusieurs signatures et se limite aux scénarios multi-signatures, tandis que MAST permet la création de scripts plus complexes, mais s'appuie sur le modèle UTXO uniquement pour le règlement des actifs et ne peut pas réaliser une vérification globale de l'état. La construction d'une matrice de nœuds légers complexe peut améliorer l'interactivité entre la chaîne latérale et la chaîne principale, ainsi que la sécurité et la vitesse de réponse du règlement des actifs.
La controverse sur le stockage est indéniable. Bitcoin a évolué sur une voie d’une extrême simplicité, un consensus atteint après la précédente guerre de taille de bloc. Par conséquent, l’idée d’apporter des modifications significatives à l’espace de script basé sur Taproot est certainement irréaliste. Bien qu'ils n'atteignent peut-être pas le niveau de castration de SegWit, les protocoles de mise à niveau comme Atomics, RUNE et PIPE ont tendance à faire des compromis et à utiliser des blocs plus petits, comme la suppression de gros paquets de données JSON et le retour à l'optimisation et à l'application OP\ _Return space.
Ces limitations déterminent que la solution de mise à l’échelle de couche 2 de Bitcoin est très différente de celle d’Ethereum :
Bitcoin ne dispose pas de capacités de disponibilité des données (DA). Le DA d'Ethereum représente les capacités de calcul et de vérification du validateur du réseau principal pour les soumissions de couche 2. De toute évidence, même si Bitcoin peut accepter une certaine quantité de données, le réseau principal ne dispose pas des capacités de calcul et de vérification nécessaires pour être réalisable et efficace.
Par conséquent, le DA de Bitcoin ressemble plus à un « tableau d'affichage » : les données originales sont stockées dans le bloc Bitcoin et ne peuvent être prises en compte et vérifiées que par l'indexeur hors chaîne. Cela testera sans aucun doute les capacités de comptabilité et de vérification de l'indexeur. Le défi augmente encore s'il existe plusieurs indexeurs, ce qui entraîne une logique comptable confuse et des problèmes d'erreur.
Bitcoin a une interopérabilité limitée. La couche 2 d'Ethereum soumet le statut au réseau principal. Le réseau principal a des contrats qui peuvent se coordonner avec la couche 2 pour mettre en œuvre des mécanismes tels que la fenêtre de temps de défi de 7 jours et les trappes d'évacuation de la couche 2 pour garantir que le réseau principal peut protéger les actifs d'Ethereum. 2 utilisateurs. Sur la base des actes répréhensibles de Sequener. Évidemment, sans la capacité des contrats intelligents, Bitcoin n’aurait pas ce niveau de sécurité. Les utilisateurs peuvent seulement être sûrs que Bitcoin Layer 2 ne se comportera pas de manière malveillante.
Le modèle de sécurité UTXO de Bitcoin est limité aux scénarios de « paiement ». Semblable à la solution Ethereum Plasma Layer 2, si le hachage occasionnel correspondant à chaque transaction est synchronisé avec le réseau principal sous la forme d'UTXO via la couche 2, un modèle de sécurité basé sur UTXO peut être établi. Cependant, tout comme Plasma est limité aux scénarios de paiement, Bitcoin Layer 2 basé sur le modèle UTXO présente également cette limitation. Tout mécanisme comportant des contrats intelligents complexes comme l’EVM ne peut pas s’appuyer uniquement sur ce mécanisme de sécurité à moins qu’un consensus supplémentaire ne soit ajouté en dehors de la chaîne Bitcoin.
Compte tenu de cette logique et de cette compréhension techniques, l’espace narratif de Bitcoin Layer 2 devient très clair :
Utilisez Bitcoin comme couche de règlement pour construire un consensus indépendant pour la couche 2 et fournir un ensemble complet de DA, d'interopérabilité, de machine virtuelle VM et d'autres fonctionnalités cohérentes avec l'écosystème Ethereum. Cependant, une chaîne aussi puissante recrée essentiellement la chaîne d’exécution d’Ethereum. Beaucoup de gens ne savent peut-être pas qu'Ethereum dispose en fait d'une chaîne de règlement Beacon, et la chaîne principale d'Ethereum 2.0 que nous voyons peut être considérée comme la deuxième couche de la chaîne Beacon.
La raison pour laquelle les gens ont une faible compréhension de la chaîne de règlement est que le cœur du réseau principal est la capacité de vérifier les interactions. Si une seule chaîne de règlement est construite, alors la chaîne qui gère un grand nombre de calculs et d'opérations de vérification deviendra la véritable « chaîne principale ».
Voici la question : si nous utilisons Bitcoin comme chaîne de règlement, d’autres chaînes osent-elles s’appeler la chaîne principale ? L’écosystème Bitcoin permet-il ce genre de « consensus » ?
Utilisez Bitcoin comme solution de paiement, y compris la vérification côté client du Lightning Network, des actifs Taproot et du RVB. Essentiellement, ces solutions s’appuient sur le modèle UTXO du réseau principal Bitcoin pour assurer la sécurité. Cela limite naturellement ces solutions aux scénarios de paiement.
Le Lightning Network offre une expérience fluide pour la circulation de petites quantités de Bitcoin. De même, les actifs Taproot et RGB conviennent également aux canaux de paiement stablecoin.
Si vous souhaitez superposer certains statuts DeFi et EVM sur le canal d'état et la vérification du client, cela équivaut à ajouter une logique de vérification plus complexe au modèle UTXO d'origine. Bien entendu, certains états qui ne peuvent pas être vérifiés par le réseau principal seront soumis au réseau principal, en s'appuyant essentiellement sur un consensus hors chaîne. Une telle solution peut être réalisable, mais le niveau de sécurité sera d’autant plus faible par rapport à un scénario de transaction contrôlé par un modèle UTXO pur.
En résumé, comment l’écosystème Bitcoin se concrétise-t-il ?
Si nous orientons les capacités de consensus de sécurité de Bitcoin vers des applications et des scénarios de consommation tels que les actifs Lightning Network et Taproot, alors la vérification du client RVB peut réaliser des scénarios d'application de contrats intelligents de deuxième couche plus complexes ;
Si Bitcoin permet un certain consensus hors chaîne en dehors du consensus principal, alors la vérification du client RVB pointe vers des scénarios d'application plus complexes, rendant possibles des contrats intelligents complexes de couche 2 ;
Si le réseau principal Bitcoin sert uniquement de chaîne de règlement et repose sur un consensus indépendant en dehors de la chaîne, alors diverses solutions telles que des chaînes latérales, des chaînes d'alliance et des chaînes d'index qui peuvent établir un consensus et mettre en œuvre strictement un règlement transparent des actifs semblent réalisables.
Si une solution révolutionnaire de calcul et de vérification Bitcoin Turing comme BitVM est mise en œuvre et est moins rentable que la construction de contrats intelligents d'Ethereum, alors la conclusion ci-dessus pourrait être annulée.
Dans tous les cas, les problèmes du « triangle impossible » que sont la sécurité, la décentralisation et l’évolutivité sur le réseau principal Bitcoin sont devenus plus importants. La soi-disant couche 2 orthodoxe de Bitcoin n’est peut-être qu’une proposition superficielle. À mon avis, choisir le consensus orthodoxe signifie accepter les « limites » de l’expansion. Si vous espérez dépasser ces limites, ne brandissez pas haut l’étendard du consensus imbattable.
Voir l'original
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
Explorez le chemin vers la mise en œuvre de l'écosystème Bitcoin Layer 2
Écrit par :****@tmel0211
Traduction : Blockchain vernaculaire
Dans l’engouement autour des inscriptions FOMO, j’ai rencontré de « vrais » développeurs Bitcoin. Étonnamment, ils n’ont pas fait preuve d’un enthousiasme excessif ni parlé de perturber Ethereum avec Bitcoin Layer 2 comme on pourrait s’y attendre.
Au lieu de cela, il semble y avoir un consensus : l’écosystème Bitcoin a du potentiel, mais il sera différent du paradigme Lego de DeFi d’Ethereum. Voyons ensuite comment l’écosystème Bitcoin devrait être mis en œuvre sur la base d’un raisonnement technique.
En effet, cette nouvelle manière d’émettre des actifs, comme les inscriptions, a ramené de nombreuses personnes à l’ère des ICO en 2017 et ravivé l’enthousiasme. Cette vague d'abonnements a apporté de nouveaux utilisateurs, de nouveaux scénarios d'application et des fonds supplémentaires. Dans une certaine mesure, il est logique d’appeler cela une course haussière du Bitcoin.
Par la suite, diverses directions telles que les chaînes latérales, Lightning Network, Taproot Assets, RGB, BitVM, etc. ont été remplies de « prétendants » de la couche 2 orthodoxe de Bitcoin. Ils ont souvent affirmé haut et fort qu'ils copieraient tout ce qui concerne Ethereum dans l'écosystème Bitcoin, provoquant troubles.Une petite sensation.
Tout comme la nature non durable du boom de l’émission d’actifs ICO, alors que la vague de FOMO s’apaise, le marché des inscriptions est également impatient d’inaugurer une nouvelle tendance Bitcoin Layer 2.
Il n’y a rien de mal à avoir de telles ambitions. Cependant, si vous souhaitez reproduire le gameplay diversifié de l’écosystème Ethereum dans Bitcoin, cela n’est pas réalisable. L’écosystème Bitcoin doit explorer une voie d’atterrissage cohérente avec ses caractéristiques inhérentes.
La logique fondamentale est que les caractéristiques natives de la chaîne Bitcoin imposent des capacités de calcul et de vérification « limitées ». Même la capacité de stockage des adresses Taproot de SegWit a été contestée par des attaques de poussière.
Une puissance de calcul limitée signifie qu'une logique de transaction plus complexe doit être mise en œuvre hors chaîne. Par exemple, bitVM envisage un calcul complet de Turing basé sur des circuits hors chaîne et des portes logiques en chaîne (0, 1), et est implémenté sur la base du concept optimiste Rollup. Même si l’idée était ambitieuse et que la logique technique était logique, l’effort d’ingénierie requis n’était pas pratique.
Les capacités de vérification limitées rendent Bitcoin plus adapté au règlement d’actifs qu’à la vérification d’État mondiale. Les fonctionnalités de signature Schnorr et de structure de données MAST des nœuds Bitcoin offrent actuellement certaines capacités de vérification. Cependant, Schnorr ne regroupe que plusieurs signatures et se limite aux scénarios multi-signatures, tandis que MAST permet la création de scripts plus complexes, mais s'appuie sur le modèle UTXO uniquement pour le règlement des actifs et ne peut pas réaliser une vérification globale de l'état. La construction d'une matrice de nœuds légers complexe peut améliorer l'interactivité entre la chaîne latérale et la chaîne principale, ainsi que la sécurité et la vitesse de réponse du règlement des actifs.
La controverse sur le stockage est indéniable. Bitcoin a évolué sur une voie d’une extrême simplicité, un consensus atteint après la précédente guerre de taille de bloc. Par conséquent, l’idée d’apporter des modifications significatives à l’espace de script basé sur Taproot est certainement irréaliste. Bien qu'ils n'atteignent peut-être pas le niveau de castration de SegWit, les protocoles de mise à niveau comme Atomics, RUNE et PIPE ont tendance à faire des compromis et à utiliser des blocs plus petits, comme la suppression de gros paquets de données JSON et le retour à l'optimisation et à l'application OP\ _Return space.
Ces limitations déterminent que la solution de mise à l’échelle de couche 2 de Bitcoin est très différente de celle d’Ethereum :
Par conséquent, le DA de Bitcoin ressemble plus à un « tableau d'affichage » : les données originales sont stockées dans le bloc Bitcoin et ne peuvent être prises en compte et vérifiées que par l'indexeur hors chaîne. Cela testera sans aucun doute les capacités de comptabilité et de vérification de l'indexeur. Le défi augmente encore s'il existe plusieurs indexeurs, ce qui entraîne une logique comptable confuse et des problèmes d'erreur.
Bitcoin a une interopérabilité limitée. La couche 2 d'Ethereum soumet le statut au réseau principal. Le réseau principal a des contrats qui peuvent se coordonner avec la couche 2 pour mettre en œuvre des mécanismes tels que la fenêtre de temps de défi de 7 jours et les trappes d'évacuation de la couche 2 pour garantir que le réseau principal peut protéger les actifs d'Ethereum. 2 utilisateurs. Sur la base des actes répréhensibles de Sequener. Évidemment, sans la capacité des contrats intelligents, Bitcoin n’aurait pas ce niveau de sécurité. Les utilisateurs peuvent seulement être sûrs que Bitcoin Layer 2 ne se comportera pas de manière malveillante.
Le modèle de sécurité UTXO de Bitcoin est limité aux scénarios de « paiement ». Semblable à la solution Ethereum Plasma Layer 2, si le hachage occasionnel correspondant à chaque transaction est synchronisé avec le réseau principal sous la forme d'UTXO via la couche 2, un modèle de sécurité basé sur UTXO peut être établi. Cependant, tout comme Plasma est limité aux scénarios de paiement, Bitcoin Layer 2 basé sur le modèle UTXO présente également cette limitation. Tout mécanisme comportant des contrats intelligents complexes comme l’EVM ne peut pas s’appuyer uniquement sur ce mécanisme de sécurité à moins qu’un consensus supplémentaire ne soit ajouté en dehors de la chaîne Bitcoin.
Compte tenu de cette logique et de cette compréhension techniques, l’espace narratif de Bitcoin Layer 2 devient très clair :
La raison pour laquelle les gens ont une faible compréhension de la chaîne de règlement est que le cœur du réseau principal est la capacité de vérifier les interactions. Si une seule chaîne de règlement est construite, alors la chaîne qui gère un grand nombre de calculs et d'opérations de vérification deviendra la véritable « chaîne principale ».
Voici la question : si nous utilisons Bitcoin comme chaîne de règlement, d’autres chaînes osent-elles s’appeler la chaîne principale ? L’écosystème Bitcoin permet-il ce genre de « consensus » ?
Le Lightning Network offre une expérience fluide pour la circulation de petites quantités de Bitcoin. De même, les actifs Taproot et RGB conviennent également aux canaux de paiement stablecoin.
Si vous souhaitez superposer certains statuts DeFi et EVM sur le canal d'état et la vérification du client, cela équivaut à ajouter une logique de vérification plus complexe au modèle UTXO d'origine. Bien entendu, certains états qui ne peuvent pas être vérifiés par le réseau principal seront soumis au réseau principal, en s'appuyant essentiellement sur un consensus hors chaîne. Une telle solution peut être réalisable, mais le niveau de sécurité sera d’autant plus faible par rapport à un scénario de transaction contrôlé par un modèle UTXO pur.
En résumé, comment l’écosystème Bitcoin se concrétise-t-il ?
Si nous orientons les capacités de consensus de sécurité de Bitcoin vers des applications et des scénarios de consommation tels que les actifs Lightning Network et Taproot, alors la vérification du client RVB peut réaliser des scénarios d'application de contrats intelligents de deuxième couche plus complexes ;
Si Bitcoin permet un certain consensus hors chaîne en dehors du consensus principal, alors la vérification du client RVB pointe vers des scénarios d'application plus complexes, rendant possibles des contrats intelligents complexes de couche 2 ;
Si le réseau principal Bitcoin sert uniquement de chaîne de règlement et repose sur un consensus indépendant en dehors de la chaîne, alors diverses solutions telles que des chaînes latérales, des chaînes d'alliance et des chaînes d'index qui peuvent établir un consensus et mettre en œuvre strictement un règlement transparent des actifs semblent réalisables.
Si une solution révolutionnaire de calcul et de vérification Bitcoin Turing comme BitVM est mise en œuvre et est moins rentable que la construction de contrats intelligents d'Ethereum, alors la conclusion ci-dessus pourrait être annulée.
Dans tous les cas, les problèmes du « triangle impossible » que sont la sécurité, la décentralisation et l’évolutivité sur le réseau principal Bitcoin sont devenus plus importants. La soi-disant couche 2 orthodoxe de Bitcoin n’est peut-être qu’une proposition superficielle. À mon avis, choisir le consensus orthodoxe signifie accepter les « limites » de l’expansion. Si vous espérez dépasser ces limites, ne brandissez pas haut l’étendard du consensus imbattable.