Inscripciones

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.

El modelo de contenido de las inscripciones funciona similar al de la web.Una inscripción está conformada por el tipo de contenido, conocido como el tipo MIME, y el contenido que es una cadena de bytes. Esto permite que el contenido de la inscripción se pueda obtener de un servidor web y tener la posibilidad de crear inscripciones HTML que usen el contenido de otras inscripciones.

El contenido de la inscripción está completamente en la cadena de bloques o blockchain, almacenado en scripts de taproot. Los scripts de taproot tienen muy pocas restricciones en cuanto a lo que pueden contener, y además reciben el descuento de testigo, lo que hace que el almacenamiento de contenido de las inscripciones sea relativamente económico.

Dado que los gastos de script de taproot (taproot script spends) sólo pueden hacerse desde salidas de taproot existentes, las inscripciones se hacen en dos fases de compromiso/revelación. Primero, en la transacción de compromiso, se crea una salida de taproot que se compromete a un script que contiene el contenido de inscripción. Segundo, en la transacción de revelación, la salida creada por la transacción de compromiso se gasta, revelando el contenido de la inscripción en la cadena.

El contenido de la inscripción se serializa utilizando push de datos dentro de condicionales que no han sido ejecutados, a estos se les llama "sobres". Los sobres consisten en un OP_FALSE OP_IF ... OP_ENDIF envolviendo los push de datos. Dado que los sobres son operaciones nulas, no cambian la semántica del script en el que están incluidos y pueden combinarse con cualquier otro script de bloqueo.

Una inscripción de texto que contiene la cadena "¡Hola, Mundo!" se serializa de la siguiente manera:

OP_FALSE
OP_IF
  OP_PUSH "ord"
  OP_PUSH 1
  OP_PUSH "text/plain;charset=utf-8"
  OP_PUSH 0
  OP_PUSH "¡Hola, Mundo!"
OP_ENDIF

Primero, se hace un push con el string ord para diferenciar que sobre va a utilizar la inscripción.

OP_PUSH 1 indica que el próximo push es el tipo de contenido y OP_PUSH 0 indica que los siguientes datos en el push contienen el contenido que se va a anexar. Múltiples push de datos deben ser utilizados para inscripciones de gran tamaño ya que una de las pocas restricciones de Taproot es que un push de datos no puede ser mayor a 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.

Contenido

El modelo de datos de las inscripciones es el de una respuesta HTTP, permitiendo que el contenido de la inscripción sea obtenido a través de un servidor web y visualizado en un navegador web.

Campos

Las inscripciones pueden incluir campos antes de un cuerpo opcional. Cada campo consta de dos push de datos, una etiqueta y un valor.

Actualmente, el único campo definido es content-type, con una etiqueta de 1, cuyo valor es el tipo MIME del cuerpo.

Para indicar el principio del cuerpo y el final de los campos se hace un push de datos vacío.

Las etiquetas no reconocidas se interpretan de forma diferente según sean pares o impares, siguiendo la regla "está bien que sean impares" utilizada por la Lightning Network.

Las etiquetas pares se utilizan para campos que pueden afectar a la creación, asignación inicial o transferencia de una inscripción. Por esto, las inscripciones con campos pares no reconocidos deben mostrarse como "no vinculadas", es decir, sin ubicación.

Las etiquetas impares se utilizan para campos que no afectan a la creación,asignación inicial o transferencia, tales como los metadatos adicionales, y por lo tanto se pueden ignorar.

IDs de las Inscripciones

Las inscripciones están alojadas en las entradas de una transacción de revelación. Para identificarlas se les asigna un ID como este:

521f8eccffa4c41a3a7728dd012ea5a4a02feed81f41159231251ecf1e5c79dai0

La parte delante de la i es el ID de transacción (txid) de la transacción de revelación. El número después la i es el índice (comenzando por 0) de las nuevas inscripciones que se están inscribiendo en la transacción de revelación.

Las inscripciones pueden estar en diferentes entradas, dentro de la misma entrada o en una combinación de ambas. En ambos de estos casos, el orden es claro, ya que un analizador sintáctico (parser) recorrería las entradas consecutivamente buscando los sobres de las inscripciones.

Sandboxing o Aislamiento

Las inscripciones en HTML y SVG están restringidas en un entorno aislado llamado sandboxing para evitar referencias a contenido fuera de la cadena, manteniendo así las inscripciones inmutables y contenidas dentro del entorno.

Esto se logra cargando las inscripciones en HTML y SVG dentro de iframes con el atributo sandbox y agregando Content-Security-Policy a los encabezados.