Le Saint Graal du réseau de couche 2 de Bitcoin : Introspection et conventions

cd

Comparé aux blockchains Turing-complètes comme Ethereum, le langage de script de Bitcoin est considéré comme significativement limité, capable seulement d’opérations de base, et manque même de fonctions de multiplication et de division. Plus important encore, les données de la blockchain sont pratiquement inaccessibles aux scripts, ce qui limite considérablement la flexibilité et la programmabilité. Par conséquent, les gens ont longtemps cherché des moyens d’activer l’introspection pour les scripts Bitcoin.

Introspection fait référence à la capacité des scripts Bitcoin d’inspecter et de limiter les données de transaction. Cela permet aux scripts de contrôler l’utilisation des fonds sur la base de détails spécifiques de la transaction, ce qui permet des fonctionnalités plus complexes. Actuellement, la plupart des opcodes Bitcoin poussent les données fournies par l’utilisateur sur la pile ou manipulent les données qui s’y trouvent déjà. Les opcodes d’introspection, cependant, peuvent pousser les données de transaction actuelles (telles que les horodatages, les montants et les identifiants de transaction) sur la pile, ce qui permet un contrôle plus granulaire des dépenses UTXO.

Il n’y a actuellement que trois opcodes principaux dans les scripts Bitcoin qui supportent l’introspection : CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY et CHECKSIG. CHECKSIG a plusieurs variantes, dont CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG, et CHECKMULTISIGVERIFY.

Pactes sont des restrictions sur la manière dont les jetons peuvent être transférés. Les utilisateurs peuvent spécifier la manière dont les UTXO sont distribués par le biais de conventions, dont beaucoup sont mises en œuvre à l’aide d’opcodes d’introspection. Actuellement, Bitcoin Optech classe l’introspection dans les entrées de conventions.

Bitcoin dispose actuellement de deux clauses restrictives : CSV (CheckSequenceVerify) et CLTV (CheckLockTimeVerify), qui sont toutes deux basées sur le temps et constituent la base de nombreuses solutions de mise à l’échelle, telles que le Lightning Network. Cela indique que les solutions de mise à l’échelle de Bitcoin s’appuient fortement sur l’introspection et les conventions.

Comment ajouter des conditions aux transferts de jetons

Dans le monde de la cryptographie, la méthode la plus courante est la méthode engagements, souvent mise en œuvre à l’aide de hachages. Pour prouver que les conditions de transfert sont remplies, des mécanismes de signature sont utilisés pour la vérification. Par conséquent, les conventions impliquent de nombreux ajustements au niveau des hachages et des signatures.

Les propositions suivantes sont largement débattues en ce qui concerne les opcodes de convention :

CTV (CheckTemplateVerify) BIP-119

CTV (CheckTemplateVerify), inclus dans BIP-119, est une mise à jour de Bitcoin très controversée. CTV permet aux scripts de sortie de spécifier des modèles pour les transactions de dépenses, y compris des champs tels que nVersion, nLockTime, scriptSig hash, input count, sequences hash, output count, outputs hash et input index. Ces restrictions de modèle sont mises en œuvre par le biais d’un engagement de hachage, et les futurs scripts de dépenses vérifieront si les valeurs de hachage des champs spécifiés dans la transaction de dépenses correspondent à celles du script d’entrée. Ces modèles définissent essentiellement le moment, la méthode et le montant des futures transactions UTXO.

Notamment, le TXID d’entrée est exclu de l’engagement de hachage. Cette exclusion est nécessaire car, que ce soit dans les transactions Legacy ou Segwit, le TXID dépend de la valeur scriptPubKey lors de l’utilisation du type de signature SIGHASH_ALL par défaut. L’inclusion du TXID créerait une dépendance circulaire, rendant l’engagement de hachage impossible à construire.

CTV réalise l’introspection en obtenant directement les informations de transaction spécifiées par le biais d’un nouvel opcode, en les hachant et en les comparant à l’engagement sur la pile. Cette méthode consomme moins d’espace sur la chaîne mais manque de flexibilité.

