FlowCards: Deklaratív Keretrendszer az Ergo dApp-ok Fejlesztéséhez

Köszönet Robert Kornacki -nak a tervezet finomításáért.

Bevezetés

ErgoScript az okos szerződések nyelve, amelyet
az Ergo blokklánc használ. Bár tömör szintaxisa van, amely a Scala/Kotlin-ból származik, mégis
elsőre zavarónak tűnhet, mert fogalmilag az ErgoScript meglehetősen eltér a
hagyományos nyelvektől, amelyeket mindannyian ismerünk és szeretünk. Ennek az az oka, hogy az Ergo egy UTXO alapú
blokklánc, míg az okos szerződések hagyományosan a fiók alapú
rendszerekhez, például az Ethereumhoz kapcsolódnak. Azonban az Ergo tranzakciós modellje számos előnnyel rendelkezik a fiók
alapú modellel szemben, és a megfelelő megközelítéssel még jelentősen könnyebb lehet Ergo szerződéseket fejleszteni,
mint Solidity kódot írni és hibakeresni.

Az alábbiakban áttekintjük az Ergo szerződési modell kulcsfontosságú aspektusait, amelyek megkülönböztetik:

Paradigma

Az Ethereum fiók modellje imperatív. Ez azt jelenti, hogy a tipikus feladat, hogy érméket küldjünk
Alice-tól Bobnak, a tárolási egyensúlyok sorozatának megváltoztatását igényli. Az Ergo UTXO
alapú programozási modellje ezzel szemben deklaratív. Az ErgoScript szerződések feltételeket határoznak meg ahhoz,
hogy egy tranzakciót elfogadjon a blokklánc (nem a tárolási állapot megváltoztatását az
szerződés végrehajtásának eredményeként).

Skálázhatóság

Az Ethereum fiók modelljében mind a tárolási változások, mind a érvényességi ellenőrzések
on-chain történnek a kód végrehajtása során. Ezzel szemben az Ergo tranzakciók
off-chain jönnek létre, és csak az érvényességi ellenőrzések történnek on-chain, így csökkentve a
hálózat minden csomópontja által végrehajtott műveletek számát. Ezenkívül a tranzakciós grafikon
változatlansága miatt különböző optimalizálási stratégiák lehetségesek a tranzakciók másodpercenkénti áteresztőképességének
javítására a hálózatban. Könnyű ellenőrző csomópontok is lehetségesek, így
további lehetőségeket biztosítva a hálózat skálázhatóságához és hozzáférhetőségéhez.

Megosztott állapot

A fiók alapú modell a megosztott, módosítható állapotra támaszkodik, amelyről ismert, hogy
bonyolult szemantikához (és finom, millió dolláros hibákhoz) vezet a párhuzamos/
megosztott számítások kontextusában. Az Ergo modellje egy változatlan tranzakciós grafikonra épül. Ez
a megközelítés, amely a Bitcointól származik, jól illeszkedik a blokkláncok párhuzamos és megosztott természetéhez,
és lehetővé teszi a könnyű, bizalmatlan klienseket.

Kifejezőerő

Az Ethereum a blokkláncon egy turing-teljes nyelv végrehajtását szorgalmazta. Elméletileg
korlátlan potenciált ígért, azonban a gyakorlatban súlyos
korlátozások derültek ki a túlzott blokklánc bloat, finom millió dolláros hibák, a gázköltségek, amelyek
korlátozzák a szerződések összetettségét, és más hasonló problémák miatt. Az Ergo ezzel szemben kiterjeszti a UTXO-t, hogy lehetővé tegye
a turing-teljesítményt, miközben korlátozza az ErgoScript nyelv összetettségét. Ugyanazt
kifejezőerőt érjük el egy másik és szemantikailag megalapozottabb módon.

A fent említett összes ponttal világos, hogy sok előnye van az Ergo által használt modellnek.
A cikk további részében bemutatom a FlowCards fogalmát - egy dApp fejlesztői komponenst,
amely lehetővé teszi bonyolult Ergo szerződések tervezését deklaratív és vizuális módon.

Az Imperatívról a Deklaratívra

Az Ethereum imperatív programozási modelljében egy tranzakció egy műveletek sorozata,
amelyet az Ethereum VM hajt végre. Az alábbi Solidity függvény
valósítja meg a tokenek átvitelét a sender-től a receiver-hez. A tranzakció akkor kezdődik,
amikor a sender ezt a függvényt hívja meg egy szerződés példányán, és akkor ér véget, amikor a függvény
visszatér.

