Dies ist Teil 5 der technischen Artikelreihe von Cointelegraph Research über Bitcoin-Covenants. Den vorherigen Artikel können Sie hier lesen. 

MATT (Merkleize All The Things) ist ein Smart-Contract-Framework für Bitcoin, das zustandsbehaftete Verträge und skalierbare Betrugsnachweise ermöglicht. Ein zustandsbehafteter Vertrag führt Informationen über mehrere Transaktionen hinweg fort und kann diese aktualisieren, während sich der Vertrag weiterentwickelt. Standardmäßige Bitcoin-Skripte bieten diese Möglichkeit nicht, da jede Transaktion unabhängig und ohne Kenntnis vorheriger Ausführungen ausgewertet wird.

Jeder Covenant-Vorschlag ermöglicht bis zu einem gewissen Grad UTXOs, die Zustände mitführen. Das zeigen Skriptsprachen wie Sapio, das auf OP_CTV aufbaut. Dabei werden Adressen verwendet, um einen endlichen Zustandsautomaten darzustellen, dessen Zustandsübergänge durch Transaktionen ausgeführt werden. In diesem Paradigma gibt es jedoch keine elegante Möglichkeit, numerische Logik zu implementieren. Diese Lücke schließt MATT, insbesondere mit seiner vorgeschlagenen Implementierung durch OP_CCV. Da MATT ermöglicht, dass gebundene Daten zum Ausgabenzeitpunkt berechnet und in den nächsten Output eingebettet werden, kann jeder Spend dynamisch einen neuen Zustand ableiten, anstatt aus einer vorgegebenen Menge von Zuständen auszuwählen. 

Wie OP_CCV einen Zustand in einen Taproot-Schlüssel einbindet

Um den MATT-Vorschlag zu verstehen, ist es hilfreich, zunächst zu betrachten, wie Taproot Daten über öffentliche Schlüssel einbindet. Jeder Taproot-Output enthält einen Basisschlüssel, den sogenannten internen Schlüssel, der kryptografisch verändert oder „getweakt“ werden kann, um zusätzliche Informationen einzubinden. Formal lautet der getweakte öffentliche Schlüssel Q = P + t·G, wobei P der interne Schlüssel, G der Generator der elliptischen Kurve secp256k1 und t ein getaggter Hash von P und den eingebundenen Daten ist. 

In einem regulären Taproot-Output codiert dieses Commitment typischerweise die Merkle-Wurzel eines Taptrees, der verborgene Ausgabepfade enthält. MATT baut auf diesem Mechanismus auf und bettet zusätzlich den Vertragszustand in den Schlüssel ein. Anstatt komplexe Logik direkt in der Skriptsprache von Bitcoin abzubilden, codiert MATT Berechnungen als Folge von Zustands-Commitments. Die Blockchain verifiziert lediglich, dass jeder Zustandsübergang gültig ist.

MATT lässt sich mit verschiedenen Opcode-Kombinationen umsetzen. Die direkteste und am besten spezifizierte Implementierung basiert auf OP_CHECKCONTRACTVERIFY (OP_CCV). OP_CCV stellt die Grundfunktion bereit, die UTXOs mit mitgeführtem Zustand innerhalb von Taproot ermöglicht.  OP_CCV ermöglicht einem Skript zu prüfen, ob ein Taproot-Eingabe- oder -Ausgabeschlüssel so getweakt wurde, dass er ein bestimmtes Zustandsdatum bindet. Zunächst wird der interne Schlüssel mit einem Hash des aktuellen Vertragszustands getweakt; anschließend wird darüber der standardmäßige Taptree-Tweak von Taproot angewendet. Der resultierende Ausgabeschlüssel bindet daher sowohl das Tapscript (die Menge der Ausgabebedingungen) als auch den aktuellen Zustand des Vertrags.

Anschließend kann OP_CCV erzwingen, welcher Zustand in den nächsten Output übernommen wird. Das Skript kann die auf dem Witness-Stack bereitgestellten Zustandsdaten prüfen, Berechnungen damit durchführen und verlangen, dass der aktualisierte Zustand korrekt in einem festgelegten Output erneut gebunden wird. So werden Zustandsübergänge on-chain erzwungen. Das Stack-Format lautet:

<data> <index> <pk> <taptree> <mode> OP_CHECKCONTRACTVERIFY

