Ausgehend von der Bitcoin-Anwendungsprogrammierung erklären zehntausend Worte die Programmierbarkeit von CKB im Detail

Der folgende Inhalt stammt aus dem Nervos Talk-Forum, geschrieben von Ajian (Chefredakteur der Bitcoin-Content-Plattform BTC Study).

Zusammenfassung

Um die Programmierbarkeit eines Systems zu verstehen, müssen wir die strukturellen Eigenschaften des Systems identifizieren. Die Erforschung der Anwendungsprogrammierung auf Basis von Bitcoin-Skripten hilft uns, die Grundstruktur von CKB Cell und sein Programmierparadigma zu verstehen. Darüber hinaus zerlegt es die Programmierelemente von CKB in die entsprechenden Teile und hilft uns, die Programmierbarkeitsgewinne zu verstehen, die jeder Teil mit sich bringt.

1. Einleitung

„Programmierbarkeit“ ist eine Dimension, die beim Vergleich von Blockchain-Systemen häufig berücksichtigt wird. Allerdings gibt es häufig Meinungsverschiedenheiten darüber, wie Programmierbarkeit beschrieben wird. Ein gebräuchlicher Ausdruck ist „XX Blockchain unterstützt Turing-vollständige Programmiersprache“ oder „XX Blockchain unterstützt allgemeine Programmierung“, was bedeuten soll, dass „XX Blockchain“ hier eine leistungsstarke Programmierbarkeit aufweist. An diesen Aussagen ist etwas Wahres dran: Systeme, die die Turing-vollständige Programmierung unterstützen, sind im Allgemeinen einfacher zu programmieren als Systeme, die dies nicht tun. Es gibt jedoch viele Aspekte der strukturellen Merkmale von Smart-Contract-Systemen, und diese Aussage berührt nur einen davon. Daher reicht es nicht aus, ein ausreichend tiefes Verständnis zu erlangen: Entwickler können daraus keine Anleitung erhalten und normale Benutzer können nicht unterscheiden es davon.

Zu den strukturellen Merkmalen des Smart-Contract-Systems gehören:

• Die Grundform des Zustandsausdrucks (Vertrag) (Konto vs. Transaktionsausgabe)
• Ob es erlaubt ist, beliebige Berechnungen zu programmieren (der Begriff „Turing Complete“ betrifft dies). Aspekt)
• Kann der Ausführungsprozess neue Daten erstellen oder werden nur boolesche Werte ausgegeben? (Berechnung vs. Verifizierung)
• Ob es erlaubt ist, zusätzliche Zustände im Vertrag aufzuzeichnen
• Ob ein Vertrag während der Ausführung auf den Zustand eines anderen Vertrags zugreifen kann

Also, zusätzlich zu „ob beliebige Berechnungen programmiert werden können“, Zumindest gibt es vier Merkmale, die die Programmierbarkeit eines Smart-Contract-Systems beeinflussen. Man kann sogar sagen, dass diese anderen Merkmale wichtiger sind, weil sie auf einer tieferen Ebene bestimmen, was einfacher und was schwieriger umzusetzen ist;

Zum Beispiel wird Ethereum oft als Beispiel für gute Programmierbarkeit genommen. Die grundlegende Form des Statusausdrucks in Ethereum ist jedoch ein Konto, und es ist schwierig, Peer-to-Peer-Verträge (z. B. Zahlungskanäle) zu programmieren -zu-eins-Wettverträge) ——Es ist nicht absolut unmöglich, es zu erreichen, es ist einfach undankbar. Es ist nicht so, dass es im Ethereum-Ökosystem nie Projekte gegeben hätte, die versuchten, Zahlungskanäle/Statuskanäle zu implementieren. Es gibt auch viele theoretische Diskussionen, aber diese Projekte scheinen heute inaktiv zu sein – dies kann offensichtlich nicht auf mangelnde Bemühungen der Entwickler zurückgeführt werden. Es ist kein Zufall, dass die heute auf Ethereum aktiven Projekte alle die Form von „Fondspools“ und nicht von „Punkt-zu-Punkt-Verträgen“ haben. Ebenso mag man mit der Programmierbarkeit von Ethereum sehr zufrieden sein, aber wenn es darum geht, eine „Kontoabstraktion“ (die auch als Verallgemeinerung des Wallet-Konzepts verstanden werden kann) zu erreichen, ist das Kontomodell von Natur aus mangelhaft.

In ähnlicher Weise erfordert die Erforschung der Programmierbarkeit von CKB auch, dass wir die strukturellen Merkmale des CKB-Smart-Contract-Systems in diesen Aspekten verstehen. Was wir bereits wissen, ist, dass CKB die Programmierung beliebiger Berechnungen ermöglicht, die Aufzeichnung zusätzlicher Zustände innerhalb von Verträgen ermöglicht und es einem Vertrag ermöglicht, während der Ausführung auf den Zustand eines anderen Vertrags zuzugreifen. Allerdings ist die Vertragsform das Ergebnis der Transaktion (eine sogenannte „Zelle“), was es grundlegend von Ethereum unterscheidet. Daher hilft uns das Verständnis des Ethereum-Smart-Contract-Systems und der darin enthaltenen Vertragsinstanzen weder zu verstehen, wie CKB diese Strukturmerkmale implementiert, noch hilft es uns, die Programmierbarkeit von CKB zu verstehen.

Glücklicherweise scheinen intelligente Verträge auf Bitcoin die beste Grundlage für uns zu bieten, um die Programmierbarkeit von CKB zu verstehen. Dies liegt nicht nur daran, dass die Grundform des Zustandsausdrucks von Bitcoin auch die Ausgabe einer Transaktion ist (genannt „UTXO“), sondern auch daran, dass wir mit Hilfe eines von der Bitcoin-Community vorgeschlagenen Konzepts „Covenants“ diesen CKB verstehen können verfügt über die oben genannten strukturellen Merkmale und den Programmierbarkeitsgewinn, der durch die entsprechende Aufteilung des Endeffekts in mehrere Teile und deren schrittweise Identifizierung erzielt wird.

2. CKB vs. BTC: Was ist mehr?

Grundstruktur

Als Grundform des Bitcoin-Statusausdrucks verfügt Bitcoins UTXO („Unspent Transaction Output“) über zwei Felder:

• Der Betrag in Satoshi (Satoshi) gibt an, dass der UTXO den Wert von Bitcoin hat
• Der öffentliche Schlüssel des Skripts, auch Sperrskript genannt, stellt die Bedingungen dar, die erfüllt sein müssen, um die Gelder auszugeben, also das Smart-Contract-Programm, das die Bedingungen für die Freischaltung der Gelder festlegt.

Im Vergleich zu späteren Smart-Contract-Systemen sind Bitcoin-Skripte recht begrenzt:

