Ulubionym pytaniem osoby nietechnicznej na temat dowolnego systemu rozproszonego jest: „Ile tps znajduje się na Twoim blockchainie?” Jednak liczba podana w odpowiedzi zwykle ma niewiele wspólnego z tym, co pytający chciałby usłyszeć. Tak naprawdę chciał zapytać „czy Twój blockchain będzie odpowiadał moim wymaganiom biznesowym”, a wymagania te to nie jedna liczba, ale wiele warunków – są tu tolerancja na awarie sieci, wymagania dotyczące finalności, rozmiary, charakter transakcji i wiele innych parametrów. Zatem odpowiedź na pytanie „ile tps” raczej nie będzie prosta i prawie nigdy nie będzie kompletna. System rozproszony z dziesiątkami lub setkami węzłów wykonujących dość złożone obliczenia może znajdować się w ogromnej liczbie różnych stanów związanych ze stanem sieci, zawartością blockchainu, awariami technicznymi, problemami ekonomicznymi, atakami na sieć i wieloma innymi przyczynami . Etapy, na których możliwe są problemy z wydajnością, różnią się od tradycyjnych usług, a serwer sieciowy typu blockchain jest usługą sieciową, która łączy w sobie funkcjonalność bazy danych, serwera WWW i klienta torrent, co czyni ją niezwykle złożoną pod względem profilu obciążenia na wszystkich podsystemach : procesor, pamięć, sieć, pamięć masowa

Tak się składa, że zdecentralizowane sieci i blockchainy są dość specyficznym i nietypowym oprogramowaniem dla scentralizowanych twórców oprogramowania. Dlatego chciałbym podkreślić ważne aspekty wydajności i trwałości zdecentralizowanych sieci, podejścia do ich pomiaru i znajdowania wąskich gardeł. Przyjrzymy się różnym problemom wydajnościowym, które ograniczają prędkość świadczenia usług użytkownikom blockchain i zwrócimy uwagę na cechy charakterystyczne dla tego typu oprogramowania.

Etapy żądania usługi przez klienta blockchain

Aby szczerze mówić o jakości mniej lub bardziej złożonej usługi, należy wziąć pod uwagę nie tylko wartości średnie, ale także maksymalne/minimalne, mediany, percentyle. Teoretycznie w jakimś blockchainie możemy mówić o 1000 tps, jednak jeśli 900 transakcji zostało zrealizowanych z ogromną szybkością, a 100 „zablokowało się” na kilka sekund, to średni czas zebrany po wszystkich transakcjach nie jest do końca miarodajnym miernikiem dla klienta którym nie udało mi się sfinalizować transakcji w kilka sekund. Tymczasowe „dziury” spowodowane nieudanymi rundami konsensusu lub podziałami sieci mogą znacznie zniszczyć usługę, która wykazała się doskonałą wydajnością na stanowiskach testowych.

Aby zidentyfikować takie wąskie gardła, konieczne jest dobre zrozumienie etapów, na których prawdziwy blockchain może mieć trudności z obsługą użytkowników. Opiszmy cykl dostarczenia i przetworzenia transakcji, a także uzyskania nowego stanu blockchainu, z którego klient może zweryfikować, czy jego transakcja została przetworzona i rozliczona.

transakcja jest tworzona na kliencie
transakcja jest podpisana 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 pojawienie się wyników swojej transakcji
węzeł dystrybuuje transakcję w sieci p2p
kilka lub jeden BP (producent bloków) przetwarza skumulowane transakcje, aktualizując stanową bazę danych
BP tworzy nowy blok po przetworzeniu wymaganej liczby transakcji
BP dystrybuuje nowy blok w sieci p2p
nowy blok jest dostarczany do węzła, do którego uzyskuje dostęp klient
węzeł aktualizuje bazę danych stanu
węzeł widzi aktualizację dotyczącą klienta i wysyła mu powiadomienie o transakcji

