Der Heilige Gral des Bitcoin Layer 2 Netzwerks: Introspektion und Abmachungen

Im Vergleich zu Turing-kompletten Blockchains wie Ethereum gilt die Skriptsprache von Bitcoin als deutlich eingeschränkt, da sie nur grundlegende Operationen ausführen kann und ihr sogar Multiplikations- und Divisionsfunktionen fehlen. Noch wichtiger ist, dass die Daten der Blockchain selbst für Skripte fast unzugänglich sind, was zu erheblichen Einschränkungen bei der Flexibilität und Programmierbarkeit führt. Daher wird seit langem nach Möglichkeiten gesucht, Bitcoin-Skripten eine Introspektion zu ermöglichen.

Introspektion bezieht sich auf die Fähigkeit von Bitcoin Skripten die Möglichkeit, Transaktionsdaten zu prüfen und einzuschränken. Dadurch können Skripte die Verwendung von Geldern auf der Grundlage spezifischer Transaktionsdetails steuern und komplexere Funktionen ermöglichen. Derzeit schieben die meisten Bitcoin-Opcodes entweder vom Benutzer bereitgestellte Daten auf den Stack oder manipulieren bereits auf dem Stack befindliche Daten. Introspection Opcodes können jedoch aktuelle Transaktionsdaten (wie Zeitstempel, Beträge und Transaktions-IDs) auf den Stack schieben, was eine genauere Kontrolle über UTXO-Ausgaben ermöglicht.

Derzeit gibt es nur drei Haupt-Opcodes in Bitcoin-Skripten, die Introspektion unterstützen: CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY und CHECKSIG. CHECKSIG hat mehrere Varianten, einschließlich CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG, und CHECKMULTISIGVERIFY.

Pakte sind Beschränkungen dafür, wie Token übertragen werden können. Benutzer können festlegen, wie UTXOs durch Covenants verteilt werden, von denen viele mit Introspektions-Opcodes implementiert werden. Derzeit kategorisiert Bitcoin Optech die Introspektion unter Covenant-Einträgen.

Bitcoin hat derzeit zwei Covenants: CSV (CheckSequenceVerify) und CLTV (CheckLockTimeVerify), beides zeitbasierte Covenants, die die Grundlage für viele Skalierungslösungen wie das Lightning Network bilden. Dies zeigt, dass die Skalierungslösungen von Bitcoin stark auf Introspektion und Covenants angewiesen sind.

Hinzufügen von Bedingungen zu Token-Übertragungen

In der Kryptowelt ist die gebräuchlichste Methode Verpflichtungen, die oft mit Hashes umgesetzt wird. Um zu beweisen, dass die Übertragungsbedingungen erfüllt sind, werden Signaturmechanismen zur Überprüfung eingesetzt. Daher beinhalten die Vereinbarungen zahlreiche Anpassungen an Hashes und Signaturen.

Die folgenden Vorschläge für Covenant-Opcodes sind weithin diskutiert worden:

CTV (CheckTemplateVerify) BIP-119

CTV (CheckTemplateVerify), das in BIP-119 enthalten ist, ist ein viel diskutiertes Bitcoin-Upgrade. CTV erlaubt es Ausgabeskripten, Vorlagen für Ausgabetransaktionen zu spezifizieren, einschließlich Feldern wie nVersion, nLockTime, scriptSig Hash, Input Count, Sequences Hash, Output Count, Output Hash und Input Index. Diese Vorlageneinschränkungen werden durch eine Hash-Bindung implementiert, und künftige Ausgabeskripte prüfen, ob die Hash-Werte der angegebenen Felder in der Ausgabetransaktion mit denen im Eingabeskript übereinstimmen. Diese Vorlagen definieren im Wesentlichen den Zeitpunkt, die Methode und den Betrag künftiger UTXO-Transaktionen.

Insbesondere ist die Eingabe-TXID von der Hash-Zusage ausgeschlossen. Dieser Ausschluss ist notwendig, weil die TXID bei Legacy- oder Segwit-Transaktionen vom scriptPubKey-Wert abhängt, wenn der Standard-Signaturtyp SIGHASH_ALL verwendet wird. Die Einbeziehung der TXID würde zu einer zirkulären Abhängigkeit führen und die Erstellung der Hash-Zusage unmöglich machen.

