Glossaire / Référence pour développeurs
OP_DUP
- Qu'est-ce qu'OP_DUP ?
- OP_DUP copie l'élément situé au sommet de la pile pour qu'il puisse servir deux fois, ce qui permet au script standard pay-to-public-key-hash de hacher votre clé publique et de vérifier une signature à partir d'elle.
Un octet, 0x76, et une seule tâche. Bitcoin Script n'a pas de variables, seulement une pile, donc un élément consommé par une instruction a disparu avant que la suivante s'exécute, et la duplication est le seul moyen de le réutiliser. C'est le premier des quatre opcodes utiles du script de 25 octets qui protégeait presque toutes les adresses bitcoin commençant par 1.
Comment cela fonctionne
La duplication est nécessaire parce que la vérification a besoin de la même clé publique pour deux usages incompatibles. La sortie ne s'engageait que sur un hash, donc la clé doit être hachée et comparée pour prouver qu'il s'agit de la bonne clé. La vérification de signature a ensuite besoin de la clé elle-même, que la comparaison aurait consommée.
Suivez une dépense héritée. Les données du dépensier arrivent sur la pile sous la forme d'une signature surmontée d'une clé publique. OP_DUP fait une deuxième copie de la clé. OP_HASH160 remplace la copie par son condensé de 20 octets. La sortie pousse les 20 octets engagés, OP_EQUALVERIFY consomme les deux et interrompt tout le script à la moindre différence, et OP_CHECKSIG se retrouve face à la clé d'origine et à la signature, exactement ce qu'il lui faut. Cinq étapes, aucun branchement, aucune boucle, et un coût fixe à chaque fois.
L'opcode compte contre deux plafonds sans rien faire de coûteux. C'est l'une des 201 instructions utiles qu'un script antérieur à Taproot peut contenir, et la copie qu'il produit compte dans la limite de 1 000 éléments sur l'ensemble des piles. Ni l'un ni l'autre ne compte pour une dépense à clé unique, et les deux comptent dans un script qui duplique au sein d'une chaîne de conditions sans boucle.
Où le voir
Regardez toute transaction qui dépense une adresse commençant par 1 : le script de sortie commence par OP_DUP. Les explorateurs l'affichent comme premier jeton de l'assembleur.
Plus intéressant encore, là où il s'exécute sans apparaître. Une sortie SegWit native à clé unique ne contient aucune logique, seulement un octet de version et un hash de 20 octets, mais le BIP-141 demande au nœud de reconstruire le modèle classique à partir de ce hash et de l'exécuter quand même. L'opcode s'exécute donc encore à chaque dépense P2WPKH du réseau et n'apparaît nulle part dans le bloc. Vous obtenez le comportement sans payer les quatre unités de poids que l'octet coûtait auparavant.
Les sorties script hash et les dépenses Taproot à chemin de clé l'ignorent complètement. Une sortie P2SH compare directement un hash, et une dépense Taproot à clé vérifie une signature contre la clé de sortie sans aucun script. C'est la plus petite illustration possible de ce que SegWit et Taproot ont réellement fait : pas tant de nouvelles capacités que les mêmes vérifications agencées pour que la chaîne ait à transporter moins d'octets pour les obtenir.