Cena AO

$AO jest jak $ICP, ale bez inwestorów venture, przy różnicy wyceny wynoszącej 39x. Zrobiliśmy na ten temat długi raport w zeszłym miesiącu w @dyorcryptoapp.

Autorzy: 0xjacobzhao i ChatGPT 4o "Bezpieczeństwo", "decentralizacja" i "skalowalność" blockchaina "Trylemat Blockchain" ujawniają 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 przez wykonywanie: zwiększa możliwości wykonywania, takie jak równoległość, procesor graficzny i wielordzeniowość, in situ Skalowanie izolowane od stanu: dzieli w poziomie stan/fragmenty, takie jak fragmenty, UTXO i wiele podsieci Skalowanie outsourcingu poza łańcuchem: Umieszczanie realizacji poza łańcuchem, takiej jak rollupy, koprocesory i DA Strukturalne rozszerzenie zdolności odsprzęgania: Architektura jest modułowa i współpracuje ze sobą, np. łańcuchy modułów, współdzielone sekwencery i siatki rollupów Asynchroniczne skalowanie współbieżne: model aktora, izolacja procesu, sterowane komunikatami, takie jak agenci i wielowątkowe łańcuchy asynchroniczne 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. Na poziomie konta: Reprezentuje projekt Solana Równoległość na poziomie obiektu: reprezentuje projekt Sui Na poziomie transakcji: reprezentuje projekt Monad, Aptos Call-level / MicroVM: Reprezentuje projekt MegaETH Poziom instrukcji: Reprezentuje projekt 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. EVM Parallel Enhancement Chain: 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. Równoległa analiza mechanizmów obliczeniowych Monad Monad to wysokowydajny blockchain warstwy 1 przeprojektowany dla maszyny wirtualnej Ethereum (EVM), oparty na podstawowej koncepcji równoległego potokowania, z asynchronicznym wykonaniem w warstwie konsensusu i optymistycznym wykonaniem równoległym w warstwie wykonawczej. 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: równoległy mechanizm wykonawczy dla rurociągów wieloetapowych Potokowanie jest podstawową koncepcją równoległego wykonywania Monad, a jej główną 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 i ostatecznie osiągnąć efekt poprawy przepustowości i zmniejszenia opóźnień. Etapy te obejmują: Propozycję, Konsensus, Wykonanie i Zatwierdzenie. Wykonywanie asynchroniczne: Konsensus — wykonuje asynchroniczne rozprzęganie W tradycyjnych łańcuchach konsensus transakcji i ich realizacja są zazwyczaj 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 porządkowanie 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łe Tradycyjne Ethereum wykorzystuje ściśle szeregowy model do 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 egzekwowania: Monad optymistycznie realizuje wszystkie transakcje równolegle, zakładając, że większość z nich nie ma między sobą konfliktów stanowych. 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. Równoległa analiza obliczeniowa MegaETH W odróżnieniu od pozycjonowania L1 Monad, 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 wykonanie lub modułowy komponent 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 mikromaszyn wirtualnych: Konta są wątkami MegaETH wprowadza model wykonywania "jednej mikro-maszyny wirtualnej na konto", który "łączy się" ze środowiskiem wykonawczym i zapewnia minimalną jednostkę izolacyjną dla równoległego planowania. 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. Asynchroniczne wykonywanie i mechanizmy wywoływania zwrotnego MegaETH jest zbudowany na szczycie paradygmatu programowania asynchronicznego, podobnie jak asynchroniczne przesyłanie wiadomości w modelu aktora, co rozwiązuje problem 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. Koncepcje projektowe zarówno Monady, jak i MegaETH są zupełnie inne niż sharding: sharding poziomo dzieli blockchain na wiele niezależnych podłańcuchów (shardów), a każdy podłańcuch jest odpowiedzialny za część transakcji i stanów, łamiąc limit 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). Analiza obliczeń równoległych Rollup Mesh: Asynchroniczne potokowanie w pełnym cyklu życia: Pharos oddziela różne etapy transakcji (np. konsensus, wykonanie, 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. 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. 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. 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 zkRollup z architekturą wykonywania równoległego GPU, a jej rdzeniem jest refaktoryzacja procesu wykonywania EVM w celu osiągnięcia 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. W chwili obecnej uruchomiony został SDK i udostępniony jest zintegrowany moduł wykonawczy Nazywając siebie "GPU-EVM", GatlingX proponuje bardziej radykalną architekturę, która próbuje przenieść model "szeregowego wykonywania na poziomie instrukcji" tradycyjnych maszyn wirtualnych EVM do natywnych dla GPU równoległych środowisk uruchomieniowych. 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: Rekonstrukcja ontologii wykonywania maszyn wirtualnych Model realizacji EVM Ethereum od początku swojego projektowania przyjął jednowątkową architekturę "pełne zlecenie transakcji + wykonanie szeregowe", 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 równoległego wykonywania z dolnej warstwy 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 implementuje statyczną ocenę konfliktu w oparciu o klasyfikację typu transakcji i obsługuje 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. Podstawowa mechanika: 1. Jawne listy dostępu do konta: Każda transakcja musi deklarować dane konto (odczyt/zapis) podczas przesyłania, aby system mógł określić, czy występuje konflikt statusu między transakcjami. 2. Wykrywanie konfliktów i planowanie wielowątkowe Jeśli zestawy kont nie nakładają się na siebie→ mogą być wykonywane równolegle; Występuje konflikt→ wykonywany szeregowo 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: sterowana 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 w łańcuchu istnieją jako obiekty, z jasną 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 Sui Możliwości Sui w zakresie obliczeń równoległych 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 egzekwowania Block-STM firmy Aptos Aptos 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 realizację transakcji w bloku na trzy etapy: Wykonywanie spekulatywne: Wszystkie transakcje są domyślnie wolne od konfliktów przed wykonaniem, a system planuje transakcje w wielu wątkach dla jednoczesnych prób wykonania i rejestruje stan konta (zestaw odczytu/zapisu), do którego uzyskano 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 przypominająca "jądro systemu operacyjnego", nadająca się do jasnych granic stanu, kontrolowanego handlu o wysokiej częstotliwości i jest stylem inżyniera sprzętu, który powinien działać w łańcuchu 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 Rozszerzenie równoległe zestawu Cosmos SDK 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, mającej na celu obsługę scenariuszy transakcji on-chain o wysokiej częstotliwości i niskich opóźnieniach, takich jak DEX-y księgi zamówień, infrastruktura wymiany w łańcuchu itp. Podstawowy mechanizm równoległy: 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ąskich gardeł jednowątkowych. 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. 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 Paliwo do reformingu modelu UTXO Fuel to wysokowydajna warstwa wykonawcza zaprojektowana w oparciu o modułową architekturę Ethereum, a jej podstawowa równoległość 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 równoległego wykonywania oparty na agencie lub procesie, który różni się od tradycyjnego synchronicznego obliczania globalnego stanu 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), superrównoległy komputer na wierzchu warstwy pamięci masowej AO to zdecentralizowana platforma obliczeniowa działająca w trwałej warstwie pamięci masowej Arweave, której głównym celem jest zbudowanie systemu operacyjnego on-chain, który obsługuje asynchroniczną operację agentów 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), kompleksowa platforma hostingowa Web3 ICP to natywna dla Web3 platforma aplikacji on-chain 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 kanistra (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 równoległe projekty obliczeniowe dla innych paradygmatów modelu aktora można znaleźć w poniższej tabeli: 5. Podsumowanie i perspektywy Opierając się na różnicach między architekturą maszyny wirtualnej a systemem językowym, rozwiązania obliczeń równoległych blockchain można z grubsza podzielić na dwie kategorie: łańcuch równoległego wzmocnienia EVM i natywny łańcuch architektury równoległej (bez 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: Zaimplementuj optymistyczny model wykonywania równoległego zgodny z EVM poprzez odroczony zapis i wykrywanie konfliktów w czasie wykonywania, buduj wykresy zależności po osiągnięciu konsensusu i planuj wykonywanie w wielu wątkach. 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. Do typowych podklas należą: Solana (SVM): Opierając się na roszczeniach o dostęp do konta i statycznym planowaniu wykresów konfliktów, reprezentuje model równoległego wykonywania na poziomie konta. 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): buduje asynchroniczny system mikrojądra on-chain oparty na trwałym środowisku uruchomieniowym agenta sterowanym przez pamięć 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 aktorów 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.

Napisane przez 0xjacobzhao i ChatGPT 4o "Bezpieczeństwo", "decentralizacja" i "skalowalność" blockchaina "Trylemat Blockchain" ujawniają 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 przez wykonywanie: zwiększa możliwości wykonywania, takie jak równoległość, procesor graficzny i wielordzeniowość, in situ Skalowanie izolowane od stanu: dzieli w poziomie stan/fragmenty, takie jak fragmenty, UTXO i wiele podsieci Skalowanie outsourcingu poza łańcuchem: Umieszczanie realizacji poza łańcuchem, takiej jak rollupy, koprocesory i DA Strukturalne rozszerzenie zdolności odsprzęgania: Architektura jest modułowa i współpracuje ze sobą, np. łańcuchy modułów, współdzielone sekwencery i siatki rollupów Asynchroniczne skalowanie współbieżne: model aktora, izolacja procesu, sterowane komunikatami, takie jak agenci i wielowątkowe łańcuchy asynchroniczne 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. Na poziomie konta: Reprezentuje projekt Solana Równoległość na poziomie obiektu: reprezentuje projekt Sui Na poziomie transakcji: reprezentuje projekt Monad, Aptos Call-level / MicroVM: Reprezentuje projekt MegaETH Poziom instrukcji: Reprezentuje projekt 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. EVM Parallel Enhancement Chain: 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. Równoległa analiza mechanizmów obliczeniowych Monad Monad to wysokowydajny blockchain warstwy 1 przeprojektowany dla maszyny wirtualnej Ethereum (EVM), oparty na podstawowej koncepcji równoległego potokowania, z asynchronicznym wykonaniem w warstwie konsensusu i optymistycznym wykonaniem równoległym w warstwie wykonawczej. 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: równoległy mechanizm wykonawczy dla rurociągów wieloetapowych Potokowanie jest podstawową koncepcją równoległego wykonywania Monad, a jej główną 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 i ostatecznie osiągnąć efekt poprawy przepustowości i zmniejszenia opóźnień. Etapy te obejmują: Propozycję, Konsensus, Wykonanie i Zatwierdzenie. Wykonywanie asynchroniczne: Konsensus — wykonuje asynchroniczne rozprzęganie W tradycyjnych łańcuchach konsensus transakcji i ich realizacja są zazwyczaj 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 porządkowanie 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łe Tradycyjne Ethereum wykorzystuje ściśle szeregowy model do 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 egzekwowania: Monad optymistycznie realizuje wszystkie transakcje równolegle, zakładając, że większość z nich nie ma między sobą konfliktów stanowych. 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. Równoległa analiza obliczeniowa MegaETH W odróżnieniu od pozycjonowania L1 Monad, 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 wykonanie lub modułowy komponent 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 mikromaszyn wirtualnych: Konta są wątkami MegaETH wprowadza model wykonywania "jednej mikro-maszyny wirtualnej na konto", który "łączy się" ze środowiskiem wykonawczym i zapewnia minimalną jednostkę izolacyjną dla równoległego planowania. 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. Asynchroniczne wykonywanie i mechanizmy wywoływania zwrotnego MegaETH jest zbudowany na szczycie paradygmatu programowania asynchronicznego, podobnie jak asynchroniczne przesyłanie wiadomości w modelu aktora, co rozwiązuje problem 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. Koncepcje projektowe zarówno Monady, jak i MegaETH są zupełnie inne niż sharding: sharding poziomo dzieli blockchain na wiele niezależnych podłańcuchów (shardów), a każdy podłańcuch jest odpowiedzialny za część transakcji i stanów, łamiąc limit 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). Analiza obliczeń równoległych Rollup Mesh: Asynchroniczne potokowanie w pełnym cyklu życia: Pharos oddziela różne etapy transakcji (np. konsensus, wykonanie, 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. 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. 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. 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 zkRollup z architekturą wykonywania równoległego GPU, a jej rdzeniem jest refaktoryzacja procesu wykonywania EVM w celu osiągnięcia 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. W chwili obecnej uruchomiony został SDK i udostępniony jest zintegrowany moduł wykonawczy Nazywając siebie "GPU-EVM", GatlingX proponuje bardziej radykalną architekturę, która próbuje przenieść model "szeregowego wykonywania na poziomie instrukcji" tradycyjnych maszyn wirtualnych EVM do natywnych dla GPU równoległych środowisk uruchomieniowych. 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: Rekonstrukcja ontologii wykonywania maszyn wirtualnych Model realizacji EVM Ethereum od początku swojego projektowania przyjął jednowątkową architekturę "pełne zlecenie transakcji + wykonanie szeregowe", 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 równoległego wykonywania z dolnej warstwy 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 implementuje statyczną ocenę konfliktu w oparciu o klasyfikację typu transakcji i obsługuje 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. Podstawowa mechanika: 1. Jawne listy dostępu do konta: Każda transakcja musi deklarować dane konto (odczyt/zapis) podczas przesyłania, aby system mógł określić, czy występuje konflikt statusu między transakcjami. 2. Wykrywanie konfliktów i planowanie wielowątkowe Jeśli zestawy kont nie nakładają się na siebie→ mogą być wykonywane równolegle; Występuje konflikt→ wykonywany szeregowo 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: sterowana 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 w łańcuchu istnieją jako obiekty, z jasną 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 Sui Możliwości Sui w zakresie obliczeń równoległych 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 egzekwowania Block-STM firmy Aptos Aptos 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 realizację transakcji w bloku na trzy etapy: Wykonywanie spekulatywne: Wszystkie transakcje są domyślnie wolne od konfliktów przed wykonaniem, a system planuje transakcje w wielu wątkach dla jednoczesnych prób wykonania i rejestruje stan konta (zestaw odczytu/zapisu), do którego uzyskano 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 przypominająca "jądro systemu operacyjnego", nadająca się do jasnych granic stanu, kontrolowanego handlu o wysokiej częstotliwości i jest stylem inżyniera sprzętu, który powinien działać w łańcuchu 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 Rozszerzenie równoległe zestawu Cosmos SDK 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, mającej na celu obsługę scenariuszy transakcji on-chain o wysokiej częstotliwości i niskich opóźnieniach, takich jak DEX-y księgi zamówień, infrastruktura wymiany w łańcuchu itp. Podstawowy mechanizm równoległy: 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ąskich gardeł jednowątkowych. 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. 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 Paliwo do reformingu modelu UTXO Fuel to wysokowydajna warstwa wykonawcza zaprojektowana w oparciu o modułową architekturę Ethereum, a jej podstawowa równoległość 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 równoległego wykonywania oparty na agencie lub procesie, który różni się od tradycyjnego synchronicznego obliczania globalnego stanu 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), superrównoległy komputer na wierzchu warstwy pamięci masowej AO to zdecentralizowana platforma obliczeniowa działająca w trwałej warstwie pamięci masowej Arweave, której głównym celem jest zbudowanie systemu operacyjnego on-chain, który obsługuje asynchroniczną operację agentów 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), kompleksowa platforma hostingowa Web3 ICP to natywna dla Web3 platforma aplikacji on-chain 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 kanistra (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 równoległe projekty obliczeniowe dla innych paradygmatów modelu aktora można znaleźć w poniższej tabeli: 5. Podsumowanie i perspektywy Opierając się na różnicach między architekturą maszyny wirtualnej a systemem językowym, rozwiązania obliczeń równoległych blockchain można z grubsza podzielić na dwie kategorie: łańcuch równoległego wzmocnienia EVM i natywny łańcuch architektury równoległej (bez 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: Zaimplementuj optymistyczny model wykonywania równoległego zgodny z EVM poprzez odroczony zapis i wykrywanie konfliktów w czasie wykonywania, buduj wykresy zależności po osiągnięciu konsensusu i planuj wykonywanie w wielu wątkach. 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. Do typowych podklas należą: Solana (SVM): Opierając się na roszczeniach o dostęp do konta i statycznym planowaniu wykresów konfliktów, reprezentuje model równoległego wykonywania na poziomie konta. 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): buduje asynchroniczny system mikrojądra on-chain oparty na trwałym środowisku uruchomieniowym agenta sterowanym przez pamięć 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 aktorów 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.

Uwielbiam patrzeć, jak rośnie liczba spotkań społeczności Permabites!

Codzienny Degen - piątek, 18 kwietnia 2025 r. Trendy, pegi, TGE, Tech, Makro, Video, + Nowe Projekty! Pozdrowienia dla wymienionych projektów i tickerów: $DOLO, $ATOM, $sUSD, $BTC, $OL, $WZRD, $AERGO, $T, $EVER, $AO, @GammaSwapLabs, @TradeNeutral, @Lighter_xyz, @jigsawdefi, @PeerlessAI, @VertigoDex, @clickerxyz, @getoro_xyz I pozdrowienia dla kont gigabrain, które mają >10 tys. obserwujących (upewnij się, że je obserwujesz!): @leviathan_news, @robbiepetersen_, @0xlykt, @AresLabs_xyz, @CryptoISFreedom I proszę RT / etc o wsparcie! Link w następnym tweecie 👇