NFT jako praktický nástroj pro správu dat
Když se dnes někde řekne NFT, tak si lidé představují jen prodej digitálního umění. Nicméně není tomu tak. Jedná se o architektonický softwarový patern, který říká, jak se dají využít záznamy na blockchainu pro správu unikátních dat a jak zajistit jejich trasovatelnost, přenositelnost, ověřitelnost, apod. Tuto architekturu je možné využít v celém spektru případů. Jen namátkou lze zmínit:
- Profily
- Obrázky
- Hudba
- Články a publikace
- Aplikace
- Zprávy
- Objednávky, faktury, potvrzení
- Události a lístky
- Data z procesu výroby produktu
- a mnoho dalších
Zde je náhled celé galerie různých NFT ve VENFT App
Příklad NFT Aplikace:
Příklad NFT Videa:
A mnoho dalších. Nicméně zpět k vysvětlení NFT...
Obecně lze říci, že NFT je forma digitálního dvojčete. Konkrétní informace o obsahu jsou uložené v uživatelských datech v NFT protokolu (pokud by někdo nechápal, doporučuji přečíst tento článek). S každou transakcí je možné tato data i updatovat. Můžu například poslat NFT sám sobě, abych jen upravil nějaké informace v jeho obsahu. Tím se v podstatě dělá "update" digitálního dvojčete v čase. Pro zpětnou analýu pak můžu trackovat dané NFT zpět po jeho transakcích a tím získat záznam celé historie daného digitálního dvojčete. V tomto vnímám velkou výhodu Utxo protokolu (kdo neví co je Utxo protokol, tak si to přečtěte prosím zde). U Utxo protokolu mám pro každé NFT samostatný výstup. Což je výhoda, protože pak s danými NFT opravdu můžu zacházet jak s nějakými "kartičkami" které mám v kapse. Tento způsob unifikace dat napříč obory byl (co já vím) prvně prezentován v rámci počítače Macintosh jako aplikace HyperCard. Zde je k dispozici video, které opravdu stojí za to shlédnout. Je to neuvěřitelně nadčasové. Jen jim tehdy chyběli ty správné technologie, které máme již dnes k dispozici. VEFramework se snaží určitým stylem splnit sen tehdejších vývojářů Macintosh :)
Každé NFT má nějakou definovanou strukturu dat. V základu se většinou jedná o JSON, aby bylo možné jednoduše data serializovat do tříd a zpět. Může se však jednat i o slovník, apod. Je to na tom kdo daný formát definuje. Důležité je zvážit čitelnost formátu vs jeho úspornost. Kupříkladu VEFramework tuto část ještě nemá optimalizovanou, nicméně toto jsou velmi drobné úpravy. Nyní byl fokus spíše na čitelnost bez nutnosti překladu parametrů do čitelné podoby. Pro příklad v praxi u blockchainu je lepší neukládat celé slovo u parametru "Type" ale raději jej mít označený jen znakem "T", apod. Pokud bude na blockchainu hromada záznamů, tak se každý byte počítá. U Utxo protokolu je možné využít tzv Issuance transakce, kdy se vydávají tokeny a do nich lze definovat specifický protokol, který pak určuje propojení mezi značkou parametru a jejím popisem. Tím lze jednoduše integrovat popis protokolu do blockchainu a mít jej tedy vždy k dispozici v jasné definované podobě. Problém je zde však jeho nemožnost updatu. Proto se snažím spíše tyto věci řešit prvně v úrovni druhé vrstvy, protože tam je možnost protokol upravovat.
Ve VEFramework je nyní protokol definován ve dvou částech, jednak obecné vlastnosti, které se překládají z objektu v CommonNFT.cs třídě a jsou pro všechny NFT stejné. Základní vlastnosti a funkce všech NFT definuje interface INFT.cs. Druhá část protokolu je specifická a souvisí již s konkrétním typem NFT a její zbylé vlastnosti se tedy definují tam. Příkladem je třeba XrayImageNFT.cs, kde dochází ještě k serializaci specifických proměnných, které jsou jen v rámci tohoto typu NFT a ostatní je nemají. Stejně tak při parsování těchto vlastností se využívá funkce ParseSpecific, kterou mají všechna NFT (je v INFT interfacu) a v rámci implementace třídy ji lze přepsat a dodefinovat si parsování specifických proměnných. Příklad takových metadat je třeba zde:
{
"NFT": true,
"Type": "NFT XrayImage",
"Name": "ProductFinished_VolvoZamek-P-OP00a01@01-05-2022T20_16_49_131",
"Author": "Tomas Svoboda",
"Image": "https://ve-framework.com/ipfs/QmaqyetGdECvnC165nDAJFdztDAskuxUnNaQ5A3Dr3t8Nd",
"DataItems": [
{
"Type": 0,
"Hash": "QmaqyetGdECvnC165nDAJFdztDAskuxUnNaQ5A3Dr3t8Nd",
"Storage": 0,
"TagsList": [],
"IsMain": true
},
{
"Type": 7,
"Hash": "QmdFq2sVu2Txvd86gSa1Mrj15XZYZ7tNPcYGnWyboVaZF3",
"Storage": 0,
"TagsList": [],
"IsMain": false
},
{
"Type": 5,
"Hash": "QmdBvk7899Cj1WdSZQgYwRZgLXqhZtWnTvnXmgvvEo8zx2",
"Storage": 0,
"TagsList": [],
"IsMain": false
}
],
"Tags": "Production P-UID-VolvoZamek-P-OP00a01 PLUID-113995084 OID-ID654321 OP-123 TP1_-_Place_part",
"Text": "komponentě pro náš produkt, který má problém s porozitou. Jedná se o kus: ProductFinished_VolvoZamek-P@02-05-2022T14_35_01_284. Tento produkt asi neprošel správně procesem lití. Jedná se o kovovou komponentu, která je litá, takže tam můžou vznikat bublinky (voidy). Je to vidět na přiložených snímcích v tomto NFT. Bylo by vhodné přidat Mermaid sekvenční graf pro toto: \"je potřeba aby šéf směny odeslal 100 posledních kusů od výše uvedeného kusu k analýze na CT pracoviště. CT pracoviště provede snímek každého kusu a vyhodnotí procentuální množství kusů. Manažer kvality následně připraví report pro vedení společnosti, které po obdržení podkladů rozhodne o investici do pořízení dodatečné kontroly.",
"SourceTxId": "58aa1904992a32a84bb37b967bf06b947cabf567d267f480e7fd0c5471e23167",
"ExpPar": {
"Voltage": 100.0,
"Current": 0.24,
"Filters": [],
"ExposureTime": 61.0
},
"IsOrig": true,
"SourceUtxo": "1f09b41a86d1fb762873ce13ff4f3379e9b258167eb2bc3b1cc49dfa13b88d7f",
"NFT FirstTx": true
}Jedná se o data k RTG snímků z výroby, který ještě nese v sobě tzv. DataItems, které odkazují na přílohy například na IPFS, nebo jiném uložišti. V tomto NFT například je k dispozici obrázek, pak data z výrobního procesu (zde ze simulátoru linky v PLFramework) a také Mermaid diagram, který definuje nějaké další kroky v procesu kontroly kvality.
Při prohlížení v BaseDataPlace app (vychází z VENFT App šablony) vypadá NFT následovně:
Jak již bylo zmíněno výše, NFT může v sobě nést odkaz na externí data. !!!Zde prosím velké zbystření!!! Blockchain většinou neukládá v sobě velká data jako třeba obrázek, ty jsou uloženy často někde jinde. Proto když si někdo třeba koupil nějaké to "umělecké dílo jako NFT", tak si v podstatě koupil certifikát o tom, že nějaký obrázek, který je někde uložený je jeho. Vlastník je však pak zodpovědný za to, aby byl obrázek k dispozici a šel zobrazit. Pokud by NFT záznam obsahoval odkaz na nějaké konkrétní uložiště, tak to může být do budoucna problém, protože daný server už nemusí být k dispozici. Proto je lepší používat jen "hashe" souborů kterými jsou například identifikovány soubory na IPFS. Pokud tedy chci mít jistotu, že soubor bude vždy dostupný, tak si jej můžu připnout na svůj IPFS node a tím zajistit jeho dostupnost. Toto se samozřejmě netýká jen obrázků, ale jakýchkoliv větších dat. Ve výše uvedeném příkladu NFT RTG snímku jsou to celkem tři soubory, na kteér se NFT odkazuje (obrázek, JSON a Mermaid).
V rámci VEFramework postupně vzniká StorageDriver, který řeší připojení k IPFS, File systému, web serveru, apod. Nyní je zatím jen ve fázi "náčrtu" a proto obhsahuje jen základní strukturu a hlavně příkazy pro IPFS, které je velmi dobrým uložištěm pro účely správy dat formou NFT. Inicializaci Storage driveru je možné vidět například zde. Výhodou je, že můžu mít připojených více IPFS driverů. Jeden může odkazovat na sdílený node a jeden na lokální node. To pak umožňuje se soubory pracovat i v podstatě v offline módu. Lze automatizovat i například to, že pokud mě přijde nějaké NFT, tak se automaticky nabídne možnost připnout k lokálnímu IPFS nodu, apod.
Vytvoření NFT není nic složitého. U Utxo blockchainu to funguje následovně:
- Najde se Utxo, které obsahuje větší množství tokenů, například 100 VENFT tokenů
- Poté se vytvoří data pro NFT (tedy naplní se nějaká konkrétní implenentace NFT konkrétními daty)
- Vytvoří se nová transakce, kde vznikne nový výstup ke kterému se přiřadí jen 1 VENFT token a zbylých 99 VENFT tokenů se pošle jako samostatný výstup zpět tomu kdo jej vytváří. Pokud má zůstat na stejné adrese, tak bude také posláno zpět tomu kdo jej vytváří. Tedy provede transakci sám vůči sobě.
Pokud bychom to zobrazili na flow Utxos dané adresy, tak to bude vypadat takto:
Zde je vidět, že Alice, vzala dvě Utxa (1 a 2), kde Utxo 2 je tokenové Utxo obsahující 100 VENFT. Při transakci se jeden token oddělí (jak kdybych vzal jeden papírek z takového toho bloku barevných lepících papírků nebo šeků => VENFT symbol by byl jak vodoznak na nich) a ten se pošle Bobovi. Při transakci také vzniknou dvě nová Utxa která jdou jako "change" (vrácení "drobných" zpět) Alici. Po transakci má zůstatek 99 VENFT tokenů a 0.9998 NEBL protože ji stál poplatek 0.0002 NEBL (0.0001 poplatek za transakci a 0.0001 je potřeba pro vytvoření nového výstupu, který jde Bobovi).
Tímto je NFT vytvořeno, tzv. "Vymintováno" (mintování proces tvorby NFT). S Utxo protokolem je to opravdu takto jednoduché. Tento princip je nezávislý na konkrétním typu NFT. Nejduležitějším je si zapamatovat, že NFT vznikne tím, že se s nějakého jednotného většího množství tokenů oddělí jeden samostatný v samostatném Utxu. Díky tomu totiž vždy můžu jednoduše automaticky dojít v blockchainu k momentu, kdy byl vytvořen. I kdyby byl pak stokrát různě přeposlán mezi adresami. Přeposlání NFT ukazuje další obrázek.
Transakce je velmi jednoduchá. Ve chvíli kdy je předešlá transakce (mintování) již potvrzené (většinou je potřeba mít více jak 3 potvrzení), tak může Bob dané Utxo použít jako vstup pro novou transakci a poslat jej zpět Alici s doplněnou novou uživatelskou zprávou. Aby mohl transakci provést, musí zase vložit i nějaké Neblio pro zaplacení poplatku v síti.
Pokud taková transakce proběhne, tak Alice bude mít nyní 3 Utxa a Bobovi zůstane jen jedno. Transakce můžou být různého druhu. Díky tomu, že se pracuje se samostatnými Vstupy/výstupy, tak je možné mít ve vstupu vícero NFT, nebo vytvářet jejich kopii, apod.
Díky tomu, že jsou záznamy provázány na blockchainu, lze velmi jednoduše zpětně dohledat všechny transakce daného NFT a také všechna uživatelská data v historickcých krocích. Pro výše uvedený příklad by trasování historie vypadalo následovně:
Podobný princip jako je mintování lze uplatnit i pro zničení, či lépe recyklaci NFT. Pokud už daný záznam nepotřebuji, tak jej můžu v rámci nové transakce sdružit s Utxem s nějakým větším počtem tokenů a tím si v podstatě resetovat jeho možnost trasování. Historické záznamy sice na blockchainu zůstanou, ale už tento 1 token nebude jako samostatné Utxo.