• Die Programmierung beliebiger Berechnungen ist nicht möglich. Es gibt nur wenige praktische Berechnungen, die zur Überprüfung verwendet werden können (Signaturprüfung, Hash-Preimage-Prüfung, Zeitprüfung).
• Die Aufzeichnung zusätzlicher Zustände innerhalb des Vertrags ist nicht möglich. Es ist beispielsweise nicht möglich, ein Skript zu verwenden, um den Anteil/die Höhe einer einzelnen Ausgabe zu begrenzen. Es ist auch nicht möglich, einen Token darin zu verbergen.)
• Es ermöglicht auch keinen Zugriff auf den Status eines anderen Vertrags während der Ausführung (Jedes Skript ist ein unabhängiges Universum und man kann nicht voneinander abhängen).

Obwohl diese Art von Skript begrenzt ist, mangelt es ihr nicht an der Fähigkeit, erstaunliche Anwendungen zu programmieren, und sie ist auch die Grundlage für uns, die Programmierbarkeit von CKB zu untersuchen. Später wird es einen speziellen Abschnitt geben, in dem zwei Beispiele für die Bitcoin-Skriptprogrammierung vorgestellt werden.

Im Gegensatz dazu heißt die Zustandseinheit von CKB „Zelle“ und hat vier Felder:

• Kapazität, die der Menge von UTXO ähnelt und die Größe des Raums ausdrückt, den die Zelle belegen kann, in Byte-Einheiten;
• Lock Script, ein öffentlicher Skriptschlüssel ähnlich wie UTXO, definiert den Besitz der Zelle nur, wenn die bereitgestellten Daten das Lock Script passieren können. Die Zelle kann „aktualisiert“ werden (man kann auch sagen, dass die Zelle freigegeben und verwendet wird). diese Kapazitäten zum Umwandeln einer neuen Zelle);
• Darüber hinaus können Lock Script und Type Script auch beliebige Berechnungen programmieren. Sie können jeden beliebigen Signaturverifizierungsalgorithmus programmieren, Sie können auch jede beliebige Vorbildprüfung für jeden beliebigen Hash-Algorithmus usw. programmieren.
• Leser können die Verbesserung der Programmierbarkeit von Cell im Vergleich zu UTXO leicht erkennen:

Cell kann jede beliebige Berechnung programmieren, anstatt nur bestimmte Berechnungen zu programmieren;

Aufgrund der Daten- und Typskriptfelder , kann die Zelle zusätzlichen Status aufzeichnen; dadurch kann die Zelle das sogenannte „UDT (User-Defined Token)“ tragen.

• In Kombination mit Cells eigener „Transaktionsausgabe“-Struktur sind die Vorteile, die diese beiden Punkte mit sich bringen können, bereits sehr, sehr groß. Allein aus der obigen Beschreibung wissen wir jedoch immer noch nicht, wie Cell „den Laufzeitzugriff eines Vertrags“ implementiert „der Status eines anderen Vertrags“. Dazu müssen wir uns einem Konzept zuwenden, das in der Bitcoin-Community schon seit langem diskutiert wird: „Covenants“.
• Einschränkungen und Selbstbeobachtung

Die ursprüngliche Absicht von Beschränkungen besteht darin, die Ausgaben für einen bestimmten Geldbetrag einzuschränken. Beim aktuellen Bitcoin (für das noch keine Einschränkungsvorschläge gemacht wurden) kann ein Geldbetrag, sobald er freigeschaltet ist, überall ausgegeben werden (zahlbar an einen beliebigen öffentlichen Schlüssel des Skripts). Die Idee der Beschränkungsklausel besteht jedoch darin, dass die Ausgabe nur an bestimmten Orten erfolgen kann. Beispielsweise kann eine bestimmte UTXO nur dann ausgegeben werden, wenn jemand eine Unterschrift vorlegen kann Für dieses UTXO wurde durch den Deal auch festgelegt, wofür es ausgegeben werden kann. Diese Funktion mag etwas seltsam erscheinen, kann aber einige interessante Anwendungen hervorbringen, die später in einem eigenen Abschnitt vorgestellt werden. Wichtig ist, dass es der Schlüssel zu unserem weiteren Verständnis der CKB-Programmierbarkeit ist.

Rusty Russell hat richtig darauf hingewiesen, dass die Einschränkungsklausel als die „Introspektion“-Fähigkeit der Transaktion verstanden werden kann, das heißt, wenn ein UTXO A von einer Transaktion B ausgegeben wird, kann der Skriptbetreiber einen Teil (oder alles) davon lesen Transaktion B und überprüfen Sie dann, ob sie mit den vom Skript vorab erforderlichen Parametern übereinstimmen. Ob beispielsweise der öffentliche Skriptschlüssel der ersten Ausgabe von Transaktion A mit dem öffentlichen Skriptschlüssel von UTXO A übereinstimmt (dies ist die ursprüngliche Bedeutung der Einschränkungsklausel).

Die Leser werden sich darüber im Klaren sein, dass die Eingabe einer Transaktion den Status einer anderen Eingabe derselben Transaktion lesen kann, wenn Sie über vollständige Selbstbeobachtungsfähigkeiten verfügen. Dadurch wird erkannt, was wir zuvor gesagt haben: „Ein Vertrag läuft zur Laufzeit“. Die Zugriffsmöglichkeit den Status eines anderen Vertrags. Tatsächlich ist CKB Cell genau auf diese Weise konzipiert.

Auf dieser Grundlage können wir diese vollständige Selbstbeobachtungsfähigkeit in vier Situationen unterteilen:

Lock Script liest andere (Eingabe und Ausgabe) Lock Script

Lock Script liest andere (Eingabe und Ausgabe) Type Script (und Daten)

• Type Script liest andere (Eingabe und Ausgabe) Lock Script
• Type Script liest andere (Eingabe und Ausgabe) Type Script (und Daten)
• Dies ermöglicht uns unter der Annahme (die funktionale Aufteilung von Lock Script und Type Script), Wir analysieren die Rolle der Selbstbeobachtungsfähigkeit jedes Teils in verschiedenen Anwendungsszenarien, das heißt, wir analysieren die Programmierbarkeitsgewinne, die uns jeder Teil bringt.
• In den folgenden beiden Kapiteln werfen wir einen Blick auf die aktuelle (noch nicht eingeschränkte Klauselvorschlag) Bitcoin-Skriptprogrammierung und die Funktionalität, die der eingeschränkte Klauselvorschlag voraussichtlich implementieren wird, um konkret zu verstehen, wie CKB Cell programmiert werden kann Machs besser.

3. Bitcoin-Skriptprogrammierung

In diesem Abschnitt werden „Lightning Channel/Lightning Network“ und „Discreet Log Contract (DLC)“ als Beispiele für Anwendungsprogrammierung basierend auf Bitcoin Script verwendet. Bevor wir fortfahren, müssen wir zwei Konzepte verstehen.

OP_IF und „Commitment Transaction“

Das erste Konzept ist der Prozesssteuerungs-Opcode im Bitcoin-Skript, wie zum Beispiel: OP_IF, OP_ELSE. Diese Opcodes unterscheiden sich nicht von IF in der Computerprogrammierung. Ihre Funktion besteht darin, unterschiedliche Anweisungen basierend auf unterschiedlichen Eingaben auszuführen. Im Zusammenhang mit Bitcoin-Skripten bedeutet dies, dass wir mehrere Entsperrpfade für Gelder einrichten können; gepaart mit der Timelock-Funktion bedeutet dies, dass wir Aktionen Priorität zuweisen können.

