­č窭čç░ V├Żzvy pre Cardano developerov

V├Żzvy pre Cardano developerov

Pre v├Żvoj├írov m├┤┼że by┼ą ┼ąa┼żk├ę naplno vyu┼żi┼ą model UTxO, preto┼że musia bra┼ą do ├║vahy paraleliz├íciu. Cardano neumo┼ż┼łuje udr┼żiava┼ą jeden glob├ílny stav aplik├ície v on-chain ─Źasti inteligentn├ęho kontraktu. Ka┼żd├Ż UTxO m├┤┼że predstavova┼ą ─Źas┼ą stavu aplik├ície a m├┤┼że by┼ą spracovan├Ż nez├ívisle a paralelne. To teoreticky umo┼ż┼łuje vysok├║ priepustnos┼ą a ┼ík├ílovate─żnos┼ą, ale aplik├ícia sa mus├ş vysporiada┼ą so zlo┼żitos┼ąami s├║visiacimi so spr├ívou s├║be┼żn├Żch transakci├ş. Ak├Żm v├Żzvam ─Źelia v├Żvoj├íri na Cardano?

Ke─Ć je paraleliz├ícia jednoduch├í

V modeli eUTxO (Extended Unspent Transaction Output) m├┤┼że by┼ą ka┼żd├Ż UTxO spracovan├Ż nez├ívisle a paralelne. V├Żdaj UTxO nez├ívis├ş od ┼żiadneho glob├ílneho stavu Cardana. Ak s├║ splnen├ę podmienky utr├ícania, zo vstupn├ęho UTxO (alebo viacer├Żch vstupn├Żch UTxO) sa prostredn├şctvom transakcie vytvor├ş jedno alebo viac v├Żstupn├Żch UTxO. Vstupn├Ż(├ę) UTxO mus├ş(├║) by┼ą ├║plne spotrebovan├Ż(├ę). V├Żstupn├ę UTxO musia ma┼ą rovnak├║ (alebo men┼íiu) hodnotu ako vstupn├ę UTxO.

Ak Alica po┼íle Bobovi 100 ADA, v├Żdaj UTxO z├ívis├ş len od Alicinho svedka. Ak sto ─Ćal┼í├şch pou┼ż├şvate─żov po┼íle podobn├║ transakciu, pou┼żije sa 100 ─Ćal┼í├şch jedine─Źn├Żch vstupn├Żch UTxO. Ka┼żd├Ż odosielate─ż transakcie je vlastn├şkom vstupn├ęho UTxO. Medzi transakciami a vstupn├Żmi UTxO neexistuje ┼żiadna z├ívislos┼ą.

Medzi transakciami a vstupn├Żmi UTxO neexistuje z├ívislos┼ą, preto┼że v┼íetci odosielatelia s├║ na sebe nez├ívisl├ş. Urobili svoje vlastn├ę nez├ívisl├ę rozhodnutie posla┼ą 100 ADA. V┼íetk├Żch 100 transakci├ş m├┤┼że by┼ą vlo┼żen├Żch do toho ist├ęho bloku a bud├║ vyhodnoten├ę ako platn├ę.

Transakcia spotrebuje jeden alebo viac UTxO ako vstupy a vytvor├ş jeden alebo viac nov├Żch UTxO ako v├Żstupy. Toto jednoduch├ę pravidlo plat├ş tak pre prenos hodnoty medzi Alicou a Bobom, ako aj v pr├şpade aplik├íci├ş, ako uvid├şte nesk├┤r.

Na obr├ízku vid├şte 3 identick├ę transakcie. Pri 100 transakci├ích by to vyzeralo rovnako. Nenechajte sa zmias┼ą t├Żm, ┼że odosielate─żom je v┼żdy Alica a pr├şjemcom Bob. Zaka┼żd├Żm je to in├í Alica a in├Ż Bob. Obr├ízok m├í demon┼ítrova┼ą skuto─Źnos┼ą, ┼że medzi odosielate─żmi transakci├ş nie je potrebn├í ┼żiadna synchroniz├ícia. Ak s├║ transakcie platn├ę, nem├┤┼żu zlyha┼ą a v┼íetky sa dostan├║ do blockchainu.

