Blockchain platforma za poduzeća
Dobar dan, dragi čitatelji, moje ime je Nikolay Nefedov, tehnički sam stručnjak u IBM-u, u ovom bih vam članku želio predstaviti blockchain platformu - Hyperledger Fabric. Platforma je dizajnirana za izgradnju poslovnih aplikacija poslovne klase. Razina članka je za nespremne čitatelje s osnovnim poznavanjem IT tehnologija.
Hyperledger Fabric je projekt otvorenog koda, jedan od ogranaka projekta otvorenog koda Hyperledger, konzorcija Linux Foundationa. Hyperledger Fabric izvorno su pokrenuli Digital Assets i IBM. Glavna značajka platforme Hyperledger Fabric je njezin fokus na korištenje u poduzećima. Stoga je platforma razvijena uzimajući u obzir veliku brzinu transakcija i njihovu nisku cijenu, kao i identifikaciju svih sudionika. Navedene prednosti ostvaruju se odvajanjem usluge verifikacije transakcija i formiranjem novih blokova distribuiranog registra, te korištenjem certifikacijskog centra i autorizacijom sudionika.
Moj je članak dio serije članaka o Hyperledger Fabric-u, u okviru kojega opisujemo projekt sustava za evidentiranje upisa studenata na sveučilište.
Opća arhitektura Hyperledger Fabric
Hyperledger Fabric je distribuirana blockchain mreža koja se sastoji od različitih funkcionalnih komponenti koje su instalirane na mrežnim čvorovima. Komponente Hyperledger Fabric su Docker spremnici koji se mogu besplatno preuzeti s DockerHuba. Hyperledger Fabric također se može pokrenuti u Kubernetes okruženju.
Koristili smo Golang za pisanje pametnih ugovora (lančani kod u kontekstu Hyperledger Fabrica) (iako Hyperledger Fabric dopušta korištenje drugih jezika). Za razvoj prilagođene aplikacije, u našem slučaju, koristili smo Node.js s odgovarajućim Hyperledger Fabric SDK-om.
Čvorovi izvršavaju poslovnu logiku (pametni ugovor) - lančani kod, pohranjuju stanje distribuiranog registra (podaci glavne knjige) i izvršavaju ostale sistemske usluge platforme. Čvor je samo logička jedinica; različiti čvorovi mogu postojati na istom fizičkom poslužitelju. Puno je važnije kako su čvorovi grupirani (Trusted domain) i s kojim su funkcijama blockchain mreže povezani.
Opća arhitektura izgleda ovako:
Slika 1. Opća arhitektura Hyperledger tkanine
Korisnička aplikacija (Submitting Client) je aplikacija s kojom korisnici rade s blockchain mrežom. Za rad morate biti ovlašteni i imati odgovarajuća prava za razne vrste radnji na mreži.
Vršnjaci imaju nekoliko uloga:
- Endorsing Peer je čvor koji simulira izvršenje transakcije (izvršava kod pametnog ugovora). Nakon provjere i izvršenja pametnog ugovora, čvor vraća rezultate izvršenja klijentskoj aplikaciji zajedno sa svojim potpisom.
- Ordering Service je distribuirani servis na nekoliko čvorova, koji se koristi za generiranje novih blokova distribuiranog registra i kreiranje reda čekanja za izvršenje transakcija. Usluga naručivanja ne dodaje nove blokove u registar (Ova značajka je premještena u Committing Peers radi poboljšanja performansi).
- Committing Peer je čvor koji sadrži distribuirani registar i dodaje nove blokove u registar (koje je generirala Usluga naručivanja). Svi vršnjaci koji predaju sadrže lokalnu kopiju distribuirane knjige. Obavezni peer provjerava valjanost svih transakcija unutar bloka prije lokalnog dodavanja novog bloka.
Politika odobrenja je politika za provjeru valjanosti transakcije. Ove politike definiraju potrebni skup čvorova na kojima se pametni ugovor mora izvršiti kako bi se transakcija prepoznala kao važeća.
Distribuirani registar - Lerger - sastoji se od dva dijela: WolrldState (koji se također naziva State DataBase) i BlockChain.
BlockChain je lanac blokova koji pohranjuje zapise o svim promjenama koje su se dogodile na objektima distribuiranog registra.
WolrldState je komponenta distribuirane knjige koja pohranjuje trenutne (najmodernije) vrijednosti svih objekata distribuirane knjige.
WorldState je baza podataka, u osnovnoj verziji - LevelDB ili složenijoj - CouchDB, koja sadrži parove ključ-vrijednost, npr.: Ime - Ivan, Prezime - Ivanov, datum registracije u sustavu - 12.12.21. , datum rođenja - 17.12.1961., itd. WorldState i distribuirani registar moraju biti dosljedni među svim sudionicima u određenom kanalu.
Budući da je Hyperledger Fabric mreža u kojoj su svi sudionici poznati i autentificirani, koristi namjensko certifikacijsko tijelo - CA (Certification Authority). CA radi na temelju X.509 standarda i infrastrukture javnih ključeva - PKI.
Membership Service je usluga putem koje članovi provjeravaju pripadnost objekta određenoj organizaciji ili kanalu.
Transakcija – u većini slučajeva je upisivanje novih podataka u distribuirani registar.
Tu su i transakcije za stvaranje kanala ili pametnih ugovora. Transakciju pokreće korisnička aplikacija i završava zapisom u distribuiranoj knjizi.
Kanal je zatvorena podmreža koja se sastoji od dva ili više sudionika blockchain mreže, dizajnirana za provođenje povjerljivih transakcija unutar ograničenog, ali poznatog kruga sudionika. Kanal određuju sudionici, njegov distribuirani registar, pametni ugovori, Usluga naručivanja, WorldState. Svaki sudionik kanala mora biti ovlašten za pristup kanalu i imati pravo obavljanja različitih vrsta transakcija. Autorizacija se provodi putem Članskog servisa.
Tipični scenarij izvršenja transakcije
Zatim bih želio govoriti o tipičnom scenariju izvršenja transakcije koristeći naš projekt kao primjer.
Kao dio našeg internog projekta izradili smo Hyperledger Fabric mrežu koja je dizajnirana za registraciju i obračunavanje studenata koji ulaze na sveučilišta. Naša mreža sastoji se od dvije organizacije koje pripadaju Sveučilištu A i Sveučilištu B. Svaka organizacija sadrži klijentsku aplikaciju, kao i vlastitog partnera za obvezu i podršku. Također koristimo zajedničke usluge Služba za naručivanje, Usluga za članstvo i Tijelo za izdavanje certifikata.
1) Pokretanje transakcije
Korisnička aplikacija, koristeći Hyperledger Fabric SDK, pokreće zahtjev za transakciju i šalje zahtjev čvorovima s pametnim ugovorima. Zahtjev može biti promjena ili čitanje iz distribuiranog registra (Ledger). Ako uzmemo u obzir primjer konfiguracije našeg testnog sustava za računovodstvo za sveučilišne studente, klijentska aplikacija šalje zahtjev za transakciju čvorovima sveučilišta A i B, koji su uključeni u politiku odobrenja pozvanog pametnog ugovora. Čvor A je čvor koji se nalazi na sveučilištu koje prijavljuje dolaznog studenta, a čvor B je čvor koji se nalazi na drugom sveučilištu. Kako bi se transakcija spremila u distribuirani registar, potrebno je da svi čvorovi koji po poslovnoj logici moraju odobriti transakciju uspješno izvršavaju pametne ugovore s istim rezultatom. Čvor Korisnička aplikacija, pomoću alata Hyperledger Fabric SDK, dobiva politiku odobrenja i uči kojim čvorovima treba poslati zahtjev za transakciju. Ovo je zahtjev za pozivanje određenog pametnog ugovora (funkcija lančanog koda) za čitanje ili pisanje određenih podataka u distribuirani registar. Tehnički, klijentski SDK koristi odgovarajuću funkciju, čijem se API-ju prosljeđuje određeni objekt s parametrima transakcije, a također dodaje potpis klijenta i šalje te podatke putem međuspremnika protokola preko gRPC-a do odgovarajućih čvorova (upravni uređaji).
Slika 2. Pokretanje transakcije
2) Izvršenje pametnog ugovora
Čvorovi (Endorsing Peers), primivši zahtjev za provedbu transakcije, provjeravaju potpis klijenta i ako je sve u redu, uzimaju objekt s podacima zahtjeva i pokreću simulaciju izvršenja pametnog ugovora (funkcija lančanog koda) s ove podatke. Pametni ugovor je poslovna logika transakcije, određeni set uvjeta i uputa (kod nas je to provjera studenta, je li to novi student ili je već registriran, provjera dobi itd.). Za izvršenje pametnog ugovora bit će vam potrebni i podaci iz WorldState-a. Kao rezultat simulacije pametnog ugovora na ravnopravnom uređaju koji podržava, dobivaju se dva skupa podataka – Read Set i Write Set. Read Set i Write Set izvorne su i nove vrijednosti WorldState. (novo – u smislu dobivenom tijekom simulacije pametnog ugovora).
Slika 3. Izvršenje pametnog ugovora
3) Vraćanje podataka klijentskoj aplikaciji
Nakon provedbe simulacije pametnog ugovora, Endorsing Peers klijentskoj aplikaciji vraćaju originalne podatke i rezultat simulacije, kao i RW Set, potpisan njihovim certifikatom. U ovoj fazi ne dolazi do promjena u distribuiranom registru. Klijentska aplikacija provjerava potpis Endorsing Peer-a, a također uspoređuje izvorne podatke o transakciji koji su poslani i podatke koji su vraćeni (to jest, provjerava jesu li izvorni podaci na kojima je transakcija simulirana iskrivljeni). Ako je transakcija bila samo za čitanje podataka iz registra, tada klijentska aplikacija u skladu s tim prima potreban Read Set i to obično uspješno dovršava transakciju bez mijenjanja distribuiranog registra. U slučaju transakcije koja mora promijeniti podatke u registru, klijentska aplikacija dodatno provjerava provedbu Endorsing politike. Moguće je da klijentska aplikacija ne provjerava rezultat izvršavanja Politike odobrenja, ali platforma Hyperledger Fabric u tom slučaju omogućuje provjeru politika na čvorovima (Committing Peers) u fazi dodavanja transakcije u registar.
Slika 4. Vraćanje podataka klijentskoj aplikaciji
4) Slanje RW skupova ravnopravnim uređajima za naručivanje
Klijentska aplikacija transakciju s pripadajućim podacima šalje servisu Naručivanje. To uključuje RW set, potpise istovrsnih korisnika koji podržavaju i ID kanala.
Usluga naručivanja – prema nazivu, glavna funkcija ove usluge je sređivanje dolaznih transakcija točnim redoslijedom. Kao i formiranje novog bloka distribuiranog registra i zajamčenu isporuku novih generiranih blokova svim Commiting čvorovima, čime se osigurava konzistentnost podataka na svim čvorovima koji sadrže distribuirani registar (Committing peers). Pritom sama usluga naručivanja ni na koji način ne mijenja registar. Usluga naručivanja vitalna je komponenta sustava, stoga je klaster od nekoliko čvorova. Usluga naručivanja ne provjerava valjanost transakcije, ona jednostavno prihvaća transakciju s određenim identifikatorom kanala, raspoređuje dolazne transakcije određenim redoslijedom i od njih formira nove blokove distribuiranog registra. Jedna usluga naručivanja može opsluživati nekoliko kanala istovremeno. Usluga naručivanja uključuje Kafka klaster koji održava ispravan (nepromjenjiv) red transakcija (vidi točku 7).
Slika 5. Slanje RW skupova vršnjacima za naručivanje
5) Slanje generiranih blokova ravnopravnom uređaju za predaju
Blokovi generirani u usluzi naručivanja prenose se (emitiraju) svim mrežnim čvorovima. Svaki čvor, nakon što je primio novi blok, provjerava njegovu usklađenost s Politikom odobravanja, provjerava jesu li svi ravnopravni korisnici koji podržavaju dobili isti rezultat (Write Set) kao rezultat simulacije pametnog ugovora, te također provjerava imaju li originalne vrijednosti promijenjen (odnosno Read Set - podaci koje pametni ugovor čita iz WorldState-a) od trenutka kada je transakcija pokrenuta. Ako su ispunjeni svi uvjeti, transakcija se označava kao važeća, u suprotnom, transakcija dobiva status nevažeća.
Slika 6. Slanje generiranih blokova u Committing Peer
6) Dodavanje bloka u registar
Svaki čvor dodaje transakciju u svoju lokalnu kopiju distribuiranog registra, a ako je transakcija valjana, tada se Write Set primjenjuje na WorldState (trenutno stanje), i sukladno tome, nove vrijednosti objekata na koje je utjecao transakcije su napisane. Ako je transakcija primila token koji nije važeći (na primjer, dogodile su se dvije transakcije s istim objektima unutar istog bloka, tada će se jedna od transakcija pokazati nevažećom, budući da je izvorne vrijednosti već promijenio drugi transakcija). Ova se transakcija također dodaje u distribuiranu knjigu s nevažećim tokenom, ali Write Set ove transakcije nije primijenjen na trenutni WorldState i, sukladno tome, ne mijenja objekte koji sudjeluju u transakciji. Nakon toga korisničkoj aplikaciji se šalje obavijest da je transakcija trajno dodana u distribuirani registar, kao i status transakcije, odnosno da li je važeća ili ne...
Slika 7. Dodavanje bloka u registar
NARUČIVANJE USLUGE
Usluga naručivanja sastoji se od Kafka klastera s odgovarajućim ZooKeeper čvorovima i čvorovima usluge naručivanja (OSN), koji stoje između klijenata usluge naručivanja i Kafka klastera. Kafka klaster je distribuirana platforma za upravljanje protokom (porukama) otporna na pogreške. Svaki kanal (tema) u Kafki je nepromjenjiv niz zapisa koji podržava samo dodavanje novog zapisa (brisanje postojećeg nije moguće). Dolje je prikazana ilustracija strukture teme. To je Kafkino svojstvo koje se koristi za izgradnju blockchain platforme.
preuzeto s kafka.apache.org
- Slika 8. Struktura teme usluge naručivanja*
Korisni linkovi
Blagodarnosti
Želio bih izraziti duboku zahvalnost svojim kolegama na pomoći u pripremi ovog članka:
Nikolaj Marin
Igor Khapov
Dmitrij Gorbačov
Aleksandar Zemcov
Ekaterina Guseva
Izvor: www.habr.com