Cardano je monolitický blockchain a upgrade Ouroboros Leios to nezmění. Mnoho týmů blockchainových projektů implementovalo sharding ve snaze dosáhnout vyšší škálovatelnosti. I Cardano by teoreticky mohlo jednou mít sharding. Rozhodně se tak však nestane dříve než po implementaci Ouroboros Leios. Prozkoumejme rozdíly mezi monolitickým a sharded blockchainem z hlediska konsensu. Téma je komplexní, proto se záměrně zaměříme jen na některé aspekty. V zájmu zjednodušení pro čtenáře si článek neklade za cíl poskytnout úplné a vyčerpávající informace.
Výzvy pro monolitický a sharded blockchain
Monolitický blockchain řeší všechny základní součásti systému, jako je konsensus, dostupnost dat a provádění, ve stejné vrstvě či prostoru. Všechny uzly účastnící se konsensu v síti sdílejí jeden prostor, ve kterém společně ověřují transakce a bloky.
Sharded blockchain rozděluje systém na menší podskupiny, kterým se říká shardy. Každý shard může zpracovávat část transakcí nezávisle a paralelně. Uzly jsou rozděleny mezi jednotlivé shardy. Pokud by v síti bylo 1000 uzlů a 10 shardů, bylo by 100 uzlů rozděleno do každého shardu podle specifických pravidel.
Shardy však na sobě nejsou nezávislé, protože jsou stále součástí jednoho systému. Každý systém, ať už monolitický, nebo využívající sharding, musí udržovat jeden platný globální stav.
Globální stav je reprezentací vlastnictví a převodu aktiv v blockchainu. Globální stav je ukládán a aktualizován uzly, které se účastní konsensu. Nezapomeňte, že jednou z klíčových inovací, které blockchain přináší, je ochrana proti útokům typu double-spend. Složité je tento úkol zvládnout v rámci distribuované sítě. Pro centralizovaný server je to snadný úkol.
Z hlediska bezpečnosti musí všechny uzly v síti znát globální stav.
V monolitickém blockchainu je globální stav uložen ve všech uzlech, což usnadňuje udržování konzistence a úplnosti dat v každém okamžiku. To však klade nároky na uzly z hlediska zdrojů (úložiště, šířka pásma, výpočetní výkon). Monolitický systém může mít tendenci k centralizaci, má vyšší nároky na výkon uzlů a je velmi obtížné (ne-li téměř nemožné) dosáhnout vysoké škálovatelnosti.
V sharded blockchainu je obtížnější udržet konzistenci globálního stavu, protože je udržován v jednotlivých shardech. Každý shard má pouze částečnou znalost globálního stavu, protože nemá k dispozici všechna data. Musí existovat nějaký synchronizační mechanismus (protokol), který zajistí konzistenci globálního stavu napříč jednotlivými shardy. To přináší složitost a problémy z hlediska bezpečnosti. Na druhou stranu je relativně snadné dosáhnout vysoké škálovatelnosti, protože transakce jsou ověřovány ve shardech. Počet oddílů je však omezen potřebou komunikace mezi oddíly.
Monolitický blockchain může mít jednodušší konsensus a je transparentnější. V případě Cardana to po přechodu na Ouroboros Leios nebude platit, protože budou existovat 3 verze bloků s různým časováním. Další výhodou je snadnější zabezpečení díky vyšší dostupnosti dat. Snadněji se zajistí odolnost proti útokům typu double-spend a replay. Díky vyšší dostupnosti dat je výrazně snazší zajistit bezpečnost. Monolitický blockchain je vysoce odolný vůči double-spend a replay útokům.
Největší výzvou pro monolitické blockchainy je dosažení rychlé konečnosti transakcí (a bloků) bez obětování decentralizace a zabezpečení. Složitost (vyšší nároky na komunikaci) může růst s počtem uzlů, což omezuje škálovatelnost.
Dodejme, že Cardano používá konsensus ve stylu Nakamoto, tj. pravděpodobnostní konečnost. Konečnost transakcí je tedy ve srovnání se sítěmi s prokazatelnou konečností (Ethereum) pomalá.
Největší výhodou sharded blockchainu je vysoká škálovatelnost dosažená díky paralelizaci při ověřování transakcí. Jinými slovy, ověřování transakcí je rozděleno mezi několik částečně nezávislých skupin uzlů (shardů). To má další výhody, protože se tím snižují požadavky na úložiště, šířku pásma a výpočetní výkon jednotlivých uzlů. Síť může být více decentralizovaná a může být ekonomičtější provozovat vlastní uzel. Nevýhodou je složitost, zejména pokud jde o synchronizaci a správu shardů, komunikaci mezi shardy, řešení konfliktů mezi shardy atd. Největší výzvou pro týmy vytvářející sharding je dosažení vysoké bezpečnosti a spolehlivosti v poměrně složitém systému, který je závislý na internetu.
Režie komunikace mezi jednotlivými shady
Podívejme se nyní na sharded blockchain z pohledu aktiv a aplikací. Je zřejmé, že pokud by na jeden shard připadal pouze omezený počet aplikací a aktiv (v extrémním případě jedna aplikace a jeden typ tokenu na jeden shard), utrpěla by uživatelská přívětivost a použitelnost systému. Nemá smysl mít například v jednom shardu pouze mince ADA, ve druhém shardu HOSKY a ve třetím shardu DJED. Jak by v takovém prostředí mohla fungovat decentralizovaná burza? Do kterého shardu byste ji umístili?
Tento problém řeší komunikace mezi jednotlivými shardy. Je to proces, který umožňuje shardům vyměňovat si informace a koordinovat akce v systému. Transakce mezi jednotlivými shardy zahrnují více shardů. Je nutné zajistit atomicitu a konzistenci mezi jednotlivými shardy. Ukažme si to na několika jednoduchých příkladech.
Pokud chce Alice poslat token X ze shardu 1 Bobovi na shard 2, musí systém zajistit, aby transakce byla platná, konečná a konzistentní na obou shardech a aby Alice nemohla token X utratit dvakrát na jiném shardu. Jak vidíte, uzly v jednom shardu nejsou schopny tuto transakci potvrdit a prohlásit ji za konečnou (kompletní). Je nutné, aby uzly z obou shardů transakci potvrdily. Je také nutné zajistit, aby token X nebyl utracen v ostatních shardech. Ostatní uzly (z jiných shardů) by také měly mít alespoň částečnou znalost stavu tokenu X. Vzpomínáte, když jsem mluvil o globálním stavu?
V případě aplikací je to velmi podobné. Chytré kontrakty mezi jednotlivými shardy vyžadují komunikaci mezi více shardy a data (nebo logiku) z jiných shardů. Například pokud chce chytrá smlouva DEX (nasazená na shardu 3) vyměnit token X ze shardu 1 za token Y ze shardu 2, systém musí zajistit, aby chytrá smlouva mohla přistupovat k datům a stavu tokenu X a tokenu Y na jejich příslušných shardech a aby se výměna provedla atomicky a konzistentně napříč shardy.
Nyní si zkuste představit, co to vše znamená v kontextu škálovatelnosti, časové synchronizace shardů, ukládání (dostupnosti dat), komunikace (šířky pásma), řešení konfliktů, prevence útoků, udržování globálního stavu atd. Synchronizace mezi jednotlivými oddíly je proces, který zajišťuje, že všechny oddíly mají konzistentní a aktuální pohled na globální stav systému.
Závislost shardu na ostatních shardech při validaci cross-shard transakcí (nebo chytrých kontraktů) je nežádoucí (ale nutná) vlastnost, protože shard není zcela autonomní (nezávislý na svém okolí). Pokud má jeden shard problémy (například v důsledku útoku, síťových problémů nebo nižšího výkonu), může to ovlivnit ostatní shardy, tedy celý systém. Síťový konsensus proto musí být navržen velmi pečlivě a musí tyto eventuality zohledňovat.
Pro týmy, které se snaží implementovat konsensus sharding, existuje jedna velká výzva. Co když velký (nadpoloviční) počet transakcí vyžaduje komunikaci napříč shardy? V takovém případě nemusí být sharded blockchain tak efektivní, jak se původně předpokládalo. Naštěstí sharded blockchainy již existují, takže můžeme jednotlivé implementace pozorovat a porovnávat.
Konečnost transakcí v kontextu škálovatelnosti
Pro pochopení tématu je nutné chápat konečnost transakcí v kontextu škálovatelnosti. Konečnost znamená, že jakmile je transakce jednou potvrzena sítí, nelze ji vrátit zpět ani změnit. To zajišťuje bezpečnost a integritu systému a zabraňuje dvojímu utrácení nebo útokům typu replay.
Konečnost ovlivňuje výkonnost a efektivitu systému, protože snižuje latenci a režii čekání na potvrzení nebo řešení konfliktů.
Zjednodušeně řečeno, dokud není transakce X finální, nemá aktivum, které bylo převedeno transakcí X, jistého vlastníka (může jím být původní odesílatel nebo nový příjemce). Je zřejmé, že opětovné použití tohoto aktiva (s nejistým vlastníkem) pro další transakci Y je “riskantní”, protože pokud je předchozí transakce X vrácena, měla by být vrácena i transakce Y (kterou se právě někdo snaží odeslat). Problém by mohl být zřetězený. Pro blockchain je obtížné revertovat jednu transakci, takže by bylo nutné revertovat celý blok. Tím by se výrazně narušila konzistence dat.
Konečnost je důležitá pro škálovatelnost obecně, ale zejména pro sharded blockchainy, protože umožňuje rychlejší a jednodušší transakce mezi jednotlivými bloky. Pokud transakce nejsou finální, mohou vytvářet nekonzistence nebo konflikty mezi jednotlivými shardy, což může ovlivnit škálovatelnost a bezpečnost systému.
Například pokud shard 1 potvrdí transakci, která převádí token X od Alice k Bobovi, ale shard 2 ji ještě nepotvrdí, Alice se může pokusit utratit token X znovu na shardu 2, což způsobí dvojí utrácení. Aby se tomu zabránilo, musí systém zajistit, aby transakce byla na obou shardech dokončena, než umožní Alici nebo Bobovi použít token X na jiných shardech.
Dalším důvodem, proč je konečnost důležitá pro škálovatelnost, je to, že umožňuje efektivnější a flexibilnější konsensuální protokoly. Konsensuální protokoly jsou pravidla, která určují, jak se uzly dohodnou na stavu blockchainu a jak řeší konflikty. Pokud transakce nejsou finální, mohou vytvářet forky nebo reorgy, což může ovlivnit škálovatelnost a bezpečnost systému.
Pokud například uzel A potvrdí blok, který obsahuje transakci T1, ale uzel B potvrdí jiný blok, který obsahuje transakci T2, mohou v blockchainu vytvořit fork, což může způsobit zmatek nebo nekonzistenci. K vyřešení tohoto problému musí systém používat konsensuální protokol, který si s forky nebo reorgy poradí (např. pravidlo nejdelšího řetězce). Tyto protokoly však mohou být pomalé, nákladné nebo složité, což může omezovat škálovatelnost a výkonnost systému.
Sharded blockchain nemůže fungovat efektivně a spolehlivě, pokud není zajištěna rychlá konečnost transakcí (prokazatelná konečnost), a to nejen v rámci shardů, ale také pro komunikaci mezi shardy.
Jak vypočítat propustnost systému?
Je obtížné odhadnout, který systém může mít vyšší propustnost. Problém spočívá v tom, že transakce nelze ověřovat nezávisle, tj. paralelně. Existují určité rozdíly mezi UTXO a blockchainy založenými na účtech, ale k tomu se ještě dostaneme. Pokud je k validaci transakcí nutná komunikace napříč řetězci, přináší to režii a latenci, což snižuje propustnost. Není možné vypočítat celkovou propustnost sharded systému vynásobením propustnosti shardu počtem shardů.
Podobně není možné vypočítat propustnost monolitických systémů vynásobením kapacity zpracování na validátor počtem validátorů. Validátory mohou mít různou kapacitu zpracování, takže je možné, že nejméně výkonný validátor ovlivní celkovou výkonnost systému. Záleží také na konkrétním konsensu.
Dosáhnout vysoké škálovatelnosti (a také rychlé finalizace) v monolitickém blockchainu není snadné. Existuje mnoho výzev a týmy musí pečlivě vyvažovat kompromisy. Rychlejší finalizace obvykle vyžaduje rychlejší tvorbu a šíření bloků, což může ohrozit bezpečnost a decentralizaci systému (riziko forků nebo reorgů). Rychlejší finalizace obvykle vyžaduje sofistikovanější protokoly nebo mechanismy (hlasování v rámci produkce každého nového bloku se musí účastnit mnoho uzlů), což může ohrozit jednoduchost a transparentnost systému. Konsensus s rychlou finalitou může vyžadovat více komunikace nebo synchronizace mezi uzly, což může zvýšit latenci nebo režii.
Sharded blockchainy mají v současnosti vyšší propustnost (alespoň na papíře), ale jejich spolehlivost se projeví až při vyšší zátěžy systému kdy bude nutné spracovávat cross-shard transakce.
Jak model účtování a konsensus ovlivňují škálovatelnost?
To, co může ovlivnit propustnost, je pro někoho překvapivě účetní model. Model založený na účtech, který používá Ethereum a většina platforem SC, neumožňuje paralelní zpracování transakcí. Při ověřování je nutné udržovat pořadí transakcí (systém udržuje sdílený globální stav). Jinými slovy, transakce jsou na sobě vzájemně závislé. Při validaci transakce je nutné brát v úvahu globální stav, který musí být v době validace neměnný (atomicita).
Model založený na účtech vyžaduje sekvenční zpracování transakcí v rámci jednotlivých shardů, ale i mezi nimi, protože každý účet může záviset na jiných účtech nebo transakcích (nebo s nimi být v konfliktu). Paralelizace prostřednictvím shardů může zlepšit propustnost systému, ale pouze v případě, že je efektivně řešena komunikace mezi shardy.
Cardano používá model Extended-UTXO (nebo jednoduše UTXO/eUTXO), který umožňuje paralelní zpracování transakcí. Transakce na sobě nejsou při ověřování závislé. Na jejich pořadí v bloku nezáleží.
Model UTXO umožňuje paralelnější zpracování transakcí v rámci shardů i mezi nimi, protože každý UTXO je nezávislý a lze jej ověřit bez odkazu na jiné UTXO (nebo účty).
Cardano by se potenciálně mohlo stát sharded blockchainem, ale nejprve musí tým implementovat rychlou konečnost (prokazatelnou konečnost). S pravděpodobnostní konečností nemá smysl o shardingu uvažovat. Alespoň z našeho pohledu. Jakmile bude Ouroboros Leios implementován, bude možné o shardingu uvažovat.
Vraťme se k finalitě transakcí a bloků. Konečnost je založena na hlasování (schvalování) transakcí uzly. Jakmile transakci schválí určité procento uzlů v síti, stává se nevratnou. Konečnost bloků (a tedy i transakcí) v síti Cardano je nyní pomalá, protože váha se zvyšuje s každým novým blokem přidaným do blockchainu. Hlasování (přidání nového bloku, a tím i schválení všech předchozích) může trvat až 1 hodinu pro pouze 10 % uzlů v síti Cardano.
Závěr
Škálovatelnost decentralizovaných blockchainů (L1) je velmi složité téma. Tým a komunita Cardano by měli zvážit implementaci shardingu, což však nelze provést bez zvýšení konečnosti transakcí. Musíme počkat na implementaci Ouroboros Leios a pak možná bude mít smysl začít o shardingu uvažovat. Účetní model UTXO je pro sharding vhodný, protože umožňuje paralelizaci nejen v rámci shardů, ale také pro komunikaci mezi shardy. Sharding je velkou technologickou výzvou, když vezmeme v úvahu zachování decentralizace, bezpečnosti, spolehlivosti a dalších věcí, jako je spravedlnost odměn. Pokud se druhé vrstvy neuchytí jako současná snaha o zvýšení škálovatelnosti, nezbude nám nic jiného než zvýšit škálovatelnost prvních vrstev. Na závěr ještě dodejme, že vedle shardingu existují další zajímavé možnosti jak zvýšit škálovatenost.
Článek připravili Cardanians s podporou od Cexplorer.
Přečtěte si celý článek v AJ: https://cexplorer.io/article/cardano-and-sharding