A Blockchain Platform for the Enterprise
Добры дзень, дарагія чытачы, мяне клічуць Мікалай Няфёдаў, я тэхнічны спецыяліст кампаніі IBM, у гэтым артыкуле я хацеў бы пазнаёміць вас з блокчейн платформай - Hyperledger Fabric. Платформа прызначана для пабудовы бізнес прыкладанняў ўзроўню прадпрыемства (Enterprise class). Узровень артыкула - для непадрыхтаваных чытачоў, якія маюць базавыя веды IT тэхналогій.
Hyperledger Fabric гэта open-source праект, адна з галін адчыненага праекту Hyperledger, кансорцыўма Linux Foundation. Hyperledger Fabric быў першапачаткова стартаваны Digital Assets і IBM. Асноўнай асаблівасцю платформы Hyperledger Fabric з'яўляецца накіраванасць на карпаратыўнае прымяненне. Таму платформа распрацоўвалася з улікам забеспячэння высокай хуткасці правядзення транзакцый і іх нізкага кошту, а таксама ідэнтыфікацыі ўсіх удзельнікаў. Гэтыя перавагі дасягаюцца за кошт раздзялення службы праверкі транзакцый і фарміравання новых блокаў размеркаванага рэестра, а таксама прымянення цэнтра сертыфікацыі і аўтарызацыі ўдзельнікаў.
Мая артыкул гэта частка цыклу артыкулаў аб Hyperledger Fabric у рамках якой мы апісваем праект сістэмы па ўліку студэнтаў, якія паступаюць у ВНУ.
Агульная архітэктура Hyperledger Fabric
Hyperledger Fabric - гэта размеркаваная блокчейн сетка, якая складаецца з розных функцыянальных кампанентаў, якія ўстанаўліваюцца на вузлы сеткі. Кампаненты Hyperledger Fabric уяўляюць з сябе Docker кантэйнеры, якія можна свабодна спампаваць з DockerHub. Hyperledger Fabric таксама можна запусціць у асяроддзі Kubernetes.
Для напісання смарт-кантрактаў (chaincode у кантэксце Hyperledger Fabric) мы выкарыстоўвалі Golang (хоць Hyperledger Fabric дазваляе выкарыстоўваць і іншыя мовы). Для распрацоўкі карыстацкага дадатку ў нашым выпадку выкарыстоўваўся Node.js з адпаведным Hyperledger Fabric SDK.
На вузлах выконваецца бізнэс логіка (смарт-кантракт) - chaincode, захоўваецца стан размеркаванага рэестра (ledger data) і выконваюцца іншыя сістэмныя службы платформы. Вузел - гэта толькі лагічная адзінка, розныя вузлы могуць існаваць на адным фізічным серверы. Значна важней - гэта як вузлы згрупаваныя (Trusted domain) і з якімі функцыямі блокчейн сеткі яны асацыяваныя.
Агульная архітэктура выглядае наступным чынам:
Picture 1. Агульная Архітэктура Hyperledger Fabric
Карыстальніцкае прыкладанне (Submitting Client) - дадатак, з дапамогай якога карыстальнікі працуюць з блокчейн сеткай. Для працы неабходна прайсці аўтарызацыю і валодаць адпаведнымі правамі на розныя дзеянні ў сетцы.
Peers (Вузлы) бываюць некалькіх роляў:
- Endorsing Peer - вузел, які сімулюе выкананне транзакцыі (выконвае код смарт-кантракту). Пасля выканання праверкі і выканання смарт-кантракта вузел вяртае вынікі выканання кліенцкаму з дадаткам разам са сваім подпісам.
- Ordering Service - размеркаваны сэрвіс на некалькіх вузлах, служыць для фарміравання новых блокаў размеркаванага рэестра і стварэння чарговасці выканання транзакцый. Ordering Service не дадае новыя блокі ў рэестр (Для павышэння прадукцыйнасці гэтая функцыя перанесена на Committing Peers).
- Committing Peer - вузел, які змяшчае размеркаваны рэестр і дадае новыя блокі да рэестру (якія сфарміраваў Ordering Service). Усе Committing Peer утрымоўваюць лакальную копію размеркаванага рэестра. Committing Peer перад лакальным даданнем новага блока правярае ўсе транзакцыі ўнутры блока на валіднасць.
Endorsement Policy - гэта палітыка праверкі транзакцыі на валіднасць. Гэтыя палітыкі вызначаюць неабходны набор вузлоў, на якіх павінен быць выкананы смарт-кантракт для таго, каб транзакцыя была прызнана валіднай.
Размеркаваны Рэестр - Lerger - складаецца з двух частак: WolrldState (таксама называецца - State DataBase) і BlockChain.
BlockChain - гэта ланцужок блокаў, якая захоўвае запісы аб усіх зменах, якія адбыліся з аб'ектамі размеркаванага рэестра.
WolrldState - гэта кампанент размеркаванага рэестра, які захоўвае бягучыя (крайнія) значэння ўсіх аб'ектаў размеркаванага рэестра.
WorldState уяўляе сабой базу дадзеных, у базавым варыянце - LevelDB або больш складаная - CouchDB, якая змяшчае пары ключ - значэнне, напрыклад: Імя - Іван, Прозвішча - Іваноў, дата рэгістрацыі ў сістэме - 12.12.21, дата нараджэння - 17.12.1961, і г.д. WorldState і размеркаваны рэестр павінны быць кансістэнтныя ва ўсіх удзельнікаў дадзенага канала.
Паколькі Hyperledger Fabric гэта сетка, у якой усе ўдзельнікі вядомыя і аўтэнтыфікаваны, тут выкарыстоўваецца выдзелены цэнтр сертыфікацыі – CA (Certification Authority). CA працуе на аснове X.509 стандарту і інфраструктуры публічных ключоў - PKI.
Membership Service - гэта служба, праз якую ўдзельнікі ажыццяўляюць праверку прыналежнасці аб'екта да той ці іншай арганізацыі або каналу.
Транзакцыя - у большасці выпадкаў, гэта запіс новых дадзеных у размеркаваны рэестр.
Таксама транзакцыі бываюць на стварэнне каналаў ці смарт-кантрактаў. Транзакцыя ініцыюецца карыстацкім дадаткам і заканчваецца запісам у размеркаваны рэестр.
Канал (Channel) - гэта закрытая падсетка, якая складаецца з двух або больш удзельнікаў блокчейн сеткі, прызначаная для правядзення канфідэнцыйных транзакцый усярэдзіне абмежаванага, але вядомага, круга ўдзельнікаў. Канал вызначаецца ўдзельнікамі, сваім размеркаваным рэестрам, смарт-кантрактамі, Ordering Service, WorldState. Кожны ўдзельнік канала павінен быць аўтарызаваны на доступ да канала і мець права выконваць розныя транзакцыі. Аўтарызацыя выконваецца з дапамогай Membership Service.
Тыпавы сцэнар выканання транзакцыі
Далей я хацеў бы распавесці пра тыпавы сцэнар выканання транзакцыі на прыкладзе нашага праекту.
У рамках нашага ўнутранага праекта мы стварылі Hyperledger Fabric сетку, якая прызначана для рэгістрацыі і ўліку студэнтаў, якія паступаюць у ВНУ. Наша сетка складаецца з двух арганізацый, якія належаць ВНУ A і ВНУ B. Кожная арганізацыя змяшчае кліенцкае прыкладанне, а таксама свае Committing і Endorsing Peer. Таксама мы выкарыстоўваем агульныя сэрвісы Ordering Service, Memebership Service і Certification Authority.
1) Ініцыяцыя транзакцыі
Карыстальніцкі дадатак, выкарыстоўваючы Hyperledger Fabric SDK, ініцыюе запыт на транзакцыю і адпраўляе запыт на вузлы са смарт-кантрактамі. Запыт можа быць на змену або чытанне з размеркаванага рэестра (Ledger). Калі разглядаць прыклад нашай тэставай канфігурацыі сістэмы для ўліку студэнтаў ВНУ, то кліенцкі дадатак пасылае запыт на транзакцыю на вузлы ВНУ A і B, якія ўключаны ў Endorsement policy выкліканага смарт-кантракта. Вузел A — гэта вузел, які знаходзіцца ў ВНУ, які рэгіструе студэнта, які паступае, а вузел B — гэта вузел, які знаходзіцца ў іншай ВНУ. Для таго каб транзакцыя была захавана ў размеркаваны рэестр, неабходна, каб усе вузлы, якія згодна з бізнес логікай павінны адобрыць транзакцыю, паспяхова выканалі смарт-кантракты з аднолькавым вынікам. Карыстальніцкі дадатак вузла A, выкарыстоўваючы прылады Hyperledger Fabric SDK, атрымлівае Endorsement policy (палітыка адабрэння) і даведаецца, на якія вузлы трэба адправіць запыт на транзакцыю. Гэта запыт на выклік (invoke) вызначанага смарт-кантракту (chaincode function), каб прачытаць ці запісаць пэўныя дадзеныя ў размеркаваны рэестр. Тэхнічна, кліенцкае SDK выкарыстоўвае адпаведную функцыю, API якой перадаецца нейкі аб'ект з параметрамі транзакцыі, а таксама дадае кліенцкі подпіс і адпраўляе гэтыя дадзеныя па пратаколе protocol buffer over gRPC на адпаведныя вузлы (endorsing peers).
Picture 2. Ініцыяцыя транзакцыі
2) Выкананне смарт-кантракта
Вузлы (Endorsing Peers), атрымаўшы запыт на правядзенне транзакцыі, правяраюць кліенцкі подпіс і калі ўсё ў парадку, то бяруць аб'ект з дадзенымі запыту і запускаюць сімуляцыю выканання смарт-кантракта (chaincode function) з гэтымі дадзенымі. Смарт-кантракт - гэта бізнес логіка транзакцыі, пэўны набор умоў і інструкцый (у нашым выпадку гэта праверка студэнта, новы гэта студэнт, ці ён ужо зарэгістраваны, праверка ўзросту і г.д.). Для выканання смарт-кантракта таксама спатрэбяцца дадзеныя з WorldState. У выніку сімуляцыі смарт-кантракту на Endorsing peer атрымліваецца два наборы дадзеных - Read Set і Write Set. Read Set і Write Set - гэта зыходныя і новыя значэння WorldState. (новыя - у сэнсе атрыманыя пры сімуляцыі смарт-кантракту).
Picture 3. Выкананне смарт-кантракта
3) Зварот дадзеных кліенцкаму з дадаткам
Пасля правядзення сімуляцыі смарт-кантракта Endorsing Peers вяртаюць кліенцкаму з дадаткам зыходныя дадзеныя і вынік сімуляцыі, а таксама RW Set, падпісаныя сваім сертыфікатам. На дадзеным этапе ніякіх змен у размеркаваным рэестры не адбываецца. Кліенцкае прыкладанне правярае подпіс Endorsing Peer, а таксама параўноўвае зыходныя дадзеныя транзакцыі, якія былі адпраўленыя, і дадзеныя, якія вярнуліся (гэта значыць правярае не сказіліся ці зыходныя дадзеныя над якімі праводзілася сімуляцыя транзакцыі). Калі транзакцыя была толькі на чытанне дадзеных з рэестра, то кліенцкі дадатак адпаведна атрымлівае неабходны Read Set і на гэтым звычайна транзакцыя паспяхова завяршаецца без змены размеркаванага рэестра. У выпадку транзакцыі, якая павінна змяніць дадзеныя ў рэестры, кліенцкі дадатак дадаткова праводзіць праверку выканання Endorsing policy. Магчымая сітуацыя, калі кліенцкае прыкладанне не правярае вынік выканання Endorsement Policy, але платформа Hyperledger Fabric у дадзеным выпадку прадугледжвае праверку палітык на вузлах (Comitting Peers) на стадыі дадання транзакцыі ў рэестр.
Picture 4. Зварот дадзеных кліенцкаму з дадаткам
4) Адпраўка RW sets на Ordering Peers
Кліенцкае прыкладанне адпраўляе транзакцыю разам са спадарожнымі дадзенымі на Ordering service. Сюды ўключаюцца RW Set, подпісы Endorsing peers, а таксама ідэнтыфікатар канала (Channel ID).
Ordering service - зыходзячы з назвы, асноўная функцыя гэтага сэрвісу - пабудова транзакцый, якія паступаюць у правільным парадку. А таксама фармаванне новага блока размеркаванага рэестра і гарантаваную дастаўку новых сфармаваных блокаў усім Commiting вузлам, такім чынам забяспечваючы кансістэнтнасць дадзеных на ўсіх вузлах утрымоўвальных размеркаваны рэестр (Commiting peers). Пры гэтым сам Ordering service ніяк не мяняе рэестр. Ordering Service гэта жыццёва важны кампанент сістэмы, таму ён уяўляе з сябе кластар з некалькіх вузлоў. Ordering Service не правярае транзакцыю на валіднасць, ён проста прымае транзакцыю з вызначаным ідэнтыфікатарам канала, выбудоўвае паступаючыя транзакцыі ў вызначаным парадку і фармуе з іх новыя блокі размеркаванага рэестра. Адзін Ordering Service можа абслугоўваць некалькі каналаў адначасова. У склад Ordering Service уваходзіць Kafka кластар, які і падтрымлівае правільную (нязменную) чаргу транзакцый (гл. Пункт 7).
Picture 5. Адпраўка RW sets на Ordering Peers
5) Адпраўка сфармаваных блокаў на Committing Peer
Сфармаваныя ў Ordering Service блокі перадаюцца (broadcast) усім вузлам сеткі. Кожны вузел, атрымаўшы новы блок, правярае яго на адпаведнасць Endorsing Policy, правярае, што ўсе Endorsing Peers атрымалі аднолькавы вынік (Write Set) у выніку сімуляцыі смарт-кантракту, а таксама правярае, ці не змяніліся зыходныя значэння (гэта значыць - Read Set - дадзеныя прачытаныя смарт-кантрактам з WorldState) з моманту ініцыяцыі транзакцыі. Калі ўсе ўмовы выкананы - транзакцыя пазначаецца валіднай, у адваротным выпадку, транзакцыя атрымлівае статус не валіднай.
Picture 6. Адпраўка сфармаваных блокаў на Committing Peer
6) Даданні блока ў рэестр
Кожны вузел дадае транзакцыю ў сваю лакальную копію размеркаванага рэестра, пры гэтым, калі транзакцыя валідна, то Write Set ужываецца да WorldState (бягучаму стану), адпаведна, запісваюцца новыя значэнні аб'ектаў, якія закраналіся транзакцыяй. У выпадку, калі транзакцыя атрымала маркер - не валіднай (напрыклад, адбылося дзве транзакцыі з аднымі і тымі ж аб'ектамі ў рамках аднаго блока, то адна з транзакцый атрымаецца не валіднай, паколькі зыходныя велічыні ўжо зменены іншай транзакцыяй). Гэтая транзакцыя таксама дадаецца ў размеркаваны рэестр з маркерам не валіднай, але Write Set гэтай транзакцыі не прымяняецца да бягучага стану WorldState і, адпаведна, не змяняе аб'екты, якія ўдзельнічаюць у транзакцыі. Пасля гэтага карыстацкаму з дадаткам адпраўляецца натыфікацыя, што транзакцыя на векі вечныя дададзена ў размеркаваны рэестр, а таксама статус транзакцыі, гэта значыць валідна яна ці не…
Picture 7. Даданні блока ў рэестр
ORDERING SERVICE
Ordering Service складаецца з Kafka кластара з адпаведнымі ZooKeeper нодамі і Ordering Service Nodes (OSN), якія стаяць паміж кліентамі Ordering service і Kafka кластарам. Kafka кластар - гэта размеркаваная, адмоваўстойлівая платформа кіравання патокамі (паведамленнямі). Кожны канал (топік) у Kafka - гэта нязменная паслядоўнасць запісаў, якая падтрымлівае толькі даданне новага запісу (выдаленне існуючага немагчыма). Ілюстрацыя структуры топіка прыведзена ніжэй. Менавіта гэтая ўласцівасць Kafka і выкарыстоўваецца для пабудовы блокчейн платформы.
узята з сайта kafka.apache.org
- Picture 8. Ordering Service Topic Structure*
Карысныя спасылкі
падзякі
Выказваю вялікую падзяку за дапамогу ў падрыхтоўцы артыкула маім калегам:
Мікалаю Марыну
Ігару Хапаву
Дзмітрыю Гарбачову
Аляксандру Зямцову
Кацярыне Гусевай
Крыніца: habr.com