WALLETS•EXCHANGES•ROADMAP•BLOG•DOCUMENTATION•SIGMAVERSE•ERGOBLOCKCHAIN

FlowCards: Deklaratívny rámec pre vývoj Ergo dApps

This page is machine-translated.

Alexander Slesarenko

29. apríla 2020

S poďakovaním Robertovi Kornackimu za vylepšenie návrhu.

Úvod

ErgoScript je jazyk smart kontraktov používaný
blockchainom Ergo. Hoci má stručnú syntax prevzatú zo Scaly/Kotlinu, môže sa na prvý pohľad
javiť ako mätúca, pretože konceptuálne je ErgoScript dosť odlišný v porovnaní s
konvenčnými jazykmi, ktoré všetci poznáme a milujeme. Dôvodom je, že Ergo je blockchain založený na UTXO,
pričom smart kontrakty sú tradične spojené s účtovými systémami ako Ethereum. Avšak transakčný model Ergo má
mnohé výhody oproti modelu založenému na účtoch a s správnym prístupom môže byť dokonca
výrazne jednoduchšie vyvíjať Ergo kontrakty ako písať a ladit kód v Solidity.

Nižšie sa budeme zaoberať kľúčovými aspektmi modelu kontraktov Ergo, ktoré ho robia odlišným:

Paradigma

Model účtu Etherea je imperatívny. To znamená, že typická úloha posielania mincí z
Alice Bobovi si vyžaduje zmenu zostatkov v úložisku ako sériu operácií. Na druhej strane,
programovací model Ergo založený na UTXO je deklaratívny. ErgoScript kontrakty špecifikujú podmienky,
za ktorých bude transakcia prijatá blockchainom (nie zmeny, ktoré sa majú vykonať v stave úložiska
ako výsledok vykonania kontraktu).

Škálovateľnosť

V účtovom modeli Etherea sa zmeny úložiska a kontroly platnosti vykonávajú
on-chain počas vykonávania kódu. Naopak, transakcie Ergo sú vytvárané
off-chain a iba kontroly platnosti sa vykonávajú on-chain, čím sa znižuje množstvo
operácií vykonávaných každým uzlom v sieti. Okrem toho, vďaka nemennosti
transakčného grafu sú možné rôzne optimalizačné stratégie na zlepšenie priepustnosti
transakcií za sekundu v sieti. Ľahké overovacie uzly sú tiež možné, čím sa
ďalej uľahčuje škálovateľnosť a prístupnosť siete.

Zdieľaný stav

Model založený na účtoch sa spolieha na zdieľaný mutabilný stav, ktorý je známy tým, že vedie
to zložitým sémantickým problémom (a jemným miliónovým chybám) v kontexte súbežného/
distribuovaného výpočtu. Model Ergo je založený na nemennom grafe transakcií. Tento
prístup, prevzatý z Bitcoinu, dobre funguje so súbežnou a distribuovanou povahou
blockchainov a uľahčuje ľahkých bezdôveryhodných klientov.

Výrazová moc

Ethereum presadzovalo vykonávanie turing-complete jazyka na blockchain. Teoreticky sľubovalo
neobmedzený potenciál, avšak v praxi sa objavili vážne
obmedzenia z nadmerného zbytočného blockchainu, jemných miliónových chýb, nákladov na plyn,
ktoré obmedzujú zložitosti kontraktov, a iných podobných problémov. Ergo naopak rozširuje UTXO, aby umožnilo
turing-completeness pri obmedzení zložitosti samotného jazyka ErgoScript. Rovnaká
výrazová moc je dosiahnutá iným a semanticky zvukovejším spôsobom.

S všetkými vyššie uvedenými bodmi by malo byť jasné, že model, ktorý Ergo používa, má veľa výhod.
V zvyšku tohto článku vás oboznámim s konceptom FlowCards - komponentom pre vývojárov dApp,
ktorý umožňuje navrhovať zložité Ergo kontrakty deklaratívne a vizuálne.

Z imperatívneho na deklaratívne

