Autor: Tia, Techub News
Blockchain, z powodu swojej zdecentralizowanej konstrukcji, poświęcił wydajność, więc zwiększenie szybkości wykonania zawsze było jednym z kluczowych problemów do rozwiązania. „Warstwa wykonawcza” blockchaina jest kluczowym elementem przetwarzania każdej transakcji i dodawania jej do łańcucha. Udoskonalenie zdolności przetwarzania na warstwie wykonawczej stało się jednym z kluczowych strategii, a równoległe wykonanie jest istotnym przełomem w tym zakresie.
Tradycyjne blockchainy zazwyczaj przetwarzają transakcje w sposób szeregowy, co znacznie ogranicza prędkość transakcji, szczególnie w gęstych sieciach, gdzie może wystąpić zator. 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ć, co to jest równoległość, zaczniemy od wykonania i weźmiemy Ethereum w modelu PBS po Merge jako przykład, aby wyjaśnić, czym jest wykonanie, jednocześnie pokazując, jakie miejsce zajmuje wykonanie w całym cyklu życia transakcji.
Szczegóły dotyczące wykonania transakcji
Transakcje wchodzą do puli pamięci i są filtrowane oraz sortowane: to jest faza wstępnego przetwarzania po złożeniu transakcji, obejmująca interakcje z Mempool, Searcher i Builder, aby ukończyć filtrowanie i sortowanie transakcji.
Builder buduje blok (ale go nie wykonuje): Builder porządkuje zyskowne transakcje w blok, aby zakończyć pakowanie i sortowanie transakcji.
Proposer weryfikuje i zatwierdza blok: Po zbudowaniu bloku Builder wysyła propozycję bloku do Proposera. Proposer weryfikuje strukturę bloku i zawartość transakcji, a następnie oficjalnie zatwierdza blok w sieci, aby rozpocząć jego wykonanie.
Wykonywanie transakcji: Po złożeniu bloku węzły wykonują transakcje w bloku jedna po drugiej. To kluczowa faza aktualizacji stanu, gdzie każda transakcja wywołuje wywołanie inteligentnego kontraktu, zmianę salda konta lub zmianę stanu.
Świadkowie potwierdzają: Walidatorzy potwierdzają wyniki wykonania bloku i korzeń stanu, traktując je jako ostateczne potwierdzenie. Zapewnia to autentyczność i ważność bloku na warstwie wykonawczej oraz zapobiega niespójności.
Synchronizacja stanu: Każdy węzeł synchronizuje wyniki wykonania bloku (takie jak saldo konta, aktualizacje stanu kontraktu itp.) do swojego lokalnego stanu. Po wykonaniu każdej transakcji węzeł oblicza i przechowuje nowy korzeń stanu, który służy jako stan początkowy w następnym bloku.
Oczywiście, to tylko synchronizacja stanu transakcji na poziomie bloków. Aby zachować aktualny stan na łańcuchu, węzły zazwyczaj synchronizują dane blok po bloku, nieprzerwanie weryfikując blok i stan. Aby osiągnąć ostateczność w mechanizmie POS, agregator musi złożyć podpisy świadków z każdego Slotu w jeden pełny podpis i przekazać go do proponującego w następnym Slocie, a walidatorzy muszą, po jednym Epochu, potwierdzić stan wszystkich bloków w tym Epochu na podstawie liczby głosów, tworząc tymczasowy punkt kontrolny konsensusu stanu. Dopiero po uzyskaniu poparcia większości walidatorów w dwóch kolejnych Epochach, blok i transakcje osiągną ostateczność.
Patrząc na cały cykl życia transakcji, wykonanie następuje po zweryfikowaniu przez Proposera struktury i zawartości bloku wysłanego przez Buildera. Proces wykonania wymaga przetwarzania transakcji jedna po drugiej i aktualizacji odpowiednich stanów kont lub kontraktów. Po zakończeniu wszystkich transakcji Proposer oblicza nowy korzeń stanu (korzeń Merkle), który jest podsumowaniem wyników wykonania wszystkich transakcji w bieżącym bloku oraz ostatecznego stanu globalnego. Mówiąc prosto, pełny proces wykonania bloku obejmuje szereg obliczeń, które muszą zostać ukończone, aby Ethereum mogło przejść z jednego stanu do następnego, od wykonania każdej transakcji po obliczenie korzenia Merkle.
Wykonanie szeregowe
W przeciwieństwie do równoległości, wykonanie szeregowe jest obecnie bardziej powszechną metodą wykonania w blockchainie. Zazwyczaj transakcje są wykonywane krok po kroku w kolejności. Po zakończeniu wykonania transakcji Ethereum aktualizuje stan konta oraz powiązane informacje (np. saldo, dane przechowywane w kontrakcie) w drzewie stanu konta, generując nowy hasz stanu konta. Po aktualizacji wszystkich drzew stanu konta powstaje korzeń hasza drzewa stanu, znany jako korzeń Merkle stanu. Po obliczeniu korzeni Merkle stanu, korzeni Merkle transakcji i korzeni Merkle dowodów, nagłówek bloku jest haszowany, generując hasz bloku.
W tej kwestii kolejność wykonywania transakcji jest kluczowa. Ponieważ drzewo Merkle to drzewo binarne z wartościami haszy, różne kolejności tworzą różne wartości korzeni Merkle.
Równoległe wykonanie
W środowisku równoległego wykonania węzły próbują równolegle przetwarzać transakcje w bloku. Nie są one wykonywane kolejno jedna po drugiej, lecz przypisane do różnych „ścieżek wykonania”, co pozwala im na równoległe działanie. Dzięki równoległemu wykonaniu system może bardziej efektywnie przetwarzać transakcje w bloku, zwiększając wydajność.
Po zakończeniu wszystkich transakcji, węzły zbierają wyniki wykonania (czyli aktualizacje stanu wynikające z transakcji) i tworzą nowy stan bloku. Ten stan zostaje dodany do łańcucha bloków, reprezentując najnowszy stan globalny na łańcuchu.
Konflikty stanu
Ponieważ równoległość przetwarza transakcje na różnych ścieżkach jednocześnie, jednym z głównych wyzwań równoległości są konflikty stanu. Istnieje możliwość, że wiele transakcji w tym samym czasie odczytuje lub zapisuje do tej samej części danych (stanu) w blockchainie. Jeśli nie zostanie to odpowiednio obsłużone, może prowadzić do niepewnych wyników wykonania. Ponieważ kolejność aktualizacji stanu różni się, ostateczne wyniki obliczeń również będą różne. Na przykład,
Załóżmy, że mamy dwie transakcje, transakcję A i transakcję B, które próbują jednocześnie 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 wykonamy to szeregowo, wynik kolejności wykonania jest pewny:
1. Najpierw wykonaj transakcję A, a potem transakcję B:
Saldo konta wzrasta najpierw o 10, staje się 110.
Następnie wzrasta o 20, ostatecznie staje się 130.
2. Najpierw wykonaj transakcję B, a potem transakcję A:
Saldo konta najpierw wzrasta o 20, staje się 120.
Następnie wzrasta o 10, ostatecznie staje się 130.
W obu tych kolejnościach końcowe saldo wynosi 130, ponieważ system zapewnia spójność kolejności wykonania transakcji.
Jednak w środowisku równoległego wykonania, transakcje A i B mogą jednocześnie odczytać początkowe saldo 100 i przeprowadzić swoje obliczenia:
1. Transakcja A odczytuje saldo jako 100, oblicza i aktualizuje saldo do 110.
2. Transakcja B także odczytuje saldo jako 100, oblicza i aktualizuje saldo do 120.
W tej sytuacji, ponieważ transakcje są wykonywane jednocześnie, ostateczne saldo aktualizuje się tylko do 120, a nie 130, ponieważ operacje transakcji A i B „nakładają się” na wyniki, co powoduje konflikt stanu.
Problemy z konfliktami stanu tego rodzaju nazywane są „nakładaniem danych”, co oznacza, że gdy transakcje próbują jednocześnie modyfikować te same dane, mogą wzajemnie nadpisywać wyniki obliczeń, prowadząc do błędnego stanu. Inny rodzaj problemu z konfliktem stanu może prowadzić do braku gwarancji co do kolejności wykonania. Ponieważ wiele transakcji kończy swoje operacje w różnych okresach czasu, może to prowadzić do różnych kolejności wykonania. Różne kolejności mogą prowadzić do różnych wyników obliczeń, co sprawia, że wyniki są niepewne.
Aby uniknąć tej niepewności, systemy równoległego wykonania blockchaina zazwyczaj wprowadzają pewne mechanizmy wykrywania konfliktów i wycofywania, lub dokonują wcześniejszej analizy zależności transakcji, aby zapewnić, że mogą być wykonywane równolegle bez wpływu na ostateczną spójność stanu.
Optymistyczna równoległość a deterministyczna równoległość
Są dwie metody podejścia do potencjalnych problemów z konfliktami stanu: deterministyczna równoległość i optymistyczna równoległość. Oba te tryby mają swoje kompromisy w zakresie efektywności i złożoności projektowej.
Deterministyczna równoległość wymaga wcześniejszego zadeklarowania dostępu do stanu, walidator lub sekwencer sprawdzają zadeklarowany dostęp do stanu podczas sortowania transakcji. Jeśli wiele transakcji próbuje zapisać ten sam stan, te transakcje są oznaczane jako konfliktowe, aby uniknąć jednoczesnego wykonania. Różne łańcuchy mają różne konkretne implementacje wcześniejszego zadeklarowania dostępu do stanu, ale ogólnie obejmują następujące metody:
Poprzez specyfikację umowy: Deweloperzy bezpośrednio określają zakres dostępu do stanu w inteligentnym kontrakcie. Na przykład, transfer tokenów ERC-20 wymaga dostępu do pól salda nadawcy i odbiorcy.
Poprzez strukturę danych transakcji: Dodanie specjalnych pól do transakcji w celu oznaczenia dostępu do stanu.
Poprzez analizę kompilatora: Kompilatory języków wysokiego poziomu mogą analizować kod kontraktów statycznie, automatycznie generując zestaw dostępu do stanu.
Poprzez wymuszenie deklaracji w ramach: Niektóre ramy wymagają od deweloperów wyraźnego określenia, które stany są wymagane w trakcie wywoływania funkcji.
Optymistyczna równoległość najpierw przetwarza transakcje, a gdy wystąpi konflikt, ponownie wykonuje dotknięte transakcje w kolejności. Aby uniknąć konfliktów, kluczowym elementem projektowania optymistycznej równoległości jest szybka ocena i hipotezy dotyczące stanu na podstawie danych historycznych i analizy statycznej. Oznacza to, że system, bez pełnej weryfikacji, zakłada, że niektóre operacje lub aktualizacje stanu są ważne, aby uniknąć czekania na wszystkie procesy weryfikacji, co zwiększa wydajność i przepustowość.
Chociaż optymistyczna równoległość może unikać konfliktów poprzez szybkie oszacowania i hipotezy dotyczące stanu, napotyka również nieuniknione wyzwania, szczególnie w przypadku wykonania kontraktów lub transakcji międzyłańcuchowych. 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ć w przypadku optymistycznej równoległości, poprzez sprawdzanie zależności stanu przed transakcją, ale wymaga od deweloperów dokładnego zadeklarowania zależności stanu przed złożeniem transakcji, co zwiększa złożoność realizacji.
Dylemat równoległości EVM
Zarządzanie konfliktami stanu obejmuje zarówno deterministyczną, jak i optymistyczną równoległość. W procesie realizacji równoległości z perspektywy architektury bazy danych łańcucha konieczne jest także rozważenie kwestii konfliktów stanu. Problemy związane z konfliktami stanu w równoległości są szczególnie trudne w EVM z architekturą drzewa Merkle. Drzewo Merkle to hierarchiczna struktura haszująca, która po każdej transakcji modyfikującej dane stanu wymaga aktualizacji wartości hasza korzenia. Proces aktualizacji jest rekurencyjny, obliczany od liści do korzenia. Ponieważ hasz jest nieodwracalny, można obliczyć wyższy poziom dopiero po zakończeniu modyfikacji danych na niższym poziomie, co sprawia, że równoległa aktualizacja jest bardzo trudna.
Jeśli dwie transakcje są wykonywane równolegle i uzyskują dostęp do tego samego stanu (np. saldo konta), spowoduje to konflikt w węzłach drzewa Merkle. Rozwiązanie takiego konfliktu zazwyczaj wymaga dodatkowych mechanizmów zarządzania transakcjami, aby zapewnić spójny korzeń hasza w wielu gałęziach. To nie jest łatwe do zrealizowania dla EVM, ponieważ wymaga dokonania wyboru między równoległością a spójnością stanu.
Rozwiązania równoległe, które nie są EVM
Solana
W przeciwieństwie do globalnego drzewa stanu Ethereum, Solana przyjęła model kont. Każde konto ma niezależną przestrzeń do przechowywania, co eliminuje problemy z konfliktem ścieżek.
Solana to równoległość deterministyczna. W Solanie każda transakcja musi przy składaniu wyraźnie zadeklarować, które konta i jakich uprawnień potrzebuje (tylko do odczytu lub do odczytu i zapisu). Taki projekt pozwala węzłom blockchaina na wcześniejsze analizowanie zasobów, do których każda transakcja będzie miała dostęp przed jej wykonaniem. Ponieważ przed rozpoczęciem wykonania transakcje zadeklarowały wszystkie zależności konta, węzły mogą ocenić, które transakcje będą miały dostęp do tego samego konta, a które transakcje można bezpiecznie wykonać równolegle, co pozwala na inteligentne planowanie i unikanie konfliktów, a tym samym stanowi podstawę równoległego planowania.
Ponieważ każda transakcja zadeklarowała przed jej wykonaniem, które konta i jakie uprawnienia są potrzebne, Solana może sprawdzić, czy istnieją zależności między transakcjami (model Sealevel). Jeśli transakcje nie mają wspólnych kont do odczytu i zapisu, system może przydzielić je do różnych procesorów do równoległego wykonania.
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 podczas wykonywania transakcji musi często aktualizować globalne drzewo stanu (MPT). Wszystkie stany kont i kontraktów są przechowywane w wspólnym drzewie stanu, a każda transakcja musi uzyskać dostęp i zaktualizować część tego drzewa stanu. Aptos natomiast dzieli konta na niezależne jednostki stanu, gdzie każdy obiekt jest niezależną parą klucz-wartość; obiekty mogą istnieć niezależnie od siebie, nie wpływając na siebie, a powiązanie występuje tylko wtedy, gdy zachodzi wyraźna relacja odniesienia. Obiekty nie mają wspólnej ścieżki drzewa, co eliminuje konkurencję o blokady i pozwala na pełną równoległość.
Podstawowa struktura danych Aptos to Drzewo Merkle Jellyfish. Stan każdego obiektu jest ostatecznie przechowywany w JMT, jako niezależna para klucz-wartość. W przeciwieństwie do MPT Ethereum, Drzewo Merkle Jellyfish ma formę pełnej struktury drzewa binarnego, co upraszcza ścieżki przechowywania i zapytania węzłów, znacznie skracając czas weryfikacji. Dodatkowo, położenie każdego konta w drzewie jest stałe, a węzły w drzewie są przechowywane niezależnie, co pozwala na równoległe aktualizacje i przeszukiwania wielu kont.
Aptos to optymistyczna równoległość, która nie wymaga wcześniejszego podawania wszystkich zależności zadeklarowanych 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łość EVM
W porównaniu do równoległości, EVM napotyka większe trudności techniczne w zarządzaniu zależnościami stanu, wykrywaniu konfliktów, zarządzaniu gazem i mechanizmach wycofywania. Aby lepiej to zrozumieć, możemy odwołać się do niektórych projektów EVM równoległych (takich jak Sui, Monad, Canto), które pokazują, jak rozwiązują te problemy.
Sui
Sui, podobnie jak Aptos, również korzysta z modelu obiektowego do zarządzania stanem, przyjmując każdy obiekt (np. konto, stan inteligentnego kontraktu) jako niezależny zasób. Te obiekty są rozróżniane przez unikalne identyfikatory obiektów. Kiedy transakcje dotyczą różnych obiektów, mogą być przetwarzane równolegle, ponieważ operują na różnych stanach, nie powodując bezpośrednich konfliktów.
Chociaż Sui korzysta z modelu obiektowego do zarządzania stanem, aby być zgodnym z EVM, architektura Sui poprzez dodatkową warstwę adaptacyjną lub mechanizm abstrakcji łączy model obiektowy z modelem kont EVM.
W Sui harmonogram transakcji wykorzystuje strategię optymistycznej równoległości, zakładając, że nie ma konfliktów między transakcjami. Jeśli wystąpi konflikt, system użyje mechanizmu wycofywania, aby przywrócić stan.
Sui używa modelu obiektowego i technologii izolacji stanu, aby skutecznie unikać problemów z zależnościami stanu. Każdy obiekt jest niezależnym zasobem, co pozwala na równoległe wykonanie różnych transakcji, zwiększając tym samym przepustowość i wydajność. Jednak ta metoda wiąże się z pewnymi kompromisami, takimi jak złożoność modelu obiektowego i koszty mechanizmu wycofywania. Jeśli wystąpią konflikty między transakcjami, konieczne może być wycofanie części stanu, co zwiększa obciążenie systemu i może wpływać na efektywność przetwarzania równoległego. W porównaniu do systemów równoległych, które nie są EVM (takich jak Solana), Sui wymaga więcej zasobów obliczeniowych i pamięci do utrzymania wysokiej efektywności równoległej.
Monad
Podobnie jak Sui, Monad również korzysta z optymistycznej równoległości. Ale optymistyczna równoległość Monad przewiduje w rzeczywistości niektóre transakcje z zależnościami przed ich wykonaniem, a prognozy te są głównie realizowane za pomocą statycznego analizatora kodu Monad. Prognozowanie 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, z każdą partycją zarządzającą swoim własnym poddrzewem stanu. Podczas aktualizacji wystarczy zmodyfikować odpowiednie fragmenty, nie trzeba odbudowywać całego drzewa stanu. Szybkie lokalizowanie stanu w partycji odbywa się za pomocą tabeli indeksów stanu, co zmniejsza interakcje między partycjami.
Wymagania sprzętowe węzłów TPS w łańcuchu bloków Wirtualna maszyna Cechy Solana 65 000+ 12 rdzeni CPU, 256 GB RAM, węzeł walidatora 500 GB SSD, węzeł archiwalny 1 TB SSD, a najlepiej dodatkowe 500 GB dla systemu operacyjnego Solana VM Wsparcie dla wysokiej współbieżności, wykorzystuje Proof of History (PoH), bardzo wysoka przepustowość, stosunkowo lekki mechanizm konsensusu Aptos 160 000+ 32 rdzenie CPU, 64 GB+ RAM, 3,0 TB SSD Move VM oparty na języku Move, wspiera równoległe wykonanie, optymalizuje wysoką przepustowość i niską latencję Sui 120 000+ 8 rdzeni CPU, 128 GB RAM, 4 TB NVMe SSD Move VM równoległe wykonanie, model oparty na zasobach, wspiera niską latencję i wysoką przepustowość Monad 10 000+ 16 rdzeni CPU, 32 GB RAM, 2 TB NVMe SSD EVM (warstwa kompatybilności) Wysoka wydajność równoległa, optymalizuje przepustowość poprzez asynchroniczne wykonanie i bardziej lekką konstrukcję wirtualnej maszyny EVM Ethereum (po Merge) 30-100+ 4 rdzenie CPU, 32 GB RAM, 4 TB SSD EVM tradycyjna platforma inteligentnych kontraktów, po Merge przechodzi na Proof of Stake, nadal wspiera ograniczoną równoległość
Podsumowanie
Równoległość koncentruje się na zwiększeniu wydajności wykonania na warstwie wykonawczej poprzez realizację wielościeżkową, a aby zrealizować wielościeżkowe wykonanie, łańcuch musi przejść przez szereg procesó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, a także wprowadzić pewne ulepszenia bazy danych.
Oczywiście, poprawa efektywności warstwy wykonawczej nie ogranicza się tylko do równoległości; optymalizacja etapu wykonania może również być osiągnięta poprzez zmniejszenie liczby operacji odczytu i zapisu, które transakcja wymaga od bazy danych. Natomiast podniesienie całkowitej szybkości łańcucha obejmuje znacznie szerszy zakres, w tym również poprawę efektywności warstwy konsensusu.
Za każdą technologią stoją specyficzne ograniczenia. Równoległość to tylko jeden ze sposobów na zwiększenie efektywności; ostateczna decyzja o zastosowaniu danej technologii musi również uwzględniać jej przyjazność dla deweloperów, czy można ją zrealizować bez poświęcania decentralizacji itp. Stos technologii nie zawsze jest lepszy im jest ich więcej; przynajmniej w przypadku Ethereum, równoległość nie jest tak atrakcyjna, jeśli rozpatrujemy to wyłącznie z perspektywy zwiększenia efektywności. Włączenie równoległości do Ethereum nie jest optymalnym rozwiązaniem, zarówno z punktu widzenia prostoty, jak i obecnej mapy drogowej Ethereum, która koncentruje się na Rollupach.