// Küld egy meglévő érmét bármely hívótól egy címre
function send(address receiver, uint amount) public {
    require(amount <= balances[msg.sender], "Insufficient balance.");
    balances[msg.sender] -= amount;
    balances[receiver] += amount;
    emit Sent(msg.sender, receiver, amount);
}

A függvény először ellenőrzi az előfeltételeket, majd frissíti a tárolást (azaz az egyensúlyokat), és
végül közzéteszi a posztfeltételt mint Sent eseményt. A tranzakció által felhasznált gáz
jutalomként kerül a bányászhoz a tranzakció végrehajtásáért.

Az Ethereummal ellentétben az Ergo tranzakció egy adatstruktúra, amely egy listát tartalmaz a felhasznált bemeneti érmékről,
valamint egy listát a létrehozott kimeneti érmékről, megőrizve az ERG-k és tokenek összesített egyensúlyát
(amikor az Ergo hasonlít a Bitcoinra).

Visszatérve a fenti példához, mivel az Ergo natívan támogatja a tokeneket, ezért ehhez a
konkrét tokenküldési példához nem kell semmilyen kódot írni ErgoScript-ben. Ehelyett
létre kell hoznunk a 'send' tranzakciót, amelyet a következő ábra mutat, amely ugyanazt a tokenátvitelt
írja le, de deklaratívan.

A kép vizuálisan leírja a következő lépéseket, amelyeket a hálózati felhasználónak
kell végrehajtania:

1. Válassza ki a fel nem használt küldő dobozokat, amelyek összesen tB >= amount tokenet és B >= txFee + minErg ERG-t tartalmaznak.
2. Hozzon létre egy kimeneti target dobozt, amelyet a receiver nyilvános kulcs véd, minErg
   ERG-vel és amount T tokennel.
3. Hozzon létre egy fee kimenetet, amelyet a minerFee szerződés véd, txFee ERG-vel.
4. Hozzon létre egy change kimenetet, amelyet a sender nyilvános kulcs véd, amely tartalmazza
   B - minErg - txFee ERG-t és tB - amount T tokent.
5. Hozzon létre egy új tranzakciót, írja alá a küldő titkos kulcsával, és küldje el az Ergo
   hálózatra.

Ami itt fontos megérteni, hogy mindezeket a lépéseket off-chain hajtják végre (például az Appkit Tranzakció API használatával) a
felhasználó alkalmazása által. Az Ergo hálózati csomópontoknak nem kell megismételniük ezt a tranzakció létrehozási folyamatot,
csak az már létrehozott tranzakció érvényesítésére van szükségük. Az ErgoScript szerződések a tranzakció bemeneteiben tárolódnak,
és ellenőrzik a költési feltételeket. A csomópont a
szerződéseket on-chain hajtja végre, amikor a tranzakció érvényesítve van. A tranzakció érvényes, ha minden
feltétel teljesül.

Így az Ethereumban, amikor "küldünk egy összeget a küldőtől a címzettnek", akkor szó szerint
módosítjuk az egyensúlyokat és frissítjük a tárolást egy konkrét parancssorozattal. Ez történik
on-chain, és így egy új tranzakció is létrejön on-chain ennek a folyamatnak az eredményeként.

Az Ergóban (mint a Bitcoinban) a tranzakciók off-chain jönnek létre, és a hálózati csomópontok csak
ellenőrzik őket. A tranzakció hatásai a blokklánc állapotára az, hogy a bemeneti érmék
(vagy dobozok az Ergo terminológiájában) eltávolításra kerülnek, és a kimeneti dobozok hozzáadódnak a
UTXO halmazhoz.

A fenti példában nem használunk ErgoScript szerződést, hanem feltételezzük, hogy aláírás-ellenőrzést
használunk mint költési előfeltételt. Azonban bonyolultabb alkalmazási forgatókönyvekben természetesen szükség van
ErgoScript használatára, amelyről a következő részben fogunk beszélni.

Állapotváltoztatásról a Kontextus Ellenőrzésére

A send függvény példájában először ellenőriztük az előfeltételt (require(amount <= balances[msg.sender],...)), majd megváltoztattuk az állapotot (azaz frissítettük az egyensúlyokat
balances[msg.sender] -= amount). Ez tipikus az Ethereum tranzakciókban. Mielőtt
bármilyen változást végrehajtanánk, ellenőriznünk kell, hogy érvényes-e ezt megtenni.

