Principales explorations et conflits de la technologie originale de Bitcoin

La technologie originale de Bitcoin a toujours été confrontée à des conflits entre sa capacité d'adoption de masse et la fonctionnalité qu'elle devrait posséder. Le passage à l'échelle et le volume des transactions impliquent-ils des commandes de transaction plus complexes et un espace de transaction plus grand ? Cela signifie-t-il que toutes les fonctions doivent être mises en œuvre sur un seul système Bitcoin ? Aux premiers jours, lorsque le développement de la technologie de l'écosystème Bitcoin était incomplet, ces problèmes semblaient inhérents à Bitcoin lui-même. Cependant, avec l'avancée de la technologie, bon nombre de ces problèmes sont devenus plus clairs.

Cet article répertorie certaines des questions connexes, ainsi que les processus par lesquels elles ont émergé et ont été traitées. Grâce à cet article, on peut voir le lien entre ces questions et la technologie, ainsi que les changements sur la chaîne principale de Bitcoin et les « chaînes de test » connexes. La technologie de Bitcoin a été continuellement explorée par divers projets et équipes (y compris Ethereum, qui explore les imperfections de Bitcoin). Cependant, les changements sur le mainnet de Bitcoin n'étaient pas très apparents avant l'avènement de technologies comme Taproot, qui a stimulé le développement de protocoles tels que Ordinals, entraînant une nouvelle vague de développement.

D'un point de vue plus large, en examinant ces développements et les technologies qu'ils ont produits, nous pouvons voir leurs connexions et en déduire plus de directions pour le développement et l'architecture globale.

1.1 Langage de script Bitcoin et plusieurs réductions d'instructions

Le langage de programmation de Bitcoin est un langage de script basé sur la pile utilisant la notation polonaise inversée, sans boucles ni instructions de contrôle conditionnel (les extensions ultérieures telles que Taproot & Taproot Script ont amélioré cette capacité). Par conséquent, on dit souvent que le langage de script de Bitcoin n'est pas complet, limitant ses capacités.

En raison de ces limitations, les pirates informatiques ne peuvent pas utiliser ce langage de script pour écrire des boucles infinies (ce qui paralyserait le réseau) ou du code pouvant entraîner des attaques DOS, protégeant ainsi le réseau Bitcoin contre les attaques DOS. Les développeurs de Bitcoin estiment également que la blockchain de base ne doit pas avoir de complétude de Turing pour éviter certaines attaques et la congestion du réseau.

Cependant, ces limitations signifient que le réseau Bitcoin ne peut pas exécuter d'autres programmes complexes ou effectuer certaines fonctions "utiles". Les systèmes de blockchain ultérieurs développés pour résoudre des problèmes spécifiques et répondre aux besoins des utilisateurs ont changé cet aspect. Par exemple, le langage utilisé par Ethereum est complet

Les types courants d'instructions de script Bitcoin incluent:

Mots-clés :

1. Constantes. par exemple, OP_0, OP_FALSE

2. Contrôle du flux. par exemple, OP_IF, OP_NOTIF, OP_ELSE, etc.

