Dlaczego wydajność Blockchain jest trudna do zmierzenia

Wydajność i skalowalność to szeroko omawiane wyzwania w przestrzeni kryptograficznej, istotne zarówno dla projektów warstwy 1 (niezależne łańcuchy bloków), jak i rozwiązań warstwy 2 (takich jak rollupy i kanały poza łańcuchem). Nie mamy jednak standardowych wskaźników ani punktów odniesienia. Liczby są często podawane w sposób niespójny i niekompletny, co utrudnia dokładne porównanie projektów i często zaciemnia to, co w praktyce najważniejsze. 

Potrzebujemy bardziej zniuansowanego i dokładnego podejścia do pomiaru i porównywania wydajności – takiego, które rozkłada wydajność na wiele komponentów i porównuje kompromisy na wielu osiach. W tym poście definiuję podstawową terminologię, zarysowuję wyzwania oraz przedstawiam wytyczne i kluczowe zasady, o których należy pamiętać przy ocenie wydajności blockchain. 

Skalowalność a wydajność

Najpierw zdefiniujmy dwa terminy: skalowalność i wydajność, które mają standardowe znaczenia w informatyce, ale często są niewłaściwie używane w kontekście blockchain. Wydajność mierzy, czym jest system obecnie w stanie osiągnąć. Jak omówimy poniżej, wskaźniki wydajności mogą obejmować liczbę transakcji na sekundę lub średni czas potwierdzenia transakcji. Skalowalnośćz drugiej strony mierzy zdolność systemu do poprawy wydajności poprzez dodanie zasobów.

To rozróżnienie jest ważne: wiele podejść do poprawy wydajności w ogóle nie poprawia skalowalności, jeśli są właściwie zdefiniowane. Prostym przykładem jest użycie bardziej wydajnego schematu podpisu cyfrowego, takiego jak podpisy BLS, które są mniej więcej o połowę mniejsze niż podpisy Schnorra lub ECDSA. Gdyby Bitcoin przeszedł z ECDSA na BLS, liczba transakcji na blok mogłaby wzrosnąć o 20-30%, poprawiając wydajność z dnia na dzień. Ale możemy to zrobić tylko raz — nie ma jeszcze bardziej oszczędzającego miejsce schematu podpisów, na który można by się przełączyć (podpisy BLS można również agregować, aby zaoszczędzić więcej miejsca, ale jest to kolejna jednorazowa sztuczka).

Wiele innych jednorazowych sztuczek (takich jak SegWit) jest możliwych w blockchainach, ale potrzebujesz skalowalnej architektury, aby osiągnąć ciągłą poprawę wydajności, gdzie dodanie większej ilości zasobów poprawia wydajność w czasie. Jest to powszechna mądrość stosowana również w wielu innych systemach komputerowych, na przykład przy budowie serwera WWW. Stosując kilka typowych sztuczek, możesz zbudować jeden bardzo szybki serwer; ostatecznie jednak potrzebna jest architektura wieloserwerowa, która będzie w stanie sprostać stale rosnącemu zapotrzebowaniu poprzez ciągłe dodawanie dodatkowych serwerów.

Zrozumienie tego rozróżnienia pomaga również uniknąć typowego błędu kategorii, który można znaleźć w stwierdzeniach typu: „Blockchain X jest wysoce skalowalny, może obsłużyć Y transakcji na sekundę!” Drugie twierdzenie może robić wrażenie, ale jest to: jest gwarancją najlepszej jakości, które mogą dostarczyć Ci Twoje monitory, metryka, a nie metryka skalowalności. Nie mówi się o możliwości poprawy wydajności poprzez dodanie zasobów.

Skalowalność z natury wymaga wykorzystania równoległości. W przestrzeni blockchain skalowanie warstwy 1 wydaje się wymagać shardingu lub czegoś, co wygląda na sharding. Podstawowa koncepcja shardingu — dzielenia stanu na części, tak aby różne walidatory mogły przetwarzać je niezależnie — ściśle odpowiada definicji skalowalności. W warstwie 2 dostępnych jest jeszcze więcej opcji, które umożliwiają dodanie przetwarzania równoległego — w tym kanałów poza łańcuchem, serwerów zbiorczych i łańcuchów bocznych.

Opóźnienie a przepustowość

