Direkt zum Hauptinhalt

Bitcoins Covenant-Renaissance: Wie OP_CTV, LNHANCE, OP_CAT und BitVM2 endlich Smart Contracts auf Bitcoin L1 bringen könnten

· 14 Min. Lesezeit
Dora Noda
Dora Noda
Software Engineer

Seit fünfzehn Jahren ist die Script - Sprache von Bitcoin bewusst und aggressiv langweilig. Keine Schleifen. Keine Rekursion. Kein Status. Ein kleiner Stack, eine Handvoll Opcodes und eine Kultur, die jede vorgeschlagene Erweiterung wie einen potenziellen Bürgerkrieg behandelt. Dieser Konservatismus ist der Grund, warum Bitcoin auf der Konsensschicht nie erfolgreich ausgenutzt wurde – und der Grund, warum Entwickler, die mehr als nur „Coins von A nach B senden“ bauen wollten, schließlich aufgaben und zu Ethereum wechselten.

Dieses Kalkül ändert sich im Jahr 2026. OP_CHECKTEMPLATEVERIFY hat zum ersten Mal seit dem Entwurf von BIP - 119 konkrete Aktivierungsparameter auf dem Tisch. OP_CAT hat eine offizielle BIP - Nummer. LNHANCE wird aktiv als Lightning - fokussierte Alternative diskutiert. Und BitVM2 – das überhaupt keinen Soft Fork erfordert – ist bereits in der Produktion live und betreibt die im Januar gestartete Mainnet - Bridge von Citrea. Nach Jahren, in denen es hieß „Covenants kommen bald“, befindet sich Bitcoin endlich in der Phase, in der mehrere glaubwürdige Vorschläge parallel laufen, die jeweils einen anderen Teil des Problems lösen.

Was Covenants eigentlich sind (und warum sie so umstritten waren)​

Ein Covenant ist im Bitcoin - Kontext eine Einschränkung darüber, wie ein UTXO in der Zukunft ausgegeben werden kann. Ein normales Bitcoin - Script kann nur die Frage beantworten: „Ist diese Ausgabe genau jetzt autorisiert?“ Ein Covenant erweitert dies auf: „Ist diese Ausgabe autorisiert und entspricht die nächste Transaktion diesen Bedingungen?“

Diese kleine Erweiterung schaltet eine überraschende Menge an Funktionalität frei. Vaults (Tresore), die eine obligatorische Zeitverzögerung erzwingen, bevor Gelder ein bestimmtes Ziel verlassen können. Zusagen zur Überlastungskontrolle (Congestion Control), die es ermöglichen, mit einer On - Chain - Transaktion Tausende von Off - Chain - Zahlungen zu finanzieren. Payment Pools. Nicht - interaktive Kanäle. ZK - Rollup - Bridges, die nicht auf Multisig - Federations angewiesen sind. Die Liste der Dinge, die neu möglich werden, ist lang genug, dass Entwickler seit fast einem Jahrzehnt über Covenants streiten.

Warum der Streit? Zwei reale Bedenken, ein kulturelles. Technisch gesehen könnten rekursive Covenants – Covenants, die sich jeder nachfolgenden Ausgabe für immer selbst auferlegen – theoretisch dazu verwendet werden, permanent eingeschränkte Coins zu erstellen, was die Fungibilität von Bitcoin untergraben würde. Kulturell betrachtet behandelt das Entwicklungsethos von Bitcoin jeden neuen Opcode als potenzielle Angriffsfläche. Die Ermöglichung von Covenants nach Taproot stellt für einige Entwickler eine inakzeptable Erweiterung des Komplexitätsbudgets des Protokolls dar. Die Berichterstattung des Bitcoin Magazine über die BIP - 119 - Debatte brachte diese Dynamik unverblümt auf den Punkt: „Die Aktivierung von Covenants auf Bitcoin ist ein großer Entwicklungsschritt, zu dem es kaum bestehende Forschung gibt. Der Versuch, dies so kurz nach der Taproot - Aktivierung durch die Hintertür durchzudrücken, sollte abgelehnt werden.“

Drei Jahre zusätzlicher Forschung später ist diese Kritik des „kaum Vorhandenen“ schwerer aufrechtzuerhalten.

OP_CTV (BIP - 119): Der minimalistische Vault - Vorschlag​

