Solution programmable bitcoin Introvection et alliance Explication détaillée

Auteur: Chakra; compilation: 0xjs @ 作 作 作 作 作

Cet article est la partie III publiée par Bitcoin Expansion Series publiée par Chakra.

La première partie se réfère à l’article précédent « >Examen du schéma d’extension des natifs de Bitcoin: segwit et tapoot« ,,

La deuxième partie se réfère à l’article précédent « >Évolutivité Bitcoin: Solution Layer2 et analyse de projet connexe«  » « .

La troisième partie est cet article, comme suit:

Aperçu

Par rapport à la blockchain complète telle que Ethereum, le script Bitcoin est considéré comme extrêmement limité et ne peut effectuer que des opérations de base, et ne prend même pas en charge la multiplication et la suppression.Plus important encore, les données de la blockchain elle-même peuvent difficilement être accessibles par les scripts, entraînant de graves carences en matière de flexibilité et de programmation.Par conséquent, les gens ont travaillé dur pour laisser le script Bitcoin réaliser l’introspecture.

La province interne fait référence à la capacité des données d’inspection de script et de retenue Bitcoin.Cela permet au script de contrôler l’utilisation de fonds basés sur des détails de transaction spécifiques pour atteindre des fonctions plus complexes.À l’heure actuelle, la plupart des codes de fonctionnement Bitcoin poussent les données fournies par l’utilisateur vers la pile ou manipulent les données existantes sur la pile.Cependant, le code de fonctionnement interne peut pousser les données de transaction actuelles (telles que l’horodatage, le montant, TXID, etc.) vers la pile, afin que les dépenses UTXO puissent être plus finement contrôlées.

À partir de maintenant, il n’y a que trois codes de fonctionnement principaux dans les scripts Bitcoin pour soutenir la province: checklockTimeVify, checkSevenceVerify et Checksig, et ses variantes Checksigverify, Checksigadd, CheckMultiSig et CheckMulti.

Contrat (Covenant peut également être traduit par «restrictions»).De nombreux contrats sont obtenus par le biais du code opérationnel provincial interne.

Bitcoin a actuellement deux contrats, CSV (CheckSelenceVerify) et CLTV (Casque de temps de temps).Cela montre que la solution d’expansion du bitcoin dépend sérieusement de la province et du contrat.

Comment ajouter des conditions au transfert de jetons?Dans le domaine des crypto-monnaies, notre méthode la plus couramment utilisée consiste à réaliser par l’engagement et généralement par le hachage.Afin de prouver que les exigences de transfert sont remplies, le mécanisme de signature est également nécessaire pour vérifier.Par conséquent, il existe de nombreux ajustements aux hachages et signatures dans le contrat.

Ci-dessous, nous décrirons la proposition de code d’opération d’alliance largement discutée.

CTV (CheckTemplateify) BIP-119

CTV (CheckTemplatingVerify) est une proposition de mise à niveau de Bitcoin dans BIP-119, qui a attiré une attention généralisée de la communauté.CTV permet aux scripts de sortie de spécifier des modèles dans les transactions, notamment la nversion, Nlocktime, le hachage Scriptsig, le comptage d’entrée, le hachage de séquence, le comptage de sortie, le hachage de sortie, l’index d’entrée et d’autres champs.Ces limites de modèle sont implémentées par les promesses de hachage.Cela limite efficacement le temps, les méthodes et les quantités de la transaction future UTXO.

Il convient de noter que l’entrée TXID est exclue de ce hachage.Cette exclusion est nécessaire car dans les témoins traditionnels et d’isolement, lors de l’utilisation du type de signature Sighash_all par défaut, TXID dépend de la valeur dans ScriptPubKey.L’inclusion du TXID peut entraîner des dépendances de circulation dans les engagements de hachage et ne peut pas être construite.

La méthode interne de CTV consiste à extraire directement les informations de transaction spécifiées pour les opérations de hachage, puis à comparer l’engagement sur la pile.Cette province interne nécessite de faibles exigences pour l’espace de chaîne, mais n’a pas de flexibilité.

La base de la solution de gardien Bitcoin 2 (comme Lightning Network) est la transaction désignée.La pré-signature fait généralement référence à la génération et à la signature des transactions à l’avance, mais ne les diffuse pas avant de remplir certaines conditions.Essentiellement, CTV met en œuvre un formulaire de pré-Sign-Name plus rigoureux, publiant les promesses pré-signées sur la chaîne et limitée au modèle prédéfini.

