Limite de sigops par bloc

La vérification des signatures coûte du temps à un nœud, aussi le consensus mesure ce travail dans son propre budget plutôt que de l'imputer à l'espace de bloc. Le BIP141 a fixé le compteur à 80 000 unités et a facturé chaque opération de signature héritée à quatre de ces unités, multipliant par quatre un plafond plus ancien de 20 000. Un retrait ordinaire à clé unique ou Taproot dépense une poignée d'unités, si bien que le plafond est invisible pour presque tous ceux qui déplacent des bitcoins.

Comment cela fonctionne

La limite de sigops par bloc est un total cumulé, additionné transaction par transaction lorsqu'un nœud connecte un bloc, et un bloc dont le total dépasse 80 000 est invalide.

Rien n'est exécuté pour la produire : un nœud parcourt les octets de script et compte les opcodes, si bien qu'une vérification de signature dans une branche que la dépense n'emprunte jamais est facturée en entier. Le pessimisme est délibéré : un nœud doit savoir qu'un bloc reste dans les limites de son budget avant de vérifier quoi que ce soit.

Trois comptages sont additionnés, et ils ne portent pas tous sur la même transaction. Le comptage hérité lit les scripts d'entrée propres à une transaction et ses propres scripts de sortie, multipliés par quatre, si bien qu'une opération écrite dans un scriptPubKey est facturée à celui qui crée la sortie plutôt qu'à celui qui la dépense plus tard. Le comptage pay to script hash lit le script de rachat qu'une entrée dépensée révèle, également multiplié par quatre. Le comptage des témoins compte à sa valeur nominale : une unité pour une entrée P2WPKH, et un script P2WSH facturé exactement comme il l'aurait été sous P2SH.

Une différence entre ces lectures coûte de l'argent réel. Les lectures P2SH et témoin appliquent la réduction du BIP141, où OP_CHECKMULTISIG précédé de OP_1 à OP_16 compte de un à seize plutôt que vingt à forfait ; la lecture héritée ne l'applique jamais. Une sortie multisig deux sur trois nue est facturée les vingt opérations complètes, quatre-vingts unités de budget, et facturée à la création.

Tapscript a quitté le budget tout à fait. Le BIP342 a retiré les opérations de signature tapscript du plafond de 80 000 à l'échelle du bloc et a donné à chaque script sa propre allocation : 50 unités, plus la taille sérialisée du témoin de cette entrée, décrémentée de 50 chaque fois qu'un opcode de signature s'exécute avec une signature réelle attachée. Cinquante, c'est quatre millions de poids divisés par quatre-vingt mille sigops, le rapport entre les deux plafonds.

Où cela se voit

La politique de relais rencontre la limite de sigops par bloc bien avant le consensus, par trois constantes de Bitcoin Core plus strictes que la règle du réseau.

Une transaction ne peut réclamer plus d'un cinquième du budget de bloc, soit 16 000 unités. Une entrée pay to script hash standard peut révéler un script de rachat contenant au plus 15 opérations de signature. Un troisième comptage lit les opérations hors témoin là où elles peuvent réellement s'exécuter plutôt que là où elles se trouvent, et arrête le relais au-delà de 2 500 par transaction ; il lit le scriptPubKey dépensé, que le comptage à l'échelle du bloc a déjà facturé à la création.

La limite atteint aussi vos frais. Le réglage bytespersigop de Bitcoin Core, 20 par défaut, remplace le poids d'une transaction par le plus grand de son poids réel et de son coût en sigops multiplié par vingt, si bien qu'une transaction lourde en opérations de signature pour sa taille est facturée comme plus grosse qu'elle ne l'est. Créer une sortie multisig nue est la façon ordinaire de la déclencher.

Les mineurs rencontrent ce budget comme une seconde contrainte à côté du poids, ce que le BIP342 donne comme raison de retirer tapscript : deux plafonds rendent la construction d'un bloc plus difficile qu'un seul. Core réserve 400 unités pour les sorties coinbase avant de remplir un modèle.

Limite de sigops par bloc vs poids de bloc

Le poids de bloc compte les données et la limite de sigops par bloc compte le travail de vérification, et un bloc est plein dès qu'il atteint l'un ou l'autre plafond. Le poids est le plafond qu'un bloc ordinaire atteint en premier, parce qu'une entrée P2WPKH coûte une unité et qu'une dépense Taproot n'ajoute rien du tout, si bien que le budget de sigops ne décide de l'issue que pour un bloc chargé de script à l'ancienne. Divisez un plafond par l'autre et vous obtenez 50 unités de poids par opération de signature, le rapport que le BIP342 a réutilisé pour facturer le budget tapscript et ce qui ressemble le plus, dans le protocole, à un taux de change entre les octets et les vérifications de signature.