Źródło oryginalne: Gravity

Wprowadzenie

Od uruchomienia Gravity Alpha Mainnet w sierpniu 2024 roku, sieć przetworzyła ponad 275 milionów transakcji, osiągając średni dzienny wolumen transakcji na poziomie 2,6 miliona, a także osiągając 30 milionów G w kosztach transakcji. Wraz z publikacją Litepaper, z niecierpliwością oczekujemy przyszłości tego wysokowydajnego łańcucha EVM. Artykuł ten szczegółowo analizuje Litepaper, pokazując, jak Gravity buduje doskonałą, wysokowydajną architekturę blockchaina Layer-1 dla zastosowań w rzeczywistym świecie.

Gravity jest wysokowydajnym, kompatybilnym z EVM blockchainem Layer-1 stworzonym przez Galxe. Rozwój Gravity wynika z potrzeb rozwojowych Galxe. Platforma Galxe jako największa na świecie platforma dystrybucji na łańcuchu, łączy ogromny ekosystem wielołańcuchowy, przyciągający ponad 25 milionów użytkowników. W swoim ciągłym rozwoju, Galxe stało się zdecentralizowaną superaplikacją, integrującą innowacyjne narzędzia, takie jak Quest, Passport, Score, Compass i Alva, oferując jednocześnie bogate usługi, takie jak punkty lojalnościowe, NFT z wydarzeń, nagrody tokenowe, weryfikacja zk-tożsamości i inteligentne oszczędzanie międzyłańcuchowe. W ciągu tego ciągłego rozwoju, wysoki wolumen transakcji Galxe stał się kluczowym czynnikiem w budowie Gravity — ich system punktów lojalnościowych obsługuje średnio 51,2 transakcji na sekundę, a kampanie nagród tokenowych obsługują średnio 32,1 transakcji na sekundę. To skłoniło nas do zwrócenia się ku blockchainowi EVM, jednocześnie zachowując optymalne doświadczenie użytkownika.

W miarę rozwoju całkowitej łańcuchowości Galxe, dalszy wzrost wolumenu transakcji jest przewidywalny. Oczekuje się, że zapotrzebowanie na przepustowość osiągnie 50 milionów gazu na sekundę, podczas gdy zaspokojenie szerszych potrzeb ekosystemu (takich jak rozliczenia międzyłańcuchowe, transakcje punktów lojalnościowych i rynek NFT) może wymagać zdolności przetwarzania wynoszącej 500 milionów gazu na sekundę. W tym celu Gravity dąży do wsparcia przepustowości na poziomie 1 gigagasa na sekundę, aby spełnić wymagania rozszerzenia dla aplikacji zasobożernych.

W istniejących rozwiązaniach wiele platform osiąga skalowalność poprzez Ethereum, ale okres wyzwań L2 Rollup nieuchronnie prowadzi do opóźnienia transakcji, co nie jest przyjazne dla aplikacji wymagających natychmiastowego potwierdzenia transakcji, takich jak Galxe. Chociaż niektóre DApp próbują zrekompensować opóźnienia poprzez model zaufania lub zewnętrzne monitorowanie, te metody wprowadzają dodatkową złożoność i ryzyko, co jest wyraźnie nieidealne dla kluczowych zastosowań.

W tym kontekście pojawił się Gravity. Gravity, centralizując równoległe EVM, opracowało Grevm, obecnie najszybszy otwarty system wykonania równoległego EVM, co zmniejszyło różnicę wydajności pomiędzy L2 a L1. Ponadto Gravity zmodulowało architekturę Aptos, integrując zweryfikowane komponenty, takie jak Quorum Store i silnik konsensusu AptosBFT. Wykorzystując dojrzałą architekturę Aptos, Gravity unika skomplikowania i potencjalnych ryzyk związanych z rozwojem od podstaw. Ostatecznie Gravity nie tylko zbudowało wysoko wydajny blockchain L1 oferujący pełne doświadczenie łańcucha, ale także wprowadziło pierwsze SDK blockchaina potokowego, znacznie upraszczając proces interakcji dla programistów i użytkowników.

Gravity oferuje bezprecedensową skalowalność, zdolność do decentralizacji i niemal natychmiastową prędkość transakcji. Jego technologia łączy zalety L1 i L2, osiągając 10 000 transakcji na sekundę i poniżej jednej sekundy ostateczności. Dodatkowo, dzięki integracji protokołów restakowania, takich jak EigenLayer i Babylon, Gravity nie tylko zapewnia silne bezpieczeństwo w fazie uruchamiania, ale także zmniejsza długoterminowe ryzyko systemowe związane z poleganiem na jednym aktywie.

W przyszłości Gravity będzie postępować zgodnie z następującą mapą drogową:

· Wprowadzenie etapu 1 Devnet, testowanie wydajności w czasie rzeczywistym;

· Uruchomienie Longevity Testnet, aby zweryfikować długoterminową stabilność sieci;

· Przejście z Gravity Alpha Mainnet do w pełni działającego Gravity Mainnet, aby położyć fundamenty pod szeroką aplikację technologii zdecentralizowanej.

Poniżej znajduje się całość Gravity Litepaper.

Streszczenie