CTV a été initialement proposé pour atténuer la congestion du bitcoin, qui peut également être appelé contrôle congestionné.Lorsque la congestion est sérieuse, CTV peut promettre plusieurs transactions futures dans une seule transaction pour éviter de diffuser plusieurs transactions pendant les heures de pointe et effectuer des transactions réelles après la relevée de la congestion.Cela peut être particulièrement utile pendant les échanges.De plus, le modèle peut être utilisé pour implémenter un coffre-fort pour éviter le piratage.Étant donné que le flux de fonds est pré-déterminé, les pirates ne peuvent pas utiliser le script CTV pour pointer UTXO à leur adresse.

CTV peut améliorer considérablement la deuxième couche de réseau.Par exemple, dans le réseau Lightning, CTV peut créer un délai d’expiration et des usines de canaux en étendant un seul UTXO à un arbre CTV.De plus, CTV prend également en charge les transactions atomiques dans le protocole ARK via ATLC.

Apo (sighash_anyprevout) bip-118

BIP-118 a introduit un nouveau type de logo de hachage de signature à Tapscript, qui vise à promouvoir une logique de dépenses plus flexible, appelée Sighash_anyprevout.APO et CTV ont de nombreuses similitudes.Lors de la résolution du cycle entre ScriptPubKeys et TXID, la méthode APO consiste à éliminer les informations d’entrée pertinentes et à signer la sortie uniquement, afin que la transaction soit autorisée à se lier dynamiquement à différents UTXO.

Logiquement, l’opération de vérification de signature OP_CHECKSIG (et ses variantes) exécutent trois fonctions:

1. Chaque partie de la transaction de dépenses d’assemblage.

2. Hachs pour eux.

3. Vérifiez si le hachage a été signé par une clé donnée.

Les détails spécifiques de la signature sont très flexibles et le logo Sighash détermine quels champs de la transaction.Selon la définition du code d’opération de signature dans BIP 342, le logo Sighash est divisé en Sighash_all, Sighash_None, Sighash_Single et SighashonEcanPay.Sighash_anyOneCanPay contrôle l’entrée, tandis que d’autres sorties de contrôle.

Sighash_all est le logo Sighash par défaut pour signer toutes les sorties;Sighash_anyonECanpay peut être défini avec les trois premiers logos de Sighash.Si Sighash_anyonECanPay est défini, seule l’entrée spécifiée est signée; sinon, toutes les entrées doivent être signées.

De toute évidence, ces logos Sighash ne peuvent pas éliminer l’impact de l’entrée, même s’il s’agit de Sighash_anyonECanpay, il doit également promettre une entrée.

Par conséquent, le BIP 118 propose Sighash_anyprevout.La signature APO n’a pas besoin d’être promise de saisir UTXO (appelé prévisionnelle), mais n’a besoin que de signer la sortie pour offrir une plus grande flexibilité pour le contrôle du bitcoin.Par des transactions pré-conformes et la création de signatures et de clés publiques correspondantes, les actifs envoyés à l’adresse de la clé publique doivent être utilisés par les transactions pré-construites pour atteindre les contrats.La flexibilité de l’APO peut également être utilisée pour la réparation des transactions;De plus, pour plusieurs portefeuilles de signature, ne pas s’appuyer sur les entrées dépensées rendra l’opération plus pratique.

En raison de l’élimination du cycle entre ScriptPubKeys et l’entrée TXID, l’APO peut exécuter la province interne en ajoutant des données de sortie au témoin, bien que cela nécessite toujours une consommation d’espace de témoin supplémentaire.

Pour les lintes telles que les réseaux de foudre et les voûtes (coffres), l’APO réduit les besoins de préservation de l’état intermédiaire et réduit considérablement les exigences de stockage et la complexité.Le cas d’utilisation le plus direct de l’APO est Eltoo.L’APO peut également être utilisé pour simuler la fonction CTV, bien qu’il oblige les personnes à stocker des transactions de signature et de pré-signature, ce qui est plus cher et plus efficace que CTV.

