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 якої передається певний об'єкт з параметрами транзакції, а також додає клієнтський підпис і надсилає ці дані протоколом 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