Forschungsbericht von HashKey Capital: Vereinbarungen, die Programmierbarkeit von Bitcoin

Originalautor: HashKey Capital Leiter Investment Research Jeffrey HU, HashKey Capital Investment Manager Harper LI

In letzter Zeit gab es in der Bitcoin-Community eine Diskussionswelle über die Wiederaktivierung von Opcodes wie OP_CAT. Taproot Wizard hat auch viel Aufmerksamkeit erregt, indem er Quantum Cats NFTs gestartet und behauptet hat, die BIP-420-Nummer erhalten zu haben. Unterstützer behaupten, dass die Aktivierung von OP_CAT Vereinbarungen implementieren und Bitcoins Smart Contracts oder Programmierbarkeit realisieren kann.

Wenn Sie das Wort Einschränkungen bemerken und ein wenig suchen, werden Sie feststellen, dass dies ein weiteres großes Kaninchenloch ist. Entwickler diskutieren seit Jahren, dass es neben OP_CAT auch OP_CTV, APO, OP_VAULT und andere Techniken zur Implementierung von Einschränkungsklauseln gibt.

Was genau sind also die Einschränkungen von Bitcoin? Warum haben sie jahrelang so viel Aufmerksamkeit und Diskussionen unter Entwicklern auf sich gezogen? Welche Art von Programmierbarkeit kann Bitcoin erreichen? Welche Designprinzipien stecken dahinter? Dieser Artikel versucht, einen Überblick und eine Diskussion zu geben.

Was ist eine Sperrklausel?

Covenants, im Chinesischen als restriktive Klauseln und manchmal als Verträge übersetzt, sind ein Mechanismus, der Bedingungen für zukünftige Bitcoin-Transaktionen festlegen kann.

Das aktuelle Bitcoin-Skript enthält auch einschränkende Bedingungen, wie z. B. die Eingabe einer rechtsgültigen Signatur und die Eingabe eines passenden Skripts beim Ausgeben. Solange der Benutzer es jedoch entsperren kann, kann er die UTXO überall ausgeben, wo er möchte.

Die restriktiven Bedingungen dienen dazu, weitere Einschränkungen vorzunehmen, je nachdem, wie diese Einschränkung aufgehoben werden kann, z. B. die Begrenzung der Ausgaben nach UTXO, d. h. das Erreichen einer ähnlichen Wirkung wie Anzahlung für besondere Zwecke, oder andere Eingabebedingungen, die in einer Transaktion gesendet werden.

Genauer gesagt unterliegen aktuelle Bitcoin-Skripte auch bestimmten Einschränkungen, wie etwa opcode-basierte Zeitsperren, die durch die Introspektion der nLock- oder nSequence-Felder von Transaktionen Zeitlimits implementieren, bevor Transaktionen ausgegeben werden, sie sind jedoch grundsätzlich auf Zeitlimits beschränkt.

Warum also entwerfen Entwickler und Forscher diese Einschränkungsprüfungen? Weil die Einschränkungsklauseln nicht nur der Einschränkung dienen, sondern auch Regeln für die Transaktionsausführung festlegen. Auf diese Weise können Benutzer Transaktionen nur gemäß den voreingestellten Regeln ausführen, um den vorgegebenen Geschäftsprozess abzuschließen.

Was also kontraintuitiv erscheint, ist, dass dadurch weitere Anwendungsszenarien freigeschaltet werden können.

Anwendungsszenario

Sicherstellung von Staking-Strafen

Eines der intuitivsten Beispiele für restriktive Klauseln sind die Slash-Transaktionen von Babylon im Bitcoin-Staking-Prozess.

Babylons Bitcoin-Staking-Prozess besteht darin, dass Benutzer ihre BTC-Vermögenswerte an ein spezielles Skript in der Hauptkette senden. Die Ausgabebedingungen umfassen zwei Arten:

• Happy End: Nach einer gewissen Zeit kann der Benutzer es mit seiner eigenen Signatur entsperren und damit den Unstake-Prozess abschließen

• Schlechtes Ende: Wenn ein Benutzer eine von Babylon gemietete PoS-Kette doppelt signiert hat oder sich anderweitig böswillig verhält, kann dieser Teil der Vermögenswerte durch EOTS (extrahierbare Einmalsignaturen) entsperrt werden, und die ausführende Rolle im Netzwerk erzwingt, dass ein Teil der Vermögenswerte an die brennende Adresse (Schrägstrich) gesendet wird.