Klasycznie wydajność systemu blockchain ocenia się w dwóch wymiarach: opóźnienia i przepustowości: opóźnienie mierzy, jak szybko można potwierdzić pojedynczą transakcję, podczas gdy przepustowość mierzy łączny współczynnik transakcji w czasie. Osie te dotyczą zarówno systemów warstwy 1 i warstwy 2, jak i wielu innych typów systemów komputerowych (takich jak silniki zapytań do baz danych i serwery WWW).

Niestety zarówno opóźnienie, jak i przepustowość są trudne do zmierzenia i porównania. Co więcej, indywidualni użytkownicy tak naprawdę nie dbają o przepustowość (która jest miarą ogólnosystemową). Tak naprawdę zależy im na opóźnieniach i opłatach transakcyjnych, a dokładniej na tym, aby ich transakcje były potwierdzane tak szybko i jak najtaniej. Chociaż wiele innych systemów komputerowych jest również ocenianych na podstawie kosztu/wydajności, opłaty transakcyjne stanowią nieco nową oś wydajności systemów blockchain, która tak naprawdę nie istnieje w tradycyjnych systemach komputerowych.

Wyzwania związane z pomiarem opóźnień

Opóźnienie na pierwszy rzut oka wydaje się proste: ile czasu zajmuje potwierdzenie transakcji? Ale zawsze istnieje kilka różnych sposobów odpowiedzi na to pytanie.

Po pierwsze, możemy zmierzyć opóźnienie między różnymi punktami w czasie i uzyskać różne wyniki. Na przykład, czy zaczynamy mierzyć opóźnienie, gdy użytkownik lokalnie naciśnie przycisk „wyślij”, czy też gdy transakcja trafi do puli pamięci? I czy zatrzymujemy zegar, gdy transakcja znajduje się w proponowanym bloku, czy też gdy blok jest potwierdzony jednym lub sześcioma blokami uzupełniającymi?

Najbardziej powszechne podejście przyjmuje punkt widzenia walidatorów, mierząc czas od chwili, gdy klient po raz pierwszy ogłosi transakcję, do chwili, gdy transakcja zostanie w rozsądny sposób „potwierdzona” (w tym sensie, że akceptanci w świecie rzeczywistym uznaliby otrzymaną płatność i wydali towar). . Oczywiście różni sprzedawcy mogą stosować różne kryteria akceptacji, a nawet pojedynczy sprzedawca może stosować różne standardy w zależności od kwoty transakcji.

Podejście skoncentrowane na walidatorze pomija kilka rzeczy, które mają znaczenie w praktyce. Po pierwsze, ignoruje opóźnienia w sieci peer-to-peer (ile czasu zajmuje od rozgłoszenia transakcji przez klienta do momentu, gdy większość węzłów ją usłyszała?) i opóźnienie po stronie klienta (ile czasu zajmuje przygotowanie transakcji na komputerze lokalnym klienta?). Opóźnienie po stronie klienta może być bardzo małe i przewidywalne w przypadku prostych transakcji, takich jak podpisanie płatności Ethereum, ale może być znaczące w bardziej złożonych przypadkach, takich jak udowodnienie, że chroniona transakcja Zcash jest poprawna.

Nawet jeśli ujednolicilibyśmy okno czasu, które staramy się mierzyć za pomocą opóźnienia, odpowiedź jest prawie zawsze to zależy. Żaden system kryptowalut, jaki kiedykolwiek zbudowano, nie oferował stałych opóźnień transakcji. Podstawową zasadą, o której warto pamiętać, jest:

Opóźnienie to rozkład, a nie pojedyncza liczba.

Społeczność badaczy sieci od dawna to rozumie (patrz na przykład this doskonała przemowa Gila Tene). Szczególny nacisk kładzie się na „długi ogon” dystrybucji, ponieważ bardzo duże opóźnienia nawet w 0.1% transakcji (lub zapytań do serwera WWW) poważnie wpływ użytkownicy końcowi.

W przypadku łańcuchów bloków opóźnienie potwierdzenia może się różnić z wielu powodów:

Dozowanie: większość systemów w jakiś sposób grupuje transakcje, na przykład w bloki w większości systemów warstwy 1. Prowadzi to do zmiennych opóźnień, ponieważ niektóre transakcje będą musiały poczekać, aż partia się zapełni. Inni mogą mieć szczęście i dołączyć do grupy jako ostatni. Transakcje te są potwierdzane od razu i nie występują żadne dodatkowe opóźnienia.

