Opcode

Das Bitcoin-Script hat ein festes Vokabular von 256 möglichen Byte-Werten, aufgeteilt in Opcodes, die Literaldaten auf den Stack legen, und Opcodes, die auf bereits abgelegte Daten einwirken. Ein Legacy-Script darf höchstens 201 wirkende Opcodes ausführen und nicht mehr als 10.000 Bytes umfassen. Für alle, die Bitcoin kaufen, erklärt dieses kleine Vokabular, warum eine Wallet eine Gebühr nennen kann, bevor sie die Transaktion sendet, und warum Bitcoin keine Angriffsfläche für außer Kontrolle geratene Vertragsfehler bietet.

So funktioniert es

Ein validierender Node liest ein Script Byte für Byte und schlägt jedes Byte in einer festen Tabelle nach. Die Werte 0x01 bis 0x4b sind überhaupt keine Anweisungen: Jeder besagt, dass die nächsten N Bytes Literaldaten sind und auf den Stack gehören, weshalb ein komprimierter öffentlicher Schlüssel mit 33 Bytes in einem Script als 0x21 gefolgt vom Schlüssel selbst erscheint. Drei weitere Push-Codes, OP_PUSHDATA1, OP_PUSHDATA2 und OP_PUSHDATA4, decken längere Elemente ab, und die Werte 0x51 bis 0x60 legen die kleinen ganzen Zahlen 1 bis 16 auf den Stack, die in Quorum-Zählungen auftauchen.

Alles über 0x60 verrichtet Arbeit, statt Daten zu tragen, und nur diese zählt Bitcoin. Ein Script vor Taproot darf höchstens 201 davon enthalten, kein Stack-Element von mehr als 520 Bytes halten, nicht mehr als 1.000 Elemente auf seinen Stacks behalten und insgesamt nicht mehr als 10.000 Bytes umfassen. Alle vier Zahlen stammen aus script.h in Bitcoin Core, und alle vier sind Konsensregeln, keine Vorlieben, die ein Node-Betreiber lockern kann.

Fünfzehn Opcodes stehen in der Tabelle, sind aber tot. OP_CAT, OP_MUL, OP_LSHIFT und zwölf weitere wurden im Jahr 2010 nach einem Absturzfehler abgeschaltet, und ein Script, das nur einen davon enthält, schlägt fehl, selbst in einem Zweig, der nie ausgeführt wird. Keiner wurde je wieder aktiviert. Diese eine Entscheidung ist der größte Grund, warum Bitcoins Scripting enger ist, als das Wort „programmierbar“ erwarten lässt.

Tapscript schrieb die Buchführung für Taproot-Ausgaben neu. BIP-342, in Kraft seit Block 709.632 im November 2021, strich sowohl die Obergrenze von 201 Anweisungen als auch die Größenbeschränkung von 10.000 Bytes und ersetzte sie durch ein Signaturbudget: Die Transaktion muss für jede Signatur, die das Script prüft, 50 Gewichtseinheiten mitführen. Außerdem verwandelte es einen Block undefinierter Byte-Werte in OP_SUCCESS-Codes, sodass ein Script, das einen enthält, gültig ist, ohne überhaupt ausgeführt zu werden. Das ist bewusst freigelassener Raum für künftige Upgrades.

Warum das beim Bitcoin-Kauf zählt

Opcodes entscheiden, was Ihre Auszahlung kostet. Eine Legacy-Ausgabe schreibt vier wirkende Anweisungen um einen Hash von 20 Bytes in 25 Bytes; das native SegWit-Äquivalent ist ein Versions-Byte und ein Push, 22 Bytes; eine Taproot-Ausgabe umfasst 34. Weil SegWit die entsperrende Seite mit einem Viertel des Gewichts in den Witness verschob, kostet das Ausgeben einer bech32-Ausgabe ungefähr 68 virtuelle Bytes gegenüber ungefähr 148 für die Legacy-Version derselben Zahlung. Beim Auszahlen bech32 oder bech32m zu wählen, wo immer die Börse es anbietet, ist annähernd die günstigste Entscheidung in diesem Glossar.

Opcodes entscheiden auch, was Ihr Signiergerät tatsächlich verarbeiten kann. Eine Hardware-Wallet, die nur die standardmäßigen Einzelschlüssel-Vorlagen kennt, kann einen zeitgesperrten Tresor oder eine ungewöhnliche Richtlinie nicht mitzeichnen. Wenn Nachlassplanung oder Multisig irgendwo in Ihren Plänen vorkommt, prüfen Sie die Script-Unterstützung in den Bewertungen, bevor Sie das Gerät kaufen, und nicht erst, wenn die Bitcoin bereits darauf liegen.

Die Enge ist eine Sicherheitseigenschaft, kein Mangel. Es gibt keine Schleifen, keine Möglichkeit, eine andere Transaktion zu lesen, und keinen Zustand, der zwischen Ausgaben bestehen bleibt. Der Fehlermodus, der programmierbare Ketten um Milliarden von Dollar erleichtert hat, ein Vertrag, der sich bei Eingaben korrekt verhält, die sein Autor nie bedacht hat, hat daher keinen Ort, an dem er auftreten könnte. Bitcoin-Verluste entstehen durch Börsen, Phishing und verlorene Backups, nicht durch Fehlfunktionen der Script-Engine.

Praxisbeispiel: Der Tag, an dem OP_NOP2 Zähne bekam

OP_NOP2 war Byte 0xb1 und tat überhaupt nichts, einer von zehn nummerierten No-Ops, die für spätere Verwendung in der Tabelle blieben. BIP-65 gab ihm eine Aufgabe: bestätigen, dass die Locktime der Transaktion verstrichen ist, und das Script fehlschlagen lassen, wenn nicht. Die Durchsetzung begann bei Block 388.381 am 14. Dezember 2015, und seitdem heißt der Opcode OP_CHECKLOCKTIMEVERIFY.

Der Trick ist, dass ältere Software weiterhin ein Byte sah, das nichts tut, und die neuen Transaktionen daher weiterhin als gültig akzeptierte. Nur aktualisierte Nodes setzten die Zeitsperre durch. Diese Asymmetrie macht einen Soft Fork weich, und auf demselben Weg wurde OP_NOP3 bei Block 419.328 im Juli 2016 zu OP_CHECKSEQUENCEVERIFY. Acht reservierte No-Op-Plätze bleiben übrig, das ist der größte Teil von Bitcoins verbleibendem Upgrade-Raum unter den Regeln vor Taproot und ein großer Teil des Grundes, warum sich so viel Design-Aufmerksamkeit auf die OP_SUCCESS-Werte verlagert hat, die Tapscript geschaffen hat.

Opcode vs. Bitcoin-Script

Bitcoin-Script ist die Sprache, und ein Opcode ist ein Wort ihres Vokabulars. Der Unterschied zählt, wenn Sie Behauptungen darüber lesen, was Bitcoin kann oder nicht kann, denn fast jeder ernsthafte Vorschlag des letzten Jahrzehnts war der Vorschlag, einen neuen Opcode zu definieren, nicht die Sprache darum herum zu ändern. OP_CHECKTEMPLATEVERIFY, OP_CAT und OP_CHECKSIGADD sind jeweils ein einzelnes Byte mit einer einzigen Aufgabe, und öffentliche Auseinandersetzungen über Covenants oder Tresore sind Auseinandersetzungen darüber, ob ein bestimmtes Byte etwas bedeuten darf. Der Stack, die Limits und das Fehlen von Schleifen bleiben genau so, wie sie sind, wenn ein neuer Opcode kommt.