­č窭čç░ ─îo prin├í┼ía aktualiz├ícia Vasil do Cardana

Čo prináša aktualizácia Vasil do Cardana

T├şm IOG sa nestar├í o to, ─Źi je medved├ş alebo b├Ż─Ź├ş trh, a neust├íle vylep┼íuje protokol Cardano. D├┤le┼żit├í je dlhodob├í v├şzia. T├şm tak prin├í┼ía to, ─Źo komunita o─Źak├íva. Po─Ćme sa pozrie┼ą na to, ─Źo dlho o─Źak├ívan├í aktualiz├ícia Vasil prin├í┼ía do syst├ęmu Cardano.

Aktualiz├ície s├║ bud├║cnos┼ą

┼Żiadna digit├ílna technol├│gia sa nezaob├şde bez t├şmu, ktor├Ż z ─Źasu na ─Źas opravuje chyby a prin├í┼ía v├Żznamn├ę vylep┼íenia. Blockchain je technol├│gia a je potrebn├ę ju vylep┼íova┼ą, preto┼że len zvy┼íovanie efektivity, nov├ę mo┼żnosti a zni┼żovanie n├íkladov pre pou┼ż├şvate─żov prines├║ dlhodob├Ż ├║spech v podobe ┼íir┼íieho prijatia. To plat├ş tak pre s├║─Źasn├Żch IT gigantov, ako aj pre technol├│giu blockchain, ktor├í pri┼íla na svet pred viac ako 10 rokmi ako ve─żmi neefekt├şvna. Ak m├í jedn├ęho d┼ła blockchainov├║ sie┼ą pou┼ż├şva┼ą stovky mili├│nov pou┼ż├şvate─żov denne, je nevyhnutn├ę pokra─Źova┼ą v inov├íci├ích.

Cardano je navrhnut├ę tak, aby bolo schopn├ę pravidelne inovova┼ą bez preru┼íenia. Cardano je glob├ílna sie┼ą, tak┼że nie je mo┼żn├ę ju do─Źasne vypn├║┼ą, aby sa sie┼ą aktualizovala. T├şm na┼íiel sp├┤sob, ako vykon├íva┼ą aktualiz├ície a z├írove┼ł neovplyvni┼ą pou┼ż├şvanie siete. Vytvorili na to n├ístroj hard-fork combinator. Hard-fork combinator umo┼ż┼łuje nasadi┼ą aktualiz├ície bez obmedzenia pou┼ż├şvania. Pou┼ż├şvatelia si ani nev┼íimn├║, ┼że boli nasaden├ę vylep┼íenia. M├┤┼żu ich v┼íak za─Źa┼ą okam┼żite pou┼ż├şva┼ą.

Aktualiz├ícia Vasil prin├í┼ía v├Żznamn├ę vylep┼íenia v├Żkonu a schopnost├ş protokolu Cardano. Aktualiz├ícia je s├║─Źas┼ąou uzla Cardano verzie 1.35.0 a sie┼ą sa na ┼łu pripravuje. Najd├┤le┼żitej┼í├şm vylep┼íen├şm v aktualiz├ícii Vasil je hlavne Diffusion pipelining, ktor├Ż bude ma┼ą vplyv na lep┼íiu ┼ík├ílovate─żnos┼ą. Existuje aj nieko─żko CIP (Cardano Improvement Proposal), ktor├ę sa t├Żkaj├║ platformy Plutus.

Diffusion pipelining

Diffusion pipelining zefekt├şv┼łuje ┼í├şrenie inform├íci├ş o novo vytvoren├Żch blokoch medzi ├║─Źastn├şkmi siete Peer-to-Peer. Toto vylep┼íenie umo┼ż┼łuje ┼í├şrenie inform├íci├ş o bloku e┼íte pred jeho ├║pln├Żm overen├şm v uzle. To umo┼ż┼łuje paralelizova┼ą valid├íciu a distrib├║ciu blokov.

