Blockchainová platforma pre podniky
Dobrý deň, milí čitatelia, volám sa Nikolay Nefedov, som technický špecialista v IBM, v tomto článku by som vám rád predstavil blockchainovú platformu – Hyperledger Fabric. Platforma je navrhnutá na vytváranie podnikových aplikácií podnikovej triedy. Úroveň článku je pre nepripravených čitateľov so základnými znalosťami IT technológií.
Hyperledger Fabric je open-source projekt, jedna z vetiev open source projektu Hyperledger, konzorcia Linux Foundation. Hyperledger Fabric pôvodne založili Digital Assets a IBM. Hlavnou črtou platformy Hyperledger Fabric je jej zameranie na podnikové využitie. Preto bola platforma vyvinutá s ohľadom na vysokú rýchlosť transakcií a ich nízku cenu, ako aj identifikáciu všetkých účastníkov. Tieto výhody sa dosahujú oddelením služby overovania transakcií a vytváraním nových blokov distribuovaného registra, ako aj využívaním certifikačného centra a autorizáciou účastníkov.
Môj článok je súčasťou série článkov o Hyperledger Fabric, v rámci ktorej popisujeme systémový projekt na evidenciu študentov nastupujúcich na univerzitu.
Všeobecná architektúra Hyperledger Fabric
Hyperledger Fabric je distribuovaná blockchain sieť pozostávajúca z rôznych funkčných komponentov, ktoré sú nainštalované na sieťových uzloch. Komponenty Hyperledger Fabric sú kontajnery Docker, ktoré je možné voľne stiahnuť z DockerHub. Hyperledger Fabric je možné spustiť aj v prostredí Kubernetes.
Na písanie inteligentných zmlúv (reťazový kód v kontexte Hyperledger Fabric) sme použili Golang (hoci Hyperledger Fabric umožňuje použitie iných jazykov). Na vývoj vlastnej aplikácie sme v našom prípade použili Node.js s príslušným Hyperledger Fabric SDK.
Uzly vykonávajú obchodnú logiku (smart contract) - reťazový kód, ukladajú stav distribuovaného registra (údaje účtovnej knihy) a vykonávajú ďalšie systémové služby platformy. Uzol je len logická jednotka; na rovnakom fyzickom serveri môžu existovať rôzne uzly. Oveľa dôležitejšie je, ako sú uzly zoskupené (Trusted domain) a s akými funkciami blockchainovej siete sú spojené.
Všeobecná architektúra vyzerá takto:
Obrázok 1. Všeobecná architektúra Hyperledger Fabric
Používateľská aplikácia (Submitting Client) je aplikácia, s ktorou používatelia pracujú s blockchainovou sieťou. Ak chcete pracovať, musíte byť autorizovaní a mať príslušné práva na rôzne typy akcií v sieti.
Vrstovníci vystupujú v niekoľkých rolách:
- Endorsing Peer je uzol, ktorý simuluje vykonávanie transakcie (vykonáva kód inteligentnej zmluvy). Po overení a vykonaní smart kontraktu uzol vráti výsledky vykonania klientskej aplikácii spolu s podpisom.
- Objednávková služba je distribuovaná služba na niekoľkých uzloch, ktorá sa používa na generovanie nových blokov distribuovaného registra a vytváranie frontu na vykonávanie transakcií. Objednávková služba nepridáva do registra nové bloky (Táto funkcia bola presunutá do Committing Peers, aby sa zlepšil výkon).
- Committing Peer je uzol, ktorý obsahuje distribuovaný register a pridáva do registra nové bloky (ktoré boli vygenerované objednávkovou službou). Všetci zaviazaní partneri obsahujú lokálnu kópiu distribuovanej účtovnej knihy. Committing Peer skontroluje platnosť všetkých transakcií v rámci bloku pred lokálnym pridaním nového bloku.
Schvaľovacia politika je politika na kontrolu platnosti transakcie. Tieto politiky definujú požadovanú množinu uzlov, na ktorých musí byť vykonaná smart zmluva, aby bola transakcia uznaná ako platná.
Distribuovaný register – Lerger – pozostáva z dvoch častí: WolrldState (nazývaný aj State DataBase) a BlockChain.
BlockChain je reťazec blokov, ktorý uchováva záznamy o všetkých zmenách, ktoré sa vyskytli v distribuovaných objektoch registra.
WolrldState je komponent distribuovanej účtovnej knihy, ktorý ukladá aktuálne (najnovšie) hodnoty všetkých objektov distribuovanej účtovnej knihy.
WorldState je databáza, v základnej verzii - LevelDB alebo komplexnejšej - CouchDB, ktorá obsahuje páry kľúč-hodnota, napr.: Meno - Ivan, Priezvisko - Ivanov, dátum registrácie v systéme - 12.12.21. , dátum narodenia - 17.12.1961 atď. WorldState a distribuovaný register musia byť konzistentné medzi všetkými účastníkmi v danom kanáli.
Keďže Hyperledger Fabric je sieť, v ktorej sú všetci účastníci známi a autentifikovaní, využíva vyhradenú certifikačnú autoritu – CA (Certification Authority). CA funguje na základe štandardu X.509 a infraštruktúry verejného kľúča – PKI.
Členská služba je služba, prostredníctvom ktorej členovia overujú, že objekt patrí konkrétnej organizácii alebo kanálu.
Transakcia – vo väčšine prípadov je zápis nových údajov do distribuovaného registra.
Existujú aj transakcie na vytváranie kanálov alebo smart kontraktov. Transakcia je iniciovaná používateľskou aplikáciou a končí záznamom v distribuovanej účtovnej knihe.
Kanál je uzavretá podsieť pozostávajúca z dvoch alebo viacerých účastníkov blockchainovej siete, ktorá je určená na vykonávanie dôverných transakcií v rámci obmedzeného, ale známeho okruhu účastníkov. Kanál určujú účastníci, jeho distribuovaný register, inteligentné zmluvy, objednávková služba, WorldState. Každý účastník kanála musí mať oprávnenie na prístup ku kanálu a musí mať právo vykonávať rôzne typy transakcií. Autorizácia sa vykonáva pomocou členskej služby.
Typický scenár vykonávania transakcie
Ďalej by som chcel hovoriť o typickom scenári vykonávania transakcií s použitím nášho projektu ako príkladu.
V rámci nášho interného projektu sme vytvorili sieť Hyperledger Fabric, ktorá je určená na registráciu a účtovníctvo študentov vstupujúcich na vysoké školy. Naša sieť pozostáva z dvoch organizácií patriacich Univerzite A a Univerzite B. Každá organizácia obsahuje klientsku aplikáciu, ako aj svojho vlastného zaväzujúceho a schvaľovacieho partnera. Využívame aj bežné služby Objednávková služba, Členská služba a Certifikačná autorita.
1) Začatie transakcie
Používateľská aplikácia pomocou súpravy Hyperledger Fabric SDK iniciuje požiadavku na transakciu a odošle požiadavku uzlom s inteligentnými zmluvami. Požiadavka môže byť zmena alebo čítanie z distribuovaného registra (Ledger). Ak vezmeme do úvahy príklad našej konfigurácie testovacieho systému pre účtovníctvo pre vysokoškolákov, klientska aplikácia odošle požiadavku na transakciu do uzlov univerzít A a B, ktoré sú zahrnuté v politike Endorsement nazývanej smart kontrakt. Uzol A je uzol, ktorý sa nachádza na univerzite, ktorá eviduje prichádzajúceho študenta, a uzol B je uzol, ktorý sa nachádza na inej univerzite. Aby sa transakcia uložila do distribuovaného registra, je potrebné, aby všetky uzly, ktoré podľa obchodnej logiky transakciu musia schváliť, úspešne vykonali smart kontrakty s rovnakým výsledkom. Používateľská aplikácia uzla A pomocou nástrojov Hyperledger Fabric SDK získa politiku schválenia a naučí sa, na ktoré uzly má odoslať požiadavku na transakciu. Toto je požiadavka na vyvolanie špecifického smart kontraktu (funkcia reťazového kódu) na čítanie alebo zápis určitých údajov do distribuovaného registra. Technicky klient SDK využíva zodpovedajúcu funkciu, ktorej API odovzdá určitý objekt s transakčnými parametrami a pridá aj podpis klienta a tieto dáta odošle cez protokolový buffer cez gRPC príslušným uzlom (podporujúcim peerom).
Obrázok 2. Začatie transakcie
2) Vykonanie smart kontraktu
Uzly (Endoring Peers) po prijatí požiadavky na vykonanie transakcie skontrolujú podpis klienta a ak je všetko v poriadku, vezmú objekt s údajmi požiadavky a spustia simuláciu vykonania inteligentnej zmluvy (funkcia reťazového kódu) s tieto údaje. Inteligentná zmluva je obchodná logika transakcie, určitý súbor podmienok a pokynov (v našom prípade ide o overenie študenta, ide o nového študenta, alebo je už zaregistrovaný, overenie veku atď.). Na vykonanie smart kontraktu budete potrebovať aj údaje od WorldState. V dôsledku simulácie inteligentnej zmluvy na podpornom partnerovi sa získajú dve sady údajov – množina čítania a množiny zápisu. Read Set a Write Set sú pôvodné a nové hodnoty WorldState. (nový – v zmysle získanom počas simulácie smart kontraktu).
Obrázok 3. Realizácia smart kontraktu
3) Vrátenie údajov do klientskej aplikácie
Po vykonaní simulácie inteligentnej zmluvy vrátia Endorsing Peers pôvodné údaje a výsledok simulácie, ako aj RW Set podpísaný ich certifikátom do klientskej aplikácie. V tomto štádiu nenastanú v distribuovanom registri žiadne zmeny. Klientska aplikácia skontroluje podpis Endorsing Peer a tiež porovná pôvodné dáta transakcie, ktoré boli odoslané, a dáta, ktoré boli vrátené (teda skontroluje, či pôvodné dáta, na ktorých bola transakcia simulovaná, neboli skreslené). Ak bola transakcia len na čítanie údajov z registra, potom klientska aplikácia podľa toho dostane potrebnú sadu na čítanie a to zvyčajne úspešne dokončí transakciu bez zmeny distribuovaného registra. V prípade transakcie, ktorá musí zmeniť údaje v registri, klientska aplikácia dodatočne kontroluje implementáciu Endorsing policy. Je možné, že klientska aplikácia nekontroluje výsledok vykonania politiky schvaľovania, ale platforma Hyperledger Fabric v tomto prípade poskytuje kontrolu politík na uzloch (Committing Peers) vo fáze pridávania transakcie do registra.
Obrázok 4. Vrátenie údajov do klientskej aplikácie
4) Odoslanie sád RW objednávkovým partnerom
Klientska aplikácia odošle transakciu spolu so sprievodnými údajmi do služby Objednávanie. To zahŕňa RW Set, Schvaľovanie podpisov partnerov a ID kanála.
Objednávková služba – podľa názvu je hlavnou funkciou tejto služby usporiadanie prichádzajúcich transakcií v správnom poradí. Rovnako ako vytvorenie nového bloku distribuovaného registra a garantované doručenie nových vygenerovaných blokov do všetkých Commiting nodov, čím sa zabezpečí konzistentnosť údajov na všetkých uzloch obsahujúcich distribuovaný register (Committing peers). Zároveň samotná služba Objednávanie nijako nemení register. Objednávková služba je dôležitou súčasťou systému, takže ide o zhluk niekoľkých uzlov. Objednávková služba nekontroluje platnosť transakcie, jednoducho prijme transakciu s určitým identifikátorom kanála, usporiada prichádzajúce transakcie v určitom poradí a vytvorí z nich nové bloky distribuovaného registra. Jedna objednávková služba môže obsluhovať niekoľko kanálov súčasne. Objednávková služba obsahuje klaster Kafka, ktorý udržiava správny (nezmeniteľný) front transakcií (pozri bod 7).
Obrázok 5. Odoslanie sád RW objednávkovým partnerom
5) Odoslanie vygenerovaných blokov Committing Peer
Bloky generované v Objednávkovej službe sa prenášajú (vysielajú) do všetkých sieťových uzlov. Každý uzol po prijatí nového bloku skontroluje, či je v súlade s politikou schvaľovania, skontroluje, či všetci podporujúci partneri dostali rovnaký výsledok (súbor zápisu) ako výsledok simulácie inteligentnej zmluvy, a tiež skontroluje, či majú pôvodné hodnoty zmenené (t. j. Read Set - dáta načítané smart kontraktom z WorldState) od okamihu začatia transakcie. Ak sú splnené všetky podmienky, transakcia je označená ako platná, v opačnom prípade dostane transakcia status neplatná.
Obrázok 6. Odoslanie vygenerovaných blokov Committing Peer
6) Pridanie bloku do registra
Každý uzol pridá transakciu do svojej lokálnej kópie distribuovaného registra, a ak je transakcia platná, potom sa na WorldState (aktuálny stav) použije sada zápisu a podľa toho sa pridajú nové hodnoty objektov, ktoré boli ovplyvnené transakcie sú napísané. Ak transakcia prijala token, ktorý nie je platný (napríklad sa vyskytli dve transakcie s rovnakými objektmi v rámci toho istého bloku, potom sa jedna z transakcií ukáže ako neplatná, pretože pôvodné hodnoty už zmenila iná transakcia). Táto transakcia je tiež pridaná do distribuovanej účtovnej knihy s neplatným tokenom, ale zapisovacia sada tejto transakcie sa nepoužije na aktuálny WorldState, a preto nemení objekty zúčastňujúce sa transakcie. Potom sa používateľskej aplikácii odošle upozornenie, že transakcia bola natrvalo pridaná do distribuovaného registra, ako aj stav transakcie, teda či je platná alebo nie...
Obrázok 7. Pridanie bloku do registra
OBJEDNÁVKA SLUŽBY
Objednávková služba pozostáva z klastra Kafka s príslušnými uzlami ZooKeeper a uzlami objednávacej služby (OSN), ktoré stoja medzi klientmi objednávacej služby a klastrom Kafka. Kafka cluster je distribuovaná platforma na správu toku (správ) odolná voči chybám. Každý kanál (téma) v Kafke je nemenná postupnosť záznamov, ktorá podporuje len pridanie nového záznamu (vymazanie existujúceho nie je možné). Ilustrácia štruktúry témy je uvedená nižšie. Práve táto vlastnosť Kafku sa používa na vybudovanie blockchainovej platformy.
prevzaté z kafka.apache.org
- Obrázok 8. Štruktúra témy objednania služby*
Užitočné odkazy
Poďakovanie
Rád by som vyjadril hlbokú vďaku svojim kolegom za pomoc pri príprave tohto článku:
Nikolaj Marin
Igor Khapov
Dmitrij Gorbačov
Alexander Zemcov
Jekaterina Guseva
Zdroj: hab.com