Hyperledger Fabric for Dummies

Блокчейн платформа за предприятието

Добър ден, скъпи читатели, казвам се Николай Нефедов, аз съм технически специалист на IBM, в тази статия бих искал да ви запозная с блокчейн платформата - Hyperledger Fabric. Платформата е предназначена за изграждане на бизнес приложения на корпоративно ниво (Enterprise class). Нивото на статията е за неподготвени читатели с основни познания по IT технологии.

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 Fabric

Потребителско приложение (Submitting Client) е приложение, с което потребителите работят с блокчейн мрежата. За да работите, трябва да преминете през оторизация и да имате съответните права за различни видове действия в мрежата.

Партньорите (възлите) имат няколко роли:

• Endorsing Peer е възел, който симулира изпълнението на транзакция (изпълнява кода на интелигентния договор). След валидиране и изпълнение на интелигентния договор, възелът връща резултатите от изпълнението на клиентското приложение заедно със своя подпис.
• Услугата за поръчки е разпределена услуга на няколко възела, използва се за формиране на нови блокове от разпределената книга и създаване на последователност за изпълнение на транзакции. Услугата за поръчка не добавя нови блокове към регистъра (Преместено в Committing Peers за по-добра производителност).
• Committing Peer - възел, който съдържа разпределен регистър и добавя нови блокове към регистъра (които са формирани от услугата за поръчки). Всички предаващи партньори съдържат локално копие на разпределената книга. Партньорът за ангажиране, преди да добави нов блок локално, проверява всички транзакции в рамките на блока за валидност.

Политиката за одобрение е политика за проверка на транзакция за валидност. Тези политики дефинират необходимия набор от възли, на които интелигентният договор трябва да бъде изпълнен, за да може транзакцията да бъде призната за валидна.

Разпределеният регистър - 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.

Услугата за членство е услуга, чрез която членовете проверяват дали даден обект принадлежи към определена организация или канал.

Транзакцията в повечето случаи е запис на нови данни в разпределена книга.
Има и транзакции за създаване на канали или интелигентни договори. Транзакцията се инициира от потребителското приложение и завършва със запис в разпределената книга.

Канал (Channel) е затворена подмрежа, състояща се от двама или повече участници в блокчейн мрежата, предназначена за извършване на поверителни транзакции в рамките на ограничен, но известен кръг от участници. Каналът се определя от участниците, неговата разпределена книга, интелигентни договори, услуга за поръчки, WorldState. Всеки член на канала трябва да бъде оторизиран за достъп до канала и да има право да извършва различни видове транзакции. Оторизацията се извършва чрез услугата за членство.

Типичен сценарий за изпълнение на транзакция

След това бих искал да говоря за типичен сценарий за изпълнение на транзакция, като използвам примера на нашия проект.

Като част от нашия вътрешен проект създадохме мрежа Hyperledger Fabric, която е предназначена за регистриране и записване на студенти, влизащи в университети. Нашата мрежа се състои от две организации, собственост на Университет А и Университет Б. Всяка организация съдържа клиентско приложение, както и собствен партньор за ангажиране и одобрение. Ние също така използваме общата услуга за поръчки, услуга за членство и услуги на сертифициращ орган.

1) Иницииране на транзакция

Потребителското приложение, използващо Hyperledger Fabric SDK, инициира заявка за транзакция и изпраща заявката до възли с интелигентни договори. Заявката може да бъде за промяна или четене от разпределена книга (Ledger). Ако разгледаме пример за нашата тестова конфигурация на системата за счетоводство за студенти, тогава клиентското приложение изпраща заявка за транзакция до възлите на университети A и B, които са включени в политиката за одобрение на извикания интелигентен договор. Възел A е възел, който се намира в университета, който регистрира пристигащ студент, а възел B е възел, който се намира в друг университет. За да бъде запазена транзакция в разпределена книга, е необходимо всички възли, които според бизнес логиката трябва да одобрят транзакцията, да изпълнят успешно интелигентни договори със същия резултат. Потребителското приложение на възел A, използвайки инструментите Hyperledger Fabric SDK, получава политиката за одобрение (политика за одобрение) и открива към кои възли да изпрати заявка за транзакция. Това е заявка за извикване (извикване) на определен интелигентен договор (функция за верижен код), за да се прочетат или запишат определени данни в разпределената книга. Технически клиентският SDK използва съответната функция, на чийто API се предава обект с параметри на транзакция, а също така добавя клиентски подпис и изпраща тези данни чрез протоколен буфер през gRPC до съответните възли (одобряващи партньори).

Снимка 2. Иницииране на транзакция

2) Интелигентно изпълнение на договор

Възлите (Endorsing Peers), след като са получили заявка за извършване на транзакция, проверяват подписа на клиента и ако всичко е наред, те вземат обект с данните на заявката и изпълняват симулация на изпълнението на интелигентен договор (функция на верижен код) с тези данни. Интелигентният договор е бизнес логиката на транзакция, определен набор от условия и инструкции (в нашия случай това е проверка на студент, нов студент ли е или вече е регистриран, проверка на възрастта и т.н.). За да изпълните интелигентен договор, ще ви трябват и данни от WorldState. В резултат на симулацията на интелигентния договор на партньора за одобрение се получават два набора от данни - набор за четене и набор за запис. Read Set и Write Set са оригиналните и новите стойности на WorldState. (нов - в смисъла, получен чрез симулиране на интелигентен договор).

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