Priepustnos┼ą siete mo┼żno zefekt├şvni┼ą zv├Ż┼íen├şm ve─żkosti bloku a zn├ş┼żen├şm intervalu, v ktorom sa vytv├íraj├║ nov├ę bloky. Do v├Ą─Ź┼íieho bloku mo┼żno vlo┼żi┼ą viac inform├íci├ş, napr├şklad transakci├ş. ─î├şm ─Źastej┼íie sa vytv├íraj├║ bloky, t├Żm viac po┼żiadaviek pou┼ż├şvate─żov sa spracuje za dan├Ż ─Źas.

Zv├Ą─Ź┼íovanie ve─żkosti bloku a skracovanie ─Źasu bloku m├í obmedzenia vypl├Żvaj├║ce z mo┼żnost├ş internetu. Cardano je glob├ílna sie┼ą s uzlami po celom svete. Ak uzol vytvor├ş nov├Ż blok napr├şklad v Eur├│pe, blok sa mus├ş postupne dosta┼ą cez ostatn├ę uzly do ├üzie, Ju┼żnej a Severnej Ameriky, Austr├ílie a ─Ćal┼í├şch miest. Ka┼żd├Ż jednotliv├Ż uzol overuje inform├ície predt├Żm, ako ich m├┤┼że ─Ćalej distribuova┼ą svojim kolegom. To znamen├í, ┼że k├Żm sa blok dostane aspo┼ł k 95 % uzlov v sieti, uplynie ur─Źit├Ż ─Źas naz├Żvan├Ż oneskorenie. Tento ─Źas je v sieti Cardano najviac 5 sek├║nd. Oneskorenie nastaven├ę na 5 sek├║nd je ─Źas potrebn├Ż na zaru─Źenie ┼í├şrenia bloku, ktor├ęho ve─żkos┼ą nepresahuje 2 MB.

Je zrejm├ę, ┼że ─Ź├şm je blok v├Ą─Ź┼í├ş, t├Żm dlh┼íie bude trva┼ą jeho valid├ícia (─Źas procesora), a teda t├Żm dlh┼íie bude trva┼ą jeho ┼í├şrenie. V sieti Cardano je potrebn├ę validova┼ą nielen transakcie, ale aj skripty Plutus. Valid├ícia skriptov je v├Żpo─Źtovo n├íro─Źnej┼íia ako valid├ícia transakci├ş. S rast├║cou ve─żkos┼ąou bloku m├┤┼że r├ís┼ą aj po─Źet skriptov v ┼łom, tak┼że bude r├ís┼ą aj ─Źas potrebn├Ż na valid├íciu cel├ęho bloku.

V┼íimnite si, ┼że ─Źas bloku mus├ş by┼ą nastaven├Ż na dlh┼í├ş ─Źas ako Oneskorenie, aby sa vytvorila dostato─Źn├í rezerva na ┼í├şrenie bloku v sieti. V pr├şpade Cardano je teraz ─Źas bloku nastaven├Ż na 20 sek├║nd. Ak je mo┼żn├ę skr├íti┼ą ─Źas ┼í├şrenia bloku, je mo┼żn├ę postupne skracova┼ą aj ─Źas bloku. V├Żsledkom bude vy┼í┼íia priepustnos┼ą.

Ako sa vlastne vykon├íva valid├ícia blokov? Pre zjednodu┼íenie si m├┤┼żete predstavi┼ą, ┼że ka┼żd├Ż uzol m├í tri vrstvy. ├Üplne dole je sie┼ąov├í vrstva, ktor├í prij├şma a odosiela ├║daje cez internet. Sie┼ąov├í vrstva m├┤┼że prij├şma┼ą a odosiela┼ą bloky. Blok m├┤┼że by┼ą spracovan├Ż po ─Źastiach, t. j. ako hlavi─Źka bloku a telo bloku. Druhou vrstvou je vrstva konsenzu. Na tejto ├║rovni prebieha valid├ícia hlavi─Źky a tela bloku. Overovanie tela bloku je v├Żpo─Źtovo n├íro─Źnej┼íie ako overovanie hlavi─Źky. Tre┼ąou vrstvou je blockchain, ktor├Ż prij├şma platn├ę bloky. M├┤┼żete si to predstavi┼ą ako presun inform├íci├ş zo spodnej vrstvy na vrchn├║. Do blockchainu sa dostan├║ len platn├ę bloky. Neplatn├ę bloky sa na z├íklade konsenzu vyradia, tak┼że sa neulo┼żia do blockchainu ani sa ─Ćalej ne┼í├şria do siete.

