Glossaire / Protocole et mises à jour
OP_CHECKSIGADD
- Qu'est-ce qu'OP_CHECKSIGADD ?
- OP_CHECKSIGADD compte les signatures une clé à la fois dans le tapscript, remplaçant l'ancien opcode multisig par une vérification que la vérification par lots et les futurs types de clés peuvent tous deux prendre en charge.
Spécifié dans BIP-342.
L'opcode prend trois éléments sur la pile, une signature, un compteur courant et une clé publique, et renvoie le compteur soit inchangé, soit augmenté d'une unité. Le BIP-342 lui a attribué l'opcode 186 et a désactivé OP_CHECKMULTISIG dans la foulée, de sorte que tout multisig de script Taproot s'écrit ainsi. Le gain pratique est qu'une politique de seuil ne s'arrête plus à 20 clés.
Comment cela fonctionne
Un seuil tapscript est une chaîne de vérifications de signature avec un décompte transmis entre elles, et une comparaison à la fin.
Écrit en toutes lettres, un deux sur trois se lit : pousser la première clé publique, OP_CHECKSIG, pousser la deuxième, OP_CHECKSIGADD, pousser la troisième, OP_CHECKSIGADD, pousser 2, OP_NUMEQUAL. L'exécution avance de gauche à droite. OP_CHECKSIG laisse 1 ou 0 sur la pile, et chaque OP_CHECKSIGADD dépile une clé publique, dépile ce total courant, dépile la signature offerte pour cette clé, et repousse le total augmenté de 1 si la signature a été vérifiée. La comparaison finale décide si suffisamment d'entre elles l'ont été.
Un signataire qui ne participe pas fournit une chaîne d'octets vide à la place d'une signature. L'opcode la voit, traite l'emplacement comme non signé, et renvoie le décompte inchangé, ce qui coûte un seul octet dans le witness. C'est tout le mécanisme, et il supprime l'élément de pile factice qu'OP_CHECKMULTISIG exigeait en raison d'un bogue de décalage d'une unité dans l'implémentation d'origine.
Deux conséquences découlent de la vérification d'une clé contre une signature. La vérification devient groupable : un nœud peut jeter toutes les signatures Schnorr du bloc dans une seule vérification agrégée au lieu de tester des clés candidates dans l'ordre, ce qui représente une grande partie de l'accélération de la validation de Taproot. Et le nombre de clés est limité par le budget de validation tapscript, qui dépense 50 unités de poids par signature vérifiée, plutôt que par un plafond fixe inscrit dans l'opcode.
Où le voit-on
OP_CHECKSIGADD apparaît dans tout script Taproot qui nécessite plus d'un signataire, ce qui, dans un logiciel de portefeuille, signifie généralement un descripteur plutôt qu'un script brut.
Bitcoin Core l'expose sous forme de fragments multi_a et sortedmulti_a dans un descripteur tr(), de sorte qu'un quorum de trois clés s'écrit tr(internalkey,multi_a(2,KEY1,KEY2,KEY3)) et le logiciel émet la chaîne d'opcodes à votre place. Miniscript le traite de la même manière, et les appareils matériels qui prennent en charge les politiques Taproot signent ces scripts sans avoir besoin de connaître la disposition à l'avance.
La conception change aussi la façon dont vous pouvez façonner un quorum. Au lieu d'une seule feuille contenant les trois clés, un taptree peut contenir trois feuilles distinctes de deux clés, une par paire possible, et une dépense ne révèle alors que la paire qui a réellement signé. Cela coûte plus cher en feuilles de script et économise une clé publique dans le witness, et c'est une véritable amélioration de la confidentialité par rapport à la publication de l'ensemble complet des clés à chaque dépense.
OP_CHECKSIGADD vs OP_CHECKMULTISIG
OP_CHECKSIGADD et OP_CHECKMULTISIG comptent tous deux les signatures par rapport à un ensemble de clés, et un seul d'entre eux fonctionne dans une feuille Taproot. OP_CHECKMULTISIG reste parfaitement valide dans les scripts hérités et de version SegWit 0, de sorte que le multisig bc1q que les gens utilisent depuis des années n'est pas affecté et n'a besoin d'aucune migration.
Dans le tapscript, OP_CHECKMULTISIG et OP_CHECKMULTISIGVERIFY sont désactivés purement et simplement. Au-delà de ce cadre, trois différences comptent : l'ancien opcode plafonne un script à 20 clés publiques et le nouveau n'a pas un tel nombre, l'ancien exige un élément factice supplémentaire sur la pile que le BIP-147 a ensuite imposé comme vide par une règle de consensus, et l'ancien ne peut pas être vérifié par lots car un vérificateur ne sait pas à l'avance à quelle clé appartient chaque signature.