Gravity jest wysokowydajnym, kompatybilnym z EVM blockchainem Layer-1 stworzonym przez Galxe, zaprojektowanym z myślą o aplikacjach na dużą skalę i ekosystemach wielołańcuchowych. Jego cechy obejmują przepustowość 1 gigagasa na sekundę, czas ostatecznego potwierdzenia transakcji poniżej jednej sekundy oraz mechanizm konsensusu PoS oparty na protokołach restakowania. Projekt Gravity opiera się na dwóch głównych komponentach open source: (1) Gravity SDK, będącym opartym na restakowaniu, potokowym silniku konsensusu AptosBFT; (2) Gravity reth, warstwie wykonawczej napędzanej równoległym EVM Grevm (Gravity EVM). Te narzędzia oferują możliwości budowy alternatywnych Layer-1 i efektywnych Layer-2 dla aplikacji Web3, zwłaszcza w kontekście blockchainów EVM. Artykuł ten szczegółowo omawia projekt inżynieryjny Gravity i innowacje technologiczne, pokazując, jak zaspokoić potrzeby wysokiej wydajności poprzez architekturę potoku, zaawansowane algorytmy konsensusu, technики równoległego wykonania oraz zoptymalizowane mechanizmy przechowywania (poprzez ulepszony reth i zmodyfikowany silnik konsensusu Aptos).

Wprowadzenie

Rozwój Gravity wynika z wyzwań, z jakimi Galxe borykało się podczas działalności. Galxe to wiodąca aplikacja Web3, oferująca użytkownikom punkty lojalnościowe, NFT z wydarzeń, nagrody tokenowe, weryfikację tożsamości opartą na zerowej wiedzy oraz wielołańcuchowe inteligentne oszczędzanie. W miarę szybkiego rozwoju Galxe, jego system punktów lojalnościowych przetwarza średnio 51,2 transakcji na sekundę, podczas gdy kampanie nagród tokenowych przetwarzają średnio 32,1 transakcji na sekundę. W trakcie stopniowego decentralizowania backendu Galxe, kluczowe stało się przeniesienie tych przypadków użycia do blockchaina EVM, jednocześnie zapewniając płynne doświadczenie użytkownika.

W tym kontekście wybór istniejącego rozwiązania Layer-2 lub opracowanie nowego Layer-1 jest kluczowym punktem decyzyjnym. Layer-1 osiąga ostateczność za pomocą algorytmu konsensusu, natomiast Layer-2 rozwiązuje ten problem za pomocą protokołu Rollup. Istnieje kompromis: Layer-1 zazwyczaj poświęca część przepustowości z powodu ograniczeń algorytmu konsensusu, ale może osiągnąć szybsze ostateczne potwierdzenie transakcji. Na przykład algorytm konsensusu oparty na AptosBFT może potwierdzić transakcje w czasie poniżej jednej sekundy, podczas gdy optymistyczny Rollup może mieć okres wyzwań trwający nawet do siedmiu dni. Chociaż dowody zerowej wiedzy mogą przyspieszyć ten proces, ostateczne potwierdzenie nadal może zająć kilka godzin. Biorąc pod uwagę wymagania Gravity dotyczące ostatecznego potwierdzenia w czasie poniżej jednej sekundy (szczególnie w przypadku ich protokołu z pełnym zamiarem łańcucha), zdecydowaliśmy się na budowę Layer-1.

Pomimo że Layer-2 ma wrodzone zalety w komunikacji z Ethereum, warstwa 1, taka jak Gravity, może dzięki protokołowi zamiarów Gravity i mostom międzyłańcuchowym, osiągnąć głęboką interoperacyjność z Ethereum i innymi blockchainami. Taki projekt nie tylko bezproblemowo współpracuje z Ethereum, ale także zwiększa łączność całego ekosystemu Web3.

Ponadto protokoły restakowania znacznie ułatwiają budowę blockchaina PoS Layer-1. Gravity, korzystając z protokołów takich jak EigenLayer i Babylon, integruje stakowane aktywa Ethereum i Bitcoin oraz ich rozległą sieć weryfikatorów. To zapewnia ekonomiczne zabezpieczenie dla konsensusu PoS, umożliwiając Gravity osiągnięcie poziomu decentralizacji i bezpieczeństwa porównywalnego z Ethereum.

Podsumowując, Gravity zostało zbudowane jako wysoko wydajny, kompatybilny z EVM blockchain Layer-1, aby spełnić wymagania skalowalności i wydajności nowoczesnych aplikacji Web3. Choć jego pierwotnym celem było wsparcie Galxe, elastyczna struktura oferowana przez Gravity SDK i Grevm (Gravity EVM) nadaje się do budowy każdego Layer-1 i efektywnego Layer-2, funkcjonując podobnie do Tendermint/Cosmos SDK.

Potrzebujemy przepustowości 1 gigagasa/s

Dla blockchaina, przepustowość jest najważniejszym wskaźnikiem wydajności, zazwyczaj mierzonym liczbą transakcji na sekundę (TPS) lub ilością używanego gazu na sekundę (gaz/s). Na przykład system punktów lojalnościowych Galxe wymaga co najmniej 4 milionów gazu/s, aby działać stabilnie. Ta liczba pochodzi z przeciętnego zużycia gazu 80 000 dla każdej transakcji punktów lojalnościowych, przy czym można przetwarzać około 51,2 transakcji na sekundę.

To przewidywanie zostało potwierdzone przez dane z Gravity Alpha Mainnet. Jako nasza sieć Layer 2 w testach, transakcje punktów lojalnościowych Gravity Alpha Mainnet wykazały stabilną przepustowość na poziomie 4 milionów gazu/s, potwierdzając dokładność powyższych oszacowań.