V├Żznam obr├ízka si mo┼żno uvedom├şte nesk├┤r, ke─Ć si vysvetl├şme, ako DEX funguje.

Sie┼ą Cardano m├┤┼że overova┼ą transakcie v ─żubovo─żnom porad├ş, preto┼że transakcie s├║ na sebe nez├ívisl├ę. To je v├Żhoda z h─żadiska priepustnosti siete, preto┼że konsenzus nie je z├ívisl├Ż od postupn├ęho spracovania.

Ako vytvori┼ą paraleln├║ aplik├íciu?

V ide├ílnom pr├şpade by mali v├Żvoj├íri aplik├íci├ş vytvori┼ą tak├║ logiku inteligentn├ęho kontraktu, ktor├í sa z h─żadiska paraleliz├ície spr├íva podobne, ako ke─Ć 100 odosielate─żov (Alices) odo┼íle transakciu. To je v┼íak takmer nemo┼żn├ę.

Objasn├şme si to na pr├şklade DEX, ktor├Ż vyu┼ż├şva pooly likvidity.

Baz├ęn likvidity je naplnen├Ż viacer├Żmi transakciami, ktor├ę produkuj├║ v├Żstupn├ę UTxO. Tieto UTxO predstavuj├║ tokeny v poole likvidity. S ka┼żd├Żm novo pridan├Żm blokom do ├║─Źtovnej knihy sa zlo┼żenie UTxO v poole likvidity m├┤┼że zmeni┼ą.

Na obr├ízku vid├şte baz├ęn likvidity s dvojicou tokenov X a Y. V baz├ęne likvidity je nieko─żko UTxO s tokeny X a Y. V ─Ćal┼íom bloku Alice, Bob a Carol vlo┼żili do baz├ęna likvidity nov├ę UTxO s tokenom X a Dave, Eve a Frank vlo┼żili nieko─żko UTxO s tokenom Y. Ke─Ć┼że nedo┼ílo k v├Żmene, z baz├ęna neboli odstr├ínen├ę ┼żiadne UTxO.

Na uskuto─Źnenie swapu mus├ş DEX spotrebova┼ą UTxO (alebo viac UTxO) z fondu likvidity ako vstup pre ka┼żd├Ż typ tokenu. Tieto UTxO musia by┼ą ├║plne spotrebovan├ę. Ak si swap nevy┼żaduje v┼íetky tokeny UTxO, potom sa zvy┼ín├ę tokeny musia vr├íti┼ą do poolu likvidity ako nov├ę UTxO.

V pr├şpade DEX prebieha s├║─Źasne mnoho oper├íci├ş. Pou┼ż├şvatelia posielaj├║ tokeny (poskytovatelia likvidity) do poolov likvidity. Poskytovatelia s├║ odosielatelia a DEX je pr├şjemca. Z├írove┼ł m├┤┼żu in├ş pou┼ż├şvatelia posiela┼ą ┼żiadosti o v├Żmenu. S├║ to odosielatelia, ktor├ş d├ívaj├║ tokenov X do DEX a chc├║ z├şska┼ą tokenov Y. Alebo naopak.

┼Żiados┼ą o swap m├┤┼że v kr├ítkom ─Źase posla┼ą viac ├║─Źastn├şkov. Tieto swapy sa m├┤┼żu t├Żka┼ą jedn├ęho fondu likvidity. Medzi ├║─Źastn├şkmi teda existuje vz├íjomn├í z├ívislos┼ą.

