Autor: Tia, Techub News
Blockchain ze względu na swoją zdecentralizowaną konstrukcję poświęca wydajność, dlatego poprawa prędkości wykonania zawsze była jednym z pilnych problemów do rozwiązania. „Warstwa wykonawcza” blockchaina jest kluczowym elementem przetwarzania każdej transakcji i dodawania jej do łańcucha. Aby przyspieszyć zdolność przetwarzania, poprawa warstwy wykonawczej stała się jedną z kluczowych strategii, a równoległe wykonanie jest istotnym przełomem w tym zakresie.
Tradycyjne blockchainy zazwyczaj przetwarzają transakcje sekwencyjnie, co znacznie ogranicza prędkość transakcji, zwłaszcza w gęstych sieciach, prowadząc do zatorów. Jednak dzięki równoległemu wykonaniu wiele transakcji może być przetwarzanych jednocześnie, co znacznie zwiększa wydajność wykonania i zmniejsza obciążenie na łańcuchu.
Aby lepiej zrozumieć, czym jest równoległość, zaczniemy od wprowadzenia do wykonania i użyjemy Ethereum w trybie PBS po scaleniu jako przykładu, aby wyjaśnić, czym jest wykonanie i pokazać miejsce wykonania w całym cyklu życia transakcji.
Konkretne aspekty wykonania transakcji
Transakcje wchodzą do puli pamięci i są sortowane i filtrowane: to jest faza wstępnego przetwarzania po złożeniu transakcji, która obejmuje interakcję między Mempool, Searcher i Builder, kończąc na filtrowaniu i sortowaniu transakcji.
Builder buduje blok (ale nie wykonuje): Builder układa korzystne transakcje w blok, aby zakończyć pakowanie i sortowanie transakcji.
Propozycja weryfikuje i przesyła blok: Po zakończeniu budowy bloku, Builder wysyła propozycję bloku do Propozytora. Propozytor weryfikuje strukturę bloku i zawartość transakcji, a następnie oficjalnie przesyła blok do sieci, aby rozpocząć wykonanie.
Wykonanie transakcji: Po przesłaniu bloku, węzły wykonują transakcje w bloku jedna po drugiej. To jest kluczowa faza aktualizacji stanu, każda transakcja wywołuje wywołanie inteligentnego kontraktu, zmiany salda konta lub zmiany stanu.
Świadkowie świadczą: weryfikatorzy świadczą o wyniku wykonania bloku i korzeniu stanu, a następnie potwierdzają to jako ostateczne. To zapewnia autentyczność i ważność bloku w warstwie wykonawczej oraz zapobiega niespójnościom.
Synchronizacja stanu: Każdy węzeł synchronizuje wyniki wykonania bloku (takie jak saldo konta, aktualizacje stanu kontraktu itp.) z własnym lokalnym stanem. Po wykonaniu każdej transakcji węzeł oblicza i przechowuje nowy korzeń stanu, aby użyć go jako stanu początkowego w następnym bloku.
Oczywiście, to tylko synchronizacja stanu transakcji na jednostkach bloków. Aby utrzymać najnowszy stan na łańcuchu, w normalnych warunkach węzły synchronizują dane blok po bloku, stale weryfikując bloki i stany. Ale aby osiągnąć ostateczność w mechanizmie POS, agregatorzy muszą złożyć podpisy świadków z każdego slotu w jeden kompletny podpis i przekazać go do propozytora następnego slotu, a weryfikatorzy muszą po jednym epoku potwierdzić stan wszystkich bloków w tym epoku na podstawie liczby głosów, tworząc tymczasowy punkt kontrolny stanu konsensusu. Po uzyskaniu większości wsparcia świadków w dwóch kolejnych epokach bloki i transakcje osiągają ostateczność.
Z perspektywy całego cyklu życia transakcji, wykonanie odbywa się po tym, jak Propozytor weryfikuje strukturę bloku i zawartość transakcji przesłanych przez Buildera. Rzeczywisty proces wykonania wymaga przetwarzania transakcji jedna po drugiej oraz aktualizacji odpowiednich kont lub stanów kontraktów. Po zakończeniu wszystkich transakcji, Propozytor oblicza nowy korzeń stanu (korzeń Merkle'a), co stanowi podsumowanie wyników wykonania wszystkich transakcji w bieżącym bloku oraz ostatecznego globalnego stanu. Mówiąc prościej, cały proces wykonania bloku obejmuje szereg obliczeń, które muszą być przeprowadzone, aby przekształcić Ethereum z poprzedniego stanu w nowy stan, od wykonania każdej transakcji do obliczenia korzenia Merkle'a.
Wykonanie sekwencyjne
W przeciwieństwie do równoległości, istnieje wykonanie sekwencyjne, czyli obecnie bardziej powszechny sposób wykonywania w blockchainie. Zazwyczaj transakcje są wykonywane jeden po drugim w kolejności. Po zakończeniu wykonania transakcji, Ethereum aktualizuje stan konta i powiązane informacje (takie jak saldo, dane przechowywane w kontrakcie) w drzewie stanu konta, generując nowy hash stanu konta. Po zakończeniu aktualizacji całego drzewa stanu konta, powstaje tzw. korzeń Merkle'a stanu. Po zakończeniu korzeni Merkle'a stanu, Merkle'a transakcji i Merkle'a potwierdzenia, nagłówek bloku przechodzi przez obliczenia haszujące, generując hash bloku.
W tym kontekście kolejność wykonania transakcji jest kluczowa. Ponieważ drzewo Merkle'a jest drzewem binarnym hashy, różne kolejności prowadzą do różnych wartości korzenia Merkle'a.
Równoległe wykonanie
W środowisku równoległego wykonania węzły starają się równolegle przetwarzać transakcje w bloku. Nie wykonują transakcji jedna po drugiej, ale rozdzielają je na różne „ścieżki wykonawcze”, co pozwala im na jednoczesne wykonywanie. Dzięki równoległemu wykonaniu system może efektywniej obsługiwać transakcje w blokach, zwiększając przepustowość.
Po zakończeniu wszystkich transakcji, węzły zbierają wyniki wykonania (tj. aktualizacje stanu wynikające z transakcji), tworząc nowy stan bloku. Stan ten jest dodawany do blockchaina, reprezentując najnowszy globalny stan na łańcuchu.
Konflikty stanu
Ponieważ równoległość przetwarza transakcje na różnych ścieżkach, jednym z największych wyzwań jest konflikt stanu. Istnieje możliwość, że wiele transakcji jednocześnie odczyta lub zapisze dane (stan) na tym samym fragmencie blockchaina. Jeśli nie będzie to odpowiednio zarządzane, wyniki wykonania mogą być niepewne. Z powodu różnej kolejności aktualizacji stanu końcowy wynik obliczeń może być różny. Na przykład,
Załóżmy, że istnieją dwie transakcje, transakcja A i transakcja B, które próbują zaktualizować saldo tego samego konta:
Transakcja A: zwiększ saldo konta o 10.
Transakcja B: zwiększ saldo konta o 20.
Początkowe saldo konta wynosi 100.
Jeśli wykonujemy serialnie, wynik kolejności wykonania jest określony:
1. Najpierw wykonaj transakcję A, potem transakcję B:
Saldo konta najpierw wzrasta o 10, co daje 110.
Następnie dodaj 20, co w końcu daje 130.
2. Najpierw wykonaj transakcję B, potem transakcję A:
Saldo konta najpierw wzrasta o 20, co daje 120.
Dodaj jeszcze 10, co w końcu daje 130.
W obu tych kolejnościach, ostateczny bilans wynosi 130, ponieważ system zapewnia spójność kolejności wykonywania transakcji.
Jednak w środowisku równoległego wykonania, transakcja A i transakcja B mogą jednocześnie odczytać początkowe saldo 100 i przeprowadzić własne obliczenia:
Transakcja A odczytuje saldo 100, a po obliczeniach aktualizuje saldo do 110.
Transakcja B również odczytuje saldo 100, a po obliczeniach aktualizuje saldo do 120.
W tej sytuacji, ponieważ transakcje wykonują się jednocześnie, ostateczne saldo aktualizuje się tylko do 120, a nie 130, ponieważ operacje transakcji A i B „nadpisują” wyniki wzajemnie, co powoduje konflikt stanu.
Takie problemy z konfliktami stanu zazwyczaj określane są jako „nadzór danych”, co oznacza, że gdy transakcje próbują jednocześnie zmienić te same dane, mogą wzajemnie nadpisać swoje wyniki obliczeń, co prowadzi do niepoprawnego stanu końcowego. Innym problemem, który może wystąpić w wyniku konfliktu stanu, jest niemożność zapewnienia kolejności wykonania. Ponieważ wiele transakcji kończy swoje operacje w różnych momentach, może to prowadzić do różnych wyników obliczeń w różnych kolejnościach, co z kolei powoduje niepewność wyniku.
Aby uniknąć tej niepewności, systemy równoległego wykonania blockchaina zazwyczaj wprowadzają mechanizmy wykrywania konfliktów i wycofywania, lub wcześniej przeprowadzają analizę zależności transakcji, aby upewnić się, że mogą być wykonywane równolegle bez wpływu na ostateczną spójność stanu.
Optymistyczna równoległość i deterministyczna równoległość
Istnieją dwa podejścia do radzenia sobie z problemem potencjalnych konfliktów stanu: równoległość deterministyczna i równoległość optymistyczna. Oba te tryby mają swoje kompromisy w zakresie wydajności i złożoności projektowej.
Równoległość deterministyczna wymaga wcześniejszego zadeklarowania dostępu do stanu, weryfikatorzy lub sekwencery sprawdzają zadeklarowany dostęp do stanu podczas sortowania transakcji. Jeśli wiele transakcji próbuje zapisać do tego samego stanu, te transakcje są oznaczane jako konfliktowe, aby uniknąć równoległego wykonania. Różne łańcuchy wprowadzają różne formy wcześniejszego deklarowania dostępu do stanu, ale zazwyczaj obejmują one następujące metody:
Poprzez ograniczenia specyfikacji kontraktów: deweloperzy bezpośrednio określają zakres dostępu do stanu w inteligentnych kontraktach. Na przykład, transfer tokenów ERC-20 wymaga dostępu do pól salda nadawcy i odbiorcy.
Poprzez strukturalne deklaracje danych transakcji: dodanie specjalnych pól do transakcji, aby oznaczyć dostęp do stanu.
Poprzez analizę kompilatora: kompilatory języków wysokiego poziomu mogą przeprowadzać statyczną analizę kodu kontraktu, automatycznie generując zbiór dostępu do stanu.
Poprzez wymuszanie deklaracji przez framework: niektóre frameworki wymagają, aby deweloperzy jawnie określali potrzebny stan podczas wywoływania funkcji.
Optymistyczna równoległość najpierw optymistycznie przetwarza transakcje, a gdy występuje konflikt, ponownie wykonuje dotknięte transakcje w kolejności. Aby jak najbardziej uniknąć konfliktów, rdzeń projektowania optymistycznej równoległości polega na szybkim przewidywaniu i hipotezach dotyczących stanu na podstawie danych historycznych, analizy statycznej itp. To oznacza, że system zakłada, że pewne operacje lub aktualizacje stanu są ważne w sytuacji, gdy nie są w pełni zweryfikowane, starając się uniknąć czekania na wszystkie procesy weryfikacyjne, co zwiększa wydajność i przepustowość.
Chociaż optymistyczna równoległość może unikać konfliktów poprzez szybkie przewidywanie i hipotezy dotyczące stanu, istnieje wiele nieuniknionych wyzwań, szczególnie w przypadku wykonania kontraktu lub transakcji między łańcuchami. Jeśli konflikty występują często, ponowne wykonanie może znacznie spowolnić wydajność systemu i zwiększyć zużycie zasobów obliczeniowych.
Równoległość deterministyczna unika konfliktów, które mogą wystąpić przy optymistycznej równoległości, przeprowadzając przed transakcją kontrole zależności stanu, ale wymaga dokładnego zadeklarowania zależności stanu przed złożeniem transakcji, co stawia wyższe wymagania przed deweloperami, zwiększając tym samym złożoność realizacji.
Dylemat EVM równoległego
Radzenie sobie z konfliktami stanu nie tylko różni się między deterministycznym a optymistycznym, ale w konkretnej realizacji równoległości trzeba również brać pod uwagę architekturę bazy danych łańcucha. Problemy z konfliktami stanu w równoległości są szczególnie trudne w EVM opartym na architekturze drzewa Merkle'a. Drzewo Merkle'a to struktura haszująca w hierarchii, a po każdej transakcji zmieniającej dane stanu, korzeń haszujący drzewa Merkle'a musi również zostać zaktualizowany. Proces aktualizacji jest rekurencyjny, obliczany od liści w górę do korzenia. Ponieważ haszowanie jest nieodwracalne, obliczenia na wyższych poziomach mogą odbywać się tylko po zakończeniu zmian na niższych poziomach, co sprawia, że trudno jest zaktualizować drzewo równolegle.
Jeśli dwie transakcje wykonują się równolegle i uzyskują dostęp do tego samego stanu (np. salda konta), może to prowadzić do konfliktów w węzłach drzewa Merkle'a. Rozwiązywanie takich konfliktów zazwyczaj wymaga dodatkowych mechanizmów zarządzania transakcjami, aby zapewnić spójny korzeń hashu w wielu gałęziach. Dla EVM nie jest to łatwe do osiągnięcia, ponieważ wymaga kompromisu między równoległością a spójnością stanu.
Rozwiązania równoległe bez EVM
Solana
W przeciwieństwie do globalnego drzewa stanu Ethereum, Solana przyjęła model kont. Każde konto jest niezależną przestrzenią przechowywania, przechowywaną w księdze, co pozwala uniknąć problemu konfliktu ścieżek.
Solana jest równoległa deterministycznie. W Solanie każda transakcja musi w momencie złożenia wyraźnie zadeklarować, które konta będą używane i jakie są wymagane uprawnienia dostępu (tylko do odczytu lub do odczytu i zapisu). Taki projekt pozwala węzłom blockchaina na wcześniejsze analizowanie zasobów potrzebnych dla każdej transakcji przed jej wykonaniem. Ponieważ wszystkie zależności kont są już wyraźnie zadeklarowane przed rozpoczęciem wykonania, węzły mogą ocenić, które transakcje będą uzyskiwać dostęp do tych samych kont i które transakcje mogą być bezpiecznie wykonywane równolegle, co pozwala na inteligentne harmonogramowanie i unikanie konfliktów, co stanowi podstawę równoległego harmonogramowania.
Ponieważ przed każdą transakcją zadeklarowano, które konta i uprawnienia są wymagane, Solana może sprawdzić, czy istnieją zależności między kontami w transakcjach (model Sealevel). Jeżeli transakcje nie dzielą wspólnych kont do odczytu i zapisu, system może przydzielić je do różnych procesorów i wykonać równolegle.
Aptos
Projekt równoległego wykonania Aptos różni się znacznie od Ethereum, wprowadza kluczowe innowacje w architekturze i mechanizmach, głównie w modelu kont i przechowywaniu stanu.
Ethereum wymaga częstych aktualizacji globalnego drzewa stanu (MPT) podczas wykonywania transakcji. Wszystkie konta i stany kontraktów są przechowywane w jednym wspólnym drzewie stanu, a każda transakcja musi uzyskać dostęp do i zaktualizować część tego drzewa stanu. Aptos dzieli konta na niezależne jednostki stanu, gdzie każdy obiekt jest niezależną parą klucz-wartość, obiekty mogą istnieć niezależnie, nie wpływając na siebie nawzajem, a łączą się tylko w przypadku wyraźnej relacji odniesienia. Obiekty nie mają wspólnej ścieżki drzewa, co eliminuje rywalizację o blokady, co pozwala na pełną równoległość.
Podstawową strukturą danych Aptos jest Jellyfish Merkle Tree. Stan każdego obiektu jest ostatecznie przechowywany w JMT jako niezależna para klucz-wartość. W przeciwieństwie do MPT Ethereum, Jellyfish Merkle Tree ma strukturę pełnego drzewa binarnego, co upraszcza ścieżki przechowywania i zapytań, znacznie redukując czas weryfikacji. Dodatkowo, miejsce każdego konta w drzewie jest stałe, a węzły drzewa są przechowywane niezależnie, co pozwala na równoległą aktualizację i wyszukiwanie wielu kont.
Aptos jest optymistyczny pod względem równoległości, nie wymaga wcześniejszego dostarczenia wszystkich zależności kont. W tym celu Aptos używa Block-STM, który wykorzystuje ustaloną kolejność transakcji do oszacowania zależności, co zmniejsza liczbę przerwań.
Równoległy EVM
W przeciwieństwie do równoległych systemów bez EVM, równoległy EVM napotyka większe trudności techniczne w radzeniu sobie z zależnościami stanu, wykrywaniem konfliktów, zarządzaniem gazem i mechanizmami wycofywania. Aby lepiej zrozumieć tę sytuację, możemy odwołać się do niektórych projektów równoległego EVM (takich jak Sui, Monad, Canto), które radzą sobie z tymi problemami.
Sui
Sui, podobnie jak Aptos, również używa modelu obiektowego do obsługi stanu, wykorzystując każdy obiekt (np. konto, stan inteligentnego kontraktu) jako niezależny zasób, który jest rozróżniany przez unikalny identyfikator obiektu. Gdy transakcje dotyczą różnych obiektów, mogą być wykonywane równolegle, ponieważ operują na różnych stanach, co nie prowadzi do bezpośrednich konfliktów.
Chociaż Sui wykorzystuje model obiektowy do zarządzania stanem, aby być zgodnym z EVM, architektura Sui wprowadza dodatkową warstwę adaptacyjną lub mechanizm abstrakcji, aby połączyć model obiektowy z modelem kont EVM.
W Sui, harmonogram transakcji używa strategii równoległej optymistycznej, zakładając, że nie ma konfliktów między transakcjami. Jeśli wystąpi konflikt, system używa mechanizmu wycofywania do przywrócenia stanu.
Sui używa modelu obiektowego i technologii izolacji stanu, co skutecznie unika problemów z zależnością stanu. Każdy obiekt jako niezależny zasób, różne transakcje mogą być wykonywane równolegle, co zwiększa przepustowość i wydajność. Jednak ta metoda ma swoje trade-offy, takie jak złożoność modelu obiektowego i koszty mechanizmu wycofywania. Jeśli wystąpią konflikty między transakcjami, może być konieczne wycofanie części stanu, co zwiększa obciążenie systemu i może wpływać na wydajność przetwarzania równoległego. W porównaniu do systemów równoległych bez EVM (takich jak Solana), Sui potrzebuje więcej zasobów obliczeniowych i pamięci do utrzymania efektywnej równoległości.
Monad
Podobnie jak Sui, Monad również stosuje optymistyczną równoległość. Jednak optymistyczna równoległość Monad przed rzeczywistym wykonaniem transakcji przewiduje niektóre transakcje z zależnościami, a przewidywania te są realizowane głównie przez statyczny analizator kodu Monad. Przewidywanie wymaga dostępu do stanu, a sposób przechowywania stanu w bazie danych Ethereum utrudnia dostęp do stanu, aby zwiększyć efektywność równoległości w procesie odczytu stanu, Monad również przekształcił bazę danych.
Drzewo stanu Monad jest podzielone na partycje, każda partycja utrzymuje swój własny poddrzewo stanu. Podczas aktualizacji wystarczy zmienić odpowiednie fragmenty, nie trzeba odbudowywać całego drzewa stanu. Dzięki tabeli indeksów stanu szybko lokalizowane są stany w partycji, co zmniejsza interakcje między partycjami.
Podsumowanie
Równoległość jest kluczowa dla zwiększenia wydajności warstwy wykonawczej poprzez wielościeżkowe wykonywanie, a aby osiągnąć wielościeżkowe wykonywanie, łańcuch musi wprowadzić szereg mechanizmów, takich jak wykrywanie konfliktów i mechanizmy wycofywania, aby zapewnić, że mogą być wykonywane równolegle bez wpływu na ostateczną spójność stanu oraz wprowadzić pewne ulepszenia do bazy danych.
Oczywiście, poprawa wydajności warstwy wykonawczej nie ogranicza się tylko do równoległości; optymalizacja etapu wykonania może również odbywać się poprzez zmniejszenie liczby operacji odczytu i zapisu, które transakcja wymaga w bazie danych. Całkowita poprawa prędkości łańcucha dotyczy szerszego zakresu, w tym także poprawy wydajności warstwy konsensusu.
Każda technologia ma swoje specyficzne ograniczenia. Równoległość jest tylko jednym ze sposobów na poprawę wydajności, a ostateczna decyzja o użyciu tej technologii musi uwzględniać, czy jest przyjazna dla deweloperów, czy można ją zrealizować bez poświęcania decentralizacji itp. Akumulacja technologii nie zawsze jest korzystna, przynajmniej w przypadku Ethereum, równoległość nie jest tak atrakcyjna, a jeśli chodzi o poprawę wydajności, dodanie równoległości w przypadku Ethereum nie jest optymalnym rozwiązaniem, biorąc pod uwagę zarówno kwestie prostoty, jak i obecny plan działania Ethereum koncentrujący się na Rollup.