CTV erreicht die Introspektion, indem es die angegebenen Transaktionsinformationen direkt über einen neuen Opcode abruft, sie hasht und mit der Verpflichtung auf dem Stack vergleicht. Diese Methode verbraucht weniger Speicherplatz auf der Kette, ist aber nicht sehr flexibel.

Die Grundlage von Second-Layer-Lösungen wie dem Lightning Network sind vor-signierte Transaktionen. Pre-Signing bedeutet in der Regel, dass Transaktionen im Voraus generiert und signiert werden, aber erst dann veröffentlicht werden, wenn bestimmte Bedingungen erfüllt sind. Im Wesentlichen implementiert CTV eine strengere Vorsignierungsfunktion, indem es die vorsignierte Verpflichtung direkt auf der Kette veröffentlicht und nur Transaktionen gemäß der vordefinierten Vorlage zulässt.

CTV wurde ursprünglich vorgeschlagen, um die Überlastung von Bitcoin zu verringern und kann auch als Überlastungskontrolle bezeichnet werden. In Zeiten hoher Überlastung kann CTV mehrere zukünftige Transaktionen durch eine einzige Transaktion übertragen, wodurch die Notwendigkeit vermieden wird, mehrere Transaktionen während der Überlastung zu übertragen und die tatsächlichen Transaktionen abzuschließen, nachdem die Überlastung nachlässt. Dies könnte bei Austauschläufen eine große Hilfe sein. Darüber hinaus können Vorlagen zur Implementierung von Tresoren verwendet werden, die Hackerangriffe verhindern, da der Bestimmungsort der Gelder im Voraus festgelegt ist, so dass es für Hacker unmöglich ist, UTXOs mit Hilfe des CTV-Skripts an ihre Adressen zu senden.

CTV kann Netzwerke der zweiten Schicht erheblich verbessern. Im Lightning-Netzwerk beispielsweise ermöglicht die Implementierung von Timeout Trees und Channel Factories mit CTV, dass ein einzelner UTXO zu einem CTV-Baum erweitert wird und mehrere State Channels mit nur einer On-Chain-Transaktion und Bestätigung öffnet. Außerdem unterstützt CTV atomare Transaktionen (ATLC) im Ark-Protokoll.

APO (SIGHASH_ANYPREVOUT) BIP-118

BIP-118 schlägt ein neues Signatur-Hash-Flag für tapscript vor, genannt SIGHASH_ANYPREVOUT, um das Schreiben einer flexibleren Ausgabenlogik zu erleichtern. APO und CTV sind in vielerlei Hinsicht ähnlich. Um der zirkulären Abhängigkeit zwischen scriptPubKeys und TXIDs zu begegnen, besteht die Lösung von APO darin, die relevanten Eingabeinformationen auszuschließen und nur die Ausgabe zu signieren, so dass Transaktionen dynamisch an verschiedene UTXOs gebunden werden können.

Logisch gesehen hat die Prüfoperation OP_CHECKSIG (und die zugehörigen Opcodes) drei Funktionen:

1. Stellen Sie Teile der Ausgabentransaktion zusammen.
2. Hash diese Teile.
3. Überprüfen, ob der Hash mit dem angegebenen Schlüssel signiert ist.

Der spezifische Inhalt der Signatur kann erheblich angepasst werden, und welche Transaktionsfelder signiert werden, wird durch das SIGHASH-Flag bestimmt. Nach der Definition der BIP 342-Signatur-Opcodes gehören zu den SIGHASH-Flags u. a. SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE und SIGHASH_ANYONECANPAY. SIGHASH_ANYONECANPAY kontrolliert die Eingabe, während die anderen die Ausgabe kontrollieren.

SIGHASH_ALL ist das Standard-SIGHASH-Flag und signiert alle Ausgaben. SIGHASH_NONE signiert keine Ausgaben, und SIGHASH_SINGLE signiert nur eine bestimmte Ausgabe. SIGHASH_ANYONECANPAY kann zusammen mit den anderen drei Flags gesetzt werden, und wenn es gesetzt ist, wird nur die angegebene Eingabe signiert; ansonsten müssen alle Eingaben signiert werden.

Keines dieser SIGHASH-Flags kann die Auswirkungen von Eingaben eliminieren. Selbst SIGHASH_ANYONECANPAY erfordert eine Verpflichtung zu einer Eingabe.