V imperatívnom programovacom modeli Etherea je transakcia sekvenciou operácií
vykonávaných Ethereum VM. Nasledujúca Solidity funkcia
implementuje prevod tokenov z sender na receiver. Transakcia začína, keď
sender zavolá túto funkciu na inštancii kontraktu a končí, keď funkcia
vráti.

// Posiela množstvo existujúcich mincí od akéhokoľvek volajúceho na adresu
function send(address receiver, uint amount) public {
    require(amount <= balances[msg.sender], "Nedostatočný zostatok.");
    balances[msg.sender] -= amount;
    balances[receiver] += amount;
    emit Sent(msg.sender, receiver, amount);
}

Funkcia najprv kontroluje predpoklady, potom aktualizuje úložisko (t.j. zostatky) a
nakoniec zverejňuje post-podmienku ako udalosť Sent. Plyn, ktorý je spotrebovaný
transakciou, je poslaný baníkovi ako odmena za vykonanie tejto transakcie.

Na rozdiel od Etherea, transakcia v Ergu je dátová štruktúra, ktorá obsahuje zoznam vstupných mincí,
ktoré míňa, a zoznam výstupných mincí, ktoré vytvára, pričom zachováva celkové zostatky
ERGs a tokenov (v čom je Ergo podobné Bitcoinu).

Vrátiac sa k vyššie uvedenému príkladu, keďže Ergo nativne podporuje tokeny, preto pre tento
konkrétny príklad posielania tokenov nemusíme písať žiadny kód v ErgoScript. Namiesto toho
musíme vytvoriť transakciu 'send', ako je znázornené na nasledujúcej obrázku, ktorá popisuje
rovnaký prevod tokenov, ale deklaratívne.

Send

Obrázok vizuálne popisuje nasledujúce kroky, ktoré musí používateľ siete
vykonať:

Vybrať nevyužité boxy odosielateľa, ktoré obsahujú celkovo tB >= amount tokenov a B >= txFee + minErg ERGs.
Vytvoriť výstupný box target, ktorý je chránený verejným kľúčom receiver s minErg
ERGs a amount tokenov T.
Vytvoriť jeden fee výstup chránený kontraktom minerFee s txFee ERGs.
Vytvoriť jeden change výstup chránený verejným kľúčom sender, obsahujúci
B - minErg - txFee ERGs a tB - amount tokenov T.
Vytvoriť novú transakciu, podpísať ju pomocou tajného kľúča odosielateľa a poslať do siete Ergo.

Dôležité je pochopiť, že všetky tieto kroky sa vykonávajú off-chain (napríklad pomocou
Appkit Transaction API) aplikáciou používateľa. Uzly siete Ergo
nemusia opakovať tento proces vytvárania transakcie, musia iba overiť už vytvorenú transakciu. Kontrakty
ErgoScript sú uložené vo vstupoch transakcie a kontrolujú podmienky míňania. Uzol vykonáva
kontrakty on-chain, keď je transakcia overená. Transakcia je platná, ak sú splnené všetky
podmienky.

Takže, v Ethereu, keď "posielame množstvo odosielateľa k príjemcovi", doslova
editujeme zostatky a aktualizujeme úložisko s konkrétnou sadou príkazov. To sa deje
on-chain a tak je nová transakcia tiež vytvorená on-chain ako výsledok tohto procesu.

V Ergu (ako v Bitcoine) sú transakcie vytvárané off-chain a uzly siete ich iba
overujú. Účinky transakcie na stav blockchainu sú také, že vstupné mince
(alebo boxy v terminológii Erga) sú odstránené a výstupné boxy sú pridané do
UTXO súboru.

V vyššie uvedenom príklade nepoužívame kontrakt ErgoScript, ale predpokladáme, že sa
používa kontrola podpisu ako predpoklad míňania. Avšak v zložitejších aplikačných scenároch
samozrejme potrebujeme použiť ErgoScript, o čom budeme diskutovať ďalej.

Od zmeny stavu k overovaniu kontextu

V príklade funkcie send sme najprv skontrolovali predpoklad (require(amount <= balances[msg.sender],...)) a potom sme zmenili stav (t.j. aktualizovali zostatky
balances[msg.sender] -= amount). To je typické pre transakcie Etherea. Predtým,
ako niečo zmeníme, musíme skontrolovať, či je to platné.

