Inscriptions

Inscriptions inscribe gros with arbitrary content, creating groestlcoin-native digital artifacts, more commonly known as NFTs. Inscriptions do not require a sidechain or separate token.

These inscribed gros can then be transferred using groestlcoin transactions, sent to groestlcoin addresses, and held in groestlcoin UTXOs. These transactions, addresses, and UTXOs are normal groestlcoin transactions, addresses, and UTXOS in all respects, with the exception that in order to send individual gros, transactions must control the order and value of inputs and outputs according to ordinal theory.

Das Inhaltsmodell der inscription ist das des Webs. Eine inscription besteht aus einem Inhaltstyp, auch MIME-Typ genannt, und dem Inhalt selbst, bei dem es sich um eine Bytefolge handelt. Dies ermöglicht die Rückgabe von inscriptions von einem Webserver und die Erstellung von HTML-inscriptions , die den Inhalt anderer inscription verwenden und neu mischen.

Der Inhalt der Inscription ist vollständig in der Kette und wird in Taproot-Skriptpfad-Ausgabeskripten gespeichert. Für Taproot-Skripte gelten nur sehr wenige Einschränkungen hinsichtlich ihres Inhalts und sie erhalten zusätzlich den Witness-Rabatt, was die Speicherung von Inscription-Inhalten relativ kostengünstig macht.

Da Ausgaben für Taproot-Skripts nur aus vorhandenen Taproot-Ausgaben getätigt werden können, werden inscriptions mithilfe eines zweiphasigen Commit/Reveal-Verfahrens vorgenommen. Zunächst wird in der Commit-Transaktion eine Taproot-Ausgabe erstellt, die ein Commit für ein Skript mit dem Inhalt der Inschrift durchführt. Zweitens wird bei der Offenlegungstransaktion die durch die Festschreibungstransaktion erzeugte Ausgabe ausgegeben, um den Inhalt der Inschrift in der chain preiszugeben.

Der Inhalt der Inscription wird mithilfe von Daten-Pushs innerhalb nicht ausgeführter Bedingungen, sogenannter „Umschläge“, serialisiert. Umschläge bestehen aus einem OP_FALSE OP_IF … OP_ENDIF , das eine beliebige Anzahl von Daten-Pushs umschließt. Da Umschläge praktisch No-Ops sind, ändern sie nicht die Semantik des Skripts, in dem sie enthalten sind, und können mit jedem anderen Sperrskript kombiniert werden.

Eine inscription mit der Zeichenfolge "Hello, world!" wird wie folgt serialisiert:

OP_FALSE
OP_IF
  OP_PUSH "ord"
  OP_PUSH 1
  OP_PUSH "text/plain;charset=utf-8"
  OP_PUSH 0
  OP_PUSH "Hello, world!"
OP_ENDIF

Zuerst wird die Zeichenfolge ord gedrückt, um inscriptions von anderen Verwendungszwecken von Umschlägen zu unterscheiden.

OP_PUSH 1 indicates that the next push contains the content type, and OP_PUSH 0indicates that subsequent data pushes contain the content itself. Multiple data pushes must be used for large inscriptions, as one of taproot's few restrictions is that individual data pushes may not be larger than 520 bytes.

The inscription content is contained within the input of a reveal transaction, and the inscription is made on the first gro of its input. This gro can then be tracked using the familiar rules of ordinal theory, allowing it to be transferred, bought, sold, lost to fees, and recovered.

Inhalt

Das Datenmodell von inscriptions ist das einer HTTP-Antwort, sodass inscription inhalte von einem Webserver bereitgestellt und in einem Webbrowser angezeigt werden können.

Felder

Inscriptions können Felder vor einem optionalen Text enthalten. Jedes Feld besteht aus zwei Daten-Pushs, einem Tag und einem Wert.

Derzeit ist das einzige definierte Feld content-type mit dem Tag 1, dessen Wert der MIME-Typ des Körpers ist.

Der Anfang des Hauptteils und das Ende der Felder werden durch einen leeren Daten-Push angezeigt.

Nicht erkannte Tags werden unterschiedlich interpretiert, je nachdem, ob sie gerade oder ungerade sind. Dabei gilt die vom Lightning Network verwendete Regel "Es ist in Ordnung, ungerade zu sein".

Sogar Tags werden für Felder verwendet, die sich auf die Erstellung, Erstzuweisung oder Übertragung einer inscription auswirken können. So müssen inscription mit nicht erkannten geraden Feldern als "ungebunden“, also ohne Ortsangabe, angezeigt werden.

Ungerade Tags werden für Felder verwendet, die sich nicht auf die Erstellung, anfängliche Zuweisung oder Übertragung auswirken, wie z. B. zusätzliche Metadaten, und daher sicher ignoriert werden können.

Inscription IDs

Die inscriptions sind in den Eingaben einer Enthüllungstransaktion enthalten. Um sie eindeutig zu identifizieren, wird ihnen eine ID der Form zugewiesen:

521f8eccffa4c41a3a7728dd012ea5a4a02feed81f41159231251ecf1e5c79dai0

Der Teil vor dem „i“ ist die Transaktions-ID (txid) der Offenlegungstransaktion. Die Zahl nach dem i definiert den Index (beginnend bei 0) der neuen inscriptions, die in die Offenlegungstransaktion eingeschrieben werden.

Inscriptions können sich entweder in verschiedenen Eingaben (inputs), innerhalb derselben Eingabe oder in einer Kombination aus beiden befinden. In jedem Fall ist die Reihenfolge klar, da ein Parser die Eingaben nacheinander durchgehen und nach allen inscription envelopes suchen würde.

Sandboxen

HTML- und SVG-inscriptions werden in einer Sandbox gespeichert, um Verweise auf Inhalte außerhalb der chain zu verhindern, sodass die inscriptions unveränderlich und in sich geschlossen bleiben.

Dies wird erreicht, indem HTML und SVG-Inschriften in iframes mit dem Sandbox Attribut geladen werden und inscriptions inhalte mit Content-Security-Policy Headern bereitgestellt werden.