3. Opérations de pile. par exemple, OP_TOALTSTACK (pousse l'entrée sur la pile auxiliaire, la supprimant de la pile principale), etc.

4. Opérations sur les chaînes. par exemple, OP_CAT (concatène deux chaînes, désactivé), OP_SIZE (pousse la longueur de la chaîne de l'élément de pile supérieur sur la pile sans dépiler l'élément)

5. Logique bit à bit. par exemple, OP_AND, OP_OR, OP_XOR

6. Logique arithmétique. par exemple, OP_1ADD (ajoute 1 à l'entrée), OP_1SUB (soustrait 1 de l'entrée)

7. Cryptographie. par exemple, OP_SHA1 (hache l'entrée avec l'algorithme SHA-1), OP_CHECKSIG

8. Mots-clés pseudo

9. Mots clés réservés

Types courants de script Bitcoin :

1. Transaction standard payante à une adresse Bitcoin (payer à une empreinte de clé publique)

2. Transaction standard de frappe de Bitcoin (paiement à la clé publique)

3. Sorties non dépensables / compressibles vérifiables

4. Les sorties Anyone-Can-Spend

5. Transaction de puzzle

Les cinq types standard de scripts de transaction comprennent : paiements à hachage de clé publique (P2PKH), paiements à clé publique, multisig (limité à 15 clés max), paiements à hachage de script (P2SH), et sorties de données (OP_RETURN).

Pour plus d'informations détaillées sur le script Bitcoin, vous pouvez visiter: Bitcoin Wiki - Script.

Réduction des instructions prises en charge dans Bitcoin

Historiquement, Bitcoin a subi plusieurs réductions dans les instructions prises en charge. Dans le graphique suivant, les parties rouges sont les instructions qui ont été supprimées.

• Opérations de chaîne

（2）

(3) Opérations arithmétiques

Pourquoi réduire les instructions? La sécurité n'est qu'un aspect à considérer. Si nous considérons la réduction des instructions à travers le prisme de la conception en couches, nous pouvons comprendre sa rationalité, permettant au protocole de base d'être plus fondamental et stable. Peut-être que Satoshi Nakamoto était conscient de ce problème dès le début, c'est pourquoi il a activement réduit les instructions. La pensée ordinaire consiste à construire un petit système qui satisfait directement les besoins des utilisateurs avec des commandes complètes et des fonctionnalités système, plutôt qu'un grand protocole qui nécessite une collaboration.

Cela conduit également à un fait : seul Bitcoin convient en tant que réseau de premier niveau. J'ai analysé ce phénomène dans l'article « Les prix élevés du Bitcoin peuvent favoriser l'émergence d'une nouvelle chaîne alternative », en considérant à la fois des perspectives économiques et techniques, ainsi que la possibilité de l'émergence d'une chaîne alternative à Bitcoin. Cependant, compte tenu des caractéristiques fondamentales de Bitcoin et de la perspective de la conception en couches, presque seul Bitcoin peut servir d'infrastructure de réseau de premier niveau ; même s'il existe des chaînes alternatives, elles seraient un produit de 1,5 couche. Au niveau de la première couche, le produit authentique n'est que Bitcoin, et au mieux, d'autres chaînes peuvent servir de biens alternatifs de moindre qualité.

1.2. Histoire des Forks Bitcoin, Raisons et Signification

Dans l'histoire du développement de Bitcoin, en dehors de la question de la réduction des instructions, un autre aspect est le débat sur la taille des blocs, qui conduit souvent à des bifurcations difficiles de Bitcoin.

Lors de la création du BTC, il n'y avait pas de limite de taille de bloc pour permettre à un certain nombre de transactions d'être traitées dans le même laps de temps. Cependant, lorsque les premiers prix du BTC étaient très bas, le coût des transactions malveillantes était également très faible. Pour résoudre ce problème, Satoshi Nakamoto a dirigé une bifurcation douce le 12 septembre 2010, introduisant une limite de taille des blocs ne pouvant pas dépasser 1 Mo. Satoshi a noté que cette restriction était temporaire et que, à l'avenir, la limite de bloc pourrait être augmentée de manière contrôlée et progressive pour répondre aux besoins d'expansion.

Avec la popularité de Bitcoin, le problème de la congestion des transactions réseau et des temps de confirmation accrus est devenu de plus en plus sérieux. En 2015, Gavin Andresen et Mike Hearn ont annoncé qu'ils mettraient en œuvre la proposition BIP-101 dans la nouvelle version de BitcoinXT, espérant augmenter la limite de taille des blocs à 8 Mo. Cependant, des développeurs principaux comme Greg Maxell, Luke Jr et Pieter Wuille s'y sont opposés, arguant que cela augmenterait la barrière à l'exécution d'un nœud complet et pourrait avoir des impacts incontrôlables. Ce débat s'est finalement élargi tant en termes de portée que de participation.

À partir du contenu ci-dessus, nous voyons que Satoshi Nakamoto a également exprimé que "la limite de taille de bloc est une contrainte temporaire qui peut être augmentée de manière contrôlée et graduée à l'avenir pour répondre aux besoins d'expansion." Mais quand un fork prendra-t-il en charge des blocs plus importants et la scission d'une chaîne distincte pour prendre en charge de grands blocs peut-elle résoudre le problème? Au milieu de controverses persistantes, de nombreux cas sont apparus. Par exemple, la taille de bloc BCH est de 8 Mo, augmentée plus tard à 32 Mo. BSV a une taille de bloc de 128 Mo. En dehors de BCH (et plus tard BSV), cette période a également vu de nombreux autres forks BTC; selon BitMEXResearch, au moins 50 nouvelles pièces forkées sont apparues dans l'année suivant le fork BCH seul.

Plus tard, le contenu montrera que sur le réseau principal de Bitcoin, Segwit et Taproot ont également augmenté dans une certaine mesure l'espace de bloc de 1 Mo à 4 Mo.

Les forks de Bitcoin sont une forme d'exploration développementale, cherchant à répondre à un plus large éventail de besoins à travers des changements au sein même de celui-ci, y compris les besoins des utilisateurs, des mineurs, des investisseurs, des développeurs, et plus encore.

1.3. Plusieurs explorations typiques dans le développement de Bitcoin

Après le départ de Satoshi Nakamoto, son successeur Gavin Andresen a pris la tête de la création de Bitcoin Core et de la Bitcoin Foundation. Pendant cette période, les explorations sur la scalabilité du BTC, en particulier dans le domaine de l'émission d'actifs, ont persisté.

(1) Colored Coins (jeton coloré)

Yoni Assia, PDG d'eToro, a d'abord proposé le concept de jetons colorés dans un article publié le 27 mars 2012. Cette idée a continué à évoluer et a commencé à prendre forme et à attirer l'attention sur des forums tels que Bitcointalk. Finalement, Meni Rosenfeld a publié un livre blanc détaillé sur les jetons colorés le 4 décembre 2012.

L'idée derrière les jetons colorés est de représenter une gamme plus large d'actifs et de valeurs en ajoutant des marques spéciales (c'est-à-dire, de la couleur) à des parties spécifiques de Bitcoin. Dans la mise en œuvre, les jetons colorés ont émergé dans plusieurs entités, largement divisées en deux catégories :

1) Basé sur OP_RETURN: Tel que proposé par Flavien Charlon en 2013, en utilisant Open Assets, qui utilise OP_RETURN (introduit dans Bitcoin v0.9.0 pour stocker une petite quantité de données sur Bitcoin, initialement limité à 40 octets, plus tard augmenté à 80 octets). L'opcode est stocké dans le script et le "coloring" et les transactions sont complétés par une lecture externe (Ce modèle est similaire aux Ordinaux, qui reposent sur un index externe pour déterminer la légalité des actifs).

2) Basé sur OP_RETURN: Un exemple typique est le protocole EPOBC proposé par ChromaWay en 2014, où des informations supplémentaires sur les actifs EPOBC sont stockées dans le champ nSequence des transactions Bitcoin, et la catégorie et la légalité de chaque actif EPOBC doivent être retracées jusqu'à la transaction de genèse pour le déterminer.

(2) MasterCoin (OMNI)

JR Willett a publié le concept de MasterCoin le 6 janvier 2012, le nommant "le deuxième livre blanc de Bitcoin", et a officiellement lancé le projet via une ICO en juillet 2013, levant finalement 5120 BTC (d'une valeur de 500 000 $ à l'époque). La distinction entre MasterCoin et Colored Coins réside dans le fait qu'il a établi une couche de nœud complète, qui maintient une base de données de modèle d'état en scannant les blocs Bitcoin, résidant dans des nœuds en dehors de la blockchain. Cette conception offre des fonctionnalités plus complexes que Colored Coins, telles que la création de nouveaux actifs, des échanges décentralisés et des mécanismes automatisés de rétroaction de prix. En 2014, Tether a également lancé la stablecoin connue sous le nom de Tether USD (OMNI) sur Bitcoin via le protocole Mastercoin.

(3) Contrepartie

Counterparty a été officiellement lancé en 2014. Comme Colored Coins, Counterparty utilise également OP_RETURN pour stocker des données dans le réseau BTC. Cependant, contrairement aux pièces colorées, les actifs de Counterparty n'existent pas sous forme de UTXOs, mais au lieu de cela, les informations sont chargées via OP_RETURN pour indiquer les transferts d'actifs. Lorsqu'un détenteur d'actifs signe une transaction contenant des données spéciales en utilisant l'adresse de détention, l'actif est transféré. Grâce à cette méthode, Counterparty peut mettre en œuvre l'émission d'actifs, le trading et une plateforme compatible avec les contrats intelligents Ethereum.

