Ceci est le deuxième article dans une série Une plongée profonde dans les propositions individuelles de l’alliance qui ont atteint un point de maturité méritant une ventilation approfondie.
Checksigfromstack (CSFS), mis en avant par Brandon Black et Jeremy Rubin avec BIP 348, n’est pas une alliance. Comme je l’ai dit dans l’article d’introduction à cette série, certaines des propositions que je couvrirais ne sont pas des alliances, mais synergisaient ou interagissent avec eux d’une manière ou d’une autre. CSFS en est le premier exemple.
CSFS est un OPCode très simple, mais avant de passer en revue la façon dont cela fonctionne, examinons les bases de la façon dont un script Bitcoin fonctionne réellement.
Le script est un langage basé sur la pile. Cela signifie que les données sont «empilées» ensemble les unes sur les autres sur la pile et ont fonctionné en supprimant un élément du haut de la pile pour fonctionner en fonction de ce qu’un OPCode fait, soit renvoyant les données, soit un résultat en haut de la pile.
Il y a deux parties d’un script lorsqu’il est finalement exécuté et vérifié, le «témoin» fourni pour déverrouiller le script, et le script inclus dans la sortie en cours de dépensier. Le script de témoin / déverrouillage est «ajouté» sur le côté gauche du script de verrouillage, puis chaque élément est ajouté (ou fonctionne sur) la pile une par une de gauche à droite. Regardez cet exemple (le “|»Marque la frontière entre le témoin et le script):
1 2 | On_add 3 on_equal
Cet exemple de script ajoute la valeur «1» à la pile, puis la valeur «2» en plus de cela. OP_ADD prend les deux premiers éléments de la pile et les ajoute ensemble, remettant le résultat sur la pile (donc maintenant tout ce qui est sur la pile est «3»). Un autre «3» est ensuite ajouté à la pile. Le dernier élément, OP_EQUAL, prend les deux premiers éléments de la pile et renvoie un «1» à la pile (1 et 0 peuvent représenter des nombres vrais ou faux ainsi que des nombres).
Un script doit se terminer avec le dernier élément en haut de la pile étant vrai, sinon le script (et l’exécution de la transaction) échoue et est considéré comme un consensus invalide.
Ceci est un exemple de base d’un script Pay-to-Pubkey-Hash (P2PKH), c’est-à -dire les adresses héritées qui commencent par un «1»:
La signature et la clé publique sont d’abord ajoutées à la pile. Ensuite, DUP est appelé, qui prend l’élément de pile supérieur et le double, le renvoyant en haut de la pile. Hash160 prend l’élément de pile supérieur (le duplicata de la clé publique), hache, puis le renvoie en haut de la pile. Le hachage de la clé publique du script est placé sur la pile. Equalverify fonctionne comme égal, il saisit les deux éléments de pile supérieur et renvoie un 1 ou 0 en fonction du résultat. La seule différence est que Equalverify exécute également Vérifier après égalité, ce qui échoue à la transaction si l’élément de pile supérieur n’est pas 1 et supprime également l’élément de pile supérieur. Enfin, Checksig est exécuté, qui saisit les deux éléments de pile supérieurs en supposant que ce soit une signature et un pubkey, et vérifie implicitement la signature par rapport au hachage de la transaction vérifiée. S’il est valide, il met un 1 sur le dessus de la pile.
Comment fonctionne les CSF
Checksig est l’un des opcodes les plus utilisés de Bitcoin. Chaque transaction, sans presque aucune exception, utilise cet opcode à un moment donné dans l’un de ses scripts. La vérification de la signature est une composante fondamentale du protocole Bitcoin. Le problème est qu’il n’y a presque aucune flexibilité en termes de message contre lequel vous vérifiez la signature. Checksig ne vérifiera qu’une signature par rapport à la transaction en cours de vérification. Il y a une certaine flexibilité, c’est-à -dire que vous pouvez décider avec un certain degré de liberté quelles parties de la transaction à laquelle s’applique la signature, mais c’est tout.
CSFS vise à changer cela en permettant à une signature d’être vérifiée par rapport à tout message arbitraire qui est poussé directement sur la pile, au lieu d’être limité à la vérification des signatures par rapport à la transaction elle-même. L’opcode suit une structure opérationnelle très basique:
La signature et le message sont déposés au-dessus de la pile, puis la clé publique en haut de celles-ci, et enfin CSFS saisit les trois premiers éléments de la pile en supposant que ce soit la clé publique, le message et la signature de haut en bas, vérifiant la signature par rapport au message. Si la signature est valide, un 1 est placé sur la pile.
C’est ça. Une variante simple de Checksig qui permet aux utilisateurs de spécifier des messages arbitraires au lieu de la transaction de dépenses.
Qu’est-ce que CSFS utile pour
Alors, à quoi sert-il exactement? À quoi sert la vérification d’une signature par rapport à un message arbitraire sur la pile plutôt que par rapport à la transaction de dépenses?
Premièrement, en combinaison avec CTV Il peut fournir une fonctionnalité équivalente à quelque chose que les développeurs de Lightning ont voulu depuis les signatures flottantes et flottantes qui peuvent attacher à différentes transactions. Cela a été initialement proposé comme nouveau drapeau de Sighash pour les signatures (le domaine qui dicte les parties d’une transaction à laquelle une signature s’applique). Cela était nécessaire car une signature de transaction couvre l’ID de transaction de la transaction qui a créé la sortie dépensée. Cela signifie qu’une signature n’est valable que pour une dépense de transaction qui exact sortir.
Il s’agit d’un comportement souhaité pour la foudre car il nous permettrait de supprimer les pénalités de canal. Chaque État de Lightning a besoin d’une clé de pénalité et d’une transaction afin de s’assurer que la contrepartie de votre canal n’utilise aucun d’entre elles pour essayer de réclamer des fonds qu’ils ne possèdent pas. S’ils essaient, vous pouvez réclamer tout leur argent. Une fonctionnalité supérieure serait quelque chose qui vous permet de simplement «attacher» la transaction d’état actuelle à tout précédent pour stopper la tentative de vol en distribuant correctement les fonds plutôt que pour les confisquer.
Cela peut être accompli avec un script de base qui prend un hachage CTV et une signature dessus qui est vérifié à l’aide de CSFS. Cela permettrait à tout hachage de transaction signé par cette touche CSFS de dépenser toute sortie créée avec ce script.
Une autre caractéristique utile est la délégation du contrôle d’un UTXO. De la même manière que tout hachage CTV signé par une clé CSFS peut valablement dépenser un UTXO avec un script conçu pour cela, d’autres variables peuvent être transmises dans le script pour être vérifiées, comme une nouvelle clé publique. Un script pourrait être construit qui permet à une clé CSFS de se déconnecter n’importe quel clé publique, qui pourrait ensuite être validée à l’aide de CSF et utilisé pour une validation normale de chèques. Cela vous permettrait de déléguer la possibilité de dépenser un UTXO à quelqu’un d’autre sans avoir à le déplacer sur la chaîne.
Enfin, en combinaison avec CAT, les CSF peuvent être utilisés pour composer une fonctionnalité d’introspection beaucoup plus complexe. Comme nous le verrons plus loin dans la série, CSFS n’est pas réellement tenu d’imiter l’un de ces comportements plus avancés, car CAT seul est capable de le faire.
Réflexions de clôture
CSFS est un opcode très basique qui, en plus d’offrir des fonctionnalités utiles simples à part entière, se compose très bien avec les opcodes d’alliance les plus simples pour créer des fonctionnalités très utiles. Alors que l’exemple ci-dessus concernant les signatures flottantes fait spécifiquement référence au réseau Lightning, les signatures flottantes sont une primitive généralement utile qui s’applique à tout protocole construit sur Bitcoin en utilisant des transactions pré-signées.
En plus des signatures flottantes, la délégation de script est une primitive très utile qui se généralise bien au-delà de la délégation de contrôle sur un UTXO à une nouvelle clé publique. La même capacité de base à les variables de «téléchargement» après le fait dans un flux de validation de script peut s’appliquer à n’importe quoi, pas seulement aux clés publiques. Valeurs Timelock, prémages de hashlock, etc. Tout script qui code à la main une variable à vérifier peut désormais avoir ces valeurs ajoutées dynamiquement après coup.
En plus de cela, CSFS est une proposition très mature. Il a une implémentation en direct sur le réseau liquide et les éléments (les utilisations de CodeBase Liquid) depuis 2016. De plus, Bitcoin Cash a eu un version depuis 2018.
Le CSFS est une proposition très mature qui remonte conceptuellement presque aussi longtemps que je l’ai été dans cet espace, avec plusieurs implémentations matures et des cas d’utilisation très clairs auxquels il peut être appliqué.
Résumé: Dans cet article, nous avons exploré l’opcode Checksigfromstack (CSFS) qui permet de vérifier une signature par rapport à un message arbitraire sur la pile. CSFS offre une plus grande flexibilité pour les développeurs Bitcoin, notamment en matière de signatures flottantes et de délégation de contrôle sur les UTXO, et il représente une avancée significative dans les fonctionnalités des scripts Bitcoin. Son architecture simple, alliée à des utilisations pratiques, en fait un outil précieux dans le développement de solutions sur Bitcoin.
