Dies ist der zweite Artikel in a Serie Tiefes Eintauchen in einzelne Vorschläge, die einen Reifepunkt erreicht haben, der einen eingehenden Zusammenbruch verdient.
CheckSigfromStack (CSFS), die von Brandon Black und Jeremy Rubin mit BIP 348 vorgestellt wurden, ist kein Bund. Wie ich im Einführungsartikel zu dieser Serie sagte, sind einige der Vorschläge, die ich behandeln würde, keine Bündel, sondern synergieren oder mit ihnen in irgendeiner Weise mit ihnen zusammenziehen. CSFS ist das erste Beispiel dafür.
CSFS ist ein sehr einfaches Opcode, aber bevor wir so gut wie funktioniert, schauen wir uns die Grundlagen an, wie ein Bitcoin -Skript tatsächlich funktioniert.
Skript ist eine stackbasierte Sprache. Das bedeutet, dass Daten auf dem Stapel übereinander „gestapelt“ und durch Entfernen eines Elements vom oberen Rand des Stapels anhand dessen, was ein Opcode tut, entfernt werden, entweder die Daten oder ein Ergebnis davon an die Spitze des Stapels entfernt werden.
Es gibt zwei Teile eines Skripts, wenn es letztendlich ausgeführt und verifiziert wird, der „Zeuge“ zur Erschließung des Skripts und das in der Ausgabe enthaltene Skript. Das Zeugen-/Entsperren -Skript wird auf der linken Seite des Sperrenskripts “hinzugefügt”, und dann wird jedes Element dem Stapel von links nach rechts hinzugefügt (oder arbeitet). Sehen Sie sich dieses Beispiel an (das “|”Markiert die Grenze zwischen Zeugen und Skript):
1 2 | On_add 3 on_equal
Dieses Beispielskript fügt dem Stapel den Wert “1” hinzu und dann den Wert “2” darüber. OP_ADD nimmt die beiden obersten Elemente des Stapels und fügt sie zusammen, wobei das Ergebnis wieder auf den Stapel eingerichtet wird (jetzt ist alles, was auf dem Stapel ist, „3“). Ein weiterer „3“ wird dann dem Stapel hinzugefügt. Das letzte Element, Op_equal, nimmt die beiden obersten Elemente des Stapels und gibt ein „1“ an den Stapel zurück (1 und 0 können sowohl wahr oder falsche als auch falsche Zahlen darstellen).
Ein Skript muss mit dem letzten Element oben im Stapel enden, da das Skript (und die Transaktion, die es ausführt), fehlschlägt und wird als Konsens für ungültig angesehen.
Dies ist ein grundlegendes Beispiel für ein Pay-to-Pubkey-Hash (P2PKH) -Skript, dh die Legacy-Adressen, die mit einem „1“ beginnen:
Zunächst werden die Signatur und der öffentliche Schlüssel zum Stapel hinzugefügt. Dann wird DUP aufgerufen, das den oberen Stapelartikel nimmt und es dupliziert, um es an die Oberseite des Stapels zurückzugeben. Hash160 nimmt das Top -Stapelartikel (das öffentliche Schlüssel Duplikat), Hashes und gibt es dann an die Spitze des Stapels zurück. Der öffentliche Schlüsselhash aus dem Drehbuch wird auf den Stapel gestellt. Equalverify -Funktionen, die gleich wie gleich sind, greift die beiden Top -Stapel -Elemente ab und gibt basierend auf dem Ergebnis eine 1 oder 0 zurück. Die einzige Differenz ist, dass Equalverify auch nach Equal Vental verifiziert wird. Dies schlägt die Transaktion nicht aus, wenn das obere Stapelelement nicht 1 ist und auch das obere Stapelelement entfernt. Schließlich wird Checksig ausgeführt, wodurch sich die beiden obersten Stapelartikel annehmen, unter der davon ausgegangen wird, dass sie eine Signatur und ein Pubkey sind, und die Signatur implizit gegen den Hash der überprüften Transaktion überprüft. Wenn es gültig ist, legt es eine 1 über den Stapel.
Wie CSFs funktioniert
Checksig ist eines der am häufigsten verwendeten Opcodes in Bitcoin. Jede Transaktion mit fast keinen Ausnahmen nutzt dieses Opcode irgendwann in einem seiner Skripte. Die Signaturüberprüfung ist eine grundlegende Komponente des Bitcoin -Protokolls. Das Problem ist, dass es fast keine Flexibilität gibt, in welcher Nachricht Sie die Unterschrift überprüfen. Überprüfungen überprüfen nur eine Signatur gegen die überprüfte Transaktion. Es gibt eine gewisse Flexibilität, dh Sie können mit einem gewissen Grad an Freiheit entscheiden, auf welche Teile der Transaktion die Signatur gilt, aber das war’s.
CSFS zielt darauf ab, dies zu ändern, indem eine Signatur gegen eine willkürliche Nachricht überprüft wird, die direkt auf den Stapel gedrückt wird, anstatt sich auf die Überprüfung der Unterschriften gegen die Transaktion selbst beschränken zu lassen. Der Opcode folgt einer sehr grundlegenden Betriebsstruktur:
Die Signatur und die Nachricht werden auf den Stapel fallen gelassen, dann über die öffentliche Taste über ihnen, und schließlich greift CSFS die drei wichtigsten Elemente aus dem Stapel an, wobei sie von oben nach unten als öffentliche Schlüssel, Nachricht und Unterschrift von oben nach unten sind und die Unterschrift gegen die Nachricht überprüfen. Wenn die Signatur gültig ist, wird eine 1 auf den Stapel platziert.
Das war’s. Eine einfache Variante von Schecks, mit der Benutzer anstelle der Ausgabentransaktion beliebige Nachrichten angeben können.
Was ist CSFs nützlich für
Wofür genau ist das gut? Was nutzt die Überprüfung einer Unterschrift gegen eine willkürliche Nachricht auf dem Stapel anstatt gegen die Ausgabentransaktion?
Erstens in Kombination mit CTV Es kann ein Funktionalität bieten, das etwas entspricht, das Blitzentwickler von Anfang an gewünscht haben, schwimmende Signaturen, die sich an verschiedene Transaktionen befinden können. Dies wurde ursprünglich als eine neue Seufzflagge für Unterschriften vorgeschlagen (das Feld, das bestimmt, auf welche Teile einer Transaktion eine Signatur gilt). Dies war erforderlich, da eine Transaktionssignatur die Transaktions -ID der Transaktion abdeckt, die den ausgegebenen Ausgang erstellt hat. Dies bedeutet, dass eine Signatur nur für eine Transaktionsausgaben gültig ist genau Ausgabe.
Dies ist ein gewünschtes Verhalten für Blitz, da es uns ermöglichen würde, Kanalstrafen zu beseitigen. Jeder vergangene Blitzzustand benötigt einen Strafschlüssel und eine Transaktion, um sicherzustellen, dass Ihre Channel -Gegenpartei niemals eine von ihnen verwendet, um zu versuchen, Mittel zu beanspruchen, die sie nicht besitzen. Wenn sie versuchen, können Sie ihr gesamtes Geld beanspruchen. Eine überlegene Funktionalität wäre etwas, das es Ihnen ermöglicht, einfach die aktuelle Status -Transaktion an einen Vorgänger zu „anbringen“, um den Diebstahlversuch zu stoppen, indem sie Fonds korrekt verteilen, anstatt sie zu beschlagnahmen.
Dies kann mit einem grundlegenden Skript erreicht werden, das einen CTV -Hash und eine Signatur darüber übernimmt, die mit CSFs überprüft wird. Dies würde es jedem von diesem CSFS -Schlüssel unterzeichneten Transaktions -Hash ermöglichen, alle mit diesem Skript erstellten Ausgaben auszugeben.
Eine weitere nützliche Funktion ist die Delegation der Kontrolle eines UTXO. Genauso wie jeder von einem CSFS -Schlüssel unterzeichnete CTV -Hash einen UTXO mit einem dafür entwickelten Skript ausgeben kann, können andere Variablen in das Skript übergeben werden, gegen das man überprüft werden soll, z. B. einen neuen öffentlichen Schlüssel. Es könnte ein Skript konstruiert werden, mit dem ein CSFS -Schlüssel anmelden kann beliebig Der öffentliche Schlüssel, der dann mit CSFs validiert und für eine normale Überprüfungsvalidierung verwendet werden kann. Auf diese Weise können Sie die Fähigkeit delegieren, einen UTXO an andere auszugeben, ohne es aufketont zu werden.
Schließlich können in Kombination mit CAT CSFs verwendet werden, um eine viel komplexere Introspection -Funktionalität zu bestehen. Wie wir jedoch später in der Serie sehen werden, ist CSFS nicht erforderlich, um dieses fortgeschrittenere Verhalten zu emulieren, da Cat allein dazu in der Lage ist.
Gedanken schließen
CSFS ist ein sehr grundlegender Opcode, der auch eine einfache nützliche Funktionalität anbietet, die auch sehr gut mit den einfachsten Opcodes mit Covenant -Opcodes komponiert, um sehr nützliche Funktionen zu erzeugen. Während das obige Beispiel über schwimmende Signaturen spezifisch auf das Blitznetzwerk verweist, sind schwimmende Signaturen ein allgemein nützlicher Primitiv, das für jedes Protokoll gelten, das auf Bitcoin basiert, die vorab signierte Transaktionen verwendet werden.
Zusätzlich zu schwimmenden Signaturen ist die Skriptdelegation ein sehr nützlicher Primitiv, der weit über die Delegierung der Kontrolle über einen UTXO auf einen neuen öffentlichen Schlüssel hinausgeht. Die gleiche grundlegende Fähigkeit, Variablen nach der Tatsache in einen Skriptvalidierungsfluss zu „ablegen“, kann für alles gelten, nicht nur für öffentliche Schlüssel. Timelock -Werte, Hashock -Vorbereitungen usw. Jedes Skript, das eine Variable zum Überprüfen dieser Werte harten, kann nun dynamisch hinzugefügt werden.
Darüber hinaus ist CSFS ein sehr reifer Vorschlag. Es verfügt über eine Implementierung, die im flüssigen Netzwerk und in den Elementen lebt (die Codebasis -Flüssigkeitszwecke) Seit 2016. Darüber hinaus hatte Bitcoin Cash eine Version davon seit 2018.
CSFS ist ein sehr ausgereifter Vorschlag, der konzeptionell fast so lange zurückreicht, wie ich in diesem Raum war, mit mehreren reifen Implementierungen und sehr klaren Anwendungsfällen, auf die sie angewendet werden können.
