Hyperledger Ткаенина за Dummies

Блокчејн платформа за претпријатието

Добро попладне, драги читатели, јас се викам Николај Нефедов, јас сум технички специјалист во IBM, во оваа статија би сакал да ве запознаам со блокчејн платформата - Hyperledger Fabric. Платформата е дизајнирана за градење деловни апликации од класата на претпријатија. Нивото на статијата е за неподготвени читатели со основни познавања од ИТ технологиите.

Hyperledger Fabric е проект со отворен код, една од гранките на проектот со отворен код Hyperledger, конзорциум на Фондацијата Linux. 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) е апликација со која корисниците работат со блокчејн мрежата. За да работите, мора да сте овластени и да ги имате соодветните права за различни видови дејства на мрежата.

Врсниците доаѓаат во неколку улоги:

• Одобрување на Peer е јазол кој симулира извршување на трансакција (го извршува кодот за паметен договор). По верификацијата и извршувањето на паметниот договор, јазолот ги враќа резултатите од извршувањето на клиентската апликација заедно со неговиот потпис.
• Услугата за нарачка е дистрибуирана услуга на неколку јазли, која се користи за генерирање на нови блокови од дистрибуираниот регистар и создавање на ред за извршување на трансакции. Услугата за нарачка не додава нови блокови во регистарот (Оваа функција е преместена во Committing Peers за да се подобрат перформансите).
• Извршување на Peer е јазол кој содржи дистрибуиран регистар и додава нови блокови во регистарот (кои се генерирани од услугата за нарачка). Сите обврзувачки врсници содржат локална копија од дистрибуираната книга. Обврската на Peer ги проверува сите трансакции во блокот за валидност пред да додаде нов блок локално.

Политика за одобрување е политика за проверка на валидноста на трансакцијата. Овие политики го дефинираат потребниот сет на јазли на кои мора да се изврши паметниот договор за трансакцијата да биде препознаена како валидна.

Дистрибуираниот регистар - Lerger - се состои од два дела: WolrldState (исто така наречена Државна база на податоци) и BlockChain.

BlockChain е синџир на блокови што ги складира записите за сите промени што се случиле на дистрибуираните објекти во регистарот.

WolrldState е дистрибуирана книшка компонента која ги зачувува тековните (современи) вредности на сите дистрибуирани објекти во книгата.

WorldState е база на податоци, во основната верзија - LevelDB или посложена - CouchDB, која содржи парови клучни-вредности, на пример: Име - Иван, Презиме - Иванов, датум на регистрација во системот - 12.12.21 , датум на раѓање - 17.12.1961 година итн. WorldState и дистрибуираниот регистар мора да бидат конзистентни меѓу сите учесници во даден канал.

Бидејќи Hyperledger Fabric е мрежа во која сите учесници се познати и автентицирани, таа користи посветен орган за сертификација - CA (Certification Authority). CA работи врз основа на стандардот X.509 и инфраструктурата со јавен клуч - PKI.

Услуга за членство е услуга преку која членовите потврдуваат дека објектот припаѓа на одредена организација или канал.

Трансакцијата - во повеќето случаи, е запишување нови податоци во дистрибуиран регистар.
Има и трансакции за создавање канали или паметни договори. Трансакцијата е иницирана од корисничката апликација и завршува со запис во дистрибуираната книга.

Канал е затворена подмрежа која се состои од два или повеќе учесници во блокчејн мрежата, дизајнирана да врши доверливи трансакции во ограничен, но познат круг на учесници. Каналот го одредуваат учесниците, неговиот дистрибуиран регистар, паметните договори, услугата за нарачки, WorldState. Секој учесник на каналот мора да биде овластен да пристапува до каналот и да има право да врши различни видови трансакции. Овластувањето се врши со користење на Услугата за членство.

Типично сценарио за извршување трансакција

Следно, би сакал да зборувам за типично сценарио за извршување трансакција користејќи го нашиот проект како пример.