Az Ergóban, ahogy korábban megbeszéltük, az állapot (azaz a dobozok UTXO halmaza) implicit módon változik, amikor egy
érvényes tranzakciót egy blokkba illesztenek. Így csak az előfeltételeket kell ellenőriznünk, mielőtt a tranzakciót
hozzá lehet adni a blokkhoz. Ezt teszik az ErgoScript szerződések.

Nem lehetséges az "állapot megváltoztatása" az ErgoScript-ben, mert ez egy nyelv a költési érmék
előfeltételeinek ellenőrzésére. Az ErgoScript egy tisztán funkcionális nyelv mellékhatások nélkül, amely
változatlan adatértékeken működik. Ez azt jelenti, hogy minden bemenet, kimenet és
más tranzakciós paraméter, amely elérhető egy szkriptben, változatlan. Ez, más dolgok mellett,
azt teszi, hogy az ErgoScript egy nagyon egyszerű nyelv, amelyet könnyű megtanulni és biztonságosan használni. Hasonlóan
a Bitcoinhoz, minden bemeneti doboz tartalmaz egy szkriptet, amelynek true értéket kell visszaadnia ahhoz,
hogy 1) lehetővé tegye a doboz költését (azaz eltávolítását az UTXO halmazból) és 2) hozzáadja a
tranzakciót a blokkhoz.

Ha pedánsak vagyunk, ezért helytelen (szigorúan véve) úgy gondolni az ErgoScript-re, mint az
Ergo szerződések nyelvére, mert ez a javaslatok (logikai predikátumok, formulák,
stb.) nyelve, amelyek megvédik a dobozokat az "illegális" költéstől. A Bitcoinhoz képest az Ergóban az egész
tranzakció és a jelenlegi blokklánc kontextusának egy része minden szkript számára elérhető. Ezért
minden szkript ellenőrizheti, hogy mely kimenetek jönnek létre a tranzakció által, azok ERG és token
mennyiségeit (ezt a képességet a példánk DEX szerződéseiben fogjuk használni), a jelenlegi blokk számát
stb.

_ Az ErgoScript-ben meghatározza a feltételeket, hogy a változások (azaz az érmék költése) megengedettek-e
egy adott kontextusban. Ez ellentétben áll a változások imperatív programozásával a szerződés kódjában._

Míg az Ergo tranzakciós modellje egy sor alkalmazást nyit meg (mint például DEX, DeFi
alkalmazások, LETS, stb.), a szerződések tervezése mint előfeltételek az érmék költéséhez (vagy védő
szkriptek) közvetlenül nem intuitív. A következő szakaszokban egy hasznos grafikus
jelölést fogunk figyelembe venni a szerződések deklaratív tervezésére FlowCard Diagramos formában,
mely egy vizuális reprezentációja a végrehajtható komponenseknek (FlowCards).

A FlowCards célja, hogy radikálisan leegyszerűsítse a dApp fejlesztést az Ergo platformon,
magas szintű deklaratív nyelvet, végrehajtási futási időt, tárolási formátumot és
grafikus jelölést biztosítva.

Magas szintű diagramokkal kezdünk, és lemegyünk a FlowCard specifikációra.

FlowCard Diagramos

A FlowCard diagramok mögötti ötlet a következő megfigyeléseken alapul: 1) Egy Ergo doboz
változatlan, és csak abban a tranzakcióban költhető el, amely bemenetként használja. 2) Ezért
rajzolhatunk egy dobozok áramlását a tranzakciókon keresztül, így a tranzakcióba beáramló
dobozok elköltésre kerülnek, míg a kiáramló dobozok létrejönnek és hozzáadódnak az UTXO-hoz. 3) Egy
tranzakció ebből a szempontból egyszerűen a régi dobozok újakká alakítója,
megőrizve az érintett ERG-k és tokenek egyensúlyát.

A következő ábra bemutatja az Ergo tranzakció fő elemeit, amelyeket már korábban láttunk
(most FlowCard Diagram néven).

Minden elemnek szigorúan meghatározott jelentése (szemantika) van a diagram mögött,
hogy a diagram a mögöttes végrehajtható
komponens (FlowCard) vizuális reprezentációja legyen.

A FlowCard felhasználható az Ergo dApp újrafelhasználható komponenseként a
tranzakció létrehozására és kezdeményezésére az Ergo blokkláncon. Ezt a következő szakaszokban fogjuk megvitatni.

