Artykuł powstał na podstawie: Techub News
Autor: Tia, Techub News
Blockchain, z powodu swojej zdecentralizowanej konstrukcji, poświęca wydajność, dlatego poprawa prędkości wykonania jest 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 na warstwie wykonawczej stała się jedną z kluczowych strategii, a równoległe wykonanie stanowi ważny przełom w tym zakresie.
Tradycyjne blockchainy zazwyczaj przetwarzają transakcje w sposób sekwencyjny, co znacząco ogranicza prędkość transakcji, zwłaszcza w sieciach o dużym natężeniu transakcji, co prowadzi do zatorów. Jednak dzięki równoległemu wykonaniu, wiele transakcji może być przetwarzanych jednocześnie, co znacząco zwiększa efektywność wykonania i zmniejsza obciążenie na łańcuchu.
Aby lepiej zrozumieć, czym jest równoległość, zaczniemy od wprowadzenia do wykonania, używając Ethereum w modelu PBS po scaleniu jako przykładu, aby wyjaśnić, co to jest wykonanie i jednocześnie pokazać, gdzie wykonanie znajduje się w całym cyklu życia transakcji.
Konkretne etapy wykonywania transakcji
Transakcja wchodzi do puli pamięci i jest filtrowana oraz sortowana: jest to etap wstępny po złożeniu transakcji, obejmujący interakcję Mempool, Searcher i Builder, w celu zakończenia filtrowania i sortowania 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 i treść transakcji, a następnie formalnie przesyła blok do sieci, aby rozpocząć wykonanie.
Wykonywanie transakcji: po przesłaniu bloku, węzły wykonują transakcje w bloku jedna po drugiej. Jest to kluczowy etap aktualizacji stanu, każda transakcja wywołuje wywołanie inteligentnego kontraktu, zmianę salda konta lub zmianę stanu.
Świadkowie świadczą: walidatorzy świadczą wyniki wykonania bloku oraz korzeń stanu, traktując je jako ostateczne potwierdzenie. Zapewnia to autentyczność i ważność bloku na poziomie wykonania oraz zapobiega niespójnościom.
Synchronizacja stanu: każdy węzeł synchronizuje wyniki wykonania bloku (np. salda kont, aktualizacje stanu kontraktów itp.) do własnego lokalnego stanu, 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 poziomie bloków. Aby zachować najnowszy stan na łańcuchu, węzły zazwyczaj synchronizują dane jeden blok po drugim i nieustannie weryfikują bloki i stan. Ale aby osiągnąć ostateczność w mechanizmie POS, agregator musi połączyć podpisy świadków z każdego Slotu w kompletny podpis i przekazać go do następnego Proposera Slotu, a walidatorzy muszą po przejściu jednego Epoch potwierdzić stan wszystkich bloków w tym Epoch na podstawie liczby głosów, tworząc tymczasowy punkt kontrolny stanu konsensusu. Po uzyskaniu poparcia większości walidatorów przez dwa kolejne Epochy, blok i transakcje osiągną ostateczność.
Z perspektywy całego cyklu życia transakcji, wykonanie następuje po tym, jak Proposer weryfikuje strukturę bloku i treść transakcji wysłaną przez Buildera. Rzeczywisty proces wykonania wymaga przetwarzania transakcji jedna po drugiej i aktualizacji odpowiednich stanów konta lub kontraktu. 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 i ostatecznego globalnego stanu. Mówiąc prosto, pełny proces wykonania bloku obejmuje szereg obliczeń potrzebnych do przekształcenia Ethereum z poprzedniego stanu w następny stan, od wykonania każdej transakcji po obliczenie korzenia Merkle.
Wykonanie sekwencyjne
W przeciwieństwie do równoległości, wykonanie sekwencyjne jest obecnie bardziej powszechnym sposobem wykonywania 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 skrót stanu konta. Po zakończeniu aktualizacji wszystkich drzew stanu konta, powstaje skrót korzenia drzewa stanu znany jako Merkle Root stanu. Po zakończeniu Merkle Root stanu, Merkle Root transakcji i Merkle Root pokwitowań, nagłówek bloku przechodzi obliczenia skrótu, generując skrót bloku dla tego bloku.
W tym kontekście kolejność wykonania transakcji jest kluczowa. Ponieważ drzewo Merkle jest drzewem binarnym hashu, różne kolejności tworzą różne wartości korzeni Merkle.
Wykonanie równoległe
W środowisku równoległego wykonania węzły próbują równolegle przetwarzać transakcje w bloku. Nie wykonują transakcji w kolejności jedna po drugiej, ale przypisują transakcje do różnych „ścieżek wykonania”, aby mogły być wykonywane jednocześnie. Dzięki równoległemu wykonaniu system może efektywniej przetwarzać transakcje w bloku, zwiększając przepustowość.
Po zakończeniu wszystkich transakcji, węzeł zbiera wyniki wykonania (tj. aktualizacje stanu spowodowane przez transakcje) i tworzy nowy stan bloku. Stan ten zostaje dodany do blockchaina, reprezentując najnowszy globalny stan na łańcuchu.
Konflikt stanu
Ponieważ równoległość przetwarza transakcje na różnych ścieżkach jednocześnie, jednym z największych wyzwań równoległości są konflikty stanu. Oznacza to, że mogą istnieć wiele transakcji, które w tym samym czasie próbują odczytać lub zapisać dane (stan) na tym samym obszarze blockchain. Jeśli sytuacja ta nie zostanie prawidłowo obsłużona, wyniki wykonania mogą być niepewne. Ponieważ kolejność aktualizacji stanu jest różna, ostateczny wynik obliczeń również będzie różny. Na przykład,
Załóżmy, że są dwie transakcje, transakcja A i transakcja B, które próbują zaktualizować saldo tego samego 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 wykonujemy sekwencyjnie, wynik kolejności wykonania jest określony:
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, osiągając ostatecznie 130.
2. Najpierw wykonaj transakcję B, a następnie transakcję A:
Saldo konta najpierw wzrasta o 20, stając się 120.
Następnie wzrasta o 10, osiągając ostatecznie 130.
W obu tych sekwencjach 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:
Transakcja A odczytuje saldo wynoszące 100, po obliczeniach aktualizuje saldo do 110.
Transakcja B również odczytuje saldo wynoszące 100, po obliczeniach aktualizuje saldo do 120.
W tej sytuacji, ponieważ transakcje są wykonywane jednocześnie, końcowe saldo jest aktualizowane tylko do 120 zamiast 130, ponieważ operacje transakcji A i transakcji B „przykrywają” wyniki nawzajem, co prowadzi do konfliktu stanu.
Problemy z konfliktami stanu są często nazywane „przykrywaniem danych”, co oznacza, że gdy transakcje próbują jednocześnie modyfikować te same dane, mogą wzajemnie przykrywać wyniki obliczeń, co prowadzi do nieprawidłowego stanu końcowego. Inny problem, który może wyniknąć z konfliktów stanu, to niemożność zapewnienia kolejności wykonania. Ponieważ wiele transakcji kończy operacje w różnych ramach czasowych, mogą wystąpić różnice w kolejności wykonania. Różna kolejność może prowadzić do różnych wyników obliczeń, co czyni wyniki niepewnymi.
Aby uniknąć tej niepewności, systemy równoległego wykonania w blockchainie zazwyczaj wprowadzają mechanizmy wykrywania konfliktów i wycofywania, lub wcześniej przeprowadzają analizę zależności transakcji, aby zapewnić, że mogą być wykonywane równolegle bez wpływu na ostateczną spójność stanu.
Optymistyczna równoległość kontra deterministyczna równoległość
Istnieją dwa podejścia do rozwiązywania potencjalnych problemów z konfliktami stanu: deterministyczna równoległość i optymistyczna równoległość. Te dwa modele mają różne kompromisy w zakresie wydajności i złożoności projektowania.
Deterministyczna równoległość wymaga wcześniejszego zadeklarowania dostępu do stanu, walidatorzy lub sequencery sprawdzają zadeklarowany dostęp do stanu podczas sortowania transakcji. Jeśli wiele transakcji próbuje zapisać ten sam stan, zostaną one oznaczone jako konflikty, aby uniknąć równoległego wykonania. Różne łańcuchy różnią się w tym, jak konkretne implementacje wymagają wcześniejszego zadeklarowania dostępu do stanu, ale zazwyczaj obejmują następujące metody:
Poprzez normy umowy: programiści w inteligentnych kontraktach bezpośrednio określają zakres dostępu do stanu. Na przykład, transfer tokenów ERC-20 wymaga dostępu do pól salda nadawcy i odbiorcy.
Poprzez deklarację zdystrybuowanych danych w transakcji: dodanie specjalnych pól w 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 przez ramy: niektóre ramy wymagają od programistów wyraźnego określenia, jakie stany będą odwiedzane podczas wywoływania funkcji.
Optymistyczna równoległość zakłada, że transakcje będą najpierw przetwarzane, a w przypadku wystąpienia konfliktów, dotknięte transakcje będą ponownie wykonywane w kolejności. Aby jak najbardziej uniknąć sytuacji konfliktowych, kluczowym elementem projektowania optymistycznej równoległości jest szybka ocena i założenia dotyczące stanu na podstawie danych historycznych, analizy statycznej itp. Oznacza to, że system przyjmuje, że niektóre operacje lub aktualizacje stanu są ważne bez pełnej weryfikacji, aby uniknąć czekania na wszystkie procesy weryfikacji, co zwiększa wydajność i przepustowość.
Chociaż optymistyczna równoległość może starać się unikać konfliktów poprzez szybkie przewidywania i założenia dotyczące stanu, nadal istnieją pewne 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 znacząco spowolnić wydajność systemu i zwiększyć zużycie zasobów obliczeniowych.
Deterministyczna równoległość unika konfliktów, które mogą wystąpić w optymistycznej równoległości, przeprowadzając kontrolę zależności stanu przed transakcjami, ale wymaga to dokładnego zadeklarowania zależności stanu przed złożeniem transakcji, co stawia wyższe wymagania dla programistów, zwiększając złożoność implementacji.
Dylemat równoległości EVM
Podejście do konfliktów stanu nie ogranicza się tylko do deterministycznych i optymistycznych podejść. W realizacji równoległości należy również rozważyć architekturę bazy danych blockchain. Problemy z konfliktami stanu w równoległym EVM oparte na architekturze Merkle Tree są szczególnie trudne. Drzewo Merkle to struktura haszująca w hierarchii, która wymaga aktualizacji korzenia haszowego po każdej transakcji, która modyfikuje dane stanu. Proces aktualizacji jest rekurencyjny, obliczając od liści do korzenia. Z powodu nieodwracalności haszowania, obliczenia na wyższych poziomach mogą być przeprowadzane tylko po zakończeniu modyfikacji danych na niższych poziomach, co sprawia, że równoległa aktualizacja jest trudna.
Jeśli dwie transakcje są wykonywane 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. Rozwiązanie takich konfliktów zazwyczaj wymaga dodatkowego mechanizmu zarządzania transakcjami, aby zapewnić, że w wielu gałęziach uzyskuje się spójny korzeń haszowy. Dla EVM nie jest to łatwe do osiągnięcia, ponieważ wymaga 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 stosuje model konta. Każde konto to niezależna przestrzeń pamięci, przechowywana w księdze, co pozwala uniknąć problemów z konfliktami ścieżek.
Solana jest deterministycznym równoległym systemem. W Solanie każda transakcja musi podczas składania wyraźnie zadeklarować, które konta będą odwiedzane i jakie uprawnienia są potrzebne (tylko do odczytu lub do odczytu i zapisu). Taki projekt pozwala węzłom blockchain na wcześniejsze analizowanie zasobów, do których każda transakcja będzie miała dostęp przed jej wykonaniem. Ponieważ transakcje jasno przedstawiają 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 mogą być bezpiecznie wykonywane równolegle, co umożliwia inteligentne planowanie, unikanie konfliktów i stanowi podstawę planowania równoległego.
Ponieważ każda transakcja deklaruje przed wykonaniem, które konta i uprawnienia będą 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 przypisać je do różnych procesorów do równoległego wykonania.
Aptos
Projekt równoległego wykonania Aptos różni się znacząco od Ethereum, wprowadzając kluczowe innowacje w architekturze i mechanizmach, głównie w modelu konta i przechowywaniu stanu.
Ethereum podczas wykonywania transakcji musi często aktualizować globalne drzewo stanu (MPT). Wszystkie stany kont i kontraktów są przechowywane w jednym wspólnym drzewie stanu, każda transakcja musi uzyskać dostęp do i zaktualizować część tego drzewa stanu. Aptos zaś dzieli konta na niezależne jednostki stanu, w których każdy obiekt jest niezależną parą klucz-wartość, a obiekty mogą istnieć niezależnie od siebie i nie wpływają na siebie nawzajem, łączą się tylko gdy istnieje wyraźna relacja referencyjna. Obiekty nie mają wspólnej ścieżki w drzewie, nie występują konflikty blokad, co pozwala na całkowitą 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 formę całkowitego drzewa binarnego, co upraszcza ścieżki przechowywania i zapytań węzła, znacznie skracając czas weryfikacji. Ponadto miejsce 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 wyszukiwania wielu kont.
Aptos jest optymistycznym równoległym systemem, który nie wymaga wcześniejszego podawania wszystkich zależności deklarowanych kont. W tym celu Aptos używa Block-STM, który wykorzystuje ustalony porządek transakcji do oszacowania zależności, co zmniejsza liczbę przerywań.
Równoległy EVM
W porównaniu z równoległością, która nie jest EVM, równoległy EVM stawia większe wyzwania techniczne w zakresie zarządzania zależnościami stanu, wykrywania konfliktów, zarządzania gazem i mechanizmów wycofywania. Aby lepiej zrozumieć tę kwestię, możemy przyjrzeć się, jak niektóre projekty równoległego EVM (takie jak Sui, Monad, Canto) radzą sobie z tymi problemami.
Sui
Sui, podobnie jak Aptos, korzysta z modelu obiektowego do zarządzania stanem, traktują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ć przetwarzane równolegle, ponieważ operują na różnych stanach, nie generując bezpośrednich konfliktów.
Chociaż Sui korzysta z modelu obiektowego do zarządzania stanem, aby być zgodnym z EVM, architektura Sui łączy model obiektowy z modelem kont EVM poprzez dodatkowe warstwy adaptacyjne lub mechanizmy abstrakcyjne.
W Sui harmonogram transakcji wykorzystuje strategię optymistycznej równoległości, zakładając, że transakcje nie mają konfliktów. Jeśli wystąpi konflikt, system wykorzysta mechanizm wycofywania, aby przywrócić stan.
Sui zastosowało model obiektowy i technologię izolacji stanu, co pozwala skutecznie unikać problemów z zależnościami stanu. Każdy obiekt jako niezależny zasób, różne transakcje mogą być wykonywane równolegle, co zwiększa przepustowość i efektywność. Jednak takim podejściem jest złożoność modelu obiektowego i koszty mechanizmu wycofywania. W przypadku konfliktu między transakcjami może być konieczne wycofanie niektórych stanów, co zwiększa obciążenie systemu i może wpływać na efektywność przetwarzania równoległego. W porównaniu z systemami równoległymi, które nie są EVM (takimi 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 przed wykonaniem transakcji będzie przewidywać niektóre transakcje, które mają zależności, a przewidywanie to jest realizowane głównie przez statyczny analizator kodu Monad. Przewidywanie wymaga dostępu do stanu, podczas gdy sposób przechowywania stanu w bazie danych Ethereum utrudnia dostęp do stanu. Aby zwiększyć efektywność równoległego 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 zmienić odpowiednie fragmenty bez potrzeby odbudowywania całego drzewa stanu. Dzięki tabeli indeksów stanu można szybko lokalizować stany w partycji, zmniejszając interakcje między partycjami.
Podsumowanie
Kern równoległości polega na zwiększeniu efektywności wykonania warstwy wykonawczej za pomocą wielościeżkowego wykonania, a aby to osiągnąć, łańcuch musi przeprowadzić szereg działań, takich jak wykrywanie konfliktów i mechanizmy wycofywania, aby zapewnić, że mogą one być wykonywane równolegle bez wpływu na ostateczną spójność stanu, a także przeprowadzić pewne ulepszenia w bazie danych.
Oczywiście, poprawa efektywności warstwy wykonawczej nie ogranicza się tylko do równoległości, optymalizacje w procesie wykonawczym mogą być również realizowane poprzez zmniejszenie operacji odczytu i zapisu bazy danych wymaganych przez jedną transakcję. Całkowite przyspieszenie prędkości łańcucha obejmuje szerszy zakres, w tym również poprawę efektywności warstwy konsensusu.
Każda technologia ma swoje specyficzne ograniczenia. Równoległość jest tylko jednym ze sposobów na zwiększenie efektywności, ostateczna decyzja o użyciu tej technologii musi również uwzględniać, czy jest przyjazna dla programistów, czy można ją zrealizować bez poświęcania decentralizacji itp. Nakładanie technologii nie zawsze jest lepsze, przynajmniej w przypadku Ethereum, równoległość nie jest tak atrakcyjna, jeśli spojrzeć tylko na poprawę efektywności, dodanie równoległości dla Ethereum nie jest optymalnym rozwiązaniem, zarówno z punktu widzenia prostoty, jak i obecnej mapy drogowej Ethereum skoncentrowanej na Rollup.
