Les inscriptions inscrivent des sats avec un contenu arbitraire, créant ainsi des artefacts numériques natifs du Bitcoin, plus communément appelés NFT. Les inscriptions ne nécessitent pas de chaîne secondaire ni de jeton distinct.
Ces sats inscrits peuvent ensuite être transférés au moyen de transactions en Bitcoin, envoyés à des adresses en Bitcoin et conservés dans des UTXO en Bitcoin. Ces transactions, adresses et UTXO sont des transactions, adresses et UTXOS Bitcoin normales à tous égards, à l'exception du fait que pour envoyer des sats individuels, les transactions doivent contrôler l'ordre et la valeur des entrées et des sorties conformément à la théorie ordinale.
Le modèle de contenu des inscriptions est celui du web. Une inscription se compose d'un type de contenu, également connu sous le nom de type MIME, et du contenu lui-même, qui est une chaîne d'octets. Cela permet au contenu de l'inscription d'être renvoyé par un serveur web et de créer des inscriptions HTML qui utilisent et remixent le contenu d'autres inscriptions.
Le contenu de l'inscription est entièrement sur la chaîne, stocké dans les scripts taproot script-path spend. Les scripts taproot ont très peu de restrictions sur leur contenu et bénéficient en outre de la réduction pour les témoins, ce qui rend le stockage du contenu de l'inscription relativement économique.
Le contenu de l'inscription est sérialisé à l'aide de poussées de données à l'intérieur de conditionnelles non exécutées, appelées "enveloppes". Les enveloppes consistent en un OP_FALSE OP_IF ... OP_ENDIF enveloppant n'importe quel nombre de poussées de données. Les enveloppes étant effectivement des no-ops, elles ne modifient pas la sémantique du script dans lequel elles sont incluses et peuvent être combinées avec n'importe quel autre script de verrouillage.
Une inscription textuelle contenant la chaîne "Hello, world !" est sérialisée comme suit :
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
La chaîne ord est d'abord poussée, afin de distinguer les inscriptions des autres utilisations des enveloppes.
OP_PUSH 1 indique que la poussée suivante contient le type de contenu, et OP_PUSH 0 indique que les poussées de données suivantes contiennent le contenu lui-même. Pour les inscriptions volumineuses, il est nécessaire d'utiliser plusieurs poussées de données, car l'une des rares restrictions de taproot est que les poussées de données individuelles ne peuvent pas dépasser 520 octets.
Le contenu de l'inscription est contenu dans l'entrée d'une transaction reveal, et l'inscription est faite sur le premier sat de son entrée. Ce sat peut ensuite être suivi en utilisant les règles familières de la théorie ordinale, ce qui permet de le transférer, de l'acheter, de le vendre, de le perdre dans des frais et de le récupérer.
Contenu
Le modèle de données des inscriptions est celui d'une réponse HTTP, ce qui permet au contenu de l'inscription d'être servi par un serveur web et visualisé dans un navigateur web.
Champs
Les inscriptions peuvent inclure des champs avant un corps optionnel. Chaque champ se compose de deux données, une balise et une valeur.
Actuellement, le seul champ défini est content-type, avec une balise 1, dont la valeur est le type MIME du corps.
Le début du corps et la fin des champs sont indiqués par une poussée de données vide.
Les balises non reconnues sont interprétées différemment selon qu'elles sont paires ou impaires, conformément à la règle "it's okay to be odd" utilisée par le Lightning Network.
Les balises paires sont utilisées pour les champs qui peuvent affecter la création, l'attribution initiale ou le transfert d'une inscription. Ainsi, les inscriptions dont les champs pairs ne sont pas reconnus doivent être affichées comme "non liées", c'est-à-dire sans localisation.
Les balises impaires sont utilisées pour les champs qui n'affectent pas la création, l'attribution initiale ou le transfert, tels que les métadonnées supplémentaires, et peuvent donc être ignorées en toute sécurité.
ID d'inscription
Les inscriptions sont contenues dans les entrées d'une transaction de révélation. Afin de les identifier de manière unique, elles se voient attribuer un identifiant de la forme suivante :
521f8eccffa4c41a3a7728dd012ea5a4a02feed81f41159231251ecf1e5c79dai0
La partie précédant le i est l'identifiant de la transaction (txid) de la transaction de révélation. Le nombre après le i définit l'index (commençant à 0) des nouvelles inscriptions effectuées dans la transaction de révélation.
Les inscriptions peuvent être situées dans des entrées différentes, dans la même entrée ou dans une combinaison des deux. Dans tous les cas, l'ordre est clair, puisqu'un analyseur syntaxique parcourrait les entrées consécutivement et rechercherait toutes les enveloppes d'inscription.
| Input | Nombres | Indices |
| 0 | 2 | i0, i1 |
| 1 | 1 | i2 |
| 2 | 3 | i3, i4, i5 |
| 3 | 0 | |
| 4 | 1 | i6 |
Environnement sandbox
Les inscriptions HTML et SVG sont placées dans un environnement sécurisé afin d'éviter les références à des contenus hors chaîne, ce qui permet aux inscriptions de rester immuables et autonomes.
Pour ce faire, les inscriptions HTML et SVG sont chargées dans des iframes avec l'attribut sandbox, et le contenu de l'inscription est servi avec des en-têtes Content-Security-Policy (Politique de sécurité du contenu).
3.1 Metadata
Les inscriptions peuvent inclure des métadonnées CBOR, stockées sous forme de push de données dans des champs avec la balise 5. Étant donné que les push de données sont limités à 520 bytes, les métadonnées de plus de 520 bytes doivent être divisées en plusieurs champs de balise 5, qui seront ensuite liés avant le décodage.
Les métadonnées sont lisibles par l'homme et toutes les métadonnées seront affichées à l'utilisateur avec l'inscription. Ceux qui créent des inscriptions sont encouragés à réfléchir à la manière dont les métadonnées seront affichées et à les rendre concises et attrayantes.
Les métadonnées sont rendues au format HTML pour être affichées comme suit :
- null, true, false, nombres, floats, strings sont rendus sous forme de texte brut.
- Les chaînes de bytes sont rendues en hexadécimal en majuscules.
- Les tableaux sont rendus sous forme de balises <ul>, chaque élément étant enveloppé dans des balises <li>.
- Le mapping est rendu sous forme de balises <dl>, avec chaque clé enveloppée dans des balises <dt> et chaque valeur enveloppée dans des balises <dd>.
- Les balises sont rendues sous la forme de la balise, entourée d'une balise <sup> suivie de la valeur.
CBOR est une spécification complexe avec de nombreux types de données différents et plusieurs façons de représenter les mêmes données. Les types de données exotiques, tels que les balises, les floats et les bignums, ainsi que les encodages tels que les valeurs indéfinies, peuvent ne pas s'afficher correctement, voire pas du tout. Les contributions pour remédier à cela sont les bienvenues.
Exemple
Puisque CBOR ne peut pas être lu par l'homme, ces exemples le représentent sous forme de JSON. Gardez à l'esprit que c'est seulement pour ces exemples, et le metadata JSON ne sera pas montré correctement.
Les métadonnées {"foo":"bar","baz":[null,true,false,0]} seraient incluses dans une inscription comme ceci:
OP_FALSE
OP_IF
...
OP_PUSH 0x05 OP_PUSH '{"foo":"bar","baz":[null,true,false,0]}'
...
OP_ENDIF
Et rendues comme suit:
<dl>
...
<dt>metadata</dt>
<dd>
<dl>
<dt>foo</dt>
<dd>bar</dd>
<dt>baz</dt>
<dd>
<ul>
<li>null</li>
<li>true</li>
<li>false</li>
<li>0</li>
</ul>
</dd>
</dl>
</dd>
...
</dl>
Les métadonnées de plus de 520bytes doivent être séparées en plusieurs champs:
OP_FALSE
OP_IF
...
OP_PUSH 0x05 OP_PUSH '{"very":"long","metadata":'
OP_PUSH 0x05 OP_PUSH '"is","finally":"done"}'
...
OP_ENDIF
Qui seraient ensuite liés: {"very":"long","metadata":"is","finally":"done"}.
3.2 Provenance
Le propriétaire d'une inscription peut créer des inscriptions enfants, en établissant en toute confiance la provenance de ces inscriptions enfants sur la chaîne comme ayant été créées par le propriétaire de l'inscription mère. Cela peut être utilisé pour les collections, les enfants d'une inscription mère étant membres de la même collection.
Les inscriptions enfants peuvent elles-mêmes avoir des enfants, ce qui permet d'établir des hiérarchies complexes. Par exemple, un artiste peut créer une inscription le représentant, avec des sous-inscriptions représentant les collections qu'il crée, les enfants de ces sous-inscriptions étant des éléments de ces collections.
Spécification
Créer une inscription enfant C avec une inscription parent P :
- Créer une transaction d'inscription T comme d'habitude pour C.
- Inscrire le parent P dans l'une des entrées de T.
- Inclure la balise 3, c'est-à-dire OP_PUSH 3, dans C, avec la valeur de l'identifiant binaire sérialisé de l'inscription P, sérialisé comme le TXID de 32 bytes, suivi de l'INDEX petit-endian de quatre bytes, avec les zéros de fin omis.
NB Les bytes de l'ID d'une transaction bitcoin sont inversés dans leur représentation textuelle, de sorte que l'ID sérialisé de la transaction sera dans l'ordre inverse.
Exemple
Exemple d'une inscription enfant de 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1fi0:
Exemple de codage de l'identifiant de l'inscription 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1fi255:
OP_FALSE
OP_IF
…
OP_PUSH 3
OP_PUSH 0x1f1e1d1c1b1a191817161514131211100f0e0d0c0b0a09080706050403020100ff
…
OP_ENDIF
Et de l'inscription ID 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1fi256:
OP_FALSE
OP_IF
…
OP_PUSH 3
OP_PUSH 0x1f1e1d1c1b1a191817161514131211100f0e0d0c0b0a090807060504030201000001
…
OP_ENDIF
Remarques
La balise 3 est utilisée parce que c'est la première balise impaire disponible. Les balises impaires non reconnues ne rendent pas une inscription non reliée, de sorte que les inscriptions enfants seraient reconnues et suivies par les anciennes versions d'ord.
Une collection peut être fermée en brûlant l'inscription parente de la collection, ce qui garantit que plus aucun élément de la collection ne peut être délivré.
3.3 Récursion
Une exception importante au sandboxing est la récursion : l'accès à l'extrémité /content de ord est autorisé, ce qui permet aux inscriptions d'accéder au contenu d'autres inscriptions en demandant /content/<INSCRIPTION_ID>.
Il existe un certain nombre de cas d'utilisation intéressants :
- Remixer le contenu d'inscriptions existantes.
- Publication d'extraits de code, d'images, de fichiers audio ou de feuilles de style en tant que ressources publiques partagées.
- Collections d'art génératif où un algorithme est inscrit en tant que JavaScript, et instancié à partir de plusieurs inscriptions avec des semences uniques.
- Collections d'images de profil génératives où les accessoires et les attributs sont inscrits en tant qu'images individuelles ou dans un atlas de textures partagé, puis combinés, à la manière d'un collage, en combinaisons uniques dans plusieurs inscriptions.
Les inscriptions peuvent également accéder à d'autres points de terminaison :
- /blockheight : dernière hauteur de bloc.
- /blockhash : dernier hachage du bloc.
- /blockhash/<HEIGHT> : hachage du bloc à la hauteur donnée.
- /blocktime : horodatage UNIX du dernier bloc.
Commentaires
0 commentaire
Vous devez vous connecter pour laisser un commentaire.