Nehmen Sie den berühmten „Hash Time Lock Contract (HTLC)“ als Beispiel. Dieses Skript wird in die Landessprache übersetzt als:

Oder Bob kann das Originalbild hinter einem bestimmten Hash-Wert H offenbaren und ihm dann sein eigenes Zeichen geben das Geld ausgeben;

Alternativ kann Alice das Geld mit ihrer Unterschrift nach einer gewissen Zeit T ausgeben.

Dieser „Entweder...oder...“-Effekt wird durch Prozesssteuerungs-Opcodes erreicht.

Der wichtigste Vorteil von HTLC besteht darin, dass es mehrere Operationen bündeln und Atomizität erreichen kann. Wenn Alice beispielsweise mit Bob BTC gegen CKB tauschen möchte, kann Bob zunächst einen Hash-Wert angeben und einen HTLC im Nervos-Netzwerk erstellen. Anschließend erstellt Alice einen HTLC auf Bitcoin mit demselben Hash-Wert. Alternativ nimmt Bob die von Alice über Bitcoin gezahlten BTC und enthüllt auch das Originalbild, sodass Alice CKB im Nervos-Netzwerk übernehmen kann. Oder wenn Bob das Originalbild nicht preisgibt, laufen beide Verträge aus und sowohl Alice als auch Bob können das investierte Geld zurückerhalten.

Nach der Aktivierung des Taproot Soft Forks wurde diese Funktion mehrerer Entsperrpfade durch die Einführung von MAST (Merkle Abstract Syntax Tree) weiter gestärkt: Wir können einen Entsperrpfad in einen Entsperrpfad im Merkle-Baum umwandeln. Jedes Blatt ist unabhängig Daher besteht keine Notwendigkeit, solche Flusskontroll-Opcodes zu verwenden. Und da die Offenlegung eines Pfads nicht die Offenlegung anderer Pfade erfordert, können wir einer Ausgabe eine größere Anzahl freigeschalteter Pfade hinzufügen, ohne uns um wirtschaftliche Probleme kümmern zu müssen.

Das zweite Konzept ist „Commitment-Transaktion“. Die Idee einer Commit-Transaktion besteht darin, dass eine gültige Bitcoin-Transaktion unter bestimmten Umständen auch dann noch wahr und bindend ist, wenn sie nicht von der Blockchain bestätigt wird.

Zum Beispiel besitzen Alice und Bob gemeinsam ein UTXO, und für dieses UTXO müssen beide Signaturen ausgegeben werden. Zu diesem Zeitpunkt erstellt Alice eine Transaktion, um den Betrag auszugeben, indem sie 60 % des Wertes an Bob überweist und den verbleibenden Wert an sich selbst übermittelt. Alice unterschreibt die Transaktion selbst und sendet sie an Bob. Für Bob besteht dann keine Notwendigkeit, die Transaktion an das Bitcoin-Netzwerk zu senden oder die Transaktion von der Blockchain bestätigen zu lassen. Auch der Zahlungseffekt der Transaktion ist real und glaubwürdig. Da Alice dieses UTXO nicht alleine ausgeben kann (und es daher nicht noch einmal ausgeben kann) und da die von Alice bereitgestellte Signatur gültig ist, kann Bob jederzeit seine eigene Signatur hinzufügen und dann die Transaktion rundsenden, um die Zahlung anzuerkennen. Mit anderen Worten: Alice gibt Bob durch diese gültige (nicht On-Chain-)Transaktion eine „glaubwürdige Verpflichtung“.

Commitment-Transaktionen sind das Kernkonzept der Bitcoin-Anwendungsprogrammierung. Wie bereits erwähnt, basieren die Verträge von Bitcoin auf Verifizierung, sind zustandslos und erlauben keinen Querzugriff. Wenn der Vertrag jedoch keinen Zustand enthält, wo werden diese Zustände gespeichert und wie kann der Vertrag sicher erweitert (Zustand geändert) werden? Commitment-Transaktionen geben eine einfache Antwort: Der Vertragsstatus kann in Form von Transaktionen ausgedrückt werden, sodass Vertragsteilnehmer die Zustände selbst speichern können, ohne sie auf der Blockchain anzeigen zu müssen das Problem, wie festgeschriebene Transaktionen sicher aktualisiert werden können; wenn wir uns außerdem Sorgen über die Gefahr machen, einen Vertrag abzuschließen (z. B. den Abschluss eines Vertrags, bei dem beide Parteien vor der Ausgabe unterzeichnen müssen), besteht für uns das Risiko, dass die andere Partei dies nicht tut Wenn Sie nicht reagieren und nicht weiterkommen, eliminiert das einfache Generieren und Unterzeichnen einer Verpflichtungstransaktion, die den Vertrag vorzeitig ausgibt, das Risiko und das Vertrauen in andere Teilnehmer.

Lightning Channel und Lightning Network

Lightning Channel ist ein Eins-zu-eins-Vertrag, bei dem zwei Parteien sich gegenseitig unbegrenzt oft bezahlen können, ohne dass eine Zahlung von der Blockchain bestätigt wird. Wie zu erwarten, werden Promise-Transaktionen verwendet.

Im Abschnitt „Verpflichtungstransaktionen“ haben wir einen Zahlungskanal eingeführt. Allerdings ermöglicht dieser Vertrag, der nur 2-aus-2-Mehrfachsignaturen verwendet, nur Einwegzahlungen. Das heißt, entweder zahlt Alice immer Bob, oder Bob zahlt Alice, bis sein Vertragsguthaben aufgebraucht ist. Wenn es sich um eine Zwei-Wege-Zahlung handelt, bedeutet dies, dass nach einer bestimmten Statusaktualisierung der Saldo einer Partei möglicherweise geringer ist als zuvor, er jedoch die letzte festgelegte Transaktion von der anderen Partei unterzeichnet hat. Gibt es eine Möglichkeit, ihn zu stoppen? Die alte Verpflichtungstransaktion übertragen, sodass TA nur die neueste Verpflichtungstransaktion übertragen kann?

Die Lösung von Lightning Channel für dieses Problem heißt „LN-Penalty“. Nehmen wir nun an, dass Alice und Bob jeweils 5 BTC in einem Kanal haben; nun möchte Alice Bob 1 BTC zahlen, also unterzeichnet sie eine Verpflichtungstransaktion wie diese und sendet sie an Bob:

Geben Sie #0, 10 BTC ein: Alie-Bob 2-von-2-Mehrfachsignatur-Ausgabe (d. h. Kanalvertrag)

Ausgabe #0, 4 BTC: Alice-Einzelsignatur

Ausgabe Nr. 1, 6 BTC: Entweder Alice-Bob-gemeinsamer temporärer öffentlicher Schlüssel Nr. 1 mit Einzelsignatur oder T1-Zeitsperre, Bob-Einzelsignatur

