Ang inscriptions ay sats na naglalaman ng arbitraryong content, na lumilikha ng bitcoin-native digital artifact, na mas karaniwang kilala bilang NFTs. Ang mga inskripsiyon ay hindi nangangailangan ng sidechain o hiwalay na token.
Ang mga naka-inscribe na sat na ito ay maaaring ilipat gamit ang mga transaksyon sa bitcoin, ipadala sa mga bitcoin address, at gamitin sa mga bitcoin UTXO. Ang mga transaksyon, address, at UTXO na ito ay normal na mga transaksyon sa bitcoin, address, at UTXOS sa lahat ng aspeto, maliban nalang para makapagpadala ng mga indibidwal na sats, dapat kontrolin ng transaksyon ang pagkakasunud-sunod at halaga ng mga input at output ayon sa ordinal theory.
Ang modelo ng inscription content ay sa web. Ang isang inskripsiyon ay binubuo ng isang uri ng nilalaman, na kilala rin bilang MIME type, at ang nilalaman mismo ay isang byte string. Ito ay nagbibigay-daan sa nilalaman ng inskripsiyon na maibalik mula sa isang web server, at para sa paglikha ng mga HTML inscriptions na gumagamit at nagbubuo ng nilalaman ng iba pang mga inskripsiyon.
Ang nilalaman ng inskripsiyon ay on-chain, na naka-imbak sa taproot script-path spend scripts. Ang mga script ng Taproot ay may limitasyon sa kanilang nilalaman, at bukod pa rito ay tumatanggap ng witness discount, na ginagawang matipid ang pag-iimbak ang nilalaman ng isang inskripsiyon.
Dahil ang spend ng taproot script ay maaari lamang gawin mula sa mga kasalukuyang taproot output, ang mga inskripsiyon ay ginawa gamit ang isang two-phase commit/reveal procedure. Una, sa commit transaction, isang taproot output na nag-committ sa isang script na naglalaman ng inskripsyon ay nabuo. Pangalawa, sa reveal ng transaksyon, ang output na nilikha ng commit na transaksyon ay ginamit sa pagbayad, na mag-rereveal ng inscription content sa on-chain.
Ang nilalaman ng inskripsiyon ay naka-serialize gamit ang data pushes sa loob ng mga hindi naisagawang kondisyon, na tinatawag na "envelopes." Ang envelopes ay binubuo ng isang `OP_FALSE` `OP_IF` … `OP_ENDIF` na nag-wawrap sa kahit anong numero ng data pushes. Dahil ang “envelopes” ay epektibong no-ops, hindi nito binabago ang semantika ng script kung saan kasama ang mga ito, at maaaring isama sa anumang iba pang locking script.
Isang text inscription na naglalaman ng string na "Hello, world!" ay serialized tulad ng sumusunod:
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
Una ang string na `ord` ay “pushed”, upang i-dismbiguate ang mga inskripsiyon mula sa iba pang gamit ng “envelopes”.
Ang `OP_PUSH 1` ay nagpapahiwatig na ang susunod na push ay naglalaman ng content type, at `OP_PUSH 0` naman ay nagpapahiwatig na ang mga kasunod na data ay naglalaman ng content mismo. Dapat gumamit ng maraming push data para sa isang malalaking inskripsiyon, dahil ito sa limitasyon ng taproot, na kung saan hindi maaring lumagpas sa 520 bytes ang bawat isang data push.
Ang nilalaman ng inskripsyon ay nakapaloob sa input ng isang naka-reveal na transaksyon sa Bitcoin, at ang inskripsyon ay nagawa sa unang sat ng input nito. Ang sat na ito ay maaaring masubaybayan gamit ang pamilyar na mga panuntunan ng ordinal theory, na nagreresulta sa ito na ilipat, bilhin, ibenta, mawala sa mga fees, at ma-recover.
Content
Ang data model ng mga inskripsiyon ay isang HTTP response, na nagbibigay-daan sa nilalaman ng inskripsiyon na maipakita gamit ang web server at nang web browser.
Fields
Ang inskripsiyon ay maaring magkaroon ng fields bago ang optional body. Ang bawat field ay binubuo ng dalawang data pushes, isang tag at isang value.
Sa itaas na halimbawa, ang tanging tinukoy na field ay `content-type`, na may tag na 1, na ang halaga ay ang uri ng MIME ng body (text/plain;charset=utf-8).
Ang simula ng body at dulo ng mga fields ay mayroong isang walang laman na data push.
Ang mga hindi unkown tag ay sinusuri depende sa kung even o odd ang mga ito, na sumusunod sa panuntunang "it's okay to be odd" na ginagamit ng Lightning Network.
Ang mga tag na ginagamit para sa fields ay maaaring makaapekto sa pag-create, paunang pagtatalaga, o paglipat ng isang inskripsiyon. Kaya, ang mga inskripsiyon na unknown at kahit na ang fields ay dapat na ipakita bilang "unbound", iyon ay, walang lokasyon.
Odd tags ay hindi nakakaapekto sa paggawa, paunang pagtatalaga, o paglilipat, gaya ng karagdagang metadata, at sa gayon ay ligtas na gamitin.
Inscriptions
Ang nilalaman ng inskripsyon ay nakapaloob sa input ng isang naka-reveal na transaksyon. Upang natatanging makilala ang mga ito, binibigyan sila ng ID, tulad ng:
`521f8eccffa4c41a3a7728dd012ea5a4a02feed81f41159231251ecf1e5c79dai0`
Ang bahagi sa harap na `i` ay ang transaction ID (txid) ng reveal na transaksyon. Ang numero pagkatapos ng `i` ay tumutukoy sa index (nagsisimula sa 0) ng mga bagong inskripsiyon ng transaksyon.
Maaaring matatagpuan ang mga inskripsiyon sa iba't ibang input, sa loob ng parehong input o kumbinasyon ng pareho. Sa anumang kaso ang order ay madaling makita, dahil ang parser nage-scan sa mga input nang sunud-sunod at hahanapin ang lahat ng inskripsiyon na may `envelopes`.
Input | Inscription Count | Indices |
0 | 2 | i0, i1 |
1 | 1 | i2 |
2 | 3 | i3, i4, i5 |
3 | 0 | |
4 | 1 | i6 |
Sandboxing
Ang mga inskripsiyon na gaya ng HTML at SVG ay nasa-sandbox upang maiwasan ang ma-reference sa off-chain content, sa gayo'y pinapanatili ang mga inskripsiyon na hindi nababago at self-contained.
Nagagawa ito sa pamamagitan ng pag-load sa mga HTML at SVG na inskripsiyon sa loob `iframes` na may `sandbox` na katangian, pati na rin ang pag-serve ng nilalaman ng inskripsiyon na may `Content-Security-Policy` sa header.
3.1 Provenance
Ang may-ari ng isang inscription ay maaaring lumikha ng mga child inscription, na sinisiguro na ng pinagmulan ng mga child inscription na nasa on-chain na kabilang sa nilikha ng may-ari ng isang parent inscription. Magagamit ito para sa mga koleksyon, kung saan ang mga child inscription ng parent inscription ay mga miyembro ng parehong koleksyon.
Kahit ang mga child inscription ay maaaring magkaroon ng mga child inscriptions, na nagbibigay-daan para magkaroon ng hierarchy. Halimbawa, maaring gumawa ang artist ng parent inscription na maraming child inscription na kung saan may mga sub inscription pa ang mga ito.
Pagtutukoy
Upang lumikha ng child inscription `C` na may parent inscription `P`:
- Gumawa ng inscribe transaction `T` gaya ng dati para sa C.
- I-spend ang parent inscription `P` sa isa sa mga input ng T.
- Isama ang tag `3`, ibig sabihin `OP_PUSH 3`, sa C, na may value ng serialized binary inscription ID ng `P`, na naka-serialize bilang 32-byte TXID, na sinusundan ng apat na byte na little-endian `INDEX`, kung saan ang mga trailing zeroes ay hindi kasama.
`NB` Ang mga byte ng isang bitcoin transaction ID ay nababaligtad sa kanilang text representation, kaya ang serialized transaction ID ay nasa kabaligtaran ang pagkakasunodsunod.
Halimbawa
Isang halimbawa ng child inscription:
`000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1fi0`:
OP_FALSE
OP_IF
OP_PUSH "ord"
OP_PUSH 1
OP_PUSH "text/plain;charset=utf-8"
OP_PUSH 3
OP_PUSH 0x1f1e1d1c1b1a191817161514131211100f0e0d0c0b0a09080706050403020100
OP_PUSH 0
OP_PUSH "Hello, world!"
OP_ENDIF
Tandaan na ang halaga ng tag `3` ay binary, hindi hex, at para makilala ang child inscription bilang isang child, `000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1fi0` dapat na gastusin bilang isa sa mga input ng inscription transaction.
Halimbawang pag-encode ng inscription ID `000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1fi255`:
OP_FALSE
OP_IF
…
OP_PUSH 3
OP_PUSH 0x1f1e1d1c1b1a191817161514131211100f0e0d0c0b0a09080706050403020100ff
…
OP_ENDIF
At ng inskripsiyong ID `000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1fi256`:
OP_FALSE
OP_IF
…
OP_PUSH 3
OP_PUSH 0x1f1e1d1c1b1a191817161514131211100f0e0d0c0b0a090807060504030201000001
…
OP_ENDIF
Tandaan
`3` Ginagamit ang tag dahil ito ang unang available na odd tag. Ang mga hindi kilalang odd tag ay hindi gumagawa ng isang inskripsiyon na unbound, kaya ang mga child inscription ay makikilala at masusubaybayan ng mga lumang bersyon ng ord.
Maaaring i-close ang isang koleksyon sa pamamagitan ng pag-burn sa parent isncription ng koleksyon, na ginagarantiyahan na wala nang mga item sa koleksyon ang maaaring maibigay.
3.2 Recursion
Ang isang eksepsyon sa sandboxing ay ang recursion: pinahihintulutan ang pag-access sa endpoint ng `ord’s`, na nagdudulot sa mga inskripsiyon na ma-access ang nilalaman ng iba pang mga inskripsiyon sa pamamagitan ng paggamit ng `/content/content/<INSCRIPTION_ID>`.
Ito ay nagdudulot ng magagandang use-cases:
- Paggamit sa mga existing na inskripsyon.
- Pag-publish ng mga snippet ng code, mga larawan, audio, o mga stylesheet bilang pampublikong resources.
- Mga generative na koleksyon kung saan ang isang algorithm ay nakalagay bilang JavaScript, na nag awtomatiko sa pag-create ng maraming inskripsyon na may kanya-kanyang katangian.
- Mga generative na koleksyon ng profile picture kung saan ang mga accessory at attribute ay naka-inscribe bilang mga indibidwal na larawan, o sa isang shared texture atlas, at pagkatapos ay pinagsama, parang collage, na may kanya kanyang combinasyon.
Ang ilan pang mga endpoint na maaaring ma-access ng mga inskripsiyon ay ang mga sumusunod:
- `/blockheight`: pinakabagong block height.
- `/blockhash`: pinakabagong block hash.
- `/blockhash/<HEIGHT>`: block hash sa ibinigay na block height.
- `/blocktime`: UNIX time stamp ng pinakabagong block.
Mga Komento
0 komento
Mangyaring mag-sign in upang mag-iwan ng komento.