Web3 Parallel Computing Track Panorama: najlepsze rozwiązanie do natywnego skalowania?

Autor: 0xjacobzhao i ChatGPT 4o

"Trylemat blockchain" dotyczący "bezpieczeństwa", "decentralizacji" i "skalowalności" blockchaina ujawnia zasadniczy kompromis w projektowaniu systemów blockchain, to znaczy, że projektom blockchain trudno jest osiągnąć "ekstremalne bezpieczeństwo, każdy może uczestniczyć i szybkie przetwarzanie" w tym samym czasie. W odpowiedzi na odwieczny temat "skalowalności", główne rozwiązania skalowania blockchain na rynku są podzielone według paradygmatów, w tym:

• Skalowanie ulepszone wykonanie: Poprawia możliwości wykonawcze in situ, takie jak równoległość, GPU i wielordzeniowe
• skalowanie izolowane od stanu: Poziomo podzielony stan/fragment, np. shardy, UTXO i wiele podsieci
• Skalowanie zlecone na zewnątrz poza łańcuchem: Umieszczanie wykonania poza łańcuchem, takiego jak rollupy, Skalowanie oddzielenia struktury koprocesora i
• DA: Architektura modułowa i współpraca operacyjna, taka jak łańcuch modułów, współdzielony sekwencer, Rollup Mesh
• Asynchroniczne skalowanie współbieżne: Model aktora, izolacja procesu, sterowane komunikatami, takie jak agent, wielowątkowy łańcuch asynchroniczny

  Rozwiązanie skalowania blockchain obejmuje: obliczenia równoległe on-chain, rollup, sharding, moduł DA, strukturę modułową, system aktora, kompresję zk proof, architekturę bezstanową itp., obejmując wiele poziomów wykonania, stanu, danych i struktury, i jest kompletnym systemem skalowania "wielowarstwowej współpracy i kombinacji modułów". Ten artykuł koncentruje się na metodach skalowania, które stanowią główny nurt obliczeń równoległych.

  Równoległość wewnątrzłańcuchowa, która koncentruje się na równoległym wykonywaniu transakcji/instrukcji wewnątrz bloku. Zgodnie z mechanizmem równoległym, jego metody skalowania można podzielić na pięć kategorii, z których każda reprezentuje inne dążenie do wydajności, model rozwoju i filozofię architektury, a stopień szczegółowości równoległości staje się coraz drobniejszy, intensywność równoległości jest coraz wyższa, złożoność planowania staje się coraz wyższa, a złożoność programowania i trudność implementacji również stają się coraz wyższe.

  • Poziom konta: reprezentuje projekt
  • Poziom obiektu: reprezentuje projekt Sui
  • Poziom transakcji: reprezentuje projekt Monad, Aptos
  • Call-level / MicroVM : MegaETH na poziomie instrukcji
  :
  • GatlingX

  Asynchroniczny model współbieżności poza łańcuchem, reprezentowany przez Actor / Actor Model, należy do innego paradygmatu obliczeń równoległych, jako cross-chain/asynchroniczny system komunikatów (model synchronizacji nieblokowej), każdy agent działa niezależnie jako "proces agenta", komunikaty asynchroniczne w trybie równoległym, sterowane zdarzeniami, bez planowania synchronicznego, reprezentatywne projekty, takie jak AO, ICP, Cartesi itp.

  Dobrze znany schemat rollupu lub skalowania fragmentów należy do mechanizmu współbieżności na poziomie systemu, a nie do obliczeń równoległych wewnątrz łańcucha. Osiągają skalowanie poprzez "równoległe uruchamianie wielu łańcuchów/domen wykonawczych", a nie zwiększanie równoległości w obrębie pojedynczego bloku/maszyny wirtualnej. Tego typu rozwiązanie skalowania nie jest przedmiotem tego artykułu, ale nadal będziemy go używać do porównywania podobieństw i różnic w koncepcjach architektonicznych.

  

  2. Łańcuch równoległego wzmacniania EVM: przełamywanie granicy wydajności w kompatybilności

  Od czasu opracowania architektury przetwarzania szeregowego Ethereum przeszło wiele rund prób skalowania, takich jak sharding, rollup i architektura modułowa, ale wąskie gardło przepustowości warstwy wykonawczej nadal nie zostało zasadniczo złamane. Ale jednocześnie EVM i Solidity są nadal platformami inteligentnych kontraktów o największej bazie programistów i potencjale ekologicznym. W związku z tym równoległy łańcuch ulepszeń EVM staje się ważnym kierunkiem dla nowej rundy skalowania i ewolucji jako kluczowa ścieżka, która uwzględnia kompatybilność ekologiczną i poprawę wydajności wykonania. Monad i MegaETH są najbardziej reprezentatywnymi projektami w tym kierunku, zaczynając odpowiednio od odroczonego wykonania i dekompozycji stanu, aby zbudować architekturę przetwarzania równoległego EVM dla scenariuszy o wysokiej współbieżności i wysokiej przepustowości.

  Analiza obliczeń równoległych MonadMonad

  to wysokowydajny blockchain warstwy 1 przeprojektowany dla maszyny wirtualnej Ethereum (EVM), oparty na podstawowej koncepcji równoległego potokowania, z wykonaniem asynchronicznym w warstwie konsensusu i optymistyczną współbieżnością w warstwie wykonawczej Wykonywanie równoległe) 。 Ponadto, w warstwie konsensusu i pamięci masowej, Monad wprowadził odpowiednio wysokowydajny protokół BFT (MonadBFT) i dedykowany system baz danych (MonadDB), aby osiągnąć kompleksową optymalizację.

  Potokowanie: Wieloetapowy mechanizm równoległego wykonywania potoków

  Potokowanie jest podstawową koncepcją równoległego wykonywania Monad, a jego podstawową ideą jest podzielenie procesu wykonywania blockchaina na wiele niezależnych etapów i przetwarzanie tych etapów równolegle, aby utworzyć trójwymiarową architekturę potoku, każdy etap przebiega na niezależnych wątkach lub rdzeniach, aby osiągnąć współbieżne przetwarzanie między blokami. Rezultatem jest zwiększona przepustowość i zmniejszone opóźnienia. Etapy te obejmują: Propozycję, Konsensus, Wykonanie i Zatwierdzenie.

  Wykonywanie asynchroniczne: Konsensus - Wykonywanie jest asynchronicznie rozłączoneW

  tradycyjnych łańcuchach konsensus transakcji i realizacja są często procesami synchronicznymi, a ten model szeregowy poważnie ogranicza skalowanie wydajności. Monad implementuje warstwę konsensusu asynchroniczną, warstwę wykonawczą asynchroniczną i asynchroniczną pamięć masową poprzez "asynchroniczne wykonywanie". Znacznie skróć czas bloku i opóźnienia potwierdzeń, dzięki czemu system jest bardziej odporny, przetwarzanie jest bardziej segmentowane, a wykorzystanie zasobów.

  Podstawowy projekt:

  • Proces konsensusu (warstwa konsensusu) jest odpowiedzialny tylko za sortowanie transakcji i nie wykonuje logiki kontraktu.
  • Proces wykonania (warstwa wykonawcza) jest uruchamiany asynchronicznie po zakończeniu konsensusu.
  • Po zakończeniu konsensusu natychmiast przejdzie on do procesu konsensusu następnego bloku, nie czekając na zakończenie wykonania.

  Optymistyczne wykonanie równoległe: Optymistyczne wykonanie równoległeTradycyjne

  Ethereum przyjmuje ściśle szeregowy model wykonywania transakcji, aby uniknąć konfliktów stanów. Z drugiej strony Monad przyjmuje strategię "optymistycznej równoległej realizacji", aby znacznie zwiększyć szybkość przetwarzania transakcji.

  Mechanizm wykonania:

  • Monad optymistycznie wykonuje wszystkie transakcje równolegle, zakładając, że większość transakcji jest bezstanowa i bezkonfliktowa.
  • Uruchom również "Detektor konfliktów", aby monitorować, czy ten sam stan (np. konflikty odczytu/zapisu) jest dostępny między transakcjami.
  • Jeśli zostanie wykryty konflikt, transakcja powodująca konflikt jest serializowana i ponownie wykonywana, aby upewnić się, że stan jest poprawny.

  Monad wybrał kompatybilną ścieżkę: przenieść jak najmniej reguł EVM, osiągnąć równoległość poprzez odroczenie stanu zapisu i dynamiczne wykrywanie konfliktów podczas wykonywania, co jest bardziej jak wydajna wersja Ethereum, z poziomem dojrzałości, który ułatwia migrację do ekosystemu EVM i jest równoległym akceleratorem w świecie EVM.

  Rozdzielczość mechanizmu obliczeń równoległych MegaETH

  różni się od pozycjonowania L1 Monad, a MegaETH jest pozycjonowany jako modułowa, wysokowydajna równoległa warstwa wykonawcza kompatybilna z EVM, która może być używana jako niezależny łańcuch publiczny L1, jako warstwa wzmacniająca wykonywanie lub komponent modułowy na Ethereum. Jego głównym celem projektowym jest dekonstrukcja logiki konta, środowiska wykonawczego i izolacji stanu do najmniejszej jednostki, którą można niezależnie zaplanować, aby osiągnąć wysoką współbieżność wykonywania i zdolność reagowania o małych opóźnieniach w łańcuchu. Kluczową innowacją zaproponowaną przez MegaETH jest to, że architektura Micro-VM + State Dependency DAG (directed and acyclic state dependency graph) oraz modułowy mechanizm synchronizacji wspólnie budują równoległy system wykonawczy dla "wątków wewnątrzłańcuchowych".

  Architektura Micro-VM: Konta są wątkami

  MegaETH wprowadza model wykonywania "jednej mikro-VM na konto", który "wątkuje" środowisko wykonawcze i zapewnia minimalną jednostkę izolacyjną dla planowania równoległego. Te maszyny wirtualne komunikują się ze sobą za pośrednictwem asynchronicznej obsługi komunikatów zamiast wywołań synchronicznych, a duża liczba maszyn wirtualnych może być wykonywana niezależnie, przechowywana niezależnie i naturalnie równolegle.

  State Dependency DAG: mechanizm

  planowania oparty na grafach MegaETH zbudowało system planowania DAG w oparciu o relację dostępu do stanu konta, a system utrzymuje globalny wykres zależności w czasie rzeczywistym, a to, które konta są modyfikowane i które konta są odczytywane dla każdej transakcji, są modelowane w zależnościach. Transakcje bezkonfliktowe mogą być wykonywane bezpośrednio równolegle, a transakcje zależne będą planowane i sortowane szeregowo lub odroczone w porządku topologicznym. Wykresy zależności zapewniają spójność stanu i brak zduplikowanych zapisów podczas wykonywania równoległego.

  Asynchroniczny mechanizm wykonywania i wywoływania zwrotnego

  MegaETH jest zbudowany na szczycie paradygmatu programowania asynchronicznego, podobnie jak asynchroniczne przekazywanie komunikatów w modelu aktora, w celu rozwiązania problemu tradycyjnych wywołań szeregowych EVM. Wywołania kontraktów są asynchroniczne (wykonywanie nierekurencyjne), a gdy wywoływany jest kontrakt A -> B -> C, każde wywołanie jest asynchroniczne bez blokowania oczekiwania; Stos wywołań jest rozwijany do asynchronicznego wykresu wywołań; Przetwarzanie transakcji = przechodzenie przez graf asynchroniczny + rozwiązywanie zależności + planowanie równoległe.

  Podsumowując, MegaETH przełamuje tradycyjny model jednowątkowej maszyny stanowej EVM, implementuje hermetyzację mikromaszyn wirtualnych dla poszczególnych kont, przeprowadza planowanie transakcji za pomocą wykresów zależnych od stanu i zastępuje synchroniczny stos wywołań asynchronicznym mechanizmem przesyłania wiadomości. Jest to równoległa platforma obliczeniowa, która została przeprojektowana z pełnych wymiarów "struktury konta→ architektury planowania → procesu wykonywania", zapewniając nowy pomysł na poziomie paradygmatu na budowę wysokowydajnego systemu on-chain nowej generacji.

  MegaETH wybrał ścieżkę refaktoryzacji: całkowicie abstrahuje konta i kontrakty do niezależnych maszyn wirtualnych i uwalnia najwyższy potencjał równoległości dzięki asynchronicznemu planowaniu wykonywania. Teoretycznie MegaETH ma wyższy limit równoległy, ale jest też trudniejszy do kontrolowania złożoności i bardziej przypomina superrozproszony system operacyjny w ramach koncepcji Ethereum.

  

  Monad i MegaETH Oba mają różne koncepcje projektowe od shardingu: sharding poziomo dzieli blockchain na wiele niezależnych podłańcuchów (shardów), z których każdy jest odpowiedzialny za część transakcji i stan, przełamując ograniczenie pojedynczego łańcucha i skalując się w warstwie sieciowej; Z drugiej strony, zarówno Monady, jak i MegaETH utrzymują integralność pojedynczego łańcucha, skalując się poziomo tylko w warstwie wykonawczej i dokonując przełomów optymalizacyjnych równolegle na granicy pojedynczego łańcucha. Oba reprezentują dwa kierunki: wzmocnienie pionowe i ekspansję poziomą na ścieżce ekspansji blockchain.

  Projekty obliczeń równoległych, takie jak Monad i MegaETH, koncentrują się głównie na ścieżce optymalizacji przepustowości, a głównym celem jest poprawa TPS w łańcuchu oraz osiągnięcie równoległego przetwarzania na poziomie transakcji lub konta dzięki odroczonym wykonaniom i architekturom mikro-VM. Pharos Network to modułowa, równoległa sieć blockchain L1 z pełnym stosem, a jej podstawowy system obliczeń równoległych nazywa się "Rollup Mesh". Architektura ta obsługuje środowiska maszyn wielowirtualnych (EVM i Wasm) dzięki synergii sieci głównej i specjalnych sieci przetwarzania (SPN) oraz integruje zaawansowane technologie, takie jak dowody z wiedzą zerową (ZK) i zaufane środowiska wykonawcze (TEE).

  Rollup Mesh Parallel Computing Analysis:

  1. Full Lifecycle Asynchronous Pipelining: Pharos oddziela różne etapy transakcji (takie jak konsensus, wykonanie i przechowywanie) i przyjmuje przetwarzanie asynchroniczne, dzięki czemu każdy etap może być przeprowadzany niezależnie i równolegle, poprawiając w ten sposób ogólną wydajność przetwarzania.
  2. Równoległe wykonywanie dwóch maszyn wirtualnych: Pharos obsługuje zarówno środowiska maszyn wirtualnych EVM, jak i WASM, umożliwiając programistom wybór odpowiedniego środowiska wykonawczego dla ich potrzeb. Ta architektura z dwoma maszynami wirtualnymi nie tylko zwiększa elastyczność systemu, ale także zwiększa przetwarzanie transakcji poprzez równoległe wykonywanie.
  3. Specjalne sieci przetwarzania (SPN): Nazwy SPN są kluczowymi komponentami w architekturze Pharos, podobnymi do podsieci modułowych zaprojektowanych do obsługi określonych typów zadań lub aplikacji. Dzięki nazwom SPN Pharos umożliwia dynamiczną alokację zasobów i równoległe przetwarzanie zadań, co jeszcze bardziej zwiększa skalowalność i wydajność systemu.
  4. Modular Consensus & Restaking: Pharos wprowadza elastyczny mechanizm konsensusu, który obsługuje wiele modeli konsensusu (takich jak PBFT, PoS, PoA) i umożliwia bezpieczne udostępnianie i integrację zasobów między mainnetem a SPN za pośrednictwem protokołu restaking .

  Ponadto Pharos rekonstruuje model wykonawczy od dolnej warstwy silnika pamięci masowej za pomocą wielowersyjnego drzewa Merkle'a, kodowania Delta, adresowania wersjonowanego i technologii ADS Pushdown, a także uruchamia Pharos Store, wysokowydajny silnik pamięci masowej dla natywnego blockchaina, aby osiągnąć wysoką przepustowość, niskie opóźnienia i silne weryfikowalne możliwości przetwarzania w łańcuchu.

  Ogólnie rzecz biorąc, architektura Rollup Mesh firmy Pharos osiąga wysoką wydajność obliczeń równoległych dzięki modułowej konstrukcji i mechanizmowi przetwarzania asynchronicznego.

  Oprócz równoległych architektur wykonawczych Monad, MegaETH i Pharos, obserwujemy również, że na rynku istnieją projekty, które badają ścieżkę zastosowania akceleracji GPU w obliczeniach równoległych EVM, jako ważne uzupełnienie i najnowocześniejszy eksperyment do ekosystemu równoległego EVM. Wśród nich Reddio i GatlingX to dwa reprezentatywne kierunki:

  • Reddio to wysokowydajna platforma, która łączy w sobie architekturę równoległego wykonywania zkRollup i GPU, a jej istota polega na rekonstrukcji procesu wykonywania EVM i realizacji natywnej równoległości warstwy wykonawczej poprzez wielowątkowe planowanie, asynchroniczne przechowywanie stanów i akcelerowane przez GPU wykonywanie partii transakcji. Równoległy stopień szczegółowości na poziomie transakcji + poziom operacji (wielowątkowy kod operacji). Został zaprojektowany w celu wprowadzenia wielowątkowego wykonywania wsadowego, asynchronicznego ładowania stanu i logiki transakcji przetwarzania równoległego GPU (EVM równoległe zgodne z CUDA). Podobnie jak Monad / MegaETH, Reddio koncentruje się również na przetwarzaniu równoległym w warstwie wykonawczej, z tą różnicą, że silnik wykonawczy jest rekonstruowany za pomocą architektury równoległej GPU, zaprojektowanej z myślą o scenariuszach o wysokiej przepustowości i dużej mocy obliczeniowej, takich jak wnioskowanie AI. GatlingX,
  • który nazywa siebie "GPU-EVM", proponuje bardziej radykalną architekturę, która próbuje przenieść model "szeregowego wykonywania na poziomie instrukcji" tradycyjnych maszyn wirtualnych EVM do natywnego dla GPU środowiska równoległego uruchomieniowego. Podstawowym mechanizmem jest dynamiczne kompilowanie kodu bajtowego EVM do równoległych zadań CUDA i wykonywanie strumienia instrukcji przez wielordzeniowy procesor graficzny, tak aby przełamać sekwencyjne wąskie gardło EVM na najniższym poziomie. Stopień szczegółowości równoległej, który należy do równoległości na poziomie instrukcji (ILP). W porównaniu z równoległą granulacją "na poziomie transakcji/konta" Monad / MegaETH, mechanizm równoległości GatlingX należy do ścieżki optymalizacji na poziomie instrukcji, która jest bliższa podstawowej refaktoryzacji silnika maszyny wirtualnej. Obecnie znajduje się w fazie koncepcyjnej, z opublikowaną białą księgą i szkicem architektonicznym, a także nie ma jeszcze SDK ani mainnetu.

  Artela proponuje zróżnicowaną, równoległą koncepcję projektowania. Wraz z wprowadzeniem maszyny wirtualnej WebAssembly (WASM) o architekturze EVM++, programiści mogą dynamicznie dodawać i wykonywać rozszerzenia w łańcuchu przy użyciu modelu programowania Aspect przy zachowaniu kompatybilności EVM. Wykorzystuje stopień szczegółowości wywołania kontraktu (funkcja / rozszerzenie) jako minimalną jednostkę równoległą i obsługuje wstrzykiwanie modułów rozszerzeń (podobnie jak "podłączane oprogramowanie pośredniczące"), gdy kontrakt EVM jest uruchomiony, aby osiągnąć logiczne rozłączenie, asynchroniczne wywołanie i równoległe wykonanie na poziomie modułu. Większą uwagę zwrócono na komponowalność i modułową architekturę warstwy wykonawczej. Koncepcja ta dostarcza nowych pomysłów na złożone aplikacje wielomodułowe w przyszłości.

  3. Natywny łańcuch architektury równoległej: Model wykonania EVM Ethereum, ontologia wykonania zrekonstruowanej maszyny wirtualnej

  ,

  od początku swojego projektowania przyjął jednowątkową architekturę "pełnego zamówienia transakcji + wykonania szeregowego", mając na celu zapewnienie pewności i spójności zmian stanu dla wszystkich węzłów w sieci. Jednak ta architektura ma naturalne wąskie gardło w wydajności, ograniczając przepustowość i skalowalność systemu. Z kolei natywne łańcuchy architektury obliczeń równoległych, takie jak Solana (SVM), MoveVM (Sui, Aptos) i Sei v2 zbudowane na Cosmos SDK, są dostosowane do wykonywania równoległego z podstawowego projektu i mają następujące zalety:

  • Naturalna separacja modeli stanów: Solana wykorzystuje mechanizm deklaracji blokady konta, MoveVM wprowadza model własności obiektu, a Sei v2 opiera się na klasyfikacji typów transakcji. Realizowana jest statyczna ocena konfliktu i obsługiwane jest współbieżne planowanie na poziomie transakcji.
  • Maszyny wirtualne są zoptymalizowane pod kątem współbieżności: silnik Sealevel firmy Solana natywnie obsługuje wykonywanie wielowątkowe; MoveVM może wykonywać statyczną analizę wykresów współbieżności; Sei v2 integruje wielowątkowy silnik dopasowywania z równoległym modułem maszyny wirtualnej.

  Oczywiście, ten rodzaj natywnego łańcucha równoległego stoi również przed wyzwaniem kompatybilności ekologicznej. Architektury inne niż EVM zwykle wymagają nowych języków programowania (takich jak Move i Rust) oraz łańcuchów narzędzi, które wiążą się z pewnymi kosztami migracji dla programistów. Ponadto programiści muszą opanować szereg nowych koncepcji, takich jak stanowe modele dostępu, limity współbieżności, cykle życia obiektów itp., które stawiają wyższe wymagania dotyczące zrozumienia progów i paradygmatów programowania.

  3.1 Zasada równoległego silnika na poziomie morza Solana i SVM

  Model realizacji Sealevel firmy Solana to mechanizm równoległego planowania kont, który jest podstawowym silnikiem wykorzystywanym przez Solana do realizacji realizacji równoległych transakcji w łańcuchu i osiąga wysoką wydajność współbieżności na poziomie inteligentnych kontraktów poprzez mechanizm "deklaracja konta + planowanie statyczne + wykonanie wielowątkowe". Sealevel jest pierwszym modelem wykonawczym w dziedzinie blockchain, który z powodzeniem wdraża współbieżne planowanie wewnątrz łańcucha w środowisku produkcyjnym, a jego pomysły architektoniczne wpłynęły na wiele późniejszych projektów obliczeń równoległych i stanowią paradygmat odniesienia dla wysokowydajnego projektowania równoległego warstwy 1.

  Podstawowy mechanizm:

  1. Jawne listy dostępu do konta: Każda transakcja musi zadeklarować zaangażowane konto (odczyt/zapis) podczas przesyłania, a system określi, czy występuje konflikt stanu między transakcjami.

  2. Wykrywanie konfliktów i planowanie wielowątkowe

  • Jeśli nie ma przecięcia między zestawami kont, do których uzyskuje się dostęp przez dwie transakcje→ mogą one być wykonywane równolegle;
  • Występuje konflikt→ wykonywanie szeregowe w kolejności zależnej;
  • Harmonogram przydziela transakcje do różnych wątków na podstawie wykresu zależności.

  3. Kontekst wywołania programu: Każde wywołanie kontraktu jest uruchamiane w izolowanym kontekście bez współdzielonego stosu, aby uniknąć zakłóceń między wywołaniami.

  Sealevel to silnik planowania równoległej realizacji Solany, podczas gdy SVM to środowisko realizacji inteligentnych kontraktów zbudowane na bazie Sealevel (przy użyciu maszyny wirtualnej BPF). Razem tworzą one techniczną podstawę wysokowydajnego systemu równoległej realizacji Solana.

  Eclipse to projekt, który wdraża maszyny wirtualne Solana w łańcuchach modułowych, takich jak Ethereum L2 lub Celestia, wykorzystując silnik wykonywania równoległego Solana jako warstwę wykonywania pakietów. Eclipse jest jednym z pierwszych projektów, który proponuje odłączenie warstwy wykonawczej Solana (Sealevel + SVM) od sieci głównej Solana i migrację jej do architektury modułowej, a modularnym wyjściem "super współbieżnego modelu wykonawczego" Solany jest Execution Layer-as-a-Service, więc Eclipse również należy do kategorii obliczeń równoległych.

  Trasa Neon jest inna, wprowadza EVM do działania w środowisku SVM / Sealevel. Zbuduj warstwę uruchomieniową kompatybilną z EVM, programiści mogą używać Solidity do tworzenia kontraktów i uruchamiania w środowisku SVM, ale wykonywanie harmonogramu wykorzystuje SVM + Sealeve. Neon skłania się bardziej ku kategorii Modular Blockchain niż innowacjom w zakresie obliczeń równoległych.

  Podsumowując, Solana i SVM opierają się na silniku wykonawczym Sealevel, a filozofia planowania Solany oparta na systemie operacyjnym jest podobna do harmonogramu jądra, który jest szybki, ale stosunkowo nieelastyczny. Jest to natywny, wysokowydajny, równoległy łańcuch publiczny.

  3.2 Architektura MoveVM: Sterowanie zasobami i obiektami

  MoveVM to maszyna wirtualna z inteligentnymi kontraktami zaprojektowana z myślą o bezpieczeństwie zasobów w łańcuchu i równoległym wykonywaniu, a jej podstawowy język, Move, został pierwotnie opracowany przez Meta (dawniej Facebook) dla projektu Libra, kładąc nacisk na koncepcję "zasoby są obiektami", a wszystkie stany on-chain istnieją jako obiekty, z wyraźną własnością i cyklami życia. Dzięki temu MoveVM może analizować, czy występują konflikty stanów między transakcjami w czasie kompilacji, i implementować statyczne planowanie równoległe na poziomie obiektu, które jest szeroko stosowane w natywnych równoległych łańcuchach publicznych, takich jak Sui i Aptos.

  Model

  własności obiektów firmy SuiMożliwości

  obliczeń równoległych firmy Sui wynikają z unikalnego podejścia do modelowania stanów i analizy statycznej na poziomie języka. W przeciwieństwie do tradycyjnych blockchainów, które wykorzystują globalne drzewa stanów, Sui zbudował model obiektocentryczny oparty na "obiekcie", który współpracuje z systemem typów liniowych MoveVM, aby planowanie równoległe było procesem deterministycznym, który można zakończyć w czasie kompilacji.

  • Model obiektowy jest fundamentem równoległej architektury Sui. Sui abstrahuje cały stan w łańcuchu do oddzielnych obiektów, z których każdy ma unikalny identyfikator, wyraźnego właściciela (konto lub umowę) i definicję typu. Obiekty te nie współdzielą ze sobą stanu i są z natury izolowane. Kontrakt musi jawnie deklarować zbiór obiektów zaangażowanych w jego wywołanie, unikając problemu sprzężenia stanów tradycyjnego "globalnego drzewa stanów" w łańcuchu. Ten projekt dzieli stan on-chain na kilka niezależnych jednostek, dzięki czemu jednoczesne wykonywanie jest strukturalnie wykonalną przesłanką do planowania.
  • Static Ownership Analysis to mechanizm analizy w czasie kompilacji, zaimplementowany przy wsparciu liniowego systemu czcionek języka Move. Umożliwia systemowi planowanie równoległego wykonywania transakcji poprzez wnioskowanie, które transakcje nie mają konfliktów stanu poprzez własność obiektu przed ich wykonaniem. W porównaniu z wykrywaniem konfliktów i wycofywaniem tradycyjnych środowisk wykonawczych, mechanizm analizy statycznej Sui znacznie zmniejsza złożoność planowania, jednocześnie poprawiając wydajność wykonywania, co jest kluczem do osiągnięcia wysokiej przepustowości i deterministycznych możliwości przetwarzania równoległego.

  Sui dzieli przestrzeń stanów na zasadzie obiekt po obiekcie, w połączeniu z analizą własności w czasie kompilacji, w celu uzyskania taniego, niewymagającego wycofywania równoległego wykonywania na poziomie obiektu. W porównaniu z wykonywaniem szeregowym lub wykrywaniem w czasie wykonywania tradycyjnych łańcuchów, Sui osiągnął znaczną poprawę wydajności wykonywania, determinizmu systemu i wykorzystania zasobów.

  Mechanizm wykonywania Block-STM firmy AptosAptos

  to wysokowydajny blockchain warstwy 1 oparty na języku Move, a jego zdolność do równoległego wykonywania wywodzi się głównie z samodzielnie opracowanej struktury Block-STM (Block-level Software Transactional Memory). W przeciwieństwie do strategii Sui "statycznej równoległości w czasie kompilacji", Block-STM należy do dynamicznego mechanizmu planowania "optymistycznej współbieżności w czasie wykonywania + wycofywania konfliktu", który jest odpowiedni do radzenia sobie z zestawami transakcji o złożonych zależnościach.

  Block-STM dzieli wykonanie transakcji bloku na trzy etapy:

  • Realizacja spekulatywna: Wszystkie transakcje są domyślnie wolne od konfliktów przed wykonaniem, a system planuje transakcje równolegle do wielu wątków, aby spróbować wykonać je jednocześnie, i rejestruje stan konta (zestaw odczytu/zapisu), do którego uzyskały dostęp.
  • Faza walidacji: System weryfikuje wynik wykonania: jeśli występuje konflikt odczytu i zapisu między dwiema transakcjami (na przykład Tx1 odczytuje stan zapisu przez Tx2), jedna z nich jest wycofywana.
  • Faza ponawiania prób: Transakcje powodujące konflikt zostaną ponownie zaplanowane, dopóki ich zależności nie zostaną rozwiązane, a ostatecznie wszystkie transakcje tworzą prawidłową, deterministyczną sekwencję przesyłania stanu.

  Block-STM to dynamiczny model wykonawczy "optymistycznej równoległości + wycofywania i ponownych prób", który jest odpowiedni dla intensywnych stanów i logicznie złożonych scenariuszy przetwarzania wsadowego transakcji w łańcuchu i jest równoległym rdzeniem obliczeniowym dla Aptos do budowy łańcucha publicznego o wysokiej wszechstronności i przepustowości.

  

  Solana to inżynierska szkoła planowania, bardziej jak "jądro systemu operacyjnego", odpowiednie do jasnych granic stanu, kontrolowane transakcje o wysokiej częstotliwości, to styl inżyniera sprzętu, do uruchamiania łańcucha jak sprzęt (wykonywanie równoległe klasy sprzętowej); Aptos jest odporny na awarie systemu, bardziej przypomina "silnik współbieżności bazy danych", odpowiedni dla systemów kontraktowych z silnym sprzężeniem stanów i złożonymi łańcuchami wywołań. Aptos i Sui są jak inżynierowie języków programowania, a bezpieczeństwo zasobów klasy programowej reprezentuje techniczną ścieżkę implementacji obliczeń równoległych Web3 w ramach różnych filozofii.

  3.3 Cosmos SDK Skalowanie równoległe

  Sei V2 to wysokowydajny transakcyjny łańcuch publiczny zbudowany w oparciu o Cosmos SDK, a jego zdolność do równoległości znajduje odzwierciedlenie głównie w dwóch aspektach: wielowątkowym silniku dopasowywania (Parallel Matching Engine) oraz optymalizacji równoległego wykonywania warstwy maszyny wirtualnej, która została zaprojektowana do obsługi scenariuszy transakcji on-chain o wysokiej częstotliwości i niskich opóźnieniach, takich jak księga zamówień DEX, infrastruktura wymiany on-chain itp.

  Podstawowy mechanizm równoległości:

  1. Parallel Matching Engine: SEI V2 wprowadza wielowątkową ścieżkę wykonania do logiki dopasowywania zleceń, dzieląc księgę zleceń oczekujących i logikę dopasowywania na poziomie wątku, dzięki czemu zadania dopasowywania między wieloma parami handlowymi mogą być przetwarzane równolegle i unikają wąskiego gardła jednowątkowego.
  2. Optymalizacja współbieżności na poziomie maszyny wirtualnej: Sei V2 tworzy środowisko uruchomieniowe CosmWasm z możliwościami współbieżnego wykonywania, co umożliwia równoległe uruchamianie niektórych wywołań kontraktów bez konfliktów stanów i współpracuje z mechanizmem klasyfikacji typów transakcji w celu osiągnięcia wyższej kontroli przepływności.
  3. Równoległy konsensus i planowanie warstwy wykonawczej: Tak zwany mechanizm konsensusu "Twin-Turbo" został wprowadzony w celu wzmocnienia przepustowości i oddzielenia między warstwą konsensusu a warstwą wykonawczą oraz poprawy ogólnej wydajności przetwarzania bloków.

  3.4 Model UTXO Reformer Fuel Fuel

  to wysokowydajna warstwa wykonawcza zaprojektowana w oparciu o modułową architekturę Ethereum, a jej podstawowy mechanizm równoległości wywodzi się z ulepszonego modelu UTXO (Unspent Transaction Output). W przeciwieństwie do modelu konta Ethereum, Fuel wykorzystuje strukturę UTXO do reprezentowania aktywów i stanów, która jest z natury izolowana od stanu, co ułatwia określenie, które transakcje mogą być bezpiecznie wykonywane równolegle. Ponadto Fuel wprowadza opracowany przez siebie język inteligentnych kontraktów Sway (podobny do Rusta), w połączeniu z narzędziami do analizy statycznej, w celu określenia konfliktów danych wejściowych przed wykonaniem transakcji, aby osiągnąć wydajne i bezpieczne równoległe planowanie na poziomie transakcji. Jest to alternatywna warstwa wykonawcza EVM, która równoważy wydajność i modułowość.

  4. Model aktora: nowy paradygmat współbieżnego wykonywania

  agentów Model aktora to paradygmat wykonywania równoległego oparty na agencie lub procesie, który różni się od tradycyjnego synchronicznego obliczania stanu globalnego w łańcuchu (Solana/Sui/Monad i inne scenariusze "równoległego przetwarzania w łańcuchu"), który podkreśla, że każdy agent ma niezależny stan i zachowanie oraz komunikuje się i planuje za pomocą asynchronicznych komunikatów. W ramach tej architektury system on-chain może być uruchamiany jednocześnie przez dużą liczbę procesów, które są od siebie oddzielone, i ma silną skalowalność oraz asynchroniczną odporność na awarie. Reprezentatywne projekty obejmują AO (Arweave AO), ICP (Internet Computer) i Cartesi, które napędzają ewolucję blockchaina od silnika wykonawczego do "systemu operacyjnego on-chain", zapewniając natywną infrastrukturę dla agentów AI, interakcji wielozadaniowych i złożonej orkiestracji logicznej.

  Podczas gdy projekt modelu aktora jest podobny do shardingu pod względem powierzchownych cech (np. równoległości, izolacji stanów i przetwarzania asynchronicznego), te dwie zasadniczo reprezentują zupełnie różne ścieżki techniczne i filozofie systemu. Model aktora kładzie nacisk na "wieloprocesowe przetwarzanie asynchroniczne", w którym każdy agent działa niezależnie, utrzymuje stan niezależnie i współdziała w sposób oparty na komunikatach. Z drugiej strony sharding to mechanizm "poziomego shardingu stanu i konsensusu", który dzieli cały blockchain na wiele podsystemów (shardów), które przetwarzają transakcje niezależnie. Modele aktorów są bardziej jak "rozproszony system operacyjny agenta" w świecie Web3, podczas gdy sharding jest strukturalnym rozwiązaniem skalującym dla możliwości przetwarzania transakcji w łańcuchu. Oba osiągają równoległość, ale mają różne punkty początkowe, cele i architektury wykonywania.

  4.1 AO (Arweave), super-równoległy komputer na warstwie pamięci masowejAO

  to zdecentralizowana platforma obliczeniowa działająca w warstwie pamięci trwałej Arweave, której głównym celem jest zbudowanie systemu operacyjnego on-chain, który obsługuje działanie agentów asynchronicznych na dużą skalę.

  Podstawowe cechy architektury:

  • Architektura procesu: Każdy agent jest nazywany procesem, z niezależnym stanem, niezależnym harmonogramem i logiką wykonywania;
  • Brak struktury blockchain: AO nie jest łańcuchem, ale zdecentralizowaną warstwą pamięci masowej + wieloagentowym silnikiem wykonawczym opartym na komunikatach opartym na Arweave;
  • Asynchroniczny system planowania komunikatów: Procesy komunikują się ze sobą za pośrednictwem komunikatów, przyjmują asynchroniczny model operacji bez blokad i w naturalny sposób obsługują współbieżną rozbudowę.
  • Stałe przechowywanie stanu: Wszystkie stany agentów, rekordy wiadomości i instrukcje są trwale rejestrowane w Arweave, co zapewnia pełną audytowalność i zdecentralizowaną przejrzystość.
  • Natywny dla agentów: Nadaje się do wdrażania złożonych, wieloetapowych zadań (takich jak agenci AI, kontrolery protokołu DePIN, automatyczne orkiestratory zadań itp.) i może zbudować "koprocesor AI w łańcuchu".

  AO podąża ostateczną drogą "natywna architektura agenta + sterownik pamięci masowej + architektura bezłańcuchowa", kładąc nacisk na elastyczność i oddzielenie modułów, i jest "strukturą mikrojądra w łańcuchu zbudowaną na warstwie pamięci masowej", z celowo zawężającą się granicą systemu, kładąc nacisk na lekkie przetwarzanie + komponowalną strukturę sterowania.

  4.2 ICP (Internet Computer), platforma hostingowa Web3 typu full-stackICP

  to natywna platforma aplikacji on-chain Web3 typu full-stack uruchomiona przez DFINITY, której celem jest rozszerzenie mocy obliczeniowej on-chain na doświadczenia podobne do Web2 i wspieranie pełnego hostingu usług, wiązania nazw domen i architektury bezserwerowej.

  Podstawowe cechy architektury:

  • Architektura kanistrów (kontenery jako agenci): każdy kanister jest agentem działającym na maszynie wirtualnej Wasm z niezależnymi możliwościami planowania stanu, kodu i asynchronicznego;
  • Subnet Distributed Consensus System (Subnet): Cała sieć składa się z wielu podsieci, z których każda utrzymuje zestaw kanistrów i osiąga konsensus poprzez mechanizm podpisu BLS.
  • Model wywołania asynchronicznego: Kanister komunikuje się z usługą Canister za pośrednictwem komunikatów asynchronicznych, obsługuje wykonywanie bez blokowania i ma naturalną równoległość.
  • Hosting on-chain: Obsługuje inteligentne kontrakty do bezpośredniego hostowania stron front-end, natywnego mapowania DNS i jest pierwszą platformą blockchain, która obsługuje przeglądarki w celu bezpośredniego dostępu do dApps;
  • System posiada pełne funkcje: Posiada systemowe interfejsy API, takie jak aktualizacja na gorąco on-chain, uwierzytelnianie tożsamości, losowość rozproszona i timer, który jest odpowiedni do złożonego wdrażania usług on-chain.

  ICP wybiera paradygmat systemu operacyjnego oparty na ciężkiej platformie, zintegrowanym pakowaniu i silnej kontroli platformy, a także ma "system operacyjny blockchain", który integruje konsensus, wykonywanie, przechowywanie i dostęp, kładąc nacisk na pełne możliwości hostingu usług i rozszerzając granice systemu do pełnej platformy hostingowej Web3.

  Ponadto projekty obliczeń równoległych innych paradygmatów modelu aktora można odnieść się do poniższej tabeli:

  

  5. Podsumowanie i perspektywaW

  oparciu o różnice między architekturą maszyny wirtualnej a systemem językowym, rozwiązania obliczeń równoległych blockchain można z grubsza podzielić na dwie kategorie: równoległy łańcuch ulepszeń EVM i natywny łańcuch architektury równoległej (inny niż EVM).

  Opierając się na zachowaniu kompatybilności ekosystemu EVM/Solidity, ten pierwszy osiąga wyższą przepustowość i możliwości przetwarzania równoległego dzięki dogłębnej optymalizacji warstwy wykonawczej, co jest odpowiednie dla scenariuszy, które chcą odziedziczyć aktywa Ethereum i narzędzia programistyczne oraz jednocześnie osiągnąć przełomy w wydajności. Do reprezentatywnych projektów należą:

  • Monad: Wdraża optymistyczny model równoległego wykonywania zgodny z EVM poprzez odroczony zapis i wykrywanie konfliktów w czasie wykonywania, buduje wykresy zależności i planuje wykonanie po osiągnięciu konsensusu.
  • MegaETH: Abstrahuje każde konto/kontrakt do niezależnej mikro-maszyny wirtualnej i implementuje wysoce rozdzielone równoległe planowanie na poziomie konta w oparciu o asynchroniczne przesyłanie komunikatów i wykresy zależne od stanu.
  • Pharos: Zbuduj architekturę siatki zbiorczej, aby osiągnąć równoległe przetwarzanie na poziomie systemu między procesami za pośrednictwem potoków asynchronicznych i modułów SPN.
  • Reddio: Wykorzystuje architekturę zkRollup + GPU, aby przyspieszyć proces weryfikacji zkEVM poza łańcuchem poprzez generowanie wsadowe SNARK i poprawić przepustowość weryfikacji.

  Ten ostatni całkowicie pozbywa się ograniczeń kompatybilności Ethereum i przeprojektowuje paradygmat wykonywania z maszyny wirtualnej, modelu stanu i mechanizmu planowania, aby osiągnąć natywną współbieżność o wysokiej wydajności. Typowe podklasy obejmują:

  • Solana (SVM): model równoległego wykonywania na poziomie konta oparty na roszczeniach o dostęp do konta i statycznym planowaniu wykresów konfliktów;
  • Sui / Aptos (system MoveVM): Oparty na modelu obiektów zasobów i systemie typów, obsługuje analizę statyczną w czasie kompilacji i realizuje równoległość na poziomie obiektu.
  • Sei V2 (trasa Cosmos SDK): wprowadza wielowątkowy aparat dopasowywania i optymalizację współbieżności maszyn wirtualnych w architekturze Cosmos, która jest odpowiednia dla transakcyjnych aplikacji o wysokiej częstotliwości.
  • Paliwo (architektura UTXO + Sway): równoległość na poziomie transakcji poprzez statyczną analizę zestawu wejściowego UTXO, łącząca modułową warstwę wykonawczą z dostosowanym językiem inteligentnych kontraktów Sway;

  Ponadto, jako bardziej uogólniony system równoległy, Model Aktora buduje paradygmat wykonywania on-chain "niezależna operacja od wielu agentów + współpraca sterowana komunikatami" poprzez asynchroniczny mechanizm planowania procesów oparty na Wasm lub niestandardowych maszynach wirtualnych. Do reprezentatywnych projektów należą:

  • AO (Arweave AO): Budowa asynchronicznego systemu mikrojądra on-chain opartego na trwałym środowisku uruchomieniowym agenta sterowanym pamięcią masową;
  • ICP (Internet Computer): używa konteneryzowanego agenta (Kanister) jako najmniejszej jednostki w celu osiągnięcia asynchronicznego i wysoce skalowalnego wykonywania poprzez koordynację podsieci.
  • Cartesi: Wprowadza system operacyjny Linux jako środowisko obliczeniowe poza łańcuchem, aby zapewnić ścieżkę weryfikacji w łańcuchu dla zaufanych wyników obliczeń, odpowiednią dla złożonych lub intensywnie korzystających z zasobów scenariuszy aplikacji.

  Opierając się na powyższej logice, możemy podsumować obecny schemat głównego nurtu obliczeń równoległych w łańcuchu publicznym w strukturę klasyfikacyjną, jak pokazano na poniższym rysunku:

  

  Z szerszej perspektywy skalowania, sharding i rollup (L2) koncentrują się na skalowaniu poziomym poprzez sharding stanów lub wykonywanie poza łańcuchem, podczas gdy równoległe łańcuchy obliczeniowe (np. Monad, Sui, Solana) i systemy zorientowane na aktorów (np. AO, ICP) bezpośrednio rekonstruują model wykonania i osiągają natywną równoległość w łańcuchu lub w warstwie systemu. Pierwsza z nich poprawia przepustowość wewnątrz łańcucha dzięki wielowątkowym maszynom wirtualnym, modelom obiektowym, analizie konfliktów transakcji itp.; Ten ostatni przyjmuje proces/agenta jako jednostkę podstawową i przyjmuje tryby wykonywania sterowane komunikatami i asynchroniczne, aby osiągnąć współbieżne działanie wielu agentów. W przeciwieństwie do tego, sharding i rollupy są bardziej jak "dzielenie obciążenia na wiele łańcuchów" lub "outsourcing poza łańcuchem", podczas gdy model łańcucha równoległego i aktora "uwalnia potencjał wydajności z samego silnika wykonawczego", odzwierciedlając bardziej gruntowną ewolucję architektury.

  Przetwarzanie równoległe a architektura shardingu vs skalowanie zbiorcze vs porównanie ścieżek skalowania zorientowanych na aktora

  

  Należy podkreślić, że większość natywnych łańcuchów architektury równoległej weszła w fazę uruchamiania mainnetu, chociaż cały ekosystem deweloperski jest nadal trudny do porównania z systemem Solidity systemu EVM, ale projekty reprezentowane przez Solana i Sui, z ich wysokowydajną architekturą wykonawczą i stopniowym dobrobytem aplikacji ekologicznych, stały się podstawowymi łańcuchami publicznymi, do których rynek przywiązuje dużą wagę.

  W przeciwieństwie do tego, chociaż ekosystem Ethereum Rollup (L2) wszedł w etap "10 000 łańcuchów na raz" lub nawet "nadmiernej mocy", obecny główny łańcuch równoległych ulepszeń EVM jest nadal generalnie w fazie sieci testowej i nie został jeszcze zweryfikowany przez rzeczywiste środowisko mainnetu, a jego zdolność skalowania i stabilność systemu nadal wymagają dalszych testów. Czas pokaże, czy projekty te mogą znacznie poprawić wydajność EVM i napędzać skoki ekologiczne bez poświęcania kompatybilności, czy też mogą jeszcze bardziej zróżnicować płynność i zasoby rozwojowe Ethereum.