Ewolucja synchronizacji stanu: ścieżka do ponad 100 000 transakcji na sekundę z opóźnieniem poniżej sekundy w Aptos

Blockchain Aptos wykorzystuje szeroką gamę nowatorskich technik, aby zapewnić wysoką przepustowość, niskie opóźnienia i zweryfikowaną synchronizację stanu w zdecentralizowanej sieci. Współpracownicy mogą weryfikować i synchronizować ponad 10 000 transakcji na sekundę (TPS) z opóźnieniem poniżej sekundy w Aptos, a my jesteśmy już w drodze do ponad 100 000 TPS.

Synchronizacja stanu jest ważnym, ale często pomijanym aspektem projektowania blockchain. W tym wpisie na blogu omawiamy ewolucję synchronizacji stanu w Aptos i przedstawiamy kilka kluczowych spostrzeżeń dotyczących projektu najnowszego protokołu synchronizacji stanu. Dalej badamy, w jaki sposób ostatnio zwiększyliśmy przepustowość synchronizacji stanów o 10x, zmniejszyliśmy opóźnienia o 3x i nadal torujemy drogę do szybszej i wydajniejszej synchronizacji łańcucha bloków.

Większość dzisiejszych blokchainów ma strukturę hierarchiczną, z zestawem aktywnych walidatorów w sercu sieci. Walidatorzy rozwijają łańcuch bloków poprzez wykonywanie transakcji, tworzenie bloków i osiąganie konsensusu. Reszta peerów w sieci (np. fullnodes i klienci) replikuje dane blockchain wytwarzane przez walidatory (np. bloki i transakcje). Synchronizacja stanu to protokół, który umożliwia partnerom niebędącym walidatorem dystrybucję, weryfikację i utrwalanie danych łańcucha bloków oraz zapewnia synchronizację wszystkich partnerów w ekosystemie. Zobacz poniższy diagram, aby zobaczyć, jak to wygląda w Aptos.

APTOS OVERWIEV

Dlaczego synchronizacja stanu ma znaczenie?

Synchronizacja stanu jest rzadko wspominana podczas oceny blokchaina: często jest to przypis w oficjalnym dokumencie poświęconym bardziej interesującym tematom*. Jednak synchronizacja stanu ma znaczący wpływ na wydajność, bezpieczeństwo i wrażenia użytkownika łańcucha bloków. Rozważ następujące:

1. Czas do sfinalizowania i wrażenia użytkownika: Gdy nowe transakcje są wykonywane przez walidatory, synchronizacja stanu jest odpowiedzialna za propagację danych do elementów równorzędnych i klientów. Jeśli synchronizacja stanu jest powolna lub zawodna, peery będą dostrzegać duże opóźnienia przetwarzania transakcji, sztucznie zawyżając czas do finalizacji. Ma to ogromny wpływ na wrażenia użytkownika, np. zdecentralizowane aplikacje (dApps), zdecentralizowane giełdy (DEX) i przetwarzanie płatności będzie znacznie wolniejsze.
2. Związek z konsensusem: Walidatory, które ulegają awarii lub pozostają w tyle za resztą zestawu walidatorów, polegają na synchronizacji stanu, aby przywrócić ich najnowszy stan łańcucha bloków. Jeśli synchronizacja stanu nie może przetwarzać transakcji tak szybko, jak są one wykonywane przez konsensus, awarie walidatorów nigdy nie będą w stanie odzyskać aktualnego stanu. Co więcej, nowi walidatorzy nigdy nie będą mogli zacząć brać udziału w konsensusie (ponieważ nigdy nie nadrobią zaległości!), a fullnody nigdy nie będą w stanie zsynchronizować się z najnowszym stanem (będą nadal pozostawać w tyle!)
3. Implikacje dla decentralizacji: Posiadanie szybkiego, wydajnego i skalowalnego protokołu synchronizacji stanu pozwala na: (i) szybszą rotację aktywnego zestawu walidatorów, ponieważ walidatory mogą swobodniej wchodzić i wychodzić z konsensusu; (ii) więcej potencjalnych walidatorów do wyboru w sieci; (iii) więcej pełnych węzłów, aby szybko przejść do trybu online i bez konieczności długiego oczekiwania; oraz (iv) mniejsze wymagania dotyczące zasobów, zwiększające heterogeniczność. Wszystkie te czynniki zwiększają decentralizację w sieci i pomagają skalować blockchain pod względem rozmiaru i położenia geograficznego.
4. Poprawność danych: Synchronizacja stanu odpowiada za weryfikację poprawności wszystkich danych blockchain podczas synchronizacji. Uniemożliwia to złośliwym peerom i przeciwnikom w sieci modyfikowanie, cenzurowanie lub fabrykowanie danych transakcji i przedstawianie ich jako prawidłowych. Jeśli synchronizacja stanu nie wykona tego (lub zrobi to nieprawidłowo), pełne węzły i klienci mogą zostać oszukani do zaakceptowania nieprawidłowych danych, co miałoby katastrofalne konsekwencje w sieci.

