Dieser Artikel dient nur der technischen Weitergabe und stellt keine Anlageberatung dar.

Wird BTC auch einen eigenen Smart Contract haben?

Im jüngsten Bitcoin-Ökosystem startete Fractal BTC im September schließlich das Mainnet, nachdem es mehrere Testnetze durchlaufen hatte. Ein Hauptmerkmal von Fractal ist die Möglichkeit, „intelligente Verträge“ zu haben, und fast zeitgleich mit dem Start des Mainnets wurde ein neues Token-Protokoll CAT 20 eingeführt. Welche technische Raffinesse hat CAT 20? Was können wir lernen?

Fractal Bitcoin

Bevor wir CAT 20 verstehen, müssen wir kurz die Beziehung zwischen ERC 20 und ETH verstehen. Das CAT 20-Protokoll wird auf Fractal Bitcoin eingesetzt.

Fractal Bitcoin, auch bekannt als Fractal Bitcoin, ist ein „Second-Layer“-Netzwerk, das vollständig mit BTC kompatibel ist. Im Vergleich zu BTC ist die Blockbestätigungszeit schneller und dauert nur 1 Minute. Sein Grundprinzip besteht einfach darin, mehrere Kopien des BTC-Netzwerks zu erstellen. Je mehr Knoten Transaktionen verarbeiten können, desto schneller wird es sein. Allerdings sind die spezifischen Details, etwa wie verschiedene Ketten kommunizieren, noch nicht klar und es gibt keine entsprechenden offiziellen technischen Dokumente als Referenz.

Wenn nur eine Kettentransaktion der zweiten Ebene schneller ist, scheint es keine Aufregung zu geben. Allerdings hat die Aktivierung von OP_CAT in Fractal, die von BTC vor langer Zeit aufgegeben wurde, die Fähigkeiten von Fractal Bitcoin auf ein höheres Niveau gebracht. Einige Leute sagen, dass OP_CAT BTC dabei ermöglichen kann, über intelligente Verträge zu verfügen Übrigens gibt es Raum für Fantasie.

Nun hat jemand ein ERC 20-ähnliches Protokoll auf Fractal Bitcoin implementiert.

Warum OP_CAT aufgegeben wurde und warum es auf Fractal Bitcoin verwendet werden kann, können wir später besprechen. Hier konzentrieren wir uns auf CAT 20.