De plus, certaines opinions considèrent également Ethereum, Ripple et BitShares comme faisant partie d'un plus large "Bitcoin 2.0".

1.4 Imperfections de Bitcoin et des protocoles en couches

Les imperfections (ou limitations) du Bitcoin se manifestent principalement sous plusieurs aspects (les imperfections mentionnées dans cet article sont basées sur le résumé du livre blanc d'Ethereum et ne sont pas nécessairement de véritables défauts).

1. Système de compte UTXO de Bitcoin

Dans les projets de blockchain actuels, il existe principalement deux types de méthodes de conservation des enregistrements : le modèle de compte/solde et le modèle UTXO. Bitcoin utilise le modèle UTXO, tandis qu'Ethereum, EOS et d'autres utilisent le modèle de compte/solde.

Dans un portefeuille Bitcoin, nous pouvons généralement voir le solde du compte; cependant, dans la conception originale du système Bitcoin par Satoshi Nakamoto, il n'y avait pas de concept de "solde". Le "solde Bitcoin" est un dérivé des applications de portefeuille Bitcoin. UTXO (Unspent Transaction Outputs) représente les sorties de transaction non dépensées et c'est un concept clé dans la génération et la vérification des transactions Bitcoin. Les transactions forment une structure en forme de chaîne où toutes les transactions Bitcoin légitimes peuvent être retracées jusqu'aux sorties d'une ou plusieurs transactions précédentes. Ces chaînes commencent par les récompenses minières et se terminent par les sorties de transaction non dépensées actuelles.

Par conséquent, dans le monde réel, il n'y a pas de bitcoins, seulement des UTXO. Les transactions Bitcoin se composent d'entrées et de sorties de transaction; chaque transaction dépense une entrée pour produire une sortie, qui devient ensuite une "sortie de transaction non dépensée", ou UTXO.

La mise en œuvre des contrats intelligents présente des défis importants avec le modèle UTXO. Gavin Wood, le concepteur du Livre Jaune d'Ethereum, a une compréhension approfondie de l'UTXO. La caractéristique la plus significative d'Ethereum est les contrats intelligents. En raison des contrats intelligents, il est difficile pour Gavin Wood de mettre en œuvre des contrats intelligents Turing-complets basés sur l'UTXO. Le modèle de compte, qui est intrinsèquement orienté objet, enregistre chaque transaction sur le compte correspondant (nonce++). Pour faciliter la gestion des comptes, un état global est introduit où chaque transaction modifie cet état global, de manière analogue à la façon dont chaque petit changement affecte le monde réel. Ainsi, Ethereum et les blockchains publiques ultérieures sont généralement basées sur divers types de systèmes de comptes.

Une autre faille majeure de l'UTXO est son incapacité à fournir un contrôle précis sur les limites de retrait du compte, comme cela est discuté dans le livre blanc d'Ethereum.

1. Langage de script de Bitcoin, non Turing-complet

Alors que le langage de script de Bitcoin peut prendre en charge divers calculs, il ne peut pas prendre en charge tous les calculs. La principale omission est que le langage de script de Bitcoin manque d'instructions de bouclage et d'instructions de contrôle conditionnel. Par conséquent, le langage de script de Bitcoin n'est pas complet, limitant ses capacités. Cependant, ces limitations empêchent les pirates d'utiliser ce langage de script pour créer des boucles infinies (qui pourraient paralyser le réseau) ou un code malveillant qui pourrait entraîner des attaques par déni de service, protégeant ainsi le réseau Bitcoin contre les attaques par déni de service. Les développeurs de Bitcoin pensent également que la blockchain de base ne doit pas être complète pour empêcher les attaques et la congestion du réseau. Cependant, la raison pour laquelle un langage non complet est plus sûr est insuffisante, et un tel langage ne peut effectuer que des fonctions limitées.

1. Autres imperfections de Bitcoin: Sécurité, Scalabilité

La centralisation de l'exploitation minière est un problème, où l'algorithme d'exploitation minière de Bitcoin permet essentiellement aux mineurs d'apporter de légères modifications à l'en-tête du bloc des millions de fois jusqu'à ce que le hash de la version modifiée d'un nœud soit inférieur à la valeur cible. Cet algorithme d'exploitation minière est susceptible à deux formes d'attaques de centralisation. Tout d'abord, l'écosystème minier est contrôlé par des ASIC (circuits intégrés spécifiques à une application) et des puces informatiques conçues spécifiquement pour l'exploitation minière de Bitcoin, qui sont des milliers de fois plus efficaces dans cette tâche. Cela signifie que l'exploitation minière de Bitcoin n'est plus hautement décentralisée et égalitaire mais nécessite un capital substantiel pour une participation efficace. Deuxièmement, la plupart des mineurs de Bitcoin ne valident plus les blocs localement; au contraire, ils s'appuient sur des pools miniers centralisés pour fournir les en-têtes de bloc. Ce problème est important : actuellement, les trois principaux pools miniers contrôlent indirectement environ 50% de la puissance de traitement dans le réseau Bitcoin.

La scalabilité est un problème important pour Bitcoin. En utilisant Bitcoin, les données augmentent d'environ 1 Mo par heure. Si le réseau Bitcoin traitait 2000 transactions par seconde comme Visa, il augmenterait d'1 Mo toutes les trois secondes (1 Go par heure, 8 To par an). Les chiffres de transactions plus bas ont également suscité la controverse au sein de la communauté Bitcoin, car des blockchains plus volumineuses peuvent améliorer les performances, mais au risque de la centralisation.

D'un point de vue du cycle de vie du produit, certaines des imperfections mineures du Bitcoin peuvent être améliorées au sein de son propre système, limitées par le système actuel. Cependant, ces problèmes peuvent être résolus sans tenir compte des contraintes du vieux système s'ils sont abordés dans un nouveau système. Si un nouveau système blockchain est en cours de développement, alors ces petites améliorations fonctionnelles devraient également être conçues et améliorées.

Conception en couches

La conception en couches est une méthodologie et une approche utilisée par les humains pour gérer des systèmes complexes en divisant un système en plusieurs structures hiérarchiques et en définissant les relations et les fonctions entre ces couches pour atteindre la modularité, la maintenabilité et l'évolutivité du système, améliorant ainsi l'efficacité et la fiabilité de la conception du système.

Pour un système de protocole large et étendu, l'utilisation de couches présente des avantages clairs. Cette approche facilite la compréhension des gens

, mettre en œuvre et améliorer des modules. Par exemple, dans les réseaux informatiques, le modèle ISO/OSI est une conception à sept couches, mais dans la pratique, certaines couches peuvent être combinées, comme le protocole TCP/IP à quatre couches. Les avantages spécifiques de la stratification des protocoles incluent l'indépendance et la flexibilité de chaque couche, la divisibilité structurelle, la facilité de mise en œuvre et de maintenance, et la facilitation des efforts de normalisation.

Du point de vue des protocoles en couches, la position du Bitcoin en tant que couche fondamentale signifie que ses caractéristiques telles que UTXO, la non-complétude de Turing, les longs temps de bloc, la petite capacité de bloc et la disparition de son fondateur ne sont pas des défauts mais plutôt des traits qu'une couche de réseau de base devrait avoir.

Remarque : L'auteur fournit des explications plus détaillées sur la stratification des protocoles dans "Aperçu du système de connaissances de base de construction de la couche 2 (couche 2) Bitcoin V1.5."

2. Nouvelles technologies importantes dans le développement de Bitcoin (Expansion des blocs et amélioration des capacités)

Dans la section précédente, nous avons exploré les principaux conflits de la technologie Bitcoin originale et quelques cas exploratoires, dont beaucoup ont conduit à des forks durs ou à la création de chaînes hétérogènes entièrement nouvelles. Cependant, au sein de la blockchain de Bitcoin elle-même, ces explorations ont également donné de nombreux résultats, fondamentalement sous la forme d'expansion de bloc et d'amélioration des capacités. Celles-ci se manifestent principalement dans les aspects suivants :

2.1. OP_RETURN

Les développeurs de Bitcoin ont toujours cherché à étendre les capacités de Bitcoin, manifestées de plusieurs façons :

(1) Utilisation de OP_RETURN

OP_RETURN est un code d'opération de script utilisé pour terminer un script et renvoyer la valeur supérieure de la pile. Ce code d'opération est similaire à la fonction de retour dans les langages de programmation. Tout au long de l'histoire de Bitcoin, la fonctionnalité du code d'opération OP_RETURN a été modifiée à plusieurs reprises, et il est maintenant principalement utilisé comme méthode pour stocker des données sur le grand livre. La fonctionnalité du code d'opération OP_RETURN a subi des modifications significatives dans le passé, et il est maintenant un mécanisme important pour stocker des données arbitraires on-chain.

Initialement, OP_RETURN était utilisé pour mettre fin prématurément à l'exécution du script, avec le résultat de l'exécution présenté comme le premier élément de la pile. Cet opcode avait initialement une vulnérabilité qui était facilement exploitée, mais Satoshi Nakamoto l'a rapidement corrigée.

Autres modifications de la fonctionnalité OP_RETURN

Dans la mise à niveau vers Bitcoin Core v 0.9.0, les scripts "OP_RETURN output" ont été transformés en un type de sortie standard, permettant aux utilisateurs d'ajouter des données aux "sorties de transaction non dépensables". Le volume de données disponible dans de tels scripts était initialement limité à 40 octets, puis augmenté à 80 octets.

Stockage de données sur la blockchain :

Changer OP_RETURN pour toujours retourner faux a eu des résultats intéressants. Puisque aucun autre opcode ou donnée n'est évalué après OP_RETURN, les utilisateurs du réseau ont commencé à utiliser cet opcode pour stocker des données dans des formats arbitraires.

Pendant l'ère du Bitcoin Cash (BCH), du 1er août 2017 au 15 novembre 2018, la longueur des données pouvant être attachées aux sorties OP_RETURN a été étendue à 220 octets, permettant ainsi l'intégration de données plus importantes pour favoriser des applications innovantes sur la blockchain, telles que la publication de contenu sur les médias sociaux de la blockchain.

Sur BSV, la limite de 220 octets a été conservée pendant une courte période. Plus tard, en janvier 2019, parce que l'opcode OP_RETURN termine le script de manière à ce que les nœuds ne vérifient pas les opcodes suivants, les nœuds ne vérifient également pas si le script était dans la limite de taille maximale de script de 520 octets. Par conséquent, les opérateurs de nœuds du réseau ont décidé d'augmenter le volume de transaction maximum à 100 Ko, accordant ainsi aux développeurs plus de liberté pour l'innovation des applications, permettant aux nouvelles applications d'insérer des données plus grandes et plus complexes dans le registre Bitcoin. À ce moment-là, il y avait un exemple d'application où quelqu'un avait mis un site Web entier dans le registre BSV.

Bien que OP_RETURN ait quelques extensions fonctionnelles, ses capacités globales restent limitées. Cela a conduit à la technologie de Segregated Witness.

(2) SegWit (Segregated Witness)

Segregated Witness, ou SegWit, a été proposé pour la première fois par Pieter Wuille (développeur principal de Bitcoin et co-fondateur de Blockstream) en décembre 2015 et est devenu plus tard le BIP 141 de Bitcoin. SegWit modifie légèrement la structure des données des transactions dans les blocs Bitcoin pour résoudre les problèmes suivants :

1) Problème de malléabilité des transactions.

