aperçu

Comparé aux blockchains complètes comme Ethereum, le scripting Bitcoin est considéré comme très restrictif, capable uniquement d'opérations de base, et il ne prend même pas en charge la multiplication et la division. Plus important encore, les données de la blockchain sont presque inaccessibles aux scripts, ce qui entraîne un manque significatif de flexibilité et de programmabilité. Il y a donc eu un effort de longue date pour permettre aux scripts Bitcoin d'atteindre une introspection.

l'introspection fait référence à la capacité des scripts Bitcoin à inspecter et contraindre les données de transaction. cela permet aux scripts de contrôler l'utilisation des fonds en fonction de détails de transaction spécifiques, permettant des fonctionnalités plus complexes. actuellement, la plupart des opcodes Bitcoin poussent des données fournies par l'utilisateur sur la pile ou manipulent des données existantes sur la pile. cependant, les opcodes d'introspection peuvent pousser des données de la transaction actuelle (comme des horodatages, des montants, des txid, etc.) sur la pile, permettant un contrôle plus granulaire sur les dépenses des UTXO.

À l'heure actuelle, seuls trois principaux opcodes dans le script Bitcoin prennent en charge l'inspection : checklocktimeverify, checksequenceverify et checksig, ainsi que ses variantes checksigverify, checksigadd, checkmultisig et checkmultisigverify.

Le covenant, simplement dit, fait référence aux restrictions sur la façon dont les pièces sont transférées, permettant aux utilisateurs de spécifier comment les utxos sont distribués. De nombreux covenants sont mis en œuvre grâce à des opcodes d'inspection, et les discussions sur l'inspection sont maintenant classées sous le thème des covenants sur.Bitcoin optech.

bitcoin a actuellement deux alliances, csv (checksequenceverify) et cltv (checklocktimeverify), toutes deux des alliances basées sur le temps qui sont fondamentales pour de nombreuses solutions de mise à l'échelle comme le réseau lightning. cela illustre comment les solutions de mise à l'échelle de bitcoin reposent fortement sur l'introspection et les alliances.

comment ajoutons-nous des conditions au transfert de pièces ? Dans la cryptosphère, notre méthode la plus courante est par le biais d'engagements, souvent mis en œuvre via des hachages. Pour prouver que les exigences de transfert sont satisfaites, des mécanismes de signature sont également nécessaires pour la vérification. Ainsi, de nombreuses adaptations de hachages et de signatures existent au sein des pactes.

ci-dessous, nous décrirons la proposition d'opcode de convention largement discutée.

ctv (checktemplateverify) bip-119

ctv (checktemplateverify) est une proposition de mise à niveau Bitcoin contenue dans bip-119 qui a suscité une attention importante de la communauté. ctv permet à la sortie de script de spécifier un modèle pour dépenser les fonds dans une transaction, y compris des champs tels que nversion, nlocktime, scriptsig hash, input count, sequences hash, output count, outputs hash, input index. Ces restrictions de modèle sont mises en œuvre via un engagement de hachage, et lorsque les fonds sont dépensés, le script vérifie si les valeurs de hachage des champs spécifiés dans la transaction de dépense correspondent aux valeurs de hachage dans le script d'entrée. Cela confine efficacement le temps, la méthode et le montant des transactions futures de cet utxo.

notamment, l'input txid est exclu de ce hash. cette exclusion est nécessaire, car dans les transactions legacy et segwit, le txid dépend des valeurs dans le scriptpubkey lors de l'utilisation du type de signature sighash_all par défaut. inclure le txid entraînerait une dépendance circulaire dans l'engagement hash, le rendant impossible à construire.

ctv implémente l'introspection en extrayant directement les informations de transaction spécifiées pour les hacher et les comparer avec l'engagement sur la pile. cette méthode d'introspection est moins exigeante en termes d'espace de chaîne mais manque de flexibilité.

La fondation des solutions de couche deux de Bitcoin telles que le réseau Lightning est constituée de transactions pré-signées. La pré-signature fait généralement référence à la génération et à la signature anticipée de transactions, mais à leur non-diffusion jusqu'à ce que certaines conditions soient remplies. Essentiellement, le CTV met en œuvre une forme plus rigoureuse de pré-signature, en postant l'engagement de pré-signature sur la chaîne, restreint au modèle prédéfini.