Quelle: Bitcoin Staking: Freigabe von 21 Millionen Bitcoins zur Sicherung der Proof-of-Stake-Ökonomie

Zu beachten ist hier das erzwungene Senden, das heißt, selbst wenn der UTXO entsperrt werden kann, kann das Asset nicht beliebig woanders hin gesendet, sondern nur verbrannt werden. Dadurch wird sichergestellt, dass böswillige Benutzer ihre bekannten Signaturen nicht verwenden können, um die Assets im Voraus an sich selbst zurückzuübertragen und so einer Strafe zu entgehen.

Wenn diese Funktion implementiert wird, nachdem restriktive Begriffe wie OP_CTV implementiert wurden, können Opcodes wie OP_CTV zum Zweig mit dem schlechten Ende des Staking-Skripts hinzugefügt werden, um die Beschränkungen zu implementieren.

Bevor OP_CTV aktiviert wurde, musste Babylon eine Workaround-Methode verwenden, die von Benutzern und Komitee gemeinsam implementiert wurde, um die Auswirkungen der Durchsetzung der restriktiven Klauseln zu simulieren.

Überlastungskontrolle

Im Allgemeinen bedeutet Überlastung, dass bei einer sehr hohen Transaktionsgebühr im Bitcoin-Netzwerk sehr viele Transaktionen darauf warten, im Transaktionspool gebündelt zu werden. Wenn Benutzer Transaktionen also schnell bestätigen möchten, müssen sie die Transaktionsgebühr erhöhen.

Wenn ein Benutzer mehrere Transaktionen an mehrere Empfänger senden muss, muss er die Bearbeitungsgebühr erhöhen und relativ hohe Kosten tragen, was auch die Bearbeitungsgebühr des gesamten Netzwerks weiter erhöht.

Wenn Einschränkungen bestehen, besteht eine Lösung darin, dass der Absender sich zunächst zu einer Sammeltransaktion verpflichtet. Durch diese Verpflichtung können alle Empfänger davon ausgehen, dass die endgültige Transaktion ausgeführt wird, und sie können warten, bis die Bearbeitungsgebühr niedrig ist, bevor sie die spezifische Transaktion senden.

Wie in der folgenden Abbildung dargestellt, wird es sehr teuer, Transaktionen durchzuführen, wenn die Nachfrage nach Blockspeicherplatz hoch ist. Durch die Verwendung von OP_CHECKTEMPLATEVERIFY können Zahlungsverarbeiter mit hohem Volumen alle ihre Zahlungen zur Bestätigung in einer einzigen O(1)-Transaktion zusammenfassen. Wenn die Nachfrage nach Blockspeicherplatz einige Zeit später abnimmt, können die Zahlungen aus diesem UTXO heraus erweitert werden.

Quelle: https://utxos.org/uses/scaling/

Dieses Szenario ist ein typischer Anwendungsfall, der von der OP_CTV-Einschränkungsklausel vorgeschlagen wird. Weitere Anwendungsfälle finden Sie unter https://utxos.org/uses/. Zusätzlich zur oben genannten Überlastungskontrolle listet die Webseite Soft Fork Bets, dezentrale Optionen, Drivechains, Batch-Kanäle, nicht interaktive Kanäle, vertrauenslose, koordinationsfreie Mining-Pools, Tresore, sicherere Hashed Time Locked Contracts (HTLCS)-Limits usw. auf.

Gewölbe

Tresore sind ein viel diskutiertes Anwendungsszenario in Bitcoin-Anwendungen, insbesondere im Bereich der Beschränkungen. Da im täglichen Betrieb zwangsläufig die Notwendigkeit der Aufbewahrung und Verwendung von Geldmitteln in Einklang gebracht werden muss, hoffen die Menschen auf eine Art Tresoranwendung, die die Sicherheit von Geldmitteln gewährleisten und sogar die Verwendung von Geldmitteln einschränken kann, selbst wenn das Konto gehackt wird (privater Schlüssel durchgesickert).

Basierend auf der Technologie zur Implementierung von Einschränkungsklauseln können Tresor-ähnliche Anwendungen relativ einfach erstellt werden.