V Ergu, ako sme už predtým diskutovali, sa stav (t.j. UTXO súbor boxov) mení implicitne, keď je
platná transakcia zahrnutá do bloku. Takže musíme iba skontrolovať predpoklady predtým,
ako môže byť transakcia pridaná do bloku. To je to, čo robia kontrakty ErgoScript.

Nie je možné "zmeniť stav" v ErgoScript, pretože je to jazyk na kontrolu
predpokladov pre míňanie mincí. ErgoScript je čisto funkčný jazyk bez vedľajších
účinkov, ktorý pracuje s nemennými hodnotami dát. To znamená, že všetky vstupy, výstupy a
iné parametre transakcie dostupné v skripte sú nemenné. To, okrem iného,
robí ErgoScript veľmi jednoduchým jazykom, ktorý sa ľahko učí a bezpečne používa. Podobne ako
v Bitcoine, každý vstupný box obsahuje skript, ktorý by mal vrátiť hodnotu true, aby

umožnil míňanie boxu (t.j. odstránenie z UTXO súboru) a 2) pridal
transakciu do bloku.

Ak sme pedantní, je preto nesprávne (prísne povedané) myslieť na ErgoScript ako na jazyk
kontraktov Ergo, pretože je to jazyk propozícií (logických predpokladov, formulí,
etc.), ktoré chránia boxy pred "nelegálnym" míňaním. Na rozdiel od Bitcoinu, v Ergu je celý
transakcia a časť aktuálneho kontextu blockchainu dostupná pre každý skript. Preto
každý skript môže skontrolovať, ktoré výstupy sú vytvorené transakciou, ich ERG a tokeny
(môžeme túto schopnosť využiť v našich príkladoch DEX kontraktov), aktuálne číslo bloku
atď.

V ErgoScript definujete podmienky, za ktorých sú zmeny (t.j. míňanie mincí) povolené
v danom kontexte. To je v kontraste s programovaním zmien
imperatívne v kóde kontraktu.

Zatiaľ čo transakčný model Erga odomyká celú škálu aplikácií ako (DEX, DeFi
aplikácie, LETS atď.), navrhovanie kontraktov ako predpokladov pre míňanie mincí (alebo strážnych
skriptov) priamo nie je intuitívne. V nasledujúcich sekciách zvážime užitočnú grafickú
notáciu na navrhovanie kontraktov deklaratívne pomocou FlowCard diagramov, čo je vizuálne
zobrazenie vykonateľných komponentov (FlowCards).

FlowCards majú za cieľ radikálne zjednodušiť vývoj dApp na platforme Ergo tým,
že poskytujú jazyk na vysokej úrovni, vykonávací runtime, formát úložiska a
grafickú notáciu.

Začneme s vysokou úrovňou diagramov a prejdeme k špecifikácii FlowCard.

FlowCard diagramy

Myšlienka za FlowCard diagramami je založená na nasledujúcich pozorovaniach: 1) Ergo box
je nemenný a môže byť míňaný iba v transakcii, ktorá ho používa ako vstup. 2) Môžeme
preto nakresliť tok boxov cez transakcie, tak, že boxy prichádzajúce do
transakcie sú míňané a tie odchádzajúce sú vytvorené a pridané do UTXO. 3) Transakcia z tohto
pohľadu je jednoducho transformátorom starých boxov na nové, pričom zachováva zostatky ERGs a tokenov.

Nasledujúci obrázok zobrazuje hlavné prvky transakcie Ergo, ktoré sme už videli
predtým (teraz pod názvom FlowCard diagram).

Anatomy

Za každým prvkom diagramu je prísne definovaný význam (sémantika),
aby diagram bol vizuálnym zobrazením (alebo pohľadom) na podkladový vykonateľný
komponent (nazývaný FlowCard).

FlowCard môže byť použitý ako opakovane použiteľný komponent dApp Ergo na vytvorenie a iniciovanie
transakcie na blockchainu Ergo. O tom budeme diskutovať v nasledujúcich sekciách.

Teraz sa pozrime na jednotlivé časti diagramu FlowCard jednu po druhej.

1. Názov a parametre