Chociaż wysokie koszty operacji na łańcuchu mogą prowadzić do niewielkiego spadku popytu, trend ekspansji Galxe pokazuje, że w szczytowych okresach zapotrzebowanie może wzrosnąć do dwóch lub trzech razy obecnego poziomu. Ponadto, w miarę dodawania innych scenariuszy zastosowań, takich jak NFT, nagrody tokenowe oraz wsparcie dla pełnych zadań łańcucha w przyszłości oparte na dowodach zerowej wiedzy, jeśli Galxe stanie się całkowicie łańcuchowy, przewiduje się, że zapotrzebowanie na przepustowość osiągnie 50 milionów gazu/s. Zakładając, że wykorzystanie gazu w aplikacjach na łańcuchu Gravity będzie podążać za rozkładem Pareto (analogicznie do Uniswap, który od zawsze konsumuje 10% gazu Ethereum), aby zaspokoić szersze potrzeby ekosystemu, takie jak rozliczenia międzyłańcuchowe, transakcje punktów lojalnościowych i rynek NFT, idealnie powinno wspierać przepustowość na poziomie 500 milionów gazu/s. Dlatego, aby zaspokoić te potencjalne wymagania, blockchain musi mieć zdolność przetwarzania na poziomie 1 gigagasa/s, aby zapewnić, że może dostosować się do potrzeb rozwoju aplikacji zasobożernych.

Aby osiągnąć tak wysoką przepustowość, kluczowe jest wprowadzenie równoległego EVM. Opracowaliśmy Grevm, obecnie najszybszy otwarty system wykonawczy równoległego EVM, szczegółowe osiągi będą opisane w następnych rozdziałach.

Czas potwierdzenia poniżej jednej sekundy

Oprócz przepustowości, szybkość potwierdzenia transakcji jest również kluczowa dla doświadczeń użytkowników. Wsp współcześni użytkownicy przyzwyczaili się do niemal natychmiastowej reakcji, co wciąż stanowi wyzwanie dla blockchainów. Przykład Galxe jest podobny do całkowicie łańcuchowej gry, która wymaga niskiej latencji. Obecnie czas potwierdzenia transakcji w większości blockchainów EVM wynosi od kilku sekund do kilku dni, co zdecydowanie nie spełnia tych wymagań. Wybraliśmy algorytm konsensusu AptosBFT, aby osiągnąć czas potwierdzenia poniżej jednej sekundy.

Chociaż L2 Rollup teoretycznie może zwiększyć przepustowość, ich okres wyzwań prowadzi do opóźnienia transakcji, co jest bardzo niekorzystne dla aplikacji wymagających natychmiastowego potwierdzenia transakcji (takich jak Galxe). Choć niektóre DApp próbują to zoptymalizować za pomocą modelu zaufania lub zewnętrznego monitorowania, wprowadza to dodatkową złożoność i ryzyko, co jest nieidealne dla kluczowych zastosowań. Gravity SDK poprzez zaprojektowanie pięcioetapowego potoku zrównoleglił procesy konsensusu i wykonania, skracając różnice wydajności między L2 a L1 (szczegółowy projekt przedstawiony jest poniżej).

Bezpieczeństwo PoS oparte na restakowaniu

Gravity SDK oferuje bezpieczny sposób na rozszerzenie Ethereum, nie ograniczając się do L2 Rollup, ale wybierając architekturę L1 chronioną poprzez restakowanie, aby zrównoważyć wydajność, interoperacyjność i bezpieczeństwo. Główne moduły integrują protokoły restakowania, takie jak EigenLayer i Babylon, zapewniając wsparcie dla zaufania ekonomicznego, aby zapewnić solidność konsensusu opartego na dowodzie stawki.

Dzięki 45 miliardom dolarów stakowanych aktywów Ethereum i 850 000 weryfikatorów, a także 600 miliardom dolarów aktywów dostosowanych do Bitcoina przez Babylon, Gravity od samego początku może budować solidne podstawy bezpieczeństwa, unikając częstych problemów związanych z uruchomieniem nowego blockchaina oraz ryzyk bezpieczeństwa, jednocześnie zmniejszając długoterminowe ryzyko systemowe związane z poleganiem na pojedynczym aktywie.

Architektura Gravity Chain

Gravity Chain składa się z dwóch głównych komponentów: Gravity SDK i Gravity reth. Gravity SDK to udoskonalona struktura blockchaina oparta na łańcuchu Aptos, który jest obecnie najnowocześniejszym blockchainem PoS opartym na rodzinie algorytmów konsensusu HotStuff, którego architektura potoku znacznie zwiększa przepustowość i efektywność zasobów. Gravity reth to warstwa wykonawcza oparta na reth, działająca jako reaktor strumieni bloków (BSR), służąca do odbierania propozycji bloków z warstwy konsensusu. Poprzez optymalizację reth, Gravity reth osiągnęło równoległe wykonanie, asynchroniczne obliczenia skrótów stanu oraz poprawę efektywności przechowywania. Te dwa komponenty są ściśle powiązane poprzez interfejs silnika konsensusu Gravity (GCEI) i adapter reth, dynamicznie zarządzane przez kontroler potoku na każdym etapie.

Projekt ten oddziela wykonanie bloku od konsensusu bloku, czyniąc warstwę wykonawczą konsumentem proponowanych bloków. Nasza optymalizacja reth sprawia, że doskonale pasuje do procesu proponowania bloków zarządzanego przez reaktor strumieni bloków (BSR).

Proces transakcji Gravity Chain jest następujący:

1. Transakcja jest przesyłana przez interfejs JSON RPC Gravity reth, który jest w pełni zgodny z Ethereum.

2. Następnie transakcja trafia do puli pamięci Gravity SDK i jest rozprzestrzeniana w sieci, weryfikatorzy przetwarzają transakcje w partiach i generują certyfikat Quorum Store (QS).

3. Każda runda liderów składa propozycję bloku, zawierającą metadane bloku i uporządkowane transakcje wybrane z puli pamięci i QS.

4. Po oznaczeniu jako uporządkowane, propozycje trafią do warstwy wykonawczej.

5. Warstwa wykonawcza Grevm równolegle przetwarza transakcje, generując wyniki wykonania i przekazując nowy stan do modułu zarządzania stanem.