Der Opcode unterstützt drei Modi zur Prüfung eines Outputs sowie einen separaten Eingabemodus. Im Standardmodus wird der gesamte BTC-Wert des Eingabe-UTXO dem angegebenen Output zugewiesen; im Abzugsmodus wird nur ein Teil in Höhe des Betrags des Outputs zugewiesen, sodass der Rest für weitere Outputs verfügbar bleibt; und im Ignoriermodus werden Skript und Daten-Commitment verifiziert, ohne den Betrag einzuschränken.  Da der Standard- und der Abzugsmodus den Wert über die geprüften Outputs hinweg erhalten sollen, müssen Transaktionsgebühren über separate gebührenzahlende Inputs beglichen werden. Der Transaktion lassen sich ein eigener Gebühren-Input und ein Wechselgeld-Output hinzufügen, ohne mit den Einschränkungen des Covenants in Konflikt zu geraten. So wird das versehentliche Verbrennen von Guthaben verhindert, das bei einfacheren Covenant-Implementierungen wie OP_CTV oder SIGHASH_ANYPREVOUT auftreten kann. Außerdem wird eine wesentliche Einschränkung von Covenants nach dem Muster vorab signierter Transaktionen angegangen: Sie legen Beträge in der Regel im Voraus fest und können daher weder dynamische Gebührenanpassungen noch teilweise Unvaults unterstützen.

OP_CCV + OP_CAT: Merkle-Beweise und Betrugsbeweise

In Kombination mit OP_CAT wird das MATT-Framework noch ausdrucksstärker. OP_CAT ermöglicht die Verkettung von Bytes in Script, wodurch sich Merkle-Beweise direkt on-chain konstruieren und verifizieren lassen. Bei einer solchen Anordnung sind einem Taproot-Output zwei unterschiedliche Merkle-Bäume zugeordnet. Der erste ist der bekannte Taproot-Skriptbaum (der Taptree), dessen Blätter die Ausgabeskripte des Vertrags sind. Der zweite ist ein separater Zustandsbaum, dessen Blätter die Daten des Vertrags enthalten, etwa die Zwischenschritte einer Berechnung.  Das Skript OP_CCV + OP_CAT kann einen Merkle-Beweis anhand der aktuellen Wurzel des Zustandsbaums verifizieren, nach einem Übergang die aktualisierte Wurzel berechnen und mit OP_CCV erzwingen, dass der nächste Output diese Wurzel bindet. 

Mit dieser Konstruktion lassen sich Betrugsbeweissysteme mit Slashing-Bedingung umsetzen: Eine umfangreiche Berechnung wird off-chain gebunden, und nur der konkret angefochtene Schritt (zusammen mit seinem Pfad im Binärbaum) muss offengelegt und on-chain verifiziert werden. Ähnliche Systeme gibt es als optimistische Rollups auf anderen Blockchain-Systemen: Die gesamte Berechnung läuft off-chain, und der on-chain-Vertrag greift nur ein, wenn jemand eine Anfechtung erhebt. Für Betrugsbeweise muss die Berechnung in eine binäre Schaltung oder eine gleichwertige schrittweise Darstellung übersetzt werden, die sich in einem Merkle-Baum binden lässt. OP_CCV + OP_CAT würde die Lamport-Einmalsignaturen und vorab signierten Transaktionsgraphen überflüssig machen, auf die BitVM angewiesen ist, um die Zustandskonsistenz durchzusetzen.

Über Betrugsbeweise hinaus hat die Kombination aus OP_CCV und OP_CAT auch Auswirkungen auf Vaults. Mit OP_CCV allein lassen sich Vaults implementieren; in Kombination mit OP_CAT ermöglicht es jedoch voll ausgestattete Vaults, deren Funktionalität im Wesentlichen dem Vorschlag OP_VAULT entspricht. Wie James O’Beirne, der Autor von OP_VAULT, angemerkt hat, stellt OP_CCV ein allgemeineres und robusteres Design dar, das seinen früheren Vorschlag effektiv ablöst.

Im nächsten Artikel dieser Reihe wenden wir uns von allgemeinen Covenant-Vorschlägen ab und sehen uns anwendungsspezifische Opcodes wie OP_VAULT, OP_UNVAULT und OP_EVICT an. Jeder dieser Opcodes ist darauf ausgelegt, ein bestimmtes Problem zu lösen, statt umfassende Programmierbarkeit zu bieten.

Magazin: Bitcoin-Besitzer haben eCash erhalten – Was können Sie damit machen?