La principale critique de l’APO s’y concentre nécessite une nouvelle version clé, et cela ne peut pas être réalisé par une simple compatibilité arrière.De plus, le nouveau type de hachage de signature peut entraîner des risques potentiels de double paiement.Après un large éventail de discussions communautaires, APO a ajouté des signatures conventionnelles au mécanisme de signature d’origine pour atténuer les problèmes de sécurité, obtenant ainsi le code BIP-118.

OP_VAULT BIP-345

BIP-345 propose d’ajouter deux nouveaux codes de fonctionnement, OP_VAULT et OP_VAULT_RECOVER.Au cours de ce retard, les transactions effectuées avant le chemin de récupération « révèlent ».

Les utilisateurs peuvent créer un coffre-fort en créant une adresse de tapoot spécifique. peut restaurer les jetons à tout moment avant la fin.

Comment OP_VAULT implémente-t-il le retrait de retrait de blocage interrompu?OP_VAULT est implémenté en remplaçant le script OP_VAULT utilisé par un script spécifié, afin de mettre à jour efficacement la feuille unique de mât, tout en maintenant les nœuds de feuille de tapoot restants inchangés.Cette conception est similaire à TLUV, mais OP_VAULT ne prend pas en charge la mise à jour des clés internes.

En introduisant des modèles pendant la mise à jour du script, vous pouvez limiter le paiement.Le nombre de verrous de temps est spécifié par OP_VAULT.

BIP-345 est conçu pour les coffres certains délai de paiement régulier.L’appareil de l’utilisateur continuera de surveiller les dépenses de la bibliothèque d’assurance.

Le problème de coût est nécessaire pour implémenter Vault via BIP-345, en particulier pour la restauration des transactions.Les solutions possibles incluent CPFP (sous-node est payé par le nœud parent), le point d’ancrage temporaire et le nouveau logo de hachage de signature Sighash_Group.

Tluv (taplefupdatelify)

Le schéma TLUV est construit autour de la tapoot, qui vise à résoudre efficacement le problème du partage de la sortie UTXO.Le principe de guidage est que lorsque la sortie de la tapoot est utilisée, les touches internes et le mât (Tapscript Trie) peuvent être partiellement mis à jour par conversion cryptée et la structure interne de l’adresse de tapoot, comme mentionné dans le script TLUV.Cela rend possible la mise en œuvre de la fonction d’alliance.

Le concept du schéma TLUV est de créer une nouvelle adresse de tapoot en introduisant le nouveau code d’exploitation TAPLEAF_UPDATE_VERIFY.Cela peut être implémenté en effectuant les opérations suivantes ou multiples:

• Mettre à jour la clé interne

• Tail de merkle élaguée

• Supprimer le script en cours d’exécution

• Ajoutez de nouvelles étapes à la fin du chemin Merkle

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

• Spécifiez comment mettre à jour la clé publique interne.

• Spécifiez une nouvelle étape pour le chemin Merkle.

• Spécifiez le nombre d’étapes pour supprimer le script actuel et / ou pour couper le chemin Merkle.

Le code de fonctionnement TLUV calcule le scriptpubkey mis à jour et vérifie si la sortie correspondante de l’entrée actuelle est dépensée sur ce scriptpubkey.

L’inspiration de Tluv vient du concept de Coinpool.De nos jours, le bassin de fonds unis n’a besoin que de signer une transaction avant la signification à créer, mais si vous souhaitez quitter sans licence, vous devez créer une signature à double signature.TLUV permet de sortir sans permis sous licence, pas de pré-signification.Par exemple, un partenaire de groupe peut utiliser une tapoot pour construire un UTXO partagé pour rassembler ses fonds.Ils peuvent utiliser la clé de tapoot pour transférer des fonds en interne, ou ils peuvent signer conjointement pour lancer le paiement à l’extérieur.Les particuliers peuvent se retirer du pool de fonds partagé à tout moment pour supprimer leur chemin de paiement, et d’autres peuvent toujours effectuer le paiement par le biais du chemin d’origine, et la sortie de l’individu n’expose pas d’autres informations sur d’autres personnes à l’intérieur.Par rapport aux transactions non réalisées, ce modèle est plus efficace et plus privé.

Le code d’exploitation TLUV a mis en œuvre une limite de dépenses en mettant à jour le Trie de tapoot d’origine, mais il ne réalise pas une auto-introspection du montant de sortie.Par conséquent, un nouveau code d’exploitation dans_out_amount est nécessaire.Ce code de fonctionnement pousse les deux éléments à la pile: le montant UTXO et la quantité de sortie correspondante de cette entrée, puis les personnes utilisant TLUV doivent utiliser le symbole informatique mathématique pour vérifier si les fonds sont correctement conservés dans le scriptpubkey mis à jour.

