In jüngster Zeit hat das Konzept der sogenannten Covenants erneut Beachtung gefunden, da die Bitcoin-Entwicklungs- und Protokolldiskussionen eine Renaissance erlebten. Vereinbarungen könnten eine breite Palette von Anwendungen ermöglichen und erleichtern, darunter neue vertrauenswürdige und skalierbare Layer 2svollständig nicht verwahrte Tresore mit komplexerer Ausgabenlogik und effizienter Zahlungskanäle. Die meisten Wege zur Implementierung dieser Funktionalität erfordern jedoch eine Soft Fork der Konsensregeln von Bitcoinein Prozess, der wahrscheinlich eine Debatte innerhalb der Community auslösen würde.
Mit der jüngsten Diversifizierung der Konsenskunden in Core- und Knots-Knoten ist es weniger wahrscheinlich, dass eine Einigung über eine solche Änderung erzielt wird. Obwohl sie kürzlich auf eine eigene Soft-Fork gedrängt haben, nämlich BIP-110Die Knots-Seite befürwortet tendenziell eine Protokollverknöcherung und scheint die Erleichterung von Skalierungslösungen auf der Basisschicht weniger zu unterstützen. Die jüngste Kontroverse, die Bitcoin Core hervorgerufen hat, sowohl als auch in der technischen Debatte und in der Governanceverringert die Aussicht auf baldige Vertragsumsetzungen bei Bitcoin.
Prominente Persönlichkeiten wie Michael Saylor haben das auch getan öffentlich für die Protokollverknöcherung plädiertund stellt eifrige, gut finanzierte Entwickler als die größte Bedrohung für das Protokoll dar. Nichtsdestotrotz bietet die Implementierung einer minimalen Vereinbarung wahrscheinlich den konservativsten Weg zu vertrauensminimierten Layer-2-Systemen, die der nächsten Milliarde Menschen die Privilegien der Selbstverwahrung ermöglichen können. Sollten die Mainnet-Gebühren in Zukunft erneut steigen und eine Lösung für die Spam-Kriege gefunden werden, werden die Diskussionen um diese Vorschläge wahrscheinlich wieder an Dynamik gewinnen. In diesem Artikel legen wir einige Grundlagen dafür, dass unsere Leser Bündnisse verstehen. In Folgebeiträgen werden wir uns eingehend mit den einzelnen Vorschlägen befassen.
Um Covenant-Vorschläge zu verstehen, ist es notwendig, den grundlegenden Validierungsablauf für Bitcoin-Transaktionen zu verstehen. Bitcoin-Sperrbedingungen werden in einer stapelbasierten, nicht Turing-vollständigen Sprache namens „ Bitcoin-Skript. Der Absender einer Bitcoin-Transaktion legt die Ausgabebedingungen in dieser Sprache fest, indem er ein sogenanntes Locking-Skript (auch bekannt als) erstellt scriptPubKey). Wenn der Empfänger der Gelder die Ausgaben später ausgeben möchte, muss er das entsprechende Entsperrskript (auch bekannt als) bereitstellen scriptSig), das diese Bedingungen erfüllt. Die Skriptsprache von Bitcoin kann eine Vielzahl von Validierungsbedingungen ausdrücken. Es kann Signaturen öffentlicher Schlüssel überprüfen, Zeitsperren erzwingen, Hash-Vorbilder überprüfen und Ausgabebedingungen mit Aussagenlogik kombinieren. Eine Entität mit dem richtigen Entsperrskript kann die Bitcoin an einen beliebigen Ort verschieben, sie also mit einem beliebigen Skript-PubKey belasten. Es können jedoch keine Beschränkungen für den Versand von Geldern festgelegt werden, nachdem die korrekte scriptSig bereitgestellt wurde.
Genau diese Funktion soll durch Vereinbarungen ermöglicht werden. Vereinbarungen würden es Benutzern ermöglichen, Beschränkungen für die künftige Verwendung von Münzen festzulegen. Der Konzept wurde eingeführt von Gregory Maxwell bereits im Jahr 2013, um die Skalierbarkeit und Flexibilität von Bitcoin zu verbessern. Es war später populär gemacht von Möser, Eyal und Sirer im Jahr 2016. Zunächst Maxwell vorgeschlagen Verwendung von zk-SNARKs zur Durchsetzung von Ausgabenbeschränkungen. Seitdem gab es in der Diskussion eine Explosion unterschiedlicher Vorschläge, die in einigen gipfelten, die die Anforderung einer Soft Fork umgehen könnten.
Grundlegende (oder vorberechnete) versus allgemeine (oder rekursive) Vereinbarungen
Ein wesentlicher Unterschied bei Vertragsvorschlägen besteht zwischen grundlegenden (oder vorberechneten) und allgemeinen (oder rekursiven) Verträgen. Grundsätzlich beschränken Basic Covenants nur die nächste Transaktion. Durch die Verkettung belasteter Adressen können Basisvereinbarungen jedoch auch dazu genutzt werden, eine endliche Abfolge von Transaktionen im Voraus zu definieren. Diese Abfolge erlaubter Transaktionen kann zwar beliebig lang oder komplex sein, muss aber vorher festgelegt werden.
Allgemeine Vereinbarungen könnten rekursive Ausgabenregeln direkt in Bitcoin Script ausdrücken. Dadurch kann eine Ausgabebedingung auf unbestimmte Zeit erneut angewendet werden. Wenn Alice beispielsweise Bob 1 BTC schickte, könnte eine Basisvereinbarung sicherstellen, dass Bob das Geld nur an eine bestimmte Adresse senden kann oder es für eine feste Anzahl von Schritten belastet. Unter einer allgemeinen Vereinbarung würde der UTXO im Wert von 1 BTC jedoch dieselben Ausgabenbeschränkungen behalten, wenn Bob ihn an Steve sendet und erneut, wenn Steve ihn weiter überträgt, ohne einen vordefinierten Endpunkt. Obwohl allgemeine Vereinbarungen eine größere Vielseitigkeit bieten würden, stehen sie vor erheblichen technischen Hürden und werden von der Community kritisch gesehen. Ihre Umsetzung würde ebenfalls erfordern wichtige Protokollaktualisierungen.
Vorgeschlagene Vertragsumsetzungen und ihre Anwendungen
Verschiedene Umsetzungsvorschläge und Debatten haben unser Verständnis darüber geprägt, wie Vereinbarungen die Funktionalität von Bitcoin verbessern könnten. Um sich in diesem Thema klar zurechtzufinden, ist es wichtig, die vorgeschlagenen Änderungen in vier Kategorien zu unterscheiden:
- Opcodes, die die Covenant-Funktionalität vollständig implementieren. Sie erlegen direkt Ausgabenbeschränkungen für Bitcoin-Transaktionen auf. Dazu gehört OP_CHECKTEMPLATEVERIFY Und SIGHASH_ANYPREVOUT.
- Opcodes, die als unterstützende Werkzeuge dienen. Diese erweitern die Ausdruckskraft des Bitcoin-Skripts oder der Datenverarbeitung, implementieren jedoch keine Covenant-Funktionalität, sofern sie nicht mit anderen Opcodes kombiniert werden. In dieser Kategorie werden wir diskutieren OP_CHECKSIGFROMSTACK Und OP_CAT.
- Opcodes für spezielle Anwendungen. Wir überlegen OP_VAULT, OP_UNVAULT Und OP_EVICT.
- Vorschläge, die das Covenant-Verhalten ohne Soft Fork annähern. Diese basieren auf kryptografischen Konstruktionen innerhalb bestehender Konsensregeln oder einer vertrauensminimierten Infrastruktur und nicht auf neuen Opcodes. In dieser Kategorie besprechen wir ColliderScript, Bitcoin PIPE und FE-basierte Vereinbarungen.
In unserem nächsten Artikel beginnen wir unsere Diskussion der ersten Kategorie von Covenant-Vorschlägen mit der Behandlung von OP_CHECKTEMPLATEVERIFY – einem der bislang beliebtesten Vorschläge.