Bob signiert auch eine Commitment-Transaktion (entsprechend der obigen Transaktion) und sendet sie an Alice:

Eingabe Nr. 0, 10 BTC: Alie-Bob 2-von-2-Mehrfachsignatur-Ausgabe (d. h. Kanalvertrag)

Ausgabe Nr. 0, 6 BTC: Bob-Einzelsignatur

Ausgabe Nr. 1, 4 BTC: oder Bob-Alice gemeinsamer temporärer öffentlicher Schlüssel #1 Einzelsignatur oder T1-Zeitschloss, Alice Einzelsignatur

Der Trick hierbei liegt in diesem „gemeinsamen temporären öffentlichen Schlüssel“, der aus einem öffentlichen Schlüssel der eigenen Partei und einem öffentlichen Schlüssel der anderen Partei generiert wird Der gemeinsame temporäre öffentliche Schlüssel von Alice und Bob wird beispielsweise erhalten, indem einer von Alices eigenen öffentlichen Schlüsseln und ein von Bob bereitgestellter öffentlicher Schlüssel verwendet, jeweils mit einem Hash-Wert multipliziert und dann addiert werden. Wenn ein solcher öffentlicher Schlüssel generiert wird, kennt niemand seinen privaten Schlüssel. Wenn Bob Alice jedoch den privaten Schlüssel des von ihm bereitgestellten öffentlichen Schlüssels mitteilt, kann Alice den privaten Schlüssel des gemeinsamen temporären öffentlichen Schlüssels berechnen. ——Dies ist der Schlüssel dazu, wie Lightning Channel den alten Zustand „rückgängig machen“ kann.

Wenn beide Parteien das nächste Mal den Kanalstatus aktualisieren (Zahlung veranlassen) möchten, tauschen die beiden Parteien den privaten Schlüssel des temporären öffentlichen Schlüssels aus, der der anderen Partei in der vorherigen Runde gegeben wurde. Auf diese Weise wagen es die Teilnehmer nicht mehr, die letzte Commitment-Transaktion, die sie erhalten haben, zu übertragen: Die Ausgabe dieser Commitment-Transaktion weist einem selbst einen Wert zu, und der private Schlüssel des temporären öffentlichen Schlüsselpfads ist der anderen Partei bereits bekannt Sobald die alte Verpflichtungstransaktion gesendet wurde, kann die andere Partei diesen gemeinsamen temporären privaten Schlüssel sofort verwenden, um alle Gelder in dieser Ausgabe abzuheben. – Das ist es, was „LN-Strafe“ bedeutet.

Im Einzelnen ist die Reihenfolge der Interaktion: Die Partei, die die Zahlung initiiert, fordert zunächst einen neuen temporären öffentlichen Schlüssel von der anderen Partei an, erstellt dann eine neue festgeschriebene Transaktion und übergibt sie der anderen Partei, die die festgeschriebene Transaktion freigibt Runden Sie den privaten Schlüssel mit dem temporären öffentlichen Schlüssel ab. Diese Interaktionssequenz stellt sicher, dass die Teilnehmer immer zuerst neue Commitment-Transaktionen erhalten und dann die Commitment-Transaktionen, die sie in der vorherigen Runde erhalten haben, ungültig machen, sodass es vertrauenswürdig ist.

Zusammenfassend sind die wichtigsten Designs des Lightning-Kanals:

Beide Parteien verwenden immer Commitment-Transaktionen, um den internen Status des Vertrags auszudrücken, und verwenden Änderungen in Beträgen, um Zahlungen darzustellen.

