Seitdem die Bitcoin-Community mit Diskussionen über die Optimierung von Covenants begonnen hat, besteht ein wachsendes Interesse daran, mehr über deren Kompromisse und die bereits im Liquid Network eingesetzten Covenants (digitale Pakte, bei denen Bitcoin gewissen Einschränkungen bezüglich der nächsten Transaktion unterworfen werden) zu erfahren.
Angesichts dieses erneuerten Interesses und um weitere Diskussionen anzuregen, möchten wir einen Blick auf einige der aktuellen Covenant-Angebote auf Liquid werfen, sie mit den führenden Vorschlägen für Bitcoin vergleichen, und ihre jeweiligen Anwendungsfälle untersuchen.
Geschichte der Covenants auf Liquid
Covenants im Liquid-Netzwerk lassen sich bereits in der Installation der ersten Elements-Sidechain, Alpha, aufspüren. Diese Sidechain führte unter anderem die Opcodes OP_CHECKSIGFROMSTACK (CSFS) und OP_DETERMINISTICRANDOM in Elements ein. Alpha ermöglichte ausserdem feste Versionen von Opcodes, die im frühen Bitcoin deaktiviert waren, wie z. B. OP_CAT – ein Opcode, den viele im aktuellen Diskurs auf den sozialen Medien erneut aufgreifen. Diese neuen Opcodes haben die Ausdruckskraft der in Elements verfügbaren Version von Bitcoin Script weiter verbessert, und zur Veranschaulichung der neuen Möglichkeiten wurde ein Proof of Concept Möser-Eyal-Sirer Vault mithilfe von CSFS entwickelt.
Eine der Erkenntnisse aus der Implementierung von CSFS bestand darin, dass es die Covenants komplexer macht, da bei der Durchführung einer Covenant-Ausgabe Transaktionsdaten auf den Stack geschoben werden müssen. In der Erfahrung von Entwicklern wurde auch beobachtet, dass bei CSFS-Covenants die Transaktionsdaten, aus denen der Signatur Hash besteht, auf dem Stack rekonstruiert werden müssen, was Entwickler möglicherweise dazu zwingt, Daten zu pushen, obwohl sie irrelevant sind für die Transaktionsein- und -ausgaben, an denen sie interessiert sind.
Um die Konstruktion von Covenants zu vereinfachen, wurden im Taproot Upgrade von Liquid mehr als 30 neue Opcodes, sogenannte Introspection Opcodes, für einen stärker modularen Ansatz eingeführt. Introspection Opcodes mit CSFS ermöglichen beispielsweise die Untersuchung feinerer Teile der Transaktion während einer Ausgabe, indem man sie auf den Stack legt. Dadurch entfällt die Verantwortung für die Zusammenstellung unvollständiger Transaktionsdaten über den Witness und folglich den Signatur Hash auf dem Stapel.
Führende Covenant Vorschläge
Derzeit diskutiert die Bitcoin Community eine lange Liste potenzieller Covenant Vorschläge, darunter SIGHASH_ANYPREVOUT (APO), OP_TXHASH, CSFS, OP_CAT, OP_TLUV, den MATT Opcode OP_CHECKCONTRACTVERIFY (CCV), OP_VAULT und OP_CHECKTEMPLATEVERIFY (CTV). Ebenfalls ist Simplicity, eine Skriptsprache der nächsten Generation, die ähnliche Funktionen wie viele Covenants auf einer tieferen Ebene implementieren könnte, ein potenzieller Weg für Bitcoin (wir werden später noch einmal darauf zurückkommen).
Christian Lewe vom Blockstream Research Team diskutiert Simplicity und wie der Einsatz von Kombinatoren und Jets die Funktionalität beliebter Covenants wie CTV und APO mit einem einzigen Soft Fork ermöglichen könnte.
Es wurde viel über den VAULT Opcode gesprochen, der entwickelt wurde, um den Bedarf an einfacheren Möglichkeiten zur Sicherung von Bitcoin für Benutzer zu decken. Dieser Opcode würde es ermöglichen, Coins an eine Adresse zu schicken, von der aus nur an zwei Adressen ausgegeben werden kann: eine Hot Wallet nach einer Zeitsperre oder sofort an eine Cold Wallet. Es wurden mehrere andere Varianten vorgeschlagen, die jedoch zunächst auf die Einführung von CTV angewiesen sind.
CTV ist ein Opcode, der einen Hash vom Stack liest und ihn mit einem Hash einer bestimmten Teilmenge der Transaktionsdaten einer Ausgabe vergleicht. Seine Flexibilität verspricht eine Vielzahl von Anwendungen, darunter unter anderem: Congestion Control, Vaults und rudimentäre Zahlungspools.
Abgesehen von Opcodes gab es Vorschläge, Covenants mithilfe von Sighashes zu ermöglichen. Die beiden beliebtesten Vorschläge für diesen Zweck sind APO und SIGHASH_GROUP. APO ist eine Weiterentwicklung des Opcodes SIGHASH_NOINPUT, der allgemein als Voraussetzung für die Implementierung von eltoo gilt. Eine der vielen Verbesserungen, die eltoo ermöglicht, ist die Abschaffung des Bestrafungs-Mechanismus, der die Gegenpartei zur vollständigen Einbuße des eingesetzten Geldes zwingt, wenn diese einen veralteten Kanalstatus verbreitet. Dies ermöglicht ein benutzerfreundlicheres und effizienteres Lightning-Netzwerk.
Vergleichbare Funktionalität erlangen mithilfe von Liquid Opcodes
Während Liquid nicht über die CTV und VAULT Opcodes verfügt, umfasst es jedoch CSFS und CAT für Covenants. Durch die Verwendung dieser enger definierten Opcodes mit den oben genannten Introspection Opcodes haben Entwickler neue finanzielle Möglichkeiten mit einer Funktionalität, die vergleichbar ist mit CTV und VAULT, zur Augmentierung der Sidechain eröffnet.
Beispielsweise hat Burak, ein erfahrener Liquid-Entwickler und Schöpfer des Layer 2-Protokolls Ark, in einer Diskussion mit James O’Beirne auf X eine Emulation von VAULT unter Verwendung von Liquid Covenant Opcodes demonstriert.
In ähnlicher Weise wurde mit CSFS eine Möglichkeit geschaffen, APO-unktionalität zu erreichen. Diese Demo nutzte verschiedene Opcodes, die heute Layer 2-Protokolle wie eltoo auf Liquid ermöglichen würden, leidet aber im Vergleich zur vorgeschlagenen Verwendung des APO Typ Covenants unter zusätzlicher Komplexität und einer grösseren Transaktionsgrösse. Darüber hinaus gilt die Konstruktion nicht für Taproot-Transaktionen, was eine eigene Form zusätzlicher Komplexität mit sich bringen würde.
Liquid Opcodes in Aktion
Viele Anwendungen haben bereits die Vorteile von Covenant Opcodes auf Liquid genutzt. Steven Roose, ein Covenant-Befürworter, der kürzlich eine Spezifikation für das zuvor geplante OP_TXHASH definiert hat, hat eine Applikation für Fidelity Bonds (Treuhandanleihen) auf Liquid entwickelt. Dieser Covenant gilt für Gelder, die verbrannt würden, wenn im Witness Beweise für ein Double Spend (mehrfaches Ausgeben desselben Geldes) vorgelegt würden.
Ein weiteres bemerkenswertes Beispiel ist Fuji USD (FUSD) von Fuji Money, ein algorithmischer Stablecoin, der von Vulpem Ventures entwickelt wurde. Sie stützt sich ausschliesslich auf Oracle-Informationen, um ihre Bindung aufrechtzuerhalten, und kann dezentral ausgegeben werden. Um dies zu erreichen, wird eine Kombination aus Signatur-Checks und Introspektions-Opcodes verwendet, und der wichtigste Teil ist, dass alles onchain überprüfbar ist.
Zu den weiteren Anwendungen von Covenants auf Liquid gehören Optionsverträge und vertrauliche assetbasierte Darlehen. Das Team von Blockstream Research veröffentlichte letztes Jahr ein Whitepaper (siehe begleitender Blog Post) über ersteres und erläuterte, wie ein solcher Optionsvertrag mithilfe der neuen Gruppe introspektiver Opcodes erstellt werden könnte. Diese neuen Opcodes ermöglichen es Benutzern, vertrauenslos Tokens zu erstellen, die beide Seiten eines abgedeckten Call-Optionsvertrags repräsentieren, und die entgegengesetzte Position verkaufen, die sie einnehmen möchten. Auf diese Weise abgeschlossene Verträge unterstützen auch partielle Ausführungen, was bedeutet, dass der Benutzer, der den Vertrag erstellt hat, Positionen verkaufen kann, die ein Vielfaches eines vom Benutzer festgelegten Mindestbetrags an Kollateralvermögen darstellen, der als „Vertragsgröße“ bezeichnet wird.
Erfahren Sie mehr über die auf Liquid verfügbaren Opcode Covenants und wie sie Atomic Swaps ermöglichen. Das Video behandelt die Geschichte von Atomic Swaps, gibt Beispiele für einige Dienste und Produkte, die sie in unterschiedlichen Funktionen nutzen, und untersucht den Typescript Code unter Verwendung einer Library namens LiquidJS, der für diese Art von Covenants erforderlich ist.
Warum nicht zuerst auf Liquid?
Während im Bitcoin-Ökosystem weiterhin eine lebhafte Debatte über Covenant Opcodes geführt wird, bietet Liquid seine eigenen Tools an, die ähnliche Ziele verfolgen, jedoch unterschiedliche Implementierungen aufweisen. Während sich das Gespräch intensiviert, wird es interessant sein, das Zusammenspiel zwischen den nativen Vorschlägen von Bitcoin und den bereits konkreten und aktiven Covenant bezogenen Funktionen von Liquid sowie der Emulation von Vorschlägen für Bitcoin Covenants zu beobachten, die mithilfe von Elements Script implementiert werden.
Eine weitere neue Technologie am Horizont ist Simplicity, eine verifizierbare Programmiersprache für die Blockchain. Die Simplicity-Sprache wird durch Operationen mit sehr enger Semantik definiert, die zusammen ausdrucksstarke Programme erstellen können. Die Tatsache, dass diese Sprache verifizierbar ist, bedeutet, dass Methoden etabliert werden können, um Behauptungen, die in Simplicity Programmen gemacht werden, mathematisch zu beweisen.
Die ausdruckskräftige Natur von Simplicity ermöglicht die nahtlose Portierung von Covenant Opcodes aus Script, was mehr Zuverlässigkeit und weniger unerwartete Verhaltensweisen gewährleistet. Der Bitcoin Forscher Sanket Kanjalkar hat diese Arbeit bereits für CTV durchgeführt. Mit s-lang, einer besser lesbaren Bitcoin-zentrierten Programmiersprache, die sich bis herunter auf Simplicity kompilieren lässt, konnte er die Semantik in einem praktikablen Proof of Concept nachbilden, der heute jedem zum Ausprobieren zur Verfügung steht.
Dank der für das zweite Quartal 2024 geplanten Integration von Simplicity in Liquid werden Bitcoin-Entwickler bald die Möglichkeit haben, s-lang in einer realen Umgebung zu verwenden. s-lang wird die Erstellung komplexerer Anwendungen wie Vaults und Delegation in Liquid ermöglichen. Der PR Draft kann unter diesem Link eingesehen werden.
Angesichts der langen Geschichte von Liquid als Erstanwender von Ideen, die später auf Bitcoin übertragen wurden, empfiehlt es sich für diejenigen, die die Realisierbarkeit ihrer Vorschläge demonstrieren möchten, es live auf Liquid auszuprobieren, um Ideen zunächst zu validieren – denn bei mehreren Covenant-Opcodes hat sich herausgestellt, dass sie mittels bereits existierenden Liquid Covenant und Introspection Opcodes emulierbar sind.
Wenn also das nächste Mal jemand einen neuen Covenant vorschlägt, lohnt es sich zu fragen: Warum nicht zuerst auf Liquid ausprobieren?
Eine frühere Version dieses Artikels wurde ursprünglich im Bitcoin Magazine veröffentlicht: https://bitcoinmagazine.com/technical/before-they-were-cool-covenants-in-produktion-on-liquid