Daher wird mit BIP 118 SIGHASH_ANYPREVOUT eingeführt. APO-Signaturen müssen sich nicht an den ausgegebenen Eingangs-UTXO (PREVOUT genannt) binden, sondern nur den Ausgang signieren, was eine höhere Flexibilität bei der Bitcoin-Kontrolle ermöglicht. Durch die Vorkonstruktion von Transaktionen und die Erstellung von entsprechenden Signaturen und öffentlichen Schlüsseln zur einmaligen Verwendung müssen Vermögenswerte, die an die Adresse des öffentlichen Schlüssels gesendet werden, durch die vorkonstruierte Transaktion ausgegeben werden, um die Vereinbarung zu erreichen.

Die Flexibilität von APO kann auch für die Reparatur von Transaktionen genutzt werden. Wenn eine Transaktion aufgrund niedriger Gebühren auf der Kette stecken bleibt, kann leicht eine andere Transaktion erstellt werden, um die Gebühr zu erhöhen, ohne dass neue Signaturen erforderlich sind. Bei Geldbörsen mit mehreren Signaturen vereinfachen zudem Signaturen, die nicht von der ausgegebenen Eingabe abhängen, den Betrieb.

Durch die Beseitigung der zirkulären Abhängigkeit zwischen scriptPubKeys und Eingabe-TXIDs kann der APO eine Introspektion durch Hinzufügen von Ausgabedaten im Zeugen erreichen, obwohl dies immer noch zusätzlichen Zeugen-Datenraum erfordert.

Bei Off-Chain-Protokollen wie dem Lightning Network und Tresoren reduziert APO die Notwendigkeit der Speicherung von Zwischenzuständen, was die Speicheranforderungen und die Komplexität erheblich verringert. Der direkteste Anwendungsfall für APO ist Eltoo, das Channel Factories vereinfacht, leichtgewichtige und kostengünstige Wachtürme konstruiert und einseitige Ausgänge ermöglicht, ohne fehlerhafte Zustände zu hinterlassen, wodurch die Leistung des Lightning Network verbessert wird. APO kann die Funktionalität von CTV simulieren, erfordert jedoch die persönliche Speicherung von Signaturen und vorab signierten Transaktionen, was es kostspieliger und weniger effizient als CTV macht.

Der Hauptkritikpunkt von APO ist die Notwendigkeit einer neuen Schlüsselversion, die es mit bestehenden Systemen inkompatibel macht. Außerdem könnte der neue Signatur-Hashtyp potenzielle Risiken für Doppelausgaben mit sich bringen. Nach ausführlichen Diskussionen in der Gemeinschaft erfordert APO nun zusätzlich zur Originalsignatur eine gewöhnliche Signatur, wodurch die Sicherheitsbedenken ausgeräumt wurden und es seine BIP-118-Nummer erhielt.

OP_VAULT BIP-345

BIP-345 schlägt zwei neue Opcodes vor, OP_VAULT und OP_VAULT_RECOVER, um mit CTV zu arbeiten und eine spezielle Vereinbarung zu implementieren, die eine Verzögerungszeit für die Ausgabe bestimmter Token erzwingt, während der die Ausgabe über einen Wiederherstellungspfad „widerrufen“ werden kann.

Benutzer können einen Tresor anlegen, indem sie eine bestimmte Taproot-Adresse einrichten und mindestens zwei Skripte in die MAST einfügen: ein OP_VAULT-Skript, um den erwarteten Abhebungsprozess zu erleichtern, und ein OP_VAULT_RECOVER-Skript, um die Rückgewinnung der Münzen vor Abschluss der Abhebung sicherzustellen.

Wie erreicht OP_VAULT unterbrechbare zeitlich gesperrte Entnahmen?

Vereinfacht ausgedrückt, ersetzt der Opcode OP_VAULT das verbrauchte OP_VAULT-Skript durch ein bestimmtes Skript, wobei ein einzelner Blattknoten in der MAST aktualisiert wird, während der Rest unverändert bleibt. Dies ist vergleichbar mit TLUV, ohne jedoch interne Schlüsselaktualisierungen zu unterstützen.

Die Einführung einer Vorlage bei Skriptaktualisierungen kann die Auswirkungen von Zahlungen einschränken. Der Parameter für die Zeitsperre wird durch OP_VAULT angegeben, während die durch den CTV-Opcode eingebrachte Schablone die Menge der über diesen Skriptpfad ausgegebenen Ausgaben einschränkt.