OP_CHECKTEMPLATEVERIFY ist der Covenant - Vorschlag, der einer tatsächlichen Aktivierung am nächsten ist. BIP - 119, verfasst von Jeremy Rubin, fügt einen einzelnen Opcode hinzu, der einen UTXO darauf festlegt, in einem spezifischen, vorher festgelegten Transaktions - Template ausgegeben zu werden – Version, Locktime, Input - Anzahl, Sequenzen, Output - Anzahl, Outputs und die Position des ausgebenden Inputs. Wenn das Template übereinstimmt, kann ausgegeben werden. Wenn nicht, dann nicht.

Das ist alles. OP_CTV ist per Design nicht - rekursiv: Man kann sich auf eine zukünftige Transaktion festlegen, aber diese zukünftige Transaktion kann sich selbst nicht auf weitere Transaktionen in einer Weise festlegen, die eine dauerhafte Einschränkung schafft. Diese bewusste Einschränkung ist der Grund, warum CTV - Befürworter sie als den „sicheren“ Covenant betrachten – sie ermöglicht Vaults, Überlastungskontrolle und bestimmte Lightning - Verbesserungen, kann aber nicht zur Erstellung dauerhaft „befleckter“ Coins verwendet werden.

Die konkreten Neuigkeiten für 2026: Die CTV - Deployment - Parameter legen nun einen Startzeitpunkt am 30. März 2026, einen Timeout am 30. März 2027, eine Mindestaktivierungshöhe im Mai 2027, einen 90 % Miner - Signalisierungsschwellenwert und einen Signalisierungszeitraum von 2016 Blöcken fest. Dies ist kein Konsens – es ist ein Vorschlag für Aktivierungsparameter. Aber es ist das erste Mal seit 2022, dass ein konkreter Zeitplan auf dem Tisch liegt, und es repräsentiert das CTV - Lager, das die entscheidende Frage stellt: Aktivieren oder formell ablehnen.

Die praktische „Killer - App“ für CTV ist der Vault. Wenn ein Benutzer heute 1 Mio. $ in Bitcoin selbst verwahren möchte und Schutz gegen den Verlust eines einzelnen Schlüssels sucht, sind die Optionen unschön: Multisig mit geografischer Schlüsselverteilung (operativ mühsam), zeitgesperrte Transaktionen (instabil) oder Verwahrungsdienste (macht den Zweck zunichte). Ein CTV - Vault ermöglicht es einem Benutzer festzulegen, dass jede Ausgabe aus seinem Cold Storage zuerst über eine zeitgesperrte Zwischenadresse erfolgen muss. Während dieser Zeit kann der Benutzer unbefugte Aktivitäten erkennen und einen Wiederherstellungs - Clawback auslösen. Dies ist die Art von Primitiv, die das Risikoprofil großer Bitcoin - Bestände materiell verändert.

OP_CAT (BIP - 347): Der Weg des rekursiven Covenant - Maximalisten​

OP_CAT ist philosophisch gesehen fast der gegenteilige Vorschlag. Während CTV ein sorgfältig abgegrenzter Opcode ist, der für eine bestimmte Gruppe von Anwendungsfällen entwickelt wurde, ist OP_CAT ein Primitiv – String - Verkettung auf dem Stack –, das bereits in der ursprünglichen Bitcoin - Script - Sprache vorhanden war, bevor es 2010 aufgrund von DoS - Bedenken deaktiviert wurde, die in den Post - Taproot - Script - Größenbeschränkungen nicht mehr gelten.

Die Reaktivierung von OP_CAT sieht oberflächlich nach nicht viel aus: Sie ermöglicht es Scripts lediglich, zwei Byte - Strings zu verketten. Aber die Verkettung, kombiniert mit den durch Taproot eingeführten Schnorr - Signaturen, reicht aus, um Introspektion aufzubauen – die Fähigkeit eines Scripts, die Transaktion zu untersuchen, die es ausgibt. Und Introspektion reicht aus, um rekursive Covenants, Zustandsautomaten und damit fast jeden Smart Contract zu erstellen, den man auf einer EVM - basierten Chain schreiben könnte.

StarkWare veröffentlichte einen Proof - of - Concept Bridge - Covenant auf einem OP_CAT - fähigen Bitcoin, der genau dies demonstriert: vertrauensminimiertes Bridging von Bitcoin zu L2s, das vollständig durch das Bitcoin - Script erzwungen wird, ohne dass ein föderiertes Multisig oder eine separate Bridge - Chain erforderlich ist. Das sCrypt - Team hat eine mehrteilige Serie veröffentlicht, die zeigt, wie OP_CAT zustandsbehaftete UTXO - Verträge, NFT - ähnlichen Ordinal - Handel und rekursive Vaults ermöglicht.