2) Dans les preuves SPV, le transfert des signatures de transaction devient facultatif, réduisant le volume de données des preuves de Merkle.

3) Augmentation indirecte de la capacité des blocs.

Les deux premiers éléments augmentent principalement la sécurité et les performances, avec le plus grand impact sur les nouvelles technologies étant le troisième élément, qui a indirectement augmenté la capacité du bloc (voir le concept de poids du bloc ci-dessous), posant les bases de l'amélioration des capacités de Bitcoin, et conduisant à des améliorations ultérieures dans Taproot (la deuxième version de Segregated Witness).

Bien que la réalisation ait augmenté la capacité de bloc, SegWit est toujours soumis à des limites de taille de bloc. La limite de taille de bloc de Bitcoin est de 1 M octets, et comme les données de témoin ne sont pas incluses dans cette limite, il existe toujours une restriction sur la taille totale du bloc pour éviter l'abus des données de témoin. Un nouveau concept appelé poids de bloc a été introduit :

Poids du bloc = Taille de base * 3 + Taille totale

La taille de base est la taille du bloc excluant les données des témoins

La taille totale est la taille totale du bloc sérialisée selon le BIP 144, comprenant à la fois les données de base et les données de témoin.

SegWit restreint le poids du bloc <= 4 M.

SegWit permet également techniquement l'expansion de Bitcoin pour utiliser le Lightning Network, ce qui n'est pas détaillé ici.