Most nézzük meg a FlowCard diagram egyes elemeit egyesével.

1. Név és Paraméterek

Minden flow card-ot nevet és egy típusos paraméterek listáját kap. Ez hasonló egy
paraméterekkel rendelkező sablonhoz. A fenti ábrán láthatjuk a Send flow card-ot, amely öt paraméterrel rendelkezik.
A paraméterek a specifikációban használatosak.

2. Szerződés Tárca

Ez a flow card kulcsfontosságú eleme. Minden doboznak van egy védő szkriptje. Gyakran ez az
szkript ellenőrzi az aláírást egy nyilvános kulccsal szemben. Ez a szkript triviális az ErgoScript-ben,
és a def pk(pubkey: Address) = { pubkey } sablonként van definiálva, ahol pubkey egy Address típusú paraméter. Az ábrán a szkript sablon a
pk(sender) paraméterre van alkalmazva, így egy konkrét tárcaszerződést kapunk. Ezért
pk(sender) és pk(receiver) különböző szkripteket ad, és különböző tárcákat képviselnek
az ábrán, még akkor is, ha ugyanazt a sablont használják.

A Szerződés Tárca tartalmazza az összes UTXO doboz halmazát, amelynek adott szkriptje származik
a megadott szkript sablonból a flow card paraméterek felhasználásával. Például az ábrán a
template pk, és a pubkey paramétert a sender flow card paraméterével helyettesítjük.

3. Szerződés

Bár a szerződés egy doboz tulajdonsága, a diagramon a dobozokat a szerződéseik szerint csoportosítjuk,
így úgy tűnik, hogy a dobozok a szerződésekhez tartoznak, nem pedig a szerződések a dobozokhoz. A példában három példányosított szerződésünk van:
pk(sender), pk(receiver) és minerFee. Ne feledje, hogy a pk(sender) a
pk sablon példányosítása a konkrét sender paraméterrel, és a minerFee a
előre definiált szerződés példányosítása, amely védi a bányász jutalom dobozait.

4. Doboz név

A diagramon minden doboznak adhatunk nevet. A diagram olvashatósága mellett a nevet a
bonyolultabb indexelt hozzáférés szinonimájaként is használjuk a dobozhoz a szerződésben. Például a change
doboz neve, amelyet az ErgoScript
feltételekben is használhatunk a OUTPUTS(2) helyett. A doboz neveket a költési feltételek
kapcsolására is használjuk a dobozokkal.

5. Dobozok a tárcában

A diagramon a dobozokat (sötétebb téglalapok) a szerződés tárcákhoz
(világosabb téglalapok) tartozónak mutatjuk. Minden ilyen doboz téglalap egy szürke tranzakció
teglalappal van összekötve narancssárga vagy zöld nyilakkal,
vagy mindkettővel. Egy kimeneti doboz (beérkező zöld nyíllal) sok szövegsort tartalmazhat, ahol minden
sor egy feltételt határoz meg, amelyet a tranzakció részeként ellenőrizni kell. Az első
sor a dobozba helyezendő ERG mennyiségére vonatkozó feltételt határozza meg. A többi
sor az alábbi formák egyikét vehetik fel:

1. amount: TOKEN - a doboznak tartalmaznia kell a megadott amount mennyiségű adott TOKEN-t.
2. R == value - a doboznak tartalmaznia kell a megadott value-t a megadott R regiszterben.
3. boxName ? condition - a boxName nevű doboznak ellenőriznie kell a condition-t a szkriptjében.

Ezeket a feltételeket az alábbi szakaszokban vitatjuk meg.

6. ERG mennyiség a dobozban

Minden doboznak tárolnia kell egy minimális mennyiségű ERG-t. Ezt akkor ellenőrzik, amikor a létrehozó tranzakciót
érvényesítik. A diagramon az ERG mennyisége mindig az első sorban jelenik meg (pl. B: ERG vagy B - minErg - txFee). Az érték típusú hozzárendelés B: ERG opcionális, és a
olvashatóság érdekében használható. Amikor az érték képletként van megadva, akkor ezt a képletet
be kell tartani a doboz létrehozó tranzakciójának.