Der Kompromiss ist genau das, worüber sich CTV - Befürworter Sorgen machen. Die Ausdrucksstärke von OP_CAT schließt die Fähigkeit ein, permanent eingeschränkte Coins zu erstellen. In der Praxis existiert dies bereits in schwächeren Formen (Multisig mit verlorenen Schlüsseln, Zeitsperren mit unmöglich ferner Fälligkeit), und die Verteidiger von OP_CAT argumentieren, dass die Fungibilitätsbedenken eher theoretischer als operativer Natur sind. Aber die philosophische Kluft ist real: OP_CTV sagt „lassen Sie uns Covenants für diese spezifischen Anwendungsfälle ermöglichen“; OP_CAT sagt „lassen Sie uns das Primitiv aktivieren und die Entwickler die Anwendungsfälle herausfinden lassen“.

Dass OP_CAT im Jahr 2024 die Nummer BIP - 347 erhielt, war weniger wegen seiner technischen Substanz wichtig – CAT ist ein Vier - Byte - Opcode –, sondern vielmehr als Signal dafür, dass der Weg des Covenant - Maximalisten genug Glaubwürdigkeit bei den Entwicklern hatte, um den BIP - Prozess zu durchlaufen.

LNHANCE: Der auf Lightning ausgerichtete Kompromiss​

LNHANCE ist der Vorschlag mit dem klarsten „ Welches Problem löst das “ - Pitch. Anstatt für Covenants auf abstrakter Basis zu argumentieren, bündelt LNHANCE OP_CTV mit OP_CHECKSIGFROMSTACK (CSFS) und OP_INTERNALKEY und zielt speziell auf Verbesserungen des Lightning Network ab.

Das Lightning Network im April 2026 ist auf über 65.000 öffentliche Nodes angewachsen und hat sich zum dominierenden Bitcoin-Zahlungskanal entwickelt, schleppt aber reale Protokollschulden mit sich herum. Die Verifizierung des Channel-Status erfordert immer noch Watchtower-Dienste oder Online-Wallets. Channel Factories und Multi-Party-Channels sind schwierig zu konstruieren. Nicht-interaktive Channel-Eröffnungen — bei denen eine Partei einen Channel zu einer anderen öffnen kann, ohne dass der Empfänger online sein muss — sind im aktuellen Lightning nicht möglich.

LNHANCE ermöglicht LN-Symmetry (einen saubereren Mechanismus für den Channel-Status), Timeout Trees (effiziente Massenschließungen von Channels), vereinfachte PTLC-Skripte (Point Time-Locked Contracts, die die aktuellen Hash Time-Locked Contracts ersetzen), unidirektionale nicht-interaktive Channels, verbesserte Vaults und vertrauenslose Coin-Pools. Jede dieser Neuerungen ist eine konkrete Verbesserung für Lightning und kein spekulatives Smart-Contract-Primitiv.

Diese pragmatische Rahmung ist der politische Vorteil von LNHANCE. Das Lightning Network hat echte Akzeptanz erreicht, von regionalen Zahlungsabwicklern bis hin zum L402-Protokoll, das Lightning Labs als native Zahlungsebene für KI-Agent-Transaktionen positioniert. Verbesserungen, die Lightning wettbewerbsfähig halten, sind einfacher zu rechtfertigen als Verbesserungen, die primär BTC-Anwendungsfälle auf anderen Chains ermöglichen.

BitVM2: Die Soft-Fork-freie Alternative, die bereits live ist​

Die pragmatisch wichtigste Entwicklung der letzten achtzehn Monate ist gar kein Covenant-Vorschlag — es ist BitVM2 und die Tatsache, dass es null Änderungen am Bitcoin-Konsens erfordert.

BitVM2, verfasst von Robin Linus, extrahiert den Kern dessen, was Covenants ermöglichen (verifizierbare Off-Chain-Berechnungen, die in Bitcoin verankert sind), ohne dass Bitcoin selbst die Berechnungen durchführen muss. Das Protokoll arbeitet nach einem Challenge-Response-Modell: Ein Prover stellt eine Behauptung über eine Off-Chain-Berechnung auf, hinterlegt eine Kaution (Bond), und wenn ein Verifier glaubt, dass die Behauptung falsch ist, kann er einen Binary-Search-Disput einleiten, der den spezifischen Schritt isoliert, bei dem der Prover betrogen hat. Dieser eine Schritt wird dann On-Chain in Bitcoin Script ausgeführt, und die Kaution des Lügners wird eingezogen (Slashed).