Les provinces internes avec des quantités de sortie augmentent la complexité, car la quantité de satoshis doit être représentée par jusqu’à 51 chiffres, mais le script permet uniquement des opérations mathématiques à 32 chiffres.Cela nécessite de redéfinir le comportement du code de fonctionnement pour mettre à niveau l’opérateur dans le script ou utiliser le size_group pour remplacer l’IN_OUT_AMOUNT.

TLUV a le potentiel de devenir une solution au 2ème étage de la décentralisation, mais sa fiabilité de l’ajustement du Trie de la tapoot doit encore être confirmée.

Mat

Matt (Merkleize All the Thing) vise à atteindre trois objectifs: merkleiser l’état, merkleiser le script, merkleiser l’exécution, pour réaliser des contrats intelligents généraux.

• Merkleiser l’État: cela implique la construction de Merkle Trie, où chaque nœud feuille représente la valeur de hachage d’un État, tandis que Merkle Root reflète l’état global du contrat.

• Merkleiser le script: il s’agit de l’utilisation de Tapscript pour former un mât, où chaque nœud feuille représente un chemin de conversion d’état possible.

• Merkleiser la performance: la merkléisation est effectuée par le mécanisme de défi d’engagement et de fraude crypté.Pour toute fonction de calcul, les participants peuvent calculer sous la chaîne, puis après l’engagement f (x) = y.Si d’autres participants trouvent le résultat d’erreur f (x) = z, ils peuvent lancer un défi.L’arbitrage est effectué via une recherche à deux points, similaire au principe de Rollup optimiste.

L’exécution de Merkel

Afin d’atteindre Matt, le langage de script Bitcoin doit avoir les fonctions suivantes:

• La sortie obligatoire a un script spécifique (et le nombre)

• Attacher un morceau de données à la sortie

• Lire les données de l’entrée actuelle (ou une autre entrée)

Le deuxième point est important: les données dynamiques signifient que l’état peut être calculé via les données d’entrée fournies par les consommateurs, car cela permet à la machine d’état analogique de déterminer l’état suivant et les données supplémentaires.Le schéma MATT est implémenté via le code d’opération OP_CHECONTRACTRATERIFY (OP_CCV).

Montant de sortie de contrôle: La méthode la plus directe est de province directement;OP_CCV utilise une méthode de vérification de retard, telle que OP_VAULT, où la quantité d’entrée de toutes les sorties d’entrées dans le CCV est ajoutée comme limite inférieure de la quantité de sortie.Le retard est dû au fait que ce test se produit pendant la transaction, pas pendant l’entrée d’évaluation du script.

Compte tenu de l’universalité de la preuve de la fraude, certaines variantes des contrats MATT devraient être en mesure d’atteindre tous les types de contrats intelligents ou 2 couches de structures, bien que des exigences supplémentaires soient nécessaires (telles que le verrouillage des capitaux et le retard dans le défi); la transaction.Par exemple, l’utilisation d’un mécanisme de défi d’engagement et de fraude chiffré pour simuler la fonction OP_ZK_VERIFY et réaliser des rouleaux sans confiance sur Bitcoin.

Dans la pratique, des choses se sont produites.Johan Toras HalSeth uses the OP_CHECKCONTRACTRACTRACTRACTRACTRACTVERIFY operating code in the MATT soft fork proposal to achieve ELFTRACE, which allows any program that supports RISC-V compilation to verify on the Bitcoin blockchain, so that one of the contracts in the contract agreement can pass the contract through le contrat.

CSFS (OP_CHECKSIGFROMSTACK)

D’après l’introduction du code d’exploitation APO, nous avons appris que OP_CHECKSIG (et ses opérations connexes) est responsable de l’assemblage des transactions, des signatures informatiques de hachage et de vérification.Cependant, ces messages de vérification opérationnelle sont négociés par sérialisation par le code d’opération et ne sont pas autorisés à spécifier d’autres messages.En termes simples, le rôle d’OP_CHECKSIG (et de ses opérations connexes) est de vérifier si l’UTXO dépensé en tant que transaction est autorisé par le titulaire de signature à utiliser le mécanisme de signature pour protéger la sécurité de Bitcoin.