Každej flow karte je pridelený názov a zoznam typovaných parametrov. To je podobné šablóne s parametrami. Na vyššie uvedenom obrázku vidíme flow kartu Send, ktorá má päť parametrov.
Parametre sa používajú v špecifikácii.

2. Kontraktová peňaženka

Toto je kľúčový prvok flow karty. Každý box má strážny skript. Často je to
skript, ktorý kontroluje podpis voči verejnému kľúču. Tento skript je triviálny v ErgoScript
a je definovaný ako šablóna def pk(pubkey: Address) = { pubkey }, kde pubkey je
parametrom typu Address. Na obrázku je šablóna skriptu aplikovaná na
parametr pk(sender) a tak sa získa konkrétny kontrakt peňaženky. Preto
pk(sender) a pk(receiver) produkujú rôzne skripty a predstavujú rôzne peňaženky
na diagrame, aj keď používajú tú istú šablónu.

Kontraktová peňaženka obsahuje súbor všetkých UTXO boxov, ktoré majú daný skript odvodený od
danej šablóny skriptu pomocou parametrov flow karty. Napríklad, na obrázku je
šablóna pk a parameter pubkey je nahradený parametrom flow karty sender.

3. Kontrakt

Aj keď je kontrakt vlastnosťou boxu, na diagrame skupinujeme boxy podľa ich
kontraktov, preto to vyzerá, akoby boxy patrili kontraktom, skôr než aby kontrakty patrili boxom. V príklade máme tri inštancované kontrakty
pk(sender), pk(receiver) a minerFee. Poznámka, že pk(sender) je inštanciácia
šablóny pk s konkrétnym parametrom sender a minerFee je inštanciácia
preddefinovaného kontraktu, ktorý chráni boxy odmeny baníka.

4. Názov boxu

Na diagrame môžeme každému boxu priradiť názov. Okrem čitateľnosti diagramu, používame aj
názov ako synonymum pre zložitejší indexovaný prístup k boxu v kontrakte. Napríklad,
change je názov boxu, ktorý môže byť tiež použitý v podmienkach ErgoScript
namiesto OUTPUTS(2). Používame aj názvy boxov na priradenie podmienok míňania
k boxom.

5. Boxy v peňaženke

Na diagrame zobrazuje boxy (tmavšie obdĺžniky) ako patriace kontraktovým peňaženkám
(svetlejšie obdĺžniky). Každý taký box obdĺžnik je spojený so šedým transakčným
obdĺžnikom buď oranžovými alebo zelenými šípkami
alebo oboma. Výstupný box (s prichádzajúcou zelenou šípkou) môže obsahovať mnoho riadkov textu, kde každý
riadok špecifikuje podmienku, ktorá by mala byť skontrolovaná ako súčasť transakcie. Prvý
riadok špecifikuje podmienku na množstvo ERG, ktoré by malo byť umiestnené v boxe. Iné
riadky môžu mať jednu z nasledujúcich foriem:

amount: TOKEN - box by mal obsahovať dané amount daného TOKEN
R == value - box by mal obsahovať danú value daného registra R
boxName ? condition - box s názvom boxName by mal skontrolovať condition vo svojom skripte.

Tieto podmienky diskutujeme v nasledujúcich sekciách.

6. Množstvo ERGs v boxe

Každý box by mal uchovávať minimálne množstvo ERGs. To sa kontroluje, keď je
vytváraná transakcia overená. Na diagrame je množstvo ERGs vždy zobrazené ako prvý riadok (napr. B: ERG alebo B - minErg - txFee). Typová priradenie hodnoty B: ERG je voliteľné a môže
byť použité pre čitateľnosť. Keď je hodnota daná ako formula, potom by táto formula mala byť
respektovaná transakciou, ktorá vytvára box.