6. Moduł stanu oblicza korzeń stanu i przekazuje go do silnika konsensusu w celu osiągnięcia konsensusu korzenia stanu.

7. Po ostatecznym potwierdzeniu korzenia stanu, moduł przechowywania utrwala korzeń stanu i dane bloku.

Następne rozdziały szczegółowo opiszą każdy komponent.

Gravity SDK: Innowacyjna praktyka otwartego blockchaina potokowego

Gravity SDK to modularna, otwarta struktura blockchaina oparta na produkcji gotowego łańcucha Aptos. Jej celem jest zmodulowanie architektury Aptos, korzystając z zweryfikowanych komponentów, takich jak Quorum Store i silnik konsensusu AptosBFT, aby stworzyć pierwsze SDK blockchaina potokowego.

Powody, dla których Gravity SDK wybiera Aptos jako bazę, obejmują:

· Najwyższa architektura technologiczna: Aptos to zaawansowany blockchain PoS oparty na konsensusie rodziny HotStuff.

· Ekstremalne osiągi: Aptos oferuje przepustowość 160 000 transakcji na sekundę, a czas ostatecznego potwierdzenia wynosi poniżej jednej sekundy.

· Niezawodność w praktyce: Aptos wykazał się doskonałą stabilnością i wydajnością w środowisku produkcyjnym.

· Unikaj powielania wysiłków: Wykorzystanie dojrzałej architektury Aptos pozwala uniknąć złożoności i potencjalnych ryzyk związanych z rozwojem od podstaw, podczas gdy inne próby przewyższenia Aptos zazwyczaj nie są wystarczająco teoretyczne ani praktyczne.

· Korzyści z synergii: W miarę rozwoju Aptos, Gravity SDK może bezproblemowo integrować nowe funkcje, takie jak API losowych liczb, jednocześnie wspierając Aptos poprzez modularną architekturę i innowacyjne mechanizmy bezpieczeństwa.

Blockchain oparty na Gravity SDK łączy się z potokowym silnikiem konsensusu za pośrednictwem interfejsu Gravity Consensus Engine Interface (GCEI). Choć GCEI jest zgodny z wieloma warstwami wykonawczymi, Gravity SDK obecnie obsługuje głównie Gravity reth. Szczegóły dotyczące GCEI zostaną omówione w kolejnych rozdziałach.

Gravity Consensus Engine Interface (GCEI)

Protokół GCEI (Gravity Consensus Execution Interface) jest mostem komunikacyjnym między warstwą konsensusu a warstwą wykonawczą. Normuje interakcje między tymi dwiema warstwami, zapewniając synchroniczność procesów konsensusu i wykonania przez kontroler potoku.

Główna różnica między klasycznymi SDK blockchaina a Gravity SDK leży w jego zintegrowanym silniku konsensusu potokowego. Warstwa wykonawcza musi być zaimplementowana jako reaktor strumieni bloków (Block Stream Reactor), co oznacza, że musi być w stanie nieprzerwanie konsumować proponowany strumień bloków, a obietnica stanu musi być obliczana asynchronicznie w stosunku do wykonania transakcji. Ponadto warstwa wykonawcza musi być w stanie dostarczyć sygnał przeciążenia do warstwy konsensusu, aby dynamicznie dostosować tempo proponowania bloków.

Ponadto, z uwagi na cechy potoku Gravity SDK, warstwa wykonawcza musi być w stanie obsługiwać niewykonalne transakcje w zaproponowanym bloku, ponieważ pula pamięci nie może ściśle weryfikować żadnej transakcji z powodu braku dostępu do najnowszego stanu świata: wykonanie może być nadal w toku. Jednocześnie wyniki wykonania nie powinny blokować generowania kolejnych bloków, ponieważ po tym, jak Gravity SDK zrównoleglił konsensus bloków z konsensusem stanu, warstwa wykonawcza stała się reaktorem strumienia proponowanych bloków, który może swobodnie zwracać wyniki wykonania w kolejnych etapach.

Protokół GCEI definiuje dwie grupy API:

· API warstwy konsensusu: Te API są realizowane przez Gravity SDK, aby warstwa wykonawcza mogła odpowiadać na propozycje bloków silnika konsensusu i składać obietnice stanu.

· API warstwy wykonawczej: Te API muszą być zaimplementowane przez warstwę wykonawczą. Silnik konsensusu będzie korzystał z tych API, aby zweryfikować wysiłki przed zaproponowaniem transakcji do bloku, zrealizować płynność zaproponowanego bloku i powiadomić warstwę wykonawczą o ostatecznym zatwierdzeniu stanu.

Z perspektywy cyklu życia transakcji, protokół GCEI definiuje następujące elementy:

1. check_txn (API warstwy wykonawczej)

· Wejście: Odbiera transakcję (GTxn) jako wejście.

· Wyjście: Zwraca adres nadawcy transakcji, nonce oraz limit gazu.

Zastosowanie: Ta metoda służy do tego, aby silnik konsensusu przeprowadzał weryfikację starań przed zaproponowaniem transakcji do bloku. Metoda ta może być wywoływana wielokrotnie dla tej samej transakcji, na przykład, gdy transakcja trafia do puli pamięci, przed zaproponowaniem do bloku oraz przy ostatecznym zatwierdzeniu obietnicy stanu.

2. submit_txn (API warstwy konsensusu)

Wejście: Odbiera transakcję (GTxn) z warstwy wykonawczej.

Wyjście: Zwraca Result<(), wskazując, czy transakcja została pomyślnie dodana do puli pamięci.

Zastosowanie: Warstwa wykonawcza może wykorzystać tę metodę do przesyłania transakcji do puli pamięci. Silnik konsensusu następnie rozprzestrzeni tę transakcję w sieci i utworzy Quorum Store po otrzymaniu zbioru transakcji.