Pozrime sa teraz zjednodu┼íene na to, ako sa distribuuje blok v sieti Peer-to-Peer. Predstavme si, ┼że v├Żrobca bloku pr├íve vytvoril nov├Ż blok. Pozrieme sa na to, ─Źo mus├ş urobi┼ą valid├ítor bloku. V├Żrobca bloku po┼íle hlavi─Źku bloku valid├ítorovi bloku. Valid├ítor bloku mus├ş overi┼ą, ─Źi hlavi─Źka sp─║┼ła pravidl├í protokolu. Mus├ş napr├şklad overi┼ą, ─Źi v├Żrobca bloku bol skuto─Źne zvolen├Żm ved├║cim slotu (mus├ş sa poskytn├║┼ą d├┤kaz), ─Źi je digit├ílny podpis spr├ívny a ─Źi nov├Ż blok spr├ívne odkazuje na predch├ídzaj├║ci blok. Ak je hlavi─Źka bloku v poriadku, stiahne sa aj telo bloku. Hlavi─Źka bloku obsahuje odkaz na telo bloku. Valid├ítor bloku over├ş, ─Źi je odkaz spr├ívny, a ak je spr├ívny, m├┤┼że overi┼ą transakcie a vykona┼ą skripty Plutus. Ak je telo bloku spr├ívne, valid├ítor bloku m├┤┼że prida┼ą blok do svojej verzie blockchainu a ─Ćalej distribuova┼ą blok do siete ─Ćal┼íiemu peerovi (─Ćal┼íiemu valid├ítorovi bloku).

V┼íimnite si, ┼że ka┼żd├Ż valid├ítor blokov mus├ş pred redistrib├║ciou bloku overi┼ą hlavi─Źku aj telo bloku. Celkov├Ż ─Źas potrebn├Ż na distrib├║ciu bloku do celej siete by sa z├şskal vyn├ísoben├şm priemern├ęho ─Źasu valid├ície na jednom valid├ítore bloku po─Źtom skokov v sieti.

Dif├║zna pipelining ur├Żchli distrib├║ciu blokov v sieti t├Żm, ┼że valid├ítor bloku po┼íle telo bloku do siete pred valid├íciou obsiahnut├Żch ├║dajov. Valid├ítor bloku over├ş iba odkaz medzi hlavi─Źkou a telom a ak je v poriadku, okam┼żite ┼í├şri blok. Valid├ítor mus├ş overi┼ą, ─Źi prijal blok, ktor├Ż patr├ş k prijatej hlavi─Źke. Valid├ícia odkazu (hash tela hlavi─Źky) trv├í len kr├ítko v porovnan├ş s valid├íciou zvy┼íku tela. To znamen├í, ┼że celkov├Ż rozpo─Źet na distrib├║ciu bloku do celej siete sa zni┼żuje o ─Źas, ktor├Ż by jednotliv├ę skoky str├ívili overovan├şm tela bloku. In├Żmi slovami, valid├ícia tela bloku a distrib├║cia bloku sa vykon├ívaj├║ s├║─Źasne. Dif├║zna pipelining zvy┼íuje r├Żchlos┼ą dostupnosti ├║dajov.

V┼íimnite si, ┼że iba v├Żrobca bloku (ved├║ci slotu) overuje telo bloku na za─Źiatku distrib├║cie do siete. V┼íetky ostatn├ę uzly distribuuj├║ cel├Ż blok po overen├ş iba hlavi─Źky bloku a odkazu v tele bloku.

Ne├║pln├ę bloky sa v sieti nedistribuuj├║, preto┼że ak valid├ítor bloku nedostane telo bloku so spr├ívnym odkazom, cel├Ż blok zahod├ş. Ak je odkaz v tele bloku spr├ívny, ale n├ísledn├í valid├ícia tela zlyh├í, poctiv├ę uzly cel├Ż blok zahodia.