Како дел од нашиот внатрешен проект, ја создадовме мрежата Hyperledger Fabric, која е дизајнирана да се регистрира и да води сметка за студентите кои влегуваат на универзитетите. Нашата мрежа се состои од две организации кои припаѓаат на Универзитетот А и Универзитетот Б. Секоја организација содржи клиентска апликација, како и сопствена врсничка за обврзување и одобрување. Ние, исто така, ги користиме заедничките услуги за нарачка, служба за членство и орган за сертификација.

1) Започнување на трансакцијата

Корисничка апликација, користејќи го Hyperledger Fabric SDK, иницира барање за трансакција и го испраќа барањето до јазли со паметни договори. Барањето може да биде промена или читање од дистрибуиран регистар (Леџер). Ако земеме пример за конфигурација на нашиот тест систем за сметководство за студенти, клиентската апликација испраќа барање за трансакција до јазлите на универзитетите А и Б, кои се вклучени во политиката за одобрување на наречениот паметен договор. Јазол А е јазол кој се наоѓа на универзитетот што го регистрира студентот што доаѓа, а јазолот Б е јазол што се наоѓа на друг универзитет. За да може трансакцијата да се зачува во дистрибуиран регистар, неопходно е сите јазли кои, според деловната логика, мора да ја одобрат трансакцијата, успешно да извршат паметни договори со ист резултат. Јазол Корисничка апликација, користејќи ги алатките Hyperledger Fabric SDK, ја добива политиката за одобрување и учи до кои јазли да испрати барање за трансакција. Ова е барање да се повика специфичен паметен договор (функција на верижен код) за читање или запишување одредени податоци во дистрибуиран регистар. Технички, клиентот SDK ја користи соодветната функција, на чиј API се пренесува одреден објект со параметри на трансакцијата, а исто така додава потпис на клиентот и ги испраќа овие податоци преку протоколски тампон преку gRPC до соодветните јазли (одобрени врсници).

Слика 2. Иницирање трансакција

2) Извршување на паметен договор

Јазли (Endosing Peers), откако добиле барање за спроведување трансакција, го проверуваат потписот на клиентот и ако сè е во ред, тие земаат предмет со податоците за барањето и извршуваат симулација на извршување на паметен договор (функција на верижен код) со овој податок. Паметниот договор е деловната логика на трансакцијата, одреден сет на услови и инструкции (во нашиот случај, ова е верификација на студент, дали е ова нов студент или е веќе регистриран, проверка на возраст итн.). За да го извршите паметниот договор, ќе ви требаат и податоци од WorldState. Како резултат на симулирање на паметен договор на врсникот за одобрување, се добиваат две групи на податоци - Read Set и Write Set. Read Set и Write Set се оригиналните и новите вредности на WorldState. (ново – во смисла добиена при симулација на паметен договор).

Слика 3. Извршување на паметен договор

3) Враќање податоци во клиентската апликација

По спроведувањето на симулација на паметниот договор, Endorsing Peers ги враќа оригиналните податоци и резултатот од симулацијата, како и RW Set, потпишан од нивниот сертификат до клиентската апликација. Во оваа фаза, нема промени во дистрибуираниот регистар. Клиентската апликација го проверува потписот на Andorsing Peer, а исто така ги споредува оригиналните податоци за трансакцијата што биле испратени и податоците што биле вратени (односно, проверува дали оригиналните податоци на кои била симулирана трансакцијата се искривени). Ако трансакцијата била само за читање податоци од регистарот, тогаш клиентската апликација соодветно го добива потребното множество за читање и тоа обично ја завршува трансакцијата успешно без промена на дистрибуираниот регистар. Во случај на трансакција која мора да ги промени податоците во регистарот, клиентската апликација дополнително ја проверува имплементацијата на политиката за одобрување. Можно е клиентската апликација да не го проверува резултатот од извршувањето на Политиката за одобрување, но платформата Hyperledger Fabric во овој случај предвидува проверка на политиките на јазлите (Committing Peers) во фазата на додавање трансакција во регистарот.

Слика 4. Враќање податоци во клиентската апликација

4) Испраќање на RW сетови до Ordering Peers

Клиентската апликација ја испраќа трансакцијата заедно со придружните податоци до услугата Нарачка. Ова го вклучува комплетот RW, Потписите на врсниците за одобрување и ID на каналот.