Przyjrzyjmy się teraz bliżej tym etapom i opiszmy potencjalne problemy z wydajnością na każdym etapie. W odróżnieniu od systemów scentralizowanych rozważymy również wykonanie kodu na klientach sieciowych. Dość często przy pomiarze TPS czas realizacji transakcji pobierany jest od węzłów, a nie od klienta – nie jest to do końca sprawiedliwe. Klienta nie interesuje, jak szybko węzeł przetworzył jego transakcję, najważniejszy dla niego jest moment, w którym trafiają do niego wiarygodne informacje o tej transakcji zawarte w blockchainie. To właśnie ten wskaźnik jest zasadniczo czasem realizacji transakcji. Oznacza to, że różni klienci, nawet wysyłając tę samą transakcję, mogą otrzymać zupełnie różne czasy, które zależą od kanału, obciążenia i bliskości węzła itp. Dlatego absolutnie konieczne jest mierzenie tego czasu na klientach, ponieważ jest to parametr wymagający optymalizacji.

Przygotowanie transakcji po stronie klienta

Zacznijmy od dwóch pierwszych punktów: transakcja jest tworzona i podpisana przez klienta. Co dziwne, z punktu widzenia klienta może to być również wąskie gardło w wydajności blockchain. Jest to nietypowe w przypadku usług scentralizowanych, które przejmują wszystkie obliczenia i operacje na danych, a klient po prostu przygotowuje krótkie zapytanie, które może zażądać dużej ilości danych lub obliczeń, uzyskując gotowy wynik. W blockchainach kod klienta staje się coraz potężniejszy, rdzeń blockchain staje się coraz lżejszy, a ogromne zadania obliczeniowe są zwykle przenoszone do oprogramowania klienckiego. W blockchainach istnieją klienci, którzy potrafią przygotowywać jedną transakcję dość długo (mówię o różnych dowódach merkle, dowodach zwięzłych, podpisach progowych i innych skomplikowanych operacjach po stronie klienta). Dobrym przykładem łatwej weryfikacji on-chain i starannego przygotowania transakcji u klienta jest dowód członkostwa na liście opartej na drzewie Merkle, tutaj artykuł.

Nie zapominaj także, że kod klienta nie tylko wysyła transakcje do blockchainu, ale najpierw pyta o stan blockchainu – a to działanie może mieć wpływ na przeciążenie sieci i węzłów blockchain. Zatem podczas dokonywania pomiarów rozsądne byłoby możliwie najpełniejsze emulowanie zachowania kodu klienta. Nawet jeśli w Twoim łańcuchu bloków znajdują się zwykli, lekcy klienci, którzy składają zwykły podpis cyfrowy na najprostszej transakcji polegającej na przeniesieniu jakiegoś zasobu, z każdym rokiem na kliencie wykonywane są coraz bardziej masowe obliczenia, algorytmy kryptograficzne stają się coraz silniejsze i ta część przetwarzania może w przyszłości stać się znaczącym wąskim gardłem. Dlatego należy zachować ostrożność i nie przeoczyć sytuacji, gdy w transakcji trwającej 3.5 s, 2.5 s poświęca się na przygotowanie i podpisanie transakcji, a 1.0 s na wysłanie jej do sieci i oczekiwanie na odpowiedź. Aby ocenić ryzyko związane z tym wąskim gardłem, należy zebrać metryki z maszyn klienckich, a nie tylko z węzłów blockchain.

Wysłanie transakcji i monitorowanie jej statusu

Kolejnym krokiem jest wysłanie transakcji do wybranego węzła blockchain i otrzymanie statusu przyjęcia jej do puli transakcji. Ten etap przypomina zwykły dostęp do bazy danych – węzeł musi zarejestrować transakcję w puli i rozpocząć dystrybucję informacji o niej poprzez sieć p2p. Podejście do oceny wydajności jest tutaj podobne do oceny wydajności tradycyjnych mikrousług Web API, a same transakcje w blockchainach można aktualizować i aktywnie zmieniać ich status. Ogólnie rzecz biorąc, aktualizacja informacji o transakcjach w niektórych łańcuchach bloków może odbywać się wielokrotnie, na przykład podczas przełączania między rozwidleniami łańcucha lub gdy BP ogłaszają zamiar włączenia transakcji do bloku. Ograniczenia wielkości tej puli i liczby transakcji w niej mogą mieć wpływ na wydajność łańcucha bloków. Jeśli pula transakcji zostanie zapełniona do maksymalnego możliwego rozmiaru lub nie mieści się w pamięci RAM, wydajność sieci może gwałtownie spaść. Łańcuchy bloków nie mają scentralizowanych środków ochrony przed zalewem wiadomości-śmieci, a jeśli łańcuch bloków obsługuje transakcje na dużą skalę i niskie opłaty, może to spowodować przepełnienie puli transakcji – co stanowi kolejne potencjalne wąskie gardło wydajności.