(3) Taproot (Segregated Witness V2)

Si vous utilisez directement le mot Taproot, de nombreuses personnes pourraient penser que c'est un nouveau concept, mais si vous comprenez qu'il s'agit de la deuxième version de Segregated Witness, la plupart saisiront le lien. Taproot est associé aux BIP 340, 341 et 342, nommés : BIP 340 (Signatures Schnorr pour secp256k1), BIP 341 (Taproot : règles de dépense de la version 1 de SegWit),

BIP 342 (Validation of Taproot Scripts).

En novembre 2021, Taproot a été officiellement activé en tant que soft fork. Cette mise à niveau combine BIP 340, BIP 341 et BIP 342. Parmi eux, BIP 340 introduit des signatures Schnorr qui peuvent valider simultanément plusieurs transactions, remplaçant l'algorithme de signature numérique de courbe elliptique (ECDSA), étendant une fois de plus la capacité du réseau et accélérant le traitement des transactions en lot, offrant des possibilités pour le déploiement de contrats intelligents complexes ; BIP 341 implémente les arbres de syntaxe abstraite merklisés (MAST) pour optimiser le stockage des données de transaction sur la blockchain ; BIP 342 (Tapscript) utilise le langage d'encodage de script de Bitcoin pour améliorer les capacités de script natives de Bitcoin.

L'expansion de l'espace causée par Segwit et Taproot a conduit à la création de signatures Schnorr, d'arbres MAST et de scripts Taproot, dont la mission est d'élargir les fonctionnalités du réseau principal Bitcoin.

2.2 Signatures Schnorr, MAST et scripts Taproot

De la section 2.1, nous avons observé l'exploration continue de Bitcoin dans le dimensionnement et l'amélioration des capacités, aboutissant au développement de la technologie Taproot, ainsi que plusieurs technologies cruciales telles que Schnorr, MAST et les scripts Taproot, qui ont réellement étendu les capacités de Bitcoin.

(1) Signatures Schnorr

L'évolution de Taproot, tout en élargissant les capacités, a nécessité des exigences spécifiques de l'algorithme de signature, introduisant ainsi les signatures Schnorr pour remplacer l'algorithme de signature numérique basé sur les courbes elliptiques (ECDSA). Les signatures Schnorr sont un schéma de signature numérique qui peut signer efficacement et en toute sécurité des transactions et des messages. Elles ont été décrites pour la première fois par Claus Schnorr dans un article de 1991. Schnorr est acclamé pour sa simplicité, sa sécurité prouvable et sa linéarité.

Avantages des signatures Schnorr :

1) Les signatures Schnorr offrent plusieurs avantages, notamment l'efficacité et une confidentialité renforcée tout en conservant toutes les fonctionnalités et les hypothèses de sécurité de l'ECDSA. Elles permettent des tailles de signature plus petites, des temps de vérification plus rapides et une résistance améliorée à certains types d'attaques.

2) Un avantage notable des signatures de Schnorr est l'agrégation des clés, qui agrège plusieurs signatures en une seule qui est valide pour la somme de leurs clés. En d'autres termes, Schnorr permet à plusieurs parties coopérantes de générer une seule signature qui est valide pour le total de leurs clés publiques. L'agrégation des signatures permet de combiner les signatures de plusieurs signataires en une seule signature.

L’agrégation de clés peut réduire les frais de transaction et améliorer l’évolutivité sous-jacente, car les signatures électroniques issues de configurations multisig occupent le même espace dans un bloc que celles issues de transactions à partie unique. Cette fonctionnalité de Schnorr peut être utilisée pour réduire la taille des paiements multisig et d’autres transactions liées au multisig, telles que les transactions de canal Lightning Network.

3) Une autre caractéristique importante des signatures de Schnorr est leur non-malléabilité.

4) Schnorr offre également de nombreux avantages en termes de confidentialité. Il rend les schémas multisig indiscernables des schémas de clé unique traditionnels pour les observateurs extérieurs, rendant ainsi plus difficile de différencier les dépenses multisig des dépenses à signature unique on-chain. De plus, dans les configurations n-sur-m multisig, Schnorr rend plus difficile pour les observateurs extérieurs de déterminer quels participants ont signé une transaction et lesquels ne l'ont pas fait.

Les signatures Schnorr sont mises en œuvre dans le BIP-340 dans le cadre de la mise à niveau du soft fork Taproot et ont été activées le 14 novembre 2021, au bloc 709 632. Schnorr rend les signatures numériques de BTC plus rapides, plus sécurisées et plus faciles à manipuler. Notamment, les signatures Schnorr sont rétrocompatibles avec les algorithmes cryptographiques de BTC, ce qui permet de les introduire par le biais d'une mise à niveau du soft fork.

(2) Arbres de syntaxe abstraite MAST

Il existe une légère ambiguïté dans l'abréviation de MAST en chinois et en anglais. Officiellement, BIP (BIP 114) et certains articles utilisent l'abréviation MAST pour : Merklized Abstract Syntax Tree. D'autres sources traduisent Merklized Alternative Script Trees (MAST) en chinois par Merklized Replacement Script Trees (MAST). Dans le livre "Mastering Bitcoin" et un article, cette abréviation est utilisée :https://cointelegraph.com/learn/a-beginners-guide-to-the-bitcoin-taproot-upgrade.

Les arbres de syntaxe abstraite merklisés et les arbres de script alternatifs merklisés (MAST) semblent avoir la même fonction. D'un point de vue de traduction, je pense personnellement qu'il est préférable de maintenir l'utilisation trouvée dans le protocole officiel Bitcoin BIP.

Le concept derrière MAST vient de deux idées : Arbres de Syntaxe Abstraite et Arbres de Merkle.