Услуга за нарачување – врз основа на името, главната функција на оваа услуга е да ги организира дојдовните трансакции во правилен редослед. Како и формирање на нов блок на дистрибуираниот регистар и загарантирана испорака на нови генерирани блокови до сите јазли за извршување, со што се обезбедува конзистентност на податоците за сите јазли што го содржат дистрибуираниот регистар (Committing peers). Во исто време, самата услуга Нарачка не го менува регистарот на кој било начин. Услугата за нарачување е витална компонента на системот, па затоа е кластер од неколку јазли. Услугата за нарачки не ја проверува валидноста на трансакцијата, таа едноставно прифаќа трансакција со одреден идентификатор на канал, ги уредува дојдовните трансакции по одреден ред и формира нови блокови на дистрибуираниот регистар од нив. Една услуга за нарачка може да опслужува неколку канали истовремено. Услугата за нарачка вклучува кластер Кафка, кој ја одржува точната (непроменлива) редица на трансакции (види точка 7).

Слика 5. Испраќање на RW множества до Ordering Peers

5) Испраќање на генерирани блокови до Committing Peer

Блоковите генерирани во Услугата за нарачки се пренесуваат (емитуваат) до сите мрежни јазли. Секој јазол, откако доби нов блок, го проверува за усогласеност со Политиката за одобрување, проверува дали сите врсници за одобрување го добиле истиот резултат (Write Set) како резултат на симулацијата на паметниот договор, а исто така проверува дали оригиналните вредности имаат изменета (т.е. Read Set - податоци прочитани од паметниот договор од WorldState) од моментот на започнување на трансакцијата. Доколку се исполнети сите услови, трансакцијата е означена како валидна, во спротивно, трансакцијата добива статус неважечка.

Слика 6. Испраќање на генерирани блокови до Committing Peer

6) Додавање блок во регистарот

Секој јазол додава трансакција во својата локална копија на дистрибуираниот регистар, и ако трансакцијата е валидна, тогаш множеството Write се применува на WorldState (тековната состојба) и соодветно на тоа, новите вредности на објектите кои биле засегнати од трансакцијата се напишани. Ако трансакцијата добила токен што не е валиден (на пример, две трансакции се случиле со исти објекти во истиот блок, тогаш една од трансакциите ќе испадне неважечка, бидејќи оригиналните вредности веќе се променети од друга трансакција). Оваа трансакција исто така се додава во дистрибуираната книга со неважечки токен, но множеството за запишување на оваа трансакција не се применува на тековната светска држава и, соодветно, не ги менува објектите што учествуваат во трансакцијата. По ова, до корисничката апликација се испраќа известување дека трансакцијата е трајно додадена во дистрибуираниот регистар, како и статусот на трансакцијата, односно дали е валидна или не...

Слика 7. Додавање блок во регистарот

УСЛУГА ЗА НАРАЧКИ

Услугата за нарачка се состои од кластер Кафка со соодветните ZooKeeper јазли и Јазли за нарачка (OSN), кои стојат помеѓу клиентите на услугата за нарачка и кластерот Кафка. Кластерот Кафка е дистрибуирана платформа за управување со проток (пораки) толерантна за грешки. Секој канал (тема) во Кафка е непроменлива низа од записи што поддржува само додавање нов запис (бришење на постоечки не е можно). Подолу е прикажана илустрација на структурата на темата. Токму овој имот на Кафка се користи за изградба на блокчејн платформа.

преземено од kafka.apache.org

• Слика 8. Структура на тема за нарачка на услугата*

Корисни ЛИНКОВИ

YouTube – Градење блокчејн за бизнис со проектот Hyperledger
Hyperledger Fabric Docs
Hyperledger ткаенина: дистрибуиран оперативен систем за дозволени блокчејнови

Благодарници

Би сакал да изразам длабока благодарност до моите колеги за нивната помош во подготовката на овој напис:
Николај Марин
Игор Капов
Дмитриј Горбачов
Александар Земцов
Екатерина Гушева

Извор: www.habr.com