Zmienne natężenie ruchu: większość systemów cierpi na przeciążenia, co oznacza, że ​​księgowanych jest więcej transakcji (przynajmniej w niektórych przypadkach), niż system jest w stanie natychmiast obsłużyć. Stopień zagęszczenia może się różnić, gdy transakcje są transmitowane w nieprzewidywalnych momentach (często abstrakcyjnie jako Proces Poissona) lub gdy wskaźnik nowych transakcji zmienia się w ciągu dnia lub tygodnia, lub w odpowiedzi na zdarzenia zewnętrzne, takie jak popularne uruchomienie NFT.

Wariancja warstwy konsensusu: Potwierdzenie transakcji w warstwie 1 zwykle wymaga rozproszonego zestawu węzłów w celu osiągnięcia konsensusu w sprawie bloku, co może powodować zmienne opóźnienia niezależnie od przeciążenia. Systemy Proof-of-work znajdują bloki w nieprzewidywalnych momentach (również abstrakcyjnie proces Poissona). Systemy Proof-of-stake mogą również dodawać różne opóźnienia (na przykład, jeśli niewystarczająca liczba węzłów jest online, aby utworzyć komitet w rundzie lub jeśli wymagana jest zmiana widoku w odpowiedzi na awarię lidera).

Z tych powodów dobrą wskazówką jest:

Twierdzenia dotyczące opóźnienia powinny przedstawiać rozkład (lub histogram) czasów potwierdzenia, a nie pojedynczą liczbę, taką jak średnia lub mediana.

Chociaż statystyki podsumowujące, takie jak średnia, mediana lub percentyle, dają częściowy obraz, dokładna ocena systemu wymaga uwzględnienia całego rozkładu. W niektórych zastosowaniach średnie opóźnienie może zapewnić dobry wgląd, jeśli rozkład opóźnień jest stosunkowo prosty (na przykład Gaussa). Jednak w przypadku kryptowalut prawie nigdy tak nie jest: zazwyczaj występuje długi ogon długich czasów potwierdzania.

Dobrym przykładem są sieci kanałów płatniczych (np. Lightning Network). Sieci te, będące klasycznym rozwiązaniem skalowania L2, oferują przez większość czasu bardzo szybkie potwierdzenia płatności, ale czasami wymagają resetowania kanału, co może zwiększyć opóźnienia o rzędy wielkości.

Nawet jeśli dysponujemy dobrymi statystykami dotyczącymi dokładnego rozkładu opóźnień, prawdopodobnie będą się one zmieniać w czasie w miarę zmiany systemu i zapotrzebowania na system. Nie zawsze jest jasne, jak porównać rozkład opóźnień między konkurencyjnymi systemami. Rozważmy na przykład jeden system, który potwierdza transakcje ze równomiernie rozłożonym opóźnieniem od 1 do 2 minut (ze średnią i medianą wynoszącą 90 sekund). Jeśli konkurencyjny system potwierdza 95% transakcji dokładnie w ciągu 1 minuty, a pozostałe 5% w ciągu 11 minut (ze średnią 90 sekund i medianą 60 sekund), to który system jest lepszy? Odpowiedź jest prawdopodobnie taka, że ​​niektóre aplikacje preferują tę pierwszą, a inne drugą.

Na koniec należy zauważyć, że w większości systemów nie wszystkie transakcje mają taki sam priorytet. Użytkownicy mogą zapłacić więcej, aby uzyskać wyższy priorytet włączenia, więc oprócz wszystkich powyższych, opóźnienia różnią się w zależności od uiszczanych opłat transakcyjnych. W podsumowaniu:

Opóźnienie jest złożone. Im więcej zgłoszonych danych, tym lepiej. W idealnym przypadku całkowity rozkład opóźnień powinien być mierzony w zmiennych warunkach przeciążenia. Pomocny jest również podział opóźnienia na różne komponenty (lokalne, sieciowe, wsadowe, opóźnienie konsensusowe).

Wyzwania związane z pomiarem przepustowości

Na pierwszy rzut oka przepustowość również wydaje się prosta: ile transakcji może przetworzyć system na sekundę? Pojawiają się dwie podstawowe trudności: czym dokładnie jest „transakcja” i czy mierzymy to, co system robi dzisiaj, czy też co mógłby być w stanie zrobić?

