Ulubionym pytaniem o każdą rozproszoną systemu od osoby nietechnicznej jest „Ile tps ma wasz blockchain?”. Jednak liczba podana w odpowiedzi zazwyczaj ma niewiele wspólnego z tym, co chciałby usłyszeć pytający. W rzeczywistości chciał zapytać „czy wasz blockchain spełnia moje wymagania biznesowe”, a te wymagania to nie jedna liczba, a wiele warunków — chodzi tu o odporność sieci, wymagania dotyczące finalności, rozmiary, charakter transakcji i wiele innych parametrów. Dlatego odpowiedź na pytanie „ile tps” z pewnością nie będzie prosta i prawie nigdy nie będzie pełna. Rozproszony system z dziesiątkami i setkami węzłów, wykonującymi dość złożone obliczenia, może znajdować się w ogromnej liczbie różnych stanów, związanych ze stanem sieci, zawartością blockchaina, awariami technicznymi, problemami ekonomicznymi, atakami na sieć i wieloma innymi przyczynami. Etapy, na których mogą wystąpić problemy z wydajnością, różnią się od tradycyjnych usług, a serwer sieci blockchain to serwis sieciowy, łączący w sobie funkcjonalność bazy danych, serwera webowego i klienta torrent, co czyni go niezwykle skomplikowanym pod względem profilu obciążenia dla wszystkich podsystemów: procesora, pamięci, sieci, storage.

Zdarzyło się, że zdecentralizowane sieci i blockchains są dość specyficznym i nietypowym oprogramowaniem dla programistów oprogramowania scentralizowanego. Dlatego chciałbym omówić ważne aspekty wydajności i odporności zdecentralizowanych sieci, podejścia do ich pomiaru oraz znajdowania wąskich gardeł. Zbadaamy różne problemy związane z wydajnością, które ograniczają szybkość świadczenia usług użytkownikom blockchainów i zwrócimy uwagę na cechy charakterystyczne dla tego rodzaju oprogramowania.

Etapy żądania usługi przez klienta blockchaina

Aby uczciwie ocenić jakość dowolnej bardziej złożonej usługi, należy uwzględnić nie tylko wartości średnie, ale także maksymalne/minimalne, mediany i percentyle. Teoretycznie można mówić o 1000 tps w jakimś blockchainie, ale jeśli 900 transakcji przebiegło z ogromną prędkością, a 100 — „utknęło” na kilka sekund, to średni czas obliczony dla wszystkich transakcji nie jest do końca uczciwą metryką dla klienta, który nie mógł zakończyć transakcji w ciągu kilku sekund. Czasowe „dziury”, spowodowane pominiętymi rundami konsensusu lub podziałem sieci, mogą znacząco wpłynąć na usługę, która na stanowiskach testowych wykazywała doskonałą wydajność.

Aby zidentyfikować takie wąskie gardła, należy dobrze zrozumieć etapy, na których rzeczywisty blockchain może napotykać trudności w obsłudze użytkowników. Opiszmy cykl dostarczania i przetwarzania transakcji oraz uzyskiwania nowego stanu blockchaina, z którego klient może upewnić się, że jego transakcja została przetworzona i uwzględniona.

transakcja jest tworzona na kliencie
transakcja jest podpisywana na kliencie
klient wybiera jeden z węzłów i wysyła do niego swoją transakcję
klient subskrybuje aktualizacje bazy danych stanu węzła, czekając na wyniki przetwarzania swojej transakcji
węzeł rozprzestrzenia transakcję po sieci p2p
kilku lub jeden BP (producent bloków) przetwarza zgromadzone transakcje, aktualizując bazę danych stanu
BP tworzy nowy blok, przetwarzając potrzebną liczbę transakcji
BP rozprzestrzenia nowy blok po sieci p2p
nowy blok jest dostarczany do węzła, z którym komunikuje się klient
węzeł aktualizuje bazę danych stanu
węzeł widzi aktualizację dotyczącą klienta i wysyła mu powiadomienie o transakcji

