jakiro
Auteur: Jeffrey Hu & amp;
Récemment, une vague de discussions a commencé dans la communauté Bitcoin sur la réactivité d’Opcodes tels que OP_CAT.L’assistant de tapoot a également attiré beaucoup d’attention en lançant le NFT de Quantum Cats, affirmant avoir obtenu le numéro BIP-420, etc.Les supporters affirment que l’activation OP_CAT peut implémenter des « alliances », implémenter des contrats intelligents pour Bitcoin ou la programmabilité.
Si vous remarquez le terme «clause de restriction» et que vous le recherchez,Vous constaterez qu’il s’agit d’un autre gros trou de lapin.Les développeurs en discutent depuis des années,En plus d’OP_CAT, il existe également des technologies qui implémentent des restrictions telles que OP_CTV, APO, OP_VAULT.
Alors, quelles sont exactement les «termes restreints» de Bitcoin?Pourquoi peut-il attirer autant de développeurs pour poursuivre leur attention et leur discussion pendant des années?Quelle programmabilité peut être réalisée dans Bitcoin?Quel est le principe de conception derrière?Cet article donnera un aperçu de l’introduction et de la discussion.
Quelles sont les « termes restreints »
Les alliances, traduites par «clauses restreintes» en chinois, parfois traduites par «contrats», est un mécanisme qui peut définir des conditions pour les futures transactions Bitcoin.
Les scripts Bitcoin actuels contiennent également des restrictions, telles que la saisie d’une signature juridique lors des dépenses, l’envoi d’un script conforme, etc.Mais tant que l’utilisateur peut le déverrouiller, il peut dépenser l’UTXO où qu’il veut.
La clause de restriction est de faire plus de restrictions sur la façon de déverrouiller cette restriction.Par exemple, la limitation du coût après UTXO est de réaliser un effet similaire aux «fonds spéciaux et à des fins spéciales»; ou d’autres conditions d’entrée envoyées dans une transaction, etc.En dernière analyse,La clause de restriction peut limiter directement les coûts de transaction dans le script Bitcoin, atteignant ainsi des règles de transaction similaires à l’effet des contrats intelligents.
Plus rigoureusement, les scripts Bitcoin actuels ont également certaines restrictions.
Alors, pourquoi les développeurs et les chercheurs conçoivent-ils ces contrôles de limite?Parce que la clause de restriction est non seulement limitée pour le souci de limitation, mais définit également les règles d’exécution des transactions.De cette façon, l’utilisateur ne peut exécuter des transactions que selon les règles prédéfinies pour terminer le processus métier prédéterminé.
Il est donc plus contre-intuitif que cela puisse débloquer plus de scénarios d’application.
Scénarios d’application des alliances
Assurer une punition de jalonnement
L’un des exemples les plus intuitifs de restrictions est la transaction de slash de Babylon dans le processus de mise en place du bitcoin.
Le processus de mise en œuvre du bitcoin de Babylon est que les utilisateurs envoient leurs actifs BTC sur la chaîne principale à un script spécial, avec deux conditions de dépense:
· Fin heureuse:Après une certaine période de temps, l’utilisateur peut le déverrouiller avec sa propre signature, c’est-à-dire que le processus de détention est terminé.
· Mauvaise fin: Si un utilisateur commet un comportement maléfique tel que la double signature sur une chaîne POS louée par Babylon, puis via EOT eux du réseau Le rôle d’exécution force une partie des actifs à l’adresse brûlante (slash)
(Source: Bitcoin Staking: déverrouiller 21m Bitcoins pour sécuriser l’économie de la preuve de mise en place)
Faites attention à «l’envoi forcé» ici, ce qui signifie que même si l’UTXO peut être déverrouillé, l’actif ne peut pas être envoyé arbitrairement n’importe où ailleurs et ne peut être brûlé.Cela garantira que l’utilisateur diabolique ne peut d’abord pas lui transférer les actifs avec sa signature connue pour échapper à la punition.
Si cette fonction est implémentée dans les restrictions telles que OP_CTV, vous pouvez ajouter des opcodes tels que OP_CTV à la branche « Bad Ending » du script de mise en œuvre pour implémenter les restrictions.
Avant que OP_CTV ne soit activé, Babylon doit simuler la mise en œuvre de l’application des clauses restreintes via une solution de contournement, qui est mise en œuvre conjointement par le comité User +.
Contrôle de la congestion
En général,La congestion fait référence au moment où le taux de frais de manutention sur le réseau Bitcoin est très élevé, et il y a plus de transactions accumulées dans le pool de transactions attendant d’être emballée.Par conséquent, si l’utilisateur souhaite confirmer rapidement la transaction, il doit augmenter les frais de manutention.
Pour le moment, si un utilisateur doit envoyer plusieurs transactions à plusieurs bénéficiaires, il doit augmenter les frais de manutention et supporter des coûts relativement élevés.Dans le même temps, il augmentera encore le taux de frais de manutention de l’ensemble du réseau.
S’il y a des restrictions, une solution consiste à envoyer l’expéditeur.Vous pouvez d’abord vous engager dans une transaction par lots.Cette promesse peut faire croire à tous les destinataires que la transaction finale sera effectuée, et vous pouvez attendre que les frais de manutention soient bas avant d’envoyer la transaction spécifique.
Comme le montre la figure ci-dessous, lorsque la demande d’espace de bloc est élevée, les transactions deviennent très coûteuses.En utilisant OP_CHECKTEMPELIFY, un processeur de paiement de masse peut agréger tous ses paiements en une seule transaction de complexité O (1) pour confirmation.Ensuite, après un certain temps, lorsque la demande d’espace de blocs des gens diminue, les paiements peuvent être élargis de cet UTXO.
(Source: https://utxos.org/uses/scaling/)
Ce scénario est un cas d’application typique proposé par la clause de restriction d’OP_CTV.Il y a plus de cas d’application disponibles sur https://utxos.org/uses/. Pools d’exploitation minière gratuits, Vaults, limites de contrats verrouillés à temps de hachage (HTLC), etc.
Sauter
Vault est un scénario d’application largement discuté dans les applications Bitcoin, en particulier dans le domaine des clauses restreintes.Parce que les opérations quotidiennes doivent inévitablement équilibrer les besoins du stockage des fonds et de l’utilisation des fonds,Les gens espèrent qu’il y aura un type de demande de garde des coffrets forts: il peut garantir la sécurité des fonds, et même si le compte est piraté (la clé privée est divulguée), elle peut limiter l’utilisation des fonds.
Sur la base de la technologie pour mettre en œuvre des restrictions, les applications Vault peuvent être construites relativement facilement.
Prenez le plan de conception d’Op_Vault à titre d’exemple:Lorsque vous dépensez des fonds dans le coffre-fort, vous devez d’abord envoyer une transaction au lien.Cette transaction démontre l’intention de dépenser le coffre-fort, c’est-à-dire « déclencheur », et y établit les conditions:
Si tout va bien, la deuxième transaction est le retrait final.Après avoir attendu N Blocks, vous pouvez dépenser davantage les fonds n’importe où.
Si vous constatez que la transaction a été volée (ou a été contrainte lorsqu’il est attaqué par une « clé »), vous pouvez immédiatement l’envoyer à une autre adresse sécurisée avant la transaction de retrait dans N Blocks (l’utilisateur peut le garder plus en sécurité)
(Processus OP_VAULT, Source: BIP-345)
Il convient de noter queSans restrictions, une demande de coffre-fort peut également être construite, Un moyen réalisable consiste à utiliser la clé privée pour préparer la signature que vous dépensez à l’avenir, puis à détruire la clé privée.Mais il y a encore de nombreuses restrictions.Par exemple, il est nécessaire de s’assurer que cette clé privée a été détruite (similaire au processus de configuration de confiance en preuve de connaissances zéro), le montant et les frais de manutention sont déterminés à l’avance (parce que pré-signé), et donc manquent de flexibilité.
(Comparaison des processus OP_Vault et pré-signés, Source: BIP-345)
Canaux d’état plus robustes et flexibles
Il peut généralement être considéré que les canaux d’état, y compris le réseau Lightning, ont presque la même sécurité que la chaîne principale (lorsque vous garantissez que les nœuds peuvent observer le dernier état et peuvent publier normalement le dernier état du lien).Cependant, avec des restrictions en place, certaines nouvelles idées de conception de canaux d’État peuvent être plus robustes ou flexibles en plus du réseau Lightning.Parmi eux, les plus connus incluent Eltoo, Ark, etc.
Eltoo (également connu sous le nom de LN-symétrie) est l’un des exemples les plus typiques.Cette solution technique prend l’homonyme de « L2 » et propose une couche d’exécution pour le réseau Lightning, permettant à tout état de canal ultérieur de remplacer l’état précédent sans avoir besoin d’un mécanisme de punition. Nœuds de réseau Lightning.Afin d’atteindre l’effet ci-dessus, Eltoo a proposé la méthode de signature de Sighash_noinput, à savoir APO (BIP-118).
ARK vise à réduire la difficulté de la liquidité entrante et de la gestion des canaux du réseau Lightning.Il s’agit d’une forme de protocole de jointure.Semblable aux Vaults, ARK peut également être implémentée sur le réseau Bitcoin actuel; mais après avoir introduit des restrictions, ARK peut réduire le montant d’interaction requis en fonction du modèle de transaction pour obtenir une sortie unilatérale plus détournée.
Aperçu de la technologie des alliances
D’après l’application ci-dessus, nous pouvons voir que la clause de restriction des alliances ressemble plus à un effet qu’une certaine technologie, il existe donc de nombreuses façons techniques de la mettre en œuvre.S’il est classé, il peut inclure:
taper:Type général, type spécial
Méthode d’implémentation:Basé sur Opcode, basé sur la signature
Recursion:Récursif, non-réécursif
Parmi eux, la récursivité fait référence à: il y a des implémentations de restrictions, et la production de la prochaine transaction peut être limitée en limitant la prochaine transaction.
Certaines conceptions de restrictions traditionnelles comprennent:
Conception des termes restreints des clauses d’alliances
Comme on peut le voir à partir de l’introduction précédente, les scripts Bitcoin actuels limitent principalement les conditions de déverrouillage et ne limitent pas la façon dont l’UTXO sera dépensé.Pour mettre en œuvre la clause de restriction, nous devons penser à l’envers:Pourquoi le script Bitcoin actuel ne peut-il pas implémenter la clause de restriction des alliances?
La raison principale est que le script bitcoin actuel ne peut pas lire le contenu de la transaction elle-même, c’est-à-dire «l’introspection» de la transaction.
Si nous pouvons implémenter l’introspection de la transaction – vérifier quoi que ce soit sur la transaction (y compris la sortie), nous pouvons implémenter la clause de restriction.
Par conséquent, l’idée de conception de clauses restreintes se concentre principalement sur la façon d’atteindre l’introspection.
Basé sur Opcode vs basé sur la signature
L’idée la plus simple et la plus brute est d’ajouter un ou plusieurs opcodes (c’est-à-dire un opcode + plusieurs paramètres, ou plusieurs opcodes avec différentes fonctions) pour lire directement le contenu de la transaction.C’est l’idée basée sur le code d’opération.
Une autre idée est qu’au lieu de lire et de vérifier directement le contenu de la transaction elle-même dans le script, vous pouvez utiliser le hachage du contenu de la transaction – si ce hachage a été signé, alors modifiez simplement comme OP_CHECKSIG dans le script en implémentant l’inspection De cette signature, vous pouvez indirectement réaliser des clauses d’introspection et de restriction des transactions.Cette idée est basée sur la conception de la signature.Il comprend principalement APO et OP_CSFS, etc.
Apo
Sighash_anyprevout (apo) est une méthode de signature Bitcoin proposée.Le moyen le plus simple de signer est de s’engager à la fois dans l’entrée et la sortie de la transaction, mais Bitcoin a également un moyen plus flexible, à savoir Sighash, qui s’engage sélectivement à l’entrée ou à la sortie d’une transaction.
Actuellement, Sighash et ses combinaisons signent la plage d’entrée de transaction et de sortie (source « Masterring Bitcoin, 2e »
Comme le montre la figure ci-dessus, à l’exception de tout ce qui s’applique à toutes les données, la méthode de signature de aucune est de s’appliquer uniquement à toutes les entrées, pas pour les sorties;De plus, Sighash peut également être combiné et ne s’applique qu’à une entrée après la superposition du modificateur AnyonECanPay.
Le Sighash d’APO signe uniquement la sortie, pas la partie d’entrée.Cela signifie que les transactions signées par APO peuvent être jointes à tout UTXO qui remplit les conditions plus tard.
Cette flexibilité est la base théorique de l’APO pour mettre en œuvre des restrictions:
Une ou plusieurs transactions peuvent être créées à l’avance
Grâce à ces informations de transaction, une clé publique qui ne peut obtenir qu’une seule signature peut être construite.
De cette façon, tous les actifs envoyés à l’adresse de clé publique ne peuvent être dépensés que par le biais de transactions pré-créées
Il convient de noter que parce que cette clé publique n’a pas de clé privée correspondante, il est assuré que ces actifs ne peuvent être dépensés que par le biais de transactions pré-créées.Ensuite, nous pouvons spécifier où se déroulent les actifs dans ces transactions pré-créées, implémentant ainsi la clause de restriction.
Nous pouvons en outre comprendre en comparant les contrats intelligents d’Ethereum:Ce que nous pouvons réaliser grâce à des contrats intelligents, c’est que nous pouvons retirer de l’argent de l’adresse du contrat uniquement dans certaines conditions, plutôt que de le dépenser à volonté avec une signature EOA.De ce point de vue, le bitcoin peut réaliser cet effet grâce à des améliorations du mécanisme de signature.
Mais le problème dans le processus ci-dessus est qu’il y a une dépendance circulaire pendant le calcul, car vous devez connaître le contenu d’entrée pour pré-manquer et créer une transaction.
L’importance de l’apo et de la sighash_noinput pour implémenter cette méthode de signature est qu’elle peut résoudre ce problème de dépendance circulaire.
OP_CTV
OP_CHECKTEMPLATEIFIE (CTV), ou BIP-119, adopte la méthode d’amélioration de l’opcode.Il prend le hachage de validation en tant que paramètre et exige que toute transaction qui exécute l’OPCode contient un ensemble de sorties qui correspondent à cet engagement.Grâce à CTV, les utilisateurs de Bitcoin seront autorisés à limiter la façon dont ils utilisent Bitcoin.
La proposition a été initialement lancée sous le nom d’OP_CHECKOUTSHASHVEIFY (COSHV), et dès le début de la capacité de créer des transactions de contrôle de la congestion, la critique de la proposition s’est également concentrée sur les cas d’utilisation du contrôle d’incohérence qui n’étaient pas assez universels et trop spécifiques.
Dans le cas d’utilisation du contrôle de congestion mentionné ci-dessus, l’expéditeur Alice peut créer 10 sorties et hacher les 10 sorties et utiliser le résumé généré pour créer un script tapeleaf contenant COSHV.Alice peut également utiliser les clés publiques des participants pour former des clés internes de tapoot pour leur permettre de passer ensemble sans fuir le chemin du script de tapoot.
Alice donne ensuite à chaque destinataire une copie des 10 sorties afin que chacune d’elles puisse vérifier la transaction de configuration d’Alice.Lorsqu’ils veulent dépenser ce paiement plus tard, l’un ou l’autre peut créer une transaction contenant la sortie promise.
Tout au long du processus, lorsque Alice crée et envoie des transactions définies, Alice peut envoyer ces 10 copies de la sortie via des méthodes de communication asynchrones existantes telles que les disques e-mail ou cloud.Cela signifie que les destinataires n’ont pas besoin d’être en ligne ou d’interagir les uns avec les autres.
(Source: https://bitcoinops.org/en/newsletters/2019/05/29/#proposé-transaction-utput-co-co-co-co-co-
Semblable à APO, les adresses peuvent également être construites en fonction des conditions de dépense, et les « verrous » peuvent être créés de différentes manières, notamment: l’ajout d’autres clés, les verrous temporels et la logique composable.
(Source: https://twitter.com/owenkemeys/status/1741575353716326835)
Sur cette base, CTV a proposé qu’il puisse vérifier si la transaction de dépenses après le hachage correspond à la définition, c’est-à-dire utiliser les données de transaction comme clé pour ouvrir le « verrouillage ».
Nous pouvons continuer à étendre les 10 exemples de destinataire ci-dessus, et le récepteur peut en outre définir sa clé d’adresse à un TX signé mais non diffusé pour l’envoyer au lot suivant d’adresses du destinataire, et ainsi de suite, formant un illustré dans la figure ci-dessous l’arbre – structure de type.Alice peut construire un changement de solde de compte impliquant plusieurs utilisateurs en utilisant un seul espace de bloc UTXO sur la chaîne.
Source: https://twitter.com/owenkemeys/status/1741575353716326835
Et si l’une des feuilles est un canal de foudre, un stockage froid ou d’autres chemins de paiement?Ensuite, cet arbre s’étendra d’un arbre de dépenses à une seule dimension et multicouche à un arbre de dépenses multidimensionnel et multicouche, et les scénarios qu’il peut prendre en charge sera plus riche et plus flexible.
Source: https://twitter.com/owenkemeys/status/1741575353716326835
Depuis son introduction, CTV a subi un changement de renommée par rapport à COSHV en 2019, attribué BIP-119 en 2020, et l’émergence de Sapio, un langage de programmation utilisé pour créer un contrat CTV, a reçu de nombreuses discussions et mises à jour dans la communauté dans la communauté dans 22 et 23 ans, ainsi que le débat sur son plan d’activation est toujours l’une des propositions de mise à niveau de la fourche douce dont la communauté a beaucoup discutée.
OP_CAT
OP_CAT tel qu’introduit au début, il s’agit également d’une proposition de mise à niveau qui est actuellement très concernée.Bien qu’il semble simple, OP_CAT peut implémenter de nombreuses fonctions dans les scripts avec flexibilité.
L’exemple le plus direct est l’opération liée à l’arbre Merkle.L’arbre Merkle peut être compris car deux éléments sont épissés en premier, puis hachés.Actuellement, il existe des codes d’opération de hachage tels que OP_SHA256 dans le script Bitcoin, donc si vous pouvez utiliser OP_CAT pour épisser deux éléments, vous pouvez implémenter la fonction de vérification de l’arborescence Merkle dans le script, qui aura une vérification légère du client dans une certaine mesure capacité.
Une autre base de mise en œuvre comprend également des améliorations pour les signatures de Schnorr: l’état de signature des dépenses du script peut être défini sur la clé publique de l’utilisateur et l’épissage public nonce; ., vous devez utiliser le même nonce, entraînant une fuite de clé privée.Autrement dit, l’engagement envers nonce est obtenu via OP_CAT, garantissant ainsi la validité des transactions signées.
Les autres scénarios d’application d’OP_CAT comprennent: Bistream, les signatures d’arbres, les signatures de lamport résistantes aux quantités, les voûtes, etc.
OP_CAT lui-même n’est pas une nouvelle fonctionnalité, il a existé dans les premières versions de Bitcoin, mais elle a été désactivée en 2010 en raison du potentiel d’être exploitée par des attaques.Par exemple, la réutilisation d’OP_DUP et OP_CAT peut facilement faire exploser le nœud entier lors du traitement de ces scripts, reportez-vous à cette démo.
Mais le problème d’explosion de pile susmentionné sera-t-il rencontré si OP_CAT est réactivé maintenant?Étant donné que la proposition OP_CAT actuelle implique uniquement l’activation de Tapscript, qui qualifie que chaque élément de pile ne dépasse pas 520 octets, il n’y aura pas de problème d’explosion de pile précédent.Certains développeurs croient également que l’OP_CAT désactivant direct de Satoshi Nakamoto peut être trop strict.Cependant, en raison de la flexibilité de l’OP_CAT, certains scénarios d’application qui peuvent provoquer des vulnérabilités ne peuvent pas être épuisés à l’heure actuelle.
Par conséquent, la combinaison des scénarios d’application et des risques potentiels, OP_CAT a reçu beaucoup d’attention récemment et a également eu un examen des relations publiques, qui est l’une des propositions de mise à niveau les plus populaires à l’heure actuelle.
Conclusion
« L’autodiscipline apporte la liberté », comme le montre l’introduction ci-dessus,La clause de restriction peut limiter directement les coûts de transaction dans le script Bitcoin, atteignant ainsi des règles de transaction similaires à l’effet des contrats intelligents.Par rapport aux méthodes hors chaîne telles que BitVM, cette méthode de programmation peut être vérifiée plus nativement sur Bitcoin et peut également améliorer les applications sur la chaîne principale (contrôle de la congestion), les applications hors chaîne (canaux d’état) et d’autres nouveaux. (Pintion de jalonnement, etc.).
Si la technologie de mise en œuvre des clauses restreintes peut être combinée avec certaines mises à niveau sous-jacentes, elle déclenchera davantage le potentiel de programmabilité.Par exemple, la proposition récente pour l’opérateur 64 bits dans la revue peut être combinée en outre avec l’OP_TLUV proposé ou d’autres restrictions et peut être programmée en fonction du nombre de sorties de transaction de Satoshi.
Mais les restrictions peuvent également conduire à des abus ou à des lacunes imprévus, donc la communauté est plus prudente à ce sujet.De plus, la mise à niveau de la clause de restriction nécessite également des mises à niveau de la fourche souple impliquant des règles de consensus.Compte tenu de la situation où la racine de tapoot est mise à niveau, les mises à niveau liées aux clauses de restriction peuvent également prendre du temps.