ctv a été initialement proposé pour soulager la congestion dans Bitcoin, ce qui peut également être appelé contrôle de la congestion. En période de forte congestion, ctv peut s'engager à effectuer plusieurs transactions futures dans une seule transaction, évitant ainsi la nécessité de diffuser plusieurs transactions pendant les périodes de pointe et de finaliser les transactions réelles une fois la congestion atténuée. Cela pourrait être particulièrement utile pendant les ruées bancaires d'échange. De plus, le modèle peut également être utilisé pour mettre en œuvre des coffres-forts afin de se protéger contre les attaques de piratage. Étant donné que la direction des fonds est prédéterminée, les pirates informatiques ne peuvent pas diriger les UTXO vers leurs propres adresses en utilisant des scripts ctv.

ctv peut considérablement améliorer les réseaux de couche deux. Par exemple, dans le réseau Lightning, ctv peut permettre la création d'arbres de temporisation et de fabriques de canaux en étendant un seul utxo dans un arbre ctv, ouvrant ainsi de multiples canaux d'état avec une seule transaction et une seule confirmation. De plus, ctv prend également en charge les échanges atomiques dans le protocole ark à travers atlc.

apo (sighash_anyprevout) bip-118

bip-118 introduit un nouveau type d'indicateur de hachage de signature pour tapscript, visant à faciliter une logique de dépense plus flexible connue sous le nom de sighash_anyprevout. apo et ctv partagent de nombreuses similitudes. lorsqu'il s'agit de résoudre le problème cyclique entre les scriptpubkeys et les txids, l'approche d'apo consiste à exclure les informations d'entrée pertinentes et à ne signer que les sorties, ce qui permet aux transactions de se lier dynamiquement à différents utxos.

logiquement, l'opération de vérification de signature op_checksig (et ses variantes) effectue trois fonctions:

1. assemblage des parties de la transaction de dépenses.
2. les hacher.
3. vérifier que le hachage a été signé par une clé donnée.

les spécificités de la signature offrent une grande flexibilité, la décision quant aux champs de transaction à signer étant déterminée par le drapeau sighash. selon la définition des opcodes de signature dans le bip 342, les drapeaux sighash sont divisés en sighash_all, sighash_none, sighash_single et sighash_anyonecanpay. sighash_anyonecanpay contrôle les entrées, tandis que les autres contrôlent les sorties.

sighash_all est le drapeau de sighash par défaut, signant toutes les sorties; sighash_none ne signe aucune sortie; sighash_single signe une sortie spécifique. sighash_anyonecanpay peut être défini avec les trois premiers drapeaux sighash. Si sighash_anyonecanpay est défini, seul l'input spécifié est signé; sinon, tous les inputs doivent être signés.

clairement, ces indicateurs de sighash n'éliminent pas l'influence des entrées, même sighash_anyonecanpay, qui nécessite de s'engager sur une seule entrée.

ainsi, bip 118 propose sighash_anyprevout. la signature apo n'a pas besoin de s'engager sur l'utxo de l'entrée dépensée (connu sous le nom de prevout) mais doit uniquement signer les sorties, offrant ainsi une plus grande flexibilité dans le contrôle du bitcoin. en pré-construisant des transactions et en créant des signatures et des clés publiques à usage unique correspondantes, les actifs envoyés à cette adresse de clé publique doivent être dépensés via la transaction pré-construite, ce qui permet de mettre en œuvre un engagement. la flexibilité de l'apo peut également être utilisée pour la réparation de transaction; 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 avoir besoin d'une nouvelle signature. de plus, pour les portefeuilles multi-signatures, le fait de ne pas dépendre des entrées dépensées rend les opérations plus pratiques.

puisque cela élimine le cycle entre les scriptpubkeys et les input txids, apo peut effectuer l'introspection en ajoutant des données de sortie dans le témoin, bien que cela nécessite toujours une consommation d'espace témoin supplémentaire.