Fontos megérteni, hogy az olyan változók, mint amount és txFee, nem a dobozok név szerinti
jellemzői. Ezek a diagram egészének paraméterei, amelyek bizonyos mennyiségeket képviselnek. Vagy más szavakkal, ezek a tranzakciók közötti megosztott paraméterek (pl. A Sell
Order és a Swap tranzakciók a DEX példában megosztják a tAmt paramétert). Tehát
ugyanaz a név ugyanahhoz az értékhez van kötve a diagram egészében (itt a
eszközök sokat segítenének). Azonban, amikor a on-chain érvényesítésre kerül sor, csak a
kifejezett feltételek, amelyeket ? jelöl, kerülnek átalakításra ErgoScript-re. Ugyanakkor az összes többi feltételt off-chain biztosítják a tranzakció építése során (például egy
alkalmazásban, amely az Appkit API-t használja) és a tranzakció érvényesítésekor, amikor az hozzáadódik a
blokklánchoz.

7. T token mennyiség

Egy doboz sok token értéket tárolhat. A diagramon a tokenek elnevezettek, és egy value
változó társítható a T tokenhez a value: T kifejezés használatával. A value megadható
képletként. Ha a képlet egy doboz névével van előtagolva, mint például boxName ? formula,
akkor ezt a boxName doboz védő szkriptjében is ellenőrizni kell. Ez a kiegészítő specifikáció nagyon kényelmes, mert 1) lehetővé teszi a vizuális
tervezés automatikus érvényesítését, és 2) a diagram dobozaiban megadott feltételek elegendőek
ahhoz, hogy szintetizálják a szükséges védő szkripteket. (több erről
alább a "A Diagramból ErgoScript Szerződésekhez")

8. Tx Bemenetek

A bemenetek a megfelelő tranzakcióhoz narancssárga
yilakkal kapcsolódnak. Egy bemeneti nyíl címkéje a következő formák egyikét viselheti:

1. name@index - opcionális név indexszel, azaz fee@0 vagy @2. Ez a nyíl célpontjának tulajdonsága. A név a kapcsolódó dobozok feltételeiben használatos,
   a index pedig a tranzakció INPUTS gyűjteményében a megfelelő doboz helyét jelöli.
2. !action - a nyíl forrásának tulajdonsága, és egy alternatív költési útvonalat ad a doboznak (ezt a DEX példában fogjuk látni).

Az alternatív költési útvonalak miatt egy doboznak sok kimenő narancssárga nyila lehet, amelyek esetében különböző
akciókkal kell címkézni őket.

9. Tranzakció

A tranzakció bemeneti dobozokat költ el és kimeneti dobozokat hoz létre. A bemeneti dobozokat a narancssárga nyilak adják meg,
a címkéknek a megfelelő indexekre kell helyezniük a INPUTS gyűjteményben. A kimeneti dobozokat a zöld nyilak adják meg. Minden tranzakciónak meg kell őriznie az ERG
értékek szigorú egyensúlyát (bemenetek összege == kimenetek összege), és minden token esetében a bemenetek összege >= a kimenetek összege. A tervezési diagram explicit specifikációt igényel az ERG és token
értékek számára az összes kimeneti dobozhoz, hogy elkerülje az implicit hibákat és biztosítsa a jobb olvashatóságot.

10. Tx Kimenetek

A kimenetek a megfelelő tranzakcióhoz zöld
yilakkal kapcsolódnak. Egy kimeneti nyíl címkéje a következő formában lehet: name@index, ahol egy
opcionális név indexszel van kísérve, azaz fee@0 vagy @2. Ez a nyíl forrásának tulajdonsága. A név a kapcsolódó dobozok feltételeiben használatos, és az index a tranzakció OUTPUTS gyűjteményében a megfelelő doboz helyét jelöli.

Példa: Decentralizált Tőzsde (DEX)

Most használjuk a fent leírt jelölést egy FlowCard megtervezésére egy DEX dApp-hoz. Elég egyszerű,
de ugyanakkor illusztrálja a FlowCard diagramok összes kulcsfontosságú jellemzőjét, amelyeket a korábbi szakaszban bemutattunk.

A dApp forgatókönyvét az alábbi ábra mutatja:
Három résztvevő (vásárló,
eladó és DEX) van a DEX dApp-ban, és öt különböző tranzakciótípus, amelyeket a résztvevők hoznak létre. A vásárló ergAmt ERG-t szeretne
kicserélni tAmt TID tokenre (vagy fordítva, az eladó TID tokeneket szeretne eladni ERG-ért, hogy ki küldi el az
először, az nem számít). Mind a vásárló, mind az eladó bármikor törölheti a rendelését. A DEX off-chain
illesztőszolgáltatása megtalálhatja a megfelelő rendeléseket, és létrehozhatja a Swap tranzakciót az
csere befejezéséhez.