Je dôležité pochopiť, že premenné ako amount a txFee nie sú pomenované
vlastnosti boxov. Sú to parametre celého diagramu a predstavujú nejaké
množstvá. Alebo inak povedané, sú to zdieľané parametre medzi transakciami (napr. Predajná
objednávka a Swap transakcie z DEX príkladu nižšie zdieľajú parameter tAmt). Takže
rovnaké meno je viazané na tú istú hodnotu v celom diagrame (toto je miesto, kde by
nástroje veľmi pomohli). Avšak, pokiaľ ide o on-chain overovanie týchto hodnôt,
iba explicitné podmienky, ktoré sú označené ?, sú transformované na ErgoScript. Zároveň
všetky ostatné podmienky sú zabezpečené off-chain počas budovania transakcie (napríklad v
aplikácii používajúcej Appkit API) a overovania transakcie, keď je pridaná do
blockchainu.

7. Množstvo T tokenu

Box môže uchovávať hodnoty mnohých tokenov. Tokeny na diagrame sú pomenované a premenná value
sa môže asociovať s tokenom T pomocou výrazu value: T. value môže
byť dané formulou. Ak je formula predponovaná názvom boxu ako boxName ? formula,
tak by sa mala tiež skontrolovať v strážnom skripte boxu boxName. Táto
ďalšia špecifikácia je veľmi pohodlná, pretože 1) umožňuje automaticky overiť vizuálny
dizajn a 2) podmienky špecifikované v boxoch diagramu sú dostatočné na syntézu potrebných strážnych skriptov. (viac o tom
nižšie v "Od diagramov k ErgoScript kontraktom")

8. Vstupy Tx

Vstupy sú spojené s príslušnou transakciou oranžovými
árovnami. Vstupná šípka môže mať označenie nasledujúcich foriem:

name@index - voliteľný názov s indexom, t.j. fee@0 alebo @2. Toto je vlastnosť
target endpointu šípky. Názov sa používa v podmienkach súvisiacich boxov
a index je pozícia príslušného boxu v kolekcii INPUTS transakcie.
!action - je vlastnosť zdroja šípky a dáva názov alternatívnej
ceste míňania boxu (toto uvidíme v DEX príklade)

Vzhľadom na alternatívne cesty míňania môže mať box mnoho odchádzajúcich oranžových šípok, v ktorých prípade by mali byť označené rôznymi
akciami.

9. Transakcia

Transakcia míňa vstupné boxy a vytvára výstupné boxy. Vstupné boxy sú dané
oranžovými šípkami a očakáva sa, že označenia umiestnia vstupy na
správne indexy v kolekcii INPUTS. Výstupné boxy sú dané zelenými šípkami. Každá transakcia by mala zachovať prísny zostatok hodnôt ERG
(súčet vstupov == súčet výstupov) a pre každý token by mal byť súčet vstupov >= súčet
výstupov. Dizajnový diagram vyžaduje explicitnú špecifikáciu hodnôt ERG a tokenov pre všetky výstupné boxy, aby sa predišlo implicitným chybám a zabezpečila sa lepšia čitateľnosť.

10. Výstupy Tx

Výstupy sú spojené s príslušnou transakciou zelenými
árovnami. Výstupná šípka môže mať označenie nasledujúcej formy name@index, kde je
voliteľný názov sprevádzaný indexom, t.j. fee@0 alebo @2. Toto je vlastnosť
zdrojového endpointu šípky. Názov sa používa v podmienkach súvisiacich boxov a
index je pozícia príslušného boxu v kolekcii OUTPUTS transakcie.

Príklad: Decentralizovaná burza (DEX)

Teraz použijeme vyššie opísanú notáciu na navrhnutie FlowCard pre DEX dApp. Je to dostatočne jednoduché,
ale tiež ilustruje všetky kľúčové funkcie diagramov FlowCard,
ktoré sme predstavili v predchádzajúcej sekcii.

Scenár dApp je zobrazený na obrázku nižšie:
Existujú traja účastníci (kupujúci,
predávajúci a DEX) DEX dApp a päť rôznych typov transakcií, ktoré vytvárajú
účastníci. Kupujúci chce vymeniť ergAmt ERGs za tAmt tokenov TID (alebo naopak, predávajúci chce predať TID tokeny za ERGs, kto pošle objednávku prvý, nezáleží). Obaja, kupujúci aj predávajúci, môžu kedykoľvek zrušiť svoje objednávky. DEX off-chain
matching služba môže nájsť zhodujúce sa objednávky a vytvoriť transakciu Swap, aby
ukončila výmenu.