W blockchainach klient wysyła transakcję do dowolnego węzła blockchain, jaki mu się podoba, hash transakcji jest zwykle znany klientowi przed wysłaniem, więc wystarczy, że osiągnie połączenie i po transmisji poczeka na zmianę blockchainu jego stan, umożliwiający jego transakcję. Należy pamiętać, że mierząc „tps” można uzyskać zupełnie inne wyniki dla różnych metod łączenia się z węzłem blockchain. Może to być zwykły HTTP RPC lub WebSocket, który pozwala na implementację wzorca „subskrybuj”. W drugim przypadku klient otrzyma powiadomienie wcześniej, a węzeł wyda mniej zasobów (głównie pamięci i ruchu) na odpowiedzi o statusie transakcji. Zatem przy pomiarze „tps” należy wziąć pod uwagę sposób, w jaki klienci łączą się z węzłami. Dlatego, aby ocenić ryzyko wystąpienia tego wąskiego gardła, benchmarkowy blockchain musi być w stanie emulować klientów zarówno z żądaniami WebSocket, jak i HTTP RPC, w proporcjach odpowiadających rzeczywistym sieciom, a także zmieniać charakter transakcji i ich wielkość.

Aby ocenić ryzyko związane z tym wąskim gardłem, należy również zebrać metryki z maszyn klienckich, a nie tylko z węzłów blockchain.

Transmisja transakcji i bloków poprzez sieć p2p

W blockchainach do przesyłania transakcji i bloków pomiędzy uczestnikami używana jest sieć peer-to-peer (p2p). Transakcje rozprzestrzeniają się po całej sieci, zaczynając od jednego z węzłów, aż dotrą do równorzędnych producentów bloków, którzy pakują transakcje w bloki i korzystając z tego samego p2p, dystrybuują nowe bloki do wszystkich węzłów sieci. Podstawą większości nowoczesnych sieci p2p są różne modyfikacje protokołu Kademlia. tutaj jest dobre podsumowanie tego protokołu, oraz tutaj - artykuł z różnymi pomiarami w sieci BitTorrent, z którego można zrozumieć, że tego typu sieć jest bardziej złożona i mniej przewidywalna niż sztywno skonfigurowana sieć scentralizowanej usługi. Również, tutaj artykuł na temat pomiaru różnych interesujących wskaźników dla węzłów Ethereum.

Krótko mówiąc, każdy uczestnik w takich sieciach utrzymuje własną dynamiczną listę innych partnerów, od których żąda bloków informacji, do których adresuje się treść. Kiedy peer otrzymuje żądanie, albo podaje niezbędne informacje, albo przekazuje żądanie następnemu pseudolosowemu peerowi z listy, a po otrzymaniu odpowiedzi przekazuje je requesterowi i buforuje na chwilę, dając to następnym razem blok informacji wcześniej. W ten sposób popularne informacje trafiają do dużej liczby pamięci podręcznych dużej liczby równorzędnych użytkowników, a niepopularne informacje są stopniowo zastępowane. Partnerzy prowadzą rejestr, kto komu przekazał ile informacji, a sieć stara się stymulować aktywnych dystrybutorów, podnosząc ich oceny i zapewniając im wyższy poziom usług, automatycznie wypierając nieaktywnych uczestników z list równorzędnych.