Die ökonomische Eleganz: Ehrliche Prover werden nie herausgefordert, daher sind Dispute selten und die On-Chain-Kosten werden auf nahezu Null amortisiert. Die rechnerische Eleganz: Das überarbeitete Protokoll von BitVM2 löst jeden Disput in nur drei On-Chain-Transaktionen, statt der Dutzenden, die im ursprünglichen BitVM-Schema erforderlich waren. Die Erlaubnisfreiheit: Jeder kann herausfordern, sodass die Sicherheit des Systems nicht von einer festen Gruppe ehrlicher Verifier abhängt.

BitVM2 ist bereits live. Citrea — Bitcoins erstes ZK-Rollup — startete sein Mainnet am 27. Januar 2026 mit einer BitVM2-basierten Bridge (Codename „ Clementine “) als Produktions-Vertrauensmodell. GOAT Network veröffentlichte sein BitVM2-Testnet V3 im ersten Quartal 2026 mit dem Ziel eines vollständigen Bitcoin-nativen zkRollup-Stacks. Das Muster wird deutlich: Teams, die ihren Zeitplan nicht auf einen umstrittenen Bitcoin-Soft-Fork wetten wollen, entscheiden sich stattdessen für BitVM2.

Die Einschränkung ist ökonomischer, nicht kryptographischer Natur. Dispute werden mit Bitcoin-Blockspace bezahlt, und im schlimmsten Fall, wenn die Gebühren während eines Disput-Fensters in die Höhe schnellen, könnten Herausforderer preislich verdrängt werden. Dieses „ Disput-Ökonomie “ -Risiko ist das offene Problem, das BitVM2-Betreiber durch Überbesicherung, Watchtower-Dienste und die sorgfältige Auswahl der zu sichernden Berechnungen angehen. Es ist eine reale Einschränkung, aber eine ganz andere Art von Risiko als das „ Warten darauf, dass sich der Bitcoin-Konsens auf einen Opcode einigt “.

Die Aktivierungsfrage: Warum technischer Konsens nicht ausreicht​

Die unangenehme Wahrheit über die Covenant-Debatte bei Bitcoin ist, dass die technischen Unstimmigkeiten — rekursiv vs. nicht-rekursiv, minimalistischer Opcode vs. allgemeines Primitiv — weitgehend lösbar sind. Die schwierigere Frage ist, wie man einen dieser Vorschläge aktiviert.

Die Geschichte der Soft-Forks bei Bitcoin ist kurz und politisch aufgeladen. SegWit erforderte 2017 die Androhung eines UASF (User-Activated Soft Fork), um einen Miner-Deadlock zu durchbrechen. Taproot nutzte Speedy Trial — ein dreimonatiges BIP8-Fenster mit einer Signalisierungsschwelle der Miner von 90 % — und wurde im November 2021 reibungslos aktiviert. Seitdem wird jede Diskussion über Aktivierungsmethoden von den Ereignissen der Vergangenheit überschattet.

Der CTV-Parameter-Vorschlag für 2026 verwendet ein Signalisierungsfenster im Stil von Speedy Trial, wofür es Präzedenzfälle gibt. Aber Gegner von Covenants haben deutlich gemacht, dass sie Speedy Trial für umstrittene Änderungen nicht für angemessen halten — es wurde speziell für Vorschläge entwickelt, die bereits einen überwältigenden Konsens erreicht hatten, und sein dreimonatiges Fenster gibt dem breiteren Ökosystem nicht genug Zeit, Einwände zu erheben. Es ist zu erwarten, dass der Kampf um die Aktivierungsmethodik, wenn überhaupt, noch intensiver sein wird als der technische Kampf.

Die politischen Bedingungen könnten eine Aktivierung tatsächlich begünstigen. Die On-Chain-Aktivität von Bitcoin ist gegenüber dem Inscription-Peak von 2024 deutlich zurückgegangen, die Nachfrage nach Blockspace ist schwach, und die Bitcoin-Miner — die jedem Soft-Fork durch Signalisierung zustimmen müssen — suchen nach neuen Narrativen, die die Nachfrage nach Blockspace ankurbeln. Vaults, Lightning-Verbesserungen und Bitcoin-besicherte L2s erzeugen alle eine On-Chain-Transaktionsnachfrage. Die Übereinstimmung der ökonomischen Eigeninteressen ist deutlicher als seit Jahren nicht mehr.