Les arbres de syntaxe abstraite (AST) appartiennent au domaine des principes de compilation et de la linguistique formelle en informatique. Un arbre de syntaxe abstraite est une représentation intermédiaire pendant le processus de compilation, utilisée pour représenter la structure sémantique du code source. Il transforme le code source en une structure arborescente, où chaque nœud représente une unité sémantique, et les arêtes représentent les relations entre eux. Les arbres de syntaxe abstraite jouent un rôle crucial dans les étapes d'analyse lexicale et syntaxique du compilateur, aidant à comprendre le sens du code source et à réaliser des processus ultérieurs d'optimisation et de génération de code cible. En d'autres termes, un arbre de syntaxe abstraite (AST) est une méthode de description d'un programme en le divisant en blocs indépendants, rendant le programme plus facile à analyser et à optimiser. Pour générer un AST, toutes les équations et leurs prémisses doivent être connectées avec des flèches jusqu'à ce que toutes les prémisses soient identifiées. L'image ci-dessous est un AST d'un script.

D'autre part, un arbre de Merkle peut être utilisé pour vérifier si un élément appartient à un ensemble sans avoir besoin de connaître l'ensemble entier. Par exemple, les portefeuilles de vérification de paiement simplifiés de Bitcoin (portefeuilles SPV) utilisent des arbres de Merkle pour vérifier si une transaction existe dans un bloc, économisant de la bande passante en ne téléchargeant pas le bloc entier.

Pour générer un arbre de Merkle, chaque élément est haché individuellement pour créer un identifiant unique; ces identifiants sont ensuite appariés et hachés à nouveau pour créer un identifiant pour ce couple; ce processus est répété jusqu'à ce qu'il ne reste qu'un seul identifiant, appelé "racine de Merkle", qui est un identifiant concis qui représente l'ensemble.

Lors de la vérification de l'appartenance d'un élément à un ensemble, le propriétaire de l'ensemble peut vous fournir tous les identifiants de cet élément jusqu'à la racine de Merkle. Cela prouve que l'élément fait bien partie de l'ensemble.

En bref, la technologie derrière AST vous permet de diviser un programme en plusieurs petits blocs, tandis qu'un arbre de Merkle nous permet de vérifier que ces blocs font effectivement partie d'un programme complet, sans exposer l'intégralité du programme. C'est le principe de base de MAST, qui permet aux dépensiers de remplacer des conditions inutilisées dans une seule transaction par une preuve de Merkle, avec les avantages de réduire la taille des transactions, d'améliorer la confidentialité et de prendre en charge des contrats plus importants.

Il existe de nombreux exemples d'arbres MAST en ligne, et ceux qui sont familiers avec le développement de programmes peuvent clairement comprendre la logique liée à un processus MAST.

Avec l'avènement des arbres de syntaxe abstraite MAST, il devient nécessaire d'étendre les capacités de syntaxe natives de Bitcoin, ce qui conduit à la création de scripts Taproot.

(3) Scripts Taproot

Introduit sous le protocole BIP 342, Taprootscript est une version améliorée du script Bitcoin original, essentiellement une collection de codes d'opération avec des commandes qui soutiennent la mise en œuvre d'autres BIP. Taprootscript élimine également la limite de taille de script de 10 000 octets, offrant un meilleur environnement pour la création de contrats intelligents sur le réseau Bitcoin. Cette mise à niveau a également posé les bases pour le développement ultérieur des Ordinaux, qui utilisent les scripts de dépense du chemin de script de Taproot pour attacher des données supplémentaires. Plus de détails peuvent être trouvés sur le site officiel :

https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki

Les capacités de TaprootScript n'ont pas encore été pleinement utilisées, et de nouveaux développements à l'avenir démontreront son potentiel, en particulier dans la connexion du premier réseau Bitcoin avec les technologies de deuxième couche, où Taproot, MAST et TaprootScripts seront probablement utilisés de manière plus extensive.

2.3 Ordinaux, Inscriptions, BRC 20 et autres protocoles

Avec des outils fondamentaux tels que Segwit, Taproot, Schnorr, MAST et des scripts Taproot dans l'écosystème Bitcoin, de nouvelles applications ont commencé à émerger. Initialement, ces applications étaient légères et simples.

(1) Protocole des ordinaux, inscriptions et BRC 20

La création du protocole Ordinals est étroitement associée au concept de satoshis. Le protocole introduit les concepts d'ordinaux et d'inscriptions. Les ordinaux sont un schéma de numérotation qui attribue un numéro unique à chaque satoshi sur le réseau Bitcoin selon l'ordre dans lequel ils ont été extraits. Dans le protocole, l'identifiant ordinal reste inchangé quel que soit le mode de transfert du satoshi entre différents portefeuilles. Les nœuds complets de Bitcoin exécutant le logiciel open source de Rodarmor, ORD, peuvent suivre ces satoshis numérotés, fournissant un mécanisme précis permettant aux gens de suivre chaque satoshi et de les vérifier de manière indépendante.

Les inscriptions impliquent de graver des informations sur les satoshis. En utilisant SegWit et Taproot, le protocole Ordinals permet de graver des fichiers de moins de 4 Mo sur chaque satoshi d'un bloc Bitcoin. Il s'agit des inscriptions qui peuvent contenir différents types d'informations telles que du texte, des images ou des vidéos.

En termes simples, le schéma de numérotation ordinale fournit à chaque satoshi un identifiant unique et traçable, ce qui lui confère des caractéristiques non fongibles. Les inscriptions permettent d’ajouter des données indivisibles sur ces ordinaux, comme si l’on créait de l’art sur une toile vierge. Combinés, ils permettent à Bitcoin d’héberger une nouvelle norme pour les NFT. Essentiellement, Ordinals est comme un protocole NFT, mais contrairement à l’ETH ou à d’autres blockchains publiques où les métadonnées NFT sont généralement stockées sur IPFS ou des serveurs centralisés, Ordinals intègre des métadonnées dans les données témoins de la transaction, comme si elles étaient « gravées » sur un satoshi spécifique.