Przyjrzyjmy się teraz szczegółowo tym krokom i opiszmy potencjalne problemy z wydajnością na każdym etapie. W odróżnieniu od systemów scentralizowanych, weźmiemy również pod uwagę wykonanie kodu na klientach sieci. Dość często przy pomiarze tps czas przetwarzania transakcji zbierany jest z węzłów, a nie z klienta — to nie do końca sprawiedliwe. Klientowi jest obojętne, jak szybko węzeł przetworzył jego transakcję, najważniejsze dla niego jest moment, kiedy wiarygodne informacje o tej transakcji, zawarte w łańcuchu bloków, staną się dla niego dostępne. To właśnie ta metryka jest de facto czasem wykonania transakcji. Oznacza to, że różni klienci, nawet wysyłając tę samą transakcję, mogą uzyskać zupełnie różne czasy, które zależą od kanału, obciążenia i bliskości węzła itd. Dlatego niezwykle ważne jest mierzenie tego czasu na klientach, ponieważ to właśnie ten parametr należy optymalizować.

Przygotowanie transakcji po stronie klienta

Zacznijmy od pierwszych dwóch punktów: transakcja jest formułowana i podpisywana przez klienta. Jak to dziwnie brzmi, to także może być wąskim gardłem wydajności bloku łańcucha z perspektywy klienta. To nie jest typowe dla usług scentralizowanych, które przejmują wszystkie obliczenia i operacje na danych, a klient po prostu przygotowuje krótki request, mogący zażądać dużej ilości danych lub obliczeń, otrzymując gotowy wynik. W blockchainach kod kliencki staje się coraz bardziej złożony, a jądro blockchaina coraz lżejsze, a masywne zadania obliczeniowe zwykle przypisuje się oprogramowaniu klienckiemu. W blockchainach istnieją klienci, którzy mogą długo przygotowywać jedną transakcję (mówię o różnych dowodach merkle, dowodach szczątkowych, podpisach progowych i innych złożonych operacjach po stronie klienta). Dobrym przykładem łatwej weryfikacji on-chain i ciężkiego przygotowania transakcji po stronie klienta jest dowód przynależności do listy oparty na drzewie Merkle. artykuł.

Nie należy również zapominać, że kod kliencki nie tylko przesyła transakcje do blockchaina, ale najpierw sprawdza stan blockchaina — a ta czynność może wpływać na obciążenie sieci i węzłów blockchaina. Dlatego przy przeprowadzaniu pomiarów dobrze jest jak najwierniej emulować zachowanie kodu klienckiego. Nawet jeśli w twoim blockchainie są standardowi klienci, którzy stosują zwykły podpis cyfrowy na prostej transakcji dotyczącej jakiegoś zasobu, z każdym rokiem obciążenia obliczeniowe na kliencie rosną, algorytmy kryptograficzne stają się silniejsze, a ta część przetwarzania może w przyszłości stać się istotnym wąskim gardłem. Dlatego bądź ostrożny i nie przegap sytuacji, gdy w transakcji trwającej 3,5 sekundy, 2,5 sekundy przeznacza się na przygotowanie i podpisanie transakcji, a 1,0 sekundy na wysłanie do sieci i oczekiwanie na odpowiedź. Aby ocenić ryzyko pojawienia się tego wąskiego gardła, należy zbierać metryki z maszyn klienckich, a nie tylko z węzłów blockchaina.

Wysyłanie transakcji i monitorowanie jej statusu