Commitment-Transaktionen kosten immer den gleichen Input ( Beide Parteien müssen gleichzeitig eine signierte Eingabe bereitstellen, sodass alle Verpflichtungstransaktionen miteinander konkurrieren und letztendlich nur eine von der Blockchain bestätigt werden kann.

Die Signaturen der beiden Teilnehmer sind nicht dieselbe Verpflichtungstransaktion (; obwohl sie gepaart sind; Und die Transaktionen, die sie unterzeichnen, sind für sie selbst immer schädlicher.

Pfade entsperren: Ein Pfad kann mit Ihrer eigenen Signatur entsperrt werden, aber Sie müssen eine Weile warten, während der andere Pfad den öffentlichen Schlüssel der anderen Partei verwendet und nur geschützt ist, wenn einer Ihrer eigenen temporären privaten Schlüssel nicht offengelegt wird; Bei jeder Zahlung tauschen beide Parteien eine neue Verpflichtungstransaktion gegen den temporären privaten Schlüssel aus, der von der anderen Partei in der vorherigen Runde verwendet wurde. Daher wagt die Partei, die den temporären privaten Schlüssel übergeben hat, die alte Verpflichtungstransaktion nicht mehr. , die letzte festgeschriebene Transaktion wird „storniert“ und der Status des Vertrags wird aktualisiert (Eigentlich sind diese festgeschriebenen Transaktionen alle gültige Transaktionen und können an die Blockchain gesendet werden, aber die Teilnehmer sind gezwungen, sie zu bestrafen. Wagen Sie es, erneut zu senden.)

Beide Parteien können jederzeit mit der von der anderen Partei unterzeichneten versprochenen Transaktion zurücktreten. Wenn beide Parteien jedoch zur Zusammenarbeit bereit sind, können sie eine neue Transaktion unterzeichnen, sodass beide Parteien ihr Geld sofort zurückerhalten können.

Da HTLC schließlich auch in der Commitment-Transaktion platziert werden kann, kann der Lightning-Kanal auch Zahlungen weiterleiten. Unter der Annahme, dass Alice einen Weg finden kann, der aus hin und her verbundenen Blitzkanälen besteht, und Daniel erreichen kann, kann eine vertrauenswürdige Multi-Hop-Zahlung erreicht werden, ohne einen Kanal mit Daniel zu öffnen. Das ist das Lightning Network:

Alice -- HTLC --> Carol -- HTLC --> Alice

Als Alice einen solchen Weg herausfindet und Daniel bezahlen möchte, fordert sie einen Hash-Wert von Daniel an, auf dessen Grundlage sie einen HTLC erstellt und ihn an Bob weitergibt, und fordert Bob auf, eine Nachricht an Carol weiterzuleiten und denselben HTLC bereitzustellen; die Nachricht fordert Carol auf, eine Nachricht an Daniel weiterzuleiten und denselben HTLC bereitzustellen. Als die Nachricht Daniel erreicht, enthüllt er Carol das Originalbild, erhält so den Wert von HTLC und aktualisiert den Vertragsstatus. Carol erwirkt dasselbe, erhält Bobs Zahlung und aktualisiert schließlich den Kanalstatus Status an Alice. Aufgrund der Eigenschaften von HTLC ist diese Zahlungsreihe entweder gemeinsam erfolgreich oder scheitert, sodass sie nicht vertrauenswürdig ist.

Das Lightning Network besteht aus nacheinander aufeinanderfolgenden Kanälen und jeder Kanal (Vertrag) ist unabhängig voneinander. Das bedeutet, dass Alice nur wissen muss, was in ihrem eigenen Kanal mit Bob passiert ist, und sich nicht darum kümmern muss, wie viele Interaktionen in den Kanälen anderer Leute stattgefunden haben, noch welche Währung diese Interaktionen verwendet haben oder ob sie tatsächlich über Kanäle erfolgt sind. .

Die Skalierbarkeit des Lightning-Netzwerks spiegelt sich nicht nur darin wider, dass die Zahlungsgeschwindigkeit innerhalb eines Lightning-Kanals nur durch die Hardware-Ressourceninvestition beider Parteien begrenzt ist, sondern auch darin, dass aufgrund der dezentralen Zustandsspeicherung ein einzelner Knoten dies tun kann Nutzen Sie den größten Hebel zu den niedrigsten Kosten.

Drudent Log Contract

Der Prudent Log Contract (DLC) verwendet eine kryptografische Technik namens „Adaptersignatur“, um Bitcoin-Skripten die Programmierung von Finanzverträgen zu ermöglichen, die von externen Ereignissen abhängen.

Mit der Adaptersignatur kann eine Signatur erst nach dem Hinzufügen eines privaten Schlüssels zu einer gültigen Signatur werden. Am Beispiel der Schnorr-Signatur ist die Standardform der Schnorr-Signatur (R, s), wobei:

R = r.G # Der in der Signatur verwendete Nonce-Wert r wird mit dem Punkt zur Erzeugung der elliptischen Kurve multipliziert, was auch möglich ist soll der öffentliche Schlüssel von r sein

s = r + Hash(R || m || P) * p # p ist der private Schlüssel der Signatur, P ist der öffentliche Schlüssel

Die Überprüfung der Signatur bedeutet die Überprüfung von s.G = r.G + Hash(R || m || P) * p.G = R + Hash(R || m || P) * PK

Angenommen, ich erhalte ein Datenpaar (R, s'), wobei:

R = R1 + R2 = r1.G + r2.G

s ' = r1 + Hash(R || m || P) * p

Offensichtlich ist dies keine gültige Schnorr-Signatur. Sie kann die Signaturüberprüfungsformel nicht bestehen . Ich kann es jedoch dem Prüfer beweisen, solange TA den privaten Schlüssel von R2 kennt, kann r2 daraus eine gültige Signatur machen:

s'.G + R2 = R1 + Hash(R || m || P) * P + R2 = R + Hash(R || m || P) * P

Adaptersignatur ermöglicht, dass die Gültigkeit einer Signatur von geheimen Daten abhängt und überprüfbar ist. Aber was hat das mit Finanzverträgen zu tun?

Angenommen, Alice und Bob möchten auf den Ausgang eines Fußballspiels wetten. Alice und Bob setzen jeweils 1 BTC auf Green Goblin und Alina. Darüber hinaus verspricht die Fußballkommentar-Website Carol, bei Bekanntgabe des Ergebnisses eines Fußballspiels eine Nonce R_c zu verwenden, um die Signatur s_c_i des Ergebnisses zu veröffentlichen.

Es ist ersichtlich, dass es drei mögliche Ergebnisse gibt (also hat Carols Unterschrift 3 Möglichkeiten):

• Der Grüne Kobold gewinnt, Alice gewinnt 1 BTC
• Alina gewinnt, Bob gewinnt 1 BTC
• Ein Unentschieden, die beiden Leute Gelder werden auf dem gleichen Weg zurückgegeben

Dazu erstellen die beiden Personen für jedes Ergebnis eine Verpflichtungstransaktion. Die Verpflichtungstransaktion, die sie für das erste Ergebnis erstellt haben, sieht beispielsweise so aus:

Input #0, 2 BTC: Alie-Bob 2-of-2-Multisignatur-Output (d. h. der Wettvertrag)

Output #0, 2 BTC: Alices Einzelsignatur

Die von Alice und Bob für diese Transaktion erstellten Signaturen sind jedoch keine (R, s), sondern Adaptersignaturen (R, s'); das heißt, die Signaturen, die beide Parteien einander geben, können nicht Um diesen Vertrag freizuschalten, muss ein geheimer Wert preisgegeben werden. Dieser geheime Wert ist genau das Originalbild von s_c_1.G, das Carols Signatur ist! Da der Nonce-Wert von Carols Signatur bestimmt wurde (es ist R_c), kann s_c_1.G konstruiert werden (s_c_1.G = R_c + Hash(R_c || 'The Green Goblin wins' || PK_c) * PK_c).

Wenn das Ergebnis bekannt gegeben wird, unter der Annahme, dass der Grüne Kobold gewinnt, wird Carol die Signatur ausstellen (R_c, s_c_1). Dann können sowohl Alice als auch Bob die Adaptersignatur des Gegners sowie ihre eigene Signatur vervollständigen, wodurch die obige Transaktion zu einer gültigen Transaktion wird wird an das Netzwerk gesendet und löst den Settlement-Effekt aus. Aber wenn der Grüne Kobold nicht gewonnen hätte, hätte Carol s_c_1 nicht freigelassen und der vereinbarte Deal wäre kein gültiger Deal gewesen.

Das Gleiche gilt für die anderen beiden Transaktionen. Auf diese Weise machen Alice und Bob die Ausführung dieses Vertrags von externen Ereignissen abhängig (genauer gesagt verlassen sie sich auf die Übertragung externer Ereignisse durch die Assertionsmaschine in Form einer Signatur), ohne der Gegenpartei zu vertrauen. Auf diese Weise können große und kleine Finanzkontrakte wie Futures und Optionen umgesetzt werden.

Im Vergleich zu anderen Implementierungsformen ist das größte Merkmal des vorsichtigen Protokollvertrags seine Privatsphäre: (1) Alice und Bob müssen Carol nicht mitteilen, dass sie Carols Daten verwenden, was keinen Einfluss auf die Vertragsausführung hat alle; (2) Kettenbeobachter (einschließlich Carol) können nicht feststellen, welche Website-Dienste sie nutzen, indem sie Transaktionen über die Verträge von Alice und Bob ausführen, oder sogar feststellen, dass es sich bei ihrem Vertrag um einen Wettvertrag (und nicht um einen Blitzkanal) handelt.

4. Einführung in die Anwendung restriktiver Klauseln

OP_CTV und Überlastungskontrolle

Entwickler in der Bitcoin-Community haben eine Vielzahl von Vorschlägen vorgeschlagen, die als restriktive Klauseln klassifiziert werden können. Der aus heutiger Sicht bekannteste Vorschlag ist OP_CHECKTEMPLATEVERIFY (OP_CTV). Sein Konzept ist relativ einfach, behält jedoch eine beträchtliche Flexibilität bei und wird daher von der Bitcoin-Community, die sich für Einfachheit einsetzt, begrüßt. Die Idee von OP_CTV besteht darin, einen Hash-Wert im Skript festzuschreiben, um einzuschränken, dass die Gelder nur von der durch den Hash-Wert dargestellten Transaktion ausgegeben werden können Commit Die Eingabe der Transaktion wird nur auf die Eingabemenge festgeschrieben.

„Congestion Control“ ist ein gutes Beispiel, das die Eigenschaften von OP_CTV widerspiegeln kann. Sein grundlegendes Anwendungsszenario besteht darin, einer großen Anzahl von Benutzern dabei zu helfen, sich von der Börse (einer Umgebung, die Vertrauen erfordert) in einen Fondspool zurückzuziehen. Da dieser Fondspool OP_CTV zur Planung zukünftiger Ausgabemethoden verwendet, kann sichergestellt werden, dass Benutzer aus diesem Vertrauen aussteigen können -free Der Fonds-Pool benötigt keine Hilfe; da dieser Fonds-Pool nur als UTXO erscheint, vermeidet er die Zahlung hoher Bearbeitungsgebühren, wenn die Nachfrage nach On-Chain-Transaktionen hoch ist (reduziert von n Ausgängen auf 1 Ausgang); auch ab n Transaktionen Transaktionen reduziert auf 1 Transaktion). Benutzer im Pool können auf eine Gelegenheit warten und sich dann aus dem Pool zurückziehen.

Angenommen, Alice, Bob und Carol möchten jeweils 5 BTC, 3 BTC und 2 BTC von der Börse abheben. Dann kann die Börse mit 3 OP_CTV-Filialen eine Ausgabe in Höhe von 10 BTC vornehmen. Angenommen, Alice möchte Geld abheben, sie kann Zweig 1 verwenden; die Transaktion, die durch den vom OP_CTV dieses Zweigs verwendeten Hash-Wert dargestellt wird, bildet zwei Ausgaben, eine Ausgabe dient der Zuweisung von 5 BTC an Alice, die andere Ausgabe ist ein Geldpool. Verwenden Sie OP_CTV auch, um sich auf eine Transaktion festzulegen, die es Bob nur ermöglicht, 3 BTC abzuheben und die restlichen 2 BTC an Carol zu senden.

Das Gleiche gilt, wenn Bob oder Carol Geld abheben möchten. Wenn sie Geld abheben, können sie nur Transaktionen verwenden, die die entsprechende OP_CTV-Prüfung bestehen, das heißt, sie können nur den entsprechenden Betrag selbst bezahlen und das verbleibende Geld nicht nach Belieben abheben, sondern in einen gesperrten Fondspool gelangen OP_CTV stellt so sicher, dass unabhängig von der Reihenfolge, in der Benutzer ihr Geld abheben, die verbleibenden Benutzer vertrauensvoll aus dem Pool abheben können.

Abstrakt gesehen besteht die Rolle von OP_CTV hier darin, den Weg des Vertrags bis zum Ende seiner Lebensdauer zu planen, sodass der Kapitalpoolvertrag hier die Eigenschaft eines vertrauensfreien Ausstiegs beibehalten kann, unabhängig davon, welchen Weg er einschlägt oder in welchem ​​Zustand er sich befindet es erreicht.

Diese Art von OP_CTV hat auch eine sehr interessante Verwendung: „versteckter Einweg-Zahlungskanal“. Angenommen, Alice bildet einen solchen Pool und garantiert mit einem Skript wie diesem, dass die Gelder vertrauenswürdig in eine Ausgabe abgezogen werden können:

Entweder geben Alice und Bob es zusammen aus, oder nach einiger Zeit kann Alice es alleine ausgeben

Wenn Alice es tut Wenn Sie es Bob nicht verraten, wird Bob nicht wissen, dass eine solche Ausgabe vorhanden ist. Sobald Alice sie Bob offenbart, kann Bob diese Ausgabe als zeitkritischen Einweg-Zahlungskanal verwenden, und Alice kann das Geld sofort verwenden, um Bob zu bezahlen auf die Bestätigung in der Blockchain warten müssen. Bob muss Alice lediglich erlauben, seine zugesagte Transaktion in die Kette zu bekommen, bevor Alice sie selbst ausgeben kann.

OP_Vault und Tresore

OP_VAULT ist ein Vorschlag für eine Beschränkungsklausel, der speziell für die Konstruktion von „Tresoren“ vorgeschlagen wurde.

Tresorverträge sind als sicherere und fortschrittlichere Form der Selbstverwahrung konzipiert. Obwohl der aktuelle Multi-Signatur-Vertrag den Single Point of Failure eines einzelnen privaten Schlüssels vermeiden kann, kann der Besitzer des Wallets nichts unternehmen, wenn ein Angreifer eine bestimmte Schwelle an privaten Schlüsseln erhält. Der Tresor hofft, ein einmaliges Ausgabenlimit für die Gelder festzulegen. Gleichzeitig wird beim Abheben über den regulären Weg eine Wartezeit während der Wartezeit erzwungen. Der Abhebungsvorgang kann durch einen Notfall unterbrochen werden Wallet-Wiederherstellungsvorgang. Selbst wenn ein solcher Vertrag kompromittiert wird, kann der Besitzer des Wallets Gegenmaßnahmen einleiten (über den Notfall-Wiederherstellungszweig).

Theoretisch kann OP_CTV auch einen solchen Vertrag programmieren, aber es gibt viele Unannehmlichkeiten, darunter die Bearbeitungsgebühr: Während es sich zu einer Transaktion verpflichtet, verpflichtet es sich auch zur Bearbeitungsgebühr, die für die Transaktion gezahlt wird. Aufgrund des Zwecks eines solchen Vertrages muss die Zeitspanne zwischen Vertragsabschluss und Geldabhebung sehr lang sein, so dass es nahezu unmöglich ist, ein angemessenes Entgelt vorherzusagen. Obwohl OP_CTV die Eingaben nicht begrenzt, können Sie die Bearbeitungsgebühr erhöhen, indem Sie die Eingaben erhöhen. Allerdings werden alle bereitgestellten Eingaben zu Bearbeitungsgebühren, sodass es unrealistisch ist, CPFP anders zu verwenden, dh die abgehobenen Mittel auszugeben Für neue Transaktionen fallen Gebühren an. Darüber hinaus bedeutet die Verwendung von OP_CTV auch, dass ein solcher sicherer Vertrag nicht stapelweise zurückgezogen werden kann (und natürlich nicht stapelweise wiederhergestellt werden kann). Der

OP_VAULT-Vorschlag versucht, diese Probleme zu lösen, indem er neue Opcodes (OP_VAULT und OP_UNVAULT) vorschlägt. OP_UNVAULT ist für die Batch-Wiederherstellung konzipiert, daher werden wir es vorerst nicht erwähnen. Die Aktion von OP_VAULT ist wie folgt: Wenn wir es in einen Zweig des Skriptbaums einfügen, kann es verwendet werden, um einen umsetzbaren Opcode (z. B. OP_CTV) ohne bestimmte Parameter zu versprechen, wenn dieser Zweig ausgegeben wird. Transaktionen können bestimmte Parameter übergeben. andere Zweige können jedoch nicht geändert werden. Daher muss keine Bearbeitungsgebühr festgelegt werden. Unter der Annahme, dass diese Filiale auch über eine Zeitsperre verfügt, wird die Bearbeitungsgebühr endgültig festgelegt, da nur der Standort geändert werden kann Wo sich der Zweig befindet, werden andere Zweige im neuen Skriptbaum (einschließlich des Notfallwiederherstellungszweigs) nicht geändert, sodass wir einen solchen Rückzugsvorgang unterbrechen können.

Darüber hinaus gibt es zwei erwähnenswerte Punkte: (1) Die Aktion des OP_VAULT-Opcodes ähnelt einem anderen Einschränkungsvorschlag: OP_TLUV; Jeremy Rubin hat richtig darauf hingewiesen, dass dies bereits zu einem gewissen Grad zum Konzept der „Berechnung“ geführt hat Umfang: OP_TLUV /OP_VAULT verspricht zunächst einem Opcode, dass der Benutzer über eine neue Transaktion Parameter an den Opcode übergeben kann, wodurch das gesamte Skriptbaumblatt aktualisiert wird. Dies bedeutet nicht mehr „die Überprüfung der eingehenden Daten basierend auf bestimmten Bedingungen“, sondern „; generiert auf der Grundlage eingehender Daten neue aussagekräftige Daten“, obwohl die damit möglichen Berechnungen relativ begrenzt sind.

Der vollständige OP_VAULT-Vorschlag nutzt auch einige Vorschläge zur Mempool-Richtlinie (z. B. Transaktionen im v3-Format), um bessere Ergebnisse zu erzielen. Das erinnert uns daran, dass „Programmieren“ viel mehr bedeuten kann, als wir denken. (Ein ähnliches Beispiel ist Open Transaction im Nervos Network.)

5. CKB verstehen

In den beiden oben genannten Kapiteln haben wir vorgestellt, wie wir CKB in einer eingeschränkteren Struktur (Bitcoin UTXO) verwenden. Scripting führt zu interessanten Anwendungsvorschlägen um Selbstbeobachtungsfunktionen zu dieser Struktur hinzuzufügen, werden ebenfalls eingeführt.

UTXO Obwohl es nicht an Fähigkeiten zur Programmierung dieser Anwendungen mangelt, können Leser ihre Mängel oder Bereiche, die optimiert werden können, leicht erkennen, wie zum Beispiel:

• In LN-Penalty müssen Kanalteilnehmer jede vergangene Transaktion speichern. Eine Verpflichtungstransaktion und der entsprechende Strafgeheimwert als Reaktion auf den Betrug eines Gegners stellen eine Speicherbelastung dar. Wenn es einen Mechanismus gibt, der sicherstellen kann, dass nur die letzte Commitment-Transaktion wirksam wird und die alte Commitment-Transaktion nicht wirksam wird, kann diese Belastung beseitigt werden und es kann auch die Möglichkeit ausgeschlossen werden, dass Knoten ältere Commitments aufgrund von Fehlern verwechseln . Das Problem, dass Transaktionen in der Kette stattfinden und daher unerwartet bestraft werden.
• Im DLC wird davon ausgegangen, dass es viele mögliche Ergebnisse der Veranstaltung gibt und beide Parteien im Voraus viele Unterschriften generieren und diese einander übergeben müssen, was außerdem eine enorme Belastung für die Einnahmen darstellt Der DLC-Vertrag ist direkt an den öffentlichen Schlüssel gebunden. Daher ist seine Position nicht einfach zu übertragen. Gibt es eine Möglichkeit, die Vertragsposition zu übertragen?

Tatsächlich hat die Bitcoin-Community Antworten auf diese Fragen gefunden, die im Wesentlichen mit einem Sighash-Vorschlag (BIP-118 AnyPrevOut) zusammenhängen.

Wenn wir jedoch auf CKB programmieren, ist BIP-118 jetzt verfügbar (dieser Sighash-Tag kann mit der Fähigkeit zur Introspektion und spezifischen Signaturüberprüfung simuliert werden).

Durch das Erlernen der Bitcoin-Programmierung wissen wir nicht nur, wie man das Format „Transaktionsausgabe“ programmiert (was kann CKB programmieren), sondern auch, wie man diese Anwendungen verbessert (was können wir tun, wenn wir diese Anwendungen auf CKB programmieren). Nutzen Sie die Fähigkeiten von CKB sie verbessern). Für CKB-Entwickler kann die auf Bitcoin-Skripten basierende Programmierung als Lehrbuch oder sogar als Abkürzung betrachtet werden.

Nachfolgend analysieren wir einzeln die Programmierbarkeit jedes Moduls der CKB-Programmierung. Betrachten wir vorerst nicht die introspektiven Fähigkeiten.

Sperrskript, das für beliebige Berechnungen programmiert werden kann

Wie oben erwähnt, kann UTXO nicht für beliebige Berechnungen programmiert werden. Lock Script kann, was bedeutet, dass Lock Script (bevor die Einschränkungen bereitgestellt werden) alles programmieren kann, das auf der UTXO-Programmierung basiert, einschließlich, aber nicht beschränkt auf den oben erwähnten Lightning-Kanal und DLC.

Darüber hinaus ermöglicht diese Fähigkeit, jede Berechnung zu überprüfen, Lock Script auch, mehr Authentifizierungsmethoden zu verwenden und ist flexibler als UTXO. Beispielsweise können wir einen Lightning-Kanal auf CKB implementieren, bei dem eine Partei die ECDSA-Signatur und die andere Partei die RSA-Signatur verwendet.

Tatsächlich ist dies einer der frühesten Bereiche, die Menschen auf CKB zu erforschen begannen: die Verwendung dieser flexiblen Identitätsüberprüfungsfunktion in der autonomen Obhut der Benutzer, um die sogenannte „Kontoabstraktion“ zu erreichen – Transaktionsgültigkeit Sowohl Autorisierung als auch Kontrollwiederherstellung flexibel und nahezu unbegrenzt. Im Prinzip handelt es sich dabei um eine Kombination aus „mehreren Ausgabestellen“ und „beliebiger Authentifizierungsmethode“. Beispiele für Implementierungen sind: JoyID Wallet, UniPass.

Darüber hinaus kann Lock Script auch den Eltoo-Vorschlag implementieren und so einen Lightning-Kanal realisieren, der nur die zuletzt festgeschriebene Transaktion beibehalten muss (tatsächlich kann Eltoo alle Punkt-zu-Punkt-Verträge vereinfachen).

Type Script, das beliebige Berechnungen programmieren kann

Wie oben erwähnt, ist eine der Hauptanwendungen von Type Script die Programmierung von UDT. In Kombination mit Lock Script bedeutet dies, dass wir UDT-gestützte Lightning-Kanäle (sowie andere Vertragsarten) implementieren können.

Tatsächlich kann die Trennung von Lock Script und Type Script als Sicherheitsverbesserung angesehen werden: Lock Script konzentriert sich auf die Implementierung von Verwahrungsmethoden oder Vertragsprotokollen, während Type Script sich auf die Definition von UDT konzentriert.

Darüber hinaus ermöglicht die Möglichkeit, Prüfungen auf Basis von UDT-Definitionen einzuleiten, UDT auch die Teilnahme an Verträgen auf ähnliche Weise wie CKB (UDT ist First-Class-Citizen).

Zum Beispiel: Der Autor hat einmal ein Protokoll zur Implementierung vertrauenswürdiger NFT-gesicherter Kredite auf Bitcoin vorgeschlagen. Der Schlüssel zu diesem Protokoll ist eine Commitment-Transaktion, bei der der Wert der Eingabe geringer ist als der Wert der Ausgabe (es handelt sich also noch nicht um eine gültige Transaktion). Sobald jedoch genügend Eingaben für diese Transaktion bereitgestellt werden können, handelt es sich um A gültige Transaktion: Sobald der Kreditgeber zur Rückzahlung in der Lage ist, kann der Kreditgeber das verpfändete NFT nicht mehr als sein Eigentum behalten. Der vertrauenswürdige Charakter dieser Verpflichtungstransaktion basiert jedoch darauf, dass die Transaktion die Beträge der Ein- und Ausgänge überprüft, sodass der Kreditgeber den Kredit nur in Bitcoin zurückzahlen kann – selbst wenn sowohl der Kreditgeber als auch der Kreditgeber bereit sind, eine andere Währung zu akzeptieren (z. B. Bitcoin). in RGB USDT, die vom Protokoll ausgegeben werden), kann die Commitment-Transaktion von Bitcoin nicht garantieren, dass der Kreditgeber sein NFT zurückerhalten kann, solange er den ausreichenden Betrag an USDT zurückgibt, da die Bitcoin-Transaktion den Status von USDT überhaupt nicht kennt ! (Überarbeitung: Mit anderen Worten, es ist unmöglich, eine Verpflichtungstransaktion zu konstruieren, die von der USDT-Rückzahlung abhängig ist.)

Wenn wir eine Prüfung basierend auf der Definition von UDT einleiten können, ist es für den Kreditgeber möglich, eine weitere Verpflichtungstransaktion zu unterzeichnen , was es dem Kreditgeber ermöglicht, USDT zur Rückzahlung der Zahlung zu verwenden. Bei der Transaktion wird der Betrag der USDT-Eingabe und der USDT-Ausgabe überprüft, sodass Benutzer eine vertrauensfreie Rückzahlung mit USDT erhalten.

Revision: Unter der Annahme, dass der als Sicherheit verwendete NFT und der zur Rückzahlung verwendete Token über dasselbe Protokoll (z. B. RGB) ausgegeben werden, kann das Problem hier gelöst werden. Wir können also eine Commitment-Transaktion basierend auf dem RGB-Protokoll erstellen dass der Zustandsübergang und die Rückzahlung von NFT gleichzeitig erfolgen können (Transaktionen werden verwendet, um zwei Zustandsübergänge innerhalb des RGB-Protokolls zu binden). Da RGB-Transaktionen jedoch auch auf Bitcoin-Transaktionen basieren, wird der Aufbau der Commitment-Transaktion hier etwas schwierig sein. Alles in allem ist das Problem zwar lösbar, aber der Token ist ein erstklassiger Bürger.

Als nächstes betrachten wir die Fähigkeit zur Selbstbeobachtung.

Lock Script liest andere Lock Scripts

Dies bedeutet volle Programmiermöglichkeiten auf Bitcoin UTXOs, nachdem die vorgeschlagenen Einschränkungen implementiert wurden. Einschließlich des oben erwähnten sicheren Vertrags sowie auf OP_CTV basierender Anwendungen (z. B. Überlastungskontrolle).

XueJie hat einmal ein sehr interessantes Beispiel erwähnt: Sie können eine Sammelkontozelle auf CKB implementieren, wenn Sie diese Zelle als Eingabe einer Transaktion verwenden und die Zelle, die sie ausgibt (Zelle, die dasselbe Sperrskript verwendet), mehr Kapazität hat, dann diese Die Eingabe erfordert keine Unterschrift und hat keinen Einfluss auf die Gültigkeit der Transaktion. Tatsächlich wäre eine solche Zelle ohne die Fähigkeit zur Selbstbeobachtung nicht möglich. Diese Art von Inkassokonto Cell eignet sich sehr gut als Inkassomethode für Institutionen, da es Gelder bündeln kann. Der Nachteil besteht darin, dass es eine schlechte Privatsphäre bietet.

Lock Script liest andere Typskripte (und Daten)

Eine interessante Anwendung dieser Fähigkeit sind Equity-Tokens. Das Sperrskript entscheidet anhand der Anzahl der Tokens in anderen Eingaben, ob es seine eigene Kapazität verwenden kann und wo die Kapazität ausgegeben werden kann (erfordert die Fähigkeit, das Sperrskript zu überprüfen).

Type Script liest andere Lock Scripts

Nicht sicher, aber es kann davon ausgegangen werden, dass es nützlich ist. Beispielsweise bleiben Sperrskripte, die die Ein- und Ausgaben einer Transaktion in Type Script überprüfen können, unverändert.

Type Script liest andere Type Scripts (und Daten)

Sammelkarten? Das Sammeln von n Token kann gegen einen größeren Token eingetauscht werden: )

