EN
Posted by Tradičná architektúra kryptomien spolieha na distribuovanú decentralizovanú architektúru. Na jednotlivých serveroch je typicky celá kópia ledger knihy, ktorá vlastne reprezentuje všetky doposiaľ urobené transakcie. Takáto architektúra umožňuje jednoduché pridanie ďalšieho servera a dosiahnutie stavu, kde vypnutie jedného alebo prípadne i viacerých serverov sa neprejaví nijakým negatívnym efektom z pohľadu používateľa. Maximálne možno trochu dlhšou odozvou systému, keďže rovnakú záťaž musí zvládať menej serverov.
Jednoduchosť takejto architektúry implikuje relatívne jednoduché rozširovanie serverovej infraštruktúry – na nový server stačí nainštalovať príslušný softvér, urobiť pár nastavení a nakopírovať poslednú verziu ledger-u. Pre ilustráciu Bitcoin blockchain mal ku koncu marca 2020 veľkosť okolo 270GB.
Jednoduchosť má ale i svoju odvrátenú stranu. Tou je v prípade kryptomien relatívne jednoduchý a obmedzený use case, ktorý ekosystém podporuje – sú ním iba prevody čiastok medzi peňaženkami. Kryptoprojekty tak v drvivej väčšine use casov plnia iba základnú funkciu obeživa – transport hodnoty medzi dvoma používateľmi/peňaženkami. Pre úplnosť je potrebné dodať, že napríklad Ethereum umožňuje do blockchainu vložiť prostredníctvom smart-contractov kusy kódu, ktorý môže realizovať rôznorodú funkčnosť. Smart contracty definoval Vitalik Buterin – autor konceptu ako mechanizmus, umožňujúci zahrnúť digitálny majetok(digital asset) a dve alebo viac strán kontraktu do vzťahu, podľa ktorého bude digitálny majetok redistribuovaný podľa pravidiel ktoré sú závislé na určitých dátach, ktoré ešte nie sú známe keď je kontrakt tvorený. Pri skúmaní používania smart kontraktov však človek nadobudne pocit, že ich využitie je pomerne výnimočné, najmä v porovnaní s frekvenciou používania kryptomien ako prostriedku na výmenu hodnoty medzi dvoma používateľmi.
Ale späť k téme redefinície tradičnej kryptomenovej architektúry. Cieľom toho článku je zamyslieť sa, aké zmeny architektúry sú potrebné na to, aby ekosystém okolo nejakej kryptomeny podporoval širšiu funkčnosť typicky známu z bankového sveta – trvalé príkazy, inkasá alebo prípadne inú funkčnosť. A to pri zachovaní všetkých výhod ktoré súčasné architektúry kryptomenových projektov majú – teda decentralizáciu tj. nezávislosť na jednom centrálnom prvku a bullet proof spätne nemeniteľná história dát zabezpečená blockchainom.
Na to aby, mohli byť predpoklady na takúto funkčnosť naplnené, je potrebné nahradiť jednoduchý zoznam transakcií v podobe ledger knihy relačnou databázou. Jednoducho na to, aby mohol byť napríklad nejaký trvalý príkaz vykonávaný, je potrebné mať serverovú infraštruktúru, ktorá bude v pravidelný čas vykonávať zodpovedajúce prevody. V prvom rade musí v ekosystéme existovať spôsob, ako zadať informácie o trvalom príkaze – čiastku, protiúčet/protipeňaženku, periodicitu a všetky ostatné potrebné údaje. Ak chceme, aby systém mohol variabilne prijímať takéto dáta, je relačná databáza najlepšie riešenie. Relačná databáza má vo vývoji podobných aplikácií nezastupiteľnú úlohu a je pri podobných use-caseoch osvedčenou a tradičnou voľbou.
Ak ale chceme, aby údaje na jednotlivých serveroch kryptomenového ekosystému boli synchronizované, je potrebné to zabezpečiť naprieč všetkými servermi takejto infraštruktúry. Tu vstupujú do obrazu architektúry riešenia databázových firiem – napr. Oracle, ktoré dokáže takúto službu zabezpečovať svojím produktom Oracle GoldenGate, čo je akási forma middlewaru, ktorá operuje na úrovni databázových logov a je schopná v rádoch milisekúnd propagovať zmeny na jednom DB serveri na iný server.
Z uvedeného popisu je jasné, že ak by takéto prepojenie DB serverov bolo realizované, je nutné aby prístup k údajom DB servera nemal prevádzkovateľ servra. Server by musel byť zapečatený a do jeho hardwaru i softwaru by nemohol prevádzkovateľ zasahovať. Server by sa musel spravovať vzdialene centrálou správy kryptomeny. Dáta v databázových súboroch by museli byť kryptované, aby sa nič nemohlo stať pri prípadnom zmocnení sa hardwaru treťou stranou.
Aby bolo možné zachovať blockchain a jeho výhody, dáta by do relačnej databázy museli vstupovať po blokoch transakcií. Nasledujúci obrázok ilustruje infraštruktúru vzorového projektu – visiblemoney.org
Podrobný popis diagramu v angličtine tu.
Relačnou databázou sú v diagrame tvorené tri prvky:
VMTPDB – Transakčným poolom – miestom, kde vznikajú nové transakcie pri požiadavke na zmenu alebo pridanie nejakých údajov. Každý server vkladá transakcie so špecifickým ID – tým sa dajú odlíšiť transakcie, ktoré vznikli na určitom serveri. Novo vzniknutá transakcia na určitom serveri sa pomocou middleware okamžite replikuje na ostatné servery.
VMBCDB – databáza obsahujúca samotný blockchain. Záznam v blockchaine vzniká procesom balenia transakcií do blokov – čo sa deje procesom transakčného lieviku (VMTF).
VMDB – samotná databáza obsahujúca prvky bankovníctva – trvalé príkazy, inkasá atď.
Kľúčovým prvkom v celom diagrame z pohľadu Blockchainu je proces Transakčného lievika – VMTF, ktorý sa spúšťa v prípade, že aktuálny server dostane požiadavku, na vykonanie zápisu transakcií z transakčného poolu do nového bloku. Proces postupne berie jednotlivé transakcie, validuje ich a zisťuje, či ten, kto žiada o ich vykonanie má na operáciu nárok. V prípade že požadovaná transakcia prejde validáciou, proces zakladá prípadne mení objekty v relačnej DB VMDB. Po založení týchto objektov pre všetky transakcie, sa spúšťa podproces pre finalizáciu bloku. Spočíva v tom, že do blockchainu sa zapíše nový blok. Dáta bloku sa publikujú na externý server, ktorý slúži ako externé médium na prepis ktorého nemá žiaden prvok z VMIS nárok, môže tam iba nahrať práve novo vytvorený blok. Vzhľadom na to, že k Blockchain Browser Serveru bude mať prístup ktokoľvek, kto bude mať záujem, jednotlivé transakcie v ňom budú zakryptované. Človek, ktorý transakciu zadal, bude mať prístup k dekryptovaciemu kľúču, ktorým dostane do plain textu telo transakcie, z ktorého sa budú dať vyčítať detailné informácie o transakcii. Hash bloku sa bude počítať zo zakryptovnej verzie transakcií – aby sa samotné hashe dali overiť i zo zakryptovaných verzií.
Diagram je podrobne popísaný v angličtine tu.
Záver:
Nahradenie ledgera relačnou databázou je v princípe možné, za splnenia predpokladu že databázy budú navzájom synchronizované a bude ošetrené zabránenie manipulovania hardwarom a softvérom DB servrov na jednotlivých nodoch a údaje budú v DB súboroch uložené kryptované. Prvá implementácia takéhoto riešenia môže prebiehať iba v rámci jedného DB servra. Obíde sa tým kopec potencionálnych problémov spojených so synchronizáciou databáz. I keď za cenu že kryptomena bude určitý čas žiť iba na jednom serveri. Blockchain v takejto architektúre plní svoju úlohu mierne odlišne od klasických kryptomien. Je zárukou, že všetky vykonané operácie nad databázou boli vykonané štandardným spôsobom a nikto databázu nemodifikoval napríklad administratívnym DB SQL rozhraním.
Visits: 386