Rozumienie synchronizacji stanu

Aby lepiej uzasadnić synchronizację stanu, najpierw przedstawiamy ogólny model wykonywania blockchain. Chociaż ten model jest ukierunkowany konkretnie na blockchain Aptos, można go uogólnić na inne.

Modelujemy łańcuch bloków Aptos jako prostą wersjonowaną bazę danych, w której w każdej wersji V występuje unikalny stan łańcucha bloków Sⱽ zawierający wszystkie konta i zasoby w łańcuchu. Transakcja T może zostać wykonana przez maszynę wirtualną Aptos (VM) w stanie Sⱽ w celu wytworzenia delty stanu Dᵀᵥ reprezentującej wszystkie modyfikacje stanu, które wystąpiłyby w Sⱽ, gdyby T zostało zatwierdzone. Kiedy Dᵀᵥ jest stosowane do Sⱽ (to znaczy, że uważamy T za popełnione), skutkuje to nową wersją V+1 i nowym stanem łańcucha bloków Sⱽ⁺¹. Pierwszy stan łańcucha bloków nazywamy stanem genezy S⁰. Poniższe diagramy przedstawiają wykonanie transakcji i zastosowanie delty stanu.

Wykonanie transakcji i aplikacja Delta stanu (model)

Jakie są cele?

Mając wdrożony model ogólny, możemy teraz zdefiniować kilka podstawowych celów synchronizacji stanu**:

1. Wysoka przepustowość: synchronizacja stanu powinna zmaksymalizować liczbę transakcji, które mogą być synchronizowane przez każdy element równorzędny na sekundę. Oznacza to, że maksymalizując szybkość przejść stanów od Sⱽ do Sⱽ⁺¹ dla każdego T popełnionego przez walidatory. Niska przepustowość wydłuża czas synchronizacji i staje się wąskim gardłem sieci.
2. Małe opóźnienie: synchronizacja stanu powinna zminimalizować czas potrzebny aktualnym partnerom na synchronizację nowych transakcji zatwierdzonych przez weryfikatory. Oznacza to, że zminimalizuje czas potrzebny na synchronizację elementów równorzędnych w Sⱽ z Sⱽ⁺¹ dla każdego T, który jest na nowo zatwierdzany przez weryfikatory. Wpływa to na postrzegany przez klientów całkowity czas do ostateczności.
3. Szybki czas ładowania: synchronizacja stanu powinna zminimalizować czas potrzebny nowym (lub uszkodzonym) peerom do synchronizacji z najnowszym stanem łańcucha bloków. Oznacza to, że zminimalizuje czas potrzebny na synchronizację z Sⱽ (gdzie V jest najwyższą wersją bazy danych uzgodnioną przez walidatory) niezależnie od bieżącej wersji P i stanu Sᴾ peera. Pozwala to na szybsze wykonywanie użytecznej pracy (np. odpowiadanie na zapytania o saldo lub walidację transakcji).
4. Odporność na awarie i hacki: synchronizacja stanu powinna być odporna na awarie (np. awarie komputera i sieci) i tolerować złośliwych aktorów w sieci, w tym innych równorzędnych. Oznacza to pokonanie szerokiej gamy ataków, np. sfabrykowanych danych transakcyjnych, zmodyfikowanych lub odtwarzanych komunikatów sieciowych oraz ataków typu eclipse.
5. Tolerancja na ograniczenia zasobów i heterogeniczność: synchronizacja stanu powinna tolerować ograniczenia zasobów (np. procesor, pamięć i pamięć masowa) i obejmować heterogeniczność. Biorąc pod uwagę charakter zdecentralizowanych sieci, peery będą miały dostęp do różnych typów sprzętu i optymalizują je pod kątem różnych celów. Synchronizacja stanu powinna to uwzględniać.