Pour les protocoles hors chaîne tels que le réseau lightning et les coffres-forts, apo réduit la nécessité de sauvegarder des états intermédiaires, ce qui réduit considérablement les exigences de stockage et la complexité. Le cas d'utilisation le plus direct d'Apo est Eltoo, qui simplifie les usines de canaux, construit des tours de garde 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 réseau lightning de plusieurs façons. Apo peut également être utilisé pour simuler des fonctions CTV, bien qu'il nécessite aux individus de stocker des signatures et des transactions pré-signées, ce qui est plus coûteux et moins efficace que CTV.

La principale critique d'Apo porte sur son besoin d'une nouvelle version de clé, qui ne peut pas être mise en œuvre en étant simplement rétrocompatible. De plus, le nouveau type de hachage de signature peut introduire des risques potentiels de double dépense. Après de nombreuses discussions au sein de la communauté, Apo a ajouté des signatures régulières sur le mécanisme de signature original pour atténuer les préoccupations en matière de sécurité, gagnant ainsi le code bip-118.

op_vault bip-345

bip-345 propose l'ajout de deux nouveaux opcodes, op_vault et op_vault_recover, qui, combinés à ctv, implémentent un covenant spécialisé permettant aux utilisateurs d'imposer un délai de dépense de certaines pièces. Pendant ce délai, une transaction précédemment effectuée peut être "inversée" via un chemin de récupération.

Les utilisateurs peuvent créer un coffre-fort en créant une adresse taproot spécifique qui doit contenir au moins deux scripts dans son mât : un avec l'opcode op_vault pour faciliter le processus de retrait attendu, et un autre avec l'opcode op_vault_recover pour garantir que les pièces peuvent être récupérées à tout moment avant l'achèvement du retrait.

comment op_vault met-elle en œuvre des retraits verrouillés dans le temps interruptibles ? op_vault réalise cela en remplaçant le script op_vault dépensé par un script spécifié, mettant à jour efficacement une seule feuille de l'arbre principal tout en laissant le reste des nœuds feuilles taproot inchangés. cette conception est similaire à tluv, à l'exception du fait qu'op_vault ne prend pas en charge les mises à jour de la clé interne.

en introduisant un modèle lors du processus de mise à jour du script, il est possible de limiter les paiements. Le paramètre de verrouillage temporel est spécifié par op_vault, et le modèle de l'opcode ctv restreint l'ensemble des sorties qui peuvent être dépensées via ce chemin de script.

bip-345 est conçu spécifiquement pour les coffres-forts, en utilisant op_vault et op_vault_recover pour fournir aux utilisateurs une méthode de garde sécurisée qui utilise une clé hautement sécurisée (comme un portefeuille papier ou un multisig distribué) comme chemin de récupération, tout en configurant un certain délai pour les paiements réguliers. Les appareils des utilisateurs surveillent en continu les dépenses du coffre-fort, et en cas de transfert inattendu, les utilisateurs peuvent initier une récupération.

la mise en œuvre du coffre-fort via bip-345 nécessite de prendre en compte les problèmes de coûts, en particulier pour les transactions de récupération. Les solutions possibles comprennent cpfp (child pays for parent), les ancres temporaires et les nouveaux indicateurs de hachage de signature sighash_group.

tluv (tapleafupdateverify)

Le programme TLUV est construit autour de la racine pivotante et vise à résoudre efficacement le problème de la sortie des UTXO partagés. Le principe directeur est que lorsqu’une sortie de racine pivotante est dépensée, des mises à jour partielles peuvent être apportées à la clé interne et au mât (tapscript trie) par le biais de transformations cryptographiques et de la structure interne de l’adresse de racine pivotante, comme décrit par le script TLUV. Cela permet la mise en œuvre des fonctions de l’alliance.

Le concept du schéma TLUV est de créer une nouvelle adresse Taproot basée sur l'entrée de dépense actuelle en introduisant un nouvel opcode, tapleaf_update_verify. Cela peut être réalisé en effectuant une ou plusieurs des actions suivantes:

1. mettre à jour la clé publique interne
2. réduire le chemin de Merkle
3. supprimer le script actuellement en cours d'exécution
4. ajouter une nouvelle étape à la fin du chemin de Merkle

Plus précisément, tluv accepte trois entrées :

