'N Blockchain-platform vir die onderneming
Goeiemiddag, liewe lesers, my naam is Nikolay Nefedov, ek is 'n tegniese spesialis by IBM, in hierdie artikel wil ek u graag voorstel aan die blokkettingplatform - Hyperledger Fabric. Die platform is ontwerp vir die bou van ondernemingsklas besigheidstoepassings. Die vlak van die artikel is vir onvoorbereide lesers met basiese kennis van IT-tegnologieë.
Hyperledger Fabric is 'n oopbronprojek, een van die vertakkings van die oopbron Hyperledger-projek, 'n konsortium van die Linux-stigting. Hyperledger Fabric is oorspronklik deur Digital Assets en IBM begin. Die hoofkenmerk van die Hyperledger Fabric-platform is die fokus daarvan op ondernemingsgebruik. Daarom is die platform ontwikkel met inagneming van die hoë spoed van transaksies en hul lae koste, sowel as die identifikasie van alle deelnemers. Hierdie voordele word bereik deur die skeiding van die transaksieverifikasiediens en die vorming van nuwe blokke van die verspreide register, sowel as die gebruik van 'n sertifiseringsentrum en magtiging van deelnemers.
My artikel is deel van 'n reeks artikels oor Hyperledger Fabric, waarbinne ons 'n stelselprojek beskryf vir die opname van studente wat 'n universiteit betree.
Algemene argitektuur van Hyperledger Fabric
Hyperledger Fabric is 'n verspreide blokkettingnetwerk wat bestaan uit verskeie funksionele komponente wat op netwerknodes geïnstalleer is. Hyperledger Fabric-komponente is Docker-houers wat vrylik van DockerHub afgelaai kan word. Hyperledger Fabric kan ook in 'n Kubernetes-omgewing uitgevoer word.
Om slim kontrakte te skryf (kettingkode in die konteks van Hyperledger Fabric), het ons Golang gebruik (hoewel Hyperledger Fabric die gebruik van ander tale toelaat). Om 'n pasgemaakte toepassing te ontwikkel, het ons in ons geval Node.js met die ooreenstemmende Hyperledger Fabric SDK gebruik.
Die nodusse voer besigheidslogika (slimkontrak) uit - kettingkode, stoor die toestand van die verspreide register (grootboekdata) en voer ander stelseldienste van die platform uit. 'n Nodus is slegs 'n logiese eenheid; verskillende nodusse kan op dieselfde fisiese bediener bestaan. Veel belangriker is hoe die nodusse gegroepeer word (Trusted domain) en watter funksies van die blokkettingnetwerk waarmee hulle geassosieer word.
Die algemene argitektuur lyk soos volg:
Foto 1. Algemene argitektuur van Hyperledger Fabric
Gebruikerstoepassing (Submitting Client) is 'n toepassing waarmee gebruikers met die blokkettingnetwerk werk. Om te werk, moet jy gemagtig wees en die toepaslike regte hê vir verskeie soorte aksies op die netwerk.
Eweknieë kom in verskeie rolle in:
- Endossing Peer is 'n nodus wat die uitvoering van 'n transaksie simuleer (voer die slimkontrakkode uit). Na verifikasie en uitvoering van die slim kontrak, stuur die nodus die uitvoeringsresultate terug na die kliënttoepassing saam met sy handtekening.
- Besteldiens is 'n verspreide diens op verskeie nodusse, wat gebruik word om nuwe blokke van die verspreide register te genereer en 'n tou te skep vir die uitvoering van transaksies. Besteldiens voeg nie nuwe blokke by die register nie (Hierdie kenmerk is geskuif na Committing Peers om werkverrigting te verbeter).
- Committing Peer is 'n nodus wat 'n verspreide register bevat en nuwe blokke by die register voeg (wat deur die Besteldiens gegenereer is). Alle verbindende eweknieë bevat 'n plaaslike kopie van die verspreide grootboek. Commiting Peer kontroleer alle transaksies binne die blok vir geldigheid voordat 'n nuwe blok plaaslik bygevoeg word.
Endossementbeleid is die beleid om die geldigheid van 'n transaksie na te gaan. Hierdie beleide definieer die vereiste stel nodusse waarop die slimkontrak uitgevoer moet word sodat die transaksie as geldig erken kan word.
Die verspreide register - Lerger - bestaan uit twee dele: WolrldState (ook genoem State DataBase) en BlockChain.
BlockChain is 'n ketting van blokke wat rekords stoor van alle veranderinge wat plaasgevind het aan verspreide registervoorwerpe.
WolrldState is 'n verspreide grootboekkomponent wat die huidige (voorpunt) waardes van alle verspreide grootboekvoorwerpe stoor.
WorldState is 'n databasis, in die basiese weergawe - LevelDB of 'n meer komplekse een - CouchDB, wat sleutel-waarde pare bevat, byvoorbeeld: Voornaam - Ivan, Van - Ivanov, registrasiedatum in die stelsel - 12.12.21/17.12.1961/XNUMX , geboortedatum - XNUMX/XNUMX/XNUMX, ens. WorldState en die verspreide register moet konsekwent wees tussen alle deelnemers in 'n gegewe kanaal.
Aangesien Hyperledger Fabric 'n netwerk is waarin alle deelnemers bekend en gewaarmerk is, gebruik dit 'n toegewyde sertifiseringsowerheid - CA (Sertifiseringsowerheid). CA werk gebaseer op die X.509 standaard en publieke sleutel infrastruktuur - PKI.
Lidmaatskapdiens is 'n diens waardeur lede verifieer dat 'n voorwerp aan 'n spesifieke organisasie of kanaal behoort.
'n Transaksie - in die meeste gevalle is die skryf van nuwe data na 'n verspreide register.
Daar is ook transaksies vir die skep van kanale of slim kontrakte. Die transaksie word deur die gebruikerstoepassing geïnisieer en eindig met 'n rekord in die verspreide grootboek.
'n Kanaal is 'n geslote subnetwerk wat uit twee of meer blokkettingnetwerkdeelnemers bestaan, wat ontwerp is om vertroulike transaksies binne 'n beperkte maar bekende kring van deelnemers uit te voer. Die kanaal word bepaal deur die deelnemers, sy verspreide register, slim kontrakte, Besteldiens, WorldState. Elke kanaaldeelnemer moet gemagtig wees om toegang tot die kanaal te verkry en die reg hê om verskeie tipes transaksies uit te voer. Magtiging word uitgevoer deur die lidmaatskapdiens te gebruik.
Tipiese transaksie uitvoering scenario
Vervolgens wil ek praat oor 'n tipiese transaksie-uitvoering scenario met behulp van ons projek as 'n voorbeeld.
As deel van ons interne projek het ons die Hyperledger Fabric-netwerk geskep, wat ontwerp is om te registreer en rekening te hou met studente wat universiteite betree. Ons netwerk bestaan uit twee organisasies wat aan Universiteit A en Universiteit B behoort. Elke organisasie bevat 'n kliëntaansoek, sowel as sy eie Committing and Endossing Peer. Ons gebruik ook die algemene dienste besteldiens, lidmaatskapdiens en sertifiseringsowerheid.
1) Aanvang van transaksie
'n Gebruikertoepassing, wat die Hyperledger Fabric SDK gebruik, begin 'n transaksieversoek en stuur die versoek na nodusse met slim kontrakte. Die versoek kan wees om te verander of uit 'n verspreide register (Grootboek) te lees. As ons 'n voorbeeld van ons toetsstelselkonfigurasie vir rekeningkunde vir universiteitstudente oorweeg, stuur die kliënttoepassing 'n transaksieversoek na die nodusse van universiteite A en B, wat ingesluit is in die Endossementbeleid van die genoem slimkontrak. Nodus A is 'n nodus wat by die universiteit geleë is wat die inkomende student registreer, en nodus B is 'n nodus wat by 'n ander universiteit geleë is. Om 'n transaksie in 'n verspreide register te kan stoor, is dit nodig dat alle nodusse wat volgens besigheidslogika die transaksie moet goedkeur, slim kontrakte suksesvol uitvoer met dieselfde resultaat. Die nodus 'n Gebruikertoepassing, wat die Hyperledger Fabric SDK-nutsgoed gebruik, verkry die Endossementbeleid en leer na watter nodusse 'n transaksieversoek moet stuur. Dit is 'n versoek om 'n spesifieke slim kontrak (kettingkodefunksie) op te roep om sekere data na 'n verspreide register te lees of te skryf. Tegnies gebruik die kliënt SDK die ooreenstemmende funksie, waarvan die API 'n sekere objek met transaksieparameters deurgegee word, en voeg ook 'n kliënthandtekening by en stuur hierdie data via protokolbuffer oor gRPC na die toepaslike nodusse (onderskryf eweknieë).
Foto 2. Inisieer 'n transaksie
2) Uitvoering van slim kontrak
Nodes (Endosserende eweknieë), nadat hulle 'n versoek ontvang het om 'n transaksie uit te voer, gaan die kliënthandtekening na en as alles in orde is, neem hulle 'n voorwerp met die versoekdata en voer 'n simulasie uit van die uitvoering van 'n slim kontrak (kettingkodefunksie) met hierdie data. 'n Slim kontrak is die besigheidslogika van 'n transaksie, 'n sekere stel voorwaardes en instruksies (in ons geval is dit verifikasie van 'n student, is dit 'n nuwe student, of is hy reeds geregistreer, ouderdomsverifikasie, ens.). Om die slim kontrak uit te voer, sal jy ook data van WorldState benodig. As gevolg van die simulering van 'n slim kontrak op die Onderskryf-eweknie, word twee stelle data verkry – Leesstel en Skryfstel. Leesstel en Skryfstel is die oorspronklike en nuwe WorldState-waardes. (nuut – in die sin verkry tydens die simulasie van 'n slim kontrak).
Prent 3. Uitvoering van 'n slim kontrak
3) Gee data terug na die kliënttoepassing
Nadat 'n simulasie van die slim kontrak uitgevoer is, stuur Endosserende Eweknieë die oorspronklike data en die resultaat van die simulasie, sowel as die RW-stel, onderteken deur hul sertifikaat aan die kliënttoepassing terug. Op hierdie stadium vind geen veranderinge in die verspreide register plaas nie. Die kliënttoepassing kontroleer die Endosserende Eweknie-handtekening, en vergelyk ook die oorspronklike transaksiedata wat gestuur is en die data wat teruggestuur is (dit wil sê, dit kontroleer of die oorspronklike data waarop die transaksie gesimuleer is, verdraai is). As die transaksie slegs vir die lees van data uit die register was, ontvang die kliënttoepassing dienooreenkomstig die nodige Leesstel en dit voltooi gewoonlik die transaksie suksesvol sonder om die verspreide register te verander. In die geval van 'n transaksie wat data in die register moet verander, kontroleer die kliënttoepassing ook die implementering van die Endossementbeleid. Dit is moontlik dat 'n kliënttoepassing nie die resultaat van die uitvoering van die Endossementbeleid nagaan nie, maar die Hyperledger Fabric-platform maak in hierdie geval voorsiening vir die kontrolering van beleide op nodusse (Committing Peers) in die stadium van die byvoeging van 'n transaksie by die register.
Prent 4. Gee data terug na die kliënttoepassing
4) Stuur RW-stelle na Bestel-eweknieë
Die kliënttoepassing stuur die transaksie saam met gepaardgaande data na die Besteldiens. Dit sluit die RW-stel, Onderskryf eweknie-handtekeninge en die kanaal-ID in.
Besteldiens – gebaseer op die naam, is die hooffunksie van hierdie diens om inkomende transaksies in die korrekte volgorde te reël. Sowel as die vorming van 'n nuwe blok van die verspreide register en gewaarborgde aflewering van nuwe gegenereerde blokke aan alle Commiting nodusse, om sodoende datakonsekwentheid te verseker op alle nodusse wat die verspreide register bevat (Committing peers). Terselfdertyd verander die besteldiens self nie die register op enige manier nie. Besteldiens is 'n belangrike komponent van die stelsel, so dit is 'n groep van verskeie nodusse. Die Besteldiens kontroleer nie die transaksie vir geldigheid nie, dit aanvaar bloot 'n transaksie met 'n sekere kanaalidentifiseerder, reël inkomende transaksies in 'n sekere volgorde en vorm nuwe blokke van die verspreide register van hulle. Een besteldiens kan verskeie kanale gelyktydig bedien. Die Besteldiens sluit 'n Kafka-groepering in, wat die korrekte (onveranderlike) transaksietou handhaaf (sien punt 7).
Prent 5. Stuur RW-stelle na Bestel-eweknieë
5) Stuur gegenereerde blokke na Committing Peer
Blokke wat in die Besteldiens gegenereer word, word na alle netwerknodusse oorgedra (uitgesaai). Elke nodus, nadat hy 'n nuwe blok ontvang het, kontroleer dit vir voldoening aan die endosseringsbeleid, kontroleer dat alle endosserende eweknieë dieselfde resultaat (skryfstel) as gevolg van die slimkontraksimulasie ontvang het, en kontroleer ook of die oorspronklike waardes het verander (dit wil sê Read Set - data gelees deur die slim kontrak van WorldState) vanaf die oomblik dat die transaksie geïnisieer is. As aan alle voorwaardes voldoen word, word die transaksie as geldig gemerk, anders ontvang die transaksie die status ongeldig.
Prent 6. Stuur gegenereerde blokke na Committing Peer
6) Voeg 'n blok by die register
Elke nodus voeg 'n transaksie by sy plaaslike kopie van die verspreide register, en as die transaksie geldig is, word die Skryfstel toegepas op die WorldState (huidige toestand), en dienooreenkomstig is nuwe waardes van voorwerpe wat deur die transaksie geraak is, geskryf. As 'n transaksie 'n teken ontvang het wat nie geldig is nie (byvoorbeeld twee transaksies het plaasgevind met dieselfde voorwerpe binne dieselfde blok, dan sal een van die transaksies nie geldig wees nie, aangesien die oorspronklike waardes reeds deur 'n ander transaksie verander is) . Hierdie transaksie word ook by die verspreide grootboek gevoeg met 'n ongeldige teken, maar die Skryfstel van hierdie transaksie word nie op die huidige Wêreldstaat toegepas nie en verander gevolglik nie die voorwerpe wat aan die transaksie deelneem nie. Hierna word 'n kennisgewing aan die gebruikerstoepassing gestuur dat die transaksie permanent by die verspreide register gevoeg is, sowel as die status van die transaksie, dit wil sê of dit geldig is of nie...
Prent 7. Voeg 'n blok by die register
BESTELLINGSDIENS
Die Besteldiens bestaan uit 'n Kafka-groepering met ooreenstemmende ZooKeeper-nodes en Besteldiensnodes (OSN), wat tussen die Besteldienskliënte en die Kafka-groepering staan. Kafka-groepering is 'n verspreide, foutverdraagsame vloei (boodskap) bestuursplatform. Elke kanaal (onderwerp) in Kafka is 'n onveranderlike reeks rekords wat slegs die byvoeging van 'n nuwe rekord ondersteun (dit is nie moontlik om 'n bestaande een uit te vee nie). 'n Illustrasie van die onderwerpstruktuur word hieronder getoon. Dit is hierdie eiendom van Kafka wat gebruik word om 'n blokkettingplatform te bou.
geneem van kafka.apache.org
- Prent 8. Besteldiensonderwerpstruktuur*
Nuttige skakels
Erkennings
Ek wil graag my diepe dankbaarheid teenoor my kollegas uitspreek vir hul hulp met die voorbereiding van hierdie artikel:
Nikolay Marin
Igor Khapov
Dmitri Gorbatsjof
Alexander Zemtsov
Ekaterina Guseva
Bron: will.com