3) Връщане на данни към клиентското приложение

След симулацията на интелигентния договор, Endorsing Peers връщат към клиентското приложение първоначалните данни и резултата от симулацията, както и RW Set, подписан от техния сертификат. На този етап няма промени в разпределената книга. Клиентското приложение проверява подписа на одобряващия партньор и също така сравнява оригиналните данни за транзакцията, които са изпратени, и данните, които са върнати (т.е. проверява дали оригиналните данни, върху които е симулирана транзакцията, са били повредени). Ако транзакцията е била само за четене на данни от регистъра, тогава клиентското приложение съответно получава необходимия набор за четене и при това транзакцията обикновено завършва успешно, без да променя разпределения регистър. В случай на транзакция, която трябва да промени данните в регистъра, клиентското приложение допълнително проверява дали е внедрена политиката за одобрение. Възможно е клиентското приложение да не проверява резултата от изпълнението на политиката за одобрение, но платформата Hyperledger Fabric в този случай осигурява проверка на политиките на възлите (Comitting Peers) на етапа на добавяне на транзакция към регистъра.

Снимка 4. Връщане на данни към клиентското приложение

4) Изпращане на RW комплекти към поръчващи партньори

Клиентското приложение изпраща транзакцията заедно със свързаните с нея данни към услугата за поръчки. Това включва RW Set, подписи на одобряващи партньори и ID на канала.

Услуга за поръчка - Въз основа на името, основната функция на тази услуга е да изгражда входящи транзакции в правилния ред. Както и формирането на нов блок от разпределения регистър и гарантираната доставка на нови генерирани блокове до всички Commiting възли, като по този начин се гарантира съгласуваност на данните на всички възли, съдържащи разпределения регистър (Committing peers). В същото време самата услуга за поръчка не променя регистъра по никакъв начин. Услугата за поръчка е жизненоважен компонент на системата, така че представлява клъстер от няколко възела. Услугата за поръчки не проверява транзакцията за валидност, тя просто приема транзакция с определен идентификатор на канал, подрежда входящите транзакции в определен ред и формира нови блокове от разпределената книга от тях. Една услуга за поръчки може да обслужва няколко канала едновременно. Услугата за поръчки включва клъстер Kafka, който поддържа правилната (непроменена) опашка за транзакции (вижте точка 7).

Фигура 5. Изпращане на RW комплекти към подреждащи партньори

5) Изпращане на генерираните блокове до Committing Peer

Блоковете, формирани в услугата за поръчки, се излъчват към всички мрежови възли. Всеки възел, след като е получил нов блок, го проверява за съответствие с Правилата за одобряване, проверява дали всички одобряващи партньори са получили същия резултат (Write Set) в резултат на симулацията на интелигентния договор и също така проверява дали оригиналните стойности имат променени (т.е. - Read Set - данни, прочетени от интелигентния договор от WorldState) от инициирането на транзакцията. Ако всички условия са изпълнени, транзакцията се маркира като валидна, в противен случай транзакцията получава статус на невалидна.

Фигура 6. Изпращане на генерирани блокове към Committing Peer

6) Добавяне на блок към системния регистър

Всеки възел добавя транзакция към своето локално копие на разпределената книга и ако транзакцията е валидна, тогава Write Set се прилага към WorldState (текущото състояние), съответно се записват нови стойности на обекти, които са били засегнати от транзакцията . Ако транзакция получи токен, който не е валиден (например имаше две транзакции с едни и същи обекти в рамките на един и същ блок, тогава една от транзакциите няма да бъде валидна, тъй като първоначалните стойности вече са променени от друга транзакция ). Тази транзакция също се добавя към разпределената книга с невалиден маркер, но Write Set на тази транзакция не се прилага към текущото състояние на WorldState и съответно не променя обектите, участващи в транзакцията. След това се изпраща известие до потребителското приложение, че транзакцията е добавена към разпределената книга завинаги, както и състоянието на транзакцията, тоест дали е валидна или не ...

Снимка 7. Добавяне на блок към системния регистър

ПОРЪЧКА НА УСЛУГА

Услугата за поръчка се състои от клъстер Kafka със съответните възли на ZooKeeper и възли за услуга за поръчка (OSN), които се намират между клиентите на услугата за поръчка и клъстера Kafka. Kafka cluster е разпределена платформа за управление на потоци (съобщения), устойчива на грешки. Всеки канал (тема) в Kafka е неизменна поредица от записи, която поддържа само добавяне на нов запис (изтриването на съществуващ не е възможно). По-долу е дадена илюстрация на структурата на темата. Именно това свойство на Кафка се използва за изграждане на блокчейн платформата.

взето от kafka.apache.org

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

Полезни връзки

Youtube - Изграждане на блокчейн за бизнес с проекта Hyperledger
Hyperledger Fabric Docs
Hyperledger fabric: разпределена операционна система за разрешени блокчейни

Признания

Изказвам дълбоката си благодарност на колегите за помощта при подготовката на статията:
Николай Марина
Игор Хапов
Дмитрий Горбачов
Александър Земцов
Екатерина Гусева

Източник: www.habr.com