Einführung

Sie haben vielleicht von der Wiederaktivierung von OP_CAT als potenzielles Upgrade für die Skriptsprache von Bitcoin gehört. Je nachdem, woher Sie Ihre Nachrichten beziehen, wurde OP_CAT als „nur 10 Zeilen Code“, „der beste Weg, um Experimente mit Vereinbarungen zu ermöglichen“, „zu mächtig“, „gefährlich und führt zur Zentralisierung der Miner“ oder „führt garantiert zu einem umstrittenen Soft Fork“ bezeichnet. Ich werde argumentieren, dass alle diese Perspektiven falsch sind. OP_CAT ist sehr nützlich, kann als Vereinbarung verwendet werden und ist nicht (allein) der beste nächste Schritt für Bitcoin. Nicht mehr und nicht weniger.

Um das zu belegen, werde ich mehrere (scheinbar zusammenhanglose) Themen untersuchen, von denen einige vor wenigen Monaten noch neu für mich waren. Ich werde versuchen, dies so zu ordnen, dass der notwendige Hintergrund an einem Ort bereitgestellt wird.

Wie und was OP_CAT macht

Selbstbeobachtung mit CAT

Lassen Sie uns die brennende Frage angehen, die sich viele stellen, wenn sie zum ersten Mal mit OP_CAT in Berührung kommen. Wie können ein paar Codezeilen, die zwei Elemente aus dem Stapel zu einem kombinieren (A B CAT -> AB), überhaupt irgendetwas Interessantes ermöglichen? Andrew Poelstra hat dies in jüngsten Interviews ausführlich erklärt, und ich habe eine alberne und kurze Erklärung gepostet:

Bitcoin ist ein bisschen seltsam, deshalb kann es auch Dinge aufteilen. Dann können wir mit SHA256 Hashes rückgängig machen. Und da Kryptografie nur Mathematik ist und wir wissen, wie man mahlt, können wir mit CAT einen Hash aus einer Signaturüberprüfung extrahieren. Und als Ergebnis können wir alles überprüfen, was in einer Signatur gehasht ist …

– Rearden 🍯🦡 🦢| embrace forks (@reardencode) 17. Mai 2024

Da Bitcoin-Skripte ausschließlich eine Verifizierungssprache sind, kann jeder Opcode vorwärts oder rückwärts verwendet werden. Einem Skript kann ein Hash zugewiesen werden und es kann ein Urbild erforderlich sein, oder es kann ein Urbild zugewiesen werden und es kann ein Hash mit OP_SHA256 erforderlich sein. Diese Einsicht gibt uns die ersten beiden Teile der Funktionsweise von OP_CAT-Vereinbarungen.

Wenn ein Bitcoin-Skript Zugriff auf einen Hash der Transaktion erhalten könnte, die es überprüft, könnte es verlangen, dass der Ausgabestapel das Hash-Urbild bereitstellt, es auf die vom Skript geforderte Weise aufteilt und dann einen bestimmten Teil dieses Urbilds validiert. Genau das ist ein Covenant – die Validierung eines Teils der Transaktion durch Ausgabe von Bitcoins.

Das ist toll, aber Bitcoin hat keinen Opcode wie OP_TXHASH, um dem Skript Zugriff auf den Hash der Transaktion zu geben. Hier machen wir uns die BIP340-Schnorr-Signaturüberprüfungsgleichung zunutze, um vom Benutzer die Angabe des Hashs zu verlangen. Wenn der Benutzer einen Wert angibt, der ein gültiger Transaktions-Hash ist, wenn das Skript das Byte 0x00 an sein Ende anhängt, ist dieser Wert auch Teil einer gültigen BIP340-Signatur (mit bestimmten anderen festen Parametern), wenn das Skript das Byte 0x01 daran anhängt.

Durch die Kombination dieser Techniken kann OP_CAT jeden Teil seiner Ausgabentransaktion prüfen, der signiert werden kann, und sogar in begrenztem Umfang auf die übergeordneten Transaktionen zurückblicken. Mit etwas sorgfältiger Codegestaltung kann man Purrfect Vaults, CatVM und mehr erstellen.