Les transactions pré-signées constituent le fondement des solutions de deuxième couche telles que le Lightning Network. La pré-signature consiste généralement à générer et à signer des transactions à l’avance, mais à ne pas les diffuser tant que certaines conditions ne sont pas remplies. Essentiellement, CTV met en œuvre une fonction de pré-signature plus stricte, en publiant l’engagement pré-signé directement sur la chaîne, n’autorisant les transactions que selon le modèle prédéfini.

Le CTV a été initialement proposé pour atténuer l’encombrement de Bitcoin et peut également être appelé contrôle de l’encombrement. Pendant les périodes de forte congestion, CTV peut engager plusieurs transactions futures par le biais d’une seule transaction, ce qui évite d’avoir à diffuser plusieurs transactions pendant la congestion et d’effectuer les transactions réelles une fois que la congestion s’est atténuée. Cela pourrait être très utile pendant les cycles d’échange. En outre, les modèles peuvent être utilisés pour mettre en œuvre des coffres-forts, empêchant les attaques de pirates informatiques puisque la destination des fonds est prédéterminée, ce qui rend impossible pour les pirates d’envoyer des UTXO à leurs adresses à l’aide du script CTV.

Le CTV peut améliorer de manière significative les réseaux de deuxième couche. Par exemple, dans le réseau Lightning, la mise en œuvre des Timeout Trees et des Channel Factories à l’aide de CTV permet à un UTXO unique de se développer en un arbre CTV, ouvrant plusieurs canaux d’état avec une seule transaction et une seule confirmation sur la chaîne. En outre, CTV prend en charge les transactions atomiques (ATLC) dans le protocole Ark.

APO (SIGHASH_ANYPREVOUT) BIP-118

Le document BIP-118 propose un nouvel indicateur de hachage de signature pour Tapscript, appelé SIGHASH_ANYPREVOUT, afin de faciliter l’écriture d’une logique de dépense plus souple. APO et CTV sont similaires à bien des égards. Pour remédier à la dépendance circulaire entre les scriptPubKeys et les TXID, la solution d’APO consiste à exclure les informations d’entrée pertinentes et à ne signer que la sortie, ce qui permet aux transactions de se lier dynamiquement à différents UTXO.

Logiquement, l’opération de vérification OP_CHECKSIG (et les opcodes correspondants) a trois fonctions :

  1. Assembler les parties de la transaction de dépense.
  2. Hachez ces pièces.
  3. Vérifie si le hachage est signé par la clé donnée.

Le contenu spécifique de la signature peut être ajusté de manière significative, et les champs de transaction qui sont signés sont déterminés par l’indicateur SIGHASH. Selon la définition des opcodes de signature BIP 342, les drapeaux SIGHASH comprennent notamment SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE et SIGHASH_ANYONECANPAY. SIGHASH_ANYONECANPAY contrôle l’entrée, tandis que les autres contrôlent la sortie.

SIGHASH_ALL est le drapeau SIGHASH par défaut, signant toutes les sorties. SIGHASH_NONE ne signe aucune sortie, et SIGHASH_SINGLE ne signe qu’une sortie spécifiée. SIGHASH_ANYONECANPAY peut être défini avec les trois autres drapeaux, et s’il est défini, il ne signe que l’entrée spécifiée ; sinon, toutes les entrées doivent être signées.

Aucun de ces indicateurs SIGHASH ne peut éliminer l’impact des entrées. Même SIGHASH_ANYONECANPAY nécessite un engagement sur une entrée.

C’est pourquoi le BIP 118 introduit SIGHASH_ANYPREVOUT. Les signatures APO n’ont pas besoin de s’engager dans l’UTXO d’entrée dépensée (appelée PREVOUT), mais seulement de signer la sortie, ce qui offre une plus grande flexibilité dans le contrôle de Bitcoin. En préconstruisant les transactions et en créant des signatures et des clés publiques correspondantes à usage unique, les actifs envoyés à cette adresse de clé publique doivent être dépensés par le biais de la transaction préconstruite, ce qui permet d’atteindre l’engagement.