1. l'un qui spécifie comment mettre à jour la clé publique interne.
2. une qui spécifie une nouvelle étape pour le chemin de merkle.
3. un qui spécifie s'il faut supprimer le script actuel et/ou combien d'étapes du chemin de Merkle à réduire.

L'opcode tluv calcule la clé publique de script mise à jour et vérifie que la sortie correspondant à l'entrée actuelle est dépensée pour cette clé publique de script.

tluv est inspiré du concept de coinpool. Aujourd'hui, des pools communs peuvent être créés en n'utilisant que des transactions pré-signées, mais s'il faut réaliser des sorties non autorisées, il faudrait créer un nombre exponentiellement croissant de signatures. tluv permet cependant des sorties non autorisées sans aucune pré-signature. Par exemple, un groupe de partenaires pourrait utiliser taproot pour construire un utxo partagé, en regroupant leurs fonds ensemble. Ils peuvent déplacer les fonds en interne en utilisant la clé taproot ou signer conjointement pour initier des paiements à l'extérieur. Les individus peuvent sortir du pool de fonds partagé à tout moment, en supprimant leurs chemins de paiement, tandis que d'autres peuvent toujours effectuer des paiements via les chemins d'origine, et la sortie de l'individu n'expose pas d'informations supplémentaires sur les autres à l'intérieur. Ce mode est plus efficace et plus privé que les transactions non groupées.

l'opcode tluv réalise des restrictions partielles de dépenses en mettant à jour le trie taproot d'origine, mais il n'implémente pas l'inspection du montant de la sortie. Par conséquent, un nouvel opcode, in_out_amount, est également nécessaire. Cet opcode place deux éléments sur la pile : le montant de l'utxo pour cette entrée et le montant pour la sortie correspondante, puis ceux qui utilisent tluv sont censés utiliser des opérateurs mathématiques pour vérifier que les fonds sont correctement conservés dans le scriptpubkey mis à jour.

l'introspection des montants de sortie ajoute de la complexité car les montants en satoshis nécessitent jusqu'à 51 bits pour être représentés, mais les scripts ne permettent que des opérations mathématiques sur 32 bits. cela nécessite de redéfinir le comportement des opcodes pour mettre à niveau les opérateurs dans les scripts ou d'utiliser sighash_group pour remplacer in_out_amount.

tluv a un potentiel en tant que solution pour les pools de financement de couche 2 décentralisés, bien que la fiabilité de l'ajustement du trie taproot doit encore être confirmée.

matt

matt (merkleize toutes les choses) vise à atteindre trois objectifs: merkleiser l'état, merkleiser le script et merkleiser l'exécution, permettant ainsi les contrats intelligents universels.

1. merkleizing the state: cela implique la construction d'un arbre de Merkle, où chaque nœud feuille représente le hachage d'un état, avec la racine de Merkle incarnant l'état global du contrat.
2. merkleiser le script: cela fait référence à la formation d'un mât en utilisant tapscript, où chaque nœud feuille représente un chemin de transition d'état possible.
3. exécution merkleisée : l'exécution est merkleisée par le biais d'engagements cryptographiques et d'un mécanisme de défi de fraude. pour toute fonction de calcul, les participants peuvent calculer hors chaîne puis publier un engagement, f(x)=y. si d'autres participants trouvent un résultat erroné, f(x)=z, ils peuvent lancer un défi. l'arbitrage est effectué par recherche binaire, similaire au principe du rollup optimiste.

Commercialisation de l’exécution

Pour mettre en œuvre Matt, le langage de script Bitcoin doit avoir les fonctionnalités suivantes :

1. forcer une sortie à avoir un certain script (et leurs montants)
2. attacher une pièce de données à une sortie
3. lire les données de l'entrée actuelle (ou d'une autre)

le deuxième point est crucial : les données dynamiques signifient que l'état peut être calculé à travers les données d'entrée fournies par le dépensier, car cela permet de simuler une machine à états, capable de déterminer l'état suivant et les données supplémentaires. le schéma matt implémente cela à travers l'opcode op_checkcontractverify (op_ccv), une fusion des opcodes op_checkoutputcontractverify et op_checkinputcontractverify précédemment proposés, en utilisant un paramètre de drapeaux supplémentaire pour spécifier la cible de l'opération.