3. recv_ordered_block (API warstwy wykonawczej)

Wejście: Odbiera uporządkowany blok (typ BlockBatch), zawierający uporządkowane transakcje i metadane bloków.

Wyjście: Zwraca Result<(), wskazując, czy warstwa wykonawcza pomyślnie odebrała i zaakceptowała ten blok.

Zastosowanie: Gdy silnik konsensusu zaproponuje blok, jest on wysyłany do warstwy wykonawczej w celu wykonania transakcji. Ta metoda pozwala warstwie wykonawczej na odbieranie i przetwarzanie proponowanych bloków.

4. update_state_commitment (API warstwy konsensusu)

Wejście: Obietnica stanu dla danej numeracji bloku (StateCommitment).

Wyjście: Zwraca Result<(), wskazując, czy obietnica stanu została pomyślnie zaakceptowana przez lokalny silnik konsensusu.

Zastosowanie: Po obliczeniu obietnicy stanu przez warstwę wykonawczą, jest ona wysyłana do warstwy konsensusu w celu ostatecznego zatwierdzenia, a więc osiągnięcia lekkiego konsensusu 2f+1 z innymi weryfikatorami. Jeśli konsensus obietnicy stanu i postęp proponowanego bloku są zbyt rozbieżne, kontroler potoku dostosuje tempo proponowania bloków.

5. commit_block_hash (API warstwy wykonawczej)

Wejście: Odbiera wektor block_ids, reprezentujący bloki, które mają zostać przesłane.

Wyjście: Zwraca Result<(), wskazując, czy operacja się powiodła.

Zastosowanie: Gdy obietnica stanu zostanie ostatecznie zatwierdzona, warstwa konsensusu powiadomi warstwę wykonawczą, aby złożyła skrót bloku do pamięci.

Potok blockchaina

Gravity SDK maksymalizuje wykorzystanie zasobów sprzętowych poprzez architekturę pięcioetapowego potoku, aby osiągnąć wyższą przepustowość i mniejsze opóźnienia. Potok przeplata wykonywanie zadań pomiędzy różnymi blokami, a menedżer potoku korzysta z mechanizmu sprzężenia zwrotnego, aby zapewnić stabilny postęp blockchaina. Pierwsze trzy etapy należą do warstwy konsensusu, a dwa ostatnie do warstwy wykonawczej.

Każdy etap wyjaśniony jest poniżej:

· Etap 1: Rozpowszechnianie transakcji: Ten etap skutecznie rozprzestrzenia transakcje między weryfikatorami, zapewniając ich terminowe i niezawodne uwzględnienie w trakcie budowy bloku. W projekcie oddzielono rozprzestrzenianie transakcji od mechanizmu konsensusu, stosując ideę Narwhal & Tusk oraz Aptos, polegając na tym, że weryfikatorzy ciągle dzielą się partiami transakcji, wykorzystując wszystkie zasoby sieci do równoległego działania. Gdy partia transakcji otrzymuje 2f+1 podpisów wagowych (tworząc PoAv, czyli dowód dostępności), zapewnia, że ta partia transakcji jest przechowywana przez co najmniej f+1 uczciwych weryfikatorów, co pozwala wszystkim uczciwym weryfikatorom na ich pobranie w celu wykonania.

· Etap 2: Sortowanie metadanych bloków: Ten etap ustala spójną i uznaną kolejność transakcji i metadanych bloków w sieci. Mechanizm konsensusu (AptosBFT) stosuje zasady podwójnego łańcucha (2-chain rule), aby zapewnić odporność bułgarską na bloki. Bloki następnie przechodzą do etapu wykonania, aby przygotować się do przetwarzania równoległego.

· Etap 3 (BSR): Równoległe wykonanie transakcji: Ten etap należy do warstwy wykonawczej, w tej fazie transakcje są wykonywane równolegle. Wyniki wykonania zostaną przekazane do etapu obietnicy stanu.

· Etap 4: Obietnica stanu: Ten etap kończy zmiany stanu wywołane wykonaniem transakcji i przygotowuje blok do ostatecznego zatwierdzenia. Obietnica stanu jest obliczana asynchronicznie w stosunku do wykonania transakcji, co zapewnia, że wykonanie następnego bloku nie jest blokowane przez aktualne zgłoszenie stanu.

· Etap 5: Utrwalenie stanu: Ten etap utrwala zatwierdzone zmiany stanu w pamięci blockchaina. Ostateczny korzeń stanu oraz powiązane dane są przechowywane w Gravity Store, które korzysta z wysoko zoptymalizowanego silnika przechowywania, zaprojektowanego do szybkiego dostępu i niezawodności. Równocześnie informuje pulę pamięci i Quorum Store o usunięciu transakcji, które nie będą mogły być uwzględnione w przyszłości.

Moduły stakowania i restakowania

Zbudowanie bezpiecznego blockchaina Layer 1 opartego na dowodzie stawki (PoS) jest skomplikowanym zadaniem, szczególnie w przypadku polegania wyłącznie na specyficznych tokenach stakowanych na łańcuchu. Podejście to może napotkać problemy z ekonomiczną bezpieczeństwem na wczesnym etapie, takie jak wahania wartości tokenów czy ograniczona aktywność weryfikatorów. Aby rozwiązać ten problem, Gravity SDK oferuje elastyczny moduł stakowania i restakowania, który ma na celu zwiększenie bezpieczeństwa sieci poprzez lokalne i zewnętrzne mechanizmy stakowania.