La flexibilité de l’APO peut également être utilisée pour réparer les transactions. Si une transaction est bloquée sur la chaîne en raison de frais peu élevés, une autre transaction peut être facilement créée pour augmenter les frais sans nécessiter de nouvelles signatures. En outre, pour les portefeuilles à signatures multiples, les signatures qui ne dépendent pas de l’entrée dépensée simplifient les opérations.

En éliminant la dépendance circulaire entre les scriptPubKeys et les TXID d’entrée, APO peut réaliser l’introspection en ajoutant des données de sortie dans le témoin, bien que cela nécessite toujours un espace de données témoin supplémentaire.

Pour les protocoles hors chaîne tels que le Lightning Network et les chambres fortes, l’APO réduit le besoin de stockage d’états intermédiaires, ce qui diminue considérablement les besoins de stockage et la complexité. Le cas d’utilisation le plus direct de l’APO est Eltoo, qui simplifie les usines de canaux, construit des tours de guet légères et peu coûteuses et permet des sorties unilatérales sans laisser d’états erronés, améliorant ainsi les performances du Lightning Network. L’APO peut simuler la fonctionnalité du CTV, bien qu’il nécessite un stockage personnel des signatures et des transactions pré-signées, ce qui le rend plus coûteux et moins efficace que le CTV.

La principale critique d’APO concerne la nécessité d’une nouvelle version de clé, ce qui la rend incompatible avec les systèmes existants. En outre, le nouveau type de hachage de la signature pourrait introduire des risques potentiels de double dépense. Après des discussions approfondies au sein de la communauté, APO exige désormais une signature ordinaire en plus de la signature originale, ce qui atténue les problèmes de sécurité et lui vaut son numéro BIP-118.

OP_VAULT BIP-345

Le BIP-345 propose deux nouveaux opcodes, OP_VAULT et OP_VAULT_RECOVER, pour travailler avec CTV et mettre en œuvre une convention dédiée qui impose un délai à la dépense de jetons spécifiés, pendant lequel la dépense peut être « révoquée » via un chemin de récupération.

Les utilisateurs peuvent créer un coffre-fort en configurant une adresse Taproot spécifique, en incluant au moins deux scripts dans le MAST : un script OP_VAULT pour faciliter le processus de retrait prévu et un script OP_VAULT_RECOVER pour assurer la récupération des pièces avant la fin du retrait.

Comment l’OP_VAULT réalise-t-il des retraits interrompus et verrouillés dans le temps ?

En termes simples, l’opcode OP_VAULT remplace le script OP_VAULT utilisé par un script spécifié, mettant à jour un seul nœud feuille dans le MAST tout en gardant le reste inchangé. Il s’agit d’une méthode similaire à TLUV, mais qui ne prend pas en charge les mises à jour des clés internes.

L’introduction d’un modèle lors de la mise à jour des scripts peut limiter les effets des paiements. Le paramètre de verrouillage du temps est spécifié par OP_VAULT, tandis que le modèle apporté par l’opcode CTV restreint l’ensemble des sorties passées par ce chemin de script.

Le BIP-345 est conçu pour les chambres fortes, permettant aux utilisateurs de disposer d’un chemin de recouvrement hautement sécurisé (portefeuille papier, multi-signature distribuée) tout en configurant un délai de dépense pour les paiements de routine. L’appareil de l’utilisateur surveille en permanence les dépenses du coffre-fort, ce qui permet de les récupérer en cas de transfert non autorisé.

La mise en œuvre des chambres fortes avec le BIP-345 nécessite de prendre en compte les questions de frais, en particulier pour les transactions de recouvrement. Parmi les solutions possibles figurent le CPFP (Child Pays for Parent), les ancres temporaires et les nouveaux indicateurs de hachage de signature tels que SIGHASH_GROUP.

TLUV (TapleafUpdateVerify)

Le schéma TLUV est construit autour de Taproot et vise à résoudre le problème de la sortie efficace des UTXO partagées. Le principe directeur est que lorsqu’une sortie Taproot est dépensée, nous pouvons utiliser la structure interne de l’adresse Taproot et les transformations cryptographiques pour mettre partiellement à jour la clé interne et le MAST conformément aux étapes de mise à jour décrites par le script TLUV, réalisant ainsi la fonctionnalité du contrat.