A következő diagram teljes mértékben (és formálisan) specifikálja az öt tranzakciót, amelyet off-chain
kell létrehozni a DEX dApp által. Ez is specifikálja az összes költési feltételt, amelyet on-chain
ellenőrizni kell.

Beszéljük meg a FlowCard diagramot és minden tranzakció logikáját részletesen:

Vásárlási Rendelés Tranzakció

A vásárló létrehoz egy Buy Order tranzakciót. A tranzakció E mennyiségű ERG-t költ el
(amit E: ERG-ként fogunk írni) a pk(buyer) tárcából. A tranzakció létrehoz egy bid dobozt ergAmt: ERG
értékkel, amelyet a buyOrder szkript véd. A buyOrder szkript a specifikációból származik (lásd
alább a "A Diagramból ErgoScript Szerződésekhez") manuálisan vagy automatikusan egy
eszköz által. Bár nem szükséges a buyOrder szkriptet kifejezetten definiálni a tervezés során,
a futásidő alatt a bid doboznak tartalmaznia kell a buyOrder szkriptet mint védő javaslatot
(ami ellenőrzi a doboz költési feltételeit), különben a diagramon megadott feltételek nem fognak ellenőrzésre kerülni.

A change doboz létrejön, hogy a tranzakció bemeneti és kimeneti összegei egyensúlyban legyenek.
A tranzakciós díj doboz elhagyható, mert azt a szerszámok automatikusan hozzáadhatják. A gyakorlatban azonban a tervező
kifejezetten hozzáadhatja a díj dobozt a diagramhoz. Ez lefedi a bonyolultabb tranzakciók esetét (mint például a Swap), ahol sokféleképpen lehet
fizetni a tranzakciós díjat.

Vásárlás Törlése, Eladás Törlése Tranzakciók

Bármikor a buyer törölheti a rendelést a CancelBuy tranzakció elküldésével. A
tranzakciónak meg kell felelnie a védő buyOrder szerződésnek, amely védi a bid dobozt.
Ahogy a diagramon látható, mind a Cancel, mind a Swap tranzakciók költhetik a
bid dobozt. Amikor egy doboznak költési alternatívái vannak (vagy spending paths), akkor minden
alternatívát egy egyedi név az ! előtaggal azonosítunk (!cancel és !swap
a bid dobozhoz). Minden alternatív útnak specifikus költési feltételei vannak. A példánkban,
amikor a Cancel Buy tranzakció költi a bid dobozt, a ?buyer feltételnek teljesülnie kell,
amit úgy olvasunk, hogy "a buyer cím aláírásának jelen kell lennie a tranzakcióban". Ezért csak a vásárló
törölheti a vásárlási rendelést. Ez a "szignó" feltétel csak a !cancel alternatív költési úton szükséges,
a !swap-nál nem szükséges.

Eladási Rendelés Tranzakció

Az Sell Order tranzakció hasonló a BuyOrder-hoz, mivel tokenekkel is foglalkozik az ERG-ken kívül.
A tranzakció E: ERG és T: TID tokeneket költ el az eladó tárcájából
(a pk(seller) szerződés szerint). A két kimenet a ask és a change. A change
egy standard doboz a tranzakció egyensúlyának megőrzésére. Az ask doboz tAmt: TID tokeneket tartalmaz az
cserére és minErg: ERG - a dobozokban szükséges minimális ERG mennyiség.

Swap Tranzakció

Ez a kulcsfontosságú tranzakció a DEX dApp forgatókönyvében. A tranzakciónak több költési
feltétele van a bemeneti dobozokon, és ezek a feltételek a buyOrder és
sellOrder szkriptekben szerepelnek (amelyeket ellenőriznek, amikor a tranzakciót hozzáadják a
blokklánchoz). Azonban a diagramon ezek a feltételek nem a bid és
ask dobozokban szerepelnek, hanem a tranzakció kimeneti dobozaiban vannak definiálva.

Ez egy konvenció a jobb használhatóság érdekében, mert a legtöbb feltétel a kimeneti dobozok jellemzőihez kapcsolódik.
Megadhatnánk ezeket a jellemzőket a bid dobozban, de akkor bonyolultabb kifejezéseket kellene használnunk.

