Blockchain a decentralizované databázové systémy

Každý blockchain je databází, avšak ne každá databáze je blockchainem. V případě blockchainu, jak název napovídá, jde o ukládání dat po blocích. V případě relačních databází k ukládání dat do struktur definovaných databázovým systémem. Oba typy databází lze provozovat jak centralizovaně, tak decentralizovaně.

Tento souhrn shrnuje decentralizovaná uložiště dat, a to jak na bázi blockchainu tak i klasických relačních databází. Principem decentralizovaných databází je nabízení robustních a stabilních systémů pro ukládání dat bez dozoru a vlivu centrální strany. Jestliže tedy hledáte způsoby, jak ukládat decentralizovaně v čase neměnná data, tento souhrn je určen právě pro Vás.

Osnova článku - přehled decentralizovaným ukládáním

Ukládání dat do blockchainu

Blockchain je typem databáze, do které lze pouze vkládat nové záznamy, a to prostřednictvím zařazení transakce do aktuálního bloku vkládaného na konec blockchainu. Blockchainová databáze je tímto krokem rozšířena o poslední události, čímž dochází ke změně stavů při assetech obsažených v dané transakci (změna držených jednotek měny, majitele tokenů apod.).

O zařazení nového bloku do blockchainu se stará validátor, který dle konkrétního mechanismu konsenzu blockchainu může být označován i přidruženými názvy, jako je například Miner v případě Proof of Work sítí. Vyjma tvorby a vkládání bloků do blockchainu, validátor obvykle buď přímo je, nebo je propojen s uzlem sítě. Uzel drží data blockchainu a skrze APIs umožňuje k nim přístup a interakci s daným blockchainem.

Jak software pro uzly, tak validátory (dále jen klienti) jsou zpravidla vyvíjeni paralelně a nezávisle více týmy blockchainových vývojářů, s využitím různých programovacích jazyků a přístupů. Díky tomu existuje paralelně několik nezávislých softwarových klientů, jejichž datový výstup (output) je z principu fungování blockchainu totožný. Jestliže jsou tito klienti rozdistribuování mezi provozovateli uzlů a validátorů rovnoměrně, daný blockchain se vyznačuje robustností a stabilitou - v případě projevení se chyby v některém z klientů není narušena funkčnost sítě - síť je jednoduše spravována zbylými funkčními klienty bez oné chyby, kteří jsou v převaze.

S množstvím rozdílných klientů, a tedy i přístupů, přichází i rozdílné způsoby správy ukládaných dat při blockchainových uzlech. Ukládaná klíčová data jsou napříč klienty shodná, nicméně struktura jejich uložení může být rozdílná. Co je však shodné, je ukládání dat po blocích. Samotná architektura ukládaných dat ovlivňuje nároky na velikost uložiště, počty I/O, možnou funkcionalitu i nezbytný výkon pro správu. Efektivní optimalizovaná velikost souborů hraje ve světě blockchainu prim, jelikož v rámci globální distribuce se každý přenesený a ukládaný bajt počítá.

V závislosti od konkrétního blockchainu tedy může být zbytné zjišťovat, jak jsou v něm konkrétní data uložena. Může se to totiž lišit od typu softwarového klienta. Spíše bychom se měli zaměřit na cenu uložení dat, kdy daná cena je kvantifikována cenou zápisu těchto dat do blockchainu. Zapsaná data, není-li definováno jinak, nemají expiraci, jsou tedy do blockchainu zapsána napořád. Čtení veřejných dat je skrze API rozhraní zdarma.

Je zřejmé, že standardní blockchainy profilované na transakce účetních jednotek a tokenů nejsou na ukládání velkých dat vhodné. Samotné transakce zde jsou schopny nést jednotky kilobajtů informace. Ukládány a drženy jsou na všech uzlech v síti. Chtěli-li bychom takto do blockchainu uložit například 1GB dat, museli bychom provést velké množství transakcí, z nichž každá bude ukládat v rámci právě těženého bloku pouze oněch pár kilobajtů z našeho gigabajtu. Tento typ uložiště, kdy data jsou uložena přímo na blockchainu, nazýváme on-chain.

