Platforma Blockchain dla przedsiębiorstwa
Dzień dobry, drodzy czytelnicy, nazywam się Nikolay Nefedov, jestem specjalistą technicznym w IBM, w tym artykule chciałbym przedstawić Państwu platformę blockchain - Hyperledger Fabric. Platforma przeznaczona jest do budowy aplikacji biznesowych klasy Enterprise. Poziom artykułu przeznaczony jest dla czytelników nieprzygotowanych, posiadających podstawową wiedzę z zakresu technologii informatycznych.
Hyperledger Fabric to projekt open source, jedna z gałęzi projektu open source Hyperledger, konsorcjum Linux Foundation. Hyperledger Fabric został pierwotnie zapoczątkowany przez Digital Assets i IBM. Główną cechą platformy Hyperledger Fabric jest jej skupienie na zastosowaniach korporacyjnych. Dlatego platforma została opracowana z uwzględnieniem dużej szybkości transakcji i ich niskiego kosztu, a także identyfikacji wszystkich uczestników. Korzyści te osiągane są poprzez wydzielenie usługi weryfikacji transakcji i utworzenie nowych bloków rozproszonego rejestru, a także wykorzystanie centrum certyfikacji i autoryzacji uczestników.
Mój artykuł jest częścią cyklu artykułów o Hyperledger Fabric, w ramach których opisujemy projekt systemu rejestracji studentów wchodzących na uczelnię.
Ogólna architektura Hyperledger Fabric
Hyperledger Fabric to rozproszona sieć typu blockchain składająca się z różnych komponentów funkcjonalnych instalowanych w węzłach sieci. Komponenty Hyperledger Fabric to kontenery Docker, które można bezpłatnie pobrać z DockerHub. Hyperledger Fabric można także uruchomić w środowisku Kubernetes.
Do napisania inteligentnych kontraktów (kod łańcuchowy w kontekście Hyperledger Fabric) wykorzystaliśmy Golang (chociaż Hyperledger Fabric pozwala na użycie innych języków). Aby opracować niestandardową aplikację, w naszym przypadku wykorzystaliśmy Node.js z odpowiednim pakietem SDK Hyperledger Fabric.
Węzły realizują logikę biznesową (smart kontrakt) – chaincode, przechowują stan rozproszonego rejestru (dane księgi głównej) oraz realizują inne usługi systemowe platformy. Węzeł jest tylko jednostką logiczną; na tym samym serwerze fizycznym mogą istnieć różne węzły. Dużo ważniejsze jest to, w jaki sposób węzły są zgrupowane (domena zaufana) i z jakimi funkcjami sieci blockchain są powiązane.
Ogólna architektura wygląda następująco:
Rysunek 1. Ogólna architektura Hyperledger Fabric
Aplikacja użytkownika (klient przesyłający) to aplikacja, za pomocą której użytkownicy pracują z siecią blockchain. Aby pracować, musisz być autoryzowany i posiadać odpowiednie uprawnienia do różnego rodzaju działań w sieci.
Rówieśnicy występują w kilku rolach:
- Endorsing Peer to węzeł symulujący realizację transakcji (wykonujący inteligentny kod kontraktu). Po weryfikacji i wykonaniu inteligentnego kontraktu węzeł zwraca do aplikacji klienckiej wyniki wykonania wraz z jego podpisem.
- Usługa zamawiania jest usługą rozproszoną na kilku węzłach, służącą do generowania nowych bloków rozproszonego rejestru i tworzenia kolejki do realizacji transakcji. Usługa zamawiania nie dodaje nowych bloków do rejestru (ta funkcja została przeniesiona do Committing Peers w celu poprawy wydajności).
- Committing Peer to węzeł, który zawiera rozproszony rejestr i dodaje do rejestru nowe bloki (które zostały wygenerowane przez usługę zamawiania). Wszystkie elementy równorzędne zatwierdzające zawierają lokalną kopię rozproszonej księgi. Committing Peer sprawdza ważność wszystkich transakcji w bloku przed lokalnym dodaniem nowego bloku.
Polityka zatwierdzania to polityka sprawdzania ważności transakcji. Polityki te definiują wymagany zestaw węzłów, na których musi zostać zrealizowany inteligentny kontrakt, aby transakcja została uznana za ważną.
Rejestr rozproszony – Lerger – składa się z dwóch części: WolrldState (zwanej także State DataBase) oraz BlockChain.
BlockChain to łańcuch bloków przechowujących zapisy wszystkich zmian, które nastąpiły w rozproszonych obiektach rejestru.
WolrldState to komponent księgi rozproszonej, który przechowuje bieżące (nowoczesne) wartości wszystkich obiektów księgi rozproszonej.
WorldState to baza danych w wersji podstawowej - LevelDB lub bardziej złożonej - CouchDB, która zawiera pary klucz-wartość np.: Imię - Ivan, Nazwisko - Ivanov, data rejestracji w systemie - 12.12.21 , data urodzenia - 17.12.1961 itd. WorldState i rozproszony rejestr muszą być spójne wśród wszystkich uczestników danego kanału.
Ponieważ Hyperledger Fabric jest siecią, w której wszyscy uczestnicy są znani i uwierzytelniani, korzysta z dedykowanego urzędu certyfikacji – CA (Certification Authority). CA działa w oparciu o standard X.509 oraz infrastrukturę klucza publicznego – PKI.
Usługa członkostwa to usługa, za pośrednictwem której członkowie sprawdzają, czy obiekt należy do określonej organizacji lub kanału.
Transakcja – w większości przypadków polega na zapisie nowych danych do rozproszonego rejestru.
Nie brakuje także transakcji tworzenia kanałów czy inteligentnych kontraktów. Transakcja inicjowana jest przez aplikację użytkownika i kończy się zapisem w księdze rozproszonej.
Kanał to zamknięta podsieć składająca się z dwóch lub więcej uczestników sieci typu blockchain, zaprojektowana w celu przeprowadzania poufnych transakcji w ramach ograniczonego, ale znanego kręgu uczestników. Kanał jest określany przez uczestników, jego rozproszony rejestr, inteligentne kontrakty, usługę zamawiania, stan świata. Każdy uczestnik kanału musi posiadać uprawnienia dostępu do kanału oraz możliwość dokonywania różnego rodzaju transakcji. Autoryzacja odbywa się za pomocą Serwisu Członkostwa.
Typowy scenariusz realizacji transakcji
Następnie chciałbym omówić typowy scenariusz realizacji transakcji na przykładzie naszego projektu.
W ramach naszego wewnętrznego projektu stworzyliśmy sieć Hyperledger Fabric, która ma na celu rejestrację i rozliczanie studentów rozpoczynających naukę na uczelniach. Nasza sieć składa się z dwóch organizacji należących do Uniwersytetu A i Uniwersytetu B. Każda organizacja zawiera aplikację kliencką, a także własnego partnera zatwierdzającego i zatwierdzającego. Korzystamy także z usług wspólnych: Serwis Zamówień, Serwis Członkostwa oraz Urząd Certyfikacji.
1) Rozpoczęcie Transakcji
Aplikacja użytkownika korzystająca z zestawu SDK Hyperledger Fabric inicjuje żądanie transakcji i wysyła je do węzłów z inteligentnymi kontraktami. Żądanie może dotyczyć zmiany lub odczytu z rejestru rozproszonego (Księgi). Jeśli rozważymy przykładową konfigurację naszego systemu testowego do rozliczania studentów uczelni, aplikacja kliencka wysyła żądanie transakcji do węzłów uczelni A i B, które są objęte Polityką Endorsmentu tzw. inteligentnego kontraktu. Węzeł A to węzeł, który znajduje się na uczelni, która rejestruje studenta przyjeżdżającego, a węzeł B to węzeł, który znajduje się na innej uczelni. Aby transakcja została zapisana w rozproszonym rejestrze, konieczne jest, aby wszystkie węzły, które zgodnie z logiką biznesową muszą zatwierdzić transakcję, pomyślnie wykonały inteligentne kontrakty z tym samym skutkiem. Węzeł Aplikacja użytkownika, korzystając z narzędzi zestawu SDK Hyperledger Fabric, uzyskuje politykę poparcia i dowiaduje się, do których węzłów wysłać żądanie transakcji. Jest to żądanie wywołania konkretnego inteligentnego kontraktu (funkcji kodu łańcuchowego) w celu odczytania lub zapisania określonych danych w rejestrze rozproszonym. Technicznie rzecz biorąc, klient SDK wykorzystuje odpowiednią funkcję, której API przekazuje określony obiekt z parametrami transakcji, a także dodaje podpis klienta i wysyła te dane poprzez bufor protokołu przez gRPC do odpowiednich węzłów (peerów potwierdzających).
Rysunek 2. Inicjowanie transakcji
2) Wykonanie inteligentnego kontraktu
Węzły (Endorsing Peers) po otrzymaniu żądania przeprowadzenia transakcji sprawdzają podpis klienta i jeśli wszystko jest w porządku, pobierają obiekt z danymi żądania i przeprowadzają symulację wykonania inteligentnego kontraktu (funkcja chaincode) za pomocą te dane. Inteligentny kontrakt to logika biznesowa transakcji, określony zestaw warunków i instrukcji (w naszym przypadku jest to weryfikacja ucznia, czy jest to nowy student, czy jest już zarejestrowany, weryfikacja wieku itp.). Do realizacji inteligentnej umowy potrzebne będą także dane z WorldState. W wyniku symulacji inteligentnego kontraktu na partnerze Endorsing uzyskiwane są dwa zestawy danych – Read Set i Write Set. Read Set i Write Set to oryginalne i nowe wartości WorldState. (nowy – w sensie uzyskanym podczas symulacji inteligentnego kontraktu).
Rysunek 3. Zawarcie inteligentnego kontraktu
3) Zwrócenie danych do aplikacji klienckiej
Po przeprowadzeniu symulacji inteligentnego kontraktu Endorsing Peers zwracają do aplikacji klienckiej oryginalne dane i wynik symulacji, a także zestaw RW podpisany swoim certyfikatem. Na tym etapie w rozproszonym rejestrze nie zachodzą żadne zmiany. Aplikacja kliencka sprawdza podpis Endorsing Peer, a także porównuje przesłane oryginalne dane transakcyjne z danymi zwróconymi (czyli sprawdza, czy oryginalne dane, na których symulowana była transakcja, nie zostały zniekształcone). Jeżeli transakcja dotyczyła jedynie odczytu danych z rejestru, wówczas aplikacja kliencka otrzymuje odpowiedni zestaw odczytu, co zwykle kończy pomyślnie transakcję bez zmiany rozproszonego rejestru. W przypadku transakcji wymagającej zmiany danych w rejestrze aplikacja kliencka dodatkowo sprawdza realizację Polityki Endorsingu. Może się zdarzyć, że aplikacja kliencka nie sprawdzi wyniku wykonania Polityki Endorsement, jednak platforma Hyperledger Fabric w tym przypadku umożliwia sprawdzenie polityk na węzłach (Committing Peers) już na etapie dodawania transakcji do rejestru.
Rysunek 4. Zwrot danych do aplikacji klienckiej
4) Wysyłanie zestawów RW do partnerów zamawiających
Aplikacja kliencka przesyła transakcję wraz z towarzyszącymi jej danymi do serwisu Zamówienia. Obejmuje to zestaw RW, podpisy partnerów potwierdzających i identyfikator kanału.
Usługa zamawiania – jak wynika z nazwy, główną funkcją tej usługi jest porządkowanie transakcji przychodzących we właściwej kolejności. Jak również utworzenie nowego bloku rozproszonego rejestru i gwarantowane dostarczenie nowych wygenerowanych bloków do wszystkich węzłów Commitujących, zapewniając w ten sposób spójność danych na wszystkich węzłach zawierających rejestr rozproszony (peer Commitujący). Jednocześnie sama Usługa Zamawiania nie powoduje w żaden sposób zmian w rejestrze. Usługa zamawiania jest istotnym elementem systemu, dlatego stanowi skupisko kilku węzłów. Usługa Zlecania nie sprawdza ważności transakcji, po prostu akceptuje transakcję z określonym identyfikatorem kanału, porządkuje transakcje przychodzące w określonej kolejności i tworzy z nich nowe bloki rozproszonego rejestru. Jedna Usługa Zamawiania może obsługiwać kilka kanałów jednocześnie. W ramach Usługi Zamawiania znajduje się klaster Kafka, który utrzymuje poprawną (niezmienną) kolejkę transakcji (patrz punkt 7).
Rysunek 5. Wysyłanie zestawów RW do partnerów zamawiających
5) Wysyłanie wygenerowanych bloków do partnera zatwierdzającego
Bloki wygenerowane w Serwisie Zamówień są transmitowane (rozgłaszane) do wszystkich węzłów sieci. Każdy węzeł po otrzymaniu nowego bloku sprawdza go pod kątem zgodności z Polityką Endorsingu, sprawdza, czy wszyscy Endorsing Peers otrzymali ten sam wynik (Write Set) w wyniku symulacji inteligentnego kontraktu, a także sprawdza, czy oryginalne wartości mają uległy zmianie (czyli Read Set – dane odczytane przez smart kontrakt z WorldState) od momentu zainicjowania transakcji. Jeżeli wszystkie warunki zostaną spełnione, transakcja zostanie oznaczona jako ważna, w przeciwnym razie transakcja otrzyma status nieważna.
Rysunek 6. Wysyłanie wygenerowanych bloków do Committing Peera
6) Dodanie bloku do rejestru
Każdy węzeł dodaje transakcję do swojej lokalnej kopii rozproszonego rejestru i jeśli transakcja jest ważna, wówczas do stanu świata (stanu bieżącego) stosowany jest zestaw zapisu (Write Set) i odpowiednio nowe wartości obiektów, na które miała wpływ transakcja jest zapisana. Jeżeli do transakcji otrzymano nieprawidłowy token (np. w ramach tego samego bloku miały miejsce dwie transakcje z tymi samymi obiektami, wówczas jedna z transakcji okaże się nieważna, gdyż pierwotne wartości zostały już zmienione przez inną transakcja). Ta transakcja jest również dodawana do księgi rozproszonej z nieprawidłowym tokenem, ale zestaw zapisu tej transakcji nie jest stosowany do bieżącego stanu świata i w związku z tym nie zmienia obiektów uczestniczących w transakcji. Następnie do aplikacji użytkownika wysyłane jest powiadomienie, że transakcja została trwale dodana do rozproszonego rejestru, a także status transakcji, czyli czy jest ona ważna czy nie...
Rysunek 7. Dodanie bloku do rejestru
ZAMÓWIENIE USŁUGI
Usługa zamawiania składa się z klastra Kafka z odpowiednimi węzłami ZooKeeper i węzłami usługi zamawiania (OSN), które znajdują się pomiędzy klientami usługi zamawiania a klastrem Kafka. Klaster Kafka to rozproszona, odporna na błędy platforma zarządzania przepływem (komunikatami). Każdy kanał (temat) w Kafce jest niezmienną sekwencją rekordów, która obsługuje jedynie dodanie nowego rekordu (usunięcie istniejącego nie jest możliwe). Poniżej przedstawiono ilustrację struktury tematu. To właśnie ta właściwość Kafki jest wykorzystywana do budowy platformy blockchain.
pobrane z kafka.apache.org
- Rysunek 8. Struktura tematyczna zamówienia usługi*
Przydatne linki
Podziękowanie
Chciałbym wyrazić głęboką wdzięczność moim współpracownikom za pomoc w przygotowaniu tego artykułu:
Nikołaj Marin
Igor Chapow
Dmitrij Gorbaczow
Aleksander Zemcow
Ekaterina Gusiewa
Źródło: www.habr.com