V┼íimnite si, ┼że zmena na ├║rovni siete nem├í v├Żznamn├Ż vplyv na konsenzus. V┼íetky potrebn├ę valid├ície na prijatie bloku a jeho pridanie do blockchainu sa vykon├ívaj├║ rovnak├Żm sp├┤sobom ako pred aktualiz├íciou. Dif├║zna pipelining zvy┼íuje r├Żchlos┼ą ┼í├şrenia blokov v sieti, ─Ź├şm sa otv├íraj├║ mo┼żnosti na zv├Ą─Ź┼íenie ve─żkosti bloku a potenci├ílne skr├ítenie ─Źasu blokovania.

Vypo─Ź├ştajme, o ko─żko r├Żchlej┼íie sa blok ┼í├şri od v├Żrobcu bloku cez valid├ítor 4 blokov, ak valid├ícia hlavi─Źky trv├í 50 ms a valid├ícia tela 250 ms. Produkciu bloku zapo─Ź├ştame do celkov├ęho ─Źasu, preto┼że producent mus├ş validova┼ą telo. Bez dif├║zneho potrubia trv├í valid├ícia cel├ęho bloku v ka┼żdom uzle 300 ms. Tak┼że ─Źas propag├ície od v├Żrobcu bloku k ┼ítvrt├ęmu valid├ítoru bloku trv├í 5 * 300 ms, ─Źo je 1500 ms (1,5 s).

Pri pou┼żit├ş dif├║zneho potrubia trv├í valid├ícia bloku len ─Źas potrebn├Ż na valid├íciu hlavi─Źky (50 ms) a overenie odkazu medzi hlavi─Źkou a telom bloku, pri─Źom sa po─Ź├şta 5 ms. Na dostato─Źn├║ valid├íciu bloku a jeho distrib├║ciu rovnocenn├ęmu partnerovi je potrebn├Żch len 55 ms. Celkov├Ż ─Źas distrib├║cie bloku bude trva┼ą 300 + (4 * 55), ─Źo je 520 ms.

V nasleduj├║cej tabu─żke s├║ uveden├ę zlep┼íenia, ktor├ę mo┼żno dosiahnu┼ą prostredn├şctvom aktualiz├ície. V poslednom riadku s├║ uveden├ę ├║daje pre asynchr├│nne overovanie (AV). AV nie je s├║─Źas┼ąou aktualiz├ície Vasil a je ─Ćal┼í├şm mo┼żn├Żm vylep┼íen├şm, ktor├ę roz┼íiruje pipelining Diffusion.

Alonzo prin├í┼ía inteligentn├ę zmluvy do Cardana

Hard-fork Alonzo prinesie do Cardana inteligentn├ę kontrakty. Pozrime sa na hist├│riu a potenci├íl inteligentn├Żch zml├║v. Odv├í┼żime sa myslie┼ą vo ve─żkom na bud├║cnos┼ą technol├│gi├ş.Viac

CIPy s├║visiace s platformou Plutus

Za─Źnime s CIP-32, ktor├Ż sa t├Żka inline datums. Roz┼í├şren├ę UTXO umo┼ż┼łuje pou┼ż├şvate─żom volite─żne prid├íva┼ą do UTXO ─żubovo─żn├ę pou┼ż├şvate─żsk├ę ├║daje vo form├íte podobnom JSON. Tieto ├║daje sa naz├Żvaj├║ Datum. Datum umo┼żn├ş v├Żvoj├írom poskytn├║┼ą skriptom funkcionalitu podobn├║ stavu. Pou┼ż├şvate─żsk├ę ├║daje mo┼żno pova┼żova┼ą za lok├ílny stav skriptu. Tento stav m├í len lok├ílnu platnos┼ą, preto┼że je spojen├Ż s konkr├ętnym UTXO.

V s├║─Źasnosti sa Datum implementuje pripojen├şm hashov d├ítumov k v├Żstupom a vy┼żadovan├şm, aby v├Żdajov├í transakcia poskytla skuto─Źn├Ż Datum (skuto─Źn├ę ├║daje). ├Üdaje z v├Żdavkovej transakcie sa overuj├║ tak, ┼że sa vytvor├ş hash, ktor├Ż sa mus├ş zhodova┼ą s hashom, ktor├Ż je ulo┼żen├Ż v Date.

