Détails des clauses restrictives : réaliser la Programmabilité du Bitcoin
Récemment, la communauté Bitcoin a suscité une discussion sur la réactivation des opcodes tels que OP_CAT. Taproot Wizard a attiré l'attention de nombreuses personnes en lançant Quantum Cats NFT et en affirmant avoir obtenu le numéro BIP-420. Les partisans affirment que l'activation d'OP_CAT pourrait permettre des "clauses restrictives", rendant ainsi possible les contrats intelligents ou la Programmabilité de Bitcoin.
Si vous remarquez le terme "clause de limitation" et que vous faites une petite recherche, vous découvrirez que c'est un autre grand terrier de lapin. Les développeurs en ont discuté pendant des années, en plus de OP_CAT, il existe des technologies telles que OP_CTV, APO, OP_VAULT pour mettre en œuvre des clauses de limitation.
Alors, qu'est-ce que la "clause de limitation" du Bitcoin ? Pourquoi attire-t-elle tant de développeurs depuis des années, suscitant ainsi l'attention et le débat ? Quelle Programmabilité du Bitcoin peut-elle réaliser ? Quels sont les principes de conception sous-jacents ? Cet article propose une introduction et une discussion générales.
Qu'est-ce que les "clauses restrictives"
Restrictions ( Les engagements ) sont un mécanisme qui permet de définir des conditions pour les transactions Bitcoin futures.
Le script Bitcoin actuel contient également des conditions restrictives, telles que la nécessité de fournir une signature valide lors de la dépense, d'envoyer à un script approprié, etc. Cependant, tant que l'utilisateur peut déverrouiller, il peut dépenser ce UTXO où il le souhaite.
Les clauses restrictives sont, sur la base de cette restriction sur la façon de déverrouiller, d'imposer plus de restrictions, par exemple limiter les dépenses après UTXO, ce qui réalise un effet similaire à "fonds affectés" ; ou d'autres conditions d'entrée à envoyer dans une transaction, etc.
Pour être plus précis, le script Bitcoin actuel présente également certaines clauses restrictives, telles que le verrouillage temporel basé sur les codes d'opération, qui est réalisé par les champs nLock ou nSequence de la transaction introspective pour imposer une limite de temps avant la dépense de la transaction, mais cela est essentiellement limité aux restrictions temporelles.
Alors, pourquoi les développeurs et les chercheurs conçoivent-ils ces vérifications de limites ? Parce que les clauses de limite ne sont pas seulement là pour restreindre, mais elles établissent également les règles d'exécution des transactions. Ainsi, les utilisateurs ne peuvent exécuter des transactions que selon les règles prédéfinies, complétant ainsi le processus commercial prévu.
Donc, c'est assez contre-intuitif, mais cela peut débloquer plus de cas d'application.
Scénarios d'application
Assurez-vous de la pénalité de Staking
Un exemple très intuitif de clause de restriction est la transaction de slash de Babylon dans le processus de staking Bitcoin.
Le processus de staking Bitcoin de Babylon consiste à ce que les utilisateurs envoient leurs actifs BTC dans un script spécial sur la chaîne principale, les conditions de dépense comprennent deux types :
Situation normale : après un certain temps, l'utilisateur peut déverrouiller avec sa propre signature, complétant ainsi le processus de désengagement.
Situation exceptionnelle : Si un utilisateur commet des actes malveillants tels que la double signature sur une chaîne PoS louée pour sa sécurité par Babylon, alors grâce aux EOTS(signatures uniques extractibles, une fois signées, il est possible de déverrouiller cette partie des actifs, et un rôle d'exécution dans le réseau forcera l'envoi d'une partie des actifs à l'adresse de brûlage)slash(.
Notez ici le "envoi forcé", cela signifie que même si ce UTXO peut être débloqué, cet actif ne peut pas être envoyé arbitrairement ailleurs, il ne peut être que brûlé. Cela garantit que les utilisateurs malveillants ne peuvent pas utiliser leur propre signature connue pour renvoyer l'actif à eux-mêmes afin d'échapper à la punition.
Cette fonctionnalité, une fois que les clauses restrictives telles que OP_CTV seront mises en œuvre, pourra ajouter des opcodes tels que OP_CTV dans la branche "situations exceptionnelles" du script de staking afin de mettre en place des restrictions.
Avant l'activation de OP_CTV, Babylon doit simuler l'effet de l'exécution forcée des clauses restrictives par des moyens détournés, par le biais d'une exécution conjointe par les utilisateurs et le comité.
![Détails sur les Covenants : comment réaliser la Programmabilité du Bitcoin ?])https://img-cdn.gateio.im/webp-social/moments-409951d98817702c2c2c9185b417ff9e.webp(
) Contrôle de la congestion
En général, la congestion fait référence à une situation où les frais de transaction sur le réseau Bitcoin sont très élevés et qu'un nombre important de transactions s'accumulent dans la mempool en attente d'être confirmées. Ainsi, si un utilisateur souhaite faire confirmer une transaction rapidement, il doit augmenter les frais de transaction.
Et à ce moment-là, si un utilisateur doit envoyer plusieurs transactions à plusieurs bénéficiaires, il doit augmenter les frais de transaction, supportant des coûts relativement élevés. Cela va également augmenter davantage le taux de frais de l'ensemble du réseau.
Si des clauses restrictives sont en place, une solution consiste à ce que l'expéditeur s'engage d'abord sur une transaction de lot. Cet engagement peut rassurer tous les destinataires que la transaction finale sera effectuée, et il est possible d'attendre que les frais de transaction soient bas avant d'envoyer la transaction concrète.
Lorsque la demande pour l'espace de bloc est très élevée, effectuer des transactions devient très coûteux. En utilisant OP_CHECKTEMPLATEVERIFY, les processeurs de paiement en gros peuvent agréger tous leurs paiements en une seule transaction O###1( pour confirmation. Ensuite, après un certain temps, lorsque la demande pour l'espace de bloc diminue, les paiements peuvent être étendus à partir de ce UTXO.
Ce scénario est un cas d'application typique proposé par la clause de restriction OP_CTV.
) coffre-fort
Le coffre-fort ###vault( est un type de scénario d'application largement discuté dans les applications Bitcoin, en particulier dans le domaine des conditions restrictives. En raison de la nécessité inévitable d'équilibrer entre la garde des fonds et les besoins d'utilisation des fonds dans les opérations quotidiennes, les gens souhaitent avoir un type d'application de coffre-fort : capable de garantir la sécurité des fonds, et même si le compte est piraté ) et que la clé privée ( est divulguée, cela peut limiter l'utilisation des fonds.
Les applications de type coffre-fort peuvent être relativement faciles à construire sur la base de la technologie qui réalise des clauses de restriction.
Prenons l'exemple du schéma de conception d'OP_VAULT : lors de la dépense des fonds dans le coffre-fort, il est nécessaire d'envoyer d'abord une transaction sur la chaîne. Cette transaction indique l'intention de dépenser le coffre-fort, c'est-à-dire "trigger", et y établit des conditions :
Si tout se passe bien, alors la deuxième transaction est la transaction de retrait finale. Après avoir attendu N blocs, les fonds peuvent être dépensés ailleurs.
Si vous découvrez que cette transaction a été volée ) ou a été contrainte par une "attaque par clé à molette" avec (, vous pouvez immédiatement l'envoyer à une autre adresse sécurisée ) avant que la transaction de retrait dans N blocs ne soit envoyée, pour que ( soit conservé en toute sécurité.
Il convient de noter qu'il est également possible de construire une application de garde sans clauses restrictives. Une méthode viable consiste à préparer des signatures pour des dépenses futures avec une clé privée, puis à détruire cette clé privée. Cependant, il existe encore de nombreuses restrictions, par exemple, il est nécessaire de s'assurer que cette clé privée a été détruite ), semblable au processus de configuration de confiance dans la preuve à connaissance nulle (, le montant et les frais doivent être déterminés à l'avance ) en raison de la pré-signature (, ce qui entraîne un manque de flexibilité, etc.
![Détails sur les Covenants : comment réaliser la Programmabilité de Bitcoin ?])https://img-cdn.gateio.im/webp-social/moments-163ceda005acef4c7986cd940c4f0945.webp(
) un canal d'état plus robuste et flexible
On peut généralement considérer que les canaux d'état, y compris le réseau Lightning, possèdent une sécurité presque équivalente à celle de la chaîne principale ###, à condition que les nœuds puissent observer l'état le plus récent et publier normalement l'état le plus récent sur la chaîne (. Cependant, avec l'ajout de clauses restrictives, certaines nouvelles conceptions de canaux d'état peuvent être plus robustes ou flexibles au-dessus du réseau Lightning. Parmi les plus connus, on trouve Eltoo, Ark, etc.
Eltoo ), également connu sous le nom de LN-Symmetry(, est un exemple typique. Cette solution technique tire son homophonie de "L2" et propose une couche d'exécution pour le réseau Lightning, permettant à tout état de canal ultérieur de remplacer un état précédent sans avoir besoin de mécanisme de punition, évitant ainsi également d'avoir à conserver plusieurs états précédents comme le font certains nœuds du réseau Lightning pour prévenir les comportements malveillants. Pour réaliser cet effet, Eltoo a proposé la méthode de signature SIGHASH_NOINPUT, à savoir APO)BIP-118(.
Ark vise à réduire la difficulté liée à la liquidité entrante du réseau Lightning et à la gestion des canaux. Il s'agit d'un protocole sous forme de joinpool, où plusieurs utilisateurs peuvent accepter un fournisseur de services comme contrepartie pendant une certaine période, effectuant des transactions de UTXO)vUTXO( hors chaîne, tout en partageant un UTXO sur la chaîne pour réduire les coûts. Semblable à un coffre-fort, Ark peut également être mis en œuvre sur le réseau Bitcoin actuel ; mais après l'introduction de clauses restrictives, Ark peut réduire la quantité d'interactions nécessaires basée sur des modèles de transactions, réalisant ainsi un retrait unilatéral plus décentralisé.
![Explication des Covenants : Comment réaliser la Programmabilité de Bitcoin ?])https://img-cdn.gateio.im/webp-social/moments-bf8295d231f632f2f6303d826e3e450b.webp(
Aperçu technique des conditions restrictives
D'après les applications ci-dessus, les clauses restrictives ressemblent davantage à un effet qu'à une certaine technologie, il existe donc de nombreuses manières techniques de les mettre en œuvre. Si l'on devait les classer, cela pourrait inclure :
Type : Générique, Spécifique
Méthode de mise en œuvre : basée sur l'Opcode, basée sur la signature
Récursif : Récursion, non récursif
Parmi ceux-ci, la récursivité fait référence à : la mise en œuvre de certaines clauses restrictives qui peuvent également limiter la sortie de la transaction suivante pour restreindre la sortie de la transaction suivante, permettant ainsi d'ajouter des restrictions qui peuvent dépasser une seule transaction, atteignant une profondeur de transaction plus élevée.
Certaines conceptions de clauses restrictives courantes comprennent :
OP_CTV : type général, basé sur Opcode, non récursif
OP_VAULT: type spécialisé, basé sur Opcode, non récursif
APO: Type universel, basé sur la signature, non récursif
OP_CAT: type générique, basé sur Opcode, récursif*
OP_CSFS: type général, basé sur la signature, récursif
*Si combiné avec OP_CAT
![Détails des Covenants : Comment réaliser la Programmabilité de Bitcoin ?])https://img-cdn.gateio.im/webp-social/moments-1344dbfaff294b02ebc0017e31d2a81d.webp(
Conception des clauses restrictives
D'après l'introduction précédente, on peut voir que le script Bitcoin actuel limite principalement les conditions de déverrouillage, sans restreindre comment ce UTXO peut être dépensé ultérieurement. Pour réaliser des clauses restrictives, nous devons réfléchir à l'envers : pourquoi le script Bitcoin actuel ne peut-il pas mettre en œuvre des clauses restrictives ?
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 réaliser l'introspection des transactions - examiner n'importe quel contenu des transactions (, y compris les sorties ), alors les clauses restrictives pourraient être mises en œuvre.
Ainsi, la conception des clauses restrictives tourne principalement autour de la manière d'implémenter l'introspection.
( basé sur le code d'opération vs basé sur la signature
L'idée la plus simple et brutale est d'ajouter un ou plusieurs codes d'opération ), c'est-à-dire un code d'opération + plusieurs paramètres, ou plusieurs codes d'opération fonctionnels différents ###, pour lire directement le contenu de la transaction. Cela repose également sur l'idée basée sur les codes d'opération.
Une autre approche consiste à ne pas lire et vérifier directement le contenu de la transaction dans le script, mais plutôt à utiliser le hachage du contenu de la transaction. Si ce hachage a déjà été signé, il suffit de modifier le script, par exemple avec OP_CHECKSIG, pour réaliser la vérification de cette signature, ce qui permet d'implémenter indirectement l'introspection de la transaction et les clauses de restriction. Cette approche est basée sur la conception par signature. Elle comprend principalement APO et OP_CSFS, etc.
( APO
SIGHASH_ANYPREVOUT)APO### est un type de signature Bitcoin proposé. La manière la plus simple de signer est de s'engager sur les entrées et sorties de la transaction, mais Bitcoin offre également des méthodes plus flexibles, à savoir SIGHASH, qui permet de s'engager de manière sélective sur les entrées ou sorties d'une transaction.
et le SIGHASH d'APO ne signe que la sortie, sans signer la partie d'entrée. Cela signifie donc que les transactions signées avec la méthode APO peuvent être dans
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Détails des clauses restrictives de Bitcoin : ouverture d'une nouvelle ère de Programmabilité
Détails des clauses restrictives : réaliser la Programmabilité du Bitcoin
Récemment, la communauté Bitcoin a suscité une discussion sur la réactivation des opcodes tels que OP_CAT. Taproot Wizard a attiré l'attention de nombreuses personnes en lançant Quantum Cats NFT et en affirmant avoir obtenu le numéro BIP-420. Les partisans affirment que l'activation d'OP_CAT pourrait permettre des "clauses restrictives", rendant ainsi possible les contrats intelligents ou la Programmabilité de Bitcoin.
Si vous remarquez le terme "clause de limitation" et que vous faites une petite recherche, vous découvrirez que c'est un autre grand terrier de lapin. Les développeurs en ont discuté pendant des années, en plus de OP_CAT, il existe des technologies telles que OP_CTV, APO, OP_VAULT pour mettre en œuvre des clauses de limitation.
Alors, qu'est-ce que la "clause de limitation" du Bitcoin ? Pourquoi attire-t-elle tant de développeurs depuis des années, suscitant ainsi l'attention et le débat ? Quelle Programmabilité du Bitcoin peut-elle réaliser ? Quels sont les principes de conception sous-jacents ? Cet article propose une introduction et une discussion générales.
Qu'est-ce que les "clauses restrictives"
Restrictions ( Les engagements ) sont un mécanisme qui permet de définir des conditions pour les transactions Bitcoin futures.
Le script Bitcoin actuel contient également des conditions restrictives, telles que la nécessité de fournir une signature valide lors de la dépense, d'envoyer à un script approprié, etc. Cependant, tant que l'utilisateur peut déverrouiller, il peut dépenser ce UTXO où il le souhaite.
Les clauses restrictives sont, sur la base de cette restriction sur la façon de déverrouiller, d'imposer plus de restrictions, par exemple limiter les dépenses après UTXO, ce qui réalise un effet similaire à "fonds affectés" ; ou d'autres conditions d'entrée à envoyer dans une transaction, etc.
Pour être plus précis, le script Bitcoin actuel présente également certaines clauses restrictives, telles que le verrouillage temporel basé sur les codes d'opération, qui est réalisé par les champs nLock ou nSequence de la transaction introspective pour imposer une limite de temps avant la dépense de la transaction, mais cela est essentiellement limité aux restrictions temporelles.
Alors, pourquoi les développeurs et les chercheurs conçoivent-ils ces vérifications de limites ? Parce que les clauses de limite ne sont pas seulement là pour restreindre, mais elles établissent également les règles d'exécution des transactions. Ainsi, les utilisateurs ne peuvent exécuter des transactions que selon les règles prédéfinies, complétant ainsi le processus commercial prévu.
Donc, c'est assez contre-intuitif, mais cela peut débloquer plus de cas d'application.
Scénarios d'application
Assurez-vous de la pénalité de Staking
Un exemple très intuitif de clause de restriction est la transaction de slash de Babylon dans le processus de staking Bitcoin.
Le processus de staking Bitcoin de Babylon consiste à ce que les utilisateurs envoient leurs actifs BTC dans un script spécial sur la chaîne principale, les conditions de dépense comprennent deux types :
Notez ici le "envoi forcé", cela signifie que même si ce UTXO peut être débloqué, cet actif ne peut pas être envoyé arbitrairement ailleurs, il ne peut être que brûlé. Cela garantit que les utilisateurs malveillants ne peuvent pas utiliser leur propre signature connue pour renvoyer l'actif à eux-mêmes afin d'échapper à la punition.
Cette fonctionnalité, une fois que les clauses restrictives telles que OP_CTV seront mises en œuvre, pourra ajouter des opcodes tels que OP_CTV dans la branche "situations exceptionnelles" du script de staking afin de mettre en place des restrictions.
Avant l'activation de OP_CTV, Babylon doit simuler l'effet de l'exécution forcée des clauses restrictives par des moyens détournés, par le biais d'une exécution conjointe par les utilisateurs et le comité.
![Détails sur les Covenants : comment réaliser la Programmabilité du Bitcoin ?])https://img-cdn.gateio.im/webp-social/moments-409951d98817702c2c2c9185b417ff9e.webp(
) Contrôle de la congestion
En général, la congestion fait référence à une situation où les frais de transaction sur le réseau Bitcoin sont très élevés et qu'un nombre important de transactions s'accumulent dans la mempool en attente d'être confirmées. Ainsi, si un utilisateur souhaite faire confirmer une transaction rapidement, il doit augmenter les frais de transaction.
Et à ce moment-là, si un utilisateur doit envoyer plusieurs transactions à plusieurs bénéficiaires, il doit augmenter les frais de transaction, supportant des coûts relativement élevés. Cela va également augmenter davantage le taux de frais de l'ensemble du réseau.
Si des clauses restrictives sont en place, une solution consiste à ce que l'expéditeur s'engage d'abord sur une transaction de lot. Cet engagement peut rassurer tous les destinataires que la transaction finale sera effectuée, et il est possible d'attendre que les frais de transaction soient bas avant d'envoyer la transaction concrète.
Lorsque la demande pour l'espace de bloc est très élevée, effectuer des transactions devient très coûteux. En utilisant OP_CHECKTEMPLATEVERIFY, les processeurs de paiement en gros peuvent agréger tous leurs paiements en une seule transaction O###1( pour confirmation. Ensuite, après un certain temps, lorsque la demande pour l'espace de bloc diminue, les paiements peuvent être étendus à partir de ce UTXO.
Ce scénario est un cas d'application typique proposé par la clause de restriction OP_CTV.
) coffre-fort
Le coffre-fort ###vault( est un type de scénario d'application largement discuté dans les applications Bitcoin, en particulier dans le domaine des conditions restrictives. En raison de la nécessité inévitable d'équilibrer entre la garde des fonds et les besoins d'utilisation des fonds dans les opérations quotidiennes, les gens souhaitent avoir un type d'application de coffre-fort : capable de garantir la sécurité des fonds, et même si le compte est piraté ) et que la clé privée ( est divulguée, cela peut limiter l'utilisation des fonds.
Les applications de type coffre-fort peuvent être relativement faciles à construire sur la base de la technologie qui réalise des clauses de restriction.
Prenons l'exemple du schéma de conception d'OP_VAULT : lors de la dépense des fonds dans le coffre-fort, il est nécessaire d'envoyer d'abord une transaction sur la chaîne. Cette transaction indique l'intention de dépenser le coffre-fort, c'est-à-dire "trigger", et y établit des conditions :
Il convient de noter qu'il est également possible de construire une application de garde sans clauses restrictives. Une méthode viable consiste à préparer des signatures pour des dépenses futures avec une clé privée, puis à détruire cette clé privée. Cependant, il existe encore de nombreuses restrictions, par exemple, il est nécessaire de s'assurer que cette clé privée a été détruite ), semblable au processus de configuration de confiance dans la preuve à connaissance nulle (, le montant et les frais doivent être déterminés à l'avance ) en raison de la pré-signature (, ce qui entraîne un manque de flexibilité, etc.
![Détails sur les Covenants : comment réaliser la Programmabilité de Bitcoin ?])https://img-cdn.gateio.im/webp-social/moments-163ceda005acef4c7986cd940c4f0945.webp(
) un canal d'état plus robuste et flexible
On peut généralement considérer que les canaux d'état, y compris le réseau Lightning, possèdent une sécurité presque équivalente à celle de la chaîne principale ###, à condition que les nœuds puissent observer l'état le plus récent et publier normalement l'état le plus récent sur la chaîne (. Cependant, avec l'ajout de clauses restrictives, certaines nouvelles conceptions de canaux d'état peuvent être plus robustes ou flexibles au-dessus du réseau Lightning. Parmi les plus connus, on trouve Eltoo, Ark, etc.
Eltoo ), également connu sous le nom de LN-Symmetry(, est un exemple typique. Cette solution technique tire son homophonie de "L2" et propose une couche d'exécution pour le réseau Lightning, permettant à tout état de canal ultérieur de remplacer un état précédent sans avoir besoin de mécanisme de punition, évitant ainsi également d'avoir à conserver plusieurs états précédents comme le font certains nœuds du réseau Lightning pour prévenir les comportements malveillants. Pour réaliser cet effet, Eltoo a proposé la méthode de signature SIGHASH_NOINPUT, à savoir APO)BIP-118(.
Ark vise à réduire la difficulté liée à la liquidité entrante du réseau Lightning et à la gestion des canaux. Il s'agit d'un protocole sous forme de joinpool, où plusieurs utilisateurs peuvent accepter un fournisseur de services comme contrepartie pendant une certaine période, effectuant des transactions de UTXO)vUTXO( hors chaîne, tout en partageant un UTXO sur la chaîne pour réduire les coûts. Semblable à un coffre-fort, Ark peut également être mis en œuvre sur le réseau Bitcoin actuel ; mais après l'introduction de clauses restrictives, Ark peut réduire la quantité d'interactions nécessaires basée sur des modèles de transactions, réalisant ainsi un retrait unilatéral plus décentralisé.
![Explication des Covenants : Comment réaliser la Programmabilité de Bitcoin ?])https://img-cdn.gateio.im/webp-social/moments-bf8295d231f632f2f6303d826e3e450b.webp(
Aperçu technique des conditions restrictives
D'après les applications ci-dessus, les clauses restrictives ressemblent davantage à un effet qu'à une certaine technologie, il existe donc de nombreuses manières techniques de les mettre en œuvre. Si l'on devait les classer, cela pourrait inclure :
Parmi ceux-ci, la récursivité fait référence à : la mise en œuvre de certaines clauses restrictives qui peuvent également limiter la sortie de la transaction suivante pour restreindre la sortie de la transaction suivante, permettant ainsi d'ajouter des restrictions qui peuvent dépasser une seule transaction, atteignant une profondeur de transaction plus élevée.
Certaines conceptions de clauses restrictives courantes comprennent :
*Si combiné avec OP_CAT
![Détails des Covenants : Comment réaliser la Programmabilité de Bitcoin ?])https://img-cdn.gateio.im/webp-social/moments-1344dbfaff294b02ebc0017e31d2a81d.webp(
Conception des clauses restrictives
D'après l'introduction précédente, on peut voir que le script Bitcoin actuel limite principalement les conditions de déverrouillage, sans restreindre comment ce UTXO peut être dépensé ultérieurement. Pour réaliser des clauses restrictives, nous devons réfléchir à l'envers : pourquoi le script Bitcoin actuel ne peut-il pas mettre en œuvre des clauses restrictives ?
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 réaliser l'introspection des transactions - examiner n'importe quel contenu des transactions (, y compris les sorties ), alors les clauses restrictives pourraient être mises en œuvre.
Ainsi, la conception des clauses restrictives tourne principalement autour de la manière d'implémenter l'introspection.
( basé sur le code d'opération vs basé sur la signature
L'idée la plus simple et brutale est d'ajouter un ou plusieurs codes d'opération ), c'est-à-dire un code d'opération + plusieurs paramètres, ou plusieurs codes d'opération fonctionnels différents ###, pour lire directement le contenu de la transaction. Cela repose également sur l'idée basée sur les codes d'opération.
Une autre approche consiste à ne pas lire et vérifier directement le contenu de la transaction dans le script, mais plutôt à utiliser le hachage du contenu de la transaction. Si ce hachage a déjà été signé, il suffit de modifier le script, par exemple avec OP_CHECKSIG, pour réaliser la vérification de cette signature, ce qui permet d'implémenter indirectement l'introspection de la transaction et les clauses de restriction. Cette approche est basée sur la conception par signature. Elle comprend principalement APO et OP_CSFS, etc.
( APO
SIGHASH_ANYPREVOUT)APO### est un type de signature Bitcoin proposé. La manière la plus simple de signer est de s'engager sur les entrées et sorties de la transaction, mais Bitcoin offre également des méthodes plus flexibles, à savoir SIGHASH, qui permet de s'engager de manière sélective sur les entrées ou sorties d'une transaction.
et le SIGHASH d'APO ne signe que la sortie, sans signer la partie d'entrée. Cela signifie donc que les transactions signées avec la méthode APO peuvent être dans