Wymagania

Następnie przedstawiamy zestaw podstawowych bloków konstrukcyjnych wymaganych do skonstruowania protokołu synchronizacji stanu. W trosce o zwięzłość przedstawiamy poniżej podsumowanie każdego bloku konstrukcyjnego i odkładamy szczegóły techniczne do przyszłych prac (każdy z nich może być sam w sobie wpisem na blogu!):

1. Pamięć trwała: Aby zachować dane podczas awarii (i umożliwić dystrybucję danych do innych równorzędnych użytkowników!) wymagamy, aby każdy komputer równorzędny miał dostęp do zaufanego magazynu trwałego. W Aptos obecnie korzystamy z RocksDB, ale aktywnie badamy inne opcje.
2. Weryfikowalne dane łańcucha bloków: Aby uniemożliwić złośliwym podmiotom modyfikowanie danych łańcucha bloków, wymagamy, aby dane były uwierzytelniane i weryfikowalne. W szczególności musimy być w stanie udowodnić: (i) każdą transakcję T, która została wykonana i zatwierdzona przez walidatory; (ii) kolejność każdej transakcji T wykonanej i zatwierdzonej przez walidatory; oraz (iii) powstałe stany blockchain Sⱽ po zatwierdzeniu każdej transakcji T. W Aptos osiągamy to poprzez: (i) budowanie drzew merkle nad zatwierdzonymi transakcjami i wynikającymi z nich stanami blockchain; oraz (ii) zlecanie walidacji podpisania merkle korzeni tych drzew w celu ich uwierzytelnienia.
3. Korzeń zaufania: biorąc pod uwagę, że Aptos obsługuje dynamiczne zestawy walidatorów (tj. zmiany walidatorów w każdej epoce), peery muszą być w stanie zidentyfikować bieżący zestaw walidatorów na podstawie zweryfikowanej historii łańcucha bloków Aptos. Osiągamy to poprzez: (i) blob genezy uwierzytelniony przez Aptos, który identyfikuje pierwszy zestaw walidatorów i początkowy stan łańcucha bloków S⁰; oraz (ii) ostatni zaufany punkt orientacyjny (np. skrót bieżącego zestawu walidatorów i stan łańcucha bloków Sⱽ). Razem, blob genezy i punkt orientacyjny tworzą podstawę zaufania, umożliwiając peerom synchronizację prawdziwego łańcucha bloków Aptos i zapobieganie atakom (np. atakom dalekiego zasięgu).

Osiągnięcie 1k TPS: naiwne podejście

Korzystając z modelu i bloków konstrukcyjnych przedstawionych powyżej, możemy teraz zilustrować protokół synchronizacji stanów. Ten protokół jest uproszczeniem oryginalnego protokołu używanego przez Aptos (tj. State sync v1).

Protokół działa w następujący sposób: (i) Alicja (peer synchronizujący) identyfikuje najwyższą lokalnie utrwaloną wersję V łańcucha bloków i stan Sⱽ. Jeśli żaden nie istnieje, Alicja używa genezy, tj. S⁰; (ii) Alicja następnie losowo wybiera partnera, Boba, i żąda wszelkich nowych sekwencyjnych transakcji, które zostały zatwierdzone przez weryfikatory; (iii) jeśli Alicja otrzyma odpowiedź od Boba, Alicja zweryfikuje nowe transakcje (T⁰ do Tᴺ) i wykona je, aby wytworzyć deltę stanu (D⁰ᵥ do Dᵀᵥ₊ₙ); (iv) Alicja zastosuje następnie nową deltę stanu do pamięci wraz z nowymi transakcjami, aktualizując lokalny stan łańcucha bloków z Sⱽ do Sⱽ⁺¹⁺ᴺ. Alicja powtarza tę pętlę w nieskończoność. Pseudokod dla protokołu wygląda następująco:

State Sync v1 (Pseudocode)

Wdrożyliśmy ten protokół w Aptos, przetestowaliśmy go na devnet i przeanalizowaliśmy. Niektóre z kluczowych obserwacji, jakie poczyniliśmy, to:

1. Przepustowość jest związana z opóźnieniami sieci: ten protokół osiąga maksymalnie ~1,2 tys. TPS. Jednak na przepustowość duży wpływ mają opóźnienia w sieci, ponieważ Alicja żąda danych sekwencyjnie i musi czekać na odpowiedź węzła równorzędnego. Biorąc pod uwagę, że średni czas podróży w obie strony (RTT) w sieci wynosi 150 ms w devnet, jest to nieoptymalne. Procesor jest zdominowany przez wykonanie: kiedy Alicja otrzymuje nowy zestaw transakcji do synchronizacji, widzimy, że 55% czasu procesora poświęca się na wykonywanie transakcji, a 40% poświęca się na weryfikację danych, stosowanie delt stanu do przechowywania i utrwalanie nowych transakcje. Pozostałe 5% przypisuje się obsłudze wiadomości, serializacji i innym zadaniom.
2. Opóźnienie jest wysokie: podczas działania sieci przy maksymalnym obciążeniu średnie opóźnienie, w którym Alicja otrzymuje nowe transakcje, wynosi ~900 ms po ich zatwierdzeniu. Wynika to przede wszystkim z tego, że Alicja losowo wybiera peerów podczas żądania danych i nie bierze pod uwagę topologii sieci: peery, które są bliżej walidatorów, szybciej otrzymają nowe transakcje.
3. Bootstrapping jest powolny: Powyższy protokół wymaga od Alice powtórzenia i zsynchronizowania wszystkich transakcji od momentu powstania. Jeśli Alicja jest daleko w tyle za najnowszym stanem, musi odczekać dużo czasu, zanim będzie mogła zrobić cokolwiek pożytecznego (może to zająć godziny, a nawet dni!).
4. Wydajność można łatwo manipulować: wydajność tego protokołu jest w dużym stopniu uzależniona od złośliwych elementów równorzędnych. Jak wskazano w punkcie 1 powyżej, celowo powolne (lub niereagujące) elementy równorzędne zmuszą Alicję do spędzania długiego czasu w oczekiwaniu na dane i nie robienia niczego. W ten sposób znacznie wydłuża się czas synchronizacji.
5. Użycie zasobów jest wysokie: Ten protokół jest kosztowny dla wszystkich typów zasobów: (i) Użycie procesora jest wysokie, ponieważ Alicja musi ponownie wykonać wszystkie transakcje; (ii) ilość pamięci jest wysoka, ponieważ Alicja musi przechowywać wszystkie transakcje i stany łańcucha bloków od momentu powstania; oraz (iii) wykorzystanie sieci jest wysokie, ponieważ Alicja musi odbierać wszystkie transakcje od momentu powstania za pośrednictwem sieci. To automatycznie nakłada wysokie koszty i wymagania dotyczące zasobów, zmniejszając niejednorodność.
6. Zasoby są marnowane: podczas gdy Alicja synchronizuje nowe dane, równorzędni w sieci również synchronizują się z nią. Wraz ze wzrostem liczby peerów żądających danych od Alice, do obsługi tych żądań wymagane jest dodatkowe obciążenie pamięcią masową i procesorem. Jednak większość obliczeń, które wykonuje Alice, aby obsłużyć te żądania, jest marnotrawstwem, ponieważ peery często żądają tych samych danych.

Osiągnięcie 10 tys. TPS: zoptymalizowane podejście

Patrząc na naiwny protokół powyżej, możemy wprowadzić szereg modyfikacji, które pomogą wyeliminować ograniczenia. Najpierw rozszerzamy protokół o obsługę 2 dodatkowych trybów synchronizacji:

Synchronizacja delta stanów:

Biorąc pod uwagę, że walidatory już wykonują transakcje i potwierdzają wynikowe stany łańcucha bloków za pomocą dowodów Merkle, partnerzy mogą polegać na deltach stanów wytwarzanych przez walidatory, aby pominąć wykonanie transakcji. Pozwala to uniknąć: (i) wysokich kosztów wykonania, redukując czas procesora o około 55%; oraz (ii) zapotrzebowanie na maszynę wirtualną Aptos, co znacznie upraszcza implementację synchronizacji delta. W rezultacie peery mogą teraz synchronizować się, pobierając każdą transakcję T i deltę stanu Dᵀᵥ i stosując je do pamięci w celu wytworzenia nowego stanu Sⱽ⁺¹. Zauważamy, że odbywa się to kosztem zwiększonego wykorzystania sieci (o ok. 2,5x).

Synchronizacja migawek łańcucha bloków:

Biorąc pod uwagę, że walidatory potwierdzają każdy stan Sⱽ łańcucha bloków, możemy jeszcze bardziej skrócić czas ładowania, umożliwiając partnerom bezpośrednie pobranie najnowszego stanu łańcucha bloków (zamiast tworzenia go za pomocą transakcji lub delt stanów). To znacznie skraca czas ładowania i jest podobnym podejściem do synchronizacji przystawki w Ethereum. Kompromis polega na tym, że peery nie będą przechowywać żadnych transakcji ani stanów łańcucha bloków przed Sⱽ.

Następnie wdrażamy szereg ogólnych optymalizacji i dodatkowych funkcji, aby poprawić wydajność i skalowalność:

Wstępne pobieranie danych: aby zapobiec wpływowi opóźnień w sieci na przepustowość, możemy wykonać wstępne pobieranie danych. Peery mogą wstępnie pobierać dane transakcyjne (np. transakcje i delty stanu) od innych peerów przed ich przetworzeniem, amortyzując opóźnienia w sieci. Wykonywanie i magazynowanie potokowe: aby jeszcze bardziej zwiększyć przepustowość synchronizacji, możemy oddzielić wykonywanie transakcji od trwałości magazynu i użyć potoku: powszechnie używanej optymalizacji w projektowaniu procesorów. Pozwala to na wykonanie transakcji T², podczas gdy transakcja T¹ i delta stanu Dᵀ¹ᵥ są jednocześnie utrwalane w pamięci.

Monitorowanie peerów i reputacja: Aby poprawić obserwowalność i lepiej tolerować złośliwych peerów, możemy wdrożyć usługę monitorowania peerów, aby: (i) monitorować peerów pod kątem złośliwych zachowań (np. przesyłanie nieprawidłowych danych); (ii) identyfikować metadane dotyczące każdego partnera, takie jak podsumowanie wszystkich danych transakcyjnych, jakie posiada partner i postrzegana przez niego odległość od zestawu walidatorów; oraz (iii) utrzymywać lokalny wynik dla każdego partnera. Informacje te można następnie wykorzystać do optymalizacji wyboru partnerów podczas żądania nowych danych łańcucha bloków.

Buforowanie danych: Aby zmniejszyć obciążenie pamięci masowej odczytu i zapobiec wykonywaniu nadmiarowych obliczeń podczas synchronizacji stanu, gdy coraz więcej urządzeń równorzędnych synchronizuje dane, możemy zaimplementować pamięć podręczną danych, która przechowuje w pamięci często żądane elementy danych i odpowiedzi. Przycinanie pamięci masowej: aby zapobiec ciągłemu powiększaniu się pamięci masowej w czasie (np. w miarę realizacji większej liczby transakcji), możemy również wdrożyć dynamiczne przycinanie, aby usunąć niepotrzebne dane transakcji i łańcucha bloków z pamięci, np. wszystko starsze niż kilka dni, tygodni lub miesięcy, w zależności od konfiguracji równorzędnej.

Wdrożyliśmy te modyfikacje i stworzyliśmy nowy protokół synchronizacji stanu (tj. State Sync v2). Porównaliśmy to na devnet i zaobserwowaliśmy:

1. Przepustowość zwiększona o 5x-10x: Podczas wykonywania transakcji (bez wykonywania równoległego) protokół osiąga teraz maksymalnie ~4,5 tys. TPS, głównie w wyniku potokowania i wstępnego pobierania danych (tj. protokół jest teraz w stanie w pełni nasycić procesor ). Podczas synchronizacji delt stanów protokół osiąga znacznie ponad 10 tys. TPS, co jest kolejnym wynikiem unikania wykonywania transakcji. W obu przypadkach na przepływność nie ma już wpływu opóźnienie sieci.
2. Opóźnienie zostało zmniejszone trzykrotnie: podczas działania sieci przy maksymalnym obciążeniu widzimy teraz, że średni czas oczekiwania Alicji na otrzymanie nowych transakcji wynosi ~300 ms po ich zatwierdzeniu. Wynika to z pobierania danych z wyprzedzeniem i bardziej wydajnej selekcji peerów: z peerami, którzy są bardziej responsywni i bliżej walidatorów, kontaktuje się częściej.
3. Bootstrapping jest znacznie szybszy: użytkownicy korzystający z synchronizacji migawek łańcucha bloków są w stanie wykonać rozruch znacznie szybciej. Co więcej, na czas ładowania początkowego nie ma już wpływu długość łańcucha bloków (tj. liczba transakcji), ale raczej liczba zasobów w łańcuchu do synchronizacji. Obecnie w devnet rówieśnicy mogą uruchamiać się w ciągu kilku minut***.
4. Zmniejszone wymagania dotyczące zasobów: dzięki wielu trybom synchronizacji i przycinaniu pamięci wymagania dotyczące zasobów zostały zmniejszone. Co więcej, istnieje teraz wsparcie dla heterogeniczności, ponieważ peery mają elastyczność w wyborze strategii synchronizacji. Na przykład: peery z ograniczonym procesorem mogą pominąć wykonanie transakcji; peery, które chcą szybko się aktualizować, mogą wykonywać synchronizację migawek łańcucha bloków.
5. Zasoby są efektywniej wykorzystywane: podczas obsługi żądań synchronizacji od równorzędnych użytkowników obserwujemy znacznie mniejsze obciążenie pamięci masowej podczas odczytu i mniej zmarnowanego procesora. Wynika to z nowej pamięci podręcznej danych, która przechowuje w pamięci często żądane elementy danych i odpowiedzi. Widzimy również, że wraz ze wzrostem liczby synchronizujących elementów równorzędnych w devnet pamięć podręczna danych staje się bardziej wydajna, np. przy 20 synchronizujących elementach równorzędnych wskaźnik trafień w pamięci podręcznej wynosi 70%-80% na żądanie. Jednak w przypadku 60 równorzędnych użytkowników widzimy wskaźnik trafień w pamięci podręcznej na poziomie 93%-98%. Wiąże się to z kosztem dodatkowych ~150 MB pamięci RAM do obsługi pamięci podręcznej.

100 000 TPS i więcej?

Chociaż poprawiliśmy już przepustowość dziesięciokrotnie, a opóźnienia trzykrotnie, zdajemy sobie sprawę, że jest jeszcze wiele do zrobienia. Zwłaszcza jeśli chcemy dopasować Block-STM i uczynić Aptos warstwą 1 dla każdego!

Jak więc się tam dostaniemy? Cóż, już rozpoczęliśmy nasz kolejny cel synchronizacji stanu: ponad 100 000 TPS! Chociaż planujemy zachować szczegóły w przyszłym wpisie na blogu, chcieliśmy podać kilka wskazówek dla bardzo zapalonego czytelnika:

Grupowanie transakcji: Obecnie Aptos traktuje każdą transakcję jako weryfikowalną, tj. Dowody Merkle używane do uwierzytelniania i weryfikacji danych działają na szczegółowości transakcji. To sprawia, że weryfikacja i przechowywanie są niezwykle kosztowne. Jednym ze sposobów uniknięcia tego jest przeprowadzanie grupowania transakcji, tj. sprawdzanie partii (lub bloków!) transakcji.

Kompresja sieci: przepustowość sieci często staje się wąskim gardłem w sieciach peer-to-peer, a Aptos nie jest wyjątkiem. Obecnie prefetcher synchronizacji stanu może pobrać około ~45K TPS w devnet przed nasyceniem przepustowości. To jest problem, jeśli chcemy skalować. Na szczęście już zauważyliśmy, że peery dystrybuują dane przy użyciu nieefektywnego formatu serializacji, a dzięki zastosowaniu gotowej kompresji możemy zmniejszyć ilość przesyłanych danych ponad 10-krotnie.

Szybsze zapisy w pamięci masowej: obecnie przepustowość synchronizacji stanu jest ograniczona przez czas potrzebny na utrwalenie danych łańcucha bloków w pamięci masowej. Aktywnie przyglądamy się różnym optymalizacjom i ulepszeniom, które możemy wprowadzić, aby usunąć to wąskie gardło, w tym: (i) wydajniejsze struktury danych; (ii) bardziej optymalne konfiguracje przechowywania; oraz (iii) alternatywne silniki pamięci masowej.

Równoległe przetwarzanie danych: do tej pory wymagaliśmy sekwencyjnej synchronizacji stanu przetwarzania danych (np. obsługi transakcji w kolejno rosnących wersjach). Istnieje jednak wiele istniejących podejść, które pozwolą nam uniknąć tego wymogu i wykorzystać równoległe przetwarzanie danych do znacznego zwiększenia przepustowości, np. sharding blockchain!

Do następnego razu!

link do oryginału; https://medium.com/aptoslabs/the-evolution-of-state-sync-the-path-to-100k-transactions-per-second-with-sub-second-latency-at-52e25a2c6f10