V├Żhodou je ├║spora miesta v blockchaine, preto┼że Datum je len hash k ├║dajom, ktor├ę m├┤┼żu by┼ą ─żubovo─żne ve─żk├ę. Nev├Żhodou je, ┼że ├║daje, ktor├Żch hash je rovnak├Ż ako hash v Datum, musia by┼ą poskytnut├ę v transakcii. Dodajme, ┼że teoreticky m├┤┼że by┼ą ├║dajom napr├şklad len kr├ítke ─Ź├şslo, ktor├ę m├┤┼że by┼ą men┼íie ako hash. V takom pr├şpade by bolo v├Żhodnej┼íie ma┼ą ├║daje priamo v Date a nie v hash.

Datum obsahuje ├║daje, ktor├ę predstavuj├║ ur─Źit├║ aplika─Źn├║ logiku. ├Üdaje v Date vklad├í strana, ktor├í vytv├íra v├Żstup pomocou transakcie Plutus. V├Żdajov├í strana mus├ş rozumie┼ą tejto aplika─Źnej logike, t. j. mus├ş rozumie┼ą obsahu Datumu, a to nie je mo┼żn├ę bez komunik├ície so stranou, ktor├í v├Żstup vytvorila. Komunik├ícia mus├ş prebieha┼ą bu─Ć mimo re┼ąazca, alebo in├Żm sp├┤sobom v re┼ąazci. To m├┤┼że by┼ą pre stranu, ktor├í v├Żdavky vynaklad├í, nepohodln├ę.

V CIP-32 sa navrhuje, aby Datum mohol obsahova┼ą bu─Ć priamo ├║daje (inline ├║daje), alebo hash ├║dajov, ako je to teraz. Transakcie Plutus umo┼ż┼łuj├║ vybra┼ą si jeden z t├Żchto pr├şstupov.

Ak by sa ├║daje nach├ídzali priamo v Datume, nebolo by potrebn├ę vklada┼ą ├║daje do transakci├ş v├Żdavkov. Nezabudnite, ┼że pou┼ż├şvate─ż m├┤┼że st├íle pou┼ż├şva┼ą program Redeemer ako vstup pre skript Plutus.

Tento nov├Ż pr├şstup k aplik├ícii Datum u─żah─Ź├ş pr├ícu v├Żvoj├írom dApp, najm├Ą v kombin├ícii s CIP-31.

CIP-31navrhuje vytvori┼ą nov├Ż druh vstupu, referen─Źn├Ż vstup, ktor├Ż by umo┼żnil pozrie┼ą sa na v├Żstup bez toho, aby ste ho museli min├║┼ą. Umo┼żn├ş to pr├şstup k inform├íci├ím, ktor├ę s├║ ulo┼żen├ę v blockchaine vo forme d├ít bez toho, aby bolo potrebn├ę m├ş┼ła┼ą a znovu vytv├íra┼ą UTXO, ktor├ę s├║ spojen├ę s d├ítami. Okrem toho bude mo┼żn├ę skontrolova┼ą hodnotu s├║visiacu s referen─Źn├Żm vstupom.

Datum v podstate poskytuje sp├┤sob, ako uklada┼ą ├║daje v blockchaine a pristupova┼ą k nim. M├┤┼żete sa na┼ł pozera┼ą ako na zdroj inform├íci├ş. Bohu┼żia─ż, pr├şstup k ├║dajom v syst├ęme Datum je v s├║─Źasnosti v mnoh├Żch oh─żadoch obmedzen├Ż. Aby ste mohli pristupova┼ą k inform├íci├ím a pou┼ż├şva┼ą ich, mus├şte vynalo┼żi┼ą v├Żstup, ktor├Ż je spojen├Ż s Datumom.

Aplik├ícia m├┤┼że potrebova┼ą pou┼żi┼ą inform├ície, a ak si ich chce ponecha┼ą na ─Ćal┼íie pou┼żitie, mus├ş vytvori┼ą nov├Ż v├Żstup s rovnak├Żmi inform├íciami. Nev├Żhodou je, ┼że sa vytv├íra nov├Ż v├Żstup, tak┼że ak chce k inform├íci├ím pristupova┼ą niekto in├Ż, nem├┤┼że pou┼żi┼ą star├Ż v├Żstup, ale novovytvoren├Ż. Nov├Ż v├Żstup sa v┼íak vytvor├ş po pridan├ş nov├ęho bloku. V praxi to znamen├í, ┼że niektor├ę aplik├ície s├║ obmedzen├ę na jednu oper├íciu na jeden blok.

