Blockchaini platvorm ettevõttele
Tere päevast, kallid lugejad, minu nimi on Nikolai Nefedov, ma olen IBMi tehniline spetsialist, selles artiklis tahaksin teile tutvustada plokiahela platvormi - Hyperledger Fabric. Platvorm on mõeldud ettevõtlusklassi ärirakenduste loomiseks. Artikli tase on mõeldud IT-tehnoloogiate algteadmistega ettevalmistamata lugejatele.
Hyperledger Fabric on avatud lähtekoodiga projekt, avatud lähtekoodiga Hyperledger projekti üks harudest, mis on Linuxi sihtasutuse konsortsium. Hyperledger Fabricu käivitasid algselt Digital Assets ja IBM. Hyperledger Fabric platvormi peamine omadus on keskendumine ettevõtte kasutamisele. Seetõttu on platvormi väljatöötamisel arvestatud tehingute kiiret ja madalat maksumust ning kõigi osalejate tuvastamist. Need eelised saavutatakse tehingute kontrollimise teenuse eraldamise ja hajutatud registri uute plokkide moodustamise, samuti sertifitseerimiskeskuse kasutamise ja osalejate autoriseerimise kaudu.
Minu artikkel on osa Hyperledger Fabricut käsitlevast artiklite seeriast, mille raames kirjeldame süsteemiprojekti ülikooli astuvate üliõpilaste registreerimiseks.
Hyperledger Fabricu üldine arhitektuur
Hyperledger Fabric on hajutatud plokiahela võrk, mis koosneb erinevatest funktsionaalsetest komponentidest, mis on installitud võrgusõlmedesse. Hyperledger Fabrici komponendid on Dockeri konteinerid, mida saab DockerHubist vabalt alla laadida. Hyperledger Fabricit saab käivitada ka Kubernetese keskkonnas.
Nutikate lepingute (Hyperledger Fabricu kontekstis ahelkood) kirjutamiseks kasutasime Golangi (kuigi Hyperledger Fabric võimaldab kasutada ka teisi keeli). Kohandatud rakenduse arendamiseks kasutasime meie puhul Node.js-i koos vastava Hyperledger Fabric SDK-ga.
Sõlmed täidavad äriloogikat (nutikas leping) - kettkoodi, salvestavad hajutatud registri oleku (pearaamatu andmed) ja täidavad muid platvormi süsteemiteenuseid. Sõlm on ainult loogiline üksus; samas füüsilises serveris võivad eksisteerida erinevad sõlmed. Palju olulisem on see, kuidas sõlmed on rühmitatud (usaldusdomeen) ja milliste plokiahela võrgu funktsioonidega need on seotud.
Üldine arhitektuur näeb välja selline:
Pilt 1. Hyperledgeri kanga üldarhitektuur
Kasutajarakendus (Submitting Client) on rakendus, millega kasutajad töötavad plokiahela võrguga. Töötamiseks peate olema volitatud ja teil peavad olema võrgus erinevat tüüpi toimingute jaoks sobivad õigused.
Eakaaslased on mitmes rollis:
- Endorsing Peer on sõlm, mis simuleerib tehingu täitmist (käidab nutika lepingu koodi). Pärast nutika lepingu kontrollimist ja täitmist tagastab sõlm kliendirakendusele täitmise tulemused koos allkirjaga.
- Tellimisteenus on mitmel sõlmel hajutatud teenus, mida kasutatakse hajutatud registri uute plokkide genereerimiseks ja tehingute täitmiseks järjekorra loomiseks. Tellimisteenus ei lisa registrisse uusi plokke (see funktsioon on jõudluse parandamiseks teisaldatud kausta Comitting Peers).
- Siduv partner on sõlm, mis sisaldab hajutatud registrit ja lisab registrisse uusi plokke (mille genereeris tellimisteenus). Kõik siduvad partnerid sisaldavad hajutatud pearaamatu kohalikku koopiat. Partneri sidumine kontrollib enne uue ploki kohalikku lisamist kõigi ploki sees olevate tehingute kehtivust.
Kinnituspoliitika on tehingu kehtivuse kontrollimise poliitika. Need poliitikad määratlevad nõutud sõlmede komplekti, millel tuleb nutikas leping täita, et tehing tunnistataks kehtivaks.
Hajutatud register – Lerger – koosneb kahest osast: WolrldState (nimetatakse ka State DataBase’iks) ja BlockChain.
BlockChain on plokkide kett, mis salvestab kirjed kõigist hajutatud registriobjektides toimunud muudatustest.
WolrldState on hajutatud pearaamatu komponent, mis salvestab kõigi hajutatud pearaamatuobjektide praegused (lõppserva) väärtused.
WorldState on andmebaas, põhiversioonis - LevelDB või keerulisem - CouchDB, mis sisaldab võtme-väärtuste paare, näiteks: Eesnimi - Ivan, Perekonnanimi - Ivanov, süsteemis registreerimiskuupäev - 12.12.21 , sünniaeg - 17.12.1961 jne. WorldState ja hajutatud register peavad olema järjepidevad kõigi antud kanalis osalejate vahel.
Kuna Hyperledger Fabric on võrk, milles kõik osalejad on teada ja autentitud, kasutab see spetsiaalset sertifitseerimisasutust – CA (Certification Authority). CA töötab X.509 standardil ja avaliku võtme infrastruktuuril – PKI-l.
Liikmeteenus on teenus, mille kaudu liikmed kontrollivad objekti kuulumist konkreetsesse organisatsiooni või kanalisse.
Tehing – enamikul juhtudel on uute andmete kirjutamine hajutatud registrisse.
Tehakse ka tehinguid kanalite ehk nutikate lepingute loomiseks. Tehingu algatab kasutajarakendus ja see lõpeb kirjega hajutatud pearaamatus.
Kanal on suletud alamvõrk, mis koosneb kahest või enamast plokiahelavõrgu osalejast, mis on loodud konfidentsiaalsete tehingute tegemiseks piiratud, kuid teadaoleva osalejate ringis. Kanali määravad osalejad, selle hajutatud register, nutikad lepingud, tellimisteenus, WorldState. Igal kanalis osalejal peab olema kanalile juurdepääsuõigus ja õigus teha erinevat tüüpi tehinguid. Autoriseerimine toimub liikmeteenust kasutades.
Tüüpiline tehingu täitmise stsenaarium
Järgmisena tahaksin rääkida tüüpilisest tehingute täitmise stsenaariumist, kasutades näitena meie projekti.
Siseprojekti raames lõime võrgustiku Hyperledger Fabric, mis on mõeldud ülikoolidesse sisenevate üliõpilaste registreerimiseks ja arveldamiseks. Meie võrgustik koosneb kahest organisatsioonist, mis kuuluvad ülikoolidesse A ja ülikoolidesse B. Iga organisatsioon sisaldab kliendirakendust, samuti oma pühendumist ja heakskiitmist. Kasutame ka tavateenuseid Tellimisteenus, Liikmeteenus ja Sertifitseerimiskeskus.
1) Tehingu algatamine
Kasutajarakendus, mis kasutab Hyperledger Fabric SDK-d, algatab tehingupäringu ja saadab päringu nutikate lepingutega sõlmedele. Taotlus võib olla hajutatud registrist (pearaamatust) muutmine või lugemine. Kui võtta arvesse meie ülikooli üliõpilaste raamatupidamise testsüsteemi konfiguratsiooni näidet, saadab kliendirakendus tehingupäringu ülikoolide A ja B sõlmedele, mis sisalduvad kutsutud nutika lepingu kinnituspoliitikas. Sõlm A on ülikoolis asuv sõlm, mis registreerib sissetuleva üliõpilase, ja sõlm B on sõlm, mis asub teises ülikoolis. Tehingu salvestamiseks hajusregistrisse on vajalik, et kõik sõlmed, mis äriloogika järgi peavad tehingu heaks kiitma, täidaksid edukalt sama tulemusega nutikaid lepinguid. Sõlme A kasutajarakendus, mis kasutab Hyperledger Fabric SDK tööriistu, hangib kinnituspoliitika ja õpib, millistele sõlmedele tehingutaotlus saata. See on taotlus konkreetse nutika lepingu (ahelkoodifunktsioon) käivitamiseks, et lugeda või kirjutada teatud andmed hajutatud registrisse. Tehniliselt kasutab kliendi SDK vastavat funktsiooni, mille API-le edastatakse teatud objekt koos tehinguparameetritega ning lisab ka kliendi allkirja ning saadab need andmed protokollipuhvri kaudu üle gRPC vastavatesse sõlmedesse (endosing peer).
Pilt 2. Tehingu algatamine
2) Nutilepingu täitmine
Sõlmed (Endorsing Peers), olles saanud tehingu sooritamise palve, kontrollivad kliendi allkirja ja kui kõik on korras, võtavad päringuandmetega objekti ning käivitavad nutika lepingu täitmise simulatsiooni (ahelkoodi funktsioon). need andmed. Nutikas leping on tehingu äriloogika, teatud tingimuste ja juhiste kogum (meie puhul on see õpilase kontrollimine, kas tegemist on uue üliõpilasega või on ta juba registreerunud, vanuse kontrollimine jne). Nutilepingu täitmiseks vajate ka WorldState'i andmeid. Nutika lepingu simuleerimise tulemusena kinnitava partneriga saadakse kaks andmekogumit – lugemiskomplekt ja kirjutamiskomplekt. Read Set ja Write Set on WorldState'i algsed ja uued väärtused. (uus – targa lepingu simulatsiooni käigus saadud mõttes).
Pilt 3. Nutilepingu täitmine
3) Andmete tagastamine kliendirakendusse
Pärast nutika lepingu simulatsiooni läbiviimist tagastab Endorsing Peers kliendirakendusele oma sertifikaadiga allkirjastatud algandmed ja simulatsiooni tulemuse ning RW-komplekti. Selles etapis hajutatud registris muudatusi ei toimu. Kliendirakendus kontrollib toetava kaaslase allkirja ning võrdleb ka saadetud algseid tehinguandmeid ja tagastatud andmeid (st kontrollib, kas tehingut simuleeritud algandmed on moonutatud). Kui tehing oli ainult registrist andmete lugemiseks, siis kliendirakendus saab vastavalt sellele vajaliku lugemiskomplekti ja see viib tavaliselt tehingu edukalt lõpule ilma hajutatud registrit muutmata. Tehingu puhul, mis peab registris andmeid muutma, kontrollib kliendirakendus täiendavalt Kinnituspoliitika rakendamist. Võimalik, et klientrakendus ei kontrolli kinnituspoliitika täitmise tulemust, kuid Hyperledger Fabrici platvorm näeb sel juhul ette sõlmede (Committing Peers) poliitikate kontrollimise tehingu registrisse lisamise etapis.
Pilt 4. Andmete tagastamine klientrakendusse
4) RW-komplektide saatmine tellimiskaaslastele
Kliendirakendus saadab tehingu koos kaasnevate andmetega Tellimisteenusele. See hõlmab RW komplekti, kaaslaste toetamise allkirju ja kanali ID-d.
Tellimisteenus – nimest lähtuvalt on selle teenuse põhifunktsiooniks laekuvate tehingute õiges järjekorras korraldamine. Nagu ka hajutatud registri uue ploki moodustamine ja uute genereeritud plokkide garanteeritud kohaletoimetamine kõikidesse siduvatesse sõlmedesse, tagades seeläbi andmete järjepidevuse kõigis hajutatud registrit sisaldavates sõlmedes (Committing peer). Samas ei muuda Tellimisteenus ise kuidagi registrit. Tellimisteenus on süsteemi oluline komponent, seega on see mitme sõlme klaster. Tellimisteenus ei kontrolli tehingu kehtivust, vaid lihtsalt aktsepteerib teatud kanaliidentifikaatoriga tehingut, korraldab sissetulevad tehingud kindlas järjekorras ja moodustab neist uued hajutatud registri plokid. Üks tellimisteenus võib teenindada mitut kanalit korraga. Tellimisteenus sisaldab Kafka klastrit, mis hoiab õiget (muutmatut) tehingujärjekorda (vt punkt 7).
Pilt 5. RW komplektide saatmine tellimiskaaslastele
5) Loodud plokkide saatmine siduvale partnerile
Tellimisteenuses genereeritud plokid edastatakse (edastatakse) kõikidesse võrgusõlmedesse. Iga sõlm, olles saanud uue ploki, kontrollib selle vastavust kinnituspoliitikale, kontrollib, et kõik toetavad partnerid said nutika lepingu simulatsiooni tulemusena sama tulemuse (kirjutuskomplekt) ning kontrollib ka, kas algväärtused on muudetud (st Read Set – nutilepingu poolt WorldState'ilt loetud andmed) alates tehingu algatamise hetkest. Kui kõik tingimused on täidetud, märgitakse tehing kehtivaks, vastasel juhul saab tehing staatuse kehtetu.
Pilt 6. Loodud plokkide saatmine siduvale partnerile
6) Ploki lisamine registrisse
Iga sõlm lisab tehingu oma hajutatud registri kohalikku koopiasse ja kui tehing on kehtiv, rakendatakse Write Set WorldState'ile (praegune olek) ja vastavalt sellele objektide uued väärtused, mida rakendus mõjutas. tehing on kirjas. Kui tehing sai luba, mis ei kehti (näiteks toimus kaks tehingut samade objektidega samas plokis, siis üks tehingutest osutub kehtetuks, kuna algseid väärtusi on juba teine muutnud tehing). See tehing lisatakse ka kehtetu märgiga hajutatud pearaamatusse, kuid selle tehingu kirjutamiskomplekti ei rakendata praegusele maailmariigile ja see ei muuda vastavalt tehingus osalevaid objekte. Pärast seda saadetakse kasutajarakendusele teade, et tehing on hajutatud registrisse jäädavalt lisatud ning tehingu olek ehk kas see kehtib või mitte...
Pilt 7. Ploki lisamine registrisse
TELLIMISTEENUS
Tellimisteenus koosneb Kafka klastrist koos vastavate ZooKeeperi sõlmede ja tellimisteenuse sõlmedega (OSN), mis asuvad Tellimisteenuse klientide ja Kafka klastri vahel. Kafka klaster on hajutatud, tõrketaluv voo (sõnumite) haldusplatvorm. Iga Kafka kanal (teema) on muutumatu kirjete jada, mis toetab ainult uue kirje lisamist (olemasolevat pole võimalik kustutada). Teema struktuuri illustratsioon on näidatud allpool. Just seda Kafka omadust kasutatakse plokiahela platvormi ehitamiseks.
võetud saidilt kafka.apache.org
- Pilt 8. Teenuse tellimise teema ülesehitus*
Kasulikud lingid
Tänusõnad
Tahaksin avaldada sügavat tänu oma kolleegidele abi eest selle artikli ettevalmistamisel:
Nikolai Marin
Igor Khapov
Dmitri Gorbatšov
Aleksander Zemtsov
Jekaterina Guseva
Allikas: www.habr.com