L’idée du schéma TLUV est de créer une nouvelle adresse Taproot sur la base de l’entrée des dépenses actuelles par le biais d’un nouvel opcode TAPLEAF_UPDATE_VERIFY, qui peut effectuer une ou plusieurs des opérations suivantes :

Plus précisément, TLUV prend trois entrées :

  1. Une spécification sur la façon de mettre à jour la clé publique interne
  2. Un nouveau nœud feuille pour le chemin de Merkle
  3. Une spécification indiquant s’il faut supprimer le nœud feuille actuel et/ou le nombre de nœuds feuilles du chemin de Merkle à supprimer.

L’opcode TLUV calcule la clé de script mise à jour et vérifie si la sortie correspondant à l’entrée actuelle est dépensée pour cette clé de script.

Le TLUV s’inspire des pools de pièces de monnaie. Aujourd’hui, les pools de pièces peuvent être créés à l’aide de transactions pré-signées, mais si vous voulez obtenir des sorties sans permission, vous devez créer un nombre de signatures en croissance exponentielle. Le TLUV permet des sorties sans permission sans aucune transaction pré-signée. Par exemple, un groupe de partenaires utilise Taproot pour construire une UTXO partagée, en mettant en commun leurs fonds. Ils peuvent déplacer des fonds en interne en utilisant la clé Taproot ou signer conjointement pour effectuer des paiements externes. Les individus peuvent quitter le pool partagé à tout moment, supprimant ainsi leur chemin de paiement, tandis que les autres peuvent continuer à effectuer des paiements par le chemin original sans exposer d’informations supplémentaires sur les membres restants. Cette méthode est plus efficace et plus confidentielle que les transactions non groupées.

L’opcode TLUV permet de limiter partiellement les dépenses en mettant à jour le MAST original. Cependant, il ne permet pas l’introspection des montants de sortie. Par conséquent, un nouvel opcode IN_OUT_AMOUNT est nécessaire, qui place deux données sur la pile : le montant de l’UTXO de cette entrée et le montant de la sortie correspondante. La personne qui utilise le TLUV est alors censée utiliser des opérateurs mathématiques pour vérifier si les fonds sont correctement préservés dans la clé scriptPubKey mise à jour.

L’introspection des montants de sortie ajoute une autre complexité car les montants en bitcoins sont représentés en satoshis et nécessitent jusqu’à 51 bits, mais les scripts n’autorisent que des opérations mathématiques sur 32 bits. Cela nécessite une mise à niveau des opérateurs dans le script en redéfinissant le comportement de l’opcode ou en utilisant SIGHASH_GROUP pour remplacer IN_OUT_AMOUNT.

Le TLUV devrait fournir des solutions pour les pools de pièces décentralisés de niveau 2, bien que la fiabilité en termes de modification des clés publiques de Taproot doive être confirmée.

MATT

MATT (Merkleize All The Things) vise à atteindre trois objectifs : Merkleiser l’état, Merkleiser les scripts et Merkleiser l’exécution, afin d’obtenir des contrats intelligents généraux.

Pour réaliser le MATT, les scripts de programmation de Bitcoin doivent avoir les fonctionnalités suivantes :

  1. Appliquer un script spécifique à une sortie (et leurs montants)
  2. Attacher des données à une sortie
  3. Lire les données de l’entrée actuelle (ou d’autres entrées)

Le deuxième point est crucial, car les données dynamiques permettent de calculer l’état à partir des données d’entrée fournies par l’émetteur, de simuler une machine à états et de décider de l’état suivant et des données jointes. MATT propose l’opcode OP_CHECKCONTRACTVERIFY (OP_CCV), une combinaison des opcodes OP_CHECKOUTPUTCONTRACTVERIFY et OP_CHECKINPUTCONTRACTVERIFY précédemment proposés, avec un paramètre flags supplémentaire pour spécifier la cible de l’opération.