Ukládání jakýchkoliv dat, vyjma dat jednoduchých transakcí, je tedy z pohledu ceny na veřejných distribuovaných účetních knihách, typu Bitcoin, Ethereum a další, nerealistické. Z pohledu běžného obsahu internetového prostředí - smluv, recenzí, mediálních souborů apod. - je třeba se dívat na decentralizovaná řešení, která jsou na tento typ velkých dat uzpůsobena. Tento typ uložení, kdy data jsou uložena mimo blockchain, nazýváme off-chain.

Účelem on-chain ukládání je dosáhnout maximální bezpečnost, transparentnost a dostupnosti ukládaných dat v čase.

Nevýhodou on-chain uložiště je limitované vyhledávání - a to jak rychlostí tak filtračními dotazy.

Ukládání dat do decentralizovaných relačních databází

Ukládání dat prostřednictvím decentralizovaných relačních databází spadá mezi tzv. Off-chain (tedy mimo blockchain) typ ukládání. Účelem off-chain ukládání je nabídnout soubory libovolných velikostí s co nejnižšími náklady při zachování dostatečné bezpečnosti, robustnosti a dostupnosti.

Pojem decentralizovaný v tomto případě znamená využití řešení, kdy jsou data na úrovni protokolu zašifrována a následně rozdistribuovat ve veřejné síti. Nejedná se o využívání clusterů, respektive automatické replikace dat v rámci centralizovaných serverů rozmístěných v různých geo lokacích.

Řešení ukládání dat v relačních databázích

Hašování

Hašování - nákladově efektivní způsob ukládání dat, kdy je v blockchainu uložena pouze hash hodnota daných dat.

Samotný hash je vygenerovaný řetězec, který je vypočítán pomocí našich vstupních dat, uložených v systému souborů. Se stejným vstupem bude výstupní hash vždy stejný.

Kontrola nezměnitelnosti pak spočívá ve vygenerování si hashe k uloženého souboru dat v relační databázi nebo systému souborů a jeho porovnání se zápisem v blockchainu.

Hash dat je poměrně minimální z hlediska datové velikosti, náklady jsou tedy nízké.

Použitím hashovacího mechanismu můžeme využít výhod tradičních mechanismů ukládání (jako je použití dotazů), a přitom stále získávat důkazy o manipulaci s blockchainem.

Cassandra

Apache Cassandra je open-source distribuovaná databáze NoSQL, která poskytuje lineární škálovatelnost a vysokou dostupnost bez kompromisů ve výkonu.

Psaná v jazyce Java, Cassandra dokáže zpracovat velké množství dat na mnoha komoditních serverech a poskytuje vysokou dostupnost bez jediného bodu selhání. Využívá konsensuální mechanismus Paxos.

  • Distribuce

    V Cassandře není žádný centrální uzel ani jediný kontrolní bod. Řádky a oddíly jsou rozmístěny po celém clusteru.

  • Tolerantní k chybám

    Cassandra je tolerantní k chybám, protože je distribuována a nemá jedinečný kontrolní bod. Každý uzel v clusteru má kopii databáze.

  • Jazyk dotazu

    Cassandra nepoužívá SQL; místo toho má Cassandra Query Language (CQL).

Kdy volit centralizovanou relační databázi, kdy decentralizovanou, a kdy blockchain?

Dle kterých parametrů se rozmýšlet mezi použitím standardní databáze, decentralizované databáze a blockchainem? V principu je to velmi snadné - začnete s běžnou databází. Stačí pro váš use case? → Používáte ji. Nestačí? Přejdete na decentralizovanou. Opět nestačí? Zkusíte blockchain.

Zde je seznam dalších parametrů, které při výběru databázového řešení hrají roli:

Ukládání dat v jednotlivých Blockchainech