Je tie┼ż dobr├ę objasni┼ą, ─Źo presne je DEX. Komplexn├ę inteligentn├ę kontrakty v Cardano (ako DEX) sa skladaj├║ z dvoch ─Źast├ş: logiky on-chain, ktor├í sa vykon├íva na blockchaine, a logiky off-chain, ktor├í sa vykon├íva na serveroch (alebo v lok├ílnych pe┼ła┼żenk├ích).

Na obr├ízku m├┤┼żete vidie┼ą DEX, ktor├Ż sa sklad├í z on-chain a off-chain logiky.

Zatia─ż ─Źo vykon├ívanie on-chain logiky je prirodzene decentralizovan├ę, ke─Ć┼że prebieha v sieti Cardano, za decentraliz├íciu off-chain logiky DEX je zodpovedn├Ż t├şm. ─îas┼ą DEX mimo re┼ąazca nie je (nemala by by┼ą) zlo┼żen├í len z jedn├ęho agenta, ale z viacer├Żch agentov.

V pr├şpade DEX sa t├şto agenti naz├Żvaj├║ batchers. S├║ zodpovedn├ş za vykon├ívanie v├Żmen. Batcheri vytv├íraj├║ transakcie, ktor├ę sp─║┼łaj├║ podmienky ─Źerpania UTxO v poole likvidity a prev├ídzaj├║ akt├şva v pomere, ktor├Ż po┼żadovali obaja ├║─Źastn├şci swapu.

Cardano neumo┼ż┼łuje udr┼żiava┼ą jednotn├Ż glob├ílny stav aplik├ície v on-chain ─Źasti smart kontraktu. Je to v┼íak technicky mo┼żn├ę.

Ak by v├Żvoj├íri ulo┼żili cel├Ż stav DApp do jedn├ęho UTXO, v podstate by vytvorili glob├ílny stav podobn├Ż tomu, ktor├Ż existuje v modeli Ethereum zalo┼żenom na ├║─Źtoch. To by mohlo obmedzi┼ą s├║be┼żnos┼ą a priepustnos┼ą va┼íej DApp. Tento pr├şstup by plne nevyu┼żil v├Żhody modelu EUTxO.

V on-chain ─Źasti DEX predstavuj├║ stav aplik├ície UTxO a s├║visiace d├íta. Stav je preto distribuovan├Ż naprie─Ź UTxOs. Ak m├í ma┼ą DEX jednotn├Ż glob├ílny stav aplik├ície, mus├ş sa udr┼żiava┼ą mimo re┼ąazca v r├ímci d├ívkova─Źov.

Na obr├ízku vid├şte fond likvidity s tokeny X a Y a 3 batchermi. Glob├ílny stav aplik├ície a synchroniz├ícia stavu medzi batchermi s├║ vyzna─Źen├ę modrou farbou. Stav aplik├ície pozost├íva z ├║dajov on-chain, ─Źo s├║ d├íta spojen├ę s UTxOs, a zo stavu aplik├ície off-chain udr┼żiavan├ęho batchermi (agentmi). Batchery navz├íjom komunikuj├║ s cie─żom synchronizova┼ą jednotn├Ż glob├ílny stav aplik├ície.

Je to potrebn├ę, preto┼że batchery (agenti) pristupuj├║ k rovnak├ęmu zdroju, a t├Żm je fond likvidity. Potrebuj├║ pou┼ż├şva┼ą vstupn├ę UTxO z fondu likvidity (na vykonanie v├Żmeny) a m├┤┼że sa sta┼ą, ┼że dvaja (alebo viacer├ş) agenti bud├║ chcie┼ą pou┼ż├şva┼ą rovnak├ę UTxO. M├┤┼że nasta┼ą probl├ęm s konfliktom.

Teraz je ─Źas pripomen├║┼ą si prv├Ż obr├ízok v ─Źl├ínku. Ke─Ć 100 odosielate─żov predlo┼żilo transakciu, nemohli si navz├íjom konkurova┼ą o to ist├ę UTxO, preto┼że ka┼żd├Ż odosielate─ż pou┼ż├şval svoje vlastn├ę UTxO. UTxO v poole likvidity s├║ zdie─żan├Żm zdrojom, t. j. zdrojom, ku ktor├ęmu maj├║ pr├şstup viacer├ş agenti.