Andere Verwendungen für CAT

Aber das sollten wir nicht. Diese Dinge mit OP_CAT zu bauen, führt zu schwer zu wartenden Abscheulichkeiten. Stattdessen sollten wir OP_CAT für das verwenden, wofür es gut ist, und davon gibt es jede Menge: Es ermöglicht das Äquivalent von OP_CHECKSEPARATESIG, das Prüfen von Merkle-Inklusionsnachweisen, das Kombinieren von Daten zur Signaturüberprüfung mit OP_CHECKSIGFROMSTACK und mehr.

Probleme mit CAT

Nachdem wir nun wissen, was CAT macht, stellt sich die Frage, wo das Problem liegt. Warum haben Leute (ich eingeschlossen) gesagt, dass es ein gefährliches Biest ist? Mithilfe der oben beschriebenen Introspektionstechnik ermöglicht CAT zwei spezifische Konstruktionen: Hashrate-Treuhandkonten und (angeblich) automatisierte Market Maker (AMMs). Bis vor kurzem wurden beide als erhebliche Risiken angesehen, die mit der Zentralisierung von MEV auf Bitcoin verbunden sind.

MEV, MEVil und Miner-Zentralisierung

Der Begriff MEV (Miner Extractable Value) ist etwas verwirrend. In der einfachsten Interpretation würde er Transaktionsgebühren umfassen, die wir natürlich an die Miner zahlen wollen, um die Sicherheit von Bitcoin auch in Zukunft zu gewährleisten. MEV wird im Allgemeinen verwendet, um zusätzlichen Wert zu bezeichnen, den die Miner aus ihren Blöcken extrahieren können, zusätzlich zu den im öffentlichen Relay-Netzwerk sichtbaren Gebühren. Dies könnte in Form von Out-of-Band-Zahlungen geschehen, in Form von Minern, die an Verträgen teilnehmen und Transaktionen auf eine Weise neu anordnen, die ihnen Vorteile bringt, oder sogar in Form von regelrechtem Diebstahl von Waren und Dienstleistungen durch Miner, die Blöcke minen, die eine bestätigte Zahlung an einen Händler neu organisieren und doppelt ausgeben. Alle diese Formen von MEV können im Allgemeinen als schlecht für die Teilnehmer am Netzwerk angesehen werden, da die Miner ihre Position im Netzwerk zu ihrem eigenen Vorteil auf Kosten anderer Netzwerkteilnehmer nutzen. MEV allein stellt jedoch kein systemisches Problem dar, indem es die Zentralisierung der Miner vorantreibt, sondern nur ein lokales Problem für die speziell betroffenen Teilnehmer.

MEVil ist ein Begriff, der manchmal für MEV verwendet wird, das die Zentralisierung der Miner vorantreibt – ich bevorzuge den Begriff zentralisierendes MEV und werde ihn auch in Zukunft verwenden. Um MEV in zentralisierendes MEV umzuwandeln, sind mehrere Dinge notwendig:

  1. Es muss so schwierig zu extrahieren sein, dass ein Open-Source-Blockvorlagen-Builder es nicht vernünftig extrahieren kann

  2. Der gesamte extrahierbare Wert muss mit der Bitcoin-Hash-Rate eines Miners wachsen

  3. Der gewinnbare Wert muss die Kosten der Gewinnung rechtfertigen

Wenn alle diese Voraussetzungen erfüllt sind, wird nur ein ausreichend großer Bergbaukonzern einen Anreiz haben, mit der Förderung des MEV zu beginnen. Sobald dies geschieht, wird er dank der zusätzlichen Einnahmen das Wachstum seiner kleineren Konkurrenten übertreffen können. Je teurer die Förderung des MEV ist (bis zu dem Punkt, an dem es sich für keinen Bergbaukonzern mehr lohnt), desto stärker ist der dadurch entstehende Zentralisierungsdruck.