Okrem toho, ak sa chce strana pozrie┼ą na inform├ície v Date a je n├║ten├í vyda┼ą v├Żstup, znamen├í to, ┼że musia by┼ą splnen├ę podmienky vydania a strana mus├ş zv├í┼żi┼ą, ─Źo s prostriedkami urob├ş. To je nepohodln├ę a hlavne n├íkladn├ę.

CIP-31 to zmen├ş. Autor transakcie ┼ípecifikuje vstupy bu─Ć ako v├Żdavkov├ę vstupy, alebo ako referen─Źn├ę vstupy. Referen─Źn├Ż vstup je vstup transakcie, ktor├Ż je norm├ílne prepojen├Ż s konkr├ętnym v├Żstupom transakcie, s t├Żm rozdielom, ┼że sa na v├Żstup odkazuje, a nie ho vynaklad├í.

In├Żmi slovami, teraz mus├şte zaplati┼ą poplatok za transakciu, aby ste z├şskali inform├ície z d├ítumu, preto┼że je potrebn├ę min├║┼ą v├Żstup. Po aktualiz├ícii Vasil m├┤┼żete z├şska┼ą inform├ície takmer zadarmo v s├║vislosti s v├Żdajom transakcie, ktor├í sa chyst├í min├║┼ą in├ę UTXO. V┼íimnite si, ┼że aj ke─Ć transakcia obsahuje odkaz na vstup, mus├ş e┼íte min├║┼ą aspo┼ł jeden v├Żstup. Tak┼że poplatok za transakciu mus├ş by┼ą v┼żdy zaplaten├Ż.

Referen─Źn├Ż v├Żstup sa neberie do ├║vahy pri vyrovn├ívan├ş transakcie, t. j. pri kontrole, ─Źi je hodnota na vstupe rovnak├í ako hodnota na v├Żstupe transakcie. To znamen├í, ┼że podmienky v├Żdavkov pre referen─Źn├Ż v├Żstup sa v├┤bec nekontroluj├║. Referen─Źn├Ż v├Żstup zost├íva v akt├şvnej sade UTXO na ─Ćal┼íie pou┼żitie. D├┤le┼żit├ę je, ┼że referen─Źn├ę vstupy s├║ vidite─żn├ę pre skripty, tak┼że ├║daje z Datum t├Żchto referen─Źn├Żch vstupov m├┤┼żu by┼ą pou┼żit├ę ako vstup pre logiku rozhodovania skriptu.

Skript dost├íva inform├ície o transakci├ích prostredn├şctvom kontextu skriptu. Novo dost├íva ─Ćal┼íie inform├ície o tom, ┼że m├┤┼że by┼ą zahrnut├Ż zoznam referen─Źn├Żch vstupov. Takto bude skript vedie┼ą spr├ívne pracova┼ą s referen─Źn├Żmi vstupmi.

Transakcia m├í ako vstup UTXO, ktor├Ż sa pl├ínuje min├║┼ą, a z├írove┼ł m├┤┼że ma┼ą aj referen─Źn├Ż vstup. Referen─Źn├Ż vstup sa m├┤┼że pou┼żi┼ą po─Źas vykon├ívania skriptu Plutus. Po valid├ícii a zaraden├ş transakcie do bloku sa UTXO minie, ale referen─Źn├Ż vstup zost├íva nezmenen├Ż a m├┤┼że k nemu nesk├┤r pristupova┼ą in├í strana. Inform├ície v syst├ęme Datum s├║ tak dostupn├ę dlh┼íie obdobie pre viacer├Żch pou┼ż├şvate─żov.