Jedną z kluczowych strategii Gravity SDK jest wprowadzenie protokołów restakowania, takich jak EigenLayer i Babylon. Te protokoły pozwalają weryfikatorom na restakowanie aktywów z innych dojrzałych sieci (takich jak Ethereum i Bitcoin), co umożliwia wykorzystanie ich istniejącego zabezpieczenia. Umożliwiając weryfikatorom stakowanie aktywów z tych łańcuchów, Gravity SDK jest w stanie zwiększyć bezpieczeństwo ekonomiczne sieci, nie polegając całkowicie na lokalnych tokenach. To podejście nie tylko wzmacnia odporność łańcucha, ale także promuje różnorodność ekosystemu weryfikatorów. Projekt modułu stakowania koncentruje się na modularności, a jego komponent restakowania charakteryzuje się wysoką elastycznością, umożliwiającą łatwe dostosowanie się do nowych protokołów restakowania w miarę ewolucji ekosystemu blockchain.

Moduł ten obsługuje nie tylko aktywa Restaking, ale także stakowanie niestandardowych tokenów ERC20 na łańcuchu, takich jak G Token na Ethereum. Weryfikatorzy mogą uczestniczyć w konsensusie, stakując dozwolone tokeny, przyczyniając się do bezpieczeństwa sieci. Prawo do głosowania weryfikatorów oblicza się na podstawie ich całkowitej wartości stakowania, w tym aktywów z niestandardowych tokenów i protokołu restakowania. To obliczenie odbywa się zgodnie z konkretną konfiguracją łańcucha, zapewniając, że każdy łańcuch może elastycznie ustalać zasady stakowania i restakowania zgodnie z własnymi potrzebami.

Zarządca epok w silniku konsensusu współpracuje bezpośrednio z modułem stakowania w celu obliczenia wagi zbioru weryfikatorów na następną rundę. Uzyskuje wartości stakowania z warstwy wykonawczej, aby zapewnić, że proces konsensusu dokładnie odzwierciedla najnowszą dynamikę stakowania. W tej architekturze aktywa międzyłańcuchowe (na przykład stakowane aktywa z Ethereum) muszą być najpierw mostkowane do warstwy wykonawczej, zanim będą mogły być wykorzystywane do obliczenia całkowitego stakowania weryfikatorów. Wykonanie mechanizmu mostkowania jest odpowiedzialne za warstwę wykonawczą, co pozwala na bardziej elastyczne zarządzanie komunikacją międzyłańcuchową. Możliwe rozwiązania obejmują mosty PoS, dowody zerowej wiedzy dotyczące stanu łańcucha oraz wbudowane autonomiczne wiadomości międzyłańcuchowe.

Więcej szczegółów technicznych, projektów API oraz pełne wyjaśnienie mechanizmów stakowania i restakowania będą szczegółowo opisane w kolejnych dokumentach.

Gravity Reth: warstwa wykonawcza reaktora strumieni bloków EVM

Integracja warstwy wykonawczej maszyny wirtualnej Ethereum (EVM) w architekturze Gravity SDK stwarza unikalne wyzwania, szczególnie w zakresie w pełni wykorzystania możliwości silnika konsensusu potokowego. Aby uzyskać bezproblemową integrację i w pełni wykorzystać potencjał tej architektury, musimy przeprowadzić wiele kluczowych optymalizacji w otwartym kliencie Ethereum, reth. Te optymalizacje zasadniczo przekształcają reth w Gravity reth, potokową, zoptymalizowaną warstwę wykonawczą EVM dostosowaną do silnika konsensusu potokowego.

Tradycyjna architektura blockchaina przetwarza bloki sekwencyjnie, zapewniając, że każdy blok jest w pełni weryfikowany i wykonywany przed zaproponowaniem następnego bloku. Jednak Gravity SDK przyjęło mechanizm konsensusu potokowego, oddzielając różne etapy przetwarzania bloków w celu zwiększenia wydajności. Ta zmiana paradygmatu wprowadza złożoność:

Nieoczekiwane transakcje: W łańcuchu potokowym, ponieważ wykonanie poprzednich bloków może jeszcze nie zostać zakończone, pula pamięci nie ma dostępu do najnowszego stanu świata. Dlatego transakcje zawarte w proponowanym bloku mogą nie być wykonalne w momencie proponowania, ponieważ ich ważność nie może zostać ściśle zweryfikowana bez najnowszego stanu.

Nieblokujące wyniki wykonania: Aby zapobiec zatorom w potoku, wyniki wykonania nie powinny blokować generowania kolejnych bloków. Warstwa wykonawcza musi być w stanie asynchronicznie przetwarzać proponowane bloki i zwracać wyniki wykonania na późniejszych etapach bez zakłócania procesu konsensusu. Dla EVM oznacza to konieczność redefiniowania hash bloku, eliminując zależność od pola stateRoot w nagłówku bloku.

Aby rozwiązać te problemy, wprowadziliśmy cztery kluczowe optymalizacje:

· Reaktor strumieni bloków (Block Stream Reactor, BSR): BSR ma na celu dostosowanie reth do procesu proponowania bloków Gravity SDK. Umożliwia to warstwie wykonawczej ciągłe konsumowanie proponowanego strumienia bloków, działając jako reaktor do asynchronicznego przetwarzania bloków. BSR tworzy dynamiczną pętlę sprzężenia zwrotnego z silnikiem konsensusu, łącząc odpowiednie sygnały przeciążenia. Te sygnały na bieżąco dostosowują tempo proponowania bloków i zgłaszania stanu, w zależności od przepustowości i opóźnienia warstwy wykonawczej. Jeśli z powodu złożonych transakcji lub ograniczeń zasobów warstwa wykonawcza spowolni, mechanizm przeciążenia zmniejszy tempo proponowania bloków, aby zapewnić stabilność systemu.