le contrôle sur les montants de sortie : la méthode la plus directe est l'inspection directe ; cependant, les montants de sortie sont des nombres sur 64 bits, nécessitant des calculs sur 64 bits, ce qui présente une complexité significative dans le script bitcoin. op_ccv adopte une approche de vérification différée, comme op_vault, où tous les inputs vers la même sortie avec ccv ont leurs montants d'entrée additionnés, servant de limite inférieure pour le montant de cette sortie. Le report est dû au fait que cette vérification se produit pendant le processus de transaction plutôt que pendant l'évaluation du script des inputs.

étant donné l'universalité des preuves de fraude, certaines variantes du contrat matt devraient être capables de mettre en œuvre tous les types de contrats intelligents ou de constructions de couche 2, bien que des exigences supplémentaires (telles que le verrouillage du capital et les retards de période de contestation) doivent être évaluées avec précision ; des recherches supplémentaires sont nécessaires pour évaluer quelles applications sont acceptables pour les transactions. par exemple, l'utilisation d'engagements cryptographiques et de mécanismes de contestation de fraude pour simuler la fonction op_zk_verify, permettant d'obtenir des rollups sans confiance sur Bitcoin.

En pratique, les choses se passent déjà. Johan Torås Halseth a utilisé l'opcode op_checkcontractverify de la proposition de fork soft de Matt pour mettre en œuvre elftrace, ce qui permet à n'importe quel programme prenant en charge la compilation risc-v d'être vérifié sur la blockchain Bitcoin, permettant à une partie au sein d'un protocole de contrat d'accéder aux fonds grâce à une vérification de contrat, facilitant ainsi la vérification native de Bitcoin.

csfs (op_checksigfromstack)

à partir de l'introduction du code opcode apo, nous avons appris que op_checksig (et ses opérations connexes) sont responsables de l'assemblage des transactions, du hachage et de la vérification des signatures. cependant, le message vérifié par ces opérations est dérivé de la sérialisation de la transaction à l'aide du code opcode, et il n'autorise pas la spécification d'un autre message. en termes simples, op_checksig (et ses opérations connexes) servent à vérifier via le mécanisme de signature si l'utxo dépensé en tant qu'entrée de transaction a été 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 la signature à partir de la pile. L'opcode csfs reçoit 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 les gens peuvent passer n'importe quel message à la pile grâce au témoin et le vérifier grâce à csfs, ce qui permet certaines innovations sur Bitcoin.

La flexibilité des CSFS lui permet de mettre en œuvre des mécanismes tels que des signatures de paiement, une délégation d'autorisation, des contrats d'oracle, des obligations de protection contre les doubles dépenses et, plus important encore, une introspection de transaction. Le principe d'utilisation des CSFS pour l'introspection de transaction est assez simple : si le contenu de la transaction utilisé par op_checksig est poussé dans la pile à travers le témoin, et si la même clé publique et la même signature sont utilisées pour vérifier à la fois avec op_csfs et op_checksig, et si les deux vérifications réussissent, alors le contenu du message arbitraire passé à op_csfs est identique à la transaction de dépense sérialisée (et autres données) implicitement utilisée par op_checksig. Nous obtenons ensuite les données de transaction vérifiées dans la pile, qui peuvent être utilisées pour appliquer des restrictions aux transactions de dépense avec d'autres opcodes.

csfs apparaît souvent avec op_cat car op_cat peut connecter différents champs de la transaction pour effectuer une sérialisation complète, permettant une sélection plus précise des champs de transaction nécessaires pour l'introspection. sans op_cat, le script ne peut pas recalculer le hachage à partir de données qui peuvent être vérifiées séparément, donc ce qu'il peut vraiment faire est de vérifier si le hachage correspond à une valeur spécifique, ce qui signifie que les pièces ne peuvent être dépensées que par le biais d'une seule transaction spécifique.

csfs peut implémenter des opcodes tels que cltv, csv, ctv, apo, etc., ce qui en fait un opcode polyvalent d'introspection. Ainsi, il contribue également aux solutions de mise à l'échelle pour la couche 2 de Bitcoin. L'inconvénient est qu'il nécessite l'ajout d'une copie complète de la transaction signée sur la pile, ce qui peut augmenter considérablement la taille des transactions destinées à l'introspection à l'aide de csfs. En revanche, les opcodes d'introspection à usage unique tels que cltv et csv ont un surcoût minimal, mais l'ajout de chaque nouvel opcode d'introspection spécial nécessite des modifications de consensus.

