Sigop-Limit pro Block

Das Prüfen von Signaturen kostet einen Node Zeit, deshalb misst der Konsens diese Arbeit in einem eigenen Budget ab, statt sie dem Blockspeicher anzulasten. BIP141 setzte den Zähler auf 80.000 Einheiten und bepreiste jeden Legacy-Signaturvorgang mit vier davon, womit eine ältere Obergrenze von 20.000 vervierfacht wurde. Eine normale Auszahlung mit einem einzigen Schlüssel oder eine Taproot-Auszahlung verbraucht eine Handvoll Einheiten, sodass die Obergrenze für fast alle unsichtbar ist, die Bitcoin bewegen.

So funktioniert es

Das Sigop-Limit pro Block ist eine laufende Summe, die Transaktion für Transaktion addiert wird, während ein Node einen Block verbindet, und ein Block, dessen Summe 80.000 überschreitet, ist ungültig.

Für seine Ermittlung wird nichts ausgeführt: Ein Node durchsucht die Script-Bytes und zählt die Opcodes, sodass eine Signaturprüfung in einem Zweig, den die Ausgabe nie nimmt, vollständig berechnet wird. Diese pessimistische Haltung ist beabsichtigt: Ein Node muss wissen, dass ein Block bezahlbar ist, bevor er irgendetwas verifiziert.

Drei Zählungen werden summiert, und sie fallen nicht alle auf dieselbe Transaktion. Die Legacy-Zählung liest die eigenen Eingabe-Scripts einer Transaktion und ihre eigenen Ausgabe-Scripts, multipliziert mit vier, sodass ein Vorgang, der in ein scriptPubKey geschrieben wird, demjenigen angelastet wird, der die Ausgabe erstellt, und nicht demjenigen, der sie später ausgibt. Die Pay-to-Script-Hash-Zählung liest das Redeem-Script, das eine ausgebende Eingabe offenlegt, ebenfalls multipliziert mit vier. Die Witness-Zählung zählt zum Nennwert: eine Einheit für eine P2WPKH-Eingabe, und ein P2WSH-Script wird genau so berechnet, wie es unter P2SH berechnet worden wäre.

Ein Unterschied zwischen diesen Prüfungen kostet echtes Geld. Die P2SH- und die Witness-Lesung wenden den Rabatt von BIP141 an, bei dem OP_CHECKMULTISIG mit vorangehendem OP_1 bis OP_16 als eins bis sechzehn statt als pauschal zwanzig zählt; die Legacy-Prüfung wendet ihn nie an. Eine Bare-Zwei-von-drei-Multisig-Ausgabe wird mit den vollen zwanzig Vorgängen berechnet, achtzig Einheiten des Budgets, und zwar bei ihrer Erstellung.

Tapscript verließ das Budget ganz. BIP342 nahm die Tapscript-Signaturvorgänge aus den blockweiten 80.000 heraus und gab jedem Script ein eigenes Kontingent: 50 Einheiten, zuzüglich der serialisierten Größe des Witness dieser Eingabe, vermindert um 50 jedes Mal, wenn ein Signatur-Opcode mit einer echten Signatur ausgeführt wird. Fünfzig ergibt sich aus vier Millionen Gewichtseinheiten geteilt durch achtzigtausend Sigops, das Verhältnis zwischen den beiden Obergrenzen.

Wo Sie es sehen

Die Relay-Richtlinie trifft auf das Sigop-Limit pro Block lange vor dem Konsens, über drei Bitcoin Core-Konstanten, die strenger sind als die Regel des Netzwerks.

Eine einzelne Transaktion darf nicht mehr als ein Fünftel des Blockbudgets beanspruchen, 16.000 Einheiten. Eine standardmäßige Pay-to-Script-Hash-Eingabe darf ein Redeem-Script offenlegen, das höchstens 15 Signaturvorgänge enthält. Eine dritte Zählung liest Nicht-Witness-Vorgänge dort, wo sie tatsächlich ausgeführt werden können, statt dort, wo sie stehen, und stoppt die Weitergabe oberhalb von 2.500 pro Transaktion; sie liest das ausgegebene scriptPubKey, das die blockweite Zählung bereits bei der Erstellung berechnet hat.

Das Limit erreicht auch Ihre Gebühr. Die Einstellung bytespersigop von Bitcoin Core, standardmäßig 20, ersetzt das Gewicht einer Transaktion durch den größeren Wert aus ihrem tatsächlichen Gewicht und ihren Sigop-Kosten multipliziert mit zwanzig, sodass eine Transaktion mit vielen Signaturvorgängen für ihre Größe teurer berechnet wird, als sie ist. Eine Bare-Multisig-Ausgabe zu erstellen ist der übliche Weg, sie auszulösen.

Miner treffen auf das Budget als zweite Einschränkung neben dem Gewicht, was BIP342 als Grund dafür angibt, Tapscript herauszunehmen: zwei Obergrenzen erschweren den Zusammenbau eines Blocks mehr als eine. Core reserviert 400 Einheiten für die Coinbase-Ausgaben, bevor eine Vorlage gefüllt wird.

Sigop-Limit pro Block vs. Blockgewicht

Das Blockgewicht zählt Daten und das Sigop-Limit pro Block zählt Verifikationsarbeit, und ein Block ist voll, sobald er eine der beiden Obergrenzen erreicht. Das Gewicht ist die Obergrenze, die ein gewöhnlicher Block zuerst erreicht, weil eine P2WPKH-Eingabe eine Einheit kostet und eine Taproot-Ausgabe überhaupt nichts hinzufügt, sodass das Sigop-Budget das Ergebnis nur bei einem Block entscheidet, der mit Script im alten Stil beladen ist. Teilen Sie eine Obergrenze durch die andere, erhalten Sie 50 Gewichtseinheiten pro Signaturvorgang, das Verhältnis, das BIP342 wiederverwendete, um das Tapscript-Budget zu bepreisen, und das, was im Protokoll einem Wechselkurs zwischen Bytes und Signaturprüfungen am nächsten kommt.