Aplik├ície m├┤┼żu napr├şklad skontrolova┼ą stav (Datum alebo uzamknut├║ hodnotu) bez toho, aby museli spotrebova┼ą v├Żstup. Poskytovatelia ├║dajov v re┼ąazci m├┤┼żu v syst├ęme Datum uklada┼ą ─żubovo─żn├ę ├║daje a in├ę skripty (aplik├ície) m├┤┼żu k t├Żmto ├║dajom pristupova┼ą. Za ulo┼żenie ├║dajov v blockchaine sa plat├ş len raz a potom bud├║ k dispoz├şcii aj ostatn├Żm.

CIP-33 vyu┼ż├şva CIP-31 a CIP-32, aby umo┼żnil prip├íjanie skriptov k v├Żstupom. CIP-33 zav├ídza referen─Źn├ę skripty, ktor├ę mo┼żno pou┼żi┼ą na splnenie po┼żiadaviek na skripty po─Źas valid├ície.

Zaka┼żd├Żm, ke─Ć sa m├í skript pou┼żi┼ą, mus├ş transakcia, ktor├í vy┼żaduje jeho pou┼żitie, poskytn├║┼ą cel├Ż skript ako s├║─Źas┼ą transakcie. To zv├Ą─Ź┼íuje re┼ąazec a zvy┼íuje poplatok pou┼ż├şvate─ża. Ak transakcia pou┼ż├şva viac skriptov, m├┤┼że narazi┼ą na probl├ęm s obmedzen├şm maxim├ílnej ve─żkosti.

Referen─Źn├Ż vstup a inline Datum tento probl├ęm rie┼íia t├Żm, ┼że umo┼ż┼łuj├║ ulo┼żenie skriptu v blockchaine. Potom sa na┼ł d├í odkazova┼ą opakovane. V├Żdavkov├í transakcia, ktor├í chce min├║┼ą UTXO, sa m├┤┼że odvola┼ą na skript, ktor├Ż sa pou┼żije na overenie. To znamen├í, ┼że transakcia, ktor├í pou┼ż├şva skript, nemus├ş nies┼ą jeho obsah. Mus├ş len odkazova┼ą na v├Żstup, v ktorom sa skript nach├ídza.

Ke─Ć sa transakcia validuje a je potrebn├ę poskytn├║┼ą skript zodpovedaj├║ci hash skriptu, okrem skriptov uveden├Żch v samotnej transakcii sa bud├║ bra┼ą do ├║vahy aj v┼íetky referen─Źn├ę skripty z v├Żstupov, na ktor├ę odkazuj├║ vstupy transakcie. In├Żmi slovami, pou┼żije sa odkaz na skript (ktor├Ż u┼ż bol ulo┼żen├Ż v blockchaine).

V─Ćaka tomuto vylep┼íeniu nemusia aplik├ície ─Źasto posiela┼ą skripty v┼żdy, ke─Ć ich chc├║ pou┼żi┼ą. Skript bude ulo┼żen├Ż v re┼ąazci a bude sa da┼ą opakovane pou┼żi┼ą pre viacero UTXO. Ten ist├Ż skript m├┤┼żu pou┼ż├şva┼ą viacer├ę strany.

Záver

Op├şsali sme hlavn├ę vylep┼íenia, ktor├ę prinesie aktualiz├ícia Vasil. V skuto─Źnosti bude aktualiz├ícia obsahova┼ą nieko─żko ─Ćal┼í├şch men┼í├şch vylep┼íen├ş. Zv├Ż┼íenie ┼ík├ílovate─żnosti a zlep┼íenie platformy Plutus otv├íra nov├ę mo┼żnosti pre v├Żvoj├írov a v├Żhody pre pou┼ż├şvate─żov. T├şm u┼ż pracuje na n├ívrhu nov├Żch vylep┼íen├ş. Nev├íhajte a pou┼ż├şvajte Cexplorer, ktor├Ż je pripraven├Ż na aktualiz├íciu Vasil.

Aktualiz├ícia bola pomenovan├í na po─Źes┼ą zosnul├ęho Vasila St. Dabova, ve─żvyslanca spolo─Źnosti Cardano a ve─żk├ęho podporovate─ża projektu, ktor├Ż bohu┼żia─ż zomrel v roku 2021.


(Nap├şsal @Cardanians.io) - preklad @Martin.M
P├┤vodn├Ż ─Źl├ínok: What Vasil upgrade brings to Cardano | Cardanians