Chociaż „transakcje na sekundę” (lub tps) są de facto standardem pomiaru wydajności łańcucha bloków, transakcje jako jednostka miary są problematyczne. W przypadku systemów oferujących programowalność ogólnego przeznaczenia („inteligentne kontrakty”) lub nawet ograniczone funkcje, takie jak transakcje multipleksowe Bitcoina lub opcje weryfikacji multi-sig, podstawową kwestią jest:

Nie wszystkie transakcje są sobie równe.

Jest to oczywiście prawdą w Ethereum, gdzie transakcje mogą zawierać dowolny kod i dowolnie modyfikować stan. Pojęcie gazu w Ethereum służy do ilościowego określania (i pobierania opłat) całkowitej ilości pracy wykonywanej przez transakcję, ale jest to wysoce specyficzne dla środowiska wykonawczego EVM. Nie ma prostego sposobu porównania całkowitej ilości pracy wykonanej przez zestaw transakcji EVM z, powiedzmy, zbiorem transakcji Solana przy użyciu środowiska BPF. Porównanie któregokolwiek z zestawów transakcji Bitcoin jest podobnie obarczone ryzykiem.

Łańcuchy bloków, które oddzielają warstwę transakcyjną na warstwę konsensusu i warstwę wykonawczą, mogą to uczynić bardziej przejrzystym. W (czystej) warstwie konsensusu przepustowość można mierzyć w bajtach dodanych do łańcucha w jednostce czasu. Warstwa wykonania zawsze będzie bardziej złożona.

Prostsze warstwy wykonawcze, takie jak serwery zbiorcze, które obsługują tylko transakcje płatnicze, pozwalają uniknąć trudności w ilościowym określeniu obliczeń. Jednak nawet w tym przypadku płatności mogą różnić się liczbą wejść i wyjść. Kanał płatności transakcje mogą różnić się liczbą wymaganych „przeskoków”, co wpływa na przepustowość. Przepustowość serwera zestawień może zależeć od stopnia, w jakim partia transakcji może zostać „skompensowana” do mniejszego zestawu podsumowujących zmian.

Kolejnym wyzwaniem związanym z przepustowością jest wyjście poza empiryczny pomiar dzisiejszej wydajności i ocena jej teoretycznej wydajności. Wprowadza to wszelkiego rodzaju pytania modelujące w celu oceny potencjalnej wydajności. Najpierw musimy zdecydować o realistycznym obciążeniu transakcyjnym warstwy wykonawczej. Po drugie, rzeczywiste systemy prawie nigdy nie osiągają teoretycznej wydajności, szczególnie systemy blockchain. Mamy nadzieję, że ze względu na niezawodność wdrożenia węzłów będą w praktyce heterogeniczne i zróżnicowane (a nie wszyscy klienci korzystający z jednej implementacji oprogramowania). To sprawia, że ​​dokładne symulacje przepustowości blockchain są jeszcze trudniejsze do przeprowadzenia. 

Ogólnie:

Twierdzenia dotyczące przepustowości wymagają dokładnego wyjaśnienia obciążenia transakcją i populacji walidatorów (ich ilość, implementacja i łączność sieciowa). W przypadku braku jasnego standardu wystarczą historyczne obciążenia z popularnej sieci, takiej jak Ethereum.

Kompromisy w zakresie opóźnienia i przepustowości

Opóźnienie i przepustowość są zwykle kompromisem. Jak Kontury Lefterisa Kokorisa-Kogiasa, ten kompromis często nie jest płynny, z punktem przegięcia, w którym opóźnienie gwałtownie rośnie, gdy obciążenie systemu zbliża się do maksymalnej przepustowości.

Systemy zbiorcze o zerowej wiedzy stanowią naturalny przykład kompromisu w zakresie przepustowości i opóźnień. Duże partie transakcji wydłużają czas sprawdzania, co zwiększa opóźnienia. Jednak obciążenie łańcucha, zarówno pod względem rozmiaru dowodu, jak i kosztu walidacji, zostanie zamortyzowane w przypadku większej liczby transakcji z większymi partiami, co zwiększy przepustowość.

Opłaty transakcyjne

Zrozumiałe jest, że użytkownikom końcowym bardziej zależy na kompromisie między opóźnieniami a opłaty, a nie opóźnienia i przepustowość. Użytkownicy nie mają bezpośredniego powodu, aby w ogóle przejmować się przepustowością, a jedynie dlatego, że mogą szybko potwierdzać transakcje przy możliwie najniższych opłatach (niektórzy użytkownicy bardziej zwracają uwagę na opłaty, a inni na opóźnienia). Na wysokim poziomie na opłaty wpływa wiele czynników:

