Autor: Tia, Techub News
Blockchain obětuje efektivitu kvůli své decentralizované povaze, a proto bylo zrychlení zpracování jedním z nejvíce naléhavých problémů k vyřešení. „Zpracovatelská vrstva“ blockchainu je klíčovou součástí, která zpracovává každou transakci a přidává ji do řetězce. Aby se zvýšila zpracovatelská kapacita, stalo se zlepšení na zpracovatelské vrstvě jednou z klíčových strategií, přičemž paralelní zpracování je významným průlomem v této oblasti.
Tradiční blockchainy obvykle zpracovávají transakce sériově, což značně omezuje rychlost transakcí, zejména v sítích s vysokou hustotou transakcí, což může vést k přetížení. Nicméně, prostřednictvím paralelního zpracování mohou být prováděny více transakcí současně, což výrazně zvyšuje efektivitu provádění a zmírňuje tlak na řetězec.
Abychom lépe porozuměli tomu, co je paralelní zpracování, začneme od provádění a jako příklad použijeme Ethereum v režimu PBS po Merge, abychom vysvětlili, co je provádění a ukázali, jakou pozici má provádění v celém životním cyklu transakcí.
Konkrétní fáze provádění transakcí
Transakce vstupují do paměťového poolu a jsou filtrované a seřazené: Toto je fáze předzpracování poté, co byla transakce podána, a zahrnuje interakci mezi Mempool, Searcher a Builder pro dokončení filtrování a třídění transakcí.
Builder sestavuje blok (ale neprovádí): Builder uspořádá ziskové transakce do bloku, aby dokončil balení a třídění transakcí.
Proposer ověřuje a podává blok: Po dokončení konstrukce bloku Builder odešle návrh bloku Proposerovi. Proposer ověřuje strukturu bloku a obsah transakcí a poté oficiálně podává blok do sítě, aby zahájil provádění.
Provádění transakcí: Po podání bloku uzly provádějí transakce uvnitř bloku jednu po druhé. Tato fáze je klíčová pro aktualizaci stavu, každá transakce vyvolá volání chytré smlouvy, změnu zůstatku účtu nebo změnu stavu.
Svědci svědčí: Ověřovatelé svědčí o výsledcích provádění bloku a kořenovém stavu a potvrzují je jako konečné. To zajišťuje pravdivost a platnost bloku na zpracovatelské vrstvě a zabraňuje nesrovnalostem.
Synchronizace stavů: Každý uzel synchronizuje výsledky provádění bloku (např. zůstatky účtů, aktualizace stavu smluv atd.) do svého místního stavu, po provedení každé transakce uzel vypočítá a uloží nový kořen stavu, který bude použit jako počáteční stav v dalším bloku.
Samozřejmě, že to je pouze synchronizace stavů transakcí na úrovni bloků; aby bylo možné udržovat aktuální stav na řetězci, obvykle uzly synchronizují data blok po bloku a neustále ověřují bloky a stavy. Aby však bylo dosaženo konečnosti pod mechanismem POS, je potřeba, aby agregátoři shromáždili podpisy svědků v každém Slotu do jednoho kompletního podpisu a předali ho navrhovateli dalšího Slotu. Ověřovatelé musí po uplynutí jednoho Epochu potvrdit stav všech bloků v tomto Epochu na základě počtu hlasů, což vytváří dočasný kontrolní bod konsensuálního stavu. Teprve když dva po sobě jdoucí Epochy získají většinovou podporu od ověřovatelů, bloky a transakce dosáhnou konečnosti.
Z pohledu celého životního cyklu transakce probíhá provádění po ověření struktury bloku a obsahu transakcí, které Proposer posílá Builderovi. Skutečný proces provádění vyžaduje zpracování transakcí jednu po druhé a aktualizaci příslušných stavů účtů nebo smluv. Po dokončení všech transakcí Proposer vypočítá nový kořen stavu (Merkleův kořen), což je shrnutí výsledků provádění všech transakcí v aktuálním bloku a konečného globálního stavu. Zjednodušeně řečeno, celý proces provádění bloku zahrnuje sérii výpočtů potřebných k přechodu Etherea z předchozího stavu na nový stav, od provádění každé transakce až po výpočet Merkleova kořene.
Sekvenční zpracování
Na rozdíl od paralelního zpracování existuje sekvenční zpracování, což je momentálně běžně používaný způsob zpracování na blockchainu. Obvykle se transakce provádějí po sobě. Po dokončení provádění jedné transakce Ethereum aktualizuje stav účtu a související informace (např. zůstatek, data uložená ve smlouvě) ve stavovém stromě účtů, což vede k vygenerování nového hashe stavu účtu. Jakmile jsou všechny stavy účtů aktualizovány, vytvoří se kořenový hash stavového Merkleova stromu, který se nazývá stavový Merkleův kořen. Po dokončení stavového Merkleova kořene, Merkleova kořene transakcí a Merkleova kořene potvrzení se provede hashování hlavy bloku, což generuje hash bloku.
Přičemž pořadí provádění transakcí je zásadní. Vzhledem k tomu, že Merkleův strom je binární strom hashů, různá pořadí vedou k různým hodnotám Merkleova kořene.
Paralelní zpracování
V prostředí paralelního zpracování se uzly pokoušejí provádět transakce v bloku paralelně. Neprovádějí transakce po sobě, ale přiřazují transakce na různé „zpracovatelské cesty“, aby je mohly provádět současně. Díky paralelnímu zpracování je systém schopen efektivněji zpracovávat transakce v bloku a zvýšit propustnost.
Po dokončení provádění všech transakcí uzel shrne výsledky provádění (tj. aktualizace stavů ovlivněných transakcemi) do nového stavu bloku. Tento stav bude přidán do blockchainu a představuje nejnovější globální stav na řetězci.
Konflikty stavů
Jelikož paralelní zpracování zpracovává transakce současně na různých cestách, jedním z hlavních problémů je konflikt stavů. Tedy může existovat několik transakcí, které v rámci stejného časového úseku přistupují ke stejné části dat (stavu) na blockchainu pro čtení nebo zápis. Pokud se s tímto problémem nezachází správně, může to vést k neurčitým výsledkům provádění. Vzhledem k tomu, že pořadí aktualizace stavů je odlišné, konečné výpočty se také mohou lišit. Například:
Představme si, že existují dvě transakce, transakce A a transakce B, které se obě pokouší aktualizovat zůstatek stejného účtu:
Transakce A: Zvyšte zůstatek účtu o 10.
Transakce B: Zvyšte zůstatek účtu o 20.
Počáteční zůstatek účtu je 100.
Pokud provádíme sériové zpracování, výsledek pořadí provádění je určený:
1. Nejprve provést transakci A, poté provést transakci B:
Zůstatek účtu se nejprve zvýší o 10, což se změní na 110.
Pak se zvýší o 20, což nakonec činí 130.
2. Nejprve provést transakci B, poté provést transakci A:
Zůstatek účtu se nejprve zvýší o 20, což se změní na 120.
Pak se zvýší o 10, což nakonec činí 130.
V obou těchto pořadích je konečný zůstatek 130, protože systém zajišťuje konzistenci pořadí provádění transakcí.
Avšak v prostředí paralelního zpracování může transakce A a transakce B současně číst počáteční zůstatek 100 a provádět své výpočty:
Transakce A přečte zůstatek 100 a po výpočtu ho aktualizuje na 110.
Transakce B také přečte zůstatek 100 a po výpočtu ho aktualizuje na 120.
V tomto případě, díky paralelnímu provádění, je konečný zůstatek aktualizován pouze na 120, nikoli na 130, protože operace transakcí A a B „přepsaly“ výsledky navzájem, což vedlo k konfliktu stavu.
Tyto typy problémů s konflikty stavů se obvykle nazývají „překrytí dat“, tj. když se transakce pokoušejí současně měnit stejná data, mohou si navzájem překrýt výpočty a vést k nesprávnému konečnému stavu. Dalším problémem, který mohou konflikty stavů vést, je nemožnost zaručit pořadí provádění. Vzhledem k tomu, že různé transakce dokončují operace v různých časových obdobích, může to vést k různým pořadím provádění. Různá pořadí mohou vést k různým výpočtům, což činí výsledky neurčitelnými.
Aby se zabránilo této neurčitosti, systémy paralelního zpracování blockchainu obvykle zavádějí mechanismy detekce konfliktů a vracení, nebo provádějí předběžnou analýzu závislosti transakcí, aby zajistily, že budou prováděny paralelně, aniž by to mělo vliv na konečnou konzistenci stavu.
Optimistické a deterministické paralelní zpracování
Existují dva způsoby, jak se vypořádat s potenciálními problémy s konflikty stavů: deterministické paralelní zpracování a optimistické paralelní zpracování. Tyto dva modely mají různé kompromisy v efektivitě a složitosti designu.
Deterministické paralelní zpracování vyžaduje, aby byla předem deklarována přístup k stavům, přičemž ověřovatel nebo sekvencer zkontroluje deklarované přístupy k stavům při třídění transakcí. Pokud se více transakcí pokusí zapsat do stejného stavu, budou tyto transakce označeny jako konfliktní a nebude možné je provádět současně. Různé řetězce mají různé konkrétní implementace pro předběžné deklarace přístupu k stavům, ale obvykle zahrnují následující formy:
Prostřednictvím specifikace smlouvy: Vývojáři přímo v chytré smlouvě stanoví rozsah přístupu k stavům. Například převod ERC-20 tokenů vyžaduje přístup k poli zůstatků odesílatele a příjemce.
Prostřednictvím strukturovaných dat transakce: Přidání speciálních polí do transakce pro označení přístupu k stavům.
Prostřednictvím analýzy kompilátoru: Kompilátor vysoce úrovňového jazyka může provádět statickou analýzu kódu smlouvy a automaticky generovat sadu přístupových stavů.
Rámcově vynucené prohlášení: Některé rámce vyžadují, aby vývojáři při volání funkcí výslovně určili, které stavy potřebují přistupovat.
Optimistické paralelní zpracování se optimisticky pokouší nejprve zpracovat transakce, a když dojde ke konfliktu, znovu provede ovlivněné transakce v pořadí. Aby se co nejvíce vyhnulo konfliktům, je jádrem designu optimistického paralelního zpracování rychlá předpověď a hypotéza o stavech pomocí historických dat, statické analýzy atd. To znamená, že systém předpokládá, že některé operace nebo aktualizace stavů jsou platné, aniž by čekal na všechny validační procesy, čímž zvyšuje výkonnost a propustnost.
Ačkoli optimistické paralelní zpracování se snaží co nejvíce vyhnout konfliktům pomocí rychlých předpovědí a hypotéz o stavech, stále existují některé nevyhnutelné výzvy, zejména pokud jde o provádění smluv nebo meziketlové transakce; pokud se konflikty vyskytují často, opětovné provádění může významně zpomalit výkon systému a zvýšit spotřebu výpočetních prostředků.
Deterministické paralelní zpracování provádí kontrolu závislosti stavu před transakcí, aby se vyhnulo potenciálním konfliktům, které by mohly vzniknout v optimistickém paralelním zpracování, avšak protože je nutné přesně deklarovat závislost stavu před podáním transakce, klade to na vývojáře vyšší požadavky, což zvyšuje složitost implementace.
EVM paralelní dilema
Při řešení konfliktů stavů se rozlišují nejen deterministické a optimistické přístupy, ale je také třeba zohlednit konkrétní procesy v rámci paralelního zpracování z pohledu architektury řetězových databází. Problémy s konflikty stavů v paralelním zpracování jsou zvlášť obtížné v EVM založeném na Merkleově stromě. Merkleův strom je hierarchická hashová struktura, jejíž kořenový hash se musí aktualizovat po každé transakci, která mění stavová data. Tento proces aktualizace je rekurzivní, počínaje od listových uzlů směrem vzhůru až k kořenovému uzlu. Vzhledem k tomu, že hashování je nevratné, lze výpočet nad horními vrstvami provést pouze poté, co jsou změny provedeny v dolních vrstvách, což činí paralelní aktualizace obtížnými.
Pokud dvě transakce provádějí paralelní zpracování a přistupují ke stejnému stavu (např. zůstatek účtu), vznikne konflikt uzlů Merkleova stromu. Řešení těchto konfliktů obvykle vyžaduje dodatečné mechanismy správy transakcí, které zajistí, že ve všech větvích bude dosaženo konzistentního kořenového hashe. To není pro EVM snadné, protože to vyžaduje kompromis mezi paralelizací a konzistencí stavů.
Paralelní řešení mimo EVM
Solana
Na rozdíl od globálního stavového stromu Etherea, Solana používá model účtu. Každý účet je nezávislým úložným prostorem uloženým v knize, což eliminuje problémy s konfliktem cest.
Solana je deterministické paralelní zpracování. V Solaně je každá transakce při podání povinna výslovně deklarovat, které účty budou přístupné a jaké přístupové oprávnění (pouze pro čtení nebo pro čtení a zápis) je potřeba. Tento design umožňuje uzlům blockchainu analyzovat potřebné zdroje pro každou transakci před jejím provedením. Protože transakce před jejím prováděním jasně prohlašují všechny závislosti na účtech, mohou uzly určit, které transakce budou přistupovat ke stejnému účtu a které transakce lze bezpečně provádět paralelně, čímž se dosahuje inteligentního plánování, vyhne se konfliktům a tím se zakládá základ pro paralelní plánování.
Protože každá transakce před provedením deklarovala potřebné účty a oprávnění, Solana může zkontrolovat, zda existují závislosti mezi transakcemi (model Sealevel). Pokud mezi transakcemi nejsou sdílené čtecí a zapisovací účty, systém je může přiřadit k různým procesorům k paralelnímu provádění.
Aptos
Design paralelního zpracování Aptos se výrazně liší od Etherea, přičemž v architektuře a mechanismech došlo k několika klíčovým inovacím, zejména v oblasti modelu účtů a ukládání stavů.
Ethereum při provádění transakcí často aktualizuje globální stavový strom (MPT). Všechny účty a stavy smluv jsou uloženy v jednom sdíleném stavovém stromě, přičemž každá transakce potřebuje přistupovat a aktualizovat část tohoto stromu. Aptos na druhé straně rozděluje účty na nezávislé stavové jednotky, přičemž každý objekt je nezávislým klíčovým párem, které může existovat samostatně bez vzájemného ovlivňování, a propojení nastává pouze v případě jasně definovaných referenčních vztahů. Mezi objekty neexistují společné cesty ve stromu, což eliminuje konkurenci o zámky a umožňuje plně paralelní zpracování.
Základní datová struktura Aptos je Jellyfish Merkle Tree. Stav každého objektu se nakonec ukládá v JMT jako nezávislý klíčový pár. Na rozdíl od MPT Etherea je Jellyfish Merkle Tree ve formě úplného binárního stromu, což zjednodušuje cesty pro ukládání a dotazování uzlů a významně zkracuje čas na ověření. A navíc, pozice každého účtu ve stromě je pevná a uzly ve stromě jsou nezávisle uloženy, což umožňuje paralelní aktualizaci a vyhledávání více účtů.
Aptos je optimistické paralelní zpracování, které nevyžaduje předchozí poskytnutí všech závislostí účtů. K tomu Aptos používá Block-STM, který využívá přednastaveného pořadí transakcí k odhadu závislostí, čímž se snižuje počet přerušení.
Paralelní EVM
Ve srovnání s ne-EVM paralelními systémy čelí paralelní EVM větším technickým výzvám při řešení závislostí stavů, detekci konfliktů, správě plynu a mechanismům vracení. Abychom to lépe pochopili, můžeme se podívat na to, jak některé projekty paralelního EVM (např. Sui, Monad, Canto) řeší tyto problémy.
Sui
Sui, stejně jako Aptos, také používá objektový model pro zpracování stavů, přičemž každý objekt (např. účet, stav chytré smlouvy) se považuje za nezávislý zdroj, který se odlišuje pomocí jedinečných identifikátorů objektů. Když se transakce týkají různých objektů, tyto transakce mohou být prováděny paralelně, protože operují na různých stavech a nezpůsobují přímé konflikty.
Ačkoli Sui používá objektový model pro správu stavů, aby byla zajištěna kompatibilita s EVM, architektura Sui používá dodatečné adaptační vrstvy nebo abstraktní mechanismy k propojení objektového modelu a modelu účtů EVM.
V Sui používá plánování transakcí optimistickou paralelní strategii, která předpokládá, že mezi transakcemi nejsou žádné konflikty. Pokud nastane konflikt, systém použije mechanismus vracení k obnovení stavu.
Sui používá objektový model a technologie oddělení stavů, což efektivně eliminuje problémy se závislostí stavů. Každý objekt funguje jako nezávislý zdroj, což umožňuje, aby různé transakce byly prováděny paralelně, a tím se zvyšuje propustnost a efektivita. Ale trade-off tohoto přístupu spočívá ve složitosti objektového modelu a nákladech na mechanismy vracení. Pokud mezi transakcemi dojde ke konfliktu, je třeba některé stavy vrátit, což zvyšuje zátěž systému a může ovlivnit efektivitu paralelního zpracování. Oproti ne-EVM paralelním systémům (jako je Solana) potřebuje Sui více výpočetních a úložných zdrojů k udržení efektivního paralelního zpracování.
Monad
Stejně jako Sui, Monad také používá optimistické paralelní zpracování. Ale optimistické paralelní zpracování Monad provádí předpovědi na některé transakce se závislostmi před skutečným prováděním, přičemž předpovědi se provádějí hlavně pomocí statického analyzátoru kódu Monad. Předpovědi vyžadují přístup ke stavům, a způsob, jakým jsou stavy uloženy v databázi Etherea, činí přístup ke stavům velmi obtížným. Aby se zvýšila efektivita procesu čtení stavů v paralelním zpracování, Monad také přepracoval databázi.
Stavový strom Monad je rozdělen do partition, kde každý partition spravuje svou vlastní podstrom stavu. Při aktualizaci stačí upravit příslušné fragmenty, aniž by bylo nutné zrekonstruovat celý stavový strom. Rychlým vyhledáním pomocí tabulky indexů stavů lze rychle lokalizovat stav v partition a snížit interakci mezi partition.
Shrnutí
Jádrem paralelního zpracování je zvyšování efektivity zpracovatelské vrstvy prováděním více cest současně, přičemž k dosažení více cestového zpracování musí řetězce provádět řadu opatření, jako je detekce konfliktů a mechanismy vracení, aby zajistily, že budou prováděny paralelně, aniž by to mělo vliv na konečnou konzistenci stavu, a provádět určité úpravy databáze.
Samozřejmě, že zlepšení efektivity na zpracovatelské vrstvě není omezeno pouze na paralelní zpracování; optimalizace zpracovatelského kroku může být také dosažena snížením počtu operací čtení a zápisu databáze pro jednu transakci. Zlepšení rychlosti celého řetězce zahrnuje širší oblast, včetně zlepšení efektivity konsensuální vrstvy.
Každá technologie má své specifické omezení. Paralelní zpracování je pouze jedním ze způsobů, jak zvýšit efektivitu, a konečné rozhodnutí o použití této technologie závisí také na tom, zda je přívětivá pro vývojáře a zda je možné ji implementovat, aniž by došlo k obětování decentralizace. Technologie není vždy lepší, čím více se jich používá; alespoň v případě Etherea není paralelní zpracování tak atraktivní, pokud se na to díváme pouze z hlediska zvýšení efektivity; zavedení paralelního zpracování pro Ethereum není optimálním řešením, ať už z hlediska jednoduchosti nebo z pohledu současné roadmapy Etherea zaměřené na Rollup.