Nasledujúci diagram plne (a formálne) špecifikuje všetkých päť transakcií, ktoré musia
byť vytvorené off-chain DEX dApp. Taktiež špecifikuje všetky podmienky míňania, ktoré
by mali byť overené on-chain.

DEX

Poďme podrobne prediskutovať diagram FlowCard a logiku každej transakcie:

Transakcia objednávky na nákup

Kupujúci vytvára transakciu Buy Order. Transakcia míňa E množstvo ERGs
(ktoré napíšeme E: ERG) z jedného alebo viacerých boxov v peňaženke pk(buyer). Transakcia vytvára bid box s ergAmt: ERG chráneným skriptom buyOrder. Skript buyOrder je syntetizovaný zo špecifikácie (pozri
nižšie v "Od diagramov k ErgoScript kontraktom") buď manuálne alebo automaticky pomocou
nástroja. Aj keď nemusíme explicitne definovať skript buyOrder počas
navrhovania, v čase vykonávania by mal bid box obsahovať skript buyOrder ako
strážnu propozíciu (ktorá kontroluje podmienky míňania boxu), inak nebudú podmienky
špecifikované v diagrame skontrolované.

Box change je vytvorený na vyváženie súčtov vstupov a výstupov transakcie.
Box transakčného poplatku je vynechaný, pretože ho môžu nástroje automaticky pridať. V
praxi však môže dizajnér pridať box poplatku explicitne do diagramu. Pokrýva
prípady zložitejších transakcií (ako Swap), kde existuje mnoho spôsobov, ako zaplatiť
transakčný poplatok.

Zrušiť nákup, zrušiť predaj transakcie

Kedykoľvek môže kupujúci zrušiť objednávku odoslaním transakcie CancelBuy. Transakcia by mala
splniť strážny kontrakt buyOrder, ktorý chráni bid box. Ako vidíte na diagrame, obidve transakcie Cancel a Swap môžu míňať
bid box. Keď má box alternatívy míňania (alebo cesty míňania), každá
alternatíva je identifikovaná jedinečným názvom predponovaným ! (!cancel a !swap
pre bid box). Každá alternatívna cesta má špecifické podmienky míňania. V našom príklade,
keď transakcia Cancel Buy míňa bid box, podmienka ?buyer by mala byť
splnená, čo čítame ako "podpis pre adresu buyer by mal byť predložený v transakcii". Preto iba kupujúci môže zrušiť objednávku na nákup. Táto "podpisová" podmienka
je potrebná iba pre alternatívnu cestu míňania !cancel a nie je potrebná pre !swap.

Transakcia objednávky na predaj

Transakcia Sell Order je podobná BuyOrder v tom, že sa zaoberá tokenmi okrem ERGs. Transakcia míňa E: ERG a T: TID tokeny z peňaženky predávajúceho
(špecifikované ako kontrakt pk(seller)). Dva výstupy sú ask a change. Zmena
je štandardný box na vyváženie transakcie. Box ask uchováva tAmt: TID tokeny na výmenu
a minErg: ERG - minimálne množstvo ERGs požadovaných v každom boxe.

Transakcia Swap

Toto je kľúčová transakcia v scenári dApp DEX. Transakcia má niekoľko podmienok míňania
na vstupných boxoch a tieto podmienky sú zahrnuté v skriptoch buyOrder a
sellOrder (ktoré sú overené, keď je transakcia pridaná do
blockchainu). Avšak, na diagrame nie sú tieto podmienky špecifikované v boxoch bid a
ask, ale sú namiesto toho definované vo výstupných boxoch transakcie.

Toto je konvencia pre zlepšenie použiteľnosti, pretože väčšina podmienok sa týka vlastností
výstupných boxov. Mohli by sme špecifikovať tieto vlastnosti v boxe bid, ale potom by sme
museli použiť zložitejšie výrazy.

Zvážme výstup vytvorený šípkou označenou buyerOut@0. Táto značka nám hovorí,
že výstup je na indexe 0 v kolekcii OUTPUTS transakcie a
že na diagrame môžeme tento box označiť názvom buyerOut. Takže môžeme označiť
ako box samotný, tak aj šípku, aby sme boxu dali názov.