CSFS, comme son nom l’indique, est de vérifier la signature de la pile.Le code opérationnel CSFS reçoit trois paramètres de la pile: signature, message et clé publique, et vérifiez l’efficacité de la signature.Cela signifie que les gens peuvent transmettre des nouvelles à la pile et vérifier les CSF pour réaliser certaines innovations de Bitcoin.

La flexibilité des CSF leur permet de réaliser des mécanismes tels que les signatures de paiement, les dégustations d’autorisation, les contrats de contrat de prophétie, les garanties de protection contre les paiements à double et et l’auto-introspection des transactions plus importantes.Le principe de l’utilisation de CSFS pour la transaction est très simple: si le contenu de transaction utilisé par OP_CHECKSIG est poussé vers la pile par des témoins et utilise la même clé publique et les mêmes signatures pour vérifier OP_CSFS et OP_CHECKSIG, et si les deux vérifications sont passées avec succès, transmettent un Le contenu du message pour OP_CSFS est le même que les transactions de dépenses sérialisées (comme autres données) de l’utilisation cachée OP_CHECKSIG.Nous obtenons ensuite des données de transaction vérifiées sur la pile, qui peuvent être utilisées pour restreindre la transaction de dépenses à l’aide d’autres codes d’exploitation.

Les CSF apparaissent souvent avec OP_CAT, car OP_CAT peut se connecter à différents champs de transactions pour terminer la sérialisation, afin de sélectionner plus précisément les champs de transaction requis par la province.Sans OP_CAT, le script ne peut pas être calculé à partir des données qui peuvent être vérifiées séparément.

CSFS peut implémenter des codes d’exploitation tels que CLTV, CSV, CTV, APO, ce qui en fait un code d’exploitation de sauvegarde multi-fonctionnel.Par conséquent, il aide également la solution d’évolutivité du bitcoin 2.L’inconvénient est qu’il doit ajouter une copie complète de la transaction de signature à la pile, ce qui peut augmenter considérablement la taille de la transaction à l’aide de CSFS.En revanche, les frais généraux de sauvegarde du code d’exploitation de sauvegarde dans un seul objectif comme CLTV et CSV sont très petits, mais il est nécessaire d’apporter des modifications de consensus pour ajouter chaque nouveau code d’exploitation provincial intérieur spécial.

Txhash (op_txhash)

OP_TXHASH est un simple code de fonctionnement provincial interne qui permet à l’opérateur de choisir des champs spécifiques et de le pousser vers la pile.Plus précisément, OP_TXHASH fait monter un logo TxHash de la pile, calcule (étiqueter avec les balises) TXHASH, puis repoussez le hachage généré vers la pile.

En raison de la similitude de TXHASH et CTV, un grand nombre de discussions dans la communauté ont un grand nombre de discussions dans les deux.

Txhash peut être considéré comme une mise à niveau générale de CTV.Contrairement aux autres codes de fonctionnement de l’alliance, TXHASH n’a pas besoin de voir les données nécessaires dans le test, ce qui réduit encore les exigences de stockage. Utilisé comme CTV et APOS.

Du point de vue de la construction d’un contrat, Txhash est plus propice à la création d’un « contrat supplémentaire ». La valeur fixe et la correspondance de valeur fixe;Ensuite, utilisez le code d’exploitation SHA256 Rolling.La liberté est Beh de cet État moyen.

Le champ TxFieldDelector défini dans la spécification TXHASH devrait s’étendre à d’autres codes de fonctionnement, tels que OP_TX.

Le BIP lié à Txhash est actuellement en draft sur GitHub et n’a pas encore été distribué.

OP_CAT

OP_CAT est un code opérationnel mystérieux.En fin de compte, OP_CAT a été approuvé sous BIP-347, qui est appelé la proposition BIP la plus probable récemment.

En fait, le comportement d’OP_CAT est très simple: il relie deux éléments de la pile.Comment implémente-t-il la fonction d’alliance?

En fait, la capacité de connecter deux éléments correspond à une puissante structure de données cryptée: Merkle Trie.Pour construire Merkle Trie, vous n’avez qu’à connecter et des opérations de hachage, et le script Bitcoin fournit des fonctions de hachage.Par conséquent, en utilisant OP_CAT, nous pouvons théoriquement vérifier Merkle pour prouver qu’il s’agit de l’une des méthodes de vérification légère les plus courantes dans la technologie de la blockchain.