Nehmen wir als Beispiel das Design von OP_VAULT: Wenn Geld im Tresor ausgegeben wird, muss zuerst eine Transaktion an die Kette gesendet werden. Diese Transaktion zeigt die Absicht an, den Tresor auszugeben, d. h. den Auslöser, und legt die Bedingungen darin fest:

• Wenn alles gut geht, ist die zweite Transaktion die endgültige Auszahlungstransaktion. Nach dem Warten auf N Blöcke können die Mittel überall weiter ausgegeben werden.

• Wenn festgestellt wird, dass diese Transaktion gestohlen wurde (oder während eines Wrench-Angriffs erzwungen wurde), kann sie sofort an eine andere sichere Adresse gesendet werden (zur sichereren Aufbewahrung durch den Benutzer), bevor die Auszahlungstransaktion von N Blöcken gesendet wird.

OP_VAULT-Prozess, Quelle: BIP-345

Es ist zu beachten, dass eine Tresoranwendung ohne Einschränkungen erstellt werden kann. Eine mögliche Möglichkeit besteht darin, den privaten Schlüssel zu verwenden, um die Signatur für zukünftige Ausgaben vorzubereiten und den privaten Schlüssel dann zu vernichten. Es gibt jedoch immer noch viele Einschränkungen, z. B. die Notwendigkeit, sicherzustellen, dass der private Schlüssel vernichtet wurde (ähnlich dem vertrauenswürdigen Einrichtungsprozess beim Zero-Knowledge-Proof), der Betrag und die Bearbeitungsgebühr werden im Voraus festgelegt (aufgrund der Vorsignatur) und es mangelt daher an Flexibilität.

Vergleich von OP_VAULT und vorsignierten Vault-Prozessen, Quelle: BIP-345

Robustere und flexiblere Statuskanäle

Man kann allgemein davon ausgehen, dass Statuskanäle, einschließlich des Lightning Network, fast die gleiche Sicherheit wie die Hauptkette haben (vorausgesetzt, dass Knoten den neuesten Status beobachten und den neuesten Status normal an die Kette senden können). Mit den Einschränkungen können jedoch einige neue Designideen für Statuskanäle auf dem Lightning Network robuster oder flexibler sein. Zu den bekannteren gehören Eltoo, Ark usw.

Eltoo (auch bekannt als LN-Symmetry) ist ein typisches Beispiel. Diese technische Lösung verwendet das Homonym von L2 und schlägt eine Ausführungsschicht für das Lightning Network vor, die es jedem nachfolgenden Kanalzustand ermöglicht, den vorherigen Zustand zu ersetzen, ohne dass ein Strafmechanismus erforderlich ist. Daher kann auch die Notwendigkeit vermieden werden, dass Lightning Network-Knoten mehrere vorherige Zustände speichern müssen, um zu verhindern, dass Gegner Böses tun. Um den oben genannten Effekt zu erzielen, schlug Eltoo die Signaturmethode SIGHASH_NOINPUT vor, nämlich APO (BIP-118).

Ark zielt darauf ab, die Schwierigkeit der eingehenden Liquidität und des Kanalmanagements des Lightning Network zu verringern. Es handelt sich um ein Joinpool-ähnliches Protokoll, bei dem mehrere Benutzer innerhalb eines bestimmten Zeitraums einen Dienstanbieter als Gegenpartei akzeptieren können, um virtuelle UTXO (vUTXO) außerhalb der Kette zu handeln, aber einen UTXO in der Kette teilen, um die Kosten zu senken. Ähnlich wie der Tresor kann Ark auch im aktuellen Bitcoin-Netzwerk implementiert werden. Nach der Einführung von Einschränkungen kann Ark jedoch den erforderlichen Interaktionsumfang basierend auf der Transaktionsvorlage reduzieren und einen vertrauensloseren einseitigen Ausstieg erreichen.

Technischer Überblick über Einschränkungen

Aus den oben genannten Anwendungen können wir erkennen, dass Beschränkungsklauseln eher eine Wirkung als eine bestimmte Technologie sind, sodass es viele technische Möglichkeiten gibt, sie umzusetzen. Wenn sie klassifiziert werden, können sie Folgendes umfassen:

• Typ: Allzweck, Spezialzweck

• Implementierungsmethode: Opcode-basiert, signaturbasiert

• Rekursion: rekursiv, nicht rekursiv