Vo v┼íeobecnosti sa kontingencia vz┼ąahuje na scen├ír, ke─Ć sa viacero vl├íkien alebo procesov (v na┼íom pr├şpade agentov) sna┼ż├ş pristupova┼ą k tomu ist├ęmu zdroju tak├Żm sp├┤sobom, ┼że aspo┼ł jeden z nich be┼ż├ş pomal┼íie, ako keby ostatn├ę nebe┼żali.

V na┼íom pr├şpade existuje riziko, ┼że dvaja agenti vytvoria transakciu, v ktorej pou┼żij├║ rovnak├Ż vstupn├Ż UTxO z fondu likvidity. V takom pr├şpade Cardano prijme iba jednu transakciu. Druh├í z nich zlyh├í.

Na obr├ízku m├┤┼żete vidie┼ą, ┼że batcher 1 a batcher 3 sa pok├║┼íaj├║ pou┼żi┼ą rovnak├ę UTxO s tokenom X. Do┼ílo ku kontent├ícii. Batcheri s├║ zrejme zle synchronizovan├ş a navz├íjom nevedia o svojom z├ímere pou┼żi┼ą toto konkr├ętne UTxO. Ak sa vytvoria 2 v├Żmenn├ę transakcie, jedna bude ├║spe┼ín├í a druh├í zlyh├í.

Cie─żom DEX je umo┼żni┼ą s├║be┼żn├ę vykon├ívanie swapov, t. j. aby jednotliv├ş agenti mohli kon┼ítruova┼ą transakcie s├║─Źasne a aby pri v├Żbere UTxO nedoch├ídzalo ku kontingencii.

Aby sa zabr├ínilo zlyhaniu transakci├ş, mus├ş existova┼ą komunik├ícia mimo re┼ąazca medzi agentmi alebo in├í forma synchroniz├ície. In├Żmi slovami, agenti musia udr┼żiava┼ą konzistentn├Ż glob├ílny stav DEX.

Jednotliv├ş agenti si musia nejak├Żm sp├┤sobom rezervova┼ą UTxO v poole, aby ten ist├Ż UTxO nepou┼żil in├Ż agent. Pr├şpadne to m├┤┼że fungova┼ą tak, ┼że v r├ímci ka┼żd├ęho nasleduj├║ceho bloku (20 sek├║nd) v┼íetky transakcie skon┼ítruuje jeden (n├íhodne vybran├Ż) agent. Hoci je tento pr├şstup decentralizovan├Ż, je menej s├║be┼żn├Ż.

Na obr├ízku vid├şte, ┼że batcher 1 a batcher 3 si na v├Żmeny vybrali UTxO s tokeny X a Y exkluz├şvnym sp├┤sobom, tak┼że nedo┼ílo k ┼żiadnej kontamin├ícii. Swapy 1 a 2 prebiehaj├║ s├║be┼żne. Nedo┼ílo k ┼żiadnej kontamin├ícii, preto┼że v┼íetky batchery navz├íjom synchronizovali glob├ílny stav.

V┼íimnite si, ┼że token X m├í presne 2x v├Ą─Ź┼íiu trhov├║ hodnotu ako token Y a zhodou okolnost├ş boli v poole likvidity vhodn├ę UTxO na p├írovanie. V├Żmena 1 spotrebuje 100 tokenov X a 50 tokenov Y. Swap 2 spotrebuje 200 tokenov X a 100 tokenov Y. Ak by v poole nebol UTxO so 100 X tokeny, druh├Żm najvhodnej┼í├şm by bol UTxO so 114 X tokeny. To znamen├í, ┼że 14 X tokenov by sa muselo vr├íti┼ą do fondu likvidity ako nov├Ż UTxO.