txhash (op_txhash)

op_txhash est un code opérationnel activé pour l'introspection qui permet à l'opérateur de sélectionner et de pousser le hachage d'un champ spécifique sur la pile. Plus précisément, op_txhash fait sortir un drapeau de hachage de la pile et calcule un hachage (balisé) basé sur ce drapeau, puis pousse le hachage résultant de nouveau sur la pile.

En raison des similitudes entre txhash et ctv, une quantité considérable de discussions a eu lieu au sein de la communauté concernant les deux.

txhash peut être considéré comme une mise à niveau universelle de ctv, offrant un modèle de transaction plus avancé qui permet aux utilisateurs de spécifier explicitement certaines parties d'une transaction de dépense, résolvant de nombreux problèmes liés aux frais de transaction. Contrairement aux autres codes d'opération de covenant, txhash ne nécessite pas de copie des données nécessaires dans le témoin, réduisant ainsi davantage les besoins de stockage ; contrairement à ctv, txhash n'est pas compatible avec nop et ne peut être implémenté que dans tapscript ; la combinaison de txhash et csfs peut servir d'alternative à ctv et apo.

du point de vue de la construction des pactes, txhash est plus propice à la création de « pactes additifs », où toutes les parties des données de transaction que vous souhaitez fixer sont poussées sur la pile, hashées ensemble, et le hash résultant est vérifié pour correspondre à une valeur fixe; ctv est plus adapté à la création de « pactes soustractifs », où toutes les parties des données de transaction que vous souhaitez conserver libres sont poussées sur la pile. ensuite, en utilisant un opcode de hachage sha256 roulant, le hachage commence à partir d'un état intermédiaire fixe qui s'engage à un préfixe des données de hachage de transaction. les parties libres sont hashées dans cet état intermédiaire.

le champ txfieldselector défini dans la spécification txhash devrait être étendu à d'autres opcodes, tels que op_tx.

le bip lié à txhash est actuellement en statut de brouillon sur github et n'a pas encore été attribué à un numéro.

op_cat

op_cat est un code opération enveloppé de mystère, initialement abandonné par Satoshi Nakamoto en raison de problèmes de sécurité, il a récemment suscité une discussion intense parmi les développeurs principaux de Bitcoin et a même stimulé la culture des mèmes sur Internet. Finalement, op_cat a été approuvé dans le cadre de bip-347 et a été qualifié de proposition bip la plus susceptible de passer récemment.

en fait, le comportement de op_cat est assez simple: il concatène deux éléments de la pile. comment cela permet-il la fonctionnalité du contrat?

En effet, la capacité de concaténer deux éléments correspond à une structure de données cryptographiques puissante: l'arbre de Merkle. Pour construire un arbre de Merkle, seules les opérations de concaténation et de hachage sont nécessaires, et les fonctions de hachage sont disponibles dans les scripts Bitcoin. Ainsi, avec op_cat, nous pouvons théoriquement vérifier des preuves de Merkle dans les scripts Bitcoin, ce qui est l'une des méthodes de vérification légère les plus courantes dans la technologie blockchain.

comme mentionné précédemment, csfs, avec l'aide de op_cat, peut mettre en œuvre un schéma de convention universelle. En fait, sans csfs, en tirant parti de la structure des signatures schnorr, op_cat lui-même peut réaliser l'inspection des transactions.

dans les signatures schnorr, le message qui doit être signé est composé des champs suivants:

ces champs contiennent les principaux éléments d'une transaction. en les plaçant dans le scriptpubkey ou le témoin et en utilisant op_cat combiné avec op_sha256, nous pouvons construire une signature schnorr et la vérifier en utilisant op_checksig. si la vérification réussit, la pile conserve les données de transaction vérifiées, ce qui permet une introspection de transaction. cela nous permet d'extraire et de «vérifier» diverses parties de la transaction, telles que ses entrées, sorties, adresses cibles ou les montants de bitcoins impliqués.