Rekursion bedeutet, dass bei der Implementierung einiger restriktiver Klauseln die Ausgabe der nächsten Transaktion durch die Einschränkung der nächsten Ausgabe eingeschränkt werden kann. Die hinzugefügten Einschränkungen können über eine Transaktion hinausgehen und eine höhere Transaktionstiefe erreichen.

Zu den gängigen Ausgestaltungen von Sperrklauseln zählen:

* Rekursion: In Kombination mit OP_CAT

Ausgestaltung von Sperrklauseln

Aus der vorherigen Einführung können wir ersehen, dass das aktuelle Bitcoin-Skript hauptsächlich die Bedingungen für das Entsperren einschränkt, aber nicht einschränkt, wie die UTXO weiter ausgegeben werden können. Um die Einschränkungsklausel zu implementieren, müssen wir umgekehrt darüber nachdenken: Warum kann das aktuelle Bitcoin-Skript die Einschränkungsklausel nicht implementieren?

Der Hauptgrund besteht darin, dass das aktuelle Bitcoin-Skript den Inhalt der Transaktion selbst, also die Selbstanalyse der Transaktion, nicht lesen kann.

Wenn wir eine Introspektion von Transaktionen implementieren können – also die Überprüfung sämtlicher Inhalte einer Transaktion (einschließlich der Ausgaben) –, dann können wir auch Beschränkungen implementieren.

Daher drehen sich auch die Gestaltungsideen einschränkender Klauseln hauptsächlich darum, wie eine Selbstreflexion erreicht werden kann.

Opcode-basiert vs. signaturbasiert

Die einfachste und gröbste Idee besteht darin, einen oder mehrere Opcodes hinzuzufügen (d. h. einen Opcode + mehrere Parameter oder mehrere Opcodes mit unterschiedlichen Funktionen), um den Transaktionsinhalt direkt zu lesen. Dies basiert auch auf der Idee von Opcodes.

Eine andere Idee besteht darin, den Hash des Transaktionsinhalts zu verwenden, anstatt den Transaktionsinhalt direkt im Skript zu lesen und zu überprüfen. Wenn der Hash signiert wurde, können die Transaktionsintrospektions- und -beschränkungsklauseln indirekt implementiert werden, solange das Skript geändert wird, um die Signatur zu überprüfen, z. B. OP_CHECKSIG. Diese Idee basiert auf der Entwurfsmethode von Signaturen. Sie umfasst hauptsächlich APO und OP_CSFS.

APO

SIGHASH_ANYPREVOUT (APO) ist eine vorgeschlagene Bitcoin-Signaturmethode. Die einfachste Möglichkeit zum Signieren besteht darin, sowohl die Eingabe als auch die Ausgabe einer Transaktion zu bestätigen. Bitcoin verfügt jedoch über eine flexiblere Methode, SIGHASH, die selektiv die Eingabe oder Ausgabe einer Transaktion bestätigt.

