Autor: Tia, Techub News
Blockchain poświęca efektywność na rzecz zdecentralizowanego projektu, dlatego przyspieszenie prędkości wykonania od dawna było jednym z pilnych problemów do rozwiązania. „Warstwa wykonawcza” blockchaina jest kluczową częścią przetwarzania każdej transakcji i dodawania jej do łańcucha. Aby zwiększyć zdolności przetwarzania, poprawa warstwy wykonawczej stała się jednym z kluczowych strategii, a równoległe wykonanie jest istotnym przełomem w tej kwestii.
Tradycyjne blockchainy zazwyczaj przetwarzają transakcje w sposób sekwencyjny, co znacznie ogranicza prędkość transakcji, szczególnie w sieciach o dużym natężeniu transakcji, co prowadzi do przeciążenia. Jednak dzięki równoległemu wykonaniu wiele transakcji może być przetwarzanych jednocześnie, co znacznie zwiększa efektywność wykonania i zmniejsza presję na łańcuchu.
Aby lepiej zrozumieć, czym jest równoległość, zaczniemy od wprowadzenia wykonania, używając Ethereum w modelu PBS po Merge jako przykładu, aby wyjaśnić, czym jest wykonanie i pokazać, jakie miejsce zajmuje ono w całym cyklu życia transakcji.
Szczegółowe etapy wykonywania transakcji
Transakcja trafia do puli pamięci i jest filtrowana oraz sortowana: jest to etap wstępnego przetwarzania po przesłaniu transakcji, obejmujący interakcję pomiędzy Mempool, Searcher i Builder, kończąc na filtrowaniu i sortowaniu transakcji.
Builder buduje blok (ale go nie wykonuje): Builder układa opłacalne transakcje w blok, aby zakończyć pakowanie i sortowanie transakcji.
Proposer weryfikuje i przesyła blok: Po zakończeniu budowy bloku, Builder wysyła propozycję bloku do Proposera. Proposer weryfikuje strukturę bloku oraz zawartość transakcji, a następnie formalnie 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 kluczowy etap aktualizacji stanu, każda transakcja wywołuje wywołania kontraktów inteligentnych, zmiany salda konta lub zmiany stanu.
Świadkowie poświadczają: Walidatorzy poświadczają wyniki wykonania bloku oraz korzeń stanu, traktując je jako ostateczne potwierdzenie. To zapewnia autentyczność i ważność bloku na warstwie wykonawczej, zapobiegając niespójnościom.
Synchronizacja stanu: Każdy węzeł synchronizuje wyniki wykonania bloku (takie jak saldo konta, aktualizacje stanu kontraktów itp.) ze swoim lokalnym stanem, po wykonaniu każdej transakcji węzeł oblicza i przechowuje nowy korzeń stanu, który będzie używany jako stan początkowy w następnym bloku.
Oczywiście, to tylko synchronizacja stanu transakcji na poziomie bloków. Aby utrzymać najnowszy stan na łańcuchu, węzły zazwyczaj synchronizują dane blok po bloku i nieustannie weryfikują bloki i stany. Jednak aby osiągnąć ostateczność w mechanizmie POS, agregator musi złożyć podpisy świadków z każdego slotu w jeden kompletny podpis i przekazać je do proponującego następnego slotu, a walidatorzy muszą po przejściu jednego epoki potwierdzić stan wszystkich bloków w tym epoku na podstawie liczby głosów, tworząc tymczasowy punkt kontrolny stanu konsensusu. Gdy dwa kolejne epoki uzyskają poparcie większości walidatorów, blok i transakcje osiągną ostateczność.
Z perspektywy całego cyklu życia transakcji, wykonanie ma miejsce po tym, jak Proposer zweryfikuje strukturę bloku i zawartość transakcji przesłaną przez Buildera. Proces wykonania wymaga przetwarzania transakcji jedna po drugiej oraz aktualizacji odpowiednich stanów kont lub kontraktów. Po zakończeniu wszystkich transakcji Proposer oblicza nowy korzeń stanu (korzeń Merkle), który podsumowuje wyniki wykonania wszystkich transakcji w bieżącym bloku oraz ostateczny globalny stan. Mówiąc prościej, pełny proces wykonania bloku obejmuje szereg obliczeń, które należy wykonać, aby przekształcić Ethereum z poprzedniego stanu w następny, od wykonania każdej transakcji po obliczenie korzenia Merkle.
Wykonanie sekwencyjne
W przeciwieństwie do równoległego wykonania, mamy do czynienia z wykonaniem sekwencyjnym, co jest obecnie bardziej powszechnym sposobem wykonywania w blockchainach. Zazwyczaj transakcje są wykonywane w kolejności. Po zakończeniu wykonania transakcji, Ethereum aktualizuje stan konta i powiązane informacje (takie jak saldo, dane przechowywania kontraktu) w drzewie stanu konta, generując nowy hasz stanu konta. Po zakończeniu aktualizacji stanu Merkle, hasz korzenia drzewa stanu znany jako korzeń Merkle stanu jest generowany. Po zakończeniu korzenia Merkle stanu, korzenia Merkle transakcji i korzenia Merkle dowodów, nagłówek bloku przechodzi przez obliczenia haszujące, generując hasz bloku.
W tym kontekście kolejność wykonania transakcji ma kluczowe znaczenie. Ponieważ drzewo Merkle jest binarnym drzewem wartości hasza, różne kolejności prowadzą do różnych wartości korzeni Merkle.
Równoległe wykonanie
W środowisku równoległego wykonania węzeł będzie starał się równolegle przetwarzać transakcje w bloku. Nie jest to wykonywanie transakcji jedna po drugiej, ale przypisywanie transakcji do różnych „ścieżek wykonawczych”, aby mogły być wykonywane jednocześnie. Dzięki równoległemu wykonaniu system może bardziej efektywnie przetwarzać transakcje w bloku, zwiększając przepustowość.
Po zakończeniu wykonywania wszystkich transakcji, węzeł zbiera wyniki wykonania (tj. aktualizacje stanu wpływające na transakcje) i tworzy nowy stan bloku. Ten stan zostanie dodany do blockchaina, reprezentując najnowszy globalny stan 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. Możliwe jest, że wiele transakcji wykonuje operacje odczytu lub zapisu na tym samym fragmencie danych (stanie) w tym samym czasie. Jeśli sytuacja nie zostanie właściwie obsłużona, wyniki wykonania mogą być niepewne. Ponieważ kolejność aktualizacji stanu jest różna, 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ą zaktualizować saldo konta:
Transakcja A: zwiększa saldo konta o 10.
Transakcja B: zwiększa saldo konta o 20.
Początkowe saldo konta wynosi 100.
Jeśli wykonamy sekwencyjnie, rezultaty będą określone:
1. Najpierw wykonaj transakcję A, a następnie transakcję B:
Saldo konta najpierw wzrasta o 10, stając się 110.
Następnie wzrasta o 20, ostatecznie osiągając 130.
2. Wykonaj transakcję B, a następnie transakcję A:
Saldo konta najpierw wzrasta o 20, stając się 120.
Następnie wzrasta o 10, ostatecznie osiągając 130.
W obu tych kolejnościach ostateczne saldo wynosi 130, ponieważ system zapewnia spójność kolejności wykonania transakcji.
Jednak w środowisku równoległego wykonania, transakcja A i transakcja B mogą jednocześnie odczytać początkowe saldo 100 i przeprowadzić swoje 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 są wykonywane równolegle, ostateczne saldo aktualizuje się tylko do 120, a nie do 130, ponieważ operacje transakcji A i B „przykrywają” wyniki nawzajem, co prowadzi do konfliktu stanu.
Problemy z konfliktami stanu tego typu nazywane są często „nadpisywaniem danych”, gdy transakcje próbują jednocześnie modyfikować te same dane, mogą wzajemnie przesłonić wyniki obliczeń, co prowadzi do nieprawidłowego stanu końcowego. Innym problemem, który może wyniknąć z konfliktów stanu, jest niemożność zapewnienia kolejności wykonania. Ponieważ wiele transakcji kończy operacje w różnym czasie, może prowadzić to do różnych kolejności wykonania. Różne kolejności mogą prowadzić do różnych wyników obliczeń, co skutkuje niepewnością wyników.
Aby uniknąć tej niepewności, systemy równoległego wykonania blockchain zazwyczaj wprowadzają mechanizmy wykrywania konfliktów i odwracania, a także wcześniej analizują zależności transakcji, aby zapewnić, że mogą być one wykonywane równolegle bez wpływu na ostateczną spójność stanu.
Optymistyczna równoległość i deterministyczna równoległość
Są dwa sposoby podejścia do potencjalnych problemów z konfliktami stanu: deterministyczna równoległość i optymistyczna równoległość. Oba te modele mają swoje kompromisy w efektywności i złożoności projektowania.
Deterministyczna równoległość wymaga wcześniejszego zadeklarowania dostępu do stanu, walidator lub sequencer sprawdza zadeklarowany dostęp do stanu podczas sortowania transakcji. Jeśli wiele transakcji próbuje zapisać do tego samego stanu, zostaną one oznaczone jako konfliktowe, aby uniknąć jednoczesnego wykonania. Różne łańcuchy mają różne sposoby wczesnego zadeklarowania dostępu do stanu, ale zazwyczaj obejmują one następujące metody:
Poprzez normy umowy: programiści bezpośrednio określają zakres dostępu do stanu w inteligentnej umowie. Na przykład, transfer tokena ERC-20 wymaga dostępu do pól salda nadawcy i odbiorcy.
Poprzez strukturyzowane dane transakcji: dodawanie specjalnych pól do transakcji w celu oznaczenia dostępu do stanu.
Poprzez analizę kompilatora: kompilatory języków wysokiego poziomu mogą statycznie analizować kod umowy, automatycznie generując zbiór dostępu do stanu.
Wymuszona deklaracja przez ramy: niektóre ramy wymagają od programistów wyraźnego określenia stanu, do którego mają dostęp podczas wywoływania funkcji
Optymistyczna równoległość najpierw optymistycznie przetwarza transakcje, a gdy wystąpi konflikt, ponownie wykonuje dotknięte transakcje w kolejności. Aby uniknąć konfliktów, kluczową ideą optymistycznej równoległości jest szybkie przewidywanie i zakładanie stanu na podstawie danych historycznych, analizy statycznej itp. To znaczy, że system, nie przeprowadzając pełnej weryfikacji, zakłada, że niektóre operacje lub aktualizacje stanu są ważne, starając się unikać oczekiwania na zakończenie wszystkich procesów weryfikacji, aby zwiększyć wydajność i przepustowość.
Chociaż optymistyczna równoległość może unikać konfliktów poprzez szybkie przewidywanie i założenia dotyczące stanu, nadal istnieją pewne nieuniknione wyzwania, zwłaszcza 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 oraz zwiększyć zużycie zasobów obliczeniowych.
Deterministyczna równoległość unika potencjalnych konfliktów, przeprowadzając kontrolę zależności stanu przed transakcjami, ale ponieważ wymaga dokładnego zadeklarowania zależności stanu przed przesłaniem transakcji, stawia to wyższe wymagania wobec deweloperów, co zwiększa złożoność realizacji.
Dylematy równoległe EVM
Konflikty stanu należy traktować nie tylko z perspektywy deterministycznej i optymistycznej, ale także z perspektywy architektury bazy danych łańcucha w kontekście konkretnej implementacji równoległej. Problemy z konfliktami stanu w równoległości są szczególnie trudne w EVM opartym na drzewie Merkle. Drzewo Merkle to struktura haszowana w hierarchii, której wartość hasza korzeniowego musi być aktualizowana po każdej transakcji, która modyfikuje dane stanu. Proces ten jest rekurencyjny, obliczając od liści w górę, aż do korzenia. Ponieważ haszowanie jest nieodwracalne, wartość hasza na wyższym poziomie może być obliczona dopiero po zakończeniu zmian w niższych poziomach, co czyni równoległe aktualizacje trudnymi.
Jeśli dwie transakcje są wykonywane równolegle i uzyskują dostęp do tego samego stanu (np. salda konta), spowoduje to konflikt węzłów drzewa Merkle. Rozwiązanie tego konfliktu często wymaga dodatkowych mechanizmów zarządzania transakcjami, aby zapewnić spójną wartość hasza korzeniowego w różnych gałęziach. Nie jest to łatwe do osiągnięcia w EVM, ponieważ wymaga kompromisu pomiędzy równoległością a spójnością stanu.
Równoległe rozwiązania nie-EVM
Solana
W przeciwieństwie do globalnego drzewa stanu Ethereum, Solana przyjmuje model konta. Każde konto to niezależna przestrzeń przechowywania w książce, co pozwala uniknąć problemów z konfliktami ścieżek.
Solana jest deterministyczną równoległością. W Solanie każda transakcja musi podczas przesyłania wyraźnie zadeklarować konta, które będą miały dostęp, oraz wymagane uprawnienia dostępu (tylko do odczytu lub odczytu i zapisu). Ten 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 rozpoczęciem wykonania. Ponieważ transakcje mają jasno określone wszystkie zależności kont przed rozpoczęciem wykonania, węzły mogą ocenić, które transakcje będą miały dostęp do tych samych kont, a które transakcje można bezpiecznie wykonywać równolegle, co umożliwia inteligentne planowanie i unikanie konfliktów, stając się podstawą równoległego harmonogramowania.
Ponieważ każda transakcja już przed wykonaniem zadeklarowała konta i uprawnienia, Solana może sprawdzić, czy istnieją zależności kont między transakcjami (model Sealevel). Jeśli transakcje nie mają współdzielonych kont do odczytu i zapisu, system może przypisać je do różnych procesorów do równoległego wykonania.
Aptos
Projekt równoległego wykonania Aptos znacząco różni się od Ethereum, wprowadzając 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 współdzielonym drzewie stanu, a każda transakcja musi uzyskać dostęp i zaktualizować część tego drzewa stanu. Aptos z kolei dzieli konta na niezależne jednostki stanu, gdzie każdy obiekt jest niezależną parą klucz-wartość, które mogą istnieć niezależnie od siebie, a ich powiązanie następuje tylko przy wyraźnych relacjach odwoławczych. Obiekty nie mają wspólnej ścieżki w drzewie, co eliminuje problemy z rywalizacją o blokady i umożliwia 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 przyjmuje całkowicie binarną strukturę drzewa, co upraszcza ścieżki przechowywania i zapytań węzłów, znacznie skracając czas weryfikacji. Co więcej, 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 wyszukiwanie wielu kont.
Aptos jest równoległością optymistyczną, nie wymaga wcześniejszego dostarczenia wszystkich zadeklarowanych zależności kont. W tym celu Aptos wykorzystuje Block-STM, który szacuje zależności przy użyciu ustalonej kolejności transakcji, aby zmniejszyć liczbę przerwań.
Równoległe EVM
W porównaniu do równoległych systemów nie-EVM, równoległe EVM staje przed znacznie większymi trudnościami technicznymi przy rozwiązywaniu problemów z zależnościami stanu, wykrywaniem konfliktów, zarządzaniem gazem i mechanizmami odwracania. Aby lepiej to zrozumieć, możemy odnieść się do niektórych projektów równoległych EVM (takich jak Sui, Monad, Canto), które rozwiązują te problemy.
Sui
Sui, podobnie jak Aptos, również używa modelu obiektowego do zarządzania stanem, traktując każdy obiekt (np. konto, stan kontraktu inteligentnego) jako niezależny zasób, który jest odróżniany przez unikalny identyfikator obiektu. Gdy transakcje dotyczą różnych obiektów, mogą być one przetwarzane równolegle, ponieważ operują na różnych stanach i nie powodują bezpośrednich konfliktów.
Chociaż Sui używa modelu obiektowego do zarządzania stanem, aby być zgodnym z EVM, architektura Sui mostkuje model obiektowy i model konta EVM poprzez dodatkową warstwę adaptacyjną lub mechanizm abstrakcji.
W Sui harmonogram transakcji stosuje optymistyczną strategię równoległości, zakładając, że między transakcjami nie ma konfliktów. Jeśli wystąpi konflikt, system korzysta z mechanizmu odwracania, aby przywrócić stan.
Sui zastosowało model obiektowy i technologię izolacji stanu, co skutecznie unika problemów z zależnością stanu. Każdy obiekt jest niezależnym zasobem, dzięki czemu różne transakcje mogą być wykonywane równolegle, zwiększając przepustowość i efektywność. Jednak takim podejściem jest złożoność modelu obiektowego i koszty mechanizmu odwracania. W przypadku konfliktów między transakcjami konieczne jest odwrócenie części stanu, co zwiększa obciążenie systemu i może wpływać na efektywność równoległego przetwarzania. W porównaniu do systemów równoległych nie-EVM (takich jak Solana), Sui wymaga 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 przewiduje niektóre transakcje z zależnościami przed ich rzeczywistym wykonaniem, a przewidywanie to głównie odbywa się za pomocą statycznego analizatora kodu Monad. Przewidywanie wymaga dostępu do stanu, a sposób przechowywania stanu w bazie danych Ethereum utrudnia dostęp do stanu, dlatego w celu zwiększenia wydajności odczytu stanu w równoległym wykonaniu, Monad również zreformował bazę danych.
Drzewa stanu Monad są podzielone na partycje, każda partycja utrzymuje swoją własną poddrzewo 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 interakcję między partycjami.
Podsumowanie
Rdzeniem równoległości jest zwiększenie efektywności wykonawczej poprzez wielościeżkowe wykonywanie, a aby to osiągnąć, łańcuch musi przeprowadzić szereg działań, takich jak wykrywanie konfliktów i mechanizmy odwracania, aby zapewnić, że mogą być one wykonywane równolegle bez wpływu na ostateczną spójność stanu oraz wprowadzić pewne poprawki do bazy danych.
Oczywiście, zwiększenie efektywności warstwy wykonawczej nie ogranicza się do jednego sposobu równoległego, optymalizacje w tej fazie można również osiągnąć poprzez zmniejszenie operacji odczytu i zapisu wymaganych przez pojedynczą transakcję w bazie danych. A zwiększenie prędkości całego łańcucha obejmuje szerszy zakres, w tym również zwiększenie efektywności warstwy konsensusu.
Każda technologia ma swoje specyficzne ograniczenia. Równoległość to tylko jeden ze sposobów zwiększania efektywności, a ostateczna decyzja o użyciu tej technologii musi również uwzględniać, czy jest przyjazna dla deweloperów, czy można ją zrealizować bez poświęcania decentralizacji, itd. Nakładanie technologii nie zawsze jest lepsze, przynajmniej w przypadku Ethereum, równoległość nie jest tak pociągająca; jeśli chodzi o zwiększenie efektywności, wprowadzenie równoległości nie jest optymalnym rozwiązaniem dla Ethereum, niezależnie od tego, czy rozważa się prostotę, czy aktualną trasę Ethereum skoncentrowaną na Rollup.