Das BIP-345 wurde für Tresore entwickelt und ermöglicht es den Benutzern, einen hochsicheren Wiederherstellungspfad (Papiergeldbörse, verteilte Mehrfachsignatur) zu nutzen und gleichzeitig eine Ausgabenverzögerung für Routinezahlungen zu konfigurieren. Das Gerät des Benutzers überwacht kontinuierlich die Ausgaben des Tresors und ermöglicht die Wiederherstellung, wenn eine nicht autorisierte Übertragung stattfindet.

Die Implementierung von Tresoren mit BIP-345 erfordert die Berücksichtigung von Gebührenfragen, insbesondere bei Rückgewinnungstransaktionen. Mögliche Lösungen sind CPFP (Child Pays for Parent), temporäre Verankerungen und neue Signatur-Hash-Flags wie SIGHASH_GROUP.

TLUV (TapleafUpdateVerify)

Das TLUV-Schema baut auf Taproot auf und zielt darauf ab, das Problem des effizienten Austritts aus gemeinsam genutzten UTXOs zu lösen. Das Leitprinzip besteht darin, dass wir, wenn eine Taproot-Ausgabe ausgegeben wird, die interne Struktur der Taproot-Adresse und kryptografische Transformationen nutzen können, um den internen Schlüssel und die MAST gemäß den im TLUV-Skript beschriebenen Aktualisierungsschritten teilweise zu aktualisieren und so die Vertragsfunktionalität zu erreichen.

Die Idee des TLUV-Schemas besteht darin, eine neue Taproot-Adresse auf der Grundlage der aktuellen Ausgabeneingabe durch einen neuen Opcode TAPLEAF_UPDATE_VERIFY zu erstellen, der eine oder mehrere der folgenden Operationen durchführen kann:

• Aktualisierung des internen öffentlichen Schlüssels
• Trimmen des Merkle-Pfads
• Den aktuell ausgeführten Blattknoten entfernen
• Hinzufügen eines neuen Blattknotens am Ende des Merkle-Pfads

TLUV benötigt insbesondere drei Eingaben:

1. Eine Spezifikation, wie der interne öffentliche Schlüssel zu aktualisieren ist
2. Ein neuer Blattknoten für den Merkle-Pfad
3. Eine Angabe darüber, ob der aktuelle Blattknoten zu entfernen ist und/oder wie viele Merkle-Pfad-Blattknoten zu entfernen sind

Der TLUV-Opcode berechnet den aktualisierten scriptPubKey und überprüft, ob die der aktuellen Eingabe entsprechende Ausgabe für diesen scriptPubKey ausgegeben wird.

Die Inspiration für TLUV sind Münzpools. Heutzutage können gemeinsame Pools mit vor-signierten Transaktionen erstellt werden, aber wenn man erlaubnisfreie Exits erreichen will, muss man eine exponentiell wachsende Anzahl von Signaturen erstellen. TLUV ermöglicht erlaubnisfreie Ausstiege ohne vorunterzeichnete Transaktionen. Ein Beispiel: Eine Gruppe von Partnern nutzt Taproot, um ein gemeinsames UTXO aufzubauen und ihre Mittel zu bündeln. Sie können Gelder intern mit dem Taproot-Schlüssel verschieben oder gemeinsam signieren, um externe Zahlungen vorzunehmen. Einzelne Personen können den gemeinsamen Pool jederzeit verlassen und damit ihren Zahlungspfad aufheben, während andere die Zahlungen weiterhin über den ursprünglichen Pfad abwickeln können, ohne zusätzliche Informationen über die verbleibenden Mitglieder preiszugeben. Diese Methode ist im Vergleich zu nicht gepoolten Transaktionen effizienter und privater.

Mit dem TLUV-Opcode werden partielle Ausgabenbeschränkungen durch Aktualisierung der ursprünglichen MAST erreicht. Er ermöglicht jedoch keine Introspektion der Ausgabebeträge. Daher wird ein neuer Opcode IN_OUT_AMOUNT benötigt, der zwei Daten auf den Stapel schiebt: den Betrag des UTXO dieser Eingabe und den entsprechenden Ausgabebetrag. Von der Person, die TLUV verwendet, wird dann erwartet, dass sie mathematische Operatoren verwendet, um zu überprüfen, ob die Mittel im aktualisierten scriptPubKey ordnungsgemäß erhalten sind.