Podmienky zobrazené v boxe buyerOut majú formu bid ? condition, čo znamená,
že by mali byť overené on-chain na to, aby sa míňal bid box.
Podmienky majú nasledujúci význam:

tAmt: TID vyžaduje, aby box mal tAmt množstvo tokenu TID
R4 == bid.id vyžaduje, aby register R4 v boxe bol rovný id boxu bid.
script == buyer vyžaduje, aby box buyerOut mal skript peňaženky, kde sa nachádza na diagrame, t.j. pk(buyer)

Podobné vlastnosti sú pridané do boxu sellerOut, ktorý je špecifikovaný na indexe 1
a názov je mu daný pomocou označenia na boxe samotnom, skôr než na šípke.

Transakcia Swap míňa dva boxy bid a ask pomocou cesty míňania !swap na oboch,
avšak na rozdiel od !cancel nie sú podmienky na ceste špecifikované. Tu prichádzajú do hry
predpony bid ? a ask ?. Používajú sa na to, aby sa podmienky uvedené v boxoch buyerOut a
sellerOut presunuli na cesty míňania !swap boxov bid a ask zodpovedajúcim spôsobom.

Ak sa pozriete na podmienky výstupných boxov, uvidíte, že presne špecifikujú
výmenu hodnôt medzi peňaženkami predávajúceho a kupujúceho. Kupujúci dostane potrebné množstvo
tokenu TID a predávajúci dostane zodpovedajúce množstvo ERGs. Transakcia Swap
sa vytvára, keď existujú dva zhodujúce sa boxy s kontraktmi buyOrder a sellOrder.

Od diagramov k ErgoScript kontraktom

Zaujímavé na špecifikáciách FlowCard je, že ich môžeme použiť na automatické
vytváranie potrebných ErgoTree skriptov.
S vhodnou podporou nástrojov to môže byť vykonané automaticky, ale pri ich nedostatku
môže byť vykonané manuálne. Takže FlowCard nám umožňuje zachytiť a vizuálne
predstaviť všetky dizajnové voľby a sémantické detaily dApp Ergo.

Čo budeme robiť ďalej, je mechanicky vytvoriť kontrakt buyOrder z
informácií uvedených v flow karte DEX.

Pripomeňme, že každý skript je propozícia (boolean hodnotový výraz), ktorý by mal vyhodnotiť
na true, aby umožnil míňanie boxu. Keď máme mnoho podmienok, ktoré musia byť splnené
v rovnakom čase, môžeme ich kombinovať v logickej formule pomocou binárnej operácie AND,
a ak máme alternatívy (nie nevyhnutne exkluzívne), môžeme ich vložiť do operácie OR.

Box buyOrder má alternatívne cesty míňania !cancel a !swap. Takže
kód ErgoScript by mal mať operáciu OR s dvoma argumentmi - jedným pre každú cestu míňania.

/** buyOrder kontrakt */
{
  val cancelCondition = {}
  val swapCondition = {}
  cancelCondition || swapCondition
}

Formula pre výraz cancelCondition je daná v ceste míňania !cancel
boxu buyOrder. Môžeme ju priamo zahrnúť do skriptu.

/** buyOrder kontrakt */
{
  val cancelCondition = { buyer }
  val swapCondition = {}
  cancelCondition || swapCondition
}

Pre cestu míňania !swap boxu buyOrder sú podmienky špecifikované v
výstupnom boxe buyerOut transakcie Swap. Ak ich jednoducho zahrnieme do
swapCondition, dostaneme syntakticky nesprávny skript.

/** buyOrder kontrakt */
{
  val cancelCondition = { buyer }
  val swapCondition = {
    tAmt: TID &&
    R4 == bid.id &&
    @contract
  }
  cancelCondition || swapCondition
}

Môžeme však preložiť podmienky z diagramovej syntaxe na výrazy ErgoScript
použitím nasledujúcich jednoduchých pravidiel:

buyerOut@0 ==> val buyerOut = OUTPUTS(0)
tAmt: TID ==> tid._2 == tAmt kde tid = buyerOut.tokens(TID)
R4 == bid.id ==> R4 == SELF.id kde R4 = buyerOut.R4[Coll[Byte]].get
script == buyer ==> buyerOut.propositionBytes == buyer.propBytes