Jednou z ─Ćal┼í├şch v├Żziev, ktorej sa v ─Źl├ínku nebudeme ─Ćalej venova┼ą, je vhodn├Ż v├Żber UTxO pre swapy. Pri Ethereu to nie je probl├ęm, preto┼że sa v podstate aktualizuj├║ len zostatky na ├║─Źtoch.

O probl├ęme je mo┼żn├ę uva┼żova┼ą aj ├║plne in├Żm sp├┤sobom ako pomocou poolu likvidity. Namiesto umiestnenia UTxO do jedn├ęho poolu je mo┼żn├ę prepoji┼ą jednotliv├Żch kandid├ítov na swap. Kv├┤li zjednodu┼íeniu sa v┼íak v tomto ─Źl├ínku dr┼żme baz├ęnov likvidity.

N├ívrh DEX na Cardano, ktor├Ż dok├í┼że paralelne spracov├íva┼ą UTxOs pri zachovan├ş decentraliz├ície, zah┼Ľ┼ła rie┼íenie probl├ęmu s├║be┼żnosti. To je jedna z v├Żziev pre v├Żvoj├írov.

V ─Źl├ínku sme uk├ízali jedno z mo┼żn├Żch rie┼íen├ş, t. j. pou┼żitie komponentov mimo re┼ąazca a na re┼ąazci. Komponentu off-chain mo┼żno pou┼żi┼ą na spr├ívne vytvorenie transakci├ş na interakciu s k├│dom on-chain. Korektnos┼ą je zabezpe─Źen├í prostredn├şctvom off-chain komunik├ície umo┼ż┼łuj├║cej synchroniz├íciu glob├ílneho stavu aplik├ície.

Jedn├Żm z ─Ćal┼í├şch mo┼żn├Żch pr├şstupov je vytvorenie algoritmu, ktor├Ż poskytuje pou┼ż├şvate─żom exkluz├şvny pr├şstup na odoslanie po┼żadovanej akcie. Algoritmus m├┤┼że n├ísledne zl├║─Źi┼ą v┼íetky akcie dohromady, pri─Źom re┼ípektuje ─Źasovanie a spravodlivos┼ą.

V├Żvoj├íri m├┤┼żu udr┼żiava┼ą jeden stav v on-chain ─Źasti aplik├ície alebo ho rozdeli┼ą medzi viacero UTxO. Ma┼ą jeden stav v ─Źasti on-chain je jednoduch├ę, preto┼że je jednoduch┼íie udr┼żiava┼ą konzistenciu. V┼íetky ─Źasti aplik├ície pracuj├║ s rovnak├Żmi ├║dajmi. Rozdelenie stavu on-chain do viacer├Żch UTxoS m├┤┼że zv├Ż┼íi┼ą s├║be┼żnos┼ą, ale prin├í┼ía so sebou nieko─żko probl├ęmov. Spr├íva viacer├Żch UTxOs zvy┼íuje zlo┼żitos┼ą logiky inteligentn├Żch kontraktov. Je potrebn├ę zabezpe─Źi┼ą ur─Źit├║ formu synchroniz├ície, ktor├í zabezpe─Ź├ş korektnos┼ą (zamedzenie spornosti).

Jadro probl├ęmu spo─Ź├şva v dosiahnut├ş paraleliz├ície v decentralizovanom prostred├ş.

Aplika─Źn├í logika je v┼żdy prepojen├í s UTxOs. Ka┼żd├Ż UTxO predstavuje nez├ívisl├║ ─Źas┼ą stavu, ktor├║ mo┼żno spracova┼ą paralelne. Ako sme vysvetlili v ─Źl├ínku, je to mo┼żn├ę len vtedy, ak je implementovan├í nejak├í spo─żahliv├í forma synchroniz├ície.