Die Einsichtnahme in die Ausgabebeträge bringt eine weitere Komplexität mit sich, da Bitcoin-Beträge in Satoshis dargestellt werden und bis zu 51 Bit benötigen, Skripte aber nur 32-Bit-Mathematikoperationen zulassen. Dies erfordert ein Upgrade der Operatoren im Skript durch Neudefinition des Opcode-Verhaltens oder die Verwendung von SIGHASH_GROUP anstelle von IN_OUT_AMOUNT.

Es wird erwartet, dass TLUV Lösungen für dezentralisierte Layer-2-Münzpools bietet, obwohl die Zuverlässigkeit in Bezug auf das Tweaken der öffentlichen Taproot-Schlüssel noch bestätigt werden muss.

MATT

MATT (Merkleize All The Things) will drei Ziele erreichen: Die Merkleisierung des Zustands, die Merkleisierung von Skripten und die Merkleisierung der Ausführung, um so allgemeine intelligente Verträge zu erreichen.

• Zustand der Merkelbildung: Konstruieren Sie ein Merkle-Trie, bei dem jeder Blattknoten ein Hash des Zustands ist und die Merkle-Wurzel den gesamten Vertragszustand darstellt.
• Merkleizing-Skripte: Eine aus Tapscript konstruierte MAST, bei der jeder Blattknoten einen möglichen Zustandsübergangspfad darstellt.
• Merkleizing Execution: Erreicht durch kryptographische Zusagen und Betrugsanfechtungsmechanismen. Für jede Rechenfunktion können die Teilnehmer außerhalb der Kette Berechnungen durchführen und Verpflichtungen veröffentlichen, f(x)=y. Wenn andere Teilnehmer das Ergebnis f(x)=z finden, können sie es anfechten, und die Schlichtung erfolgt durch eine binäre Suche, ähnlich dem Optimistic Rollup-Prinzip.

Um MATT zu erreichen, müssen Bitcoin-Programmierskripte die folgenden Funktionalitäten aufweisen:

1. Erzwingen eines bestimmten Skripts für eine Ausgabe (und deren Beträge)
2. Daten an eine Ausgabe anhängen
3. Daten vom aktuellen Eingang (oder anderen Eingängen) lesen

Der zweite Punkt ist von entscheidender Bedeutung, da dynamische Daten eine Zustandsberechnung durch vom Spender bereitgestellte Eingabedaten ermöglichen, die einen Zustandsautomaten simulieren und den nächsten Zustand und die angehängten Daten bestimmen. MATT schlägt den Opcode OP_CHECKCONTRACTVERIFY (OP_CCV) vor, eine Kombination der zuvor vorgeschlagenen Opcodes OP_CHECKOUTPUTCONTRACTVERIFY und OP_CHECKINPUTCONTRACTVERIFY, mit einem zusätzlichen Flags-Parameter zur Angabe des Ziels der Operation.

Kontrolle der Ausgabemengen: Der direkteste Weg ist die direkte Introspektion. Die Ausgabebeträge sind jedoch 64-Bit-Zahlen, die 64-Bit-Operationen erfordern, was die Bitcoin-Skript-Implementierung komplexer macht. CCV wendet eine verzögerte Prüfung ähnlich wie OP_VAULT an, bei der die Eingabebeträge für alle Eingaben zur gleichen Ausgabe addiert werden, wobei CCV die Untergrenze dieses Ausgabebetrags darstellt. Die Prüfung wird auf den Transaktionsprozess verschoben und nicht während der Auswertung des Eingabeskripts.

Angesichts der Allgemeingültigkeit von Betrugsnachweisen sollten einige Varianten von MATT-Verträgen alle Arten von intelligenten Verträgen oder Schicht-2-Konstruktionen erreichen, obwohl zusätzliche Anforderungen (wie Kapitalbindung und Verzögerungen bei der Herausforderungsfrist) genau bewertet werden müssen. Weitere Forschung ist erforderlich, um zu bewerten, welche Anwendungen akzeptable Transaktionen sind. Zum Beispiel die Verwendung von kryptografischen Zusagen und Betrugsherausforderungsmechanismen zur Simulation von OP_ZK_VERIFY-Funktionen, um vertrauenslose Rollups auf Bitcoin zu erreichen.

In der Praxis ist dies bereits der Fall. Johan Torås Halseth implementierte elftrace unter Verwendung des OP_CHECKCONTRACTVERIFY-Opcodes aus dem MATT-Softfork-Vorschlag, der es ermöglicht, dass alle Programme, die von der RISC-V-Kompilierung unterstützt werden, auf der Bitcoin-Kette verifiziert werden können, was native Bitcoin-Verifikationsbrücken für Vertragsprotokolle ermöglicht.