pour des principes cryptographiques spécifiques, on pourrait se référer à l'article d'andrew poelstra, "cat and schnorr tricks".

en résumé, la polyvalence de op_cat lui permet d'émuler presque n'importe quel opcode de covenant. une multitude d'opcodes de covenant reposent sur la fonctionnalité de op_cat, ce qui avance considérablement sa position sur la liste de fusion. théoriquement, en ne comptant que sur op_cat et les opcodes bitcoin existants, nous espérons construire un btc zk rollup avec une confiance minimale. starknet, chakra et d'autres partenaires de l'écosystème poussent activement pour que cela se produise.

conclusion

alors que nous explorons les diverses stratégies pour mettre à l'échelle Bitcoin et améliorer sa programmabilité, il devient clair que le chemin à suivre implique un mélange d'améliorations natives, de calculs hors chaîne et de capacités de script sophistiquées.

sans une couche de base flexible, il est impossible de construire une couche supérieure plus flexible.

L'évolutivité de la computation hors chaîne est l'avenir, mais la programmabilité du bitcoin doit évoluer pour mieux prendre en charge cette évolutivité et devenir une véritable monnaie mondiale.

Cependant, la nature du calcul sur Bitcoin est fondamentalement différente de celle sur Ethereum. Bitcoin ne prend en charge que la « vérification » en tant que forme de calcul et ne peut pas effectuer de calculs généraux, tandis qu'Ethereum est intrinsèquement computationnel, la vérification étant un produit dérivé du calcul. Cette différence est évidente à partir d'un point : Ethereum facture des frais de gaz pour les transactions qui ne parviennent pas à s'exécuter, tandis que Bitcoin ne le fait pas.

Les covenants représentent une forme de contrat intelligent basé sur la vérification plutôt que sur le calcul. À l’exception de quelques fondamentalismes Satoshi, il semble que tout le monde considère les covenants comme un bon choix pour améliorer le Bitcoin. Cependant, la communauté continue de débattre âprement de l’approche à adopter pour mettre en œuvre les engagements.

apo, op_vault et tluv penchent vers des applications directes, et les choisir peut permettre d'atteindre des applications spécifiques de manière moins coûteuse et plus efficace. Les passionnés du réseau lightning préféreraient apo pour atteindre la ln-symétrie ; ceux qui cherchent à implémenter un coffre-fort seraient mieux servis par op_vault ; pour construire un coinpool, tluv offre plus de confidentialité et d'efficacité. op_cat et txhash sont plus polyvalents, avec une probabilité plus faible de vulnérabilités de sécurité, et peuvent implémenter plus de cas d'utilisation lorsqu'ils sont combinés avec d'autres opcodes, peut-être au détriment de la complexité du script. ctv et csfs ont ajusté le traitement de la blockchain, ctv implémentant des sorties différées et csfs implémentant des signatures différées. matt se distingue par sa stratégie d'exécution optimiste et de preuves de fraude, utilisant la structure de l'arbre de Merkle pour implémenter des contrats intelligents universels, bien qu'il nécessite toujours de nouveaux opcodes pour les capacités introspectives.

nous voyons que la communauté bitcoin discute activement de la possibilité d'obtenir des alliances grâce à une bifurcation douce. Starknet a officiellement annoncé son entrée dans l'écosystème bitcoin, prévoyant de mettre en place des règlements sur le réseau bitcoin dans les six mois suivant la fusion de op_cat. Chakra continuera de surveiller les derniers développements dans l'écosystème bitcoin, poussera à la fusion de la bifurcation douce op_cat et tirera parti de la programmabilité apportée par les alliances pour construire une couche de règlement bitcoin plus sécurisée et efficace.

disclaimer：

1. Cet article est repris de [ Miroir]. tous les droits d'auteur appartiennent à l'auteur original [ chakra]. s'il y a des objections à cette réimpression, veuillez contacter le Porte apprendreéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité: les vues et opinions exprimées dans cet article sont uniquement celles de l'auteur et ne constituent pas des conseils en investissement.
3. les traductions de l'article dans d'autres langues sont réalisées par l'équipe d'apprentissage de Gate.io. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.