Ak by existoval len jeden d├ívkova─Ź alebo agent mimo re┼ąazca, mohol by spravova┼ą stav DEX a pripravova┼ą transakcie bez toho, aby sa musel stara┼ą o probl├ęmy so s├║be┼żnos┼ąou. To by potenci├ílne mohlo vies┼ą k r├Żchlej┼íiemu spracovaniu transakci├ş a vy┼í┼íej priepustnosti.

Tento pr├şstup by v┼íak v podstate centralizoval ─Źas┼ą DEX mimo re┼ąazca, ─Źo je v rozpore so z├ísadou decentraliz├ície. V├Żzvou je preto dosiahnu┼ą decentraliz├íciu mimo re┼ąazca a z├írove┼ł zachova┼ą vysok├Ż v├Żkon a vyhn├║┼ą sa probl├ęmom so s├║be┼żnos┼ąou.

V├Żvoj├íri Etherea tie┼ż ─Źelia v├Żzvam

Ethereum pou┼ż├şva model zalo┼żen├Ż na ├║─Źtoch a inteligentn├ę kontrakty maj├║ glob├ílny stav, ktor├Ż sa aktualizuje transakciami. Glob├ílny stav je k├│d (funkcie) a ├║daje (stav), ktor├ę sa nach├ídzaj├║ na konkr├ętnej adrese v blockchaine Ethereum.

Glob├ílny stav DEX by mohol predstavova┼ą aktu├ílny stav knihy objedn├ívok vr├ítane v┼íetk├Żch otvoren├Żch objedn├ívok na n├íkup a predaj. Ke─Ć sa zad├í nov├í swapov├í transakcia, predstavuje potenci├ílnu zmenu tohto glob├ílneho stavu. T├íto zmena sa v┼íak stane akceptovanou a┼ż po zaraden├ş transakcie do bloku a jej overen├ş sie┼ąou.

Transakcie v Ethereu sa sprac├║vaj├║ postupne, jedna po druhej. To znamen├í, ┼że vo svete Ethereum neexistuje s├║be┼żnos┼ą, a teda ani probl├ęmy so s├║be┼żnos┼ąou. Toto sekven─Źn├ę spracovanie zjednodu┼íuje n├ívrh DEX na Ethereum, pokia─ż ide o s├║be┼żnos┼ą a paralelizmus, preto┼że v├Żvoj├íri sa nemusia zaobera┼ą zlo┼żitos┼ąou spr├ívy s├║be┼żn├Żch transakci├ş.

Toto sekven─Źn├ę overovanie v┼íak nedok├í┼że vyu┼żi┼ą s├║be┼żnos┼ą. Paraleln├ę vykon├ívanie transakci├ş by nebolo bezpe─Źn├ę, preto┼że medzi kontraktmi m├┤┼żu existova┼ą z├ívislosti. Ak jedna zmluva z├ívis├ş od v├Żsledkov inej zmluvy, potom tieto zmluvy mus├ş ka┼żd├Ż valid├ítor vykona┼ą v rovnakom porad├ş.

Poradie transakci├ş v r├ímci bloku ur─Źuj├║ valid├ítory. M├┤┼żu sa rozhodn├║┼ą zoradi┼ą transakcie na z├íklade faktorov, ako je cena GAS, nonce a ─Źas prv├ęho zobrazenia. Preto hoci DEX m├┤┼że vytvori┼ą frontu mnoh├Żch swapov, nem├┤┼że si by┼ą ist├Ż, v akom porad├ş sa tieto swapy vykonaj├║.

T├íto neistota m├┤┼że vies┼ą k situ├íci├ím, ke─Ć transakcie zlyhaj├║ v d├┤sledku pretekov, ke─Ć r├┤zne transakcie s├║┼ąa┼żia o spotrebu rovnakej likvidity. Na rie┼íenie tejto situ├ície niektor├ę DEX implementuj├║ mechanizmy, ako s├║ tolerancia sklzu a term├şny transakci├ş, aby zv├Ż┼íili pravdepodobnos┼ą ├║spe┼ín├ęho vykonania transakci├ş.