Zatem transakcja musi teraz zostać rozproszona w całej sieci, aby producenci bloków mogli ją zobaczyć i uwzględnić w bloku. Węzeł aktywnie „rozdziela” wszystkim nową transakcję i nasłuchuje sieci, czekając na blok, w indeksie którego pojawi się żądana transakcja, aby powiadomić oczekującego klienta. Czas potrzebny sieci na przesłanie sobie informacji o nowych transakcjach i blokach w sieciach p2p zależy od bardzo dużej liczby czynników: liczby uczciwych węzłów pracujących w pobliżu (z punktu widzenia sieci), „ciepłego” górę” pamięci podręcznych tych węzłów, wielkość bloków, transakcje, charakter zmian, położenie geograficzne sieci, liczbę węzłów i wiele innych czynników. Złożone pomiary wskaźników wydajności w takich sieciach są sprawą złożoną; konieczna jest jednoczesna ocena czasu przetwarzania żądań zarówno u klientów, jak i równorzędnych węzłów (węzłów blockchain). Problemy w którymkolwiek z mechanizmów p2p, nieprawidłowe usuwanie i buforowanie danych, nieefektywne zarządzanie listami aktywnych peerów i wiele innych czynników może powodować opóźnienia, które wpływają na wydajność całej sieci jako całości, a to wąskie gardło jest najtrudniejsze do analizy , badanie i interpretacja wyników.

Przetwarzanie Blockchain i aktualizacja bazy danych stanu

Najważniejszą częścią blockchainu jest algorytm konsensusu, jego zastosowanie do nowych bloków otrzymywanych z sieci oraz przetwarzanie transakcji z rejestracją wyników w państwowej bazie danych. Dodanie nowego bloku do łańcucha, a następnie wybranie głównego łańcucha powinno zadziałać możliwie najszybciej. Jednak w prawdziwym życiu „powinno” nie znaczy „działa” i można na przykład wyobrazić sobie sytuację, w której dwa długie, konkurencyjne łańcuchy nieustannie przełączają się między sobą, zmieniając przy każdym przełączeniu metadane tysięcy transakcji w puli i ciągłe wycofywanie stanu bazy danych. Ten etap, jeśli chodzi o zdefiniowanie wąskiego gardła, jest prostszy niż warstwa sieci p2p, ponieważ wykonanie transakcji i algorytm konsensusu są ściśle deterministyczne i łatwiej jest tutaj cokolwiek zmierzyć.
Najważniejsze, aby nie mylić losowej degradacji wydajności tego etapu z problemami z siecią - węzły wolniej dostarczają bloki i informacje o głównym łańcuchu, a dla klienta zewnętrznego może to wyglądać na powolną sieć, choć problem polega na tym, że zupełnie inne miejsce.

Aby zoptymalizować wydajność na tym etapie, warto zbierać i monitorować metryki z samych węzłów i uwzględniać w nich metryki związane z aktualizacją bazy danych stanu: liczba bloków przetwarzanych w węźle, ich rozmiar, liczba transakcji, liczba przełączeń pomiędzy rozwidleniami łańcucha, liczba nieprawidłowych bloków, czas działania maszyny wirtualnej, czas zatwierdzania danych itp. Zapobiegnie to pomyleniu problemów sieciowych z błędami w algorytmach przetwarzania łańcucha.

Użytecznym źródłem informacji mogącym zoptymalizować działanie blockchainu może być maszyna wirtualna przetwarzająca transakcje. Liczba alokacji pamięci, liczba instrukcji odczytu/zapisu i inne metryki związane z wydajnością wykonywania kodu kontraktu mogą dostarczyć programistom wielu przydatnych informacji. Jednocześnie inteligentne kontrakty są programami, co oznacza, że teoretycznie mogą zużywać dowolne zasoby: procesor/pamięć/sieć/pamięć, więc przetwarzanie transakcji jest etapem dość niepewnym, który dodatkowo mocno się zmienia przy przechodzeniu pomiędzy wersjami oraz przy zmianie kodów umów. Dlatego też, aby skutecznie optymalizować wydajność blockchain, potrzebne są również metryki związane z przetwarzaniem transakcji.

Otrzymanie przez klienta powiadomienia o umieszczeniu transakcji w blockchainie