BRC-20: Inspiré par le protocole Ordinals, l'utilisateur Twitter @domodataa créé la norme de jeton fongible expérimentale BRC-20 sur Bitcoin le 8 mars 2023. En attribuant différents “attributs” à chaque satoshi, le protocole Ordinals crée des NFT du réseau BTC, tandis que le BRC-20 le fait en fournissant un “format” et des “attributs” uniformes pour les jetons fongibles basés sur le BTC (FTs). Le BRC-20 utilise le protocole Ordinals pour écrire un texte JSON dans une inscription BTC afin de déployer des contrats de jetons, de créer et de transférer des jetons. Les aspects clés du déploiement comprennent le nom du jeton, l'offre totale et la frappe maximale par occasion. Pour les transactions impliquant des transferts ou des achats/ventes, un NFT supplémentaire suit les soldes hors chaîne. Un mécanisme de frappe “premier arrivé, premier servi” offre des opportunités d'émission et de participation équitables. Cependant, l'infrastructure relativement sous-développée de l'écosystème BTC et sa courbe d'apprentissage abrupte, associées à une liquidité faible, facilitent la montée en puissance de jetons BRC-20 comme ordi, sats et rats, créant un mythe de création de richesse.

(2) Autres Protocoles - Atomiques, ARC 20

Le développement du protocole Atomicals a été assez dramatique. Son fondateur, Arthur, voulait initialement développer un projet DID sur le nouveau protocole Ordinals, mais s'est rendu compte qu'Ordinals avait de nombreuses limitations défavorables pour prendre en charge certaines des fonctionnalités qu'il voulait mettre en œuvre. Par conséquent, le 29 mai 2023, Arthur a tweeté sur son concept du protocole Atomicals, qui a été lancé plus tard le 17 septembre 2023 après des mois de développement. Ensuite, le protocole Atomicals a engendré des concepts comme Dmint, Bitwork, ARC-20 et RNS, avec des plans futurs pour introduire AVM et des solutions de fractionnement. Comme pour Ordinals et BRC-20, le déploiement de jetons fongibles sur Atomicals aboutit à la création de l'ARC-20. Les lecteurs intéressés par l'ARC-20 peuvent en savoir plus ici : Jetons ARC-20.

(3) Autres protocoles - Rune

Au fur et à mesure que l'écosystème évoluait, Casey Rodarmor, le créateur des Ordinals, a souligné que les jetons BRC-20 ont la « conséquence malheureuse de la prolifération des UTXO » et a suggéré les Runes comme une solution alternative basée sur les UTXO. Les protocoles existants souffrent généralement de mises en œuvre complexes, de mauvaises expériences utilisateur, de sorties de transaction non dépensées (UTXOs) indésirables et d'opérations nécessitant des jetons natifs.

Le transfert des Runes utilise OP_RETURN, et la première sortie de données dans le message de protocole est décodée en une séquence d'entiers, interprétée comme une série de tuples (ID, OUTPUT, AMOUNT). Si le nombre d'entiers décodés n'est pas un multiple de trois, le message de protocole est invalide. ID fait référence à l'ID du jeton à transférer, OUTPUT est l'indice de sortie assigné (c'est-à-dire, à quelle sortie il est assigné), et AMOUNT est la quantité allouée. Après le traitement de toutes les allocations de tuple, tous les jetons Runes non alloués sont assignés à la première sortie non-OP_RETURN, le reste pouvant éventuellement être inscrit avec des jetons Runes dans la sortie OP_RETURN contenant le message de protocole.

L’émission de Runes est basée sur le suivi UTXO de tokens homogènes. Si le message de protocole inclut une deuxième transmission de données, il s’agit d’une transaction d’émission. Le deuxième push de données est décodé en deux entiers, SYMBOL et DECIMALS. S’il reste des entiers supplémentaires, le message de protocole n’est pas valide. SYMBOL est un symbole lisible de base de 26 caractères, similaire à ceux utilisés dans les noms d’ordinaux, les seuls caractères valides étant de A à Z. DECIMALs indiquent les décimales à utiliser lors de l’émission de runes. Si SYMBOL n’a pas encore été attribué, une valeur d’ID est attribuée au jeton Runes (à partir de 1). Si le SYMBOLE a déjà été attribué ou s’il s’agit d’un BITCOIN, d’un BTC ou d’un XBT, aucune nouvelle rune ne sera créée. Il s’agit d’une particularité du protocole Runes : il ne relie pas les enregistrements de solde aux adresses de portefeuille, mais les stocke plutôt dans l’UTXO lui-même. Les nouveaux jetons de runes commencent à partir de la transaction d’émission, en spécifiant l’offre, le symbole et les décimales, et cette offre est allouée à des UTXO spécifiques. Les UTXO peuvent contenir n’importe quel nombre de jetons Runes, quelle que soit leur taille, et ne sont utilisés que pour le suivi des soldes. Ensuite, la fonction de transfert utilise cet UTXO, en le divisant en plusieurs nouveaux UTXO de taille arbitraire contenant différentes quantités de runes, envoyant les enregistrements à d’autres. Par rapport au BRC-20, Runes simplifie la couche de consensus, devenant plus simple tout en ne s’appuyant pas sur des données hors chaîne et en manquant de jetons natifs, ce qui le rend parfaitement adapté au modèle UTXO natif de Bitcoin.

(4) Autres protocoles - Timbres BTC, SRC 20, SRC 721

Le système Bitcoin Stamps a été lancé par Mike In Space en mars 2023, initialement en tant que projet de preuve de concept sur Counterparty, une couche 2 de Bitcoin qui existe depuis 2014. En raison des mises à jour de ses protocoles sous-jacents, Stamps est complètement passé à Bitcoin, devenant connu sous le nom de SRC-20 l'été dernier. Initialement, Mike envisageait Stamps comme une méthode pour frapper des NFT Bitcoin permanents. Cependant, le protocole s'est depuis étendu pour reproduire BRC-20, un type de jeton remplaçable par lot qui a prospéré sur Bitcoin en raison de la frénésie d'inscription suscitée par le lancement des Ordinals de Casey Rodarmor en janvier 2023.

La principale différence entre Stamps et Ordinals réside dans leur architecture. Stamps stocke ses métadonnées dans des sorties de transaction non dépensées (UTXO) à signatures multiples, tandis que Ordinals stocke ses métadonnées dans la partie "témoin" des transactions Bitcoin. Cette différence architecturale met en évidence les compromis faits par les développeurs. Par exemple, la méthode UTXO de Stamps les rend non prunable, semblant ainsi permanents, bien que leur coût de fabrication soit plus élevé que celui d'Ordinals. En revanche, l'utilisation des données de témoin par Ordinals les rend finalement prunable, et leur coût de fabrication est inférieur à celui de Stamps.