Poznámka, v diagrame TID predstavuje id tokenu, ale ErgoScript nemá prístup k
tokenom podľa id, takže nemôžeme napísať tokens.getByKey(TID). Z tohto dôvodu, keď je
diagram preložený do ErgoScript, TID sa stáva pomenovanou konštantou indexu v
kolekcii tokens boxu. Konkrétna hodnota konštanty je priradená, keď je
vytvorená transakcia BuyOrder s boxom buyOrder. Zodpovednosť a
konzistencia medzi skutočným tokenId, konštantou TID a skutočnými tokenmi
boxu buyerOut je zabezpečená off-chain aplikačným kódom, čo je úplne
možné, pretože všetky transakcie sú vytvárané aplikáciou pomocou FlowCard ako
navigačnej špecifikácie. Môže to znieť príliš zložito, ale to je súčasť prekladu
z diagramovej špecifikácie na skutočný vykonateľný aplikačný kód, z ktorého väčšina môže byť
automatizovaná.

Po transformácii môžeme získať správny skript, ktorý kontroluje všetky požadované
predpoklady pre míňanie boxu buyOrder.

/** buyOrder kontrakt */
def DEX(buyer: Addrss, seller: Address, TID: Int, ergAmt: Long, tAmt: Long)
{
  val cancelCondition: SigmaProp = { buyer }      // overiť podpis kupujúceho (ProveDlog)
  val swapCondition = OUTPUTS.size > 0 && {       // zabezpečenie prístupu k OUTPUTS
    val buyerOut = OUTPUTS(0)                     // z buyerOut@0
    buyerOut.tokens.size > TID && {               // zabezpečenie prístupu k tokenom
      val tid = buyerOut.tokens(TID)
      val regR4 = buyerOut.R4[Coll[Byte]]
      regR4.isDefined && {                        // zabezpečenie prístupu k R4
        val R4 = regR4.get
        tid._2 == tAmt &&                             // z tAmt: TID 
        R4 == SELF.id &&                              // z R4 == bid.id
        buyerOut.propositionBytes == buyer.propBytes  // z script == buyer
      }
    } 
  }
  cancelCondition || swapCondition
}

Podobný skript pre box sellOrder môže byť získaný pomocou rovnakých prekladových pravidiel.
S pomocou nástrojov môže byť kód kontraktov mechanicky generovaný z
špecifikácie diagramu.

Závery

Deklaratívne programovacie modely už vyhrali bitku proti imperatívnemu programovaniu
v mnohých aplikačných oblastiach ako Big Data, Stream Processing, Deep Learning, Databázy,
etc. Ergo je priekopníkom deklaratívneho modelu vývoja dApp ako lepšej a bezpečnejšej
alternatívy k teraz populárnemu imperatívnemu modelu smart kontraktov.

Koncept FlowCard presúva zameranie z písania kontraktov ErgoScript na
celkový tok hodnôt (odtiaľ názov), takým spôsobom, že ErgoScript môže byť vždy
vygenerovaný z nich. Nikdy nebudete musieť pozerať na kód ErgoScript, akonáhle sú nástroje
na mieste.

Tu sú možné ďalšie kroky pre budúcu prácu:

Formát úložiska pre špecifikáciu FlowCard a zodpovedajúci EIP štandardizovaný formát súboru
(Json/XML/Protobuf). To umožní rôznym nástrojom (Diagram Editor, Runtime, dApps atď.)
vytvárať a používať *.flowcard súbory.
Prehliadač FlowCard, ktorý môže generovať diagramy z *.flowcard súborov.
Runtime FlowCard, ktorý môže spúšťať *.flowcard súbory, vytvárať a posielať transakcie do siete Ergo.
Nástroj na návrh FlowCard, ktorý môže zjednodušiť vývoj zložitých diagramov. To
urobí navrhovanie a overovanie kontraktov Ergo príjemným zážitkom, viac ako kreslením
než kódovaním. Okrem toho môže byť správnosť celého scenára dApp
overená a kontrolovaná nástrojmi.