Comme mentionné précédemment, les CSF peuvent obtenir une solution d’alliance commune à l’aide d’OP_CAT.En fait, même s’il n’y a pas de CSF, OP_CAT lui-même peut réaliser la province des transactions en utilisant la structure signée par Schnorr.

Dans la signature de Schnorr, le message qui doit être signé est composé des champs suivants:

Ces champs incluent les principaux éléments de la transaction.En les mettant dans ScriptPubKey ou Témoin, et en utilisant OP_CAT Binding OP_SHA256, nous pouvons construire une signature Schnorr et utiliser OP_CHECKSIG pour la vérification.Si la vérification est passée, la pile conservera les données de transaction vérifiées pour réaliser la transaction à partir de l’introspection.Cela nous permet d’extraire et de « vérifier » chaque pièce, comme son entrée, sa sortie, son adresse cible ou son bitcoin impliqués.

En ce qui concerne la science de mot de passe spécifique, vous pouvez vous référer à l’article « Cat and Schnorr Tricks » par Andrew Poelstra.

Dans l’ensemble, la polyvalence d’OP_CAT lui permet de simuler presque tous les code de fonctionnement de l’alliance.De nombreux codes de fonctionnement de l’alliance dépendent de la fonction d’OP_CAT, qui améliore considérablement sa position dans le tableau de fusion.Théoriquement, en s’appuyant sur OP_CAT et le code d’exploitation Bitcoin existant, nous espérons construire un Rollup BTC ZK de confiance.Starknet, Chakra et d’autres partenaires écosystémiques font activement la réalisation de cet objectif.

en conclusion

Lorsque nous explorons les différentes stratégies de l’élargissement du bitcoin et de l’amélioration de sa programmation, il est évident que les routes qui avancent impliquent la fusion de l’amélioration native, du calcul de la chaîne et des fonctions de script complexes.

S’il n’y a pas de calque de base flexible, il est impossible de créer une couche à deux plus flexible.

L’expansion du calcul dans la chaîne est une tendance future, mais la programmation de Bitcoin a besoin de percées afin de mieux soutenir cette évolutivité et de devenir une véritable monnaie mondiale.

Cependant, la nature informatique sur Bitcoin est fondamentalement différente de la nature informatique d’Ethereum.Bitcoin ne prend en charge que la «vérification» en tant que formulaire informatique et ne peut pas effectuer un calcul général, et Ethereum est essentiellement le calcul.On peut voir à partir d’un point: Ethereum facture des frais de gaz aux transactions déraisonnables, tandis que le bitcoin n’est pas facturé.

Le contrat est un contrat intelligent basé sur la vérification plutôt que sur l’informatique.En plus de quelques trésor de Nakamoto, il semble que tout le monde pense que les contrats sont un bon choix pour améliorer le bitcoin.Cependant, la communauté argument toujours avec farcement quelle méthode doit être utilisée pour mettre en œuvre le contrat.

APO, OP_VAULT et TLUV sont directement appliqués.Les amateurs de Lightning Network choisiront des APO pour atteindre la symétrie LN;OP_CAT et TXHASH sont plus abondants, et la probabilité de vulnérabilités de sécurité est plus petite.CTV et CSF ont ajusté la méthode de traitement de la blockchain, CTV met en œuvre la sortie retardée et CSFS réalise les signatures retardées.Matt se démarque avec la stratégie d’exécution optimiste et d’épreuve de fraude, et utilise la structure de Trie Merkle pour réaliser des contrats intelligents généraux, mais la fonction provinciale nécessite toujours de nouveaux codes opérationnels.

Nous voyons que la communauté Bitcoin discute activement de la possibilité d’obtenir des clauses d’alliances à travers des fourches mous.Starknet a officiellement annoncé l’ajout de l’écosystème Bitcoin et prévoit de résoudre le réseau Bitcoin dans les six mois suivant la fusion de OP_CAT.Le chakra continuera de prêter attention aux derniers développements de l’écosystème Bitcoin, de promouvoir la fusion des fourchettes OP_CAT et d’utiliser la construction programmatique des alliances pour construire une couche de règlement Bitcoin plus sûre et plus sûre.