Die Zentralisierung von MEV zu vermeiden ist dann (in gewissem Sinne) einfach: Stellen Sie sicher, dass alle MEV-Möglichkeiten, die es bei Bitcoin gibt, entweder so einfach zu fördern sind, dass es jeder tut, oder dass die Förderung mehr kostet, als sie wert sind (entweder weil sie so klein oder weil sie so teuer sind).

Weitere Informationen finden Sie im aktuellen Beitrag von @TheBlueMatt.

Hashrate Escrows (geb. Drivechains)

Vor vielen Jahren (vor dem Lightning Network oder Ideen wie Ark, Timeout Trees, Roll-ups, BitVM oder CatVM) galten Sidechains als die ultimative Skalierungslösung für Bitcoin. Die Idee war konzeptionell einfach: Die Größe von Bitcoin-Blöcken muss aus den üblichen Dezentralisierungsgründen begrenzt bleiben, aber wir können Sidechains an Bitcoin anhängen, und diese können schnellere oder größere Blöcke, mehr Rechenleistung oder was auch immer haben. In der Praxis war die Implementierung von Sidechains allerdings nicht so einfach. Die endgültige Abwicklung von Bitcoin ist grundsätzlich an einen Arbeitsnachweis geknüpft, einen nicht widerlegbaren Preis für die Neuanordnung von Transaktionen. Wie erbt eine Sidechain das? Und wie können Bitcoins zur und von der Sidechain übertragen werden? Der bekannteste Vorschlag zur Beantwortung dieser beiden Fragen heißt Drivechains (BIPs 300 und 301). Ich will Sie nicht mit den Einzelheiten von Drivechains langweilen, aber es genügt zu sagen, dass es nur zwei Ergebnisse solcher Sidechain-Systeme gibt: Entweder sie sind relativ ungenutzt (und daher nutzlos) oder sie werden weithin verwendet und führen zu einer faktischen Blockgrößenerhöhung für Bitcoin. Eine faktische Blockgrößenerhöhung dieser Art ist eine Form der Zentralisierung von MEV, bei der nur größere Miner kostengünstig an den zusätzlichen Einnahmemöglichkeiten teilnehmen können, die die potenziell großen und komplexen Sidechain-Blöcke bieten.

Hashrate-Treuhandkonten, die mit OP_CAT erstellt werden können, sind ein kleiner Teil der Drivechains-Vorschläge. Dabei handelt es sich um ein System zur Beschränkung von Abhebungen von Sidechains durch die Verwendung eines Zählers, dessen Wert nur von Minern geändert werden kann, der bei einem hohen Wert beginnt und Null erreichen muss, bevor eine Sidechain-Abhebung verarbeitet werden kann. Dies soll eine „vertrauenswürdige“ Übertragung aus einer Sidechain sein, schafft aber tatsächlich eine Föderation von Minern mit Kontrolle über alle in Sidechains gehaltenen Bitcoins.

Seit der Entwicklung der Drivechains-Vorschläge ist es (zu unserem Nachteil) üblich geworden, jeden Vorschlag, mit dem eine Auszahlung auf Grundlage eines von Minern kontrollierten Zählers durchgeführt werden kann, als „Drivechains“ zu bezeichnen. Hoffentlich ist an dieser Stelle klar, warum diese unangemessene Abkürzung nicht hilfreich ist – Drivechains sind entweder wertlos oder gefährlich, aber Hashrate-Treuhandkonten sind lediglich eine Möglichkeit, die Kontrolle über das Ergebnis einer Transaktion an die implizite Föderation der Miner zu übertragen.

Token und AMMs

Token

Aus Gründen, die mir nie ganz klar werden werden, lieben Menschen gute Token (oder schlechte Token oder wirklich nur Token). Fast seit den Anfängen von Bitcoin wurde darüber gesprochen, wie andere Token in das Protokoll eingebettet werden können, von Colored Coins und Counterparty bis hin zu den neueren Taproot Assets und Runes. Alle diese Protokolle haben eines gemeinsam: Sie erfordern einen externen Index von Bitcoin-Transaktionen, der entweder Kenntnis von externen Daten hat oder Daten aus der Abfolge der Bitcoin-Transaktionen verarbeitet, um die Transformationen der Token innerhalb des Protokolls zu bestimmen. Der entscheidende Punkt für diesen Artikel ist, dass Bitcoin-Sperrskripte die Existenz der Token überhaupt nicht kennen und selbst Bitcoin-Knoten, die Transaktionen validieren, die Token nicht kennen (d. h. selbst wenn ein Bitcoin-Sperrskript vollen Zugriff auf den kompletten Bitcoin-UTXO-Satz hätte, könnte es den Status keiner dieser Token ermitteln).