Kolejnym etapem jest wysłanie transakcji do wybranego węzła blockchain i uzyskanie statusu jej akceptacji w puli transakcji. Ten etap przypomina zwykłe zapytanie do bazy danych, węzeł musi zapisać transakcję w puli i rozpocząć jej rozpowiadanie w sieci p2p. Podejście do oceny wydajności jest podobne do oceny działania tradycyjnych mikroserwisów Web API, przy czym same transakcje w blockchainach mogą być aktualizowane, zmieniając status. Ogólnie rzecz biorąc, aktualizacja informacji o transakcji w niektórych blockchainach może wystąpić kilka razy, na przykład podczas przełączania między forkami łańcucha lub gdy BP informują o zamiarze włączenia transakcji do bloku. Ograniczenia dotyczące wielkości tego puli i liczby transakcji w niej mogą wpływać na wydajność blockchaina. Jeśli pula transakcji zostanie zapełniona do maksymalnych rozmiarów, lub nie zmieści się w pamięci operacyjnej — wydajność sieci może gwałtownie spadać. Blockchainy nie mają scentralizowanych środków ochrony przed napływem śmieciowych komunikatów, a jeśli blockchain wspiera transakcje o dużej objętości i niskie opłaty, może to prowadzić do przepełnienia puli transakcji — to kolejny potencjalny wąskie gardło wydajności.

W blockchainach klient wysyła transakcję do dowolnego węzła, który mu się podoba. Hash transakcji jest zwykle znany klientowi jeszcze przed wysłaniem, więc wszystko, czego potrzebuje, to nawiązać połączenie i po przesłaniu czekać, aż blockchain zmieni swoje stanje, włączając jego transakcję. Zauważmy, że mierząc „tps”, można uzyskać zupełnie różne wyniki dla różnych sposobów łączenia się z węzłem blockchaina. Może to być zwykły HTTP RPC lub WebSocket, co umożliwia zaimplementowanie wzorca „subskrypcji”. W drugim przypadku klient otrzyma powiadomienie wcześniej, a węzeł zużyje mniej zasobów (w głównej mierze pamięci i ruchu) na odpowiedzi dotyczące stanu transakcji. Dlatego przy mierzeniu „tps” należy uwzględnić sposób łączenia klientów z węzłami. W związku z tym, aby ocenić ryzyko pojawienia się tego bottleneck-a, benchmark blockchaina powinien umieć emulować klientów zarówno z zapytaniami WebSocket, jak i HTTP RPC, w proporcjach odpowiadających rzeczywistym sieciom, a także zmieniać charakter transakcji i ich rozmiar.

Aby ocenić ryzyko pojawienia się tego bottleneck-a, należy także zbierać metryki z maszyn klienckich, a nie tylko z węzłów blockchaina.

Przesyłanie transakcji i bloków przez sieć p2p

W blockchainach do przesyłania transakcji i bloków między uczestnikami stosuje się sieci peer-to-peer (p2p). Transakcje rozprzestrzeniają się w sieci, zaczynając od jednego z węzłów, aż dotrą do peerów-producerów bloków, którzy pakują transakcje w bloki i przy pomocy tej samej sieci p2p rozprzestrzeniają nowe bloki do wszystkich węzłów w sieci. Podstawą większości nowoczesnych sieci p2p są różne modyfikacje protokołu Kademlia. Oto dobry krótki przegląd tego protokołu, a oto — artykuł z różnymi pomiarami w sieci BitTorrent, z którego można zrozumieć – że ten rodzaj sieci jest bardziej złożony i mniej przewidywalny niż sztywno skonfigurowana sieć scentralizowanej usługi. Również, oto artykuł na temat pomiaru różnych interesujących metryk dla węzłów Ethereum.

W skrócie, każdy peer w takich sieciach utrzymuje własną dynamiczną listę innych peerów, od których żąda bloków informacji, które są adresowane według zawartości. Po otrzymaniu żądania, peer albo dostarcza potrzebne informacje, albo przekazuje żądanie do następnego pseudolosowego peera z listy, a po otrzymaniu odpowiedzi, przekazuje ją żądającemu i przez pewien czas ją buforuje, udostępniając ten blok informacji wcześniej przy następnym zapytaniu. W ten sposób popularne informacje znajdują się w dużej liczbie buforów u wielu peerów, a niepopularne są stopniowo wypierane. Peery prowadzą ewidencję, kto ile informacji przekazał, a sieć stara się stymulować aktywnych nadawców, podnosząc ich rankingi i zapewniając im wyższy poziom usługi, automatycznie wypierając nieaktywnych uczestników z list peerów.

