Dies ist Teil 4 der technischen Artikelreihe über Bitcoin-Verträge von Cointelegraph Research. Um den vorherigen Artikel zu lesen, klicken Sie auf Hier.
Die folgenden Opcodes implementieren nicht unabhängig voneinander die vollständige Covenant-Funktionalität. Stattdessen sind sie Bausteine für die Erstellung von Bündnissen, wenn sie mit anderen Opcodes oder Skriptelementen kombiniert werden.
OP_CHECKSIGFROMSTACK (OP_CSFS) und OP_CAT
OP_CSFS ist ein vorgeschlagener Opcode, der es Bitcoin-Skripten ermöglichen würde, Signaturen über beliebige, auf dem Stapel bereitgestellte Nachrichten zu überprüfen. Es ist anders als ON_CHECKSIGdas die Signaturen der Ausgabetransaktion entsprechend dem aktiven SIGHASH-Modus überprüft. Durch die Aktivierung der Signaturüberprüfung für andere Daten als die serialisierten Transaktionsdetails, OP_CSFS ermöglicht eine breitere Klasse von Konstruktionen, einschließlich orakelbasierter Skripte, bei denen eine externe Partei Off-Chain-Nachrichten signiert, die reale Ereignisse darstellen. Beispielsweise könnte ein vertrauenswürdiges Orakel Schnorr-Signaturen über Nachrichten veröffentlichen, die externe Ergebnisse verschlüsseln, und eine OP_CSFS-basiertes Skript könnte Zahlungen vom Vorhandensein einer gültigen Oracle-Signatur abhängig machen.
Von allein, OP_CSFS setzt keine Vereinbarungen um. Es kann externe Daten authentifizieren, bindet diese Daten jedoch nicht an die Struktur der Ausgabentransaktion. Diese Bindung erfordert OP_CAT.
OP_CAT ist ein vorgeschlagener Opcode, der die Verkettung zweier Werte auf dem Skriptstapel ermöglicht, um eine einzelne Bytesequenz anstelle von zwei unterschiedlichen zu bilden. In Kombination mit OP_CSFSermöglicht es dem Skript, ausgewählte Transaktionsfelder zu einer kanonischen Nachricht zusammenzustellen und zu überprüfen, ob eine bereitgestellte Signatur für diese Nachricht bindend ist.
OP_CSFS Und OP_CAT Zusammengenommen kann eine Introspektion durchgeführt werden, indem der Spender dazu gezwungen wird, Transaktionsdetails auf dem Zeugenstapel anzugeben. Wenn beides OP_CSFS Und ON_CHECKSIG Wenn die gleiche Signatur erfolgreich ist, beweist dies, dass die korrekten Transaktionsdetails an den Zeugenstapel weitergeleitet wurden und weiter begründet werden können. Durch die Prüfung der Transaktion anhand einer vordefinierten Vorlage wird eine Vertragskonstruktion erstellt, ähnlich wie OP_CTVkann durchgesetzt werden. Zwei minimale Assemblys zeigen, wie das funktioniert:
OP_CAT + Maulkorbtricks
Benutzen OP_CATbundesähnliche Konstruktionen können unter Taproot ohne durchgesetzt werden OP_CSFS indem man das Wie ausnutzt Schnorr signatures mit den Taproot-Sighash-Regeln interagieren, die in definiert sind BIP 341. Die Konstruktion wandelt OP_CHECKSIG, das normalerweise zur Authentifizierung des Besitzes eines privaten Schlüssels verwendet wird, in ein Tool zur Transaktionsintrospektion um.
Eine Schnorr-Signatur ist ein Paar ⟨R, s⟩. Unter normalen Umständen wird diese Schnorr-Signatur durch Auswahl einer geheimen Nonce generiert kden Punkt ableiten R = kgund Berechnen des Signaturwerts S als Funktion des Nachrichten-Hashs und des privaten Schlüssels. Anschließend überprüft der Verifizierer das Signaturpaar ⟨R, s⟩ gegen einen öffentlichen Schlüssel P und die Nachricht, die signiert wird. Dafür sorgt die Zufälligkeit von k S ist ohne Kenntnis des privaten Schlüssels unvorhersehbar und nicht reproduzierbar.
Der Trick der Selbstbeobachtung funktioniert, indem es Zufälligkeiten eliminiert, indem einige dieser Variablen im Voraus festgelegt werden. Anstatt zu wählen R Während des Signierens legt das Skript zufällig einen vorgegebenen Wert fest R und zu einem festen öffentlichen Schlüssel P. Da die Schnorr-Verifizierung einer deterministischen Gleichung folgt, wird es möglich, diese Werte so zu konstruieren, dass die Signatur skalar wird S muss einem Hash bestimmter Transaktionsparameter entsprechen.
Der Spender sorgt R Und S auf dem Zeugenstapel. OP_CAT verkettet sie zum Signaturpaar ⟨R, s⟩ im Format ON_CHECKSIG erwartet. Das Skript überprüft dies anhand des fest codierten öffentlichen Schlüssels P. Weil R Und P werden am Basispunkt fixiert G, ON_CHECKSIG akzeptiert das Paar nur, wenn S entspricht dem SHA256-Hash der tatsächlichen Transaktionsdaten, die vom Protokoll berechnet werden. Der Spender kann keine herstellen S das geht vorbei ON_CHECKSIG es sei denn, es spiegelt tatsächlich die tatsächlichen Transaktionsdaten wider. Der Spender muss die Transaktionsdaten zerkleinern, bis sein SHA256-Hash in einem bestimmten Byte endet, was im Durchschnitt etwa 256 Versuche erfordert und vernachlässigbare Kosten verursacht.
Auf diese Weise, ON_CHECKSIG wird nicht mehr zur Authentifizierung des Besitzes eines geheimen privaten Schlüssels verwendet, sondern um zu erzwingen, dass die Transaktion einer bestimmten Vorlage entspricht. Die Ausdruckskraft ist im Großen und Ganzen vergleichbar mit OP_CTV.
Da dieser Ansatz von Schnorr-Signaturen und dem Taproot-Sighash-Algorithmus abhängt, gilt er nur für SegWit v1-Ausgaben und keine Erweiterung auf SegWit v0-Ausgaben das den BIP-143-Digest und ECDSA-Signaturen verwendet.
In unserem nächsten Artikel beginnen wir mit unserer Diskussion darüber OP_CCVwas sogar noch leistungsfähiger ist als OP_CSFS Und OP_CAT kombiniert.
