Z pohledu vývojářů aplikací se model UTxO zásadně liší od modelu založeného na účtu. Model založený na účtu je jednoduchý a nabízí vývojářům vysokou flexibilitu, zejména pokud je nutné definovat složitou logiku provádění. Přílišná flexibilita však přichází na úkor záruk provedení, což má za následek zranitelnosti systému a útoky. Práce s modelem UTxO je složitější, ale nabízí vývojářům (potažmo uživatelům) několik výhod, zejména determinismus. Pojďme si to vysvětlit podrobněji.
Model UTxO z pohledu transakcí
V případě modelu UTxO lze transakci vnímat jako funkci, která spotřebovává jeden nebo více vstupních UTxO a vytváří jeden nebo více výstupních UTxO.
UTxO, které vstupují do transakce, jsou neměnné a jak si ukážeme později, z pohledu uživatele aplikace je možné zajistit exkluzivní přístup. Při validaci transakce je zajištěno, že hodnota vstupních UTxO je rovna hodnotě všech výstupních UTxO. Na úrovni validace všech transakcí v bloku je možné zajistit ochranu před útokem double-spend, jelikož každý vstup UTxO lze spotřebovat pouze jednou a zcela. Každý nově přidaný blok do hlavní knihy definuje přechod stavu týkající se vlastnictví UTxO.
Transakce jsou ze své podstaty bezstavové. Validace transakce závisí v podstatě pouze na vstupních UTxO. Je možné lokálně ověřit, že vstupní UTxO lze utratit transakcí (tj. využít). Přechod stavu je lokálně ověřitelný bez závislosti na jakémkoli jiném globálním on-chain stavu.
Je možné lokálně předvídat, jak transakce ovlivní on-chain stav. Jinými slovy, off-chain logika (uživatel nebo aplikace) může zajistit, že transakce neselže, pokud je odeslána do sítě.
Transakce téměř jistě nikdy selže, pokud má uživatel (nebo agent) výhradní právo utratit vstupní UTxO. To je případ, kdy Alice posílá mince nebo žetony Bobovi ze své vlastní peněženky. Vstup UTxO nemůže utratit nikdo jiný.
Podívejme se na jedinou možnost, kdy může transakce selhat. To je v zásadě omezeno na případ, kdy více agentů může utratit stejný UTxO. Jak si ukážeme později, může tomu tak být v případě poolu likvidity.
Na obrázku vidíte, jak se dva agenti snaží zkonstruovat transakci. Oba agenti mají správný poslední stav účetní knihy. Shodou okolností zvolili stejný vstup UTxO. Lokální off-chain ověření bude úspěšné. Oba agenti tedy předají transakci do sítě a předpokládají, že on-chain validace transakce bude také úspěšná.
Každý UTxO však lze utratit pouze jednou. Proto bude úspěšná pouze jedna transakce a druhá selže.
Na obrázku níže můžete vidět, že v následujícím bloku se do účetní knihy dostala pouze transakce 1. Transakce 2 se nezdařila.
Jak jsme již vysvětlili, tento stav může nastat pouze v případě, že uživatelé používají aplikaci, ve které jsou sdíleny UTxOs.
Představme si nyní běžnou decentralizovanou burzu (DEX) využívající několik poolů likvidity. Každý pool likvidity lze vnímat jako soubor obsahující několik UTxO s různými hodnotami. Uživatelé, kteří zadávají transakce za účelem provádění swapů, chtějí v podstatě získat část likvidity (tokeny), které jsou v poolu likvidity. V podstatě chtějí získat jeden nebo více UTxO z poolu likvidity. Jinými slovy, uživatelé mohou zadávat swapové transakce (téměř) paralelně a soutěžit o likviditu.
Klíčovým bodem je výběr vstupních UTxO pro transakce. Pokud nemají transakce selhat, musí se agenti vzájemně synchronizovat.
Cardano teoreticky umožňuje sestavit takovou aplikaci, která zajistí, že uživatelské transakce nikdy selžou. Off-chain aplikační logika (agenti) se musí vzájemně synchronizovat. Díky tomu je možné před odesláním transakce rezervovat konkrétní UTxO ze sdíleného poolu likvidity. Jinými slovy, lokální off-chain validace může zajistit, že transakce téměř jistě nezklame.
Na obrázku níže můžete vidět, že mezi agenty dochází k vzájemné off-chain synchronizaci před lokální validací transakcí. Každý agent si vyhrazuje jiné UTxO, takže obě odeslané transakce velmi pravděpodobně projdou on-chain validací.
Samozřejmě to bude fungovat pouze v případě, že je možné rezervovat UTxO. Může se také stát, že když se uživatel pokusí odeslat transakci, nebude k dispozici žádné vhodné UTxO. V takovém případě je možné počkat (a transakci neodeslat), nebo to risknout a počkat, jestli se později neobjeví vhodné UTxO. Podrobnosti závisí na konkrétní implementaci DEX a uživatelském rozhraní.
Model EUTxO přispívá k bezpečnosti a deterministické povaze Cardana. V tomto modelu nejsou transakce závislé na uživatelských účtech nebo zůstatcích jako v případě modelu založeného na účtu, ale spíše pouze na UTxO zapojených do transakce. To znamená, že pro danou transakci jsou důležité pouze zapojené UTxO, nikoli uživatelské účty, které mají globální povahu.
V UTxO modelu je balance konkrétního účtu v podstatě jen seznam UTxOs na adresách které náleží jednomu vlastníkovi.
Proč je model založený na účtu indeterministický
Blockchainy založené na účtech jsou nedeterministické, protože účinek transakce na účetní knihu je nepředvídatelný. Důvodem je, že uživatelské účty jsou ze své podstaty proměnlivé.
V blockchainu založeném na účtu lze transakci vnímat jako funkci, která mění zůstatky účtů. Každá transakce zahrnuje převod mincí nebo tokenů z jednoho účtu na druhý, což mění zůstatky těchto účtů.
Validace transakcí je závislá na účtech a jejich zůstatcích. To může vést k nedeterministickému chování, protože výsledek transakce závisí na stavu blockchainu v přesném okamžiku, kdy jsou zahrnuty do bloku.
Účty lze v systému považovat za sdílený zdroj. Všechny transakce jsou totiž zpracovávány celou sítí a každá transakce může potenciálně ovlivnit stav kteréhokoli účtu v systému. Tato sdílená povaha účtů je jedním z důvodů, proč jsou Ethereum a další podobné blockchainy považovány za stavové blockchainy.
Transakce v Ethereu lze považovat za stavové. Kompletní stav Etherea popisuje aktuální stav všech účtů a zůstatků, stejně jako kolektivní paměti všech smart kontraktů nasazených a běžících v EVM. Aktuální stav lze změnit transakcemi.
Vraťme se k našemu příkladu, kdy se dva uživatelé (agenti) pokoušejí zadat swapovou transakci, aby získali část likvidity (tokeny) z poolu likvidity.
Není možné rezervovat část konkrétního zůstatku pro transakci stejným způsobem, jako si můžete rezervovat UTxO v Cardano. Pokud by transakce dokázala zarezervovat část zůstatku z poolu likvidity a následně nebyla dlouhodobě zahrnuta do blockchainu (třeba kvůli nízkému poplatku), zablokovaly by provedení dalších swapů.
Svým způsobem jsou na sobě i jednotlivé aplikace závislé, protože aktivita v síti ovlivňuje cenu GAS. GAS cena ovlivňuje výběr transakcí a jejich pořadí v bloku. To vede k nedeterministickému chování.
V modelu AMM jsou pooly likvidity v podstatě rezervy dvou nebo více tokenů uzavřených v inteligentní smlouvě. Uživatelé obchodují s těmito inteligentními smlouvami spíše než mezi sebou a sazby jsou založeny na matematických vzorcích.
V ekosystému Ethereum uživatelé v podstatě soutěží o zůstatek nebo likviditu v daném poolu likvidity. Když uživatelé zadávají transakce paralelně, síť Ethereum upřednostňuje transakce na základě poplatků za GAS. Čím vyšší poplatek za GAS je uživatel ochoten zaplatit, tím vyšší je priorita jeho transakce. To znamená, že transakce s vyššími poplatky budou zpracovány jako první a budou mít první šanci spotřebovat likviditu.
Tato soutěž o likviditu může vést k tomu, co je známé jako GAS WARS, kde uživatelé neustále převyšují poplatky za GAS ve snaze, aby jejich transakce byly zpracovány co nejrychleji. To je jeden z důvodů, proč mohou být transakční poplatky na Ethereu někdy vysoké.
Na obrázku vidíte, že dva agenti chtějí spotřebovat stejný zůstatek. Oba agenti vidí, že zůstatek je dostatečný pro jejich transakci, a proto transakci zadají přibližně ve stejnou dobu. První agent stanoví vyšší poplatek než druhý.
Není zaručeno, že odeslané transakce budou úspěšné, ale uživatelé v zásadě musí podstoupit riziko a zkusit odeslání, pokud chtějí provést swap. Transakce s nízkým poplatkem může být zpožděna a jiné transakce s vyšším poplatkem mohou být upřednostněny. Transakce s nízkými poplatky mohou následně selhat. Poplatek bude účtován bez ohledu na konečný stav. Uživatel tedy platí za pokus o swap bez záruky, že se swap uskuteční.
Na obrázku vidíte, že uspěla pouze transakce 1, protože agent nastavil vyšší poplatek. Transakce 1 odčerpala tak velké množství likvidity z poolu, že transakci 2 nemohla být provedena. Druhý agent musel zaplatit poplatek, i když transakce 2 selhala.
Jak již bylo popsáno, agenti se nemohou vzájemně synchronizovat a vyhradit si část zůstatku ve poolu likvidity. Agenti reagují pouze na stav, který je platný v době, kdy se pokoušejí zadat transakci.
Nedeterminismus je také nevýhodný z hlediska spravedlnosti, protože poskytuje příležitost pro nepřátelské agenty zneužít zranitelnosti sítě. Známé jsou front-running útoky, kdy boti skenují transakce v mem-poolu a hledají vhodné příležitosti, ze kterých mohou profitovat. Pokud takové transakce najdou, stačí jim zadat podobnou transakci s vyšším poplatkem.
V našem případě by to znamenalo, že transakce obou agentů selžou, jelikož by útočník odčerpal veškerou likviditu z poolu pouze pro sebe.
V případě Cardana by podobný útok selhal, pokud by existoval off-chain rezervační systém, ve kterém by si agenti mohli zarezervovat konkrétní UTxO pro sebe.
Závěr
Vývojáři mají rádi model založený na účtech, protože je jednoduchý a snadno se s ním pracuje. Aplikace v podstatě pracují pouze s balancemi. Nevýhodou však je, že transakce se nechovají deterministicky a mohou selhat. Důvodem je skutečnost, že mezi okamžikem odeslání transakce uživatelem a jejím provedením se může změnit globální stav systému, tedy zůstatek na účtech.
Model UTxO je složitější na pochopení a výběr vstupních UTxO se může zdát poněkud těžkopádný. Je jednodušší odečíst částku z účtu a připsat ji na jiný účet, než muset vybírat více UTxO a vytvářet z nich nové výstupní UTxO (včetně UTxO, které vrací část hodnoty zpět na původní adresu). Vývojáři jsou nuceni přemýšlet o aplikacích s ohledem na paralelizaci. Musí se postarat o synchronizaci mezi agenty, aby nenastal problém se spory. Z uživatelského hlediska je ale možné vytvářet takové aplikace, které se budou chovat deterministicky. Pokud projde lokálni off-chain ověření, projde také on-chain ověření.
Článek připravili Cardanians s podporou Cexplorer.
Přečtěte si celý článek: https://cexplorer.io/article/eutxo-model-offers-determinism-to-users