Zatem transakcję należy teraz rozpropagować po sieci, aby została zauważona przez producentów bloków i włączona do bloku. Węzeł aktywnie „rozprowadza” nową transakcję wszystkim chętnym i nasłuchuje sieci, czekając na blok, w indeksie którego pojawi się potrzebna transakcja, aby powiadomić oczekującego klienta. Czas, w którym sieć wymienia informacje o nowych transakcjach i blokach w sieciach p2p, zależy od bardzo wielu czynników: liczby uczciwych, działających w pobliżu (z punktu widzenia sieci) węzłów, „przygotowania” buforów tych węzłów, rozmiaru bloków, transakcji, charakteru zmian, geografii sieci, liczby węzłów oraz wielu innych czynników. Złożone pomiary metryk wydajności w takich sieciach to skomplikowana sprawa; należy jednocześnie oceniać czas przetwarzania zapytań zarówno na klientach, jak i na peerach (węzłach blockchain). Problemy w jakimkolwiek z mechanizmów p2p, błędne wypieranie i buforyzowanie danych, nieefektywne zarządzanie listami aktywnych peerów oraz wiele innych czynników może prowadzić do opóźnień, które wpływają na wydajność całej sieci, a ten wąskie gardło - jest najbardziej skomplikowane do analizy, testowania i interpretacji wyników.

Przetwarzanie łańcucha bloków i aktualizacja bazy danych stanu

Najważniejszą częścią pracy łańcucha bloków jest algorytm konsensusu, jego zastosowanie do nowych, otrzymanych z sieci bloków oraz procesowanie transakcji z zapisem wyników w bazie danych stanów. Dodawanie nowego bloku do łańcucha i kolejny po tym wybór głównego łańcucha powinien działać maksymalnie szybko. Jednak w rzeczywistości „powinien” nie oznacza „działa”, i można, na przykład, wyobrazić sobie sytuację, w której dwa długie konkurujące łańcuchy ciągle się przełączają, zmieniając metadane tysięcy transakcji w puli przy każdym przełączeniu, i produkując ciągłe wycofania stanu bazy danych. Ten etap, jeśli chodzi o określenie wąskiego gardła, jest prostszy niż warstwa p2p w sieci, ponieważ wykonywanie transakcji i algorytm konsensusu są ściśle deterministyczne, a pomiar czegokolwiek tutaj jest łatwiejszy.
Najważniejsze — nie mylić przypadkowej degradacji wydajności tego etapu z problemami w sieci — węzły wolniej przekazują bloki i informacje o głównym łańcuchu, a dla zewnętrznego klienta może to wyglądać jak wolna sieć, podczas gdy problem tkwi zupełnie gdzie indziej.

Aby zoptymalizować wydajność na tym etapie, warto zbierać i monitorować metryki z samych węzłów, w tym te, które dotyczą aktualizacji bazy danych stanów: liczba bloków przetwarzanych na węźle, ich rozmiar, liczba transakcji, ilość przełączeń między rozwidleniami łańcucha, liczba nieważnych bloków, czas działania maszyny wirtualnej, czas zatwierdzania danych itd. To pozwoli nie pomylić problemów sieciowych z błędami w algorytmach procesowania łańcuchów.

Wirtualna maszyna przetwarzająca transakcje może być użytecznym źródłem informacji, mogącym zoptymalizować działanie łańcucha bloków. Ilość alokacji pamięci, liczba instrukcji read/write oraz inne metryki dotyczące efektywności wykonywania kodu kontraktów mogą dostarczyć wielu cennych informacji deweloperom. Jednocześnie smart kontrakty to programy, co oznacza, że teoretycznie mogą zużywać dowolne zasoby: cpu/pamięć/sieć/storage, więc procesowanie transakcji to dość nieokreślony etap, który dodatkowo mocno zmienia się przy przejściu między wersjami i przy modyfikacji kodu kontraktów. Dlatego metryki dotyczące procesowania transakcji są również potrzebne do efektywnej optymalizacji wydajności łańcucha bloków.

Powiadomienie klienta o włączeniu transakcji w blockchainie