Nézzük meg a buyerOut@0 címkével ellátott nyíl által létrehozott kimenetet. Ez a címke azt mondja,
hogy a kimenet az OUTPUTS gyűjtemény 0 indexén található, és hogy a diagramon ezt a dobozt a buyerOut
névvel hivatkozhatjuk. Így mind a dobozt, mind a nyilat címkézhetjük, hogy a doboznak nevet adjunk.

A buyerOut dobozban látható feltételek a bid ? condition formát öltik, ami azt jelenti,
hogy ezeket on-chain kell ellenőrizni ahhoz, hogy a bid dobozt el lehessen költeni.
A feltételek a következő jelentéssel bírnak:

• tAmt: TID megköveteli, hogy a dobozban tAmt mennyiségű TID token legyen.
• R4 == bid.id megköveteli, hogy a R4 regiszter a dobozban egyenlő legyen a bid doboz id-jével.
• script == buyer megköveteli, hogy a buyerOut dobozban a diagramon található tárca szkriptje legyen, azaz pk(buyer).

Hasonló jellemzők kerülnek hozzáadásra a sellerOut dobozhoz, amelynek indexe 1,
és a nevét a doboz címkéje adja meg, nem pedig a nyíl.

A Swap tranzakció a bid és ask dobozokat költi el az !swap költési úton mindkettőn,
de a !cancel-lal ellentétben az úton a feltételek nincsenek megadva. Itt jönnek a
bid ? és ask ? előtagok szerepbe. Ezeket arra használják, hogy a buyerOut és
sellerOut dobozokban felsorolt feltételeket a bid és ask dobozok !swap költési útjára
helyezzük.

Ha megnézi a kimeneti dobozok feltételeit, láthatja, hogy pontosan meghatározzák az értékek cseréjét az eladó
és a vásárló tárcái között. A vásárló megkapja a szükséges mennyiségű TID tokent, és az eladó megkapja a megfelelő mennyiségű ERG-t. A Swap tranzakció
akkor jön létre, amikor két megfelelő doboz van a buyOrder és sellOrder szerződésekkel.

A Diagramból ErgoScript Szerződésekhez

A FlowCard specifikációk érdekessége, hogy felhasználhatók a szükséges ErgoTree szkriptek automatikus generálására.
A megfelelő eszköztámogatással ez automatikusan elvégezhető, de ennek hiányában manuálisan is megtehető. Így a FlowCard lehetővé teszi számunkra, hogy rögzítsük és vizuálisan
ábrázoljuk az Ergo dApp összes tervezési választását és szemantikai részletét.

A következő lépésünk az lesz, hogy mechanikusan létrehozzuk a buyOrder szerződést az
információk alapján, amelyeket a DEX flow card-ban adtunk meg.

Emlékezzünk arra, hogy minden szkript egy javaslat (logikai értékű kifejezés), amelynek true-ra kell értékelődnie,
hogy lehetővé tegye a doboz költését. Amikor sok feltételt kell egyszerre teljesíteni, akkor azokat logikai képletté
kombinálhatjuk az AND bináris művelet használatával, és ha alternatíváink vannak (nem feltétlenül kizárólagosak),
akkor azokat az OR műveletbe helyezhetjük.

A buyOrder doboznak az alternatív költési útvonalai !cancel és !swap. Így az
ErgoScript kódnak OR műveletet kell tartalmaznia két argumentummal - egyet minden költési útra.

/** buyOrder szerződés */
{
  val cancelCondition = {}
  val swapCondition = {}
  cancelCondition || swapCondition
}

A cancelCondition kifejezés képlete a buyOrder doboz !cancel költési útvonalán található. Közvetlenül beilleszthetjük a szkriptbe.

/** buyOrder szerződés */
{
  val cancelCondition = { buyer }
  val swapCondition = {}
  cancelCondition || swapCondition
}

A buyOrder doboz !swap költési útvonalán a feltételek a Swap tranzakció buyerOut kimeneti dobozában vannak megadva. Ha egyszerűen beillesztjük őket a
swapCondition-be, akkor szintaktikailag helytelen szkriptet kapunk.

/** buyOrder szerződés */
{
  val cancelCondition = { buyer }
  val swapCondition = {
    tAmt: TID &&
    R4 == bid.id &&
    @contract
  }
  cancelCondition || swapCondition
}

Azonban lefordíthatjuk a diagram szintaxisát ErgoScript kifejezésekké a következő egyszerű szabályok
használatával:

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