CSFS (OP_CHECKSIGFROMSTACK)

Aus der Einführung des APO-Opcodes wissen wir, dass OP_CHECKSIG (und verwandte Operationen) für die Zusammenstellung von Transaktionen, das Hashing und die Signaturprüfung zuständig ist. Die zu prüfende Nachricht wird jedoch aus der Serialisierung der Transaktion mit diesem Opcode abgeleitet, so dass keine anderen Nachrichten angegeben werden können. Vereinfacht ausgedrückt dient OP_CHECKSIG (und verwandte Operationen) dazu, zu überprüfen, ob der UTXO als Transaktionsinput autorisiert ist, vom Signaturinhaber ausgegeben zu werden, und somit die Sicherheit von Bitcoin zu schützen.

CSFS prüft, wie der Name schon sagt, Signaturen aus dem Stack. Der CSFS-Opcode nimmt drei Parameter vom Stack entgegen: eine Signatur, eine Nachricht und einen öffentlichen Schlüssel, und prüft die Gültigkeit der Signatur. Das bedeutet, dass jede beliebige Nachricht mit Hilfe von Zeugendaten an den Stack übergeben und von CSFS überprüft werden kann, was einige Innovationen bei Bitcoin ermöglicht.

Die Flexibilität von CSFS ermöglicht die Implementierung verschiedener Mechanismen wie Zahlungssignaturen, Delegation von Befugnissen, Orakelverträge und Anleihen zum Schutz vor doppelten Ausgaben, vor allem aber die Introspektion von Transaktionen. Das Prinzip der Introspektion von Transaktionen mit CSFS ist sehr einfach. Wenn der von OP_CHECKSIG verwendete Transaktionsinhalt über den Zeugen auf den Stapel geschoben wird und derselbe öffentliche Schlüssel und dieselbe Signatur zur Verifizierung sowohl mit CSFS als auch mit OP_CHECKSIG verwendet werden, dann ist der Inhalt jeder an CSFS übergebenen Nachricht derselbe wie die von OP_CHECKSIG implizit verwendete serialisierte Ausgabetransaktion (und andere Daten). Wir erhalten dann geprüfte Transaktionsdaten auf dem Stack, die verwendet werden können, um mit anderen Opcodes Einschränkungen auf die Ausgabetransaktion anzuwenden.

CSFS erscheint oft mit OP_CAT, weil OP_CAT verschiedene Felder der Transaktion verketten kann, um die Serialisierung abzuschließen, was eine genauere Auswahl der Transaktionsfelder für die Introspektion ermöglicht. Ohne OP_CAT kann das Skript keine Hashes aus einzeln prüfbaren Daten neu berechnen, so dass es nur prüfen kann, ob ein Hash mit einem bestimmten Wert übereinstimmt, was bedeutet, dass Münzen nur durch eine einzige bestimmte Transaktion ausgegeben werden können.

CSFS kann Opcodes wie CLTV, CSV, CTV, APO erreichen und ist ein allgemeiner Introspektions-Opcode, der auch Layer-2-Skalierungslösungen für Bitcoin unterstützt. Sein Nachteil ist, dass er eine vollständige Kopie der signierten Transaktion zum Stack hinzufügt, was die Größe von Transaktionen, die CSFS für die Introspektion nutzen wollen, erheblich erhöhen kann. Im Gegensatz dazu haben Einzweck-Introspektions-Opcodes wie CLTV und CSV den geringsten Overhead, aber das Hinzufügen jedes neuen speziellen Introspektions-Opcodes erfordert Änderungen am Konsens.

TXHASH (OP_TXHASH)

OP_TXHASH ist ein sehr einfacher Introspektions-Opcode, der es dem Operator ermöglicht, den Hash eines Feldes auszuwählen und ihn auf den Stack zu schieben. Konkret holt OP_TXHASH ein txhash-Flag vom Stack, berechnet einen (mit einem Flag versehenen) txhash auf der Grundlage des Flags und schiebt den resultierenden Hash auf den Stack.

Aufgrund der Ähnlichkeit zwischen TXHASH und CTV gab es in der Community eine umfangreiche Diskussion über die beiden.

