Článek převzat z: Techub News
Autor: Tia, Techub News
Blockchain obětoval efektivitu díky své decentralizované konstrukci, proto je zvýšení rychlosti vykonání jedním z naléhavých problémů, které je třeba vyřešit. Vykonávací vrstva blockchainu je klíčovou částí, která zpracovává každou transakci a přidává ji do řetězce. Aby se zvýšila zpracovatelská kapacita, zlepšování na vykonávací vrstvě se stává jednou z klíčových strategií, přičemž paralelní vykonání je důležitým průlomem v této oblasti.
Tradiční blockchainy obvykle zpracovávají transakce sekvenčně, což výrazně omezuje rychlost transakcí, zejména v hustých sítích, což může vést k přetížení. Nicméně, paralelním vykonáním mohou být zpracovány více transakcí současně, čímž se výrazně zvyšuje efektivita vykonání a snižuje tlak na řetězec.
Abychom lépe pochopili, co je paralelní vykonání, začneme s vykonáním a jako příklad vezmeme Ethereum v režimu PBS po Merge, abychom vysvětlili, co je vykonání a zároveň ukázali, kde se vykonání nachází v celém životním cyklu transakce.
Konkrétní fáze vykonání transakcí
Transakce vstupuje do paměťového poolu a je filtrována a tříděna: Toto je fáze předzpracování, která následuje po podání transakce a zahrnuje interakci mezi Mempool, Searcher a Builder, která dokončuje filtrování a třídění transakcí.
Builder vytváří blok (ale nevykonává): Builder uspořádá ziskové transakce do bloku, aby dokončil balení a třídění transakcí.
Proposer ověřuje a odevzdává blok: Po dokončení stavby bloku, Builder odešle návrh bloku Proposerovi. Proposer ověřuje strukturu bloku a obsah transakcí, a poté oficiálně odevzdává blok do sítě, aby začal vykonávat.
Vykonání transakcí: Po odevzdání bloku, uzly vykonávají transakce uvnitř bloku jednu po druhé. Toto je klíčová fáze aktualizace stavu, každá transakce spouští volání inteligentní smlouvy, změnu zůstatku účtu nebo změnu stavu.
Svědci svědčí: Ověřovatelé svědčí o výsledku vykonání bloku a kořeni stavu a potvrzují je jako konečné. To zajišťuje pravdivost a platnost bloku na vykonávací vrstvě a zabraňuje nesrovnalostem.
Synchronizace stavu: Každý uzel synchronizuje výsledky vykonání bloku (např. změny zůstatků účtů, aktualizace stavu smlouvy atd.) do svého místního stavu, po vykonání každé transakce uzel spočítá a uloží nový kořen stavu, který se použije jako počáteční stav v dalším bloku.
Samozřejmě, že to je pouze synchronizace stavu transakcí na úrovni bloků, aby se udržel nejnovější stav na řetězci, obvykle uzly synchronizují data po blocích a pokračují v ověřování bloků a stavů. Aby se však dosáhlo konečnosti pod POS mechanismem, musí agregátor shromáždit podpisy svědků z každého slotu do jednoho kompletního podpisu a předat je navrhovateli příštího slotu. Ověřovatelé musí po uplynutí jednoho epochu potvrdit stav všech bloků v tomto epochu na základě počtu hlasů, čímž se vytvoří dočasný konsensuální stav kontrolního bodu. Teprve když dva po sobě jdoucí epochy získají podporu většiny ověřovatelů, bloky a transakce dosáhnou konečnosti.
Z pohledu celého životního cyklu transakce se vykonání odehrává po ověření struktury bloku a obsahu transakcí, které Proposer poslal Builderovi. Skutečný proces vykoná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 spočítá nový kořen stavu (Merkle root), což je shrnutí výsledků vykonání všech transakcí v aktuálním bloku a konečného globálního stavu. Zjednodušeně řečeno, kompletní proces vykonání bloku zahrnuje sérii výpočtů potřebných k přeměně Ethereum z předchozího stavu do dalšího stavu, od vykonání každé transakce až po výpočet Merkle kořene.
Sekvenční vykonání
Proti paralelnímu vykonání stojí sekvenční vykonání, což je v současnosti běžný způsob vykonání na blockchainu. Obvykle se transakce vykonávají postupně. Jakmile je transakce provedena, Ethereum aktualizuje stav účtu a související informace (např. zůstatek, data uložená ve smlouvě) do stromu stavu účtu a generuje se nový hash stavu účtu. Po dokončení aktualizace všech stromů stavu účtu se vytvoří hash kořene stavu známý jako Merkle root. Po dokončení Merkle kořene stavu, Merkle kořene transakce a Merkle kořene příjmu se provede hashování hlavičky bloku a vygeneruje se hash bloku.
A v této souvislosti je pořadí vykonání transakcí zásadní. Vzhledem k tomu, že Merkle tree je binární strom hashů, různé pořadí vytváří různé hodnoty Merkle root.
Paralelní vykonání
V prostředí paralelního vykonání se uzly pokoušejí provádět paralelní zpracování transakcí v bloku. Neprovádějí se postupně jedna po druhé, ale transakce se přidělují na různé „vykonávací cesty“, aby je bylo možné vykonávat současně. Paralelním vykonáním může systém efektivněji zpracovávat transakce v bloku a zvyšovat propustnost.
Po dokončení všech transakcí uzly shrnou výsledky vykonání (tj. aktualizace stavu ovlivněného transakcemi) a vytvoří nový stav bloku. Tento stav bude přidán do blockchainu a představuje nejnovější globální stav na řetězci.
Stavové konflikty
Protože paralelní vykonání zpracovává transakce současně na různých cestách, jedním z hlavních problémů paralelního vykonání jsou stavové konflikty. Může existovat více transakcí, které současně čtou nebo zapisují do stejné části dat (stavu) na blockchainu. Pokud se s tímto problémem nezachází správně, může to vést k neurčitým výsledkům vykonání. Protože se pořadí aktualizace stavu liší, konečné výpočty se také liší. Například,
Předpokládejme, že existují dvě transakce, transakce A a transakce B, které se obě snaží 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 bychom vykonávali sekvenčně, výsledek pořadí vykonání je určitý:
1. Nejprve vykonejte transakci A, poté vykonejte transakci B:
Zůstatek účtu se nejprve zvýší o 10, tedy na 110.
Poté se zvýší o 20, nakonec se stane 130.
2. Nejprve vykonejte transakci B, poté vykonejte transakci A:
Zůstatek účtu se nejprve zvýší o 20, tedy na 120.
Poté se zvýší o 10, nakonec se stane 130.
V obou těchto pořadích je konečný zůstatek 130, protože systém zajišťuje konzistenci pořadí vykonání transakcí.
Ale v prostředí paralelního vykonání mohou transakce A a B současně přečíst počáteční zůstatek 100 a provést své výpočty:
Transakce A přečetla zůstatek 100 a po výpočtu jej aktualizovala na 110.
Transakce B také přečetla zůstatek 100 a po výpočtu jej aktualizovala na 120.
V tomto případě, protože se transakce vykonávají současně, konečný zůstatek se aktualizuje pouze na 120, místo 130, protože operace transakce A a transakce B „překrývaly“ výsledky druhého a vznikly stavové konflikty.
Tyto typy problémů se stavovými konflikty se obvykle nazývají „překrytí dat“, což znamená, že když se transakce snaží současně měnit stejná data, mohou si vzájemně překrýt výpočty, což vede k nesprávnému konečnému stavu. Další potenciální problém ze stavových konfliktů je nemožnost zaručit pořadí vykonání. Protože různé transakce dokončují operace v různých časových obdobích, mohou způsobit různé pořadí vykonání. Různé pořadí může vést k různým výpočtům, což činí výsledky neurčitými.
Aby se předešlo této nejistotě, systémy paralelního vykonání blockchainu obvykle zavádějí některé mechanismy detekce konfliktů a rollback, nebo provádějí analýzu závislostí transakcí předem, aby zajistily, že budou paralelně vykonávány bez ovlivnění konečné konzistence stavu.
Optimistická paralela vs. deterministická paralela
Existují dva přístupy k řešení potenciálních problémů se stavovými konflikty: deterministická paralela a optimistická paralela. Tyto dva přístupy mají různé vyvážení efektivity a složitosti návrhu.
Deterministická paralela vyžaduje předem deklaraci přístupu k stavu; ověřovatelé nebo sekvencery kontrolují deklarovaný přístup k stavu při třídění transakcí. Pokud se několik transakcí pokouší zapisovat do stejného stavu, označí tyto transakce jako konfliktní, čímž se zabrání jejich současnému vykonání. Různé řetězce implementují různými způsoby předběžnou deklaraci přístupu k stavu, ale obecně zahrnují následující metody:
Pomocí smluvních specifikací: Vývojáři přímo určují rozsah přístupu k stavu v inteligentní smlouvě. Například převod tokenu ERC-20 vyžaduje přístup k poli zůstatku odesílatele a příjemce.
Pomocí strukturovaných dat transakcí: Přidání speciálních polí do transakce na označení přístupu k stavu.
Pomocí analýzy kompilátoru: Kompilátory vysoce úrovňových jazyků mohou provádět statickou analýzu kódu smlouvy a automaticky generovat soubor přístupů k stavu.
Pomocí rámců, které vyžadují deklaraci: Některé rámce vyžadují, aby vývojáři při volání funkce explicitně uvedli, jaký stav potřebují přistupovat.
Optimistická paralelní výkonnost nejprve optimisticky zpracovává transakce a když dojde ke konfliktu, znovu vykoná dotčené transakce v pořadí. Aby se co nejvíce předešlo konfliktům, je jádrem návrhu optimistické paralelní výkonnosti rychlá predikce a hypotéza stavu pomocí historických dat, statické analýzy atd. To znamená, že systém předpokládá, že některé operace nebo aktualizace stavu jsou platné, aniž by čekal na všechny ověřovací procesy, a tím zvyšuje výkon a propustnost.
I když optimistická paralela může co nejvíce předejít konfliktům pomocí rychlého predikování a hypotéz stavu, stále existují některé nevyhnutelné výzvy, zejména ty, které se týkají vykonání smluv nebo meziblokových transakcí. Pokud se konflikty často vyskytují, opětovné vykonání může výrazně zpomalit výkon systému a zvýšit spotřebu výpočetních zdrojů.
Deterministické paralelní vykonání zabraňuje optimistickým konfliktním situacím pomocí kontroly závislosti stavu před transakcí, ale vyžaduje, aby byly závislosti stavu přesně deklarovány před podáním transakce, což klade vyšší požadavky na vývojáře a zvyšuje složitost implementace.
EVM paralelní dilema
K vyřešení stavových konfliktů existují nejen deterministické a optimistické přístupy, ale také je třeba brát v úvahu architekturu databáze řetězce. Problém stavových konfliktů v paralelních systémech je obzvláště složitý v EVM založeném na Merkle tree. Merkle tree je hierarchická hash struktura, kde je potřeba aktualizovat hash kořene po každé transakci, která mění určité stavové údaje. Tento proces aktualizace je rekurzivní, počínaje listovými uzly a postupně se počítá nahoru až k kořenovému uzlu. Protože hash je nevratný, je možné vypočítat horní úroveň až po dokončení změn na dolní úrovni, což činí paralelní aktualizaci velmi obtížnou.
Pokud dvě transakce vykonávají paralelně a přistupují ke stejnému stavu (např. zůstatek účtu), může to vést ke konfliktu uzlů Merkle tree. A řešení tohoto konfliktu obvykle vyžaduje dodatečné mechanismy správy transakcí, aby se zajistilo, že ve všech větvích se dosáhne konzistentní hodnoty kořene hash. To není pro EVM snadné implementovat, protože to vyžaduje vyvážení mezi paralelním zpracováním a konzistencí stavu.
Ne-EVM paralelní řešení
Solana
Na rozdíl od globálního stavového stromu Ethereum, Solana používá model účtů. Každý účet je nezávislý úložný prostor, uložený v knize, což zabraňuje problémům s konfliktem cest.
Solana je deterministická paralela. V Solaně musí každá transakce při podání jasně deklarovat účty, které budou přístupné, a potřebná oprávnění (pouze pro čtení nebo pro čtení a zápis). Tento design umožňuje uzlům blockchainu analyzovat potřebné zdroje pro každou transakci před jejím provedením. Protože transakce již před zahájením vykonání jasně deklarovaly všechny závislosti účtů, uzly mohou určit, které transakce přistupují ke stejnému účtu, a které transakce mohou být bezpečně vykonávány paralelně, čímž se dosáhne inteligentního plánování a vyhnutí se konfliktům, což tvoří základ pro paralelní plánování.
Protože každá transakce před vykonáním deklarovala účty a oprávnění, které potřebuje, Solana může zkontrolovat, zda mezi transakcemi existují závislosti na účtech (model Sealevel). Pokud mezi transakcemi neexistují sdílené účty pro čtení a zápis, systém je může přiřadit k různým procesorům a vykonávat je paralelně.
Aptos
Paralelní vykonávací design Aptos se značně liší od Ethereum, provádí některé klíčové inovace v architektuře a mechanismu, zejména v modelu účtů a ukládání stavu.
Ethereum při vykonávání transakcí musí často aktualizovat globální stavový strom (MPT). Všechny účty a stavy smluv jsou uloženy ve sdíleném stavovém stromu, jakákoli transakce musí přistupovat a aktualizovat část tohoto stromu. Aptos však dělí účty na nezávislé stavové jednotky, kde každý objekt je samostatným párem klíč-hodnota, objekty mohou existovat nezávisle na sobě a vzájemně se neovlivňují, pouze když existuje jasná referencia, tak se propojí. Mezi objekty neexistují společné cesty stromu, což zabraňuje konfliktům zámku a umožňuje úplnou paralelu.
Základní datová struktura Aptos je Jellyfish Merkle Tree. Stav každého objektu je nakonec uložen v JMT jako samostatný pár klíč-hodnota. Na rozdíl od MPT Ethereum, Jellyfish Merkle Tree má strukturu úplného binárního stromu, což zjednodušuje cesty pro ukládání uzlů a cesty pro dotazy, což výrazně snižuje čas ověřování. A pozice každého účtu ve stromu je fixní a uzly ve stromu jsou uloženy samostatně, což umožňuje paralelní aktualizace a vyhledávání více účtů.
Aptos je optimistická paralela, která nevyžaduje předběžné poskytnutí závislostí všech deklarovaných účtů. K tomu Aptos používá Block-STM, který využívá předem stanovený pořadí transakcí k odhadu závislostí a tím snižuje počet zastavení.
Paralelní EVM
Ve srovnání s ne-EVM paralelním zpracováním, paralelní EVM čelí větším technickým výzvám při zpracování závislostí stavu, detekci konfliktů, správě plynu a mechanismech rollback. Abychom to lépe pochopili, můžeme se podívat na některé projekty paralelního EVM (jako Sui, Monad, Canto), jak tyto problémy řeší.
Sui
Sui a Aptos také používají objektový model pro práci se stavem a považují každý objekt (například účet, stav inteligentní smlouvy) za nezávislý zdroj, který se od sebe odlišuje pomocí jedinečných identifikátorů objektů. Když transakce zahrnují různé objekty, tyto transakce lze zpracovávat paralelně, protože operují na různých stavech a nevytvářejí přímé konflikty.
I když Sui používá objektový model pro správu stavů, pro kompatibilitu s EVM Sui architektura spojuje objektový model a model účtů EVM pomocí dodatečné adaptační vrstvy nebo abstraktního mechanismu.
V Sui se plánování transakcí provádí pomocí optimistické paralely, která předpokládá, že mezi transakcemi nejsou žádné konflikty. Pokud konflikt nastane, systém použije mechanismus rollback k obnovení stavu.
Sui používá objektový model a technologie izolace stavu, což efektivně předchází problémům se závislostmi stavu. Každý objekt jako nezávislý zdroj umožňuje různým transakcím paralelně vykonávat, čímž se zvyšuje propustnost a efektivita. Ale tento přístup má trade-off v podobě složitosti objektového modelu a nákladů na mechanismus rollback. Pokud dojde ke konfliktu mezi transakcemi, je třeba část stavu vrátit, což zvyšuje zátěž systému a může ovlivnit efektivitu paralelního zpracování. Na rozdíl od ne-EVM paralelních systémů (jako je Solana) vyžaduje Sui více výpočetních a úložných zdrojů k udržení efektivní paralelnosti.
Monad
Stejně jako Sui, Monad také používá optimistickou paralelu. Ale optimistická paralela Monadu před konkrétním vykonáním transakcí provádí predikce pro některé transakce se závislostmi, které se provádějí hlavně pomocí statického analyzátoru kódu Monadu. Predikce vyžaduje přístup k stavu, zatímco způsob, jakým Ethereum ukládá stav v databázi, činí přístup k stavu velmi obtížným. Aby byla paralela v procesu čtení stavu efektivnější, Monad také přestavěl databázi.
Monad stavový strom je rozdělen na části, přičemž každá část spravuje svůj vlastní podstrom stavu. Při aktualizaci je třeba měnit pouze relevantní fragmenty, není nutné přestavovat celý stavový strom. Rychlé lokalizování stavu v části pomocí tabulky indexu stavu snižuje interakci mezi částmi.
Shrnutí
Jádrem paralelního vykonání je zvýšení efektivity vykonávání prostřednictvím více cest, a aby bylo možné dosáhnout více cest, řetězec musí provést řadu kroků, jako je detekce konfliktů a mechanismus rollback, aby zajistil, že budou paralelně vykonávány, aniž by to ovlivnilo konečnou konzistenci stavu, a provést určité úpravy databáze.
Samozřejmě, že zlepšení efektivity vykonávací vrstvy nezávisí pouze na paralelním přístupu, optimalizace vykonávacího procesu může být také provedena snížením počtu potřebných čtení a zápisů do databáze pro jednu transakci. Celkový nárůst rychlosti řetězce zahrnuje širší oblast, včetně zlepšení efektivity konsensuální vrstvy.
Každá technologie má svá specifická omezení. Paralelní vykonání je pouze jedním ze způsobů, jak zvýšit efektivitu, konečné rozhodnutí o použití této technologie musí také brát v úvahu, zda je přátelská k vývojářům, zda ji lze dokončit bez obětování decentralizace atd. Hromadění technologií není vždy výhodné, alespoň pokud jde o Ethereum, paralelní vykonání není tak atraktivní; pokud se zaměříme pouze na zvyšování efektivity, přidání paralelního vykonání není pro Ethereum optimálním řešením, ať už z hlediska jednoduchosti nebo s ohledem na současnou cestovní mapu Ethereum zaměřenou na Rollup.