Contrôle des quantités produites : Le moyen le plus direct est l’introspection directe. Cependant, les montants de sortie sont des nombres de 64 bits nécessitant des opérations de 64 bits, ce qui ajoute de la complexité à la mise en œuvre du script Bitcoin. CCV adopte une vérification différée similaire à OP_VAULT, en additionnant les montants d’entrée pour toutes les entrées vers la même sortie avec CCV comme limite inférieure de ce montant de sortie. La vérification est retardée jusqu’au processus de transaction et non plus pendant l’évaluation du script d’entrée.

Compte tenu de la généralité des preuves de fraude, certaines variantes des contrats MATT devraient permettre de réaliser tous les types de contrats intelligents ou de constructions de la couche 2, bien que des exigences supplémentaires (telles que l’immobilisation du capital et les délais de la période de contestation) doivent être évaluées avec précision. Des recherches supplémentaires sont nécessaires pour évaluer quelles applications sont des transactions acceptables. Par exemple, l’utilisation d’engagements cryptographiques et de mécanismes de contestation de la fraude pour simuler les fonctions OP_ZK_VERIFY, permettant de réaliser des rollups sans confiance sur Bitcoin.

Dans la pratique, les choses sont déjà en train de se passer. Johan Torås Halseth a mis en œuvre elftrace en utilisant l’opcode OP_CHECKCONTRACTVERIFY de la proposition de soft fork MATT, permettant à tous les programmes pris en charge par la compilation RISC-V d’être vérifiés sur la chaîne Bitcoin, ce qui permet de créer des ponts de vérification Bitcoin natifs pour les protocoles contractuels.

CSFS (OP_CHECKSIGFROMSTACK)

Depuis l’introduction de l’opcode APO, nous savons que OP_CHECKSIG (et les opérations connexes) est responsable de l’assemblage des transactions, du hachage et de la vérification de la signature. Cependant, le message qu’il vérifie est dérivé de la sérialisation de la transaction à l’aide de cet opcode, ce qui ne permet pas de spécifier d’autres messages. En termes simples, OP_CHECKSIG (et les opérations connexes) sert à vérifier que l’UTXO en tant qu’entrée de transaction est autorisé à être dépensé par le détenteur de la signature, protégeant ainsi la sécurité de Bitcoin.

CSFS, comme son nom l’indique, vérifie les signatures de la pile. L’opcode CSFS prend trois paramètres de la pile : une signature, un message et une clé publique, et vérifie la validité de la signature. Cela signifie que n’importe quel message peut être transmis à la pile par l’intermédiaire de données témoins et vérifié par CSFS, ce qui permet certaines innovations sur Bitcoin.

La flexibilité de CSFS lui permet de mettre en œuvre divers mécanismes tels que les signatures de paiement, la délégation d’autorité, les contrats d’oracle, les obligations de protection contre les doubles dépenses et, surtout, l’introspection des transactions. Le principe de l’introspection des transactions à l’aide de CSFS est très simple. Si le contenu de la transaction utilisé par OP_CHECKSIG est placé sur la pile par l’intermédiaire du témoin et que la même clé publique et la même signature sont utilisées pour vérifier à la fois avec CSFS et OP_CHECKSIG, si les deux réussissent, alors le contenu de tout message transmis à CSFS est le même que la transaction de dépense sérialisée (et d’autres données) implicitement utilisée par OP_CHECKSIG. Nous obtenons alors des données de transaction vérifiées sur la pile, qui peuvent être utilisées pour appliquer des restrictions à la transaction de dépense avec d’autres opcodes.

CSFS apparaît souvent avec OP_CAT parce que OP_CAT peut concaténer différents champs de la transaction pour compléter la sérialisation, ce qui permet une sélection plus précise des champs de la transaction pour l’introspection. Sans OP_CAT, le script ne peut pas recalculer les hachages à partir de données vérifiables individuellement. Il ne peut donc vérifier que si un hachage correspond à une valeur spécifique, ce qui signifie que les pièces ne peuvent être dépensées que dans le cadre d’une seule transaction spécifique.