Automatisierte Market Maker (AMMs)

Bei anderen Blockchain-Systemen werden häufig sogenannte AMMs verwendet, um beispielsweise das Verhältnis zwischen zwei Token durch Kauf und Verkauf zu einem festen Preis festzulegen. Die Regeln, die in einem AMM kodiert werden können, gehen über den Rahmen dieses Artikels hinaus. Es genügt zu sagen, dass AMMs enorme Möglichkeiten für MEV schaffen und aufgrund der privaten Austauschbeziehungen, die zur Maximierung der Erträge dieses MEV erforderlich sind, MEV auch zentralisieren. Dies wurde oft als Argument gegen den Aufbau ausdrucksstärkerer Bitcoin-Skripte verwendet – wir möchten wirklich vermeiden, das Bitcoin-Netzwerk den Launen der Zentralisierung von MEV auszusetzen. Wie ich jedoch oben beschrieben habe, gibt es für Bitcoin-Skripte, egal wie ausdrucksstark sie sind, einfach keine praktische Möglichkeit, den Status eines anderen Tokens als Bitcoin zu bewerten. Bitcoin-Skripte können keinen seltenen Sat lokalisieren. Sie können keinen Runensaldo finden. Sie können kein Taproot-Asset identifizieren.

Ohne Zugang zu Informationen über die Disposition von Nicht-Bitcoin-Vermögenswerten ergibt das gesamte Konzept eines Bitcoin-Skript-basierten AMM keinen Sinn. Token-Standorte können durch eine Signatur eines Orakels bestätigt werden, aber Orakelbestätigungen machen noch kein AMM aus. Sie können verwendet werden, um bestimmte manuelle Transaktionen zu erleichtern, aber kein dauerhaftes automatisiertes System. Darüber hinaus könnte ein solches orakelbasiertes System heute ohne Änderungen an Bitcoin erstellt werden.

Abschluss

Wie Sie hoffentlich sehen können, ist CAT kein so furchterregendes Biest. Es ist eigentlich gar kein großes Biest. Es hat weder unendliche Fähigkeiten noch magische Kräfte. Es ist nur ein kleiner Opcode, der sehr hilfreich sein kann. Das Einzige, was wir wahrscheinlich vermeiden möchten, ist die Aktivierung von OP_CAT ohne eine andere Möglichkeit zur Transaktionsintrospektion, wie OP_TXHASH, OP_TX oder beides. Sogar die Aktivierung mit LNHANCE ist eine Verbesserung gegenüber OP_CAT allein, da es die Größe und Komplexität der Skripte reduziert, die zum Erreichen vieler OP_CAT-Introspektionsprotokolle erforderlich sind.

Ich denke, an diesem Punkt wurde die Aussage „CAT führt unendlich alles ein“ auf ~nichts reduziert.

Es führt hilfreiche Selbstbeobachtung auf eine beschissene Art und Weise ein, die niemand verwenden sollte. Um den Leuten zu helfen, es nicht zu verwenden, sollten wir CAT zusammen mit TXHASH oder ähnlichem aktivieren.https://t.co/nvnxYn66Um https://t.co/1Ag5TwjuUw

– Rearden 🍯🦡 🦢| embrace forks (@reardencode) 17. Mai 2024

Dies ist ein Gastbeitrag von Brandon Black. Die geäußerten Meinungen sind ausschließlich ihre eigenen und spiegeln nicht unbedingt die von BTC Inc oder Bitcoin Magazine wider.

Quelle: Bitcoin Magazine

Der Beitrag OP_CAT und das unendliche Nichts erschien zuerst auf Crypto Breaking News.