Der aktuelle Signaturbereich von SIGHASH und seine Kombination für Transaktionseingabe und -ausgabe (Quelle: Mastering Bitcoin, 2.

Wie in der obigen Abbildung gezeigt, ist die Signaturmethode NONE zusätzlich zu ALL, das auf alle Daten anwendbar ist, nur auf alle Eingaben anwendbar, nicht auf Ausgaben; SINGLE basiert darauf und ist nur auf Ausgaben mit derselben Eingabesequenznummer anwendbar. Darüber hinaus kann SIGHASH auch kombiniert werden und ist nach Überlagerung mit dem Modifikator ANYONECANPAY nur auf eine Eingabe anwendbar.

Allerdings signiert APOs SIGHASH nur die Ausgabe, nicht die Eingabe. Das bedeutet, dass eine mit APO signierte Transaktion an jeden UTXO angehängt werden kann, der die Bedingungen erfüllt.

Diese Flexibilität ist die theoretische Grundlage für die APO-Umsetzungsbeschränkungsklausel:

• Eine oder mehrere Transaktionen können vorab erstellt werden

• Anhand der Informationen dieser Transaktionen wird ein öffentlicher Schlüssel erstellt, der nur eine Signatur generieren kann.

• Auf diese Weise können alle an die öffentliche Schlüsseladresse gesendeten Vermögenswerte nur über vorab erstellte Transaktionen ausgegeben werden.

Es ist erwähnenswert, dass dieser öffentliche Schlüssel, da er keinen entsprechenden privaten Schlüssel hat, sicherstellen kann, dass diese Vermögenswerte nur durch vorab erstellte Transaktionen ausgegeben werden können. Dann können wir das Ziel der Vermögenswerte in diesen vorab erstellten Transaktionen angeben und so Einschränkungsklauseln implementieren.

Wir können dies besser verstehen, indem wir es mit den Smart Contracts von Ethereum vergleichen: Durch Smart Contracts können wir nur dann Geld von der Vertragsadresse abheben, wenn bestimmte Bedingungen erfüllt sind, anstatt es willkürlich mit einer EOA-Signatur auszugeben. Aus dieser Sicht kann Bitcoin diesen Effekt erzielen, indem es den Signaturmechanismus verbessert.

Das Problem beim obigen Verfahren besteht darin, dass eine zirkuläre Abhängigkeit in der Berechnung besteht, da der Eingabeinhalt bekannt sein muss, um die Transaktion vorab zu signieren und zu erstellen.

Die Bedeutung der Implementierung dieser Signaturmethode mit APO und SIGHASH_NOINPUT besteht darin, dass sie das Problem der zirkulären Abhängigkeit lösen kann. Bei der Berechnung müssen Sie nur alle Ausgaben der Transaktion kennen (angeben).

OP_CTV

OP_CHECKTEMPLATEVERIFY (CTV) oder BIP-119 bietet einen verbesserten Ansatz für Opcode. Es verwendet einen Commitment-Hash als Parameter und erfordert, dass jede Transaktion, die den Opcode ausführt, eine Reihe von Ausgaben enthält, die diesem Commitment entsprechen. Mit CTV können Bitcoin-Benutzer ihre Verwendung von Bitcoin einschränken.

Der Vorschlag wurde ursprünglich unter dem Namen OP_CHECKOUTPUTSHASHVERIFY (COSHV) eingeführt und konzentrierte sich anfangs auf die Möglichkeit, überlastungsgesteuerte Transaktionen zu erstellen. Daher konzentrierte sich die Kritik am Vorschlag auch auf die Tatsache, dass die Lösung nicht allgemein genug und zu spezifisch auf den Anwendungsfall der Überlastungskontrolle zugeschnitten war.

Im oben erwähnten Anwendungsfall der Überlastungskontrolle kann die Absenderin Alice 10 Ausgaben erstellen und diese 10 Ausgaben hashen und den resultierenden Digest verwenden, um ein Tapleaf-Skript mit COSHV zu erstellen. Alice kann auch die öffentlichen Schlüssel der Teilnehmer verwenden, um einen internen Taproot-Schlüssel zu bilden, der es ihnen ermöglicht, bei Ausgaben zusammenzuarbeiten, ohne den Taproot-Skriptpfad preiszugeben.

Alice gibt dann jedem Empfänger eine Kopie aller 10 Ausgaben, damit jeder die von Alice eingerichtete Transaktion überprüfen kann. Wenn sie diese Zahlung später ausgeben möchten, kann jeder von ihnen eine Transaktion erstellen, die die festgeschriebene Ausgabe enthält.

Während des gesamten Prozesses, wenn Alice die Setup-Transaktion erstellt und sendet, kann sie diese 10 Kopien der Ausgabe über vorhandene asynchrone Kommunikationsmethoden wie E-Mail oder Cloud-Laufwerke senden. Dies bedeutet, dass die Empfänger nicht online sein oder miteinander interagieren müssen.

Quelle: https://bitcoinops.org/en/newsletters/2019/05/29/#proposed-transaction-output-commitments

Ähnlich wie bei APO können Adressen auch basierend auf Ausgabebedingungen erstellt und Sperren auf verschiedene Arten vorgenommen werden, einschließlich: Hinzufügen anderer Schlüssel, Zeitsperren und kombinierbarer Logik.

Quelle: https://twitter.com/OwenKemeys/status/1741575353716326835

Auf dieser Grundlage schlug CTV vor, dass es möglich sei, zu überprüfen, ob die gehashte Ausgabetransaktion der Definition entspricht, d. h. die Transaktionsdaten als Schlüssel zum Öffnen des Schlosses zu verwenden.

Wir können das obige Beispiel mit 10 Empfängern erweitern. Der Empfänger kann seinen Adressschlüssel außerdem auf eine signierte, aber nicht gesendete tx setzen, um sie an die nächste Gruppe von Empfängeradressen zu senden, und so weiter, wodurch eine Baumstruktur entsteht, wie in der folgenden Abbildung dargestellt. Alice kann eine Kontostandsänderung mit mehreren Benutzern konstruieren, indem sie nur 1 utxo-Blockplatz in der Kette verwendet.

Quelle: https://twitter.com/OwenKemeys/status/1741575353716326835

Was ist, wenn eines der Blätter ein Lightning-Kanal, ein Cold Storage oder ein anderer Zahlungspfad ist? Dann wird der Baum von einem eindimensionalen und mehrschichtigen Ausgabenbaum zu einem mehrdimensionalen und mehrschichtigen Ausgabenbaum erweitert, und die Szenarien, die er unterstützen kann, werden umfangreicher und flexibler.

Quelle: https://twitter.com/OwenKemeys/status/1744181234417140076

Seit seinem Vorschlag wurde CTV 2019 von COSHV umbenannt, 2020 erhielt es BIP-119 und die Programmiersprache Sapio zum Erstellen von Verträgen, die CTV unterstützen, ist entstanden. In den Jahren 2022 und 2023 gab es in der Community viele Diskussionen und Updates sowie Debatten über seinen Aktivierungsplan. Es ist immer noch einer der Soft-Fork-Upgrade-Vorschläge, der in der Community am meisten diskutiert wird.

OP_CAT

Wie eingangs erwähnt, ist OP_CAT auch ein sehr beliebter Upgrade-Vorschlag. Er implementiert die Funktion zum Verketten zweier Elemente im Stapel. Obwohl es einfach aussieht, kann OP_CAT viele Funktionen im Skript flexibel implementieren.

Das direkteste Beispiel ist die Operation im Zusammenhang mit dem Merkle-Baum. Der Merkle-Baum kann als zwei Elemente verstanden werden, die zuerst verkettet und dann gehasht werden. Derzeit gibt es im Bitcoin-Skript Hash-Opcodes wie OP_SHA 256. Wenn also OP_CAT zum Verketten zweier Elemente verwendet werden kann, kann die Merkle-Baum-Verifizierungsfunktion im Skript implementiert werden, was bedeutet, dass es bis zu einem gewissen Grad die Fähigkeit zur leichten Client-Verifizierung hat.

Die andere Implementierungsgrundlage umfasst auch die Verbesserung der Schnorr-Signatur: Die Ausgabesignaturbedingung des Skripts kann als Verkettung des öffentlichen Schlüssels und des öffentlichen Nonce des Benutzers festgelegt werden. Wenn der Unterzeichner eine andere Transaktion unterzeichnen möchte, um die Mittel woanders auszugeben, muss er denselben Nonce verwenden, was zum Verlust des privaten Schlüssels führen würde. Das heißt, die Verpflichtung zum Nonce wird durch OP_CAT erreicht, wodurch die Gültigkeit der unterzeichneten Transaktion sichergestellt wird.

Andere Anwendungsszenarien von OP_CAT umfassen: Bistream, Baumsignatur, quantenresistente Lamport-Signatur, Tresor usw.

OP_CAT selbst ist keine neue Funktion. Es existierte in den frühesten Versionen von Bitcoin, wurde jedoch 2010 deaktiviert, da es für Angriffe ausgenutzt werden konnte. Beispielsweise kann die wiederholte Verwendung von OP_DUP und OP_CAT bei der Verarbeitung solcher Skripte leicht dazu führen, dass der Stapel eines vollständigen Knotens explodiert, wie in dieser Demo gezeigt wird.

Aber tritt das oben erwähnte Stapelexplosionsproblem nicht auf, wenn OP_CAT jetzt wieder aktiviert wird? Da der aktuelle OP_CAT-Vorschlag nur die Aktivierung in Tapscript beinhaltet und Tapscript jedes Stapelelement auf nicht mehr als 520 Bytes begrenzt, wird es nicht das vorherige Stapelexplosionsproblem verursachen. Einige Entwickler denken auch, dass Nakamotos direkte Deaktivierung von OP_CAT zu hart sein könnte. Aufgrund der Flexibilität von OP_CAT kann es jedoch tatsächlich einige Anwendungsszenarien geben, die zu Schwachstellen führen können, die derzeit nicht ausgeschöpft werden können.

Angesichts der Anwendungsszenarien und potenziellen Risiken hat OP_CAT in letzter Zeit viel Aufmerksamkeit erhalten und wurde auch einer PR-Prüfung unterzogen. Es ist derzeit einer der beliebtesten Upgrade-Vorschläge.

Abschluss

Selbstdisziplin bringt Freiheit. Aus der obigen Einführung können wir ersehen, dass die Einschränkungsklauseln direkt im Bitcoin-Skript implementiert werden können, um die weiteren Ausgaben der Transaktion zu begrenzen und so Transaktionsregeln zu realisieren, die der Wirkung von Smart Contracts ähneln. Verglichen mit Off-Chain-Methoden wie BitVM kann diese Programmiermethode bei Bitcoin nativer verifiziert werden und kann auch die Anwendungen auf der Hauptkette (Überlastungskontrolle), Off-Chain-Anwendungen (Statuskanäle) und andere neue Anwendungsrichtungen (Staking-Strafen usw.) verbessern.

Wenn die Technologie zur Implementierung von Beschränkungen mit einigen zugrunde liegenden Upgrades kombiniert werden kann, wird das Potenzial der Programmierbarkeit weiter ausgeschöpft. Beispielsweise der Vorschlag für 64-Bit-Operatoren in Rezension kann kürzlich weiter mit dem vorgeschlagenen OP_TLUV oder anderen Einschränkungsklauseln kombiniert werden, um basierend auf der Anzahl der Satoshis in der Transaktionsausgabe zu programmieren.

Einschränkungen können jedoch auch zu ungeplantem Missbrauch oder Schlupflöchern führen, daher ist die Community diesbezüglich vorsichtig. Darüber hinaus erfordert die Aktualisierung der Einschränkungen auch eine Soft-Fork-Aktualisierung der Konsensregeln. Angesichts der Situation während der Taproot-Aktualisierung kann die Aktualisierung der Einschränkungen auch einige Zeit in Anspruch nehmen.

Vielen Dank an Ajian, Fisher und Ben für die Überprüfung und die Vorschläge zu diesem Artikel!

Verweise
https://utxos.org/

https://bitcoincovenants.com/

Eine Sammlung von Ressourcen im Zusammenhang mit Bündnissen:

https://gist.github.com/RobinLinus/c96fb7c81430ec6dc92f048687bd3068

https://anyprevout.xyz/

BIP 345: OP_VAULT-Vorschlag: https://www.btcstudy.org/2023/04/13/bitcoin-improvement-proposals-345-op-vault-commit-0b0674c546/ 聽

https://fc17.ifca.ai/bitcoin/papers/bitcoin17-final2 8.pdf

https://maltemoeser.de/paper/covenants.pdf

https://bitcoinops.org/en/topics/op_cat/

OP_CAT:

https://github.com/bitcoin-inquisition/binana/blob/master/2024/BIN-2024-0001.md

CAT- und Schnorr-Tricks: https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298

Dieser Artikel stammt aus dem Internet: HashKey Capital Research Report: Covenants, die Programmierbarkeit von Bitcoin

Verbunden: Meme-Münze BONK anfällig für 50%-Rückgang aufgrund bärischer Signale

Kurz gesagt: Der Bonk-Preis befindet sich in einem absteigenden Keil, und die untere Trendlinie wird wahrscheinlich erneut getestet. Dies würde zu einem potenziellen Rückgang von 50% führen, was auf breiterer Marktbasis Unterstützung signalisiert. BONK-Inhaber wetten auch auf einen Preisrückgang, da die Finanzierungsraten stark negativ sind. Bonk konnte eine wichtige Widerstandstrendlinie nicht durchbrechen, was dazu geführt hätte, dass die Meme-Münze einem weiteren Rückgang entgangen wäre. Wenn man sich jedoch den absteigenden Keil ansieht, in dem BONK feststeckt, rechtfertigt dies einen weiteren Rückgang. Diese Meinung wird auch von Anlegern geteilt, die Short-Wetten auf die Meme-Münze abschließen. Bonk-Finanzierungsrate sinkt erneut Zum Zeitpunkt des Schreibens liegt der Bonk-Preis über einer wichtigen Unterstützungslinie von $0.00002153. Dieses Niveau wurde in der Vergangenheit mehrfach getestet, aber dieses Mal liegt der…