TXHASH kann als allgemeines Upgrade von CTV angesehen werden und bietet eine fortschrittlichere Transaktionsvorlage, die es den Benutzern ermöglicht, Teile der Ausgabentransaktion zu spezifizieren, wodurch viele Probleme im Zusammenhang mit Transaktionsgebühren gelöst werden. Im Gegensatz zu anderen Vertrags-Opcodes ist es bei TXHASH nicht erforderlich, eine Kopie der erforderlichen Daten im Zeugen bereitzustellen, was den Speicherbedarf weiter reduziert. Im Gegensatz zu CTV ist TXHASH nicht NOP-kompatibel und kann nur in tapscript implementiert werden. Die Kombination aus TXHASH und CSFS kann als Alternative zu CTV und APO betrachtet werden.

Was die Konstruktion von Verträgen betrifft, so ist es mit TXHASH einfacher, „additive Verträge“ zu erreichen, indem alle Teile der Transaktionsdaten, die man fixieren möchte, auf den Stack gelegt werden, zusammengehasht werden und überprüft wird, ob das Ergebnis mit einem festen Wert übereinstimmt. Mit CTV ist es einfacher, „subtraktive Verträge“ zu erreichen, indem man alle Teile der Transaktionsdaten, die frei bleiben sollen, auf den Stack legt. Dann wird unter Verwendung von rollierendem OP_SHA256, ausgehend von einem festen Zwischenzustand, dieser Zwischenzustand das Hashdatenpräfix der Transaktion festschreiben. Die freien Teile werden in diesen Zwischenzustand gehasht.

Es wird erwartet, dass das in der TXHASH-Spezifikation definierte Feld TxFieldSelector auf andere Opcodes, wie OP_TX, ausgedehnt wird.

Das BIP für TXHASH befindet sich derzeit im Entwurfsstatus auf Github und hat noch keine Nummer erhalten.

OP_CAT

OP_CAT ist ein etwas mysteriöser Opcode, der von Satoshi Nakamoto aufgrund von Sicherheitsbedenken veraltet wurde. Er hat jedoch kürzlich eine ausführliche Diskussion unter den Bitcoin-Core-Entwicklern ausgelöst und wurde sogar zu einem Meme in der Online-Community. Letztendlich wurde OP_CAT als BIP-347 genehmigt, wobei viele ihn als den wahrscheinlichsten BIP-Vorschlag bezeichnen, der in naher Zukunft verabschiedet wird.

In Wirklichkeit ist das Verhalten von OP_CAT sehr einfach: Es verkettet zwei Elemente auf dem Stapel zu einem. Aber wie wird dadurch die Vertragsfunktionalität ermöglicht?

Die Funktion der Verkettung von zwei Elementen entspricht einer leistungsstarken kryptografischen Datenstruktur, die als Merkle Trie bekannt ist. Die Konstruktion eines Merkle Trie erfordert nur Verkettungs- und Hashing-Operationen, die beide in Bitcoin-Skripten verfügbar sind. Daher können wir mit OP_CAT theoretisch Merkle-Beweise in Bitcoin-Skripten verifizieren, was die gängigste leichtgewichtige Verifizierungsmethode in Blockchains ist.

Wie bereits erwähnt, kann CSFS OP_CAT nutzen, um ein allgemeines Vertragsschema zu erreichen. Aber auch ohne CSFS ermöglicht die Struktur der Schnorr-Signaturen OP_CAT selbst die Introspektion von Transaktionen.

Bei einer Schnorr-Signatur setzt sich die zu signierende Nachricht aus den folgenden Feldern zusammen:

• Version
• Sperrzeit
• Anzahl der Eingaben
• Anzahl der Ausgaben
• Liste der Eingaben (jeweils mit Hash der vorherigen Transaktion, Index, Skriptlänge, Skript, Sequenz)
• Liste der Ausgaben (jeweils mit Wert, Skriptlänge, Skript)

Diese Felder enthalten die wichtigsten Elemente einer Transaktion. Indem wir sie in scriptPubKey oder witness platzieren und OP_CAT und OP_SHA256 verwenden, können wir eine Schnorr-Signatur konstruieren und sie mit OP_CHECKSIG verifizieren. Wenn die Verifizierung erfolgreich ist, behält der Stack die verifizierten Transaktionsdaten und ermöglicht die Introspektion der Transaktion. Dies ermöglicht uns, verschiedene Teile der Transaktion zu extrahieren und zu „inspizieren“, wie z.B. ihre Eingänge, Ausgänge, Zieladressen oder beteiligten Bitcoin-Beträge.