Jest to końcowy etap odbioru usługi przez klienta blockchain; w porównaniu do innych etapów nie ma dużych kosztów ogólnych, ale nadal warto rozważyć możliwość otrzymania przez klienta obszernej odpowiedzi z węzła (na przykład inteligentnego kontraktu zwrócenie tablicy danych). W każdym razie ten punkt jest najważniejszy dla tego, który zadał pytanie „ile tps jest w twoim blockchainie?”, ponieważ W tym momencie odnotowywany jest czas otrzymania usługi.

W tym miejscu zawsze przesyłany jest cały czas, jaki klient musiał przeznaczyć na oczekiwanie na odpowiedź z blockchaina; to właśnie czas użytkownik będzie czekał na potwierdzenie w swoim wniosku i to właśnie jego optymalizacja jest celem główne zadanie deweloperów.

wniosek

W rezultacie możemy opisać rodzaje operacji wykonywanych na blockchainach i podzielić je na kilka kategorii:

transformacje kryptograficzne, konstrukcja dowodu
sieci peer-to-peer, replikacja transakcji i bloków
przetwarzanie transakcji, realizacja inteligentnych kontraktów
wprowadzanie zmian w blockchainie do stanowej bazy danych, aktualizacja danych o transakcjach i blokach
żądania tylko do odczytu do bazy danych stanu, API węzła blockchain, usługi subskrypcyjne

Ogólnie rzecz biorąc, wymagania techniczne współczesnych węzłów blockchain są niezwykle poważne – szybkie procesory do kryptografii, duża ilość pamięci RAM do przechowywania i szybkiego dostępu do stanowej bazy danych, interakcja sieciowa z wykorzystaniem dużej liczby jednocześnie otwartych połączeń oraz duża pamięć masowa. Tak wysokie wymagania i mnogość różnego rodzaju operacji nieuchronnie prowadzą do tego, że węzły mogą nie mieć wystarczających zasobów, a wtedy każdy z omówionych powyżej etapów może stać się kolejnym wąskim gardłem dla ogólnej wydajności sieci.

Projektując i oceniając wydajność łańcuchów bloków, będziesz musiał wziąć pod uwagę wszystkie te punkty. Aby to zrobić, musisz jednocześnie zbierać i analizować metryki od klientów i węzłów sieci, szukać korelacji między nimi, oszacować czas potrzebny na świadczenie usług klientom, wziąć pod uwagę wszystkie główne zasoby: procesor/pamięć/sieć/pamięć masowa , zrozumieć, w jaki sposób są wykorzystywane i na siebie wpływają. Wszystko to sprawia, że porównywanie prędkości różnych blockchainów w formie „ile TPS” jest zadaniem niezwykle niewdzięcznym, gdyż istnieje ogromna ilość różnych konfiguracji i stanów. W dużych scentralizowanych systemach, klastrach setek serwerów, problemy te są również złożone i wymagają również gromadzenia dużej liczby różnych metryk, ale w blockchainach ze względu na sieci p2p, umowy o przetwarzanie maszyn wirtualnych, oszczędności wewnętrzne, liczbę stopni wolności jest znacznie większa, co sprawia, że test nawet na kilku serwerach nie ma charakteru orientacyjnego i pokazuje jedynie wartości skrajnie przybliżone, które nie mają prawie żadnego związku z rzeczywistością.

Dlatego też, rozwijając się w rdzeniu blockchain, aby ocenić wydajność i odpowiedzieć na pytanie „czy poprawiła się w porównaniu do ostatniego razu?”, używamy dość złożonego oprogramowania, które koordynuje uruchomienie blockchainu z kilkudziesięciu węzłów i automatycznie uruchamia benchmark i zbiera metryki ; bez tych informacji niezwykle trudno jest debugować protokoły współpracujące z wieloma uczestnikami.

Tak więc, gdy otrzymasz pytanie „ile TPS znajduje się w Twoim blockchainie?”, zaproponuj swojemu rozmówcy herbatę i zapytaj, czy jest gotowy spojrzeć na kilkanaście wykresów, a także wysłuchać wszystkich trzech pudełek problemów z wydajnością blockchainu i Twoich sugestii dotyczących ich rozwiązanie...

Źródło: www.habr.com

Ile TPS znajduje się na Twoim blockchainie?