· Dekompozycja zgłoszeń stanu i wykonania transakcji: Druga optymalizacja dotyczy rozdzielenia obliczeń zgłoszeń stanu od wykonania transakcji. Poprzez dekompozycję tych procesów, osiągamy asynchroniczność obliczeń zgłoszeń stanu, co pozwala na wykonanie kolejnych bloków bez oczekiwania na zakończenie zgłoszenia stanu bieżącego bloku. Zdefiniowaliśmy na nowo hash bloku, eliminując zależność od pola stateRoot w nagłówku bloku, co zapewnia, że obliczenie korzenia stanu nie blokuje generowania kolejnych bloków.

· Optymalizacja warstwy przechowywania: W strukturze potoku efektywne buforowanie i trwałość wielowersyjnych wartości stanu oraz zgłoszeń stanu są kluczowe. Trzecia optymalizacja koncentruje się na wzmocnieniu warstwy przechowywania, aby spełnić te potrzeby bez wprowadzania wąskich gardeł. Poprzez optymalizację mechanizmów przechowywania, zapewniamy szybkie zapisywanie danych stanu oraz ich wysoką równoległość w dostępie. Obejmuje to budowę silnika przechowywania wielowersyjnego oraz wsparcie dla asynchronicznego I/O od bazy danych do API przechowywania.

· Równoległe EVM: Ostatnia optymalizacja dotyczy równoległej egzekucji transakcji wewnątrz EVM. Opracowaliśmy Grevm, równoległe środowisko wykonawcze EVM, które znacząco przyspiesza przetwarzanie transakcji poprzez równoległe wykonanie. Grevm wykorzystuje dane uzyskane z symulacji transakcji, aby zoptymalizować równoległe wykonanie, zmniejszając powtórne wykonanie transakcji i zwiększając przepustowość.

Grevm (Gravity EVM) - równoległe wykonanie EVM

Grevm to projekt open source, hostowany na GitHubie (jeśli jeszcze nie został otwarty, w przyszłości zostanie otwarty). Proszę zapoznać się z jego README w celu uzyskania dodatkowych informacji.

Grevm (Gravity EVM) jest oparty na revm, otwartym środowisku wykonawczym równoległego EVM. Algorytm Grevm czerpie inspirację z BlockSTM, a jego wydajność została wzmocniona przez wprowadzenie grafów zależności danych uzyskanych z symulacji transakcji. Mechanizm ten sprawia, że harmonogram równoległej egzekucji jest bardziej efektywny, minimalizując potrzebę ponownego wykonywania transakcji.

W naszych testach porównawczych Grevm jest obecnie najszybszą otwartą implementacją równoległego EVM. Dla transakcji bez kolizji Grevm jest 4,13 razy szybszy od wykonania sekwencyjnego, osiągając prędkość 26,50 gigagasa/s. Jeśli symulujemy rzeczywisty 100 μs opóźnienie I/O, jego prędkość wynosi 50,84 razy wykonanie sekwencyjne, przy przepustowości 6,80 gigagasa/s. Ta skokowa poprawa wydajności jest wynikiem integracji równoległego wykonania z asynchronicznymi operacjami I/O — równoległość umożliwia efektywne nakładanie operacji I/O, co dodatkowo przyspiesza.

Główna idea Grevm polega na wykorzystaniu zależności danych między transakcjami, poprzez hipotetyczne zbiory odczytu/zapisu transakcji, aby zoptymalizować równoległe wykonanie. Mimo że nie wszystkie wskazówki są całkowicie dokładne, te oparte na symulacji są zazwyczaj wystarczająco praktyczne. Na przykład, na głównym łańcuchu Ethereum, według historii użycia gazu, około 30% transakcji to proste przelewy Ether, a kolejne 25%-30% to przelewy tokenów ERC20, a te transakcje zazwyczaj dotyczą odczytu i zapisu ograniczonej liczby kont i miejsc przechowywania. Dla tych transakcji wyniki symulacji wykazują spójną dokładność.

Na podstawie tych spostrzeżeń opracowaliśmy dla Grevm trzyetapową strukturę równoległego wykonania, jako kontynuację modelu Block-STM, łączącą dane zależności uzyskane z symulacji transakcji:

· Etap 1: Generowanie wskazówek i wstępne ładowanie stanu — symulacja transakcji w celu zebrania wskazówek zależności i wstępnego załadowania pamięci podręcznej. Etap ten można przeprowadzać w różnych momentach, w zależności od projektu blockchaina. Na przykład, gdy nowa transakcja dociera do puli pamięci, symulacja może być natychmiast uruchomiona, aby przygotować wskazówki zależności.

· Etap 2: Analiza zależności — przekształcenie zebranych wskazówek zależności w skierowany acykliczny graf (DAG), reprezentujący zależności między transakcjami. Ten DAG służy do planowania harmonogramu transakcji w kolejnych równoległych wykonaniach.

· Etap 3: Równoległe wykonanie pod presją — równoległe wykonywanie transakcji przy użyciu zmodyfikowanego algorytmu BlockSTM opartego na zależności DAG. Program harmonogramu nie wybiera już transakcji ściśle według numeru sekwencyjnego w bloku (takiego jak 1, 2, 3, ..., n), lecz priorytetowo wybiera transakcje według DAG, aby zminimalizować konflikty i ograniczyć potrzebę ponownego wykonania.

Asynchroniczne obliczenia skrótów wsadowych