CSFS peut réaliser des opcodes tels que CLTV, CSV, CTV, APO, et est un opcode d’introspection général, ce qui contribue également aux solutions de mise à l’échelle de la couche 2 pour Bitcoin. Son inconvénient est qu’il nécessite l’ajout d’une copie complète de la transaction signée à la pile, ce qui peut augmenter considérablement la taille des transactions qui souhaitent utiliser CSFS pour l’introspection. En revanche, les opcodes d’introspection à usage unique tels que CLTV et CSV sont les moins coûteux, mais l’ajout de chaque nouvel opcode d’introspection spécial nécessite des modifications du consensus.

TXHASH (OP_TXHASH)

OP_TXHASH est un opcode d’introspection très simple qui permet à l’opérateur de sélectionner le hachage d’un champ et de le pousser sur la pile. Plus précisément, OP_TXHASH extrait un drapeau txhash de la pile, calcule un txhash (avec drapeau) basé sur le drapeau, et pousse le hash résultant sur la pile.

En raison de la similitude entre TXHASH et CTV, les deux ont fait l’objet de nombreuses discussions au sein de la communauté.

TXHASH peut être considéré comme une amélioration générale de CTV, fournissant un modèle de transaction plus avancé qui permet aux utilisateurs de spécifier des parties de la transaction de dépense, résolvant ainsi de nombreux problèmes liés aux frais de transaction. Contrairement à d’autres opcodes de contrat, TXHASH ne nécessite pas de fournir une copie des données nécessaires dans le témoin, ce qui réduit encore les besoins de stockage. Contrairement à CTV, TXHASH n’est pas compatible avec NOP et ne peut être mis en œuvre que dans tapscript. La combinaison de TXHASH et de CSFS peut être considérée comme une alternative à CTV et APO.

En termes de construction de contrats, TXHASH est plus facile à réaliser pour les « contrats additifs » en poussant toutes les parties des données de transaction que vous souhaitez fixer sur la pile, en les hachant ensemble et en vérifiant si le résultat correspond à une valeur fixe. CTV est plus facile à réaliser en termes de « contrats soustractifs » en poussant toutes les parties des données de la transaction que vous souhaitez garder libres dans la pile. Ensuite, en utilisant OP_SHA256, à partir d’un état intermédiaire fixe, cet état intermédiaire engage le préfixe des données de hachage de la transaction. Les parties libres sont hachées dans cet état intermédiaire.

Le champ TxFieldSelector défini dans la spécification TXHASH devrait s’étendre à d’autres opcodes, tels que OP_TX.

Le BIP relatif à TXHASH est actuellement à l’état de projet sur Github et n’a pas encore reçu de numéro.

OP_CAT

OP_CAT est un opcode quelque peu mystérieux qui a été déprécié par Satoshi Nakamoto pour des raisons de sécurité. Cependant, il a récemment suscité de nombreuses discussions parmi les développeurs de Bitcoin core, devenant même un mème dans la communauté en ligne. En fin de compte, OP_CAT a été approuvé en tant que BIP-347, et beaucoup considèrent qu’il s’agit de la proposition BIP la plus susceptible d’être adoptée dans un avenir proche.

En réalité, le comportement de OP_CAT est très simple : il concatène deux éléments de la pile en un seul. Mais comment cela permet-il d’obtenir une fonctionnalité contractuelle ?

La fonction de concaténation de deux éléments correspond à une puissante structure de données cryptographiques connue sous le nom de Trie de Merkle. La construction d’une Trie de Merkle ne nécessite que des opérations de concaténation et de hachage, toutes deux disponibles dans les scripts Bitcoin. Par conséquent, avec OP_CAT, nous pouvons théoriquement vérifier les preuves de Merkle dans les scripts Bitcoin, ce qui est la méthode de vérification légère la plus courante dans les blockchains.

Comme indiqué précédemment, CSFS peut utiliser OP_CAT pour réaliser un schéma contractuel général. En fait, même sans CSFS, la structure des signatures de Schnorr permet à OP_CAT lui-même de réaliser l’introspection des transactions.

Dans une signature Schnorr, le message à signer est composé des champs suivants :

