Blockchainová platforma pro podniky
Dobré odpoledne, milí čtenáři, jmenuji se Nikolai Nefedov, jsem technický specialista IBM, v tomto článku bych vám rád představil blockchainovou platformu – Hyperledger Fabric. Platforma je určena pro vytváření podnikových aplikací na podnikové úrovni (třída Enterprise). Úroveň článku je pro nepřipravené čtenáře se základními znalostmi IT technologií.
Hyperledger Fabric je open-source projekt, jedna z větví projektu Hyperledger open source, konsorcia Linux Foundation. Hyperledger Fabric byl původně spuštěn společnostmi Digital Assets a IBM. Hlavním rysem platformy Hyperledger Fabric je její zaměření na firemní aplikace. Proto byla platforma vyvinuta s ohledem na vysokou rychlost transakcí a jejich nízkou cenu a také na identifikaci všech účastníků. Těchto výhod je dosaženo oddělením služby ověřování transakcí a vytvořením nových bloků distribuovaného registru, stejně jako použitím certifikační autority a autorizace účastníků.
Můj článek je součástí série článků o Hyperledger Fabric, ve kterých popisujeme projekt systému pro registraci studentů nastupujících na vysokou školu.
Obecná architektura Hyperledger Fabric
Hyperledger Fabric je distribuovaná blockchain síť sestávající z různých funkčních komponent, které jsou instalovány na síťových uzlech. Komponenty Hyperledger Fabric jsou kontejnery Docker, které lze volně stáhnout z DockerHubu. Hyperledger Fabric lze také spustit v prostředí Kubernetes.
Pro psaní chytrých kontraktů (řetězový kód v kontextu Hyperledger Fabric) jsme použili Golang (ačkoli Hyperledger Fabric umožňuje používat jiné jazyky). K vývoji vlastní aplikace byl v našem případě použit Node.js s odpovídající sadou Hyperledger Fabric SDK.
Uzly provozují obchodní logiku (smart contract) – řetězový kód, ukládají stav distribuovaného registru (data hlavní knihy) a provádějí další systémové služby platformy. Uzel je pouze logická jednotka, na stejném fyzickém serveru mohou existovat různé uzly. Mnohem důležitější je, jak jsou uzly seskupeny (Trusted domain) a s jakými funkcemi blockchainové sítě jsou spojeny.
Obecná architektura vypadá takto:
Obrázek 1. Obecná architektura Hyperledger Fabric
Uživatelská aplikace (Submitting Client) je aplikace, se kterou uživatelé pracují s blockchainovou sítí. Chcete-li pracovat, musíte projít autorizací a mít příslušná práva pro různé druhy akcí v síti.
Peers (Nodes) mají několik rolí:
- Endorsing Peer je uzel, který simuluje provádění transakce (provádí kód inteligentní smlouvy). Po ověření a provedení smart kontraktu vrátí uzel výsledky provedení klientské aplikaci spolu se svým podpisem.
- Objednávková služba je distribuovaná služba na několika uzlech, používá se k vytvoření nových bloků distribuované účetní knihy a vytvoření sekvence pro provádění transakcí. Služba Ordering Service nepřidává do registru nové bloky (přesunuto do Committing Peers pro lepší výkon).
- Committing Peer - uzel, který obsahuje distribuovaný registr a přidává do registru nové bloky (které byly vytvořeny objednávkovou službou). Všichni schvalující peeři obsahují místní kopii distribuované účetní knihy. Committing Peer před místním přidáním nového bloku zkontroluje platnost všech transakcí v rámci bloku.
Zásady schvalování jsou zásady pro kontrolu platnosti transakce. Tyto zásady definují nezbytnou sadu uzlů, na kterých musí být proveden inteligentní kontrakt, aby byla transakce uznána jako platná.
Distribuovaný registr - Lerger - se skládá ze dvou částí: WolrldState (také nazývaný State DataBase) a BlockChain.
BlockChain je řetězec bloků, který ukládá záznamy o všech změnách, ke kterým došlo v objektech distribuované knihy.
WolrldState je komponenta distribuovaného registru, která ukládá aktuální (extrémní) hodnoty všech objektů distribuovaného registru.
WorldState je databáze, v základní verzi - LevelDB nebo složitější - CouchDB, která obsahuje páry klíč-hodnota, např.: Jméno - Ivan, Příjmení - Ivanov, datum registrace v systému - 12.12.21, datum narození - 17.12.1961 atd. WorldState a distribuovaná účetní kniha musí být konzistentní napříč všemi členy daného kanálu.
Vzhledem k tomu, že Hyperledger Fabric je síť, ve které jsou všichni účastníci známí a autentizováni, používá se zde vyhrazená certifikační autorita – CA (Certification Authority). CA funguje na základě standardu X.509 a infrastruktury veřejných klíčů - PKI.
Členská služba je služba, jejímž prostřednictvím členové ověřují, že objekt patří určité organizaci nebo kanálu.
Transakce je ve většině případů záznamem nových dat v distribuované účetní knize.
Existují také transakce pro vytváření kanálů nebo smart kontraktů. Transakce je iniciována uživatelskou aplikací a končí zápisem do distribuované účetní knihy.
Kanál (Channel) je uzavřená podsíť sestávající ze dvou nebo více účastníků v blockchainové síti, určená k provádění důvěrných transakcí v rámci omezeného, ale známého okruhu účastníků. Kanál je určen účastníky, jeho distribuovanou účetní knihou, inteligentními smlouvami, objednávkovou službou, WorldState. Každý člen kanálu musí mít oprávnění pro přístup ke kanálu a mít právo provádět různé druhy transakcí. Autorizace se provádí pomocí členské služby.
Typický scénář provádění transakce
Dále bych rád hovořil o typickém scénáři pro provedení transakce na příkladu našeho projektu.
V rámci našeho interního projektu jsme vytvořili síť Hyperledger Fabric, která je určena k registraci a evidenci studentů nastupujících na vysoké školy. Naše síť se skládá ze dvou organizací vlastněných Univerzitou A a Univerzitou B. Každá organizace obsahuje klientskou aplikaci a také svého vlastního zavazujícího a schvalujícího partnera. Využíváme také běžné služby Objednávková služba, Členská služba a Certifikační autorita.
1) Zahájení transakce
Uživatelská aplikace pomocí sady Hyperledger Fabric SDK zahájí požadavek na transakci a odešle požadavek uzlům s inteligentními smlouvami. Požadavek může být změna nebo čtení z distribuované účetní knihy (Ledger). Pokud vezmeme v úvahu příklad naší testovací konfigurace systému pro účtování pro vysokoškoláky, pak klientská aplikace odešle transakční požadavek na uzly univerzit A a B, které jsou zahrnuty v Endorsement policy tzv. smart kontraktu. Uzel A je uzel, který se nachází na univerzitě, která registruje příchozího studenta, a uzel B je uzel, který se nachází na jiné univerzitě. Aby byla transakce uložena do distribuované účetní knihy, je nutné, aby všechny uzly, které podle obchodní logiky musí transakci schválit, úspěšně provedly smart kontrakty se stejným výsledkem. Uživatelská aplikace uzlu A pomocí nástrojů Hyperledger Fabric SDK obdrží zásadu Endorsement (zásady schvalování) a zjistí, na které uzly má odeslat požadavek na transakci. Toto je požadavek na volání (vyvolání) určité inteligentní smlouvy (funkce řetězového kódu) za účelem čtení nebo zápisu určitých dat do distribuované účetní knihy. Technicky klientské SDK využívá odpovídající funkci, jejímž API předává objekt s transakčními parametry, přidává také klientský podpis a odesílá tato data přes protokolový buffer přes gRPC příslušným uzlům (podporujícím peerům).
Obrázek 2. Zahájení transakce
2) Chytré provedení smlouvy
Uzly (Endorsing Peers), po obdržení požadavku na provedení transakce, zkontrolují podpis klienta a pokud je vše v pořádku, vezmou objekt s daty požadavku a spustí simulaci provedení chytré smlouvy (funkce řetězového kódu) s těmito údaji. Chytrá smlouva je obchodní logika transakce, určitý soubor podmínek a pokynů (v našem případě se jedná o studentský šek, je to nový student, nebo je již registrován, věková kontrola atd.). K realizaci smart kontraktu budete potřebovat také data z WorldState. V důsledku simulace inteligentní smlouvy na schvalovacím peeru jsou získány dvě datové sady – Read Set a Write Set. Read Set a Write Set jsou původní a nové hodnoty WorldState. (nové – ve smyslu získaném simulací chytré smlouvy).
Obrázek 3. Chytrá realizace smlouvy
3) Vrácení dat do klientské aplikace
Po simulaci chytré smlouvy vrátí Endorsing Peers do klientské aplikace počáteční data a výsledek simulace a také sadu RW podepsanou jejich certifikátem. V této fázi nedochází k žádným změnám v distribuované knize. Klientská aplikace ověří podpis Endorsing Peer a také porovná původní data transakce, která byla odeslána, a data, která se vrátila (to znamená, že zkontroluje, zda nebyla poškozena původní data, na kterých byla transakce simulována). Pokud byla transakce pouze pro čtení dat z registru, pak klientská aplikace odpovídajícím způsobem obdrží potřebnou sadu pro čtení a transakce se pak obvykle úspěšně dokončí bez změny distribuovaného registru. V případě transakce, která by měla změnit data v registru, klientská aplikace navíc zkontroluje, zda byla implementována politika schvalování. Je možné, že klientská aplikace nekontroluje výsledek provádění Endorsement Policy, ale platforma Hyperledger Fabric v tomto případě poskytuje kontrolu politik na uzlech (Committing Peers) ve fázi přidávání transakce do registru.
Obrázek 4. Vrácení dat do klientské aplikace
4) Odeslání sad RW objednávkovým kolegům
Klientská aplikace odešle transakci spolu se souvisejícími daty do služby Objednávání. To zahrnuje sadu RW, podpisy schvalujících kolegů a ID kanálu.
Objednávková služba – Na základě názvu je hlavní funkcí této služby sestavení příchozích transakcí ve správném pořadí. Stejně jako vytvoření nového bloku distribuovaného registru a garantované doručení nově vygenerovaných bloků do všech Commiting uzlů, čímž je zajištěna konzistence dat na všech uzlech obsahujících distribuovaný registr (Committing peers). Samotná služba Objednávání přitom registr nijak nemění. Objednávková služba je důležitou součástí systému, takže se jedná o shluk několika uzlů. Objednávková služba nekontroluje platnost transakce, pouze přijme transakci s konkrétním ID kanálu, uspořádá příchozí transakce do konkrétního pořadí a vytvoří z nich nové bloky distribuované knihy. Jedna objednávková služba může obsluhovat několik kanálů současně. Objednávková služba zahrnuje Kafka cluster, který udržuje správnou (nezměněnou) frontu transakcí (viz bod 7).
Obrázek 5. Odesílání sad RW do Ordering Peers
5) Odeslání vygenerovaných bloků do Committing Peer
Bloky vytvořené v objednávkové službě jsou vysílány do všech síťových uzlů. Každý uzel, který obdržel nový blok, zkontroluje, zda je v souladu se zásadami schvalování, zkontroluje, zda všichni schvalující rovnocenní partneři obdrželi stejný výsledek (sada zápisu) jako výsledek simulace inteligentní smlouvy, a také zkontroluje, zda mají původní hodnoty změněna (tj. - Read Set - data načtená smart kontraktem z WorldState) od zahájení transakce. Pokud jsou splněny všechny podmínky, transakce je označena jako platná, v opačném případě je transakce označena jako neplatná.
Obrázek 6. Odeslání vygenerovaných bloků do Committing Peer
6) Přidání bloku do registru
Každý uzel přidá transakci do své místní kopie distribuované účetní knihy, a pokud je transakce platná, použije se sada zápisu na WorldState (aktuální stav), respektive se zapíší nové hodnoty objektů, které byly transakcí ovlivněny. . Pokud transakce obdržela token, který nebyl platný (například došlo ke dvěma transakcím se stejnými objekty ve stejném bloku, pak jedna z transakcí nebude platná, protože původní hodnoty již byly změněny jinou transakcí ). Tato transakce je také přidána do distribuované účetní knihy s neplatnou značkou, ale zapisovací sada této transakce se nevztahuje na aktuální stav WorldState, a tudíž nemění objekty účastnící se transakce. Poté je do uživatelské aplikace odesláno upozornění, že transakce byla navždy přidána do distribuované účetní knihy, a také stav transakce, tedy zda je platná nebo ne ...
Obrázek 7. Přidání bloku do registru
OBJEDNÁVKA SLUŽBY
Objednávková služba se skládá z klastru Kafka s odpovídajícími uzly ZooKeeper a uzlů objednávkové služby (OSN), které jsou umístěny mezi klienty objednávkové služby a klastrem Kafka. Kafka cluster je distribuovaná platforma pro správu toku (zpráv) odolná vůči chybám. Každý kanál (téma) v Kafce je neměnná sekvence záznamů, která podporuje pouze přidání nového záznamu (smazání stávajícího není možné). Níže je uvedena ilustrace struktury tématu. Právě tato vlastnost Kafky se používá k vybudování blockchainové platformy.
převzato z kafka.apache.org
- Obrázek 8. Struktura tématu služby objednávání*
Užitečné odkazy
Poděkování
Vyjadřuji hlubokou vděčnost svým kolegům za pomoc při přípravě článku:
Nikolaj Marina
Igor Khapov
Dmitrij Gorbačov
Alexandr Zemtsov
Jekatěrina Guseva
Zdroj: www.habr.com