Isang Blockchain Platform para sa Enterprise
Magandang hapon, mahal na mga mambabasa, ang pangalan ko ay Nikolay Nefedov, isa akong teknikal na espesyalista sa IBM, sa artikulong ito nais kong ipakilala sa iyo ang platform ng blockchain - Hyperledger Fabric. Ang platform ay dinisenyo para sa pagbuo ng enterprise-class na mga aplikasyon ng negosyo. Ang antas ng artikulo ay para sa mga hindi handa na mambabasa na may pangunahing kaalaman sa mga teknolohiyang IT.
Ang Hyperledger Fabric ay isang open-source na proyekto, isa sa mga sangay ng open source na Hyperledger project, isang consortium ng Linux Foundation. Ang Hyperledger Fabric ay orihinal na sinimulan ng Digital Assets at IBM. Ang pangunahing tampok ng platform ng Hyperledger Fabric ay ang pagtutok nito sa paggamit ng negosyo. Samakatuwid, ang platform ay binuo na isinasaalang-alang ang mataas na bilis ng mga transaksyon at ang kanilang mababang gastos, pati na rin ang pagkakakilanlan ng lahat ng mga kalahok. Ang mga pakinabang na ito ay nakamit sa pamamagitan ng paghihiwalay ng serbisyo sa pag-verify ng transaksyon at pagbuo ng mga bagong bloke ng ipinamamahaging pagpapatala, pati na rin ang paggamit ng isang sentro ng sertipikasyon at awtorisasyon ng mga kalahok.
Ang aking artikulo ay bahagi ng isang serye ng mga artikulo tungkol sa Hyperledger Fabric, kung saan inilalarawan namin ang isang proyekto ng system para sa pagtatala ng mga mag-aaral na pumapasok sa isang unibersidad.
Pangkalahatang arkitektura ng Hyperledger Fabric
Ang Hyperledger Fabric ay isang distributed blockchain network na binubuo ng iba't ibang functional na bahagi na naka-install sa mga network node. Ang mga bahagi ng Hyperledger Fabric ay mga container ng Docker na maaaring malayang ma-download mula sa DockerHub. Ang Hyperledger Fabric ay maaari ding patakbuhin sa isang Kubernetes na kapaligiran.
Upang magsulat ng mga matalinong kontrata (chaincode sa konteksto ng Hyperledger Fabric), ginamit namin ang Golang (bagaman pinapayagan ng Hyperledger Fabric ang paggamit ng iba pang mga wika). Upang bumuo ng custom na application, sa aming kaso, ginamit namin ang Node.js na may kaukulang Hyperledger Fabric SDK.
Ang mga node ay nagpapatakbo ng lohika ng negosyo (matalinong kontrata) - chaincode, nag-iimbak ng estado ng ipinamahagi na pagpapatala (data ng ledger) at nagsagawa ng iba pang mga serbisyo ng system ng platform. Ang isang node ay isang lohikal na yunit lamang; ang iba't ibang mga node ay maaaring umiral sa parehong pisikal na server. Ang mas mahalaga ay kung paano pinagsama-sama ang mga node (Trusted domain) at kung anong mga function ng blockchain network ang nauugnay sa kanila.
Ang pangkalahatang arkitektura ay ganito ang hitsura:
Larawan 1. Pangkalahatang Arkitektura ng Hyperledger Fabric
Ang application ng gumagamit (Pagsusumite ng Kliyente) ay isang application kung saan nagtatrabaho ang mga gumagamit sa network ng blockchain. Upang magtrabaho, dapat kang awtorisado at may mga naaangkop na karapatan para sa iba't ibang uri ng mga aksyon sa network.
Ang mga kapantay ay may ilang tungkulin:
- Ang pag-endorso ng Peer ay isang node na ginagaya ang pagpapatupad ng isang transaksyon (nagpapatupad ng smart contract code). Pagkatapos ng pag-verify at pagpapatupad ng matalinong kontrata, ibabalik ng node ang mga resulta ng pagpapatupad sa application ng kliyente kasama ang lagda nito.
- Ang Serbisyo ng Pag-order ay isang ipinamahagi na serbisyo sa ilang mga node, na ginagamit upang bumuo ng mga bagong bloke ng ipinamahagi na pagpapatala at lumikha ng isang pila para sa pagpapatupad ng mga transaksyon. Ang Serbisyo sa Pag-order ay hindi nagdaragdag ng mga bagong block sa registry (Ang feature na ito ay inilipat sa Committing Peers upang mapabuti ang performance).
- Ang Committing Peer ay isang node na naglalaman ng distributed registry at nagdaragdag ng mga bagong block sa registry (na nabuo ng Ordering Service). Lahat ng Committing Peer ay naglalaman ng lokal na kopya ng ipinamahagi na ledger. Sinusuri ng Committing Peer ang lahat ng transaksyon sa loob ng block para sa validity bago magdagdag ng bagong block nang lokal.
Ang Patakaran sa Pag-endorso ay ang patakaran para sa pagsuri sa bisa ng isang transaksyon. Tinutukoy ng mga patakarang ito ang kinakailangang hanay ng mga node kung saan dapat isagawa ang smart contract para makilala ang transaksyon bilang valid.
Ang distributed registry - Lerger - ay binubuo ng dalawang bahagi: WolrldState (tinatawag ding State DataBase) at BlockChain.
Ang BlockChain ay isang hanay ng mga bloke na nag-iimbak ng mga talaan ng lahat ng mga pagbabagong naganap sa mga ipinamahagi na bagay sa pagpapatala.
Ang WolrldState ay isang distributed ledger component na nag-iimbak ng kasalukuyang (cutting edge) na mga halaga ng lahat ng distributed ledger object.
Ang WorldState ay isang database, sa pangunahing bersyon - LevelDB o mas kumplikado - CouchDB, na naglalaman ng mga pares ng key-value, halimbawa: Pangalan - Ivan, Apelyido - Ivanov, petsa ng pagpaparehistro sa system - 12.12.21/17.12.1961/XNUMX , petsa ng kapanganakan - XNUMX/XNUMX/XNUMX, atbp. Ang WorldState at ang distributed registry ay dapat na pare-pareho sa lahat ng kalahok sa isang partikular na channel.
Dahil ang Hyperledger Fabric ay isang network kung saan kilala at napatotohanan ang lahat ng kalahok, gumagamit ito ng nakalaang awtoridad sa sertipikasyon - CA (Certification Authority). Ang CA ay gumagana batay sa X.509 na pamantayan at pampublikong pangunahing imprastraktura - PKI.
Ang Membership Service ay isang serbisyo kung saan pinapatunayan ng mga miyembro na ang isang bagay ay kabilang sa isang partikular na organisasyon o channel.
Ang isang transaksyon – sa karamihan ng mga kaso, ay nagsusulat ng bagong data sa isang distributed registry.
Mayroon ding mga transaksyon para sa paggawa ng mga channel o smart contract. Ang transaksyon ay pinasimulan ng application ng user at nagtatapos sa isang tala sa ipinamahagi na ledger.
Ang Channel ay isang saradong subnetwork na binubuo ng dalawa o higit pang mga kalahok sa network ng blockchain, na idinisenyo upang magsagawa ng mga kumpidensyal na transaksyon sa loob ng limitado ngunit kilalang lupon ng mga kalahok. Ang channel ay tinutukoy ng mga kalahok, ang ipinamahagi nitong pagpapatala, mga matalinong kontrata, Serbisyo sa Pag-order, WorldState. Ang bawat kalahok ng channel ay dapat na awtorisado na ma-access ang channel at may karapatang magsagawa ng iba't ibang uri ng mga transaksyon. Ang pahintulot ay isinasagawa gamit ang Membership Service.
Karaniwang senaryo ng pagpapatupad ng transaksyon
Susunod, gusto kong pag-usapan ang isang tipikal na senaryo ng pagpapatupad ng transaksyon gamit ang aming proyekto bilang isang halimbawa.
Bilang bahagi ng aming panloob na proyekto, nilikha namin ang network ng Hyperledger Fabric, na idinisenyo upang magparehistro at mag-account para sa mga mag-aaral na pumapasok sa mga unibersidad. Ang aming network ay binubuo ng dalawang organisasyong kabilang sa Unibersidad A at Unibersidad B. Ang bawat organisasyon ay naglalaman ng aplikasyon ng kliyente, pati na rin ang sarili nitong Committing at Endorsing Peer. Ginagamit din namin ang mga karaniwang serbisyong Serbisyo sa Pag-order, Serbisyo ng Membership at Awtoridad sa Sertipikasyon.
1) Pagsisimula ng Transaksyon
Ang isang application ng user, gamit ang Hyperledger Fabric SDK, ay nagpapasimula ng kahilingan sa transaksyon at ipinapadala ang kahilingan sa mga node na may mga smart contract. Ang kahilingan ay maaaring baguhin o basahin mula sa isang distributed registry (Ledger). Kung isasaalang-alang namin ang isang halimbawa ng aming configuration ng system ng pagsubok para sa accounting para sa mga mag-aaral sa unibersidad, ang application ng kliyente ay nagpapadala ng kahilingan sa transaksyon sa mga node ng mga unibersidad A at B, na kasama sa patakaran sa Pag-endorso ng tinatawag na smart contract. Ang node A ay isang node na matatagpuan sa unibersidad na nagrerehistro sa papasok na estudyante, at ang node B ay isang node na matatagpuan sa ibang unibersidad. Upang ma-save ang isang transaksyon sa isang distributed registry, kinakailangan na ang lahat ng mga node na, ayon sa lohika ng negosyo, ay dapat aprubahan ang transaksyon, matagumpay na maisagawa ang mga matalinong kontrata na may parehong resulta. Nakukuha ng node A user application, gamit ang Hyperledger Fabric SDK tool, ang patakaran sa Pag-endorso at natututo kung saang mga node padadalhan ng kahilingan sa transaksyon. Ito ay isang kahilingan na mag-invoke ng isang partikular na smart contract (chaincode function) para basahin o isulat ang ilang partikular na data sa isang distributed registry. Sa teknikal, ginagamit ng client SDK ang kaukulang function, ang API kung saan ipinapasa ang isang partikular na bagay na may mga parameter ng transaksyon, at nagdaragdag din ng lagda ng kliyente at ipinapadala ang data na ito sa pamamagitan ng protocol buffer sa gRPC sa mga naaangkop na node (nag-eendorso ng mga kapantay).
Larawan 2. Pagsisimula ng Transaksyon
2) Pagpapatupad ng matalinong kontrata
Mga Node (Endorsing Peers), na nakatanggap ng kahilingan na magsagawa ng isang transaksyon, suriin ang pirma ng kliyente at kung maayos ang lahat, kumuha sila ng isang bagay na may data ng kahilingan at nagpapatakbo ng isang simulation ng pagpapatupad ng isang matalinong kontrata (chaincode function) na may ang datos na ito. Ang isang matalinong kontrata ay ang lohika ng negosyo ng isang transaksyon, isang tiyak na hanay ng mga kundisyon at tagubilin (sa aming kaso, ito ay pag-verify ng isang mag-aaral, ito ba ay isang bagong mag-aaral, o siya ba ay nakarehistro na, pag-verify ng edad, atbp.). Upang maisagawa ang matalinong kontrata, kakailanganin mo rin ng data mula sa WorldState. Bilang resulta ng pagtulad sa isang matalinong kontrata sa Endorsing peer, dalawang set ng data ang nakuha – Read Set at Write Set. Ang Read Set at Write Set ay ang orihinal at bagong mga halaga ng WorldState. (bago – sa kahulugang nakuha sa simulation ng isang matalinong kontrata).
Larawan 3. Pagpapatupad ng isang matalinong kontrata
3) Pagbabalik ng data sa application ng kliyente
Pagkatapos magsagawa ng simulation ng smart contract, ibabalik ng Endorsing Peers ang orihinal na data at ang resulta ng simulation, pati na rin ang RW Set, na nilagdaan ng kanilang certificate sa application ng kliyente. Sa yugtong ito, walang pagbabagong nagaganap sa distributed registry. Sinusuri ng application ng kliyente ang pirma ng Pag-endorso ng Peer, at inihahambing din ang orihinal na data ng transaksyon na ipinadala at ang data na ibinalik (ibig sabihin, sinusuri nito kung na-distort ang orihinal na data kung saan na-simulate ang transaksyon). Kung ang transaksyon ay para lamang sa pagbabasa ng data mula sa registry, kung gayon ang application ng kliyente ay naaayon na natatanggap ang kinakailangang Read Set at kadalasang nakumpleto nito ang transaksyon nang matagumpay nang hindi binabago ang ipinamahagi na registry. Sa kaso ng isang transaksyon na dapat magbago ng data sa registry, ang application ng kliyente ay tumitingin din sa pagpapatupad ng patakaran sa Pag-endorso. Posibleng hindi sinusuri ng application ng kliyente ang resulta ng pagpapatupad ng Patakaran sa Pag-endorso, ngunit ang platform ng Hyperledger Fabric sa kasong ito ay nagbibigay para sa pagsuri ng mga patakaran sa mga node (Committing Peers) sa yugto ng pagdaragdag ng transaksyon sa registry.
Larawan 4. Pagbabalik ng data sa application ng kliyente
4) Pagpapadala ng mga RW set sa Pag-order ng mga Kapantay
Ipinapadala ng application ng kliyente ang transaksyon kasama ang kasamang data sa serbisyo ng Pag-order. Kabilang dito ang RW Set, Mga lagda ng pag-endorso ng mga kasamahan, at ang Channel ID.
Serbisyo ng pag-order - batay sa pangalan, ang pangunahing tungkulin ng serbisyong ito ay upang ayusin ang mga papasok na transaksyon sa tamang pagkakasunud-sunod. Pati na rin ang pagbuo ng bagong block ng distributed registry at garantisadong paghahatid ng mga bagong nabuong block sa lahat ng Commiting node, kaya tinitiyak ang pagkakapare-pareho ng data sa lahat ng node na naglalaman ng distributed registry (Committing peers). Kasabay nito, ang serbisyo ng Pag-order mismo ay hindi nagbabago sa pagpapatala sa anumang paraan. Ang Serbisyo ng Pag-order ay isang mahalagang bahagi ng system, kaya ito ay isang kumpol ng ilang mga node. Ang Serbisyo ng Pag-order ay hindi sinusuri ang transaksyon para sa bisa, tinatanggap lamang nito ang isang transaksyon na may isang tiyak na channel identifier, nag-aayos ng mga papasok na transaksyon sa isang tiyak na pagkakasunud-sunod at bumubuo ng mga bagong bloke ng ipinamamahaging pagpapatala mula sa kanila. Ang isang Serbisyo sa Pag-order ay maaaring maghatid ng ilang channel nang sabay-sabay. Ang Serbisyo sa Pag-order ay may kasamang Kafka cluster, na nagpapanatili ng tamang (hindi mababago) na pila ng transaksyon (tingnan ang Point 7).
Larawan 5. Pagpapadala ng mga RW set sa Pag-order ng mga Kapantay
5) Pagpapadala ng mga nabuong bloke sa Committing Peer
Ang mga bloke na nabuo sa Serbisyo ng Pag-order ay ipinapadala (broadcast) sa lahat ng mga node ng network. Ang bawat node, na nakatanggap ng bagong block, sinusuri ito para sa pagsunod sa Patakaran sa Pag-eendorso, sinusuri na ang lahat ng Nag-eendorso na Peer ay nakatanggap ng parehong resulta (Write Set) bilang resulta ng matalinong simulation ng kontrata, at sinusuri din kung ang mga orihinal na halaga ay may nagbago (iyon ay, Read Set - data na binasa ng matalinong kontrata mula sa WorldState) mula sa sandaling sinimulan ang transaksyon. Kung ang lahat ng mga kundisyon ay natutugunan, ang transaksyon ay minarkahan bilang wasto, kung hindi, ang transaksyon ay makakatanggap ng katayuan na hindi wasto.
Larawan 6. Pagpapadala ng mga nabuong bloke sa Committing Peer
6) Pagdaragdag ng block sa registry
Ang bawat node ay nagdaragdag ng isang transaksyon sa lokal na kopya nito ng ipinamahagi na pagpapatala, at kung ang transaksyon ay wasto, ang Write Set ay inilalapat sa WorldState (kasalukuyang estado), at naaayon, ang mga bagong halaga ng mga bagay na naapektuhan ng nakasulat ang transaksyon. Kung ang isang transaksyon ay nakatanggap ng isang token na hindi wasto (halimbawa, dalawang transaksyon ang naganap na may parehong mga bagay sa loob ng parehong bloke, kung gayon ang isa sa mga transaksyon ay magiging hindi wasto, dahil ang orihinal na mga halaga ay binago na ng isa pa. transaksyon). Ang transaksyong ito ay idinagdag din sa ipinamahagi na ledger na may di-wastong token, ngunit ang Write Set ng transaksyong ito ay hindi inilalapat sa kasalukuyang WorldState at, nang naaayon, ay hindi nagbabago sa mga bagay na kalahok sa transaksyon. Pagkatapos nito, ang isang abiso ay ipinadala sa application ng gumagamit na ang transaksyon ay permanenteng idinagdag sa ipinamahagi na pagpapatala, pati na rin ang katayuan ng transaksyon, iyon ay, kung ito ay wasto o hindi...
Larawan 7. Pagdaragdag ng block sa registry
PAG-ORDER NG SERBISYO
Ang Serbisyo sa Pag-order ay binubuo ng isang Kafka cluster na may kaukulang mga ZooKeeper node at Ordering Service Nodes (OSN), na nasa pagitan ng mga kliyente ng serbisyo ng Pag-order at ng Kafka Cluster. Ang Kafka cluster ay isang distributed, fault-tolerant flow (message) management platform. Ang bawat channel (paksa) sa Kafka ay isang hindi nababagong pagkakasunud-sunod ng mga tala na sumusuporta lamang sa pagdaragdag ng isang bagong tala (hindi posible ang pagtanggal ng isang umiiral na). Ang isang paglalarawan ng istraktura ng paksa ay ipinapakita sa ibaba. Ito ang pag-aari ng Kafka na ginagamit upang bumuo ng isang blockchain platform.
kinuha mula sa kafka.apache.org
- Larawan 8. Istraktura ng Paksa ng Serbisyo sa Pag-order*
Mga kapaki-pakinabang na link
Mga Pasasalamat
Nais kong ipahayag ang aking matinding pasasalamat sa aking mga kasamahan sa kanilang tulong sa paghahanda ng artikulong ito:
Nikolay Marin
Igor Khapov
Dmitry Gorbachev
Alexander Zemtsov
Ekaterina Guseva
Pinagmulan: www.habr.com