Původní text: Gravity
Úvod
Od spuštění Gravity Alpha Mainnet v srpnu 2024 zpracovala síť více než 275 milionů transakcí, s průměrným denním objemem až 2,6 milionu transakcí a úspěšně dosáhla 30 milionů G transakčních poplatků. S vydáním Litepaper jsme plní očekávání ohledně budoucího plánu této vysoce výkonné EVM chain. Tento článek se podrobně zabývá Litepaperem a ukazuje, jak Gravity buduje vynikající architekturu pro vysoce výkonný Layer-1 blockchain pro skutečné aplikace.
Gravity je vysoce výkonný, EVM kompatibilní Layer-1 blockchain vyvinutý Galxe. Vývoj Gravity pramení z potřeb rozvoje Galxe. Platforma Galxe, jakožto největší globální platforma pro distribuci na řetězci, spojuje obrovský vícerozměrný ekosystém a přitahuje více než 25 milionů uživatelů. Během svého vývoje se Galxe transformoval na decentralizovanou superaplikaci, integrující inovativní nástroje jako Quest, Passport, Score, Compass a Alva, zatímco nabízí bohaté služby jako loajalitní body, NFT akcí, odměny v tokenech, zk-ověření identity a mezichainové inteligentní úložiště. V průběhu svého vývoje se vysoký objem transakcí Galxe stal klíčovým faktorem pro budování Gravity - jeho systém loajalitních bodů podporuje 51,2 transakcí za sekundu, zatímco akce odměn v tokenech podporují 32,1 transakcí za sekundu. To nás vedlo k nutnosti přechodu na EVM blockchain, zatímco jsme si udrželi nejlepší uživatelskou zkušenost.
S rozvojem Galxe do plně řetězcové platformy je očekáván další růst objemu transakcí. Očekává se, že požadavek na propustnost dosáhne 50 milionů gas za sekundu, zatímco pro splnění širších ekologických potřeb (jako jsou mezichainové vypořádání, transakce s loajalitními body a trh NFT) může být potřeba zpracovat až 500 milionů gas za sekundu. Proto cílem Gravity je podpořit propustnost 1 gigagas za sekundu, aby splnila požadavky na škálování pro aplikace náročné na zdroje.
Mezi existujícími řešeními mnoho platforem realizuje škálovatelnost prostřednictvím Ethereum, avšak výzvy L2 Rollup nevyhnutelně vedou k zpoždění transakcí, což není příznivé pro aplikace, které potřebují okamžité potvrzení transakcí, jako je Galxe. I když některé DApp se snaží optimalizovat toto zpoždění pomocí důvěryhodných modelů nebo externího sledování, tyto metody přinášejí další složitosti a rizika, což není ideální pro základní scénáře aplikací.
V tomto kontextu vzniká Gravity. Gravity, s jádrem z paralelního EVM, zmenšuje výkonovou propast mezi L2 a L1 prostřednictvím vývoje Grevm, což je dosud nejrychlejší open-source paralelní EVM vykonávací systém, navíc Gravity modularizuje architekturu Aptos, integruje ověřené komponenty jako Quorum Store a konsensuální motor AptosBFT. Využitím zavedené architektury Aptos se Gravity vyhýbá složitosti a potencionálním rizikům spojeným s vývojem od nuly. Nakonec Gravity nevytváří pouze vysoce výkonný L1 blockchain, který poskytuje kompletní řetězovou zkušenost, ale také uvádí první pipeline blockchain SDK, výrazně zjednodušující interakci mezi vývojáři a uživateli.
Gravity poskytuje bezprecedentní škálovatelnost, schopnost decentralizace a téměř okamžité rychlosti transakcí. Její technologie kombinuje výhody L1 a L2, dosahuje 10 000 transakcí za sekundu a subsekundové konečnosti. Současně integrací protokolů pro restaking, jako jsou EigenLayer a Babylon, Gravity nejen zajišťuje silnou bezpečnost v počátečních fázích, ale také snižuje dlouhodobé systémové riziko spojené s závislostí na jediném aktivu.
V budoucnu bude Gravity postupovat podle následujícího plánu:
· Spuštění fáze 1 Devnet, testování výkonu v reálném čase;
· Spuštění Longevity Testnet, ověření dlouhodobé stability sítě;
· Přechod z Gravity Alpha Mainnet na plně provozovaný Gravity Mainnet, což položí základy pro masové aplikace decentralizovaných technologií.
Následuje plný překlad Gravity Litepaper.
Shrnutí
Gravity je vysoce výkonný, EVM kompatibilní Layer-1 blockchain vytvořený Galxe, navržený pro masové aplikace a vícerozměrné ekosystémy. Mezi jeho charakteristiky patří propustnost 1 gigagas za sekundu, subsekundové konečné potvrzení transakcí a konsensuální mechanismus PoS založený na protokolu pro restaking. Design Gravity se opírá o dvě hlavní komponenty s otevřeným zdrojovým kódem: (1) Gravity SDK, což je pipeline AptosBFT PoS konsensuální motor založený na restakingu; (2) Gravity reth, což je vykonávací vrstva poháněná paralelním EVM Grevm (Gravity EVM). Tyto nástroje poskytují schopnost vytvářet alternativní Layer-1 a efektivní Layer-2 aplikace, zejména na EVM řetězcích. Tento článek podrobně zkoumá inženýrský design Gravity a technické inovace, ukazuje, jak splnit vysoké výkonnostní požadavky prostřednictvím architektury potrubí, pokročilých konsensuálních algoritmů, paralelní vykonávací technologie a optimalizovaných úložných mechanismů (vylepšením reth a zlepšením konsensuálního motoru Aptos).
Úvod
Vývoj Gravity pramení z výzev, které Galxe čelil během svého provozu. Galxe je přední Web3 aplikace, která uživatelům poskytuje loajalitní body, NFT akcí, odměny v tokenech, ověřování identity pomocí nulových znalostí a mezichainové inteligentní úložiště. S rychlým rozvojem Galxe jeho systém loajalitních bodů průměrně zpracovává 51,2 transakcí za sekundu, zatímco akce odměn v tokenech průměrně zpracovávají 32,1 transakcí za sekundu. Během postupného decentralizování Galxe se stalo výzvou přenést tyto použití na EVM blockchain, při zachování plynulé uživatelské zkušenosti. Proto se stalo zásadní vyvinout vysoce výkonný EVM blockchain, který by splnil (1) vysokou transakční propustnost a (2) téměř okamžité potvrzení transakcí.
V tomto kontextu je výběr existujícího řešení Layer-2 nebo vývoj nového Layer-1 klíčovým rozhodovacím bodem. Layer-1 dosahuje konečnosti prostřednictvím konsensuálního algoritmu, zatímco Layer-2 se snaží tento problém vyřešit pomocí protokolu Rollup. Obě možnosti mají své výhody a nevýhody: Layer-1 obvykle obětuje část propustnosti kvůli omezením konsensuálního algoritmu, ale může dosáhnout rychlejšího konečného potvrzení transakcí. Například konsensuální algoritmus založený na AptosBFT dokáže potvrdit transakce na subsekundové úrovni, zatímco optimistický Rollup může mít výzvy s delšími obdobími. I když důkazy se nulovou znalostí mohou tento proces urychlit, konečné potvrzení stále trvá několik hodin. Vzhledem k potřebě Gravity po subsekundovém konečném potvrzení (zejména pro její protokol s celkovým záměrem) jsme se rozhodli vybudovat Layer-1.
I když má Layer-2 nativní výhodu v komunikaci s Ethereumem, Layer-1 jako Gravity může dosáhnout hluboké interoperability s Ethereumem a dalšími blockchainy prostřednictvím protokolu záměru Gravity a mezichainových mostů. Tento design nejenže umožňuje bezproblémovou spolupráci s Ethereumem, ale také zlepšuje konektivitu celého ekosystému Web3.
Dále, protokoly pro restaking (restaking) výrazně snižují obtížnost budování PoS Layer-1 blockchainu. Gravity integruje stakingová aktiva Ethereum a Bitcoin díky protokolům jako EigenLayer a Babylon a jejich rozsáhlé síti validátorů. To poskytuje ekonomické zajištění pro konsensus PoS, takže decentralizace a bezpečnost Gravity dosahují srovnatelné úrovně s Ethereum.
Celkově byl Gravity postaven jako vysoce výkonný, EVM kompatibilní Layer-1 blockchain, aby splnil požadavky moderního Web3 na škálovatelnost a výkon. I když jeho původní záměr byl sloužit Galxe, flexibilní rámec Gravity SDK a Grevm (Gravity EVM) se hodí k vytváření jakéhokoli Layer-1 a efektivního Layer-2, podobně jako Tendermint/Cosmos SDK.
Potřebujeme propustnost 1 gigagas/s
Pro blockchain je propustnost klíčovým výkonovým ukazatelem, obvykle měřeným počtem transakcí za sekundu (TPS) nebo množstvím plynu použitého za sekundu (gas/s). Například loajalitní bodový systém Galxe vyžaduje dosažení alespoň 4 milionů gas/s pro stabilní provoz. Tento údaj vychází z toho, že každá transakce loajalitních bodů průměrně spotřebovává 80 000 gas a lze zpracovat přibližně 51,2 transakcí za sekundu.
Tato předpověď byla podpořena praktickými daty Gravity Alpha Mainnet. Jako náš Layer 2 testovací síť ukázala transakce loajalitních bodů Gravity Alpha Mainnet, že její propustnost může stabilně dosahovat 4 miliony gas/s, což potvrzuje přesnost výše uvedeného odhadu.
I když vysoké náklady na operace na řetězci mohou vést k mírnému poklesu poptávky, expanze Galxe naznačuje, že v době špičky může poptávka vzrůst na dvě až tři aktuální úrovně. Kromě toho, s přidáním dalších scénářů použití, jako jsou NFT, odměny v tokenech a budoucí podpora pro důkazy se nulovou znalostí, se očekává, že poptávka po propustnosti dosáhne 50 milionů gas/s, pokud Galxe přejde na kompletní řetěz. Předpokládáme-li, že používání gas aplikací na Gravity Chain dodržuje Pareto rozdělení (podobně jako Uniswap, který neustále spotřebovává 10% gas Ethereum), ideálně by měl podporovat propustnost 500 milionů gas/s pro splnění širších ekologických potřeb, jako jsou mezichainová vypořádání, transakce s loajalitními body a trh NFT. Proto, abychom splnili tyto potenciální potřeby, musí mít blockchain schopnost zpracovávat 1 gigagas za sekundu, aby zajistil, že se dokáže přizpůsobit aplikacím náročným na zdroje.
Abychom dosáhli tak vysoké propustnosti, je klíčové zavést paralelní EVM. Vyvinuli jsme Grevm, což je aktuálně nejrychlejší open-source paralelní EVM vykonávací systém, jehož konkrétní výkon je podrobněji popsán v následujících kapitolách.
Subsekundová doba potvrzení
Kromě propustnosti je pro uživatelskou zkušenost klíčová také rychlost potvrzení transakcí. Moderní uživatelé jsou zvyklí na téměř okamžitou odezvu podobnou Webu 2, což je pro blockchain stále výzvou. Například Galxe, který je velmi podobný plně řetězcové hře, má určité požadavky na nízkou latenci. V současnosti se doba potvrzení transakcí většiny EVM blockchainů pohybuje od několika sekund do několika dnů, což tuto potřebu zdaleka nenaplňuje. Zvolili jsme konsensuální algoritmus AptosBFT pro dosažení subsekundové doby potvrzení.
I když L2 Rollup teoreticky může zvýšit propustnost, jejich výzvy vedou k zpoždění transakcí, což je velmi nevhodné pro aplikace, které potřebují okamžité potvrzení transakcí (jako je Galxe). Ačkoliv některé DApp se snaží optimalizovat tuto situaci pomocí důvěryhodných modelů nebo externího sledování, přináší to další složitosti a rizika, což není ideální pro kritické aplikace. Gravity SDK navrhuje pětifázové potrubí, které paralelizuje procesy konsensu a vykonávání, čímž zkracuje výkonovou propast mezi L2 a L1 (podrobnosti o návrhu jsou uvedeny níže).
Bezpečnost na základě restakingu (Restaking)
Gravity SDK poskytuje bezpečný způsob, jak rozšířit Ethereum, nikoli omezením na L2 Rollup, ale volbou architektury L1 chráněné restakingem, která vyvažuje výkon, interoperabilitu a bezpečnost. Hlavní moduly integrují restaking protokoly, jako jsou EigenLayer a Babylon, a poskytují ekonomickou důvěru, která zajišťuje robustní konsensuální mechanismus o důkazu podílu.
Díky stakingovým aktivům Ethereum v hodnotě 45 miliard dolarů a 850 000 validátorům a připojením k bitcoinovým aktivům v hodnotě 600 miliard dolarů prostřednictvím Babylon může Gravity vytvořit solidní bezpečnostní základ od samého začátku, aby se vyhnul běžným problémům a bezpečnostním hrozbám, které se vyskytují u nových blockchainů, přičemž dlouhodobě snižuje systémové riziko spojené s jediným aktivem.
Architektura Gravity Chain
Gravity Chain se skládá ze dvou hlavních komponentů: Gravity SDK a Gravity reth. Gravity SDK je blockchainový rámec vylepšený z řetězce Aptos, což je v současnosti nejpokročilejší PoS blockchain založený na rodině konsensuálních algoritmů HotStuff, jehož potrubní architektura výrazně zvyšuje propustnost a efektivitu zdrojů. Gravity reth je vykonávací vrstva založená na reth, která funguje jako blokový proudový reaktor (BSR), určený k přijímání návrhů bloků z konsensuální vrstvy. Optimalizací reth dosahuje Gravity reth paralelního vykonávání, hromadného asynchronního výpočtu odeslání stavu a zvýšení efektivity ukládání. Tyto dva komponenty jsou úzce propojeny prostřednictvím rozhraní Gravity Consensus Engine Interface (GCEI) a adaptéru reth, přičemž správce potrubí dynamicky řídí postup každé fáze.
Tento design odděluje vykonávání bloků od konsensu bloků, čímž vykonávací vrstva funguje jako spotřebitel návrhu bloků. Optimalizovali jsme reth tak, aby dokonale vyhovoval procesu návrhu bloků spravovanému blokovým proudovým reaktorem (BSR).
Transakční proces Gravity Chain je následující:
1. Transakce jsou odesílány prostřednictvím JSON RPC rozhraní Gravity reth, které je plně kompatibilní s Ethereum.
2. Následně transakce vstupuje do paměťového poolu Gravity SDK a šíří se v síti, validátoři provádějí hromadné zpracování transakcí a generují certifikát Quorum Store (QS).
3. Každé kolo vůdce předkládá návrh bloku, který obsahuje metadata bloku a seřazené transakce vybrané z paměťového poolu a QS.
4. Jakmile je návrh označen jako seřazený, vstoupí do vykonávací vrstvy.
5. Vykonávací vrstva Grevm paralelně zpracovává transakce, generuje výsledky vykonání a předává nový stav modulu správy stavu.
6. Stavový modul vypočítá kořen stavu a předá jej konsensuálnímu motoru k dosažení konsensu o kořeni stavu.
7. Jakmile je konečně potvrzen kořen stavu, úložní modul trvale ukládá kořen stavu a data bloku.
Následující kapitoly podrobněji prozkoumají každou komponentu.
Gravity SDK: Inovační praxe open-source potrubního blockchainu
Gravity SDK je modulární open-source blockchainový rámec vyvinutý na produkčně připraveném blockchainu Aptos. Jeho cílem je modularizovat architekturu Aptos, čerpat z již ověřených komponentů, jako jsou Quorum Store a konsensuální motor AptosBFT, a vytvořit první potrubní blockchain SDK.
Důvody pro výběr Aptos jako základ zahrnují:
· Nejlepší technická architektura: Aptos je pokročilý PoS blockchain založený na konsensu rodiny HotStuff.
· Extrémní výkon: Aptos poskytuje propustnost 160 000 transakcí za sekundu a doba konečného potvrzení je kratší než 1 sekunda.
· Praktická spolehlivost: Aptos již prošel ověřením v produkčním prostředí a vykazuje vynikající stabilitu a efektivitu.
· Vyhnout se opětovnému vynalézání kola: Využití zavedené architektury Aptos může obejít složitost a potenciální rizika spojená s vývojem od nuly, zatímco jiné pokusy překonat Aptos jsou většinou teoretické a nedostatečně praktické.
· Synergické výhody: S neustálým rozvojem Aptos může Gravity SDK bezproblémově integrovat nové funkce, jako je API pro generování náhodných čísel, zároveň také prostřednictvím modulární architektury a inovativních bezpečnostních mechanismů přispívá zpět do Aptos.
Blockchain založený na Gravity SDK se připojuje k potrubnímu konsensuálnímu motoru prostřednictvím Gravity Consensus Engine Interface (GCEI). Ačkoliv GCEI je kompatibilní s různými vykonávacími vrstvami, Gravity SDK v současnosti primárně podporuje Gravity reth. Podrobnosti o GCEI budou podrobněji prozkoumány v následujících kapitolách.
Gravity Consensus Engine Interface (GCEI)
Protokol GCEI (Gravity Consensus Execution Interface) je komunikační most mezi vrstvou konsensu a vrstvou vykonávání. Standardizuje interakci mezi těmito dvěma vrstvami a zajišťuje, že procesy konsensu a vykonávání zůstávají synchronizovány prostřednictvím správce potrubí.
Hlavní rozdíl mezi tradičním blockchainovým SDK a Gravity SDK spočívá v jeho potrubní konsensuální motoru. Vykonávací vrstva musí být implementována jako blokový proudový reaktor (Block Stream Reactor), což znamená, že musí být schopna kontinuálně spotřebovávat tok návrhu bloků a závazek stavu musí být asynchronně vypočítán s vykonáním transakcí. Navíc musí být vykonávací vrstva schopna poskytovat signály zpětného tlaku vrstvě konsensu, aby mohla dynamicky upravit tempo návrhu bloku.
Dále, díky vlastnostem potrubí Gravity SDK musí vykonávací vrstva být schopna zpracovat nevykonatelné transakce v návrhu bloku, protože paměťový pool nemůže kvůli nedostatečnému přístupu k nejnovějšímu stavu světa přísně ověřit platnost jakékoli transakce: vykonání nemusí být dokončeno. Zároveň by výsledky vykonání neměly blokovat generaci dalších bloků, protože po paralelizaci konsensu bloku s konsensem stavu se vykonávací vrstva stává reaktorem na tok návrhu bloků, který může svobodně vracet výsledky vykonání v následujících fázích.
Protokol GCEI definuje dvě skupiny API:
· API konsensuální vrstvy: Tato API jsou implementována Gravity SDK a slouží k reakci na návrhy bloků konsensuálního motoru a k odeslání stavového závazku.
· API pro vykonávání vrstvy: Tato API musí být implementována vrstvou vykonávání. Konsensuální motor použije tato API k ověření transakcí před tím, než je navrhne jako blok, a informuje vykonávací vrstvu o konečném stavu závazku.
Z pohledu životního cyklu transakce definuje protokol GCEI následující:
1. check_txn (API vykonávací vrstvy)
· Vstup: Přijměte transakci (GTxn) jako vstup.
· Výstup: Vrátit adresu odesílatele transakce, nonce a gas limit.
Účel: Tato metoda se používá k provádění snahy o ověření před tím, než konsensuální motor navrhne transakci jako blok. Tuto metodu lze volat vícekrát pro tutéž transakci, například když transakce vstupuje do paměťového poolu, před tím, než je navržena jako blok, a když je konečně potvrzen stavový závazek.
2. submit_txn (API konsensuální vrstvy)
Vstup: Přijměte transakci (GTxn) z vykonávací vrstvy.
Výstup: Vrátit Result<(), což indikuje, zda byla transakce úspěšně přidána do paměťového poolu.
Účel: Vykonávací vrstva může použít tuto metodu k odeslání transakcí do paměťového poolu. Konsensuální motor pak tuto transakci šíří prostřednictvím sítě a po obdržení dávky transakcí vytváří Quorum Store.
3. recv_ordered_block (API vykonávací vrstvy)
Vstup: Přijměte jeden ordered_block (typ BlockBatch), který obsahuje seřazené transakce a metadata bloků.
Výstup: Vrátit Result<(), což indikuje, zda vykonávací vrstva úspěšně přijala a přijala tento blok.
Účel: Jakmile konsensuální motor navrhne blok, je odeslán do vykonávací vrstvy k vykonání transakcí. Tato metoda umožňuje vykonávací vrstvě přijímat a zpracovávat navrhované bloky.
4. update_state_commitment (API konsensuální vrstvy)
Vstup: Stavový závazek (StateCommitment) pro určité číslo bloku.
Výstup: Vrátit Result<(), což indikuje, zda byl stavový závazek úspěšně přijat místním konsensuálním motorem.
Účel: Jakmile vykonávací vrstva vypočítá stavový závazek, odešle jej do vrstvy konsensu k finálnímu potvrzení, tj. k dosažení lehkého konsensu 2f+1 s ostatními validátory. Pokud se konsensus stavového závazku výrazně liší od pokroku návrhu bloku, správce potrubí upraví tempo návrhu bloku.
5. commit_block_hash (API vykonávací vrstvy)
Vstup: Přijměte vektor block_ids, který představuje bloky, které je třeba odeslat.
Výstup: Vrátit Result<(), což indikuje, zda byla operace úspěšná.
Účel: Když je závazek stavu konečně potvrzen, vrstva konsensu informuje vykonávací vrstvu, aby odeslala hash bloku do blockchainového úložiště.
Blockchainové potrubí
Gravity SDK maximalizuje využití hardwarových zdrojů pomocí architektury s pětifázovým potrubím, což umožňuje dosáhnout vyšší propustnosti a nižší latence. Potrubí provádí úkoly mezi různými bloky, správce potrubí používá zpětnou vazbu k zajištění plynulého postupu blockchainu. První tři fáze patří do vrstvy konsensu, zatímco poslední dvě fáze patří do vykonávací vrstvy.
Každá fáze je vysvětlena následovně:
· Fáze 1: Šíření transakcí: Tato fáze efektivně šíří transakce mezi validátory a zajišťuje, že během konstrukce bloku jsou transakce včas a spolehlivě zahrnuty. Design odděluje šíření transakcí od konsensuálního mechanismu, následuje myšlenky Narwhal & Tusk a Aptos, tedy že validátoři nepřetržitě sdílejí dávky transakcí, a využívají všechny síťové zdroje k paralelnímu provozu. Jakmile dávka transakcí získá váhový podpis 2f+1 (tvořící PoAv, což je důkaz použitelnosti), zajistí, že tuto dávku transakcí uchovává alespoň f+1 čestných validátorů, což umožní všem čestným validátorům tyto transakce získat k vykonání.
· Fáze 2: Třídění metadat bloku: Tato fáze vytváří konzistentní a uznávaný pořádek transakcí a metadat bloku v síti. Konsensuální mechanismus (AptosBFT) se drží pravidla dvou řetězců (2-chain rule), aby poskytl Byzantine fault-tolerant bloky. Bloky poté přecházejí do fáze vykonávání, připraveny na paralelní zpracování.
· Fáze 3 (BSR): Paralelní vykonávání transakcí: Tato fáze je součástí vykonávací vrstvy, kde se paralelně vykonávají transakce. Výsledky vykonání budou předány do fáze závazku stavu.
· Fáze 4: Závazek stavu: Tato fáze dokončuje změny stavu vyvolané vykonáním transakcí a připravuje blok k finálnímu potvrzení. Závazek stavu a vykonání transakcí se počítají asynchronně, což zajišťuje, že vykonání následujícího bloku není blokováno aktuálním závazkem stavu bloku.
· Fáze 5: Trvalé uložení stavu: Tato fáze trvale ukládá přijaté změny stavu do blockchainového úložiště. Konečný kořen stavu a související data jsou uložena v Gravity Store, které využívá vysoce optimalizovaný úložný motor navržený pro rychlý přístup a spolehlivost. Zároveň informuje paměťový pool a Quorum Store, aby vyčistily budoucí transakce, které již nebude možné zahrnout.
Moduly stakingu a restakingu
Vytvoření bezpečného blockchainu Layer 1 s důkazem podílu (PoS) je složitý úkol, zejména v případě, kdy se staking spoléhá pouze na specifické tokeny na řetězci. Tato metoda může v počátečních fázích čelit problémům s ekonomickou bezpečností, jako jsou kolísání hodnoty tokenů nebo omezená účast validátorů. Aby se tento problém vyřešil, Gravity SDK nabízí flexibilní moduly pro staking a restaking, které mají za cíl zvýšit bezpečnost sítě prostřednictvím místních a externích mechanismů stakingu.
Jednou z klíčových strategií Gravity SDK je zavedení protokolů pro restaking, jako jsou EigenLayer a Babylon. Tyto protokoly umožňují validátorům restakovat aktiva z jiných zavedených sítí (jako jsou Ethereum a Bitcoin), čímž využívají existující bezpečnostní záruky. Umožněním validátorům, aby zajišťovali aktiva z těchto řetězců, může Gravity SDK zvýšit ekonomickou bezpečnost sítě, aniž by se zcela spoléhalo na místní tokeny. Tento přístup nejen posiluje robustnost řetězce, ale také podporuje rozmanitost ekosystému validátorů. Modul stakingu je navržen s důrazem na modularitu, jeho komponenty pro restaking mají vysokou flexibilitu, což umožňuje snadné přizpůsobení novým protokolům restakingu, jak se blockchainový ekosystém vyvíjí.
Tento modul podporuje nejen aktiva pro restaking, ale také umožňuje staking vlastních ERC20 tokenů na podporovaných řetězcích, jako je G Token na Ethereum. Validátoři mohou prostřednictvím stakingu těchto povolených tokenů přispívat k bezpečnosti sítě. Hlasovací práva validátorů se počítají na základě jejich celkové stakingové hodnoty, která zahrnuje jak vlastní tokeny, tak aktiva v protokolu pro restaking. Tento výpočet se provádí na základě konkrétní konfigurace řetězce, aby každé chain mohl flexibilně nastavit pravidla stakingu a restakingu podle svých potřeb.
Epoch manager v konsensuálním motoru spolupracuje přímo se stakingovým modulem na výpočtu váhy příští sady validátorů. Získává stakingovou hodnotu z vykonávací vrstvy a zajišťuje, že konsensuální proces přesně odráží nejnovější dynamiku stakingu. V této architektuře musí být přesunuty mezichainové aktiva (například stakingová aktiva z Ethereum) nejprve do vykonávací vrstvy, aby mohla být použita pro výpočet celkové stakingové hodnoty validátorů. Implementace mechanismu přesunu je zodpovědná za vykonávací vrstvu, což umožňuje flexibilnější zpracování mezichainové komunikace. Možná řešení zahrnují PoS mosty, nulové důkazové certifikáty o stavu řetězce a vestavěné samočinně se spuštěné mezichainové zasílání zpráv.
Další technické detaily, návrh API a kompletní popis mechanismů stakingu a restakingu budou podrobněji představeny v následujících dokumentech.
Gravity Reth: Blokový proudový reaktor EVM vykonávací vrstva
Integrace vykonávací vrstvy Ethereum Virtual Machine (EVM) do architektury Gravity SDK přinesla jedinečné výzvy, zejména při plném využití schopností její potrubní konsensuální architektury. Abychom dosáhli bezproblémové integrace a plně využili potenciál této architektury, musíme provést řadu klíčových optimalizací na open-source Ethereum klientu reth. Tyto optimalizace zásadně transformují reth na Gravity reth, což je optimalizovaná vykonávací vrstva EVM přizpůsobená pro potrubní konsensuální motor.
Tradiční blockchainová architektura zpracovává bloky sekvenčně, zajišťující, že každý blok je plně ověřen a vykonán před tím, než navrhne další blok. Gravity SDK však přijímá mechanismus pipeline consensus, který odděluje různé fáze zpracování bloků pro zlepšení výkonu. Tento posun paradigmatu přináší složitost:
Neplatné transakce: V potrubním řetězci nemůže paměťový pool přistupovat k nejnovějšímu stavu světa, protože vykonání předchozího bloku může být dosud neúplné. Proto nemusí být transakce zahrnuté v návrhu bloku vykonatelné v okamžiku návrhu, protože jejich platnost nelze přísně ověřit bez nejnovějšího stavu.
Nevyblokovaná vykonávací výsledky: Aby se zabránilo zablokování potrubí, výsledky vykonání by neměly blokovat generaci dalších bloků. Vykonávací vrstva musí být schopna asynchronně zpracovávat návrhy bloků a vracet výsledky vykonání v pozdějších fázích bez blokování konsensuálního procesu. Pro EVM to znamená, že je třeba znovu definovat blockhash, aby se odstranila závislost na poli stateRoot v hlavičce bloku.
Abychom vyřešili tyto problémy, zavedli jsme čtyři klíčové optimalizace:
· Blokový proudový reaktor (Block Stream Reactor, BSR): BSR je navržen tak, aby upravil reth pro proces návrhu bloků Gravity SDK. Umožňuje vykonávací vrstvě nepřetržitě spotřebovávat tok návrhu bloků jako reaktor pro asynchronní zpracování bloků. BSR vytváří dynamickou zpětnou vazbu s konsensuálním motorem, kombinující odpovídající signály zpětného tlaku. Tyto signály v reálném čase upravují rychlost návrhu bloků a odesílání stavu na základě propustnosti a latence vykonávací vrstvy. Pokud zpoždění vykonávací vrstvy způsobují složité transakce nebo omezení zdrojů, mechanismus zpětného tlaku zpomaluje rychlost návrhu bloků, aby zajistil stabilitu systému.
· Oddělení odeslání stavu a vykonání transakce: Druhá optimalizace se týká oddělení výpočtu odeslání stavu a vykonání transakce. Oddělením těchto procesů dosahujeme asynchronizace výpočtu odeslání stavu, což umožňuje, aby vykonávání následujících bloků nečekalo na dokončení odeslání stavu aktuálního bloku. Znovu definujeme blockhash, abychom odstranili závislost na poli stateRoot v hlavičce bloku, a zajistili, že výpočet kořene stavu neblokuje generaci následujících bloků.
· Optimalizace úložné vrstvy: V potrubní architektuře je efektivní vyrovnávací paměť a trvalé ukládání více verzí stavových hodnot a odeslání stavu zásadní. Třetí optimalizace se zaměřuje na posílení úložné vrstvy, aby splnila tyto požadavky, aniž by došlo k zavedení úzkých míst. Optimalizací mechanismu ukládání zajišťujeme, že stavová data mohou být rychle zapsána a vysoce paralelně prohledávána. To zahrnuje budování vícerozměrného úložného motoru a podporu asynchronního I/O od databáze po API pro ukládání.
· Paralelní EVM: Poslední optimalizace se týká paralelního vykonávání transakcí uvnitř EVM. Vyvinuli jsme Grevm, paralelní EVM runtime, který výrazně urychluje zpracování transakcí prostřednictvím paralelního vykonávání. Grevm využívá datové závislosti získané ze simulace transakcí k optimalizaci paralelního vykonávání, snižuje opakované vykonávání transakcí a zvyšuje propustnost.
Grevm (Gravity EVM) - paralelní EVM vykonávání
Grevm je open-source projekt hostovaný na GitHubu (pokud ještě není open-source, v budoucnu bude open-source). Podívejte se na jeho README pro více informací.
Grevm (Gravity EVM) je open-source paralelní EVM runtime založený na revm. Algoritmus Grevm čerpá inspiraci z BlockSTM a posiluje jej zavedením grafu závislosti transakcí získaného ze simulace. Tento mechanismus činí plánování paralelního vykonávání efektivnějším a minimalizuje opakované vykonávání transakcí.
V našich benchmarkových testech je Grevm aktuálně nejrychlejší open-source paralelní EVM implementace. Pro transakce bez konfliktů je Grevm 4,13x rychlejší než sekvenční vykonávání, přičemž dosahuje rychlosti 26,50 gigagas/s. Pokud simulujeme reálný svět s 100 μs latencí I/O, je jeho rychlost 50,84x rychlejší než sekvenční vykonávání, s propustností 6,80 gigagas/s. Tento skok v výkonu je díky integraci paralelního vykonávání a asynchronních I/O operací - paralelizace umožňuje efektivní překrývání I/O operací, což dále urychluje.
Hlavní myšlenkou Grevm je využití datové závislosti mezi transakcemi k optimalizaci paralelního vykonávání prostřednictvím odhadovaného čtení/zápisu transakcí. I když všechny nápovědy nejsou zcela přesné, tyto simulované nápovědy jsou obvykle dostatečně praktické. Například na Ethereum mainnetu, podle historického použití gas, je přibližně 30% transakcí jednoduchý převod Etheru a dalších 25%-30% jsou převody ERC20 tokenů, které obvykle zahrnují pouze čtení a zápis omezeného počtu účtů a úložných slotů. Pro tyto transakce mají simulované výsledky konzistentní přesnost.
Na základě těchto poznatků jsme pro Grevm vyvinuli třífázový paralelní výkonný rámec jako pokračování modelu Block-STM, který kombinuje datové závislosti získané ze simulace transakcí:
· Fáze 1: Generování tipů a předběžné načítání stavu - simulace transakcí za účelem shromáždění závislostních tipů a předběžného ohřátí paměťové cache. Tato fáze může být prováděna v různých časových bodech, v závislosti na návrhu blockchainu. Například když nové transakce dorazí do paměťového poolu, může být simulace okamžitě spuštěna k předpřípravě závislostních tipů.
· Fáze 2: Analýza závislostí - převod závislostních tipů shromážděných v simulační fázi na orientovaný acyklický graf (DAG) představující závislosti mezi transakcemi. Tento DAG je používán pro plánování rozvrhu transakcí ve následném paralelním vykonávání.
· Fáze 3: Paralelní vykonávání pod konflikty - paralelní vykonávání transakcí pomocí modifikovaného algoritmu BlockSTM založeného na závislostním DAG. Rozvrh již nevybírá transakce striktně podle pořadí v bloku (např. 1, 2, 3, ..., n), ale upřednostňuje transakce podle DAG pro minimalizaci konfliktů a snížení potřebnosti opakovaného vykonávání.
Asynchronní hromadné odeslání stavu
Generování závazku stavu zůstává klíčovým úzkým místem v potrubí blockchainu, vyplývajícím z merkelizace inherentní sekvenčnosti. Každý výpočet podstromu musí být dokončen, než může být vygenerován konečný závazek stavu, což vede k významným zpožděním. I když stávající řešení (jako je paralelizace na úrovni účtu reth) přinášejí určitou úroveň paralelismu, stále existuje značný prostor pro optimalizaci. V kontextu blokového proudu reaktoru (BSR) Gravity reth, oddělení konsensu odeslání stavu a vykonání transakcí umožňuje asynchronní zpracování odloženého a hromadného výpočtu odeslání stavu bez blokování vykonávání.
Abychom vyřešili tyto problémy, navrhovaný rámec přináší následující klíčové inovace:
Asynchronní hromadné výpočty hash: Využitím oddělení konsensu odeslání stavu a vykonání transakcí tento rámec realizuje asynchronní výpočet odeslání stavu. Aktualizace kořenů stavu se provádějí dávkově (například jednou za 10 bloků), aby se snížila frekvence výpočtu kořenů stavu. Tento přístup hromadného zpracování dosahuje efektivního výpočtu hash prostřednictvím agregace sdílených špinavých uzlů, což maximalizuje snížení nákladů na časté aktualizace a celkové výpočetní náklady. Pro malé bloky může hromadné zpracování výrazně zvýšit paralelismus; pro velké bloky může snížit celkové výpočetní náklady.
Kompletní paralelizace: Tento rámec rozšiřuje paralelizaci na celý stavový strom, nikoli pouze na jednotlivý účetní strom. Pro uzly označené jako „špinavé“ tento rámec využívá algoritmus paralelního výpočtu stavu, rozděluje strom na nezávislé podstromy a zpracovává tyto podstromy paralelně. Výsledky se pak agregují na vrcholu pro efektivní výpočet konečného kořene. Tento přístup zajišťuje, že velké bloky s množstvím transakcí a změnami stavu mohou plně využívat vícerozměrnost, čímž maximalizují propustnost.
Alternativní rychlý kořen stavu: Abychom se přizpůsobili hlavičce bloku Ethereum a operátoru BLOCKHASH (který vyžaduje přístup k nejnovějším 256 kořenům stavu bloků), znovu definujeme kořen stavu. Na rozdíl od závislosti na konečném odeslání stavu (které není k dispozici během vykonání transakcí), vypočítáváme kořen stavu jako kombinaci hash hodnoty množin změn bloku a předchozího kořene stavu. Tento přístup zrychluje výpočet kořene stavu, aniž bychom museli čekat na dokončení celého odeslání stavu.
Gravity Store
Aby splnil požadavky na správu velkých dat pro vysoce výkonné blockchainy, Gravity Store vznikl jako optimalizovaná vrstva více verzí ukládání. Je založen na designu reth, který již snížil problém s expanzí stavu oddělením ukládání odeslání stavu a ukládání dat stavu, čímž snížil náklady na čtení a zápis dat. Nicméně vykonávací vrstva Gravity reth potřebuje další podporu pro paralelní zpracování a asynchronní odeslání stavu, což přináší více technických požadavků.
Abychom vyřešili tyto výzvy, Gravity Store navrhuje efektivní strukturu více verzí stromu, speciálně přizpůsobenou naší architektuře BSR (Block Stream Reactor). Tato struktura stromu podporuje správu aktualizací stavu více verzí. Na rozdíl od tradičního přístupu, který okamžitě aktualizuje hash hodnotu po modifikaci, Gravity Store označuje modifikované uzly jako „špinavé uzly“, čímž umožňuje zpožděné zpracování hash výpočtů a hromadné provádění. Tento design umožňuje rychlé vytváření nových verzí, efektivní dotazy na specifická data verzí a čištění starých verzí pod stanovenou výškou, což výrazně zlepšuje výkon správy stavu blockchainu.
Studujeme také nezávislý vývoj úložného motoru Gravity DB, jehož cílem je poskytnout optimalizovanou úložnou vrstvu pro blockchainové aplikace a podpořit plně asynchronní I/O operace. Design tohoto motoru je inspirován LETUS, což je vysoce výkonný logicky strukturovaný univerzální databázový motor zaměřený na blockchain. Náš hlavní vývojář Richard, jako jeden z hlavních autorů LETUS, podrobně představí jeho design v chystaném blogovém příspěvku.
Závěr
Gravity Chain je vysoce výkonný EVM kompatibilní Layer-1 blockchain navržený tak, aby splnil požadavky na škálovatelnost a výkon moderních web3 aplikací. V kombinaci s Gravity SDK, potrubním AptosBFT PoS konsensuálním motorem a vykonávací vrstvou Gravity reth poháněnou Grevm, Gravity dosahuje propustnosti 1 gigagas za sekundu, subsekundové doby potvrzení transakcí a bezpečnosti PoS založené na mechanizmu restakingu. Design těchto technických komponent poskytuje solidní základ pro vytváření vlastních alternativních L1 blockchainů nebo efektivnějších L2 řešení pro web3 aplikace, zejména pro optimalizaci scénářů využívání EVM chainů.
Tento článek pochází z příspěvku a nevyjadřuje názory BlockBeats.