Megjegyzés, hogy a diagramon a TID egy token azonosítót képvisel, de az ErgoScript nem fér hozzá a
tokenekhez az azonosítók alapján, így nem tudjuk írni tokens.getByKey(TID). Ennek
okán, amikor a diagramot ErgoScript-re fordítják, a TID a doboz tokens gyűjteményének indexének névleges állandójává válik. Az állandó konkrét értéke a BuyOrder
tranzakció létrehozásakor a buyOrder dobozzal van hozzárendelve. Az aktuális tokenId, a TID állandó és a buyerOut
doboz tényleges tokenjei közötti megfelelőség és konzisztencia biztosított az off-chain
alkalmazás kódja által, ami teljesen lehetséges, mivel az összes tranzakciót az alkalmazás hozza létre a FlowCard mint
irányadó specifikációval. Ez bonyolultnak tűnhet, de ez a diagram specifikációból a tényleges végrehajtható alkalmazás kódra való fordítás része, amelynek nagy része automatizálható.

A transzformáció után helyes szkriptet kaphatunk, amely ellenőrzi az összes szükséges
előfeltételt a buyOrder doboz költéséhez.

/** buyOrder szerződés */
def DEX(buyer: Addrss, seller: Address, TID: Int, ergAmt: Long, tAmt: Long)
{
  val cancelCondition: SigmaProp = { buyer }      // ellenőrzi a vásárló aláírását (ProveDlog)
  val swapCondition = OUTPUTS.size > 0 && {       // biztosítja az OUTPUTS hozzáférést
    val buyerOut = OUTPUTS(0)                     // a buyerOut@0-ból
    buyerOut.tokens.size > TID && {               // biztosítja a tokenek hozzáférését
      val tid = buyerOut.tokens(TID)
      val regR4 = buyerOut.R4[Coll[Byte]]
      regR4.isDefined && {                        // biztosítja az R4 hozzáférését
        val R4 = regR4.get
        tid._2 == tAmt &&                             // a tAmt: TID-ből 
        R4 == SELF.id &&                              // az R4 == bid.id-ből
        buyerOut.propositionBytes == buyer.propBytes  // a script == buyer-ből
      }
    } 
  }
  cancelCondition || swapCondition
}

Hasonló szkript a sellOrder dobozhoz is létrehozható a fenti fordítási szabályok használatával.
A szerszámok segítségével a szerződések kódja mechanikusan generálható a diagram specifikációjából.

Következtetések

A deklaratív programozási modellek már megnyerték a csatát az imperatív programozás ellen
sok alkalmazási területen, mint például Big Data, Stream Processing, Deep Learning, Adatbázisok,
stb. Az Ergo úttörő szerepet játszik a dApp fejlesztés deklaratív modelljében, mint jobb és biztonságosabb
alternatíva a most népszerű imperatív okos szerződés modellhez képest.

A FlowCard koncepciója a figyelmet az ErgoScript szerződések írásáról az
értékek áramlására helyezi (innen a név), oly módon, hogy az ErgoScript mindig
generálható legyen belőlük. Soha nem kell megnéznie az ErgoScript kódot, amint a szerszámok
rendelkezésre állnak.

Itt vannak a lehetséges következő lépések a jövőbeli munkához:

1. Tárolási formátum a FlowCard Spec és a megfelelő EIP szabványosított fájlformátum
   (Json/XML/Protobuf). Ez lehetővé teszi különböző eszközök (Diagram Szerkesztő, Futási idő, dApp stb.)
   számára, hogy létrehozzanak és használjanak *.flowcard fájlokat.

2. FlowCard Néző, amely generálhatja a diagramokat *.flowcard fájlokból.

3. FlowCard Futási idő, amely képes futtatni *.flowcard fájlokat, tranzakciókat létrehozni és küldeni az Ergo hálózatra.

4. FlowCard Tervező Eszköz, amely egyszerűsítheti a bonyolult diagramok fejlesztését. Ez
   kellemes élménnyé teszi az Ergo szerződések tervezését és érvényesítését, inkább rajzolásra hasonlítva,
   mint kódolásra. Ezenkívül az egész dApp forgatókönyv helyessége ellenőrizhető és kontrollálható az eszközök által.

Hivatkozások

• Ergo
• Ergo Appkit
• Bevezetés az Appkit-be
• Appkit Példák
• ErgoDex ScalaDocs
• ErgoTree Specifikáció