Jest to końcowy etap uzyskiwania usługi przez klienta w blockchainie. W porównaniu do innych etapów, nie ma tu dużych wydatków, ale warto wziąć pod uwagę możliwość otrzymania przez klienta obszernej odpowiedzi od węzła (na przykład smart kontrakt, który zwraca tablicę danych). W każdym razie, ten moment jest najważniejszy dla tych, którzy pytają: „Ile tps jest w waszym blockchainie?”, ponieważ w tym momencie rejestrowany jest czas uzyskania usługi.

W tym miejscu musi być obecne pełne czas, które klient musiał poświęcić na oczekiwanie na odpowiedź z blockchaina, to właśnie ten czas użytkownik będzie czekał na potwierdzenie w swoim aplikacji, a jego optymalizacja jest podstawowym zadaniem programistów.

Podsumowanie

W rezultacie można opisać typy operacji realizowanych w blockchainach i podzielić je na kilka kategorii:

przekształcenia kryptograficzne, budowa dowodów
sieci peer-to-peer, replikacja transakcji i bloków
przetwarzanie transakcji, wykonanie smart kontraktów
zastosowanie zmian w blockchainie do bazy danych stanu, aktualizacja danych o transakcjach i blokach
zapytania tylko do odczytu do bazy danych stanu, API węzła blockchaina, usługi subskrypcyjne

Ogólnie rzecz biorąc, wymagania techniczne dla węzłów nowoczesnych blockchainów są bardzo poważne — to szybkie CPU do kryptografii, duża ilość pamięci operacyjnej do przechowywania i szybkiego dostępu do bazy danych stanu, komunikacja sieciowa, wykorzystująca dużą liczbę jednocześnie otwartych połączeń, duża przestrzeń dyskowa. Tak wysokie wymagania i obfitość różnych typów operacji nieuchronnie prowadzą do sytuacji, w której zasobów dla węzłów może zabraknąć, a wtedy każdy z omówionych powyżej etapów może stać się wąskim gardłem dla ogólnej wydajności sieci.

Przy projektowaniu i ocenie wydajności blockchainów należy wziąć pod uwagę wszystkie te kwestie. W tym celu trzeba zbierać i analizować metryki z klientów i węzłów sieci jednocześnie, szukać korelacji między nimi, oceniać czas świadczenia usług dla klientów, uwzględniać wszystkie kluczowe zasoby: CPU/pamięć/sieć/przechowywanie, rozumieć, jak są wykorzystywane i wpływają na siebie nawzajem. To wszystko sprawia, że porównanie szybkości różnych blockchainów w odniesieniu do „ile TPS” jest niezwykle trudnym zadaniem, ponieważ istnieje ogromna liczba różnych konfiguracji i stanów. W dużych, scentralizowanych systemach, klastrach z setkami serwerów, te problemy są również złożone i wymagają zbierania wielu różnych metryk, ale w blockchainach, z powodu sieci P2P, maszyn wirtualnych, kontraktów procesujących, wewnętrznej gospodarki, liczba stopni swobody jest znacznie większa, co sprawia, że testowanie nawet na kilku serwerach jest mało miarodajne i pokazuje jedynie bardzo przybliżone wartości, które mają niewiele wspólnego z rzeczywistością.

Dlatego, przy rozwijaniu w jądrze blockchaina, dla oceny wydajności i odpowiedzi na pytanie „czy poprawiło się w porównaniu do ostatniego razu” korzystamy z dość złożonego oprogramowania, które orkiestruje uruchomienie blockchaina z dziesiątkami węzłów i automatycznym uruchamianiem benchmarków oraz zbieraniem metryk; bez tych informacji niezwykle trudno jest debugować protokoły działające z wieloma uczestnikami.

Kiedy więc usłyszysz pytanie „ile TPS w waszym blockchainie?”, zaproś rozmówcę na herbatę i zapytaj, czy jest gotów zapoznać się z dziesiątkami wykresów oraz wysłuchać wszystkich trzech pudeł problemów wydajności blockchainów i twoich propozycji ich rozwiązania...

Źródło: habr.com