Ces champs contiennent les principaux éléments d’une transaction. En les plaçant dans scriptPubKey ou witness, et en utilisant OP_CAT et OP_SHA256, nous pouvons construire une signature Schnorr et la vérifier avec OP_CHECKSIG. Si la vérification réussit, la pile conserve les données de la transaction vérifiée, ce qui permet l’introspection de la transaction. Cela nous permet d’extraire et d' »inspecter » différentes parties de la transaction, telles que ses entrées, ses sorties, ses adresses de destination ou les montants en bitcoins impliqués.

Pour des principes cryptographiques plus détaillés, voir l’article d’Andrew Poelstra « CAT and Schnorr Tricks ».

En résumé, la flexibilité de l’OP_CAT lui permet d’imiter presque tous les opcodes contractuels, et de nombreux opcodes contractuels dépendent de sa fonctionnalité. Cela renforce considérablement sa position sur la liste de fusion. Théoriquement, avec seulement OP_CAT et les opcodes Bitcoin existants, nous pourrions construire un BTC ZK Rollup minimisant la confiance. Starknet, Chakra et d’autres partenaires de l’écosystème travaillent activement à la réalisation de ce projet.

Conclusion

Au fur et à mesure que nous explorons les différentes stratégies visant à développer Bitcoin et à améliorer sa programmabilité, il devient évident que la voie à suivre implique une combinaison d’améliorations natives, de calculs hors chaîne et de fonctionnalités de script complexes.

Sans une couche de base flexible, il est impossible de construire une deuxième couche plus flexible.

L’évolutivité des calculs hors chaîne est l’avenir, mais la programmabilité de Bitcoin doit être améliorée pour mieux prendre en charge l’évolutivité et devenir une véritable monnaie mondiale.

Cependant, l’informatique du Bitcoin diffère fondamentalement de celle de l’Ethereum. Bitcoin ne supporte que la « vérification » comme forme de calcul, alors qu’Ethereum est fondamentalement un calcul, avec la vérification comme sous-produit. Cette différence est évidente dans le fait qu’Ethereum facture des frais de gaz pour les transactions échouées, alors que Bitcoin ne le fait pas.

Les contrats sont une forme de contrats intelligents basés sur la vérification plutôt que sur le calcul. En ce qui concerne les contrats, à part quelques fondamentalistes de Satoshi, la plupart des gens pensent que les contrats sont un bon choix pour améliorer Bitcoin. Cependant, la communauté débat constamment du schéma à utiliser pour mettre en œuvre les contrats.

APO, OP_VAULT et TLUV tendent vers des applications directes. En les choisissant, on peut mettre en œuvre des applications spécifiques de manière plus économique et plus efficace. Les adeptes du Lightning Network préfèrent APO car il permet d’obtenir la symétrie LN ; si vous souhaitez créer un coffre-fort, il est préférable d’utiliser OP_VAULT ; pour construire un CoinPool, TLUV est plus privé et plus efficace. OP_CAT et TXHASH sont plus généraux, présentent moins de vulnérabilités en matière de sécurité et permettent de réaliser davantage de cas d’utilisation grâce à des combinaisons avec d’autres opcodes, bien qu’au prix d’une complexité de script potentielle. CTV et CSFS ont ajusté l’approche de traitement de la blockchain : CTV met en œuvre des sorties différées et CSFS des signatures différées. MATT est relativement unique, utilisant l’exécution optimiste et les preuves de fraude, et s’appuie sur la structure Merkle Trie pour réaliser des contrats intelligents généraux, bien qu’il nécessite encore de nouveaux opcodes pour fournir des capacités d’introspection.

Nous constatons que la communauté Bitcoin discute déjà intensément de la possibilité d’introduire des contrats par le biais d’un soft fork. Starknet a officiellement annoncé son entrée dans l’écosystème Bitcoin, prévoyant de mettre en œuvre le règlement sur le réseau Bitcoin dans les six mois suivant la fusion OP_CAT. Chakra continuera à suivre les derniers développements de l’écosystème Bitcoin, à promouvoir la fusion OP_CAT et à utiliser la programmabilité apportée par l’introspection et les contrats pour construire une couche de règlement Bitcoin plus sûre et plus efficace.

Articles similaires
↑
Quitter la version mobile