CAT-Protokoll Den folgenden Inhalt finden Sie im Whitepaper: Einführung | CAT-Protokoll (https://catprotocol.org/)

Und Github-Repository: GitHub – CATProtocol/cat-token-box: Ein Monorepo für Pakete, die das CAT-Protokoll implementieren (https://github.com/CATProtocol/cat-token-box)

Mit der zugrunde liegenden OP_CAT-Unterstützung wird bald ein entsprechendes Protokoll, CAT Protocol, verfügbar sein. Derzeit ist das CAT 20-Protokoll ein Protokoll, das tatsächlich ausgeführt wird, und ein entsprechendes Panel wurde auf Unisat hinzugefügt: https://explorer.unisat.io/fractal-mainnet/cat20.

Jeder sollte reagieren können, wenn er den Namen CAT 20 sieht. Er sollte eher ERC 20 ähneln. Im Vergleich zum ausgereiften ERC 20-Protokoll ist es für jeden sehr bequem, einen Token bereitzustellen. Wie implementiert CAT 20 einen ähnlichen Lebenszyklus wie ERC 20?

Einsetzen

Vor der Bereitstellung müssen Benutzer ihre Wallet-Adresse und grundlegende Informationen zum Token angeben. Die grundlegenden Informationen zum Token ähneln denen von ERC 20:

Es wird einige Unterschiede geben. CAT 20 kann Pre-Mining- und Mengengrenzen für jede Mint festlegen. Natürlich kann ERC 20 diese Fähigkeiten auch durch Vertragsfähigkeiten erreichen.

Während der Bereitstellungsphase werden zwei Transaktionen initiiert, die als zwei Phasen betrachtet werden können: „Commit“ und „Reveal“. Gemäß dem offiziellen Diagramm sind die Bereitstellungsphasen wie folgt:

In der „Commit“-Phase werden die grundlegenden Informationen des Tokens in das Ausgabeskript der Transaktion geschrieben, wie z. B. der Name, das Symbol usw. des Tokens. Die Hash-ID der in der „Commit“-Phase initiierten Transaktion wird als Symbol des Tokens verwendet, um andere Token zu unterscheiden.

Sie können sehen, dass der Utxo dieser Transaktion „bc 1 pucq...ashx“ dem Commit entspricht. Dann gibt es zwei verbleibende Transaktionen, die auf „bc 1 pszp...rehc 4“ verweisen. Die erste wird zur Zahlung der Gasgebühr für die folgende „Enthüllungs“-Phase verwendet, die andere ist das Wechselgeld.

In der „Reveal“-Phase können Sie sehen, dass es zwei utxo-Eingaben gibt, die den ersten beiden Ausgaben der vorherigen Commit-Phase entsprechen. Diese Transaktion gibt zunächst einen OP_RETURN aus, in dem der Hash des Ausgangszustands von CAT 20 gespeichert wird. Anschließend wird ein Minter ausgegeben, der im nachfolgenden Mint-Prozess eine wichtige Rolle spielt und zur Aufrechterhaltung der Zustandsänderungen des Mint-Prozesses dient.

Rückblickend auf den gesamten Bereitstellungsprozess folgen „Commit“ und „Reveal“ den beiden Schritten „Übermittlung“ und „Reveal“, die häufig in der Blockchain verwendet werden. Es handelt sich um eine relativ häufige Methode zum Bereitstellen einiger Projektdaten. Etappen werden bekannt gegeben.

Als

Wenn wir uns Mint Token zum ersten Mal ansehen, sieht die Transaktion so aus.

Wie Sie im Bild oben sehen können, weist der Prozess von Mint die folgenden Merkmale auf.

  • Die Eingabe von Mint ist ein Minter, der zunächst während der Bereitstellung generiert wird.

  • Jede Münzstätte hat einen und nur einen Münzprüfer als Input und eine beliebige Anzahl von Münzprüfern als Ausgabe (etwas problematisch).

  • Jede Münzstätte hat nur einen Token (etwas problematisch)

  • Die Reihenfolge der Ausgabe ist erforderlich, auf Minter muss Token folgen

Wenn wir den Mint-Prozess kennen, können wir tatsächlich einige besondere Situationen finden, die den gesamten Mint-Prozess interessant machen.

Beispielsweise kann Minter als Ausgabe der Mint-Transaktion 1, ein Vielfaches oder sogar 0 sein. Wenn Mint jedes Mal auf 1 gesetzt wird, bleibt die Anzahl der Minter, die im gesamten Netzwerk verwendet werden können, unverändert (1), was dazu führt, dass Mint überfüllt ist und jeder sich diesen Minter schnappen muss, um dies zu vermeiden In diesem Fall müssen Sie die Anzahl der ausgegebenen Minter jedes Mal auf mehr als 1 einstellen, damit nach dem Mint immer mehr Minter verwendet werden können.

Allerdings bedeutet jede zusätzliche Ausgabe von Minter, dass Sie einen zusätzlichen Utxo bezahlen müssen. Aus wirtschaftlichen Gründen werden mehr Menschen bereit sein, Minter auf 0 zu setzen, was unweigerlich zu einer Minter-Deflation führt, die einige Leute dazu zwingt, eine Spende zu leisten und zu zahlen der zusätzliche Minter freiwillig.

In der V2-Version werden standardmäßig zwei Minter generiert, und der Status der beiden Minter wird so ähnlich wie möglich sein.

Transaktionsstrukturierung

Einige Freunde haben möglicherweise ein Problem entdeckt: Warum kann Minters Utxo zum Erstellen von Transaktionen verwendet werden? Um dieses Problem zu verstehen, müssen Sie den Quellcode des „Vertrags“ analysieren.

1. utxo offenbaren

Zuerst analysieren wir die Transaktion während des Offenlegungsprozesses und stellen fest, dass sie den Ausgabe-Commit der vorherigen Transaktion als Eingabe verwendet. Warum können wir ein utxo, das nicht unsere Adresse ist, nehmen und die Eingabe der Transaktion erstellen?

Nach dem gesunden Menschenverstand entspricht ein privater Schlüssel einem öffentlichen Schlüssel, und der öffentliche Schlüssel leitet die Adresse ab. Bei der Überprüfung, ob eine Eingabe-UTXO gültig ist, wird normalerweise durch einen Vergleich festgestellt, ob die Signatur nach der Entschlüsselung mit dem öffentlichen Schlüssel mit der Originaltransaktion übereinstimmt. Dieser Teil der Logik ist im Bitcoin-Skript geschrieben. So können wir die Logik des Skripts geschickt umschreiben. Die im Skript geschriebenen öffentlichen und privaten Schlüsselpaare gehören zu unserer eigenen Adresse, sodass wir utxo an zwei verschiedenen Adressen steuern können.

Wenn wir uns den Quellcode ansehen, können wir sehen, was passiert ist:

Hier gibt es ein weiteres Problem: Ein privater Schlüssel entspricht einem öffentlichen Schlüssel. Warum unterscheidet sich die generierte Festschreibungsadresse von unserer Adresse? Hier können Sie es im Quellcode sehen

Mit anderen Worten: Unser privater Schlüssel passt den öffentlichen Schlüssel entsprechend einem ISSUE_PUBKEY an, der auch ein Merkmal der P 2 TR-Adresse ist.

2、minter uxo

Während des Offenlegungsprozesses verwenden wir unterschiedliche utxo als Eingabe, aber tatsächlich ist der Verschlüsselungsschlüssel derselbe, nämlich der private Schlüssel des Bereitstellers. Aber in der Minter-Phase kann jeder diese utxo als Eingabe verwenden, wie wird das gemacht?

Ich vermute, dieser Teil ist die zuvor erwähnte Fähigkeit von OP_CAT, also die Fähigkeit von Smart Contracts. Jeder Minter ist ein Smart Contract. Der Quellcode dieses Teils wurde jedoch derzeit nicht veröffentlicht und die konkrete Implementierung ist uns noch nicht bekannt.

Transaktionsstatus (V2)

Im Minter bleibt auch der Zustand erhalten. Dieser Status existiert an zwei Stellen: Eine befindet sich im OP_RETURN der Transaktionsausgabe und die andere wird im Smart-Vertrag gespeichert, bei dem es sich um den oben erwähnten Minter und Token handelt.

Was in OP_RETURN gespeichert wird, ist der Hash des aktuellen Transaktionsausgabestatus, und die verbleibenden Mint-Zeiten des Tokens werden im Vertrag gespeichert. Nach jedem Mint entspricht die Anzahl der Mints des neu generierten Minters der verbleibenden Anzahl an Mints dividiert durch zwei. Mit einem Diagramm dargestellt:

Am Ende des Spiels beträgt die verbleibende Anzahl aller Minter 0.

Zurück zum ursprünglichen Bild: Minter ist nicht nur ein Smart Contract, sondern auch der generierte Token ist ein Smart Contract, nämlich CAT 20. CAT 20 hat zwei Grundzustände: Menge und Adresse des Token-Eigentümers. Sie können sehen, dass sich Ihr CAT 20 im Gegensatz zum vorherigen BRC 20 oder der vorherigen Inschrift nicht auf dem UTXO Ihrer Adresse befindet.

Überweisen

Bei der Übertragung muss die Anzahl der Eingabe- und Ausgabe-Tokens in der Transaktion konsistent sein. Natürlich kann es in derselben Transaktion mehrere verschiedene Token geben, solange die Eingabe- und Ausgabenummern verschiedener Token konsistent sind.

Brennen

Wenn Sie den Token brennen möchten, müssen Sie ihn nur an eine normale Adresse übertragen.

Zusammenfassen

Es ist ersichtlich, dass alle Vorgänge vom Benutzer selbst erstellt werden, was sehr flexibel ist und daher im Vertragsteil viel Überprüfungslogik erforderlich ist. Einige der bisher aufgedeckten Schwachstellen sind auch auf Nachlässigkeiten in der Verifizierungslogik zurückzuführen.

Ein solches Design kann einige Vorteile haben:

  • Wenn Sie den Haltestatus aller Token ermitteln möchten, müssen Sie nur die Utxo des Tokens überprüfen und müssen nicht weiter nachschlagen.

  • Wenn Sie die aktuelle Situation von Mint überprüfen möchten, können Sie in den Daten in OP_RETURN nach Transaktionen mit cat suchen.

ZAN ist hier, um Wasser ohne Schwelle zu bekommen!

Tipp: Sie können alle 24 Stunden einen kostenlosen Testnet-Token von 0,01 ETH erhalten, um Web3-Projekte im Ethereum-Ökosystem zu erleben und zu testen. Klicken Sie, um ihn jetzt zu erhalten: https://zan.top/faucet?chInfo=ch_WZ

Weitere öffentliche Ketten werden bald unterstützt ~

Dieser Artikel wurde von Yeezo (X-Konto @GaoYeezo 75065) vom ZAN-Team (X-Konto @zan_team) verfasst.

#BTC