6. Im Vergleich zu den vorherigen programmierbaren Smart-Contract-Systemen für beliebige Berechnungen (wie Ethereum) nimmt Nervos Network daher eine andere Struktur an Vertragssystemen ist es oft schwierig, eine Grundlage für das Verständnis des Nervos-Netzwerks zu bilden. In diesem Artikel wird eine Methode zum Verständnis der Programmierbarkeit von CKB Cell vorgeschlagen, beginnend mit der Anwendungsprogrammierung einer Struktur, die eingeschränkter ist als CKB Cell – BTC UTXO. Darüber hinaus können wir durch die Verwendung des Konzepts der „Introspektion“, um die Fähigkeit von Cell zum „vertragsübergreifenden Zugriff“ zu verstehen, die Situationen unterteilen, in denen Introspektionsfähigkeiten verwendet werden, und spezifische Verwendungszwecke für sie bestimmen.

Revision:

1. Unabhängig von der Cross-Access-Fähigkeit (d. h. der Introspektionsfähigkeit) können Sperrskripte als Bitcoin-Skripte mit State- und Extreme-Programming-Fähigkeiten betrachtet werden allein. Anwendung von Skripten;

2. Unabhängig von der Cross-Access-Fähigkeit (d. h. der Introspektionsfähigkeit) kann die Unterscheidung zwischen Sperrskripten und Typskripten als Sicherheitsverbesserung betrachtet werden: Sie trennt die Asset-Definitions- und Speichermethoden von UDT; Darüber hinaus implementieren Typskripte (sowie Daten), die den Status offenlegen können, den Effekt, dass UDTs erstklassige Bürger sind.

Das obige ist der detaillierte Inhalt vonAusgehend von der Bitcoin-Anwendungsprogrammierung erklären zehntausend Worte die Programmierbarkeit von CKB im Detail. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!