Mince a tokeny, říkejme jim dohromady aktiva, nejsou nic jiného než jen čísla. Na blockchain síť se můžeme dívat jako na globální účetní knihu, která eviduje zůstatky na účtech a stará se o přenos hodnoty mezi uživateli. Účetní kniha nám dává odpověď na otázku, kdo vlastnil jaká aktiva v daném čase.
V textu si vysvětlíme jak funguje model UTXO, se kterým přišel Bitcoin a porovnáme ho s modelem postaveným na účtech a balancích, který představil projekt Ethereum. Říkejme mu balanční model. Balanční model převzali téměř všechny chytré platformy jako třeba Polkadot, Algorand, Solana a další. Model UTXO se dočkal inovace, která dostala jméno Extended-UTXO (EUTXO). Tuto inovaci představil a úspěšně implementoval tým Input Output Global, který buduje Cardano. V textu se dozvíte, jak je možné dosáhnout stavových kontraktů nad UTXO modelem.
Upozornění: V článku budou některé věci mírně zjednodušené, aby bylo vysvětlení snáze srozumitelné laické veřejnosti.
Jak docílit změny stavu v blockchainu
Úkolem účetní knihy je zaznamenávat změny na jednotlivých účtech. S každou novou změnou dochází k aktualizaci. Blockchain je v podstatě specifická databáze, která dokáže zajistit neměnnost historických záznamů. Blockchain je pseudoanonymní, takže místo pomyslných účtů, jenž by reprezentovali konkrétní uživatele, se pracuje s adresami.
Z technického pohledu je blockchain stavový stroj, protože si pamatuje předchozí události, které se nazývají stavy systému. Tyto události představují interakce mezi uživateli. Stav lze měnit za předem definovaných podmínek. Každý protokol má implementovanou logiku, která umožňuje přechod ze stavu S do stavu S+1. Uživatelské transakce jsou požadavkem na změnu stavu. Jelikož jsou blockchain sítě ze své povahy globální, jsou jednotlivé transakce požadavkem na změnu globálního stavu.
V případě blockchainové sítě musí se změnou stavu souhlasit potřebná většina uzlů. Synchronizace celé sítě s každou jednotlivou transakcí by byla velmi neefektivní z hlediska zdrojů. Globální synchronizace uzlů je časově náročný proces, protože informace musí být rozeslané do celého světa. S rostoucím počtem transakcí by síť nebyla schopna včasné synchronizace.
Řešením je blok, který obsahuje více transakcí. V rámci synchronizace prostřednictvím bloků se zpracovává více uživatelských požadavků najednou. Jednotkou změny stavu je v decentralizovaných sítích blok. Každý nově vytvořený blok, včetně transakcí, musí být akceptován většinou, aby došlo k tranzici stavu. Respektive každý jednotlivý node se autonomně rozhoduje, jestli blok akceptuje. Na přijatý blok aplikuje pravidla protokolu a pokud je blok validní, je připojen na konec blockchainu.
Princip tranzice stavu na základě bloků je pro většinu současných sítí společný bez ohledu na použitý účetní model či konsensus. Na úrovni vykonávání chytrých smluv či skriptů je vše analogické v tom smyslu, že blok je požadavek na přechod do nového globálně platného stavu a musí obsahovat všechny relevantní data.
Role blockchain adres
Vlastnictví aktiv je v blockchainu reprezentováno vlastnictvím soukromého kryptografického klíče k dané veřejné adrese, která je odvozená od veřejného kryptografického klíče.
Transakci lze chápat jako konkrétní zprávu do sítě, v níž odesílatel dává pokyn k převodu vybraného počtu aktiv z adresy odesílatele na adresu příjemce. Platná transakce musí obsahovat důkaz, že odesílatel je skutečným vlastníkem tokenů. K tomu se používá soukromý kryptografický klíč, kterým se transakce takzvaně digitálně podepisuje. Síť, respektive každý jednotlivý uzel, je schopen podpis ověřit a vyhodnotit, zda je transakce platná. U jednoduchých transakcí je ověřování založeno pouze na dvojici soukromého a veřejného klíče.
Je důležité si uvědomit, že to, co uživatelé vnímají jako mince nebo tokeny, jsou z pohledu techniků ve skutečnosti jen digitální čísla (doslova jedničky a nuly) spojená s blockchain adresami. Účelem transakce je přenést číslo z dané adresy odesílatele a přiřadit stejnou hodnotu jedné nebo více adresám příjemce. K tomu je nutné počítat s poplatkem za transakci.
Platí, že hodnota na vstupu a výstupu transakce musí být vždy stejná. Během transakce nelze hodnotu vytvořit ani ztratit. Toto, ale i další pravidla, se vynucují během validace transakce. Má-li vzniknout nová hodnota (monetární expanze), existují k tomu dedikovaná pravidla.
Uživatelé se svými aktivy zacházejí jako se zůstatkem na svých účtech. Na základě seedu (passphrase) peněženky generují všechny potřebné páry soukromých a privátních klíčů, takže znají všechny veřejné adresy uživatelů. Všechny vytvořené adresy mohou obsahovat aktiva. Peněženka sečte všechny mince a tokeny na adresách (sečte všechna digitální čísla) a zobrazí je uživateli jako zůstatky.
Rozdíl mezi UTXO a balančním modelem na úrovni manipulace s aktivy
Rozdíl mezi UTXO a balančním modelem spočívá v tom, jak se nakládá se zůstatky a jak se aktiva přesouvají během validace transakcí, respektive při tranzici stavů. V širším kontextu je důležité, jaká pravidla a podmínky jsou definovány (a implementovány ve zdrojovém kódu uzlů) při vytváření nového bloku.
Nespotřebovaný transakční výstup (UTXO) je technický termín pro počet digitálních aktiv, která zůstávají po zpracované transakci. V UTXO modelu se převod aktiv zaznamenává jako směrovaný acyklický graf (DAG) mezi adresami. Každé UTXO je reprezentováno digitálním číslem a je abstrakcí aktiva. UTXO si můžete představit jako fyzické bankovky nebo mince, ale s tím rozdílem, že nejsou definovány nominální hodnoty, které UTXO musí mít. Například 10 mincí může být jedno UTXO. Také 12 mincí může být UTXO. Dokonce i 116,85 může být jedno UTXO.
Nyní si představte, že Alice má v peněžence všechny tři výše zmíněné UTXO. Nezáleží na tom, zda má všechny tři UTXO na stejné adrese, nebo zda je každé UTXO na své vlastní adrese. Pokud chce Alice znát svůj zůstatek, musí sečíst všechny UTXO. Její peněženka to udělá za Alici. Její zůstatek je 10 + 12 + 116,85 = 138,85 mincí.
Podívejme se, co se stane, když se Alice rozhodne poslat Bobovi 15 mincí. Bob má ve své peněžence 21 mincí na jedné adrese. Rozhodne se vytvořit novou adresu, na kterou od Alice obdrží 15 mincí. Peněženka patřící Alici musí použít 2 UTXO. Peněženka si vybere UTXO s 10 a 12 mincemi. UTXO s 10 mincemi je vyčerpáno v plné výši. Z UTXO s 12 mincemi se vybere pouze 5 mincí + 0,2 mince na transakční poplatek.
Po přijetí transakce bude mít Alice pouze 2 UTXO s 6,8 a 116,85 mincemi. Celkem bude mít Alice 123,65 mincí. Bob bude mít 2 UTXO s 21 a 15 mincemi. Celkem bude mít Bob 36 mincí. Na adresu pro poplatky bude přidáno 0,2 mince.
Přechod mezi dvěma stavy (bloky) byl proveden prostřednictvím transakce. Důležité je složení transakce. Transakce má vstupy (INPUT) a výstup (OUTPUT). Všimněte si, jak se hodnoty na vstupu mění na hodnoty na výstupu podle potřeby transakce, přesně tak, jak ji odesílatel (peněženka) sestavil. Každé UTXO v transakci musí být utracen jako celek, protože záznamy v předchozích blocích nelze upravovat. Vstupem je sada UTXO, které mají být utraceny, tj. celková hodnota bude transakcí použita k vytvoření výstupů. Výstupem transakce je rovněž sada UTXO, které budou přiřazeny nové adrese. Alternativně mohou být některé nebo všechny UTXO přiřazeny stejné adrese s různými hodnotami. Ukažme si příklad. Uživatel může mít na jedné adrese 3 UTXO a přeje si mít na stejné adrese (nebo jiné) pouze 1 UTXO. Celková hodnota mezi vstupem a výstupem zůstává vždy stejná.
V našem příkladu jsme měli 2 vstupy a 3 výstupy. Na vstupu byly 2 UTXO patřící Alici. Výstupem byly 3 UTXO. Konkrétně UTXO s 15 mincemi pro Boba, UTXO s 0,2 mincemi jako transakční poplatek a UTXO s 6,8 mincemi, což je částka vrácená Alici. Aby byla transakce platná, musí se počet mincí na vstupu shodovat s počtem mincí na výstupu. V našem příkladu je to 22 mincí.
Všimněte si, že model UTXO pracuje s jednotlivými UTXO při vytváření transakcí. Při utrácení určitého počtu tokenů je třeba vybrat potřebný počet vhodných UTXO. Pokud je součet tokenů ve vybraných UTXO větší než počet tokenů, které mají být utraceny, musí být zbytek vrácen jako nové UTXO na adresu odesílatele.
Lidem může připadat zvláštní, že je nutné vrátit Alici 6,8 mince. Je to podobné tomu, co vám vrátí pokladní v obchodě, pokud zaplatíte vyšší bankovkou, než je celková cena nákupu. Platí, že každé UTXO musí být utraceno v plné výši, takže je nutné zajistit, aby byl zbytek (pokud nějaký zbývá) vrácen Alici jako součást transakce.
S UTXO se zachází stejně jako se skutečnými penězi. Pokud máte v obchodě zaplatit 85 dolarů, můžete zaplatit 100dolarovou bankovkou a pokladní vám vrátí 15 dolarů (10dolarové a 5dolarové bankovky). Nemůžete nějak odstřihnout 85 dolarů od 100dolarové bankovky a zaplatit jí. V peněžence můžete najít 17 pětidolarových bankovek a zaplatit jimi. Stejně tak můžete mít v peněžence 17 UTXO s 5 mincemi.
Každé UTXO lze utratit pouze jednou a v budoucnu už nikdy. Po jeho utracení se vytvoří jedno nebo více nových UTXO, které lze následně utratit. Tento cyklus se neustále opakuje. Model UTXO je způsob organizace blockchainu který napomáhá tomu, aby žádná aktiva nebyla utracena dvakrát.
V každém bloku probíhá několik transakcí, takže se utratí mnoho UTXO najednou. Všechny transakce dohromady tvoří kolekci (blok), která jako celek představuje přechod mezi stavy. V modelu UTXO představuje celý graf výstupů transakcí, utracených i neutracených, globální stav. Je možné rozlišovat mezi aktuálním stavem a všemi předchozími stavy, což je v podstatě celá historie transakcí od prvního Genesis bloku.
Pokud by vás zajímal počet všech aktiv, které lze v aktuálním stavu utratit, museli byste spočítat všechny neutracené výstupy (UTXO). Jejich nalezení v podstatě znamená projít všechny transakce od Genesis bloku až po současnost. Plné uzly ověřují všechny transakce během synchronizace se sítí, takže znají aktuální sadu UTXO.
Podívejme se nyní na balanční model, který používá projekt Ethereum. Ten je principielně podobný bankovnímu účtu. Stejně jako u modelu UTXO jsou aktiva jen digitálními čísla, která jsou spojena s blockchainovými adresami. V balančním modelu je u daného typu aktiva na dané adrese udržován pouze aktuální zůstatek. Každá transakce upravuje zůstateky na adresách tak, že odečte hodnotu z jedné adresy a přidá ji na jinou adresu.
Ukažme si podobný příklad jako u UTXO. Alice má 138,85 ETH a rozhodne se poslat Bobovi 15 ETH. Bob má na svém zůstatku 21 ETH. Transakce odečte 15 ETH ze zůstatku Alice a přidá je k zůstatku Boba. Dále se ze zůstatku Alice odečte transakční poplatek ve výši 0,15 ETH (GAS).
Všimněte si, že vstupem transakce jsou dva účty, se kterými transakce manipuluje. Výstupem jsou právě dva změněné účty. V balančním modelu lze globální stav chápat jako databázi všech účtů a jejich aktuálních zůstatků různých aktiv v síti. S každým přidáním nového bloku se stav systému aktualizuje podle všech transakcí, které jsou v bloku obsaženy, tedy jako u UTXO modelu. Rozdíl je v tom, že počet účtů zůstává konstantní a nezávislý na počtu provedených transakcí, pokud zůstává konstantní počet uživatelů.
Všimněte si rozdílů mezi těmito oběma modely. Model UTXO na úrovni protokolu nepracuje s myšlenkou peněženky nebo balancemi. Model je založen pouze na historii transakcí. Zůstatek uživatele musí být zjištěn lokálně na základě historie převodů UTXO. V případě balančního modelu je aktuální platný stav jednotlivých účtů k dispozici téměř okamžitě.
Oba modely se liší také v tom, jak zpracovávají transakce. Model UTXO je ověřovací model. Transakce určují požadovaný výsledek přechodu stavu. Výsledek je definován jako nové UTXO, které je vytvořeno na základě vstupů transakce. Uzel ověřuje, zda jsou vstupy neutracené a zda je platný digitální podpis transakce. Případně se ověřují jiné podmínky utracení u složitějších transakcí, o čemž si více povíme níže. Balanční model je výpočetní model. Transakce dávají návod, jak má vypadat přechod stavu. Uzly na základě instrukcí v transakci vypočítají nový globální stav.
V obou případech může změna stavu vyžadovat exekuci (vykonání) složitější operace v podobě skriptu či chytré smlouvy (smart contract). Skripty a chytré smlouvy lze považovat za rozšíření instrukcí pro přechod stavu.
Rozdíly mezi modely na úrovni bloku, ověřování transakcí a programovatelnosti
Výhodou UTXO modelu je, že výpočet (využití počítačových zdrojů) při sestavování i ověřování transakcí se provádí off-chain. Transakce jsou jak výsledkem lokálního výpočtu, tak důkazem. Transakce stačí uložit do blockchainu tak jak jsou a není potřeba se dále zabývat stavy a jejich případným ukládáním.
Vstupy transakcí jsou vždy existující nespotřebované UTXO, což je pro každý synchronizovaný uzel snadné ověřit. Stejnou transakci, respektive stejné vstupy, nelze použít dvakrát. Ověřování je poměrně snadné, protože probíhá v rámci bloku, což je prostor s definovanou hranicí a k dispozici je také globální stav ze kterého se vyšlo. Pokus o dvojí utracení stejného vstupu je snadno odhalitelný a nebude akceptován.
Všimněte si, že transakce lze zpracovávat paralelně, protože nezávisí na žádném vnějším stavu. Každé UTXO musí obsahovat důkaz o právu na utracení (např. digitální podpis). Pokud uživatel sestaví transakci a projde lokální validace, včetně validace důkazu o právu na utracení, je téměř jisté, že bude transakce přijata celou sítí.
Vysoká míra determinismu (jistota, že po pozitivním lokálním ověření transakce dojde k akceptaci celou sítí) je z pohledu uživatelů také výhodou. Nicméně v případě Bitcoinu je zde malý háček. Pokud je síť zahlcená transakcemi, nemůže si být uživatel jistý, kdy se jeho validní transakce dostane do bloku. To je totiž závislé na poplatku. Pokud uživatel nastavil dostatečně velký poplatek v kontextu ostatních čekajících a nově vzniklých transakcí, může to být příští blok. Je-li poplatek nižší, transakce si bude muset na zařazení do bloku počkat předem těžko definovatelný čas. Každopádně transakce zůstavá nadále validní, takže se do blockchainu dostane. Uživatel má šanci vytvořit druhou validní transakci s vyšším poplatkem, která přeskočí a tím pádem zneplatní předešlou transakci (jak bylo řečeno, stejné UTXO nelze utratit dvakrát).
UTXO model má v případě Bitcoinu velmi slabou programovatelnost (není Turing-kompletní). Je téměř nemožné vytvořit složitý výpočet, neboť nejsou podporovány stavové kontrakty (skripty). Lze vytvořit velmi jednoduchý jednosměrný kontrakt, která má v podstatě jen binární výsledek. Je možné definovat sadu podmínek, které musí být splněny, aby se dalo dané UTXO utratit. To co je pro programátory složité je tyto podmínky definovat. Možnosti programovatelnosti Bitcoinu jsou velmi omezené, respektive vyjadřovací schopnosti jazyka odvozeného od Forth je velmi nízké a pro vývojáře dosti nepřívětivé.
Další limitací je omezenost při práci s externím on-chain kontextem. Pokus o vytvoření stavového kontraktu nad modelem UTXO často vede k vysokým nárokům na úložiště a nízké využitelnosti stavu. Každý vstup vyžaduje jeden “svědecký” (witness) skript a každý výstup vyžaduje jeden zamykací skript. S rostoucím počtem UTXO tedy roste i počet souvisejících skriptů. Výpočetní výkon potřebný pro ověřování skriptů spolu s potřebou ukládat skripty a související data zvyšují nároky na zdroje, a tedy i celkové náklady na poplatek.
Komplexnější finanční operace vyžadují práci se stavem, neboť to umožní vyhodnocení kontraktu na základě chování zainteresovaných stran či dalších vstupů, ať už interních nebo externích. V případě Bitcoinu se dají za určité maximum možného považovat HTLC kontraky. Ty v principu dovolují vytvořit platbu s časovou expirací a zajišťují možnost potrestání podvádějící strany v daném časovém okně.
Ethereum nepřevzalo UTXO model a představilo vlastní, který byl založeným na účtech s balancemi. Design Etherea je podřízený vyšší úrovni programovatelnosti. Z pohledu vývojářů je jednodušší pracovat s balancemi, než s UTXO.
Ethereum umožňuje napsat malý program se složitou logikou zvaný chytrý kontrakt (smart contract). Zcela zásadní rozdíl je, že transakce jsou interpretovány jako události, které mění globální stav (shared mutable data). Na základě nové události a aktuálního globálního stavu Ethereum Virtual Machine (EVM) provádí výpočet, jehož výsledkem je přechod z aktuálního stavu S do nového globálního stavu S+1.
Sdílený globální stav je stav, který je shodný na všech poctivých uzlech v síti. Jak bylo vysvětleno výše, impulzem pro změnu stavu je nový blok. Dá se říct, že Bitcoin i Ethereum mají aktuálně platný globální stav. Jak se dozvíte níže, v případě Etherea je globální stav důležitý nejen pro tranzici stavů na základě akceptace bloku, ale také uvnitř bloku samotného.
Při zpracování nové události je zcela zásadní, že předchozí stav se stává nedílnou součástí aktuálního výpočtu nového globálního stavu. Jinými slovy, výsledek vyhodnocování chytré smlouvy a tranzice do nového stavu závisí na aktuálním (tedy předešlém) stavu v rámci bloku. Každá událost je kriticky závislá na čase vyhodnocení, respektive na aktuálním globálním stavu.
Globální stav je udržován lokálně na uzlech a není přenášen v blocích. Uzly dosahují většinového konsenzu o novém globálním stavu tak, že lokálně provedou vlastní výpočet globálního stavu na základě transakcí (událostí) a poté porovnají svůj výsledek s přijatým výsledkem (State-Root). Jinými slovy, všechny poctivé uzly by měly po lokálním výpočtu získat stejný State-Root jako ten navržený. To je jediný způsob přechodu do nového globálního stavu v rámci celé sítě.
V balančním modelu jsou všechny účty stavové. To znamená, že v době výpočtu přechodu do nového stavu (zpracování chytrého kontraktu) je globální stav uzamčen, tedy je dočasně neměnný. Vývojáři mají k dispozici určitou abstrakci, která usnadňuje vývoj chytrých smluv. Mohou pracovat se všemi balancemi a interagovat s nimi. Na základě vypočteného výsledku se vytvoří nový globální stav, který se před dalším výpočtem, jehož výsledkem bude další nový stav, opět uzamkne. Nové globální stavy vznikají sekvenčně. Každá nová událost inicializuje nový přechod.
Výhodou je, že vývojáři mohou pracovat s libovolným účtem, protože globální stav je pro ně uzamčen (respektive pro daný kontrakt). Díky sekvenčnosti zpracování je v rámci jednoho bloku možné pracovat s konkrétním účtem vícekrát po sobě. Můžeme říct, že Ethereum je dobré v souběžnosti (concurrency).
Tento design je přívětivý pro vývojáře, protože se s ním snadno pracuje. Ethereum umožňuje napsat program s komplexní logikou. Na druhou stranu vývojáři nemohou kontrolovat pořadí zpracování transakcí a kontraktů, protože to je v rukou producentů bloků a uživatelů, kteří stanovují poplatky. Vývojáři tak musí počítat s mnoha možnými výsledky a pokusy o útok. To může představovat výzvu, neboť je nutné pracovat se stavem, který nemá daná aplikace plně ve své moci.
Dodržování posloupnosti při vyhodnocování událostí je důležité, protože je součástí obrany proti útoku dvojího utracení téže mince. Každý účet má hodnotu "nonce", která musí být obsažena v každé transakci. Při každé nové transakci z daného účtu se hodnota nonce inkrementuje. Tento mechanismus zabraňuje paralelnímu zpracování transakcí. Pokud první z několika transakcí modifikující určitý účet selže a není zahrnuta do bloku, selžou i následující transakce.
Je důležité si uvědomit, že transakce (události) na sobě závisí a záleží na jejich pořadí v bloku. Když uzel obdrží nový blok, přijme jej pouze v případě, že vypočítá stejný State-Root, který je v bloku navržen. K tomu dojde pouze v případě, že je dodrženo pořadí zpracovávaných událostí, to znamená, že lokálně musí dojít ke stejné posloupnosti přechodů. Proto není možné paralelní ověření jednotlivých událostí.
Pojďme to vzít ještě z jiného konce. Jednoduchou transakci lze chápat jako požadavek na změnu zůstatků dvou uživatelů. Transakce je událost, která mění globální stav, nikoliv konkrétní vstup a výstup tak jak je tomu u UTXO modelu. Proto musí být transakce vyhodnocena z hlediska správnosti v kontextu předchozího stavu. To platí univerzálně pro všechny akce (ověření transakcí i vyhodnocení komplexních kontraktů), které jsou postavené nad EVM.
Závislost na globálním stavu je určitá nevýhoda z pohledu determinismu systému. Uživatelé při zadávání nových transakcí reagují na určitý stav, například na cenu aktiva. Co uživatelé nemohou příliš ovlivnit, je očekávané umístění transakce v rámci posloupnosti přechodů v bloku. To může být problém u složitějších transakcí, které pracují s předem definovanými podmínkami, protože nelze předem zaručit, že navrhovaný přechod stavu bude během vyhodnocování stále platný. Uživatel nemá nikdy jistotu a nemůže si předem lokálně ověřit, že jeho transakce bude do bloku zařazena. V důsledku toho může transakce selhat navzdory zaplacenému transakčnímu poplatku. Změny stavu blockchainu na základě transakcí (aplikace transakcí na aktuální stav) mají vyšší míru nejistoty, jsou tedy nedeterministické.
Transakce, jejichž vyhodnocení selže, jsou důsledkem závislosti na globálním stavu. Více stran může chtít poslat transakce, které mají změnit globální stav určitým způsobem. Jednou změněný globální stav však může zabránit zpracování dalších poslaných transakcí. Jinými slovy, podle lokálního očekávání může být zpracována pouze první poslaná (a zařazená) transakce v daném čase za daných podmínek. Ostatní transakce mohou selhat, neboť se změní podmínky. To komplikuje vytvoření chytrých kontraktů a lze to považovat za prostor pro útoky.
Uveďme si konkrétní příklad. Uživatel Bob může sestavit transakci na základě stavu konkrétních zůstatků, které v daném okamžiku vidí. Tyto zůstatky však mohly být změněny transakcí Alice, která byla neočekávaně umístěna před transakcí Boba. Důvodů je mnoho. Alice mohla použít vyšší poplatek. Těžař se rozhodl zcela náhodně umístit transakci Alice před transakci Boba, protože poplatky byly stejné. Těžař zná Alici a nadržuje jí, nebo je Alice těžař. Důležité je, že v okamžiku, kdy je vložena Bobova transakce, je globální stav jiný než ten, který vzal v úvahu Bob. Tato změna globálního stavu může způsobit selhání transakce nebo v horším případě může vést k nepředvídatelnému stavu.
Shrňme si to. Balanční model, tak jak jej implementuje Ethereum, má pro vývojáře aplikací tu výhodu, že se nemusí starat o souběžnost. Vývojáři mohou volně pracovat s uživatelskými účty a měnit jejich zůstatek. Je zajištěno, že k jednotlivým zůstatkům se přistupuje jednotlivě na základě toho, v jakém pořadí se zpracovávají události. Na úrovni protokolu je ošetřeno, že dva agenti nebudou přistupovat ke stejnému zůstatku ve stejnou dobu. Návrh kontraktu je tedy poměrně snadný. Velká výhoda je, že tento design umožňuje uživatelům přistupovat k jednomu účtu vícekrát v rámci jednoho bloku. To znamená, že Alice může v rámci jedné transakce poslat ETH ze svého účtu Bobovi a v rámci jiné transakce poslat ze stejného účtu ETH také Carol. Obě transakce mohou být ve stejném bloku, přičemž nebudou, dle očekávání, vyhodnoceny jako pokus o dvojí utracení téže mince.
Design Etherea však v podstatě brání možnosti paralelního zpracování transakcí, což má negativní dopad na škálovatelnost. V jednom čase může existovat pouze jeden platný globální stav, což platí také v rámci přechodů mezi jednotlivými stavy na úrovni bloku. Doručit sharding na úrovni exekuce kontraktů bude pro tým Etherea pravděpodobně znamenat určitou separaci na úrovni uživatelů či aplikací. Případně určitou komplikaci nad konsensuální shodou nad jedním globálním stavem, jež bude vycházet z vícero mezistavů vzešlých z jednotlivých shardů.
Mezi další nevýhody patří časté selhání transakcí navzdory zaplacenému poplatku. Na základě nutnosti řadit transakce za sebe vzniká problém známý jako Miner Extractable Value (MEV).
Rozšířený UTXO model
Cardano používá model Extended UTXO, zkráceně EUTXO. Účelem modelu EUTXO je podporovat vyšší expresivitu programovatelnosti při zachování všech výhod modelu UTXO. Expresivita programovatenosti je vyšší díky funkcionálnímu programovacímu jazyku Plutus, jenž je odvozen od Haskellu. Programovatelnost je Turing-kompletní. Dále v textu narazíte na termíny chytré smlouvy a skripty. Jedná se o to samé, i když termín skript je v kontextu Cardana více přesný.
EUTXO nabízí oproti balančnímu modelu některé výhody, mezi než patří větší bezpečnost při provádění skriptů, předvídatelnost poplatků, vyšší úroveň determinismu, a přirozeně fragmentovaný stav blockchainu.
Mnohé výhody pramení z designu účetního modelu. EUTXO, stejně tak jako UTXO, má díky možnosti zpracovávat transakce paralelně obrovský potenciál na zvýšení škálovatelnosti v kontextu dalších inovací na úrovni protokolu. Paralelizace lze využít nejen pro validaci běžných transakcí, ale také pro vykonávání chytrých smluv. Je nutné si uvědomit, že možnosti škálovatelnosti se odvíjí od celkového designu protokolů a že i účetní model hraje významnou roli. Jak se dozvíte níže, s EUTXO modelem lze dosáhnout vyšší úrovně souběžnosti, což otevírá dveře ke zvýšení škálovatelnosti.
V případě EUTXO nemá pořadí v bloku žádný význam. UTXO lze vnímat jako samostatné neměnné objekty na jedno použití. Jednotlivé transakce i skripty lze validovat paralelně a výsledky validace jsou na sobě nezávislé. Každé ověření pracuje pouze se svým lokálním kontextem, který není externě ovlivněný. V rámci validace transakcí v bloku neexistuje něco jako globální sdílený stav. Validaci lze považovat za více bezpečnou, neboť je zde menší prostor pro útoky. Každá transakce může spotřebovat jedno nebo více EUTXO, čímž se vytvoří nové EUTXO. Jediný způsob, jak může transakce ovlivnit výsledek jiné transakce aplikované v ledgeru, je pokus o utracení stejného EUTXO, jaké se pokusí utratit pozdější transakce, a tím způsobit, že ji uzel odmítne.
Z uživatelského hlediska nabízí EUTXO zásadní rozdíl v možnosti lokálního (off-chain) ověření transakce a jejího výsledku. Pokud transakce projde lokální validací, může si být uživatel téměř jistý, že se transakce dostane do nového bloku, tedy že neselže. To platí i pro on-chain validaci Plutus skriptů.
Přestože je EUTXO model determinističtější než balanční model, může být transakce odmítnuta. Odmítnutí znamená, že přestože je transakce správně sestavena a je validní (off-chain), nemůže být aplikována v blockchainu (on-chain). Pokud se tak stane, transakce nemá žádný vliv na stav blockchainu, takže se neplatí žádné poplatky. K odmítnutí transakce dochází v případě sporu o stejný zdroj (contention). To znamená, že se stav blockchainu změnil přibližně ve stejnou dobu, kdy uživatel lokálně zkonstruoval transakci. Lokální ověření proběhlo, ale stav blockchainu je v okamžiku podání transakce již jiný. Determinismus dále zajišťuje, že kdykoli je transakce přijata, bude mít na stav ledgeru pouze předvídatelné účinky. Tedy že on-chain výsledek bude stejný jako při off-chain validaci.
V porovnání s balančním modelem klade EUTXO model na vývojáře vyšší nároky co se týká vypořádání se se souběžností (concurrency). Transakce se mohou dostat do konfliktu, pokud závisí na stejném EUTXO ve stejnou dobu (dochází k contention problému). Pokud by například několik EUTXO bylo uzamčeno skriptem, pak s nimi může uvnitř jednoho bloku interagovat pouze jeden agent. Toto omezení se vztahuje pouze na EUTXO. Různí agenti mohou interagovat s jinými skripty, aniž by došlo k selhání. Jeden skript může pracovat s řadou různých EUTXO, které tvoří jeho aktuální stav, a off-chain metadaty, která umožňují interpretaci těchto EUTXO.
V případě skriptů se bavíme o validaci takových transakcí, které mají v úmyslu utratit EUTXO, jež jsou uzamčeny adresou skriptu. Skript je program (kus kódu), který rozhoduje o tom, zda transakce, která chce utratit EUTXO, je k tomu oprávněna. Skript obsahuje funkce, jejichž výsledkem je buď True (pravda), nebo False (nepravda). Pro ověření transakce uzel spustí interpret skriptů, což je speciální program, který dokáže přeložit a spustit kód Plutus skriptu. Plutus interpret spustí skript, jehož hash byl vytvořen podle adresy, na které jsou uzamčeny UTXO. Jinými slovy, když je EUTXO uzamčeno Plutus skriptem, je kód skriptu tohoto EUTXO spojen s jeho adresou.
Podívejme se, co je na EUTXO ve srovnání s možnosti skriptování v Bitcoinu skutečně inovativní. Kromě vyšší expresivity programovatelnosti, kterou přináší Plutus, je to hlavně možnost práce s daty.
Rozšířené UTXO umožňuje uživatelům volitelně přidávat k EUTXO libovolná uživatelská data ve formátu podobnému JSON. Tato data se nazývají Datum. Datum umožní vývojářům dát skriptům funkcionalitu podobnou stavu. Uživatelská data tak lze považovat za lokální stav skriptu. Tento stav má pouze lokální platnost, protože je spojen s konkrétním UTXO. Využití plného potenciálu Datum na úrovni aplikační logiky je na vývojářích.
Rozšíření se dočkali také transakce, které mohou nést uživatelské argumenty, kterým se říká Redeemer. Na Redeemer lze pohlížet jako na záměr autora transakce, jak utratit UTXO. Redeemer mohou vývojáři decentralizovaných aplikací využít k různým účelům. Mezi daty uložené v Datum a Redeemerem může existovat nějaká logická vazba, která závisí na konkrétní funkcionalitě dané aplikace. Při ověřování transakce pracuje validační skript s Datumy, Redeemerem a kontextem, který obsahuje údaje o transakci. Skript obsahuje podmínky, které při jejich splnění umožňují spotřebovat UTXO. Datum, Redeemer a kontext transakce jsou data, která jsou vstupem skriptu.
Aby bylo možné skrze transakci utratit EUTXO, které jsou uzamčeny skriptem, je nejprve nutné dostat skript do blockchainu. Utracení EUTXO poté bude záviset na výsledku spuštění skriptu, kterému se předají vstupy.
Vývojáři (respektive off-chain část jejich aplikace) vytvoří on-chain kód Plutus skriptu a zabalí jej do speciálního formátu. Poté je třeba vytvořit transakci, do které bude skript vložen. Můžeme jí říkat Plutus transakce. Jakmile je tato transakce uložena v blockchainu, lze odeslat další transakci, která zahájí provádění skriptu (inicializuje utracení). Transakci lze považovat za jakousi zprávu pro skript.
Vývojáři rozdělují aplikace na on-chain a off-chain kód. Off-chain kód může být součástí peněženky, nebo se může jednat o decentralizovanou aplikaci (DEX). Off-chain část aplikace vytvoří Plutus transakci, která obsahuje on-chain skript a EUTXO, které mají být uzamčeny. Pro každé EUTXO je volitelně možné zadat hash Datumu, aby bylo možné pracovat s daty. Uživatel musí transakci podepsat. Jakmile je transakce v blockchainu, mohou se EUTXO utratit jen po úspěšné on-chain validaci přidruženého skriptu. Jakákoliv transakce (klidně z jiné aplikace), která splní podmínky pro utracení, dokáže odemknout EUTXO.
Validace skriptu je samozřejmě mnohem náročnější na zdroje než validace běžné transakce. Jedním ze zdrojů nízkého determinismu může být velikost poplatků za provedení chytrého kontraktu/skriptu. V případě Cardano je rozpočet na provedení skriptu součástí transakce a přesnou výši poplatku je možné vypočítat lokálně předem. Interpret skriptu sleduje spotřebované zdroje během provádění skriptu v kontextu rozpočtu. Pokud je rozpočet na provedení vyčerpán, vyhodnocování skriptu se zastaví a výsledkem je False. Hodnota False znamená, že EUTXO nebude spotřebováno. Možnost vypočítat přesný poplatek za provedení skriptu dopředu pramení z dalších vlastností protokolu a není přímou součástí tématu o účetních modelech.
Všimněte si, že Plutus skript pracuje pouze se stavem, který je přímo spojen s EUTXO, a dále s daty, která obdrží v transakci. Provádění skriptu z pohledu protokolu nezávisí na ničem jiném. Jediné, co se na úrovni účetní knihy (tedy na globální úrovni) změní, je přesun EUTXO z adres na jiné adresy s každým nově přidaným blokem.
Je dobré si uvědomit, že jeden stejný kontrakt lze použít k uzamčení mincí Alice a Boba. Provedení skriptu pro Aličiny mince nemá žádný vliv na provedení skriptu pro mince Boba, protože se jedná o dvě nezávislá provedení pro samostatné EUTXO. Výsledek obou samostatných provedení závisí na lokálních stavech.
Jak bylo řečeno výše, pro interakci se skriptem je vytvořena speciální transakce, říkejme jí transakce utracení. Tato transakce je adresovaná skriptu a vyvolá Plutus interpretr, který provede skript. Vstupem transakce může být EUTXO, které je uzamčeno daným skriptem. Jsou-li splněny podmínky pro utracení, EUTXO se převedou na novou adresu.
Některé aplikace mohou vyžadovat povědomí o izolovaném globálním stavu v kontextu vícero spravovaných EUTXO. Mohou k tomu použít Datum. Návrháři protokolů si musí být vědomi toho, že pokud jsou EUTXO uzamčeny skriptem, může s nimi uvnitř jednoho bloku interagovat pouze jeden agent. To může vyžadovat určitý druh synchronizace mezi agenty.
Ilustrujme si to na příkladu. Pooly likvidity, které používají AMM DEX, jsou sdílené zdroje, protože uživatelé je chtějí používat současně (v rámci jednoho bloku). Každý pool likvidity obsahuje sadu EUTXO. Dostupné EUTXO jsou tedy také sdílené zdroje, protože pokud si agent nějakým dohodnutým způsobem nevyhradí konkrétní EUTXO pro sebe, jsou k dispozici všem ostatním.
Aplikační algoritmus musí zajistit, aby při sestavování transakcí jednotliví agenti nesoupeřili o EUTXO v poolu. Transakce, které chtějí spotřebovat konkrétní EUTXO, jsou z hlediska validace na sobě nezávislé. Závislost však existuje, protože více agentů může chtít spotřebovat stejný prostředek (stejný EUTXO) ve stejnou dobu, aby vytvořili transakci. Jinými slovy, agenti chtějí pracovat souběžně. Jedním z vícero řešení, které se v současné době používá, jsou hromadné transakce (batch transactions). Agenti si vyhledávají vhodné UTXO v daném poolu a činí tak s ohledem na všechny ostatní dostupné požadavky na swap. Vybrané swapy vloží do jedné velké dávkové transakce. Při vytváření dávkové transakce agenti vědí, jaké EUTXO již byly použity. Mohou tak zajistit, aby konkrétní EUTXO nebylo v rámci dávkové transakce použito dvakrát, stejně tak, jako že nebude použité v jiné dávkové transakci v rámci jednoho bloku.
V době psaní tohoto textu se chystá uktualizace protokolu, které přinese mnohá zajímavá vylepšení při práci se skripty.
Závěr
UTXO a potažmo Extended-UTXO jsou v porovnání s balančním modelem dva naprosto odlišné koncepty. To má samozřejmě vliv na další vlastnosti, ať už jsou to možnosti škálovatelnosti, nebo schopnost vytvořit na první vrstvě nějakou funkcionalitu. To je důležité, neboť kdyby sítě uměli pouze přenos hodnoty z adresy na adresu v rámci vlastního blockchainu, nebylo by možné hodnotu přenést do jiné sítě decentralizovaným způsobem a pracovat přitom s nějakým stavem. Schopnost rozhodnout se a autonomně reagovat na stav který vzešel z interace mezi účastníky je klíčová vlastnost pro mnoho finančních operací. Každá interakce s druhou stranou je v principu riziková, neboť protistrana se může zachovat jinak než očekává první strana. V případě problému se nabízí otázka kdo vlastně spor vyřeší. Má to být důvěryhodná třetí strana, nebo nám může pomoc technologie, která rozhodne podle předem jasně definovaných pravidel. Fanoušci decentralizace budou spíše pro druhou možnost. Programovatelnost první vrstvy je nezbytný předpoklad pro vznik vrstev druhých, pokud se nechceme spoléhat na třetí strany. A to nechceme ani v případě, že jsou finanční operace komplexnější. Každopádně kdyby se někdy měla programovatelnost Bitcoinu zvýšit, Cardano je fungující příklad jak toho nad UTXO modelem docílit.
Nedá se jednoznačně říct, jestli je z pohledu vývoje DeFi aplikací lepší balanční model u Etherea, nebo EUTXO u Cardana. Oba přístupy mají výhody i nevýhody. Vytvořit dobře fungující a hlavně bezpečnou aplikaci je složité v obouch případech. Cardano má běžící decentralizované směnárny (DEX) a další projekty. Dokonce vzniká směnárna, která se nebude držet klasického “AMM” modelu a bude fungovat s order bookem. Ethereum má výhodu, že je tu delší dobu a že tento model převzalo mnoho jiných projektů. Vyvojáři se mohou navzájem inspirovat a společně uvažovat nad inovacemi. Cardano není jediný projekt, který se rozhodl jít po vlastní ose a vsadit na UTXO. Takových projektů je víc a spojili své síly v alianci, která si klade za cíl rozvíjet UTXO model.
[twitter-follow username="btctip_cz" scheme="dark"].
[easy-social-share buttons="facebook,twitter,linkedin" counters=1 counter_pos="inside" hide_names="no" template="tiny-retina"]
[feature_box style="10" only_advanced="There%20are%20no%20title%20options%20for%20the%20choosen%20style" alignment="center"]
Nakupujte a prodávejte kryptoměny na největší kryptoburze Binance!
Nejlepší podmínky najdete na burze Binance – na tomto odkazu získáte při NOVÉ registraci VIP stálou 20% slevu na poplatcích!
[/feature_box]