Podmienka pretekov m├┤┼że nasta┼ą, ke─Ć sa viacero pou┼ż├şvate─żov pok├║si vymeni┼ą tokeny v rovnakom ─Źase. Povedzme napr├şklad, ┼że dvaja pou┼ż├şvatelia chc├║ obaja vymeni┼ą ETH za USDT a v poole likvidity je dostatok USDT len na to, aby sa uskuto─Źnila jedna z v├Żmen. Obaja pou┼ż├şvatelia predlo┼żia svoje swapov├ę transakcie pribli┼żne v rovnakom ─Źase. Valid├ítori Etherea rozhodn├║ o porad├ş, v akom bud├║ tieto transakcie zahrnut├ę do bloku.

Ak bude transakcia pou┼ż├şvate─ża A zaraden├í ako prv├í, jeho swap prejde a v poole nezostane dostatok USDT pre swap pou┼ż├şvate─ża B. Ke─Ć sa sie┼ą Ethereum pok├║si spracova┼ą transakciu pou┼ż├şvate─ża B, zlyh├í, preto┼że nem├┤┼że splni┼ą swap.

V├Żsledok z├ívis├ş od relat├şvneho na─Źasovania dvoch alebo viacer├Żch oper├íci├ş (swapov). Aj ke─Ć Ethereum sprac├║va transakcie sekven─Źne, k pretekom m├┤┼że d├┤js┼ą aj vtedy, ke─Ć viacer├ę transakcie z├ívisia od zdie─żan├ęho zdroja (ako napr├şklad baz├ęn likvidity v DEX) a s├║ odoslan├ę pribli┼żne v rovnakom ─Źase.

V┼íimnite si, ┼że race condition m├┤┼że nasta┼ą aj vtedy, ak je pool likvidity spravovan├Ż len jedn├Żm DEX. Je to preto, ┼że stav pretekov nie je sp├┤soben├Ż samotn├Żm DEX, ale povahou spracovania transakci├ş.

In├Żmi slovami, aplik├ície na Ethereum m├┤┼żu preferova┼ą ur─Źit├ę poradie, v ktorom by sa mali transakcie spracova┼ą, ale nie je to pod ich vlastnou kontrolou. V pr├şpade Cardano sa transakcie sprac├║vaj├║ pod─ża z├ísady ÔÇťkto prv pr├şde, ten prv melieÔÇŁ. Je v┼íak potrebn├ę spomen├║┼ą, ┼że pooly sa t├Żmto pravidlom nemusia riadi┼ą a neexistuje mechanizmus, ktor├Ż by pooly n├║til spr├ívne vybera┼ą transakcie z mem-poolu.

Po─Ćme si v kr├ítkosti porovna┼ą v├Żzvy pre v├Żvoj├írov na oboch platform├ích.

Pri vytv├íran├ş DEX alebo akejko─żvek inej decentralizovanej aplik├ície na Cardano je jednou z v├Żziev spr├íva a synchroniz├ícia ─Źast├ş stavu vo viacer├Żch UTXO a agentoch. To umo┼ż┼łuje vy┼í┼íiu priepustnos┼ą a ┼ík├ílovate─żnos┼ą, ale z├írove┼ł prin├í┼ía ─Ćal┼íie zlo┼żitosti s├║visiace so spr├ívou s├║be┼żn├Żch transakci├ş.

Aplik├ícia m├┤┼że spravova┼ą a aktualizova┼ą svoj stav mimo re┼ąazca a potom pravidelne odovzd├íva┼ą stav do blockchainu. Tento pr├şstup m├┤┼że pom├┤c┼ą zn├ş┼żi┼ą za┼ąa┼żenie blockchainu a zv├Ż┼íi┼ą r├Żchlos┼ą transakci├ş. Synchroniz├ícia mimo re┼ąazca m├┤┼że navy┼íe u─żah─Źi┼ą aj paraleln├ę vykon├ívanie transakci├ş v re┼ąazci. DEX m├┤┼że paralelne pripravi┼ą viacero transakci├ş a potom ich odosla┼ą do blockchainu na vykonanie.

