Blockchain Platformo por la Entrepreno
Bonan posttagmezon, karaj legantoj, mia nomo estas Nikolay Nefedov, mi estas teknika specialisto ĉe IBM, en ĉi tiu artikolo mi ŝatus prezenti vin al la blokĉena platformo - Hyperledger Fabric. La platformo estas desegnita por konstrui entreprenajn komercajn aplikaĵojn. La nivelo de la artikolo estas por nepreparitaj legantoj kun baza scio pri IT-teknologioj.
Hyperledger Fabric estas malfermfonta projekto, unu el la branĉoj de la malfermfonteca Hyperledger-projekto, konsorcio de la Linukso-Fondaĵo. Hyperledger Fabric estis origine komencita fare de Digital Assets kaj IBM. La ĉefa trajto de la platformo Hyperledger Fabric estas ĝia fokuso pri entreprena uzo. Tial, la platformo estis evoluigita konsiderante la altan rapidon de transakcioj kaj ilian malaltan koston, same kiel la identigon de ĉiuj partoprenantoj. Ĉi tiuj avantaĝoj estas atingitaj per la disiĝo de la transakcia kontrola servo kaj la formado de novaj blokoj de la distribuita registro, same kiel la uzo de atesta centro kaj rajtigo de partoprenantoj.
Mia artikolo estas parto de serio de artikoloj pri Hyperledger Fabric, ene de kiuj ni priskribas sisteman projekton por registri studentojn enirantajn universitaton.
Ĝenerala arkitekturo de Hyperledger Fabric
Hyperledger Fabric estas distribuita blokĉena reto konsistanta el diversaj funkciaj komponantoj, kiuj estas instalitaj sur retaj nodoj. Hyperledger Fabric-komponentoj estas Docker-ujoj, kiuj povas esti libere elŝutitaj de DockerHub. Hyperledger Fabric ankaŭ povas ruliĝi en Kubernetes-medio.
Por skribi inteligentajn kontraktojn (ĉenkodo en la kunteksto de Hyperledger Fabric), ni uzis Golang (kvankam Hyperledger Fabric permesas la uzon de aliaj lingvoj). Por disvolvi kutiman aplikaĵon, en nia kazo, ni uzis Node.js kun la responda Hyperledger Fabric SDK.
La nodoj ekzekutas komercan logikon (inteligenta kontrakto) - ĉenkodo, konservas la staton de la distribuita registro (registraj datumoj) kaj ekzekutas aliajn sistemajn servojn de la platformo. Nodo estas nur logika unuo; malsamaj nodoj povas ekzisti sur la sama fizika servilo. Multe pli grava estas kiel la nodoj estas grupigitaj (Fidata domajno) kaj kun kiaj funkcioj de la blokĉena reto ili estas asociitaj.
La ĝenerala arkitekturo aspektas jene:
Bildo 1. Ĝenerala Arkitekturo de Hyperledger Fabric
Uzanta aplikaĵo (Submitting Client) estas aplikaĵo per kiu uzantoj laboras kun la blokĉena reto. Por labori, vi devas esti rajtigita kaj havi la taŭgajn rajtojn por diversaj specoj de agoj en la reto.
Kunuloj venas en pluraj roloj:
- Endorsing Peer estas nodo, kiu simulas la plenumon de transakcio (ekzekutas la inteligentan kontraktokodon). Post konfirmo kaj plenumo de la inteligenta kontrakto, la nodo resendas la ekzekutrezultojn al la klienta aplikaĵo kune kun ĝia subskribo.
- Menda Servo estas distribuita servo sur pluraj nodoj, uzata por generi novajn blokojn de la distribuita registro kaj krei vicon por la ekzekuto de transakcioj. Mendservo ne aldonas novajn blokojn al la registro (Ĉi tiu funkcio estis movita al Committing Peers por plibonigi rendimenton).
- Committing Peer estas nodo kiu enhavas distribuitan registron kaj aldonas novajn blokojn al la registro (kiuj estis generitaj de la Menda Servo). Ĉiuj Committing Peers enhavas lokan kopion de la distribuita ĉeflibro. Committing Peer kontrolas ĉiujn transakciojn ene de la bloko pri valideco antaŭ ol aldoni novan blokon loke.
Apoga Politiko estas la politiko por kontroli la validecon de transakcio. Ĉi tiuj politikoj difinas la postulatan aron de nodoj sur kiuj la inteligenta kontrakto devas esti efektivigita por ke la transakcio estu rekonita kiel valida.
La distribuita registro - Lerger - konsistas el du partoj: WolrldState (ankaŭ nomata Ŝtata Datumaro) kaj BlockChain.
BlockChain estas ĉeno de blokoj, kiu stokas registrojn de ĉiuj ŝanĝoj okazintaj al distribuitaj registraj objektoj.
WolrldState estas distribuita ĉeflibrokomponento, kiu stokas la nunajn (tranĉajn) valorojn de ĉiuj distribuitaj ĉeflibrobjektoj.
WorldState estas datumbazo, en la baza versio - LevelDB aŭ pli kompleksa - CouchDB, kiu enhavas ŝlosilvalorajn parojn, ekzemple: Antaŭnomo - Ivan, Familia nomo - Ivanov, registriĝa dato en la sistemo - 12.12.21/17.12.1961/XNUMX , naskiĝdato - XNUMX/XNUMX/XNUMX, ktp. WorldState kaj la distribuita registro devas esti konsekvencaj inter ĉiuj partoprenantoj en difinita kanalo.
Ĉar Hyperledger Fabric estas reto en kiu ĉiuj partoprenantoj estas konataj kaj aŭtentikigitaj, ĝi uzas dediĉitan atestan aŭtoritaton - CA (Atestila Aŭtoritato). CA funkcias surbaze de la X.509-normo kaj publika ŝlosila infrastrukturo - PKI.
Membra Servo estas servo per kiu membroj kontrolas ke objekto apartenas al aparta organizo aŭ kanalo.
Transakcio - en la plej multaj kazoj, skribas novajn datumojn al distribuita registro.
Estas ankaŭ transakcioj por la kreado de kanaloj aŭ inteligentaj kontraktoj. La transakcio estas iniciatita de la uzantaplikaĵo kaj finiĝas kun rekordo en la distribuita ĉeflibro.
Kanalo estas fermita subreto konsistanta el du aŭ pli da blokĉenaj retaj partoprenantoj, dizajnitaj por fari konfidencajn transakciojn ene de limigita sed konata cirklo de partoprenantoj. La kanalo estas determinita de la partoprenantoj, ĝia distribuita registro, inteligentaj kontraktoj, Mendservo, WorldState. Ĉiu kanalpartoprenanto devas esti rajtigita por aliri la kanalon kaj havi la rajton fari diversajn specojn de transakcioj. Rajtigo estas farita per la Membriĝa Servo.
Tipa transakcia ekzekutscenaro
Poste, mi ŝatus paroli pri tipa transakcia ekzekutscenaro uzante nian projekton kiel ekzemplon.
Kiel parto de nia interna projekto, ni kreis la Hyperledger Fabric-reton, kiu estas desegnita por registri kaj kontentigi studentojn enirantajn universitatojn. Nia reto konsistas el du organizoj apartenantaj al Universitato A kaj Universitato B. Ĉiu organizo enhavas klientan aplikaĵon, same kiel sian propran Committing and Endorsing Peer. Ni ankaŭ uzas la komunajn servojn Mendanta Servo, Membra Servo kaj Atestiga Aŭtoritato.
1) Komenco de Transakcio
Uzanta aplikaĵo, uzante la Hyperledger Fabric SDK, iniciatas transakcian peton kaj sendas la peton al nodoj kun inteligentaj kontraktoj. La peto povas esti ŝanĝi aŭ legi el distribuita registro (Ledger). Se ni konsideras ekzemplon de nia testa sistema agordo por kontado por universitataj studentoj, la klienta aplikaĵo sendas transakcian peton al la nodoj de universitatoj A kaj B, kiuj estas inkluzivitaj en la Apogopolitiko de la nomita inteligenta kontrakto. Nodo A estas nodo kiu situas ĉe la universitato kiu registras la envenantan studenton, kaj nodo B estas nodo kiu situas ĉe alia universitato. Por ke transakcio estu konservita al distribuita registro, necesas, ke ĉiuj nodoj, kiuj laŭ komerca logiko devas aprobi la transakcion, sukcese plenumu inteligentajn kontraktojn kun la sama rezulto. La nodo Uzanta aplikaĵo, uzante la ilojn de Hyperledger Fabric SDK, akiras la politikon de Apogo kaj lernas al kiuj nodoj sendi transakcian peton. Ĉi tio estas peto por alvoki specifan inteligentan kontrakton (ĉenkoda funkcio) por legi aŭ skribi certajn datumojn al distribuita registro. Teknike, la kliento SDK uzas la respondan funkcion, kies API estas preterpasita certa objekto kun transakciaj parametroj, kaj ankaŭ aldonas klientan subskribon kaj sendas ĉi tiujn datumojn per protokola bufro super gRPC al la taŭgaj nodoj (aprobantaj samuloj).
Bildo 2. Komencante Transakcion
2) Ekzekuto de inteligenta kontrakto
Nodoj (Endorsing Peers), ricevinte peton fari transakcion, kontrolas la klientan subskribon kaj se ĉio estas en ordo, ili prenas objekton kun la petaj datumoj kaj faras simuladon de la ekzekuto de inteligenta kontrakto (ĉenkoda funkcio) kun ĉi tiuj datumoj. Saĝa kontrakto estas la komerca logiko de transakcio, certa aro de kondiĉoj kaj instrukcioj (en nia kazo, ĉi tio estas konfirmo de studento, ĉu ĉi tio estas nova studento, aŭ ĉu li jam registris, aĝkonfirmo ktp.). Por efektivigi la inteligentan kontrakton, vi ankaŭ bezonos datumojn de WorldState. Kiel rezulto de simulado de inteligenta kontrakto sur la Endorsing-kunulo, du aroj da datumoj estas akiritaj - Legu Aron kaj Skribu Aron. Lega Aro kaj Skriba Aro estas la originalaj kaj novaj valoroj de WorldState. (nova - en la senco akirita dum la simulado de inteligenta kontrakto).
Bildo 3. Ekzekuto de inteligenta kontrakto
3) Revenante datumojn al la klienta aplikaĵo
Post farado de simulado de la inteligenta kontrakto, Endorsing Peers resendas la originalajn datumojn kaj la rezulton de la simulado, same kiel la RW-Aron, subskribitan per sia atestilo al la klienta aplikaĵo. En ĉi tiu etapo, neniuj ŝanĝoj okazas en la distribuita registro. La klienta aplikaĵo kontrolas la subskribon de Endorsing Peer, kaj ankaŭ komparas la originajn transakciajn datumojn kiuj estis senditaj kaj la datumojn kiuj estis resenditaj (tio estas, ĝi kontrolas ĉu la originaj datumoj sur kiuj la transakcio estis simulita estis distorditaj). Se la transakcio estis nur por legi datumojn de la registro, tiam la klienta aplikaĵo sekve ricevas la necesan Legan Aron kaj ĉi tio kutime kompletigas la transakcion sukcese sen ŝanĝi la distribuitan registron. En la kazo de transakcio, kiu devas ŝanĝi datumojn en la registro, la klienta aplikaĵo aldone kontrolas la efektivigon de la Apoga politiko. Eblas, ke klienta aplikaĵo ne kontrolas la rezulton de ekzekuto de la Apoga Politiko, sed la platformo Hyperledger Fabric ĉi-kaze provizas por kontroli politikojn sur nodoj (Committing Peers) en la stadio de aldoni transakcion al la registro.
Bildo 4. Revenante datumojn al la klienta aplikaĵo
4) Sendante RW-arojn al Ordonantaj Samuloj
La klienta aplikaĵo sendas la transakcion kune kun akompanaj datumoj al la Mendado-servo. Ĉi tio inkluzivas la RW-Aron, Endorsing-kunulojn subskribojn, kaj la Kanalan ID.
Menda servo - surbaze de la nomo, la ĉefa funkcio de ĉi tiu servo estas aranĝi envenantajn transakciojn en la ĝusta ordo. Same kiel la formado de nova bloko de la distribuita registro kaj garantiita livero de novaj generitaj blokoj al ĉiuj Committing-nodoj, tiel certigante datuman konsistencon sur ĉiuj nodoj enhavantaj la distribuitan registron (Committing peers). Samtempe, la Mendoservo mem neniel ŝanĝas la registron. Menda Servo estas esenca komponanto de la sistemo, do ĝi estas aro de pluraj nodoj. La Menda Servo ne kontrolas la transakcion pri valideco, ĝi simple akceptas transakcion kun certa kanala identigilo, aranĝas envenantajn transakciojn en certa ordo kaj formas novajn blokojn de la distribuita registro de ili. Unu Menda Servo povas servi plurajn kanalojn samtempe. La Menda Servo inkluzivas Kafka-areton, kiu konservas la ĝustan (neŝanĝeblan) transakcian vicon (vidu Punkton 7).
Bildo 5. Sendante RW-arojn al Ordonantaj Samuloj
5) Sendante generitajn blokojn al Committing Peer
Blokoj generitaj en la Menda Servo estas elsenditaj (elsendo) al ĉiuj retaj nodoj. Ĉiu nodo, ricevinte novan blokon, kontrolas ĝin por konformeco al la Apoga Politiko, kontrolas, ke ĉiuj Apogantaj Samuloj ricevis la saman rezulton (Skriba Aro) kiel rezulto de la inteligenta kontrakto-simulado, kaj ankaŭ kontrolas ĉu la originalaj valoroj havas. ŝanĝita (tio estas, Read Set - datumoj legitaj de la inteligenta kontrakto de WorldState) ekde la momento, kiam la transakcio estis komencita. Se ĉiuj kondiĉoj estas plenumitaj, la transakcio estas markita kiel valida, alie, la transakcio ricevas la statuson nevalida.
Bildo 6. Sendante generitajn blokojn al Committing Peer
6) Aldonante blokon al la registro
Ĉiu nodo aldonas transakcion al sia loka kopio de la distribuita registro, kaj se la transakcio validas, tiam la Skriba Aro estas aplikata al la WorldState (nuna stato), kaj sekve, novaj valoroj de la objektoj tuŝitaj de la transakcio estas skribitaj. Se transakcio ricevis ĵetonon, kiu ne validas (ekzemple, du transakcioj okazis kun la samaj objektoj ene de la sama bloko, tiam unu el la transakcioj montriĝos nevalida, ĉar la originalaj valoroj jam estis ŝanĝitaj de alia. transakcio). Ĉi tiu transakcio ankaŭ estas aldonita al la distribuita ĉeflibro kun nevalida ĵetono, sed la Skriba Aro de ĉi tiu transakcio ne estas aplikata al la nuna WorldState kaj, sekve, ne ŝanĝas la objektojn partoprenantajn en la transakcio. Post ĉi tio, sciigo estas sendita al la uzanta aplikaĵo, ke la transakcio estas konstante aldonita al la distribuita registro, same kiel la stato de la transakcio, tio estas, ĉu ĝi validas aŭ ne...
Bildo 7. Aldonante blokon al la registro
MENDA SERVO
La Mendado-Servo konsistas el Kafka areto kun ekvivalentaj ZooKeeper-nodoj kaj Ordering Service Nodes (OSN), kiuj staras inter la Mendado-servklientoj kaj la Kafka Areto. Kafka areto estas distribuita, mistolerema flua (mesaĝo) administra platformo. Ĉiu kanalo (temo) en Kafka estas neŝanĝebla sekvenco de rekordoj, kiu nur subtenas aldoni novan rekordon (forigi ekzistantan ne eblas). Ilustraĵo de la temostrukturo estas montrita malsupre. Ĉi tiu posedaĵo de Kafka estas uzata por konstrui blokĉenan platformon.
prenita de kafka.apache.org
- Bildo 8. Menda Servo Temo Strukturo*
Utilaj ligiloj
Dankoj
Mi ŝatus esprimi mian profundan dankemon al miaj kolegoj pro ilia helpo en la preparado de ĉi tiu artikolo:
Nikolao Marin
Igor Ĥapov
Dmitrij Gorbaĉov
Aleksandro Zemcov
Jekaterina Guseva
fonto: www.habr.com