Tým IOG se nestará o to, jestli je medvědí nebo býčí trh, a neustále vylepšuje protokol Cardano. Důležitá je dlouhodobá vize. Tímto způsobem tým dodává to, co komunita očekává. Pojďme se podívat, co dlouho očekávaný upgrade Vasil do Cardana přináší.
Aktualizace jsou budoucnost
Žádná digitální technologie se neobejde bez týmu, který čas od času opravuje chyby a přináší zásadní vylepšení. Blockchain je technologie a je třeba ji vylepšovat, protože pouze zvyšování efektivity, nové možnosti a snižování nákladů pro uživatele přinese dlouhodobý úspěch v podobě širšího přijetí. To platí jak pro současné IT giganty, tak pro technologii blockchain, která přišla na svět před více než 10 lety jako velmi neefektivní. Mají-li blockchain sítě jednoho dne využívat stovky milionů uživatelů denně, je nezbytná neustálá inovace.
Cardano je navrženo tak, aby bylo schopno pravidelně a bez přerušení provozou sítě inovovat. Cardano je globální síť, takže není možné ji dočasně vypnout, aby se síť aktualizovala. Tým našel způsob, jak provádět aktualizace a zároveň neovlivnit používání sítě. Vytvořili k tomu nástroj hard-fork combinator. Hard-fork combinator umožňuje nasazení aktualizací bez omezení používání. Uživatelé si ani nevšimnou, že byla vylepšení nasazena. Mohou je však začít okamžitě používat.
Aktualizace Vasil přináší významná vylepšení výkonu a schopností protokolu Cardano. Upgrade je součástí uzlu Cardano verze 1.35.0 a síť se na něj připravuje. Nejdůležitějším vylepšením v upgradu Vasil je především Diffusion pipelining, který bude mít vliv na lepší škálovatelnost. Existuje také několik CIP (Cardano Improvement Proposal), které se týkají platformy Plutus.
Diffusion pipelining
Diffusion pipelining zefektivňuje šíření informací o nově vytvořených blocích mezi účastníky sítě Peer-to-Peer. Toto vylepšení umožňuje šířit informace o bloku ještě předtím, než je blok v uzlu plně validován. To umožňuje paralelizovat ověřování a distribuci bloků.
Propustnost sítě lze zefektivnit zvětšením velikosti bloku a zkrácením intervalu, v němž jsou nové bloky vytvářeny. Do většího bloku lze vložit více informací, například transakcí. Čím častěji jsou bloky vytvářeny, tím více uživatelských požadavků bude za daný čas zpracováno.
Zvětšování velikosti bloku (block size) a zmenšování času bloku (block time) má omezení vyplývající z možností internetu. Cardano je globální síť s uzly po celém světě. Pokud uzel vytvoří nový blok například v Evropě, musí se blok postupně dostat přes další uzly do Asie, Jižní a Severní Ameriky, Austrálie a dalších míst. Každý jednotlivý uzel informaci ověří, než ji může dále distribuovat svým kolegům. To znamená, že než se blok dostane alespoň k 95 % uzlů v síti, uplyne určitá doba zvaná zpoždění (Delay). Tato doba je v síti Cardano maximálně 5 sekund. Zpoždění nastavené na 5 sekund je doba potřebná k zaručení šíření bloku, jehož velikost nepřesahuje 2 MB.
Je zřejmé, že čím větší je blok, tím déle trvá jeho validace (čas procesoru), a tím déle trvá jeho distribuce. V síti Cardano je nutné validovat nejen transakce, ale také skripty Plutus. Validace skriptů je výpočetně náročnější než validace transakcí. S rostoucí velikostí bloku může růst i počet skriptů v něm, takže poroste i doba validace celého bloku.
Všimněte si, že čas bloku musí být nastaven na delší dobu, než je “očekávané” zpoždění (Delay), aby byla dostatečná rezerva pro šíření bloku sítí. V případě Cardano je nyní doba bloku (block time) nastavena na 20 sekund. Pokud lze dobu šíření bloku zkrátit, lze postupně zkrátit i dobu bloku. To povede k vyšší propustnosti.
Jak vlastně probíhá validace bloků? Pro zjednodušení si můžete představit, že každý uzel má tři vrstvy. Úplně dole je síťová vrstva, která přijímá a odesílá data přes internet. Síťová vrstva může přijímat a odesílat bloky. Blok může být zpracován po částech, tj. jako hlavička a tělo bloku. Druhou vrstvou je vrstva konsensu. Na této úrovni probíhá validace hlavičky (bock head) a těla bloku (block body). Ověřování těla bloku je výpočetně náročnější než ověřování hlavičky. Třetí vrstvou je blockchain, který přijímá platné bloky. Lze si to představit jako přesun informací ze spodní vrstvy na horní. Do blockchainu se dostanou pouze platné bloky. Neplatné bloky budou na základě konsensu vyřazeny, takže nebudou uloženy v blockchainu ani distribuovány dále do sítě.
Podívejme se nyní zjednodušeně na to, jak je blok distribuován v síti Peer-to-Peer. Představte si, že producent bloku právě vytvořil nový blok. Podíváme se na to, co musí udělat validátor bloku. Producent bloku odešle validátoru bloku hlavičku bloku. Validátor bloku musí ověřit, zda hlavička odpovídá pravidlům protokolu. Například musí ověřit, že producent bloku byl skutečně zvolen vedoucím slotu (musí být předložen důkaz), že digitální podpis je správný a že nový blok správně odkazuje na předchozí blok. Pokud je hlavička bloku v pořádku, stáhne se i tělo bloku. Hlavička bloku obsahuje odkaz na tělo bloku. Validátor bloku ověří, zda je odkaz správný, a pokud ano, může ověřit transakce a spustit skripty Plutus. Pokud je tělo bloku správné, může validátor bloku přidat blok do své verze blockchainu a dále distribuovat blok do sítě dalšímu peerovi (dalšímu validátoru bloku).
Všimněte si, že každý validátor bloku musí před jeho redistribucí ověřit jak hlavičku, tak tělo bloku. Celkovou dobu potřebnou k distribuci bloku do celé sítě získáme vynásobením průměrné doby validace na jednom validátoru bloku počtem skoků (hops) v síti.
Diffusion pipelining urychlí distribuci bloků v síti tím, že validátor bloku odešle do sítě tělo bloku před validací obsažených dat. Validátor bloku ověří pouze odkaz mezi hlavičkou a tělem a pokud je v pořádku, okamžitě blok rozšíří. Validátor musí ověřit, že obdržel blok, který patří k přijaté hlavičce. Validace odkazu (hash těla musí být shodný s hashem jež je v hlavičce) trvá jen krátkou dobu ve srovnání s validací zbytku těla. To znamená, že celkový rozpočet na distribuci bloku do celé sítě je snížen o čas, který by jednotlivé skoky strávily validací těla bloku. Jinými slovy, validace těla bloku a distribuce bloku probíhají současně. Diffusion pipelining zvyšuje rychlost dostupnosti dat.
Všimněte si, že tělo bloku na začátku distribuce do sítě ověřuje pouze producent bloku (vedoucí slotu). Všechny ostatní uzly distribuují celý blok po ověření pouze hlavičku bloku a odkazu v těle bloku.
Neúplné bloky nejsou v síti distribuovány, protože pokud validátor bloku neobdrží tělo bloku se správným odkazem, celý blok zahodí. Pokud je odkaz v těle bloku správný, ale následná validace těla selže, poctivé uzly celý blok zahodí.
Všimněte si, že změna na úrovni sítě nemá na konsensus žádný významný vliv. Veškerá validace nutná k přijetí bloku a jeho přidání do blockchainu probíhá stejně jako před upgradem. Diffusion pipelining zvyšuje rychlost šíření bloků v síti, čímž se otevírají možnosti pro zvětšení velikosti bloku a potenciální zkrácení doby bloku.
Spočítejme, o kolik rychleji se blok šíří od producenta bloku přes 4 validátory, pokud validace hlavičky trvá 50 ms a validace těla 250 ms. Výrobu bloku započítáme do celkového času, protože producent musí validovat tělo. Bez diffusion pipeliningu trvá validace celého bloku v každém uzlu 300 ms. Doba propagace od producenta bloku ke čtvrtému validátoru bloku tedy trvá 5 * 300 ms, což je 1500 ms (1,5 s).
S diffusion pipeliningem trvá validace bloku pouze dobu potřebnou k validaci hlavičky (50 ms) a ověření reference mezi záhlavím a tělem bloku, což představuje třeba 5 ms. Pouze 55 ms je potřeba k tomu, aby byl blok dostatečně validován a distribuován peerovi. Celková doba distribuce bloku bude trvat 300 + (4 * 55), což je 520 ms.
V následující tabulce jsou uvedena vylepšení, kterých lze dosáhnout upgradem. Na posledním řádku jsou uvedeny údaje pro asynchronní ověřování (AV). AV není součástí upgradu Vasil a je dalším možným vylepšením, které rozšiřuje Diffusion pipelining.
CIPs spojené s vylepšením Plutus platformy
Začněme CIP-32, který se týká ukládání dat (Inline Datum). Rozšířené UTXO umožňuje uživatelům volitelně přidávat do UTXO libovolná uživatelská data ve formátu podobném JSON. Tato data se nazývají Datum. Datum umožní vývojářům dát skriptům funkčnost podobnou stavu. Uživatelská data lze považovat za lokální stav skriptu. Tento stav má pouze lokální platnost, protože je spojen s konkrétním UTXO.
V současné době je Datum implementováno připojením hashů dat k výstupům (output) a požadavkem, aby spending transakce poskytla Datum (uživatelská data). Data ze spending transakce se ověřují vytvořením hashe, který se musí shodovat s hashem uloženým v Datum.
Výhodou je úspora místa v blockchainu, protože Datum obsahuje pouze hash k datům, která mohou být libovolně velká. Nevýhodou je, že data, jejichž hash je stejný jako hash v Datum, musí být přítomna v transakci. Dodejme, že teoreticky mohou data být například jen krátké číslo, které může být menší než hash. V takovém případě by bylo výhodnější mít data přímo v Datum, nikoliv v hashi.
Datum obsahuje data, která reprezentují nějakou aplikační logiku. Data v Datum vkládá strana, která vytváří výstup transakcí Plutus. Protistrana (uživatel dat) musí této aplikační logice rozumět, tj. musí rozumět obsahu Datum, a to není možné bez komunikace se stranou, která výstup vytvořila. Tato komunikace musí probíhat buď mimo řetězec (off-chain), nebo jiným způsobem on-chain. To může být pro protistranu nepohodlné.
CIP-32 navrhuje, aby Datum mohl obsahovat buď přímo data (inline data), nebo hash dat, jak je tomu nyní. Transakce Plutus umožňují zvolit jeden z těchto přístupů.
Pokud by údaje byly přímo v Datum, nebylo by nutné je vkládat do spending transakcí. Nezapomeňte, že uživatel může stále používat Redeemer jako vstup pro skript Plutus.
Tento nový přístup k práci s data v Datum usnadní práci vývojářům dApp, zejména v kombinaci s CIP-31.
CIP-31navrhuje vytvořit nový druh vstupu (input), referenční vstup (reference input), který by umožňoval podívat se na výstup (output), aniž by bylo nutné jej utratit (spend). To umožní přístup k informacím, které jsou uloženy v blockchainu ve formě Datum, aniž by bylo nutné utrácet a znovu vytvářet UTXO, které jsou s Datum spojené. Kromě toho bude možné zkontrolovat hodnotu související s referenčním vstupem (například počet ADA či tokenů).
Datum v podstatě poskytuje způsob, jak ukládat data v blockchainu a přistupovat k nim. Můžete se na něj dívat jako na zdroj informací. Bohužel přístup k datům v Datum je v současné době v mnoha ohledech omezen. Abyste mohli k informacím přistupovat a používat je, musíte utratit výstup, který je s Datem spojen.
Aplikace může potřebovat informace použít, a pokud si je chce ponechat pro budoucí použití, musí vytvořit nový výstup se stejnými informacemi. Nevýhodou je, že se vytváří nový výstup, takže pokud chce k informacím přistupovat někdo jiný, nemůže použít starý výstup, ale nově vytvořený. Nový výstup se však vytvoří až po přidání nového bloku. V praxi to znamená, že některé aplikace jsou omezeny na jednu operaci na blok.
Navíc, pokud se chce strana podívat na informace v Datum a je nucena utratit výstup, pak to znamená, že musí být splněny podmínky pro utracení a strana musí zvážit, co s prostředky udělá. To je nepohodlné a hlavně drahé.
CIP-31 to změní. Autor transakce specifikuje vstupy buď jako k utracení, nebo referenční. Referenční vstup je vstup transakce, který je normálně spojen s konkrétním výstupem transakce, ale jen se na něj odkazuje místo toho aby se utratil.
Jinými slovy, nyní je třeba zaplatit transakční poplatek, abyste získali informace z Datum, protože je nutné výstup utratit. Po upgradu Vasil můžete získat informace téměř zdarma v kontextu spending transakce, která se chystá utrácet jiné UTXO. Všimněte si, že i když transakce obsahuje odkaz na vstup, musí stejně utratit alespoň jeden výstup. Poplatek za transakci tedy musí být zaplacen vždy.
Referenční výstup se nebere v úvahu při vyvažování transakce, tj. při kontrole, zda je hodnota na vstupu stejná jako hodnota na výstupu transakce. To znamená, že podmínky utracení pro referenční výstup se vůbec nekontrolují. Referenční výstup zůstává v aktivní sadě UTXO pro budoucí použití. Důležité je, že referenční vstupy jsou pro skripty viditelné, takže data z Datum těchto referenčních vstupů lze použít jako vstup pro rozhodovací logiku skriptu.
Skript získává informace o transakcích prostřednictvím kontextu skriptu. Nově získává další informace o tom, že může být zahrnut seznam referenčních vstupů. Skript tak bude vědět, jak s referenčními vstupy správně pracovat.
Transakce má jako vstup UTXO, který má být utracené, a zároveň může mít i referenční vstup. Referenční vstup lze použít během provádění skriptu Plutus. Po validaci a zařazení transakce do bloku je UTXO utraceno, ale referenční vstup zůstává nezměněn a může k němu následně přistupovat jiná strana. Informace v Datum jsou tak k dispozici po delší dobu pro více uživatelů.
Aplikace mohou například zkontrolovat stav (Datum nebo uzamčenou hodnotu), aniž by musely spotřebovat výstup. Poskytovatelé dat v řetězci mohou v Datum ukládat libovolná data a jiné skripty (aplikace) mohou k těmto datům přistupovat. Za uložení dat v blockchainu se platí pouze jednou, a pak budou k dispozici ostatním.
CIP-33 využívá CIP-31 a CIP-32, aby umožnil připojování skriptů k výstupům. CIP-33 zavádí referenční skripty, které lze použít ke splnění požadavků na skripty během validace.
Pokaždé, když má být skript použit, musí transakce, která jeho použití vyžaduje, poskytnout celý skript jako součást transakce. Tím se blockchain nafukuje a zvýšují se poplatky pro uživatele. Pokud transakce používá více skriptů, může narazit na problém s omezením maximální velikosti.
Referenční vstup a inline Datum tento problém řeší tím, že umožňují uložení skriptu v blockchainu. Pak na něj lze odkazovat opakovaně. Spending transakce, která chce utratit UTXO, může odkazovat na skript, který se použije pro ověření. To znamená, že transakce, která skript používá, nemusí nést jeho obsah. Musí pouze odkazovat na výstup, ve kterém se skript nachází.
Při validaci transakce, kdy je třeba uvést skript odpovídající hash skriptu, se kromě skriptů uvedených v samotné transakci budou brát v úvahu i případné referenční skripty z výstupů, na které odkazují vstupy transakce. Jinými slovy, bude použit odkaz na skript (který již byl uložen v blockchainu).
Díky tomuto vylepšení nemusí aplikace opakovaně odesílat skripty pokaždé, když je chtějí použít. Skript bude uložen v blockchainu a bude jej možné opakovaně použít pro více UTXO. Stejný skript může používat více stran.
Závěr
Popsali jsme hlavní vylepšení, která Vasil upgrade přinese. Ve skutečnosti bude upgrade obsahovat několik dalších drobných vylepšení. Zvýšení škálovatelnosti a vylepšení platformy Plutus otevírá nové možnosti pro vývojáře a výhody pro uživatele. Tým již pracuje na návrhu nových vylepšení. Neváhejte a používejte nástroj Cexplorer, který je na upgrade Vasil připraven.
Upgrade byl pojmenován na počest zesnulého Vasila St. Dabova, velvyslance společnosti Cardano a velkého podporovatele projektu, který bohužel v roce 2021 zemřel.
Článek byl vytvořil tým Cardanians s podporou Cexplorer.