Blockchain հարթակ ձեռնարկության համար
Բարի լույս, հարգելի ընթերցողներ, ես Նիկոլայ Նեֆեդովն եմ, ես IBM-ի տեխնիկական մասնագետ եմ, այս հոդվածում ցանկանում եմ ձեզ ներկայացնել բլոկչեյն հարթակը՝ Hyperledger Fabric: Հարթակը նախատեսված է ձեռնարկության մակարդակի բիզնես հավելվածներ ստեղծելու համար (Enterprise class): Հոդվածի մակարդակը ՏՏ տեխնոլոգիաների տարրական գիտելիքներով անպատրաստ ընթերցողների համար է։
Hyperledger Fabric-ը բաց կոդով նախագիծ է, Hyperledger բաց կոդով նախագծի մասնաճյուղերից մեկը, Linux Foundation-ի կոնսորցիում: Hyperledger Fabric-ը սկզբնապես թողարկվել է Digital Assets-ի և IBM-ի կողմից: Hyperledger Fabric հարթակի հիմնական առանձնահատկությունը կորպորատիվ հավելվածների վրա կենտրոնացումն է: Ուստի հարթակը մշակվել է՝ հաշվի առնելով գործարքների բարձր արագությունը և դրանց ցածր արժեքը, ինչպես նաև բոլոր մասնակիցների նույնականացումը։ Այս օգուտները ձեռք են բերվում գործարքների ստուգման ծառայությունը առանձնացնելու և բաշխված ռեգիստրի նոր բլոկների ձևավորման, ինչպես նաև վկայականի մարմնի օգտագործման և մասնակիցներին լիազորելու միջոցով:
Իմ հոդվածը Hyperledger Fabric-ի մասին հոդվածների շարքի մի մասն է, որտեղ մենք նկարագրում ենք համալսարան ընդունվող ուսանողների գրանցման համակարգի նախագիծը:
Hyperledger Fabric-ի ընդհանուր ճարտարապետությունը
Hyperledger Fabric-ը բաշխված բլոկչեյն ցանց է, որը բաղկացած է տարբեր ֆունկցիոնալ բաղադրիչներից, որոնք տեղադրված են ցանցի հանգույցներում: Hyperledger Fabric բաղադրիչները Docker կոնտեյներներ են, որոնք կարելի է անվճար ներբեռնել DockerHub-ից: Hyperledger Fabric-ը կարող է գործարկվել նաև Kubernetes միջավայրում:
Խելացի պայմանագրեր գրելու համար (շղթայական կոդը Hyperledger Fabric-ի համատեքստում) մենք օգտագործել ենք Golang-ը (չնայած Hyperledger Fabric-ը թույլ է տալիս օգտագործել այլ լեզուներ): Հատուկ հավելված մշակելու համար մեր դեպքում Node.js-ն օգտագործվել է համապատասխան Hyperledger Fabric SDK-ով։
Հանգույցները գործարկում են բիզնես տրամաբանությունը (խելացի պայմանագիր)՝ շղթայական կոդը, պահպանում են բաշխված ռեեստրի վիճակը (գրանցամատյանների տվյալները) և կատարում են հարթակի այլ համակարգի ծառայություններ: Հանգույցը միայն տրամաբանական միավոր է, տարբեր հանգույցներ կարող են գոյություն ունենալ նույն ֆիզիկական սերվերի վրա: Շատ ավելի կարևոր է, թե ինչպես են հանգույցները խմբավորվում (Վստահելի տիրույթ) և բլոկչեյն ցանցի ինչ գործառույթների հետ են դրանք կապված:
Ընդհանուր ճարտարապետությունն ունի հետևյալ տեսքը.
Նկար 1. Hyperledger գործվածքների ընդհանուր ճարտարապետություն
Օգտատիրոջ հավելվածը (Submitting Client) հավելված է, որի հետ օգտատերերն աշխատում են բլոկչեյն ցանցի հետ։ Աշխատելու համար դուք պետք է անցնեք թույլտվություն և ունենաք համապատասխան իրավունքներ ցանցում տարբեր տեսակի գործողությունների համար:
Հասակակիցները (հանգույցները) հանդես են գալիս մի քանի դերերով.
- Endorsing Peer-ը հանգույց է, որը մոդելավորում է գործարքի կատարումը (կատարում է խելացի պայմանագրի կոդը): Սմարթ պայմանագիրը վավերացնելուց և կատարելուց հետո հանգույցը ստորագրության հետ միասին վերադարձնում է կատարման արդյունքները հաճախորդի հավելվածին:
- Ordering Service-ը բաշխված ծառայություն է մի քանի հանգույցների վրա, որն օգտագործվում է բաշխված մատյանում նոր բլոկներ ձևավորելու և գործարքների կատարման հաջորդականություն ստեղծելու համար: Պատվերների ծառայությունը չի ավելացնում նոր բլոկներ գրանցամատյանում (ավելի լավ կատարման համար տեղափոխվել է Committing Peers):
- Committing Peer - հանգույց, որը պարունակում է բաշխված ռեեստր և ավելացնում է նոր բլոկներ գրանցամատյանում (որոնք ձևավորվել են Պատվերների ծառայության կողմից): Բոլոր Հանձնարարական Գործընկերները պարունակում են բաշխված մատյանի տեղական պատճենը: Հանձնարարականը, նախքան լոկալ նոր բլոկ ավելացնելը, ստուգում է բլոկի ներսում կատարվող բոլոր գործարքների վավերականությունը:
Հաստատման քաղաքականությունը գործարքի վավերականությունը ստուգելու քաղաքականություն է: Այս քաղաքականությունները սահմանում են հանգույցների անհրաժեշտ փաթեթը, որոնց վրա պետք է կատարվի խելացի պայմանագիրը, որպեսզի գործարքը վավեր ճանաչվի:
Բաշխված ռեգիստրը՝ Lerger, բաղկացած է երկու մասից՝ WolrldState (նաև կոչվում է State DataBase) և BlockChain։
BlockChain-ը բլոկների շղթա է, որը պահում է գրանցամատյանների բաշխված օբյեկտներում տեղի ունեցած բոլոր փոփոխությունների գրառումները:
WolrldState-ը բաշխված ռեեստրի բաղադրիչ է, որը պահպանում է բոլոր բաշխված ռեեստրի օբյեկտների ընթացիկ (ծայրահեղ) արժեքները:
WorldState-ը տվյալների բազա է, հիմնական տարբերակով՝ LevelDB կամ ավելի բարդ՝ CouchDB, որը պարունակում է բանալի-արժեք զույգեր, օրինակ՝ Անուն՝ Իվան, Ազգանուն՝ Իվանով, համակարգում գրանցման ամսաթիվ՝ 12.12.21/17.12.1961/XNUMX, ամսաթիվ ծնունդ - XNUMXթ. և այլն: WorldState-ը և բաշխված մատյանը պետք է համապատասխանեն տվյալ ալիքի բոլոր անդամներին:
Քանի որ Hyperledger Fabric-ը ցանց է, որտեղ բոլոր մասնակիցները հայտնի և վավերացված են, այստեղ օգտագործվում է հատուկ սերտիֆիկացման մարմին՝ CA (Սերտիֆիկացման մարմին): CA-ն գործում է X.509 ստանդարտի և հանրային բանալիների ենթակառուցվածքի հիման վրա՝ PKI:
Անդամության ծառայությունը ծառայություն է, որի միջոցով անդամները ստուգում են, որ օբյեկտը պատկանում է որոշակի կազմակերպության կամ ալիքի:
Գործարքը, շատ դեպքերում, նոր տվյալների գրառում է բաշխված մատյանում:
Գործարքներ կան նաև կապուղիների կամ խելացի պայմանագրերի ստեղծման համար։ Գործարքը նախաձեռնվում է օգտագործողի հավելվածի կողմից և ավարտվում է բաշխված մատյանում գրավորմամբ:
Channel (Channel) փակ ենթացանց է, որը բաղկացած է բլոկչեյն ցանցի երկու կամ ավելի մասնակիցներից, որը նախատեսված է գաղտնի գործարքներ իրականացնելու մասնակիցների սահմանափակ, բայց հայտնի շրջանակում: Ալիքը որոշվում է մասնակիցների կողմից, դրա բաշխված գրացուցակը, խելացի պայմանագրերը, Պատվերների ծառայությունը, Համաշխարհային պետությունը: Ալիքի յուրաքանչյուր անդամ պետք է լիազորված լինի մուտք գործել ալիք և իրավունք ունենա կատարել տարբեր տեսակի գործարքներ: Լիազորումը կատարվում է Անդամակցության ծառայության միջոցով:
Գործարքների կատարման տիպիկ սցենար
Հաջորդը, ես կցանկանայի խոսել մեր նախագծի օրինակով գործարքի կատարման բնորոշ սցենարի մասին:
Մեր ներքին նախագծի շրջանակներում մենք ստեղծել ենք Hyperledger Fabric ցանց, որը նախատեսված է գրանցելու և գրանցելու բուհ ընդունվող ուսանողներին: Մեր ցանցը բաղկացած է երկու կազմակերպություններից, որոնք պատկանում են համալսարանին A-ին և B-ին: Մենք նաև օգտագործում ենք ընդհանուր պատվիրման ծառայություն, անդամության ծառայություն և հավաստագրման մարմնի ծառայություններ:
1) Գործարքի նախաձեռնում
Օգտատիրոջ հավելվածը, օգտագործելով Hyperledger Fabric SDK-ն, նախաձեռնում է գործարքի հարցում և հարցումն ուղարկում խելացի պայմանագրեր ունեցող հանգույցներին: Հարցումը կարող է լինել փոխել կամ կարդալ բաշխված մատյանից (Ledger): Եթե դիտարկենք համալսարանի ուսանողների համար հաշվառման համակարգի մեր թեստային կազմաձևման օրինակ, ապա հաճախորդի հավելվածը գործարքի հարցում է ուղարկում A և B համալսարանների հանգույցներին, որոնք ներառված են կոչվող խելացի պայմանագրի Հաստատման քաղաքականության մեջ: A հանգույցը մի հանգույց է, որը գտնվում է համալսարանում, որը գրանցում է մուտքային ուսանող, իսկ B հանգույցը հանգույց է, որը գտնվում է մեկ այլ համալսարանում: Որպեսզի գործարքը պահպանվի բաշխված մատյանում, անհրաժեշտ է, որ բոլոր հանգույցները, որոնք, ըստ բիզնես տրամաբանության, պետք է հաստատեն գործարքը, հաջողությամբ կատարեն նույն արդյունքով խելացի պայմանագրերը: A հանգույցի օգտատերերի հավելվածը, օգտագործելով Hyperledger Fabric SDK գործիքները, ստանում է Հաստատման քաղաքականություն (հաստատման քաղաքականություն) և պարզում, թե որ հանգույցներին պետք է ուղարկել գործարքի հարցում: Սա որոշակի խելացի պայմանագիր (շղթայական կոդի ֆունկցիա) կանչելու (կանչելու) խնդրանք է՝ բաշխված մատյանում որոշակի տվյալներ կարդալու կամ գրելու համար: Տեխնիկապես հաճախորդի SDK-ն օգտագործում է համապատասխան գործառույթը, որի API-ին փոխանցվում է գործարքի պարամետրերով օբյեկտ, ինչպես նաև ավելացնում է հաճախորդի ստորագրությունը և ուղարկում այս տվյալները gRPC-ի միջոցով արձանագրության բուֆերի միջոցով համապատասխան հանգույցներին (հաստատող գործընկերներ):
Նկար 2. Գործարքի մեկնարկ
2) խելացի պայմանագրի կատարում
Հանգույցները (հաստատող հասակակիցները), ստանալով գործարք իրականացնելու հայտ, ստուգում են հաճախորդի ստորագրությունը և եթե ամեն ինչ կարգին է, ապա նրանք վերցնում են հարցման տվյալների հետ կապված օբյեկտ և գործարկում են խելացի պայմանագրի կատարման մոդելավորում (շղթայական կոդի ֆունկցիա): այս տվյալներով։ Սմարթ պայմանագիրը գործարքի բիզնես տրամաբանությունն է, պայմանների և հրահանգների որոշակի փաթեթ (մեր դեպքում սա ուսանողական ստուգում է, նոր ուսանող է, թե արդեն գրանցված է, տարիքի ստուգում և այլն): Խելացի պայմանագիր կնքելու համար ձեզ անհրաժեշտ կլինեն նաև տվյալներ WorldState-ից: Endorsing գործընկերոջ վրա խելացի պայմանագրի մոդելավորման արդյունքում ստացվում է տվյալների երկու հավաքածու՝ Read Set և Write Set: Read Set and Write Set-ը բնօրինակ և նոր WorldState արժեքներն են: (նոր - այն իմաստով, որը ստացվել է խելացի պայմանագրի մոդելավորման միջոցով):
Նկար 3. Խելացի պայմանագրի կատարում
3) տվյալների վերադարձ հաճախորդի հավելվածին
Խելացի պայմանագրի մոդելավորումից հետո Endorsing Peers-ը հաճախորդի հավելվածին վերադարձնում է նախնական տվյալները և սիմուլյացիայի արդյունքը, ինչպես նաև իրենց վկայականով ստորագրված RW հավաքածուն: Այս փուլում բաշխված մատյանում փոփոխություններ չկան: Հաճախորդի հավելվածը ստուգում է Հաստատող գործընկերոջ ստորագրությունը, ինչպես նաև համեմատում է ուղարկված գործարքի սկզբնական տվյալները և վերադարձված տվյալները (այսինքն՝ ստուգում է՝ արդյոք բնօրինակ տվյալները, որոնց վրա գործարքը նմանակվել է, կոռումպացված են): Եթե գործարքը եղել է միայն ռեեստրից տվյալների ընթերցման համար, ապա հաճախորդի հավելվածը համապատասխանաբար ստանում է անհրաժեշտ Read Set-ը, և այդ դեպքում գործարքը սովորաբար հաջողությամբ ավարտվում է՝ առանց բաշխված ռեեստրը փոխելու: Գործարքի դեպքում, որը պետք է փոխի ռեեստրի տվյալները, հաճախորդի հավելվածը լրացուցիչ ստուգում է, թե արդյոք ներդրման քաղաքականությունը իրականացվել է: Հնարավոր է, որ հաճախորդի հավելվածը չստուգի Հաստատման քաղաքականության կատարման արդյունքը, սակայն Hyperledger Fabric պլատֆորմն այս դեպքում նախատեսում է հանգույցների (Comitting Peers) քաղաքականությունների ստուգում ռեեստրում գործարք ավելացնելու փուլում:
Նկար 4. Տվյալների վերադարձ հաճախորդի հավելվածին
4) RW լրակազմերի ուղարկում Ordering Peers-ին
Հաճախորդի հավելվածը գործարքը հարակից տվյալների հետ միասին ուղարկում է Պատվերների ծառայություն: Սա ներառում է RW հավաքածուն, Հաստատող գործընկերների ստորագրությունները և Ալիքի ID-ն:
Պատվերների ծառայություն - Անվանումից ելնելով, այս ծառայության հիմնական գործառույթը մուտքային գործարքները ճիշտ հերթականությամբ կառուցելն է: Ինչպես նաև բաշխված ռեգիստրի նոր բլոկի ձևավորում և նոր գեներացված բլոկների երաշխավորված առաքում բոլոր Կոմիտինգ հանգույցներին՝ այդպիսով ապահովելով տվյալների հետևողականությունը բաշխված ռեեստր պարունակող բոլոր հանգույցների վրա (Committing peers): Միևնույն ժամանակ, Ordering ծառայությունն ինքնին ոչ մի կերպ չի փոխում ռեեստրը: Պատվերների ծառայությունը համակարգի կենսական բաղադրիչն է, ուստի այն մի քանի հանգույցներից բաղկացած կլաստեր է: Պատվերների ծառայությունը չի ստուգում գործարքի վավերականությունը, այն պարզապես ընդունում է գործարքը կոնկրետ կապուղու ID-ով, կազմակերպում է մուտքային գործարքները որոշակի կարգով և դրանցից ձևավորում բաշխված մատյանների նոր բլոկներ: Մեկ պատվիրման ծառայությունը կարող է միաժամանակ սպասարկել մի քանի ալիք: Պատվերների ծառայությունը ներառում է Կաֆկա կլաստեր, որը պահպանում է գործարքների ճիշտ (անփոփոխ) հերթը (տես կետ 7):
Նկար 5. Ուղարկել RW հավաքածուներ Ordering Peers-ին
5) Ստեղծված բլոկների ուղարկումը պարտավորեցնող գործընկերին
Պատվերների ծառայությունում ձևավորված բլոկները հեռարձակվում են ցանցի բոլոր հանգույցներին: Յուրաքանչյուր հանգույց, ստանալով նոր բլոկ, ստուգում է այն Հաստատման քաղաքականությանը համապատասխանելու համար, ստուգում է, որ բոլոր Հաստատող գործընկերները ստացել են նույն արդյունքը (Write Set) խելացի պայմանագրի մոդելավորման արդյունքում, ինչպես նաև ստուգում է արդյոք սկզբնական արժեքները փոխվել է (այսինքն, - Read Set - խելացի պայմանագրով կարդացված տվյալները WorldState-ից) գործարքի մեկնարկից ի վեր: Բոլոր պայմանները բավարարելու դեպքում գործարքը նշվում է որպես վավեր, հակառակ դեպքում գործարքը ստանում է անվավեր կարգավիճակ:
Նկար 6. Ստեղծված բլոկների ուղարկում Հանձնարարող Պերերին
6) ռեեստրում բլոկի ավելացում
Յուրաքանչյուր հանգույց ավելացնում է գործարք բաշխված գրանցամատյանի իր տեղական օրինակին, և եթե գործարքը վավեր է, ապա Write Set-ը կիրառվում է WorldState-ի վրա (ներկայիս վիճակ), համապատասխանաբար, գրվում են գործարքի ազդեցության տակ գտնվող օբյեկտների նոր արժեքներ: . Եթե գործարքը ստացել է անվավեր նշան (օրինակ, նույն բլոկի ներսում եղել են երկու գործարքներ նույն օբյեկտներով, ապա գործարքներից մեկը վավեր չի լինի, քանի որ սկզբնական արժեքներն արդեն փոխվել են մեկ այլ գործարքի միջոցով: ) Այս գործարքը նույնպես ավելացվում է բաշխված մատյանում անվավեր նշիչով, սակայն այս գործարքի Write Set-ը չի տարածվում Համաշխարհային պետության ներկայիս վիճակի վրա և, համապատասխանաբար, չի փոխում գործարքին մասնակցող օբյեկտները: Դրանից հետո օգտատիրոջ հավելվածին ծանուցում է ուղարկվում այն մասին, որ գործարքը հավերժ ավելացվել է բաշխված մատյանում, ինչպես նաև գործարքի կարգավիճակը, այսինքն՝ այն վավեր է, թե ոչ...
Նկար 7. Բլոկի ավելացում ռեեստրում
ՊԱՏՎԵՐԻ ԾԱՌԱՅՈՒԹՅՈՒՆ
Պատվերների ծառայությունը բաղկացած է Կաֆկա կլաստերից՝ համապատասխան ZooKeeper հանգույցներով և Պատվերի ծառայության հանգույցներով (OSN), որոնք տեղակայված են Պատվերի ծառայության հաճախորդների և Kafka կլաստերի միջև: Կաֆկա կլաստերը բաշխված, սխալ հանդուրժող հոսքի (հաղորդագրությունների) կառավարման հարթակ է: Կաֆկայի յուրաքանչյուր ալիք (թեմա) գրառումների անփոփոխ հաջորդականություն է, որն աջակցում է միայն նոր ձայնագրության ավելացմանը (գոյություն ունեցողը ջնջելը հնարավոր չէ): Թեմայի կառուցվածքի նկարազարդումը տրված է ստորև: Հենց Կաֆկայի այս հատկությունն է օգտագործվում բլոկչեյն հարթակի կառուցման համար։
վերցված է kafka.apache.org կայքից
- Նկար 8. Պատվերի ծառայության թեմայի կառուցվածքը*
Օգտակար հղումներ
Շնորհակալագրեր
Իմ խորին շնորհակալությունն եմ հայտնում իմ գործընկերներին՝ հոդվածը պատրաստելու հարցում նրանց օգնության համար.
Նիկոլայ Մարինա
Իգոր Խապով
Դմիտրի Գորբաչով
Ալեքսանդր Զեմցով
Եկատերինա Գուսևա
Source: www.habr.com