1. Jak duże jest zapotrzebowanie rynku na dokonywanie transakcji?
2. Jaką ogólną przepustowość osiąga system?
3. Ile całkowitego przychodu system zapewnia walidatorom lub górnikom?
4. Jaka część tych przychodów opiera się na opłatach transakcyjnych a nagrodach inflacyjnych?

Pierwsze dwa czynniki to w przybliżeniu krzywe podaży i popytu, które prowadzą do ceny oczyszczającej rynek (chociaż twierdzono, że górnicy działają jak kartel, aby podnieść opłaty powyżej tego punktu). Przy założeniu, że wszystkie pozostałe czynniki są takie same, większa przepustowość powinna prowadzić do niższych opłat, ale dzieje się o wiele więcej.

W szczególności punkty 3 i 4 powyżej są podstawowymi kwestiami projektowania systemu blockchain, jednak brakuje nam dobrych zasad dla żadnego z nich. Rozumiemy zalety i wady zapewniania górnikom przychodów z nagród inflacyjnych w porównaniu z opłatami transakcyjnymi. Jednak pomimo wielu analiz ekonomicznych protokołów konsensusu blockchain, nadal nie mamy powszechnie akceptowanego modelu tego, ile przychodów musi trafić do walidatorów. Obecnie większość systemów opiera się na świadomym przypuszczeniu, ile przychodów wystarczy, aby walidatorzy zachowywali się uczciwie, nie zakłócając praktycznego wykorzystania systemu. W uproszczonych modelach można wykazać, że koszt zorganizowania ataku o wartości 51% skaluje się wraz z nagrodami dla walidatorów.

Podnoszenie kosztów ataków jest dobrą rzeczą, ale nie wiemy też, na ile poziom bezpieczeństwa jest „wystarczający”. Wyobraź sobie, że rozważasz pójście do dwóch parków rozrywki. Jeden z nich twierdzi, że wydaje o 50% mniej na utrzymanie pojazdów niż drugi. Czy to dobry pomysł, aby wybrać się do tego parku? Może być tak, że są bardziej wydajne i zapewniają równoważne bezpieczeństwo za mniejsze pieniądze. Być może drugi wydaje więcej, niż jest to konieczne, aby zapewnić bezpieczeństwo przejażdżek bez korzyści. Ale może się też zdarzyć, że pierwszy park będzie niebezpieczny. Systemy Blockchain są podobne. Po uwzględnieniu przepustowości łańcuchy bloków z niższymi opłatami mają niższe opłaty, ponieważ w mniejszym stopniu nagradzają (a tym samym motywują) swoich walidatorów. Nie mamy dziś dobrych narzędzi, aby ocenić, czy jest to w porządku, czy też naraża system na atak. Ogólnie:

Porównywanie opłat pomiędzy systemami może wprowadzać w błąd. Chociaż opłaty transakcyjne są ważne dla użytkowników, wpływa na nie wiele czynników poza samą konstrukcją systemu. Przepustowość jest lepszą miarą do analizy systemu jako całości.

Wnioski

Sprawiedliwa i dokładna ocena wydajności jest trudna. Dotyczy to również pomiaru osiągów samochodu. Podobnie jak w przypadku blockchainów, różnym ludziom będą zależeć na różnych rzeczach. W przypadku samochodów niektórym użytkownikom zależy na prędkości maksymalnej lub przyspieszeniu, innym na zużyciu paliwa, a jeszcze innym na uciągu. Wszystko to nie jest trywialne w ocenie. Na przykład w USA Agencja Ochrony Środowiska utrzymuje szczegółowe wytyczne dotyczące sposobu szacowania przebiegu na benzynie oraz sposobu przedstawiania go użytkownikom u dealera.

Przestrzeń blockchain jest jeszcze daleka od tego poziomu standaryzacji. W niektórych obszarach być może uda nam się to osiągnąć w przyszłości, oferując standardowe obciążenia w celu oceny przepustowości systemu lub standardowe wykresy przedstawiające rozkład opóźnień. Na chwilę obecną najlepszym podejściem dla ewaluatorów i konstruktorów jest zebranie i opublikowanie jak największej ilości danych wraz ze szczegółowym opisem metodologii ewaluacji, aby można było je odtworzyć i porównać z innymi systemami.