Ausführlichere kryptografische Grundsätze finden Sie in Andrew Poelstras Artikel „CAT und Schnorr-Tricks“.

Zusammenfassend lässt sich sagen, dass OP_CAT aufgrund seiner Flexibilität in der Lage ist, fast jeden Vertrags-Opcode zu imitieren, und dass viele Vertrags-Opcodes von seiner Funktionalität abhängen. Dies bringt seine Position auf der Merge-Liste deutlich voran. Theoretisch könnten wir nur mit OP_CAT und bestehenden Bitcoin-Opcodes einen vertrauensminimierten BTC ZK Rollup konstruieren. Starknet, Chakra und andere Ökosystempartner arbeiten aktiv daran, dies zu ermöglichen.

Schlussfolgerung

Während wir verschiedene Strategien untersuchen, um Bitcoin zu erweitern und seine Programmierbarkeit zu verbessern, wird deutlich, dass der Weg in die Zukunft eine Kombination aus nativen Verbesserungen, Off-Chain-Berechnungen und komplexen Skript-Funktionalitäten beinhaltet.

Ohne eine flexible Basisschicht ist es unmöglich, eine flexiblere zweite Schicht aufzubauen.

Die Skalierbarkeit von Berechnungen außerhalb der Kette ist die Zukunft, aber die Programmierbarkeit von Bitcoin muss sich durchsetzen, um die Skalierung besser zu unterstützen und eine echte Weltwährung zu werden.

Die Bitcoin-Berechnungen unterscheiden sich jedoch grundlegend von den Ethereum-Berechnungen. Bitcoin unterstützt nur die „Verifizierung“ als eine Form der Berechnung, während Ethereum grundsätzlich rechnerisch arbeitet und die Verifizierung nur ein Nebenprodukt ist. Dieser Unterschied zeigt sich darin, dass Ethereum Gasgebühren für fehlgeschlagene Transaktionen erhebt, während Bitcoin dies nicht tut.

Verträge stellen eine Form von intelligenten Verträgen dar, die eher auf Verifizierung als auf Berechnung basieren. Abgesehen von ein paar strikten Satoshi-Fundamentalisten glauben die meisten Menschen, dass Verträge eine gute Wahl sind, um Bitcoin zu verbessern. Allerdings debattiert die Gemeinschaft ständig darüber, welches Schema für die Implementierung von Verträgen verwendet werden soll.

APO, OP_VAULT und TLUV sind eher für direkte Anwendungen geeignet. Mit ihnen lassen sich bestimmte Anwendungen kostengünstiger und effizienter implementieren. Lightning Network-Enthusiasten bevorzugen APO, weil es LN-Symmetrie erreicht; wenn Sie einen Tresor erstellen wollen, ist es am besten, OP_VAULT zu verwenden; um einen CoinPool aufzubauen, ist TLUV privater und effizienter. OP_CAT und TXHASH sind allgemeiner, weisen weniger Sicherheitslücken auf und können durch Kombination mit anderen Opcodes mehr Anwendungsfälle abdecken, wenn auch möglicherweise auf Kosten der Skriptkomplexität. CTV und CSFS haben den Ansatz der Blockchain-Verarbeitung angepasst: CTV implementiert verzögerte Ausgaben, und CSFS implementiert verzögerte Signaturen. MATT ist relativ einzigartig, da es optimistische Ausführung und Betrugsnachweise verwendet und sich auf die Merkle-Trie-Struktur stützt, um allgemeine intelligente Verträge zu erreichen, obwohl es immer noch neue Opcodes benötigt, um Introspektionsfähigkeiten zu bieten.

Wir sehen, dass die Bitcoin-Gemeinschaft bereits intensiv über die Möglichkeit diskutiert, Verträge durch eine Soft Fork einzuführen. Starknet hat offiziell seinen Eintritt in das Bitcoin-Ökosystem angekündigt und plant, die Abrechnung im Bitcoin-Netzwerk innerhalb von sechs Monaten nach der OP_CAT-Verschmelzung zu implementieren. Chakra wird weiterhin die neuesten Entwicklungen im Bitcoin-Ökosystem beobachten, den OP_CAT Soft Fork Merge vorantreiben und die Programmierbarkeit, die durch Introspektion und Verträge entsteht, nutzen, um eine sicherere und effizientere Bitcoin-Abwicklungsschicht aufzubauen.