Ainsi, bien que les Ordinaux puissent offrir le meilleur rapport durabilité-coût pour les NFT crypto d'aujourd'hui (qui peuvent également être obtenus sur Ethereum, mais à un coût de construction plus élevé), Stamps semble actuellement offrir la meilleure garantie de permanence directe.

Suite à l'émergence des timbres BTC, SRC 20 et SRC 721 ont été développés, fonctionnant de manière similaire à BRC-20. BRC-20 est construit sur le protocole Ordinals, tandis que SRC-20 est construit sur BTC STAMPS. Les lecteurs intéressés peuvent consulter la documentation SRC 20 et SRC 721 ici :

Protocole SRC 20

Protocole SRC 721

Ceci conclut l'introduction aux nouvelles technologies importantes sur le réseau de couche 1 de Bitcoin. Pour une mise à l'échelle et une amélioration supplémentaires, l'accent sera mis sur l'infrastructure de couche supérieure de Bitcoin, telle que la couche 2 de Bitcoin ou les solutions exploitant le réseau Lightning. Pour en savoir plus sur ce sujet, il est conseillé aux lecteurs de lire "Guide complet de l'infrastructure de couche 2 de Bitcoin, Version 1.5" et "Du point de vue des machines d'État : Observer l'architecture et le chemin de construction des futures applications Web3.0", ou d'autres articles liés à la construction ou à la conception architecturale de la couche 2 de Bitcoin.

3. Utilisation de nouvelles technologies et besoins en développement futur

Basé sur le contenu de la section 2, nous observons que l'évolution technologique au sein de l'écosystème Bitcoin a posé les bases pour des applications plus larges. Cependant, comme le développement est un processus et que certaines technologies connexes sont encore immatures, il existe une différence significative entre les applications populaires actuelles et les utilisations communes futures.

3.1 Méthodes d'utilisation de la nouvelle technologie

Des sections précédentes, nous voyons que l'essence du développement technologique de Bitcoin consiste à étendre la capacité et les fonctionnalités des blocs.

Expansion de bloc :Le témoin séparé (SegWit) a effectivement étendu la capacité des blocs, bien qu'il existe diverses propositions pour réduire les données du témoin, de tels événements sont peu probables, surtout après que les données du témoin ont gagné en importance.

Expansion des capacités :Les technologies telles que Taproot, Schnorr, MAST et Taproot Scripts ont amélioré les capacités de Bitcoin. En particulier, la combinaison de MAST et de Taproot Scripts élargit les capacités du langage de script natif de Bitcoin, permettant la gestion de scénarios plus complexes. Cependant, l'extension de ces capacités augmente également la complexité du développement et de la compréhension de Bitcoin, car le développement de script n'est pas effectué dans un langage de haut niveau. De plus, l'extension de ces capacités est en retard par rapport à la compréhension et au rythme d'apprentissage des utilisateurs concernant l'expansion de la capacité de bloc.

La simplicité de l'expansion des blocs par rapport à la complexité de l'expansion des capacités explique pourquoi les utilisateurs stockent initialement de petites NFT d'images sur le mainnet de Bitcoin, ce qui a conduit à l'émergence d'applications comme BRC 20. La plupart des applications actuellement sur le mainnet de Bitcoin explorent les utilisations post-expansion des blocs. Une petite partie des applications commence à explorer l'expansion des capacités, telles que la connexion entre les premier et deuxième niveaux dans BEVM, qui utilise de manière prédominante les éléments de base susmentionnés. La combinaison des signatures Schnorr, des contrats MAST et du réseau de nœuds légers Bitcoin (BTC L2) est un cas représentatif d'apprentissage de la connexion entre les premier et deuxième niveaux. Des cas d'expansion des capacités plus étendus sont attendus à l'avenir.

Où devraient se situer les limites de l'expansion des capacités ? Nous pouvons juger du point de vue de la conception en couches. Si ces capacités sont principalement destinées à des connexions entre la première et la deuxième couche de Bitcoin, alors elles ne doivent pas devenir trop compliquées. Cependant, poussées par la créativité humaine et la forte attraction de l'émission et de la gestion d'actifs, certaines équipes ou individus exploreront davantage de scénarios d'expansion des capacités.

3.2 Besoins de développement futur

La raison la plus directe de l'émergence de la technologie blockchain est la monnaie numérique, donc l'émission et la gestion d'actifs sont des besoins directs dans le domaine de Bitcoin ou de la blockchain. De l'exploration des jetons colorés aux applications telles que BRC 20 et ARC 20, ainsi que les ICO et IDO sur Ethereum, ce sont toutes des explorations de l'émission d'actifs. Des applications comme Uniswap, Lending et AMM concernent la gestion d'actifs. Ces types d'applications ont mûri sur des réseaux comme Ethereum et, à mesure que la technologie de l'écosystème de Bitcoin évolue, ces applications de gestion d'actifs sont susceptibles de se déplacer vers l'écosystème de Bitcoin, en particulier vers la deuxième couche de Bitcoin.

Ce n'est qu'après avoir satisfait les besoins d'émission et de gestion d'actifs qu'il y aura la capacité et le temps de développer des applications à grande échelle pour l'ère Web3.0 (également connue sous le nom d'âge de la valeur). L'architecture système pour les futures applications Web3.0 à grande échelle est abordée dans «Du point de vue des machines d'état en regardant la deuxième couche de Bitcoin, observant l'architecture des futures applications Web3.0 et le chemin de construction.

Le chemin de la construction est un processus de satisfaction continue des besoins, qui peut être divisé en étapes à court terme, à moyen terme et à long terme. Le court terme implique de nouvelles applications technologiques sur le mainnet Bitcoin et des étapes simples de construction de la deuxième couche basée sur la blockchain pour répondre aux principales expansions de capacité pour diverses applications financières. Le moyen terme implique des étapes plus avancées de la deuxième couche basée sur la blockchain et des constructions de deuxième couche de système distribué, adaptées à diverses applications financières et de confiance. Le long terme implique la construction complète de l'écosystème Bitcoin à grande échelle, construisant vraiment l'ère Web3.0.

Avertissement：

1. Cet article est repris de [ Foresightnews], Tous les droits d'auteur appartiennent à l'auteur original [付少庆、SatoshiLab、万物岛 BTC 工作室]. Si des objections à cette réimpression, veuillez contacter le Gate Apprendrel'équipe s'en chargera rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent pas des conseils en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, il est interdit de copier, distribuer ou plagier les articles traduits.