Generowanie zgłoszenia stanu pozostaje kluczowym wąskim gardłem w potoku blockchaina, wynikającym z zasadniczej sekwencyjności Merkle. Każde obliczenie poddrzewa musi zakończyć się przed wygenerowaniem ostatecznego zgłoszenia stanu, co prowadzi do znacznych opóźnień. Mimo że istniejące rozwiązania (takie jak równoległość na poziomie konta reth) wprowadziły pewien stopień równoległości, wciąż istnieje wiele możliwości optymalizacji. W kontekście warstwy wykonawczej reaktora strumieni bloków (BSR) Gravity reth, dekompozycja konsensusu zgłoszenia stanu i wykonania transakcji umożliwia asynchroniczne opóźnione i wsadowe obliczenia zgłoszenia stanu bez blokowania wykonania.

Aby rozwiązać te problemy, zaproponowana struktura wprowadza następujące kluczowe innowacje:

Asynchroniczne obliczenia skrótów wsadowych: Wykorzystując dekompozycję konsensusu stanu i wykonania transakcji, ta struktura umożliwia asynchroniczne obliczenia skrótu stanu. Aktualizacje korzenia stanu są przeprowadzane w partiach (na przykład co 10 bloków), aby zmniejszyć częstotliwość obliczeń korzenia stanu. Ta metoda przetwarzania wsadowego osiąga efektywne obliczenia skrótów poprzez agregację współdzielonych brudnych węzłów, minimalizując koszty aktualizacji i obniżając ogólne koszty obliczeniowe. W przypadku małych bloków przetwarzanie wsadowe może znacząco zwiększyć równoległość; w przypadku dużych bloków może zredukować ogólne koszty obliczeniowe.

Całkowita równoległość: Ta struktura rozszerza równoległość na całe drzewo stanu, a nie tylko na pojedyncze drzewo konta. Dla węzłów oznaczonych jako „brudne”, struktura wykorzystuje równoległy algorytm obliczania stanu, dzieląc drzewo na niezależne poddrzewa i równolegle przetwarzając te poddrzewa. Wyniki są agregowane na najwyższym poziomie w celu efektywnego obliczenia ostatecznego korzenia. Takie podejście zapewnia, że duże bloki z dużą liczbą transakcji i zmian stanu mogą w pełni korzystać z wielowątkowości, maksymalizując przepustowość.

Alternatywne szybkie korzenie stanu: Aby dostosować się do nagłówków bloków Ethereum i operacji kodowych BLOCKHASH (które wymagają dostępu do korzeni stanu ostatnich 256 bloków), zdefiniowaliśmy na nowo korzeń stanu. W przeciwieństwie do uzależnienia od ostatecznego zgłoszenia stanu (niedostępnego podczas wykonywania transakcji), obliczamy korzeń stanu jako połączenie zestawu zmian bloków z poprzednim korzeniem stanu. Ta metoda sprawia, że obliczenie korzenia stanu jest szybsze, eliminując potrzebę oczekiwania na zakończenie pełnego zatwierdzenia stanu.

Gravity Store

Aby zaspokoić wymagania blockchainów o wysokiej wydajności w zakresie zarządzania danymi na dużą skalę, Gravity Store powstało jako zoptymalizowana warstwa przechowywania wielowersyjnego. Jest to oparte na projekcie reth, który już zmniejsza problem rozrostu stanu poprzez rozdzielenie przechowywania zgłoszeń stanu i danych stanu, jednocześnie obniżając koszty odczytu i zapisu danych. Jednak warstwa wykonawcza Gravity reth wymaga dalszego wsparcia dla przetwarzania równoległego i asynchronicznego zgłaszania stanu, co stawia dodatkowe wymagania technologiczne.

Aby rozwiązać te wyzwania, Gravity Store wprowadził efektywną strukturę drzewa wielowersyjnego, dostosowaną specjalnie do naszej architektury BSR (Block Stream Reactor). Ta struktura drzewa wspiera zarządzanie wielowersyjnymi aktualizacjami stanu. W przeciwieństwie do tradycyjnego podejścia, polegającego na natychmiastowej aktualizacji wartości skrótu, Gravity Store oznacza zmodyfikowane węzły jako „brudne węzły”, co pozwala na opóźnione przetwarzanie skrótu i wykonywanie w partiach. Takie podejście umożliwia szybkie tworzenie nowych wersji, efektywne zapytania dotyczące danych w określonej wersji oraz oczyszczanie starych wersji poniżej określonej wysokości, znacznie poprawiając wydajność zarządzania stanem blockchaina.

Pracujemy również nad niezależnym silnikiem przechowywania Gravity DB, którego celem jest dostarczenie zoptymalizowanej warstwy przechowywania dla aplikacji blockchainowych oraz wsparcie dla w pełni asynchronicznych operacji I/O. Projekt tego silnika inspirowany jest LETUS, wysokowydajnym silnikiem ogólnodostępnej bazy danych o strukturze logów, skierowanym na blockchain. Nasz główny programista Richard, jako jeden z głównych autorów LETUS, szczegółowo omówi jego projekt w nadchodzącym artykule na blogu.

Wnioski

Gravity Chain to wysokowydajny, kompatybilny z EVM blockchain Layer-1, zaprojektowany w celu spełnienia wymagań skalowalności i wydajności nowoczesnych aplikacji web3. W połączeniu z Gravity SDK, potokowym silnikiem konsensusu AptosBFT oraz warstwą wykonawczą Gravity reth napędzaną Grevm, Gravity osiąga przepustowość 1 gigagasa na sekundę, czas potwierdzenia transakcji poniżej jednej sekundy oraz bezpieczeństwo PoS oparte na mechanizmie restakowania. Te komponenty technologiczne stanowią solidną podstawę do tworzenia niestandardowych alternatywnych blockchainów L1 lub bardziej efektywnych rozwiązań L2 dla aplikacji web3, szczególnie w kontekście wykorzystania blockchainów EVM.

Artykuł ten pochodzi z przesyłki i nie reprezentuje poglądów BlockBeats.