R├Żchla synchroniz├ícia mimo re┼ąazca m├┤┼że potenci├ílne vies┼ą k vysokej ┼ík├ílovate─żnosti a paralelnosti v re┼ąazci. V├Żvoj├íri sa sna┼żia dosiahnu┼ą maxim├ílnu mo┼żn├║ paraleliz├íciu prostredn├şctvom synchroniz├ície.

T├Żm sa l├ş┼íi od modelu Etherea zalo┼żen├ęho na ├║─Źtoch, kde je stav celej aplik├ície ulo┼żen├Ż v jednom glob├ílnom stave. Glob├ílny stav m├┤┼że obsahova┼ą v┼íetky potrebn├ę ├║daje pre DEX a men├ş sa prostredn├şctvom transakci├ş. Ke─Ć┼że Ethereum spracov├íva transakcie (volania) sekven─Źne, v├Żvoj├íri sa v├┤bec nemusia stara┼ą o s├║be┼żnos┼ą.

Probl├ęmom v┼íak je, ┼że ur─Źit├║ formu paralelizmu predstavuje spr├ívanie pou┼ż├şvate─żov, ktor├ş sa m├┤┼żu pok├║si┼ą spotrebova┼ą rovnak├║ likviditu v DEX na Ethereum. V podstate bojuj├║ o jeden zdroj podobne ako batcheri, ktor├ş m├┤┼żu chcie┼ą spotrebova┼ą rovnak├ę UTxO.

V├Żvoj├íri Ethereum DEX nedok├í┼żu ├║plne zabr├íni┼ą pretekov├Żm podmienkam s├║visiacim s pokusmi viacer├Żch pou┼ż├şvate─żov spotrebova┼ą rovnak├║ likviditu. Stav poolu likvidity (t. j. ko─żko likvidity je k dispoz├şcii) je ur─Źen├Ż transakciami, ktor├ę boli zahrnut├ę do blockchainu. Pou┼ż├şvatelia v re├ílnom ─Źase nevedia, ─Źi ich transakcie bud├║ ├║spe┼ín├ę, preto┼że Ethereum spracov├íva transakcie sekven─Źne a o porad├ş rozhoduj├║ valid├ítory.

V├Żvoj├íri sa m├┤┼żu pok├║si┼ą vytvori┼ą nejak├Ż mechanizmus, ktor├Ż by pou┼ż├şvate─żom zabr├ínil odosla┼ą transakciu, ktor├í m├í vysok├║ pravdepodobnos┼ą ne├║spechu. Je to v┼íak ve─żmi n├íro─Źn├í ├║loha.

V┼íimnite si, ┼że Cardano sa na rozdiel od Etherea spr├íva deterministicky.

Záver

Na pln├ę vyu┼żitie modelu UTxO a paraleliz├ície je potrebn├ę vylep┼íi┼ą Ouroboros Proof-of-Stake. Sie┼ą Cardano mus├ş by┼ą schopn├í validova┼ą a predbe┼żne schva─żova┼ą ve─żk├Ż po─Źet transakci├ş naraz. Ak by sa raz za 20 sek├║nd vlo┼żilo do bloku nieko─żko desiatok transakci├ş, nez├íle┼ż├ş na tom, ┼że je mo┼żn├ę ich spracova┼ą paralelne. ┼ák├ílovate─żnos┼ą by bola st├íle relat├şvne n├şzka. Vstupn├ę endorsery prines├║ potrebn├ę zlep┼íenie konsenzu PoS, v ktorom model UTxO za┼żiari podstatne viac.


P├┤vodn├Ż ─Źl├ínok: Challenges for Cardano Developers | Cardano Explorer (cexplorer.io)