Was dies für Bitcoin-Infrastruktur-Entwickler bedeutet​

Für Teams , die auf Bitcoin aufbauen , schafft die Covenant-Renaissance eine echte strategische Wahlmöglichkeit . Teams , die jetzt Smart-Contract-ähnliche Funktionalität benötigen , haben drei glaubwürdige Wege :

Weg 1 — Warten auf CTV / CAT / LNHANCE . Geringere Komplexität , erfordert einen Soft Fork zur Aktivierung , ungewisser Zeitplan . Bestens geeignet für Teams , deren Anwendungsfall ohne Änderungen auf Konsensebene grundlegend unmöglich ist ( z . B . nicht-föderierte Vaults im großen Stil ) .

Weg 2 — Aufbau auf BitVM2 . Heute verfügbar , höhere Implementierungskomplexität , abhängig von der ökonomischen Sicherheit . Bestens geeignet für Teams , die Bitcoin L2s , Bridges oder Rollups entwickeln und im Jahr 2026 starten müssen , ohne auf einen Konsens zu warten .

Weg 3 — Hybrider Ansatz . Start auf BitVM2 , wobei das Protokoll so gestaltet wird , dass eine Covenant-Aktivierung einen saubereren Upgrade-Pfad ermöglichen würde . Dies ist die Position , die das GOAT Network und mehrere andere Bitcoin L2-Teams einnehmen .

Für Infrastrukturanbieter ist die gemeinsame Auswirkung dieselbe : Bitcoin Script wird ausdrucksstärker , unabhängig davon , welcher dieser Wege gewinnt . Wallets , RPC-Anbieter , Indexer und Node-Infrastruktur müssen alle bereit sein , komplexere Transaktionstypen — Covenant-tragende UTXOs , BitVM2-Challenge-Transaktionen , neue Lightning-Channel-Strukturen — in der Produktion zu verarbeiten .

BlockEden.xyz bietet RPC-Infrastruktur auf Unternehmensniveau für Bitcoin und Bitcoin-nahe Netzwerke an , einschließlich aufstrebender L2s , die auf BitVM2 und Covenant-fähigen Primitiven basieren . Erkunden Sie unseren API-Marktplatz , um auf Grundlagen aufzubauen , die für das nächste Kapitel von Bitcoin entwickelt wurden .

Die Gestalt des nächsten Jahrzehnts von Bitcoin​

Das Interessanteste am Jahr 2026 ist nicht , dass einer dieser Vorschläge definitiv aktiviert wird — jeder von ihnen könnte sich noch um ein oder drei Jahre verzögern . Es ist vielmehr , dass sich die Entwicklungskultur von Bitcoin entscheidend über die binäre Debatte „ Covenants ja vs . Covenants nein “ hinausbewegt hat , die die Jahre 2022–2024 prägte .

Die Diskussion dreht sich nun darum , welche Kombination aus Covenant-Primitiven , Off-Chain-Verifizierungsprotokollen und Layer-2-Architekturen die nützlichste Programmierbarkeit bei geringster Konsensänderung bietet . CTV für Vaults und Congestion Control . CAT für Ausdrucksstärke und Bridges . LNHANCE für Lightning . BitVM2 für alles , was das Dispute-Resolution-Modell tolerieren kann . Diese sind keine konkurrierenden Visionen — sie sind komplementäre Werkzeuge in einem erweiterten Bitcoin-Scripting-Toolkit .

Bitcoin war fünfzehn Jahre lang absichtlich langweilig . Diese strategische Geduld hat den sichersten Settlement Layer der Geschichte hervorgebracht . Die Frage für das nächste Jahrzehnt ist , ob dieselbe Sicherheitsdisziplin überleben kann , wenn sie auf eine wirklich ausdrucksstarke programmierbare Ebene ausgeweitet wird . Wenn die Aktivierungsdebatten von 2026 damit enden , dass auch nur einer dieser Vorschläge umgesetzt wird , lautet die Antwort ja — und Bitcoins Rolle im breiteren Krypto-Ökosystem wird sich von „ digitalem Gold , das nichts tut “ zu „ dem Settlement Layer , dem alles andere vertraut “ wandeln .

Quellen :

Share on Twitter