FlowCards: Kerangka Deklaratif untuk Pengembangan dApps Ergo

Dengan terima kasih kepada Robert Kornacki atas penyempurnaan draf.

Pendahuluan

ErgoScript adalah bahasa kontrak pintar yang digunakan
oleh blockchain Ergo. Meskipun memiliki sintaks yang ringkas yang diadopsi dari Scala/Kotlin, ini masih
mungkin tampak membingungkan pada awalnya karena secara konseptual ErgoScript cukup berbeda dibandingkan
bahasa konvensional yang kita semua kenal dan cintai. Ini karena Ergo adalah blockchain berbasis UTXO,
sementara kontrak pintar secara tradisional diasosiasikan dengan sistem berbasis akun
seperti Ethereum. Namun, model transaksi Ergo memiliki banyak keunggulan dibandingkan model berbasis akun
dan dengan pendekatan yang tepat, dapat jauh lebih mudah untuk mengembangkan kontrak Ergo
daripada menulis dan mendebug kode Solidity.

Di bawah ini kita akan membahas aspek-aspek kunci dari model kontrak Ergo yang membuatnya berbeda:

Paradigma

Model akun Ethereum bersifat imperatif. Ini berarti bahwa tugas tipikal mengirim koin dari
Alice ke Bob memerlukan perubahan saldo dalam penyimpanan sebagai serangkaian operasi. Model pemrograman
berbasis UTXO Ergo di sisi lain bersifat deklaratif. Kontrak ErgoScript menentukan kondisi untuk
transaksi diterima oleh blockchain (bukan perubahan yang dilakukan dalam status penyimpanan
sebagai hasil dari eksekusi kontrak).

Skalabilitas

Dalam model akun Ethereum, baik perubahan penyimpanan maupun pemeriksaan validitas dilakukan
di dalam rantai selama eksekusi kode. Sebaliknya, transaksi Ergo dibuat
di luar rantai dan hanya pemeriksaan validasi yang dilakukan di dalam rantai sehingga mengurangi jumlah
operasi yang dilakukan oleh setiap node di jaringan. Selain itu, karena ketidakberubahan dari
graf transaksi, berbagai strategi optimisasi mungkin dilakukan untuk meningkatkan throughput
transaksi per detik di jaringan. Node verifikasi ringan juga mungkin ada sehingga
lebih memfasilitasi skalabilitas dan aksesibilitas jaringan.

Status Bersama

Model berbasis akun bergantung pada status yang dapat diubah bersama yang diketahui dapat menyebabkan
semantik yang kompleks (dan bug halus senilai jutaan dolar) dalam konteks komputasi yang bersamaan/ erdistribusi. Model Ergo didasarkan pada graf transaksi yang tidak dapat diubah. Pendekatan ini,
yang diwarisi dari Bitcoin, berfungsi dengan baik dengan sifat bersamaan dan terdistribusi dari
blockchain dan memfasilitasi klien tanpa kepercayaan yang ringan.

Daya Ekspresif

Ethereum menganjurkan eksekusi bahasa yang lengkap Turing di blockchain. Ini
secara teoritis menjanjikan potensi tak terbatas, namun dalam praktiknya muncul
batasan yang parah dari pembengkakan blockchain yang berlebihan, bug halus senilai jutaan dolar, biaya gas yang
membatasi kompleksitas kontrak, dan masalah lainnya. Di sisi lain, Ergo memperluas UTXO untuk memungkinkan
kecukupan Turing sambil membatasi kompleksitas bahasa ErgoScript itu sendiri. Daya ekspresif yang sama
dicapai dengan cara yang berbeda dan lebih semantik.

Dengan semua poin di atas, seharusnya jelas bahwa ada banyak manfaat dari model yang digunakan Ergo.
Dalam sisa artikel ini, saya akan memperkenalkan Anda pada konsep FlowCards - komponen pengembang dApp
yang memungkinkan perancangan kontrak Ergo yang kompleks dengan cara deklaratif dan visual.

Dari Imperatif ke Deklaratif

Dalam model pemrograman imperatif Ethereum, transaksi adalah urutan operasi
yang dieksekusi oleh Ethereum VM. Fungsi Solidity berikut
melaksanakan transfer token dari pengirim ke penerima. Transaksi dimulai ketika
pengirim memanggil fungsi ini pada instance kontrak dan berakhir ketika fungsi
mengembalikan.

// Mengirim sejumlah koin yang ada dari pemanggil mana pun ke alamat
function send(address receiver, uint amount) public {
    require(amount <= balances[msg.sender], "Saldo tidak cukup.");
    balances[msg.sender] -= amount;
    balances[receiver] += amount;
    emit Sent(msg.sender, receiver, amount);
}

Fungsi pertama-tama memeriksa prasyarat, kemudian memperbarui penyimpanan (yaitu saldo) dan
akhirnya menerbitkan pasca-kondisi sebagai acara Sent. Gas yang dikonsumsi oleh
transaksi dikirim ke penambang sebagai imbalan untuk mengeksekusi transaksi ini.

Berbeda dengan Ethereum, transaksi di Ergo adalah struktur data yang memegang daftar koin input
yang dibelanjakan dan daftar koin output yang dibuatnya, menjaga total saldo
ERG dan token (di mana Ergo mirip dengan Bitcoin).

Kembali ke contoh di atas, karena Ergo secara native mendukung token, maka untuk contoh
spesifik ini dari pengiriman token kita tidak perlu menulis kode apa pun dalam ErgoScript. Sebagai gantinya,
kita perlu membuat transaksi 'send' yang ditunjukkan dalam gambar berikut, yang menggambarkan
transfer token yang sama tetapi secara deklaratif.

Gambar tersebut secara visual menggambarkan langkah-langkah berikut, yang perlu dilakukan oleh pengguna jaringan:

1. Pilih kotak pengirim yang tidak terpakai, yang mengandung total tB >= jumlah token dan B >= txFee + minErg ERG.
2. Buat kotak output target yang dilindungi oleh kunci publik penerima dengan minErg
   ERG dan jumlah token T.
3. Buat satu output fee yang dilindungi oleh kontrak minerFee dengan txFee ERG.
4. Buat satu output change yang dilindungi oleh kunci publik pengirim, yang berisi
   B - minErg - txFee ERG dan tB - jumlah token T.
5. Buat transaksi baru, tandatangani menggunakan kunci rahasia pengirim dan kirim ke jaringan Ergo.

Yang penting untuk dipahami di sini adalah bahwa semua langkah ini dilakukan di luar rantai (misalnya menggunakan Appkit Transaction API) oleh aplikasi
pengguna. Node jaringan Ergo tidak perlu mengulangi proses pembuatan transaksi ini,
mereka hanya perlu memvalidasi transaksi yang sudah terbentuk. Kontrak ErgoScript disimpan di
input transaksi dan memeriksa kondisi pengeluaran. Node mengeksekusi
kontrak di dalam rantai ketika transaksi divalidasi. Transaksi dianggap valid jika semua
kondisi terpenuhi.

Dengan demikian, di Ethereum ketika kita "mengirim jumlah dari pengirim ke penerima" kita secara harfiah
mengedit saldo dan memperbarui penyimpanan dengan serangkaian perintah konkret. Ini terjadi
di dalam rantai dan dengan demikian transaksi baru juga dibuat di dalam rantai sebagai hasil dari proses ini.

Di Ergo (seperti di Bitcoin) transaksi dibuat di luar rantai dan node jaringan hanya
memverifikasinya. Efek dari transaksi pada status blockchain adalah bahwa koin input
(atau Kotak dalam istilah Ergo) dihapus dan kotak output ditambahkan ke
UTXO set.

Dalam contoh di atas kita tidak menggunakan kontrak ErgoScript tetapi sebaliknya mengasumsikan pemeriksaan tanda tangan digunakan sebagai prasyarat pengeluaran. Namun dalam skenario aplikasi yang lebih kompleks kita tentu perlu
menggunakan ErgoScript yang akan kita bahas selanjutnya.

Dari Mengubah Status ke Memeriksa Konteks

Dalam contoh fungsi send, kita pertama-tama memeriksa prasyarat (require(amount <= balances[msg.sender],...)) dan kemudian mengubah status (yaitu memperbarui saldo
balances[msg.sender] -= amount). Ini adalah hal yang khas dalam transaksi Ethereum. Sebelum
kita mengubah apa pun, kita perlu memeriksa apakah itu valid untuk melakukannya.

Di Ergo, seperti yang telah kita bahas sebelumnya, status (yaitu set UTXO dari kotak) diubah secara implisit ketika transaksi
valid dimasukkan ke dalam blok. Jadi kita hanya perlu memeriksa prasyarat sebelum
transaksi dapat ditambahkan ke blok. Inilah yang dilakukan kontrak ErgoScript.

Tidak mungkin untuk "mengubah status" dalam ErgoScript karena ini adalah bahasa untuk memeriksa
prasyarat untuk pengeluaran koin. ErgoScript adalah bahasa fungsional murni tanpa efek samping yang beroperasi pada nilai data yang tidak dapat diubah. Ini berarti semua input, output, dan
parameter transaksi lainnya yang tersedia dalam skrip adalah tidak dapat diubah. Ini, di antara hal-hal lain,
membuat ErgoScript menjadi bahasa yang sangat sederhana yang mudah dipelajari dan aman untuk digunakan. Mirip dengan
Bitcoin, setiap kotak input berisi skrip, yang harus mengembalikan nilai true untuk 1) mengizinkan pengeluaran kotak (yaitu menghapus dari set UTXO) dan 2) menambahkan
transaksi ke blok.

Jika kita bersikeras, maka adalah tidak benar (secara ketat) untuk menganggap ErgoScript sebagai bahasa dari
kontrak Ergo, karena ini adalah bahasa proposisi (predikat logis, rumus,
etc.) yang melindungi kotak dari pengeluaran "ilegal". Berbeda dengan Bitcoin, di Ergo seluruh
transaksi dan sebagian konteks blockchain saat ini tersedia untuk setiap skrip. Oleh karena itu,
setiap skrip dapat memeriksa output mana yang dibuat oleh transaksi, jumlah ERG dan token
mereka (kita akan menggunakan kemampuan ini dalam kontrak DEX contoh kita), nomor blok saat ini
dll.

Dalam ErgoScript Anda mendefinisikan kondisi apakah perubahan (yaitu pengeluaran koin) diizinkan
terjadi dalam konteks tertentu. Ini berbeda dengan memprogram perubahan
secara imperatif dalam kode kontrak.

Sementara model transaksi Ergo membuka seluruh rangkaian aplikasi seperti (DEX, DeFi
Apps, LETS, dll), merancang kontrak sebagai prasyarat untuk pengeluaran koin (atau skrip penjaga)
dari langsung tidak intuitif. Di bagian berikutnya kita akan mempertimbangkan notasi grafis yang berguna
untuk merancang kontrak secara deklaratif menggunakan Diagram FlowCard, yang merupakan representasi visual
komponen yang dapat dieksekusi (FlowCards).

FlowCards bertujuan untuk secara radikal menyederhanakan pengembangan dApp di platform Ergo dengan
menyediakan bahasa deklaratif tingkat tinggi, runtime eksekusi, format penyimpanan dan
otasi grafis.

Kita akan mulai dengan diagram tingkat tinggi dan turun ke spesifikasi FlowCard.

Diagram FlowCard

Ide di balik diagram FlowCard didasarkan pada pengamatan berikut: 1) Sebuah kotak Ergo
adalah tidak dapat diubah dan hanya dapat dibelanjakan dalam transaksi yang menggunakannya sebagai input. 2) Kita
karena itu dapat menggambar aliran kotak melalui transaksi, sehingga kotak mengalir ke dalam
transaksi dibelanjakan dan yang mengalir keluar dibuat dan ditambahkan ke UTXO. 3) Sebuah
transaksi dari perspektif ini hanyalah pengubah kotak lama menjadi yang baru
menjaga saldo ERG dan token yang terlibat.

Gambar berikut menunjukkan elemen utama dari transaksi Ergo yang telah kita lihat
sebelumnya (sekarang dengan nama Diagram FlowCard).

Ada makna yang ditentukan secara ketat (semantik) di balik setiap elemen diagram,
sehingga diagram adalah representasi visual (atau tampilan) dari komponen yang dapat dieksekusi
yang mendasarinya (disebut FlowCard).

FlowCard dapat digunakan sebagai komponen yang dapat digunakan kembali dari dApp Ergo untuk membuat dan memulai
transaksi di blockchain Ergo. Kita akan membahas ini di bagian yang akan datang.

Sekarang mari kita lihat bagian-bagian individu dari diagram FlowCard satu per satu.

1. Nama dan Parameter

Setiap kartu aliran diberi nama dan daftar parameter bertipe. Ini mirip dengan
template dengan parameter. Dalam gambar di atas kita dapat melihat kartu aliran Send yang memiliki lima parameter.
Parameter digunakan dalam spesifikasi.

2. Dompet Kontrak

Ini adalah elemen kunci dari kartu aliran. Setiap kotak memiliki skrip penjaga. Seringkali ini adalah
skrip yang memeriksa tanda tangan terhadap kunci publik. Skrip ini sepele dalam ErgoScript
dan didefinisikan seperti template def pk(pubkey: Address) = { pubkey } di mana pubkey adalah
parameter dari tipe Address. Dalam gambar, template skrip diterapkan pada
parameter pk(sender) dan dengan demikian kontrak dompet konkret diperoleh. Oleh karena itu
pk(sender) dan pk(receiver) menghasilkan skrip yang berbeda dan mewakili berbeda dompet
pada diagram, meskipun mereka menggunakan template yang sama.

Dompet Kontrak berisi sekumpulan semua kotak UTXO yang memiliki skrip tertentu yang diturunkan dari
template skrip tertentu menggunakan parameter kartu aliran. Misalnya, dalam gambar, template adalah pk
dan parameter pubkey digantikan dengan parameter kartu aliran sender.

3. Kontrak

Meskipun kontrak adalah properti dari sebuah kotak, pada diagram kita mengelompokkan kotak-kotak berdasarkan
kontrak mereka, oleh karena itu terlihat seolah-olah kotak-kotak tersebut milik kontrak, bukan kontrak
milik kotak-kotak tersebut. Dalam contoh, kita memiliki tiga kontrak yang diinstansiasi
pk(sender), pk(receiver) dan minerFee. Perhatikan, bahwa pk(sender) adalah instansiasi dari
template pk dengan parameter konkret sender dan minerFee adalah instansiasi dari
kontrak yang telah ditentukan sebelumnya yang melindungi kotak imbalan penambang.

4. Nama Kotak

Dalam diagram kita dapat memberi setiap kotak nama. Selain keterbacaan diagram, kita juga menggunakan
nama sebagai sinonim dari akses terindeks yang lebih kompleks ke kotak dalam kontrak. Sebagai
contoh, change adalah nama kotak, yang juga dapat digunakan dalam kondisi ErgoScript
sebagai pengganti OUTPUTS(2). Kita juga menggunakan nama kotak untuk mengaitkan kondisi pengeluaran
dengan kotak-kotak tersebut.

5. Kotak dalam dompet

Dalam diagram, kita menunjukkan kotak (persegi panjang yang lebih gelap) sebagai milik dompet kontrak
(persegi panjang yang lebih terang). Setiap kotak persegi panjang tersebut terhubung dengan kotak transaksi
abu-abu dengan panah oranye atau hijau
atau keduanya. Kotak output (dengan panah hijau yang masuk) dapat mencakup banyak baris teks di mana setiap
baris menentukan kondisi yang harus diperiksa sebagai bagian dari transaksi. Baris pertama
menentukan kondisi pada jumlah ERG yang harus ditempatkan di kotak. Baris lainnya dapat mengambil salah satu dari bentuk berikut:

1. amount: TOKEN - kotak harus berisi amount yang diberikan dari TOKEN yang diberikan
2. R == value - kotak harus berisi value yang diberikan dari register R yang diberikan
3. boxName ? condition - kotak bernama boxName harus memeriksa condition dalam skripnya.

Kita akan membahas kondisi-kondisi ini di bagian-bagian di bawah.

6. Jumlah ERG dalam kotak

Setiap kotak harus menyimpan jumlah minimum ERG. Ini diperiksa ketika transaksi yang dibuat divalidasi. Dalam diagram, jumlah ERG selalu ditunjukkan sebagai baris pertama (misalnya B: ERG atau B - minErg - txFee). Tipe nilai askripsi B: ERG adalah opsional dan dapat
Digunakan untuk keterbacaan. Ketika nilai diberikan sebagai rumus, maka rumus ini harus dihormati oleh transaksi yang membuat kotak.

Penting untuk dipahami bahwa variabel seperti amount dan txFee bukanlah
properti bernama dari kotak-kotak tersebut. Mereka adalah parameter dari seluruh diagram dan mewakili beberapa
jumlah. Atau dengan kata lain, mereka adalah parameter bersama antara transaksi (misalnya, Pesanan Jual
dan transaksi Swap dari contoh DEX di bawah berbagi parameter tAmt). Jadi
nama yang sama terikat pada nilai yang sama di seluruh diagram (di sinilah
alat bantu akan sangat membantu). Namun, ketika datang ke validasi di dalam rantai dari nilai-nilai tersebut,
hanya kondisi eksplisit yang ditandai dengan ? yang diubah menjadi ErgoScript. Pada saat yang sama, semua kondisi lainnya dipastikan di luar rantai selama pembangunan transaksi (misalnya dalam aplikasi yang menggunakan API Appkit) dan validasi transaksi ketika ditambahkan ke
blockchain.

7. Jumlah token T

Sebuah kotak dapat menyimpan nilai dari banyak token. Token dalam diagram diberi nama dan variabel value
dapat dikaitkan dengan token T menggunakan ekspresi value: T. Nilai value dapat
berikan dengan rumus. Jika rumus diawali dengan nama kotak seperti boxName ? formula,
maka juga harus diperiksa dalam skrip penjaga dari kotak boxName. Spesifikasi tambahan ini sangat nyaman karena 1) memungkinkan untuk memvalidasi desain visual secara otomatis, dan 2) kondisi yang ditentukan dalam kotak diagram sudah cukup
untuk mensintesis skrip penjaga yang diperlukan. (lebih lanjut tentang ini
di bawah pada "Dari Diagram ke Kontrak ErgoScript")

8. Input Tx

Input terhubung ke transaksi yang sesuai dengan panah oranye. Sebuah panah input dapat memiliki label dalam bentuk berikut:

1. name@index - nama opsional dengan indeks yaitu fee@0 atau @2. Ini adalah properti dari
   endpoint target panah. Nama digunakan dalam kondisi kotak terkait
   dan index adalah posisi kotak yang sesuai dalam koleksi INPUTS dari
   transaksi.
2. !action - adalah properti dari sumber panah dan memberikan nama untuk jalur pengeluaran alternatif dari kotak (kita akan melihat ini dalam contoh DEX)

Karena jalur pengeluaran alternatif, sebuah kotak dapat memiliki banyak panah keluar oranye, dalam hal ini mereka harus diberi label dengan tindakan yang berbeda.

9. Transaksi

Sebuah transaksi membelanjakan kotak input dan membuat kotak output. Kotak input diberikan oleh
panah oranye dan label diharapkan untuk menempatkan input pada
indeks yang benar dalam koleksi INPUTS. Kotak output diberikan oleh panah hijau. Setiap transaksi harus menjaga keseimbangan ketat dari nilai ERG
(jumlah input == jumlah output) dan untuk setiap token jumlah input >= jumlah
output. Diagram desain memerlukan spesifikasi eksplisit dari nilai ERG dan token
untuk semua kotak output untuk menghindari kesalahan implisit dan memastikan keterbacaan yang lebih baik.

10. Output Tx

Output terhubung ke transaksi yang sesuai dengan panah hijau. Sebuah panah output dapat memiliki label dalam bentuk name@index, di mana nama opsional disertai dengan indeks yaitu fee@0 atau @2. Ini adalah properti dari
endpoint sumber panah. Nama digunakan dalam kondisi kotak terkait dan index adalah posisi kotak yang sesuai dalam koleksi OUTPUTS dari transaksi.

Contoh: Pertukaran Terdesentralisasi (DEX)

Sekarang mari kita gunakan notasi yang dijelaskan di atas untuk merancang FlowCard untuk dApp DEX. Ini cukup sederhana
namun juga menggambarkan semua fitur kunci dari diagram FlowCard
yang telah kita perkenalkan di bagian sebelumnya.

Skenario dApp ditunjukkan dalam gambar di bawah:
Ada tiga peserta (pembeli,
penjual dan DEX) dari dApp DEX dan lima jenis transaksi berbeda, yang dibuat oleh
peserta. Pembeli ingin menukar ergAmt ERG untuk tAmt token TID (atau sebaliknya, penjual ingin menjual token TID untuk ERG, siapa yang mengirim pesanan terlebih dahulu tidak
penting). Baik pembeli maupun penjual dapat membatalkan pesanan mereka kapan saja. Layanan pencocokan off-chain DEX
dapat menemukan pesanan yang cocok dan membuat transaksi Swap untuk
menyelesaikan pertukaran.

Diagram berikut sepenuhnya (dan secara formal) menentukan semua lima transaksi yang harus
dibuat di luar rantai oleh dApp DEX. Ini juga menentukan semua kondisi pengeluaran yang
harus diverifikasi di dalam rantai.

Mari kita bahas diagram FlowCard dan logika setiap transaksi secara rinci:

Transaksi Pesanan Beli

Seorang pembeli membuat transaksi Buy Order. Transaksi membelanjakan E jumlah ERG
(yang akan kita tulis E: ERG) dari satu atau lebih kotak di dompet pk(buyer). Transaksi ini membuat kotak bid dengan ergAmt: ERG yang dilindungi oleh skrip buyOrder. Skrip buyOrder disintesis dari spesifikasi (lihat
di bawah pada "Dari Diagram ke Kontrak ErgoScript") baik secara manual atau otomatis oleh alat. Meskipun kita tidak perlu mendefinisikan skrip buyOrder secara eksplisit selama
desain, pada waktu eksekusi kotak bid harus berisi skrip buyOrder sebagai proposisi penjaga (yang memeriksa kondisi pengeluaran kotak), jika tidak, kondisi
yang ditentukan dalam diagram tidak akan diperiksa.

Kotak change dibuat untuk menyeimbangkan jumlah input dan output dari transaksi.
Kotak biaya transaksi dihilangkan karena dapat ditambahkan secara otomatis oleh alat. Dalam
praktik, bagaimanapun, perancang dapat menambahkan kotak biaya secara eksplisit ke diagram. Ini mencakup
kasus transaksi yang lebih kompleks (seperti Swap) di mana ada banyak cara untuk membayar
biaya transaksi.

Transaksi Batalkan Beli, Batalkan Jual

Kapan saja, pembeli dapat membatalkan pesanan dengan mengirim transaksi CancelBuy. Transaksi ini harus memenuhi kontrak penjaga buyOrder yang melindungi kotak bid.
Seperti yang Anda lihat pada diagram, baik transaksi Cancel dan Swap dapat membelanjakan
kotak bid. Ketika sebuah kotak memiliki alternatif pengeluaran (atau jalur pengeluaran) maka setiap
alternatif diidentifikasi dengan nama unik yang diawali dengan ! (!cancel dan !swap
untuk kotak bid). Setiap jalur alternatif memiliki kondisi pengeluaran tertentu. Dalam contoh kita,
ketika transaksi Cancel Buy membelanjakan kotak bid, kondisi ?buyer harus dipenuhi, yang kita baca sebagai "tanda tangan untuk alamat buyer harus disajikan dalam
transaksi". Oleh karena itu, hanya pembeli yang dapat membatalkan pesanan beli. Kondisi "tanda tangan" ini
hanya diperlukan untuk jalur pengeluaran alternatif !cancel dan tidak diperlukan untuk !swap.

Transaksi Pesanan Jual

Transaksi Sell Order mirip dengan BuyOrder dalam hal berurusan dengan token selain ERG. Transaksi ini membelanjakan E: ERG dan T: TID token dari dompet penjual
(yang ditentukan sebagai kontrak pk(seller)). Dua output adalah ask dan change. Perubahan
adalah kotak standar untuk menyeimbangkan transaksi. Kotak ask menyimpan token tAmt: TID untuk pertukaran
dan minErg: ERG - jumlah minimum ERG yang diperlukan di setiap kotak.

Transaksi Swap

Ini adalah transaksi kunci dalam skenario dApp DEX. Transaksi ini memiliki beberapa kondisi pengeluaran
pada kotak input dan kondisi tersebut termasuk dalam skrip buyOrder dan
sellOrder (yang diverifikasi ketika transaksi ditambahkan ke
blockchain). Namun, pada diagram kondisi tersebut tidak ditentukan dalam kotak bid dan
ask, melainkan didefinisikan dalam kotak output dari transaksi.

Ini adalah konvensi untuk meningkatkan kegunaan karena sebagian besar kondisi terkait dengan properti dari
kotak output. Kita bisa menentukan properti tersebut dalam kotak bid, tetapi kemudian kita harus
menggunakan ekspresi yang lebih kompleks.

Mari kita pertimbangkan output yang dibuat oleh panah yang diberi label buyerOut@0. Label ini memberi
tahu kita bahwa output berada di indeks 0 dalam koleksi OUTPUTS dari transaksi dan
bahwa dalam diagram kita dapat merujuk kotak ini dengan nama buyerOut. Dengan demikian kita dapat memberi label
baik kotak itu sendiri maupun panah untuk memberi kotak nama.

Kondisi yang ditunjukkan dalam kotak buyerOut memiliki bentuk bid ? condition, yang berarti
mereka harus diverifikasi di dalam rantai untuk membelanjakan kotak bid.
Kondisi tersebut memiliki arti sebagai berikut:

• tAmt: TID mengharuskan kotak memiliki jumlah tAmt dari token TID
• R4 == bid.id mengharuskan register R4 dalam kotak sama dengan id dari kotak bid.
• script == buyer mengharuskan kotak buyerOut memiliki skrip dompet di mana ia
  berada di diagram, yaitu pk(buyer)

Properti serupa ditambahkan ke kotak sellerOut, yang ditentukan berada di indeks 1
dan nama diberikan padanya menggunakan label pada kotak itu sendiri, bukan pada panah.

Transaksi Swap membelanjakan dua kotak bid dan ask menggunakan jalur pengeluaran !swap pada keduanya,
namun berbeda dengan !cancel, kondisi pada jalur tersebut tidak ditentukan. Di sinilah
awalan bid ? dan ask ? berperan. Mereka digunakan sehingga kondisi yang terdaftar dalam kotak buyerOut dan
sellerOut dipindahkan ke jalur pengeluaran !swap dari kotak bid dan ask masing-masing.

Jika Anda melihat kondisi dari kotak output, Anda akan melihat bahwa mereka secara tepat menentukan
pertukaran nilai antara dompet penjual dan pembeli. Pembeli mendapatkan jumlah yang diperlukan
dari token TID dan penjual mendapatkan jumlah ERG yang sesuai. Transaksi Swap
dibuat ketika ada dua kotak yang cocok dengan kontrak buyOrder dan sellOrder.

Dari Diagram ke Kontrak ErgoScript

Apa yang menarik tentang spesifikasi FlowCard adalah bahwa kita dapat menggunakannya untuk secara otomatis
generasi skrip ErgoTree yang diperlukan.
Dengan dukungan alat yang sesuai, ini dapat dilakukan secara otomatis, tetapi dengan kurangnya
dukungan tersebut, dapat dilakukan secara manual. Dengan demikian, FlowCard memungkinkan kita untuk menangkap dan secara visual
mewakili semua pilihan desain dan detail semantik dari dApp Ergo.

Apa yang akan kita lakukan selanjutnya adalah secara mekanis membuat kontrak buyOrder dari
informasi yang diberikan dalam kartu aliran DEX.

Ingat bahwa setiap skrip adalah proposisi (ekspresi bernilai boolean) yang harus dievaluasi
menjadi true untuk mengizinkan pengeluaran kotak. Ketika kita memiliki banyak kondisi yang harus dipenuhi pada saat yang sama,
kita dapat menggabungkannya dalam rumus logis menggunakan operasi biner AND, dan jika kita memiliki
alternatif (tidak harus eksklusif) kita dapat menempatkannya dalam operasi OR.

Kotak buyOrder memiliki jalur pengeluaran alternatif !cancel dan !swap. Oleh karena itu,
kode ErgoScript harus memiliki operasi OR dengan dua argumen - satu untuk setiap jalur pengeluaran.

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

Rumus untuk ekspresi cancelCondition diberikan dalam jalur pengeluaran !cancel
dari kotak buyOrder. Kita dapat langsung menyertakannya dalam skrip.

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

Untuk jalur pengeluaran !swap dari kotak buyOrder, kondisi ditentukan dalam
kotak output buyerOut dari transaksi Swap. Jika kita cukup menyertakannya dalam
swapCondition, maka kita mendapatkan skrip yang tidak sintaksis benar.

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

Namun, kita dapat menerjemahkan kondisi dari sintaks diagram ke ekspresi ErgoScript
menggunakan aturan sederhana berikut

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

Perhatikan, dalam diagram TID mewakili id token, tetapi ErgoScript tidak memiliki akses ke
token berdasarkan id sehingga kita tidak dapat menulis tokens.getByKey(TID). Untuk alasan ini, ketika
diagram diterjemahkan menjadi ErgoScript, TID menjadi konstanta bernama dari indeks dalam
koleksi tokens dari kotak. Nilai konkret dari konstanta ditetapkan ketika transaksi
BuyOrder dengan kotak buyOrder dibuat. Kesesuaian dan konsistensi antara tokenId aktual, konstanta TID dan token aktual dari
kotak buyerOut dijamin oleh kode aplikasi di luar rantai, yang sepenuhnya
mungkin karena semua transaksi dibuat oleh aplikasi menggunakan FlowCard sebagai
spesifikasi panduan. Ini mungkin terdengar terlalu rumit, tetapi ini adalah bagian dari terjemahan
dari spesifikasi diagram ke kode aplikasi yang dapat dieksekusi yang sebenarnya, sebagian besar dari
ini dapat diotomatisasi.

Setelah transformasi, kita dapat memperoleh skrip yang benar yang memeriksa semua prasyarat
yang diperlukan untuk pengeluaran kotak buyOrder.

/** kontrak buyOrder */
def DEX(buyer: Addrss, seller: Address, TID: Int, ergAmt: Long, tAmt: Long)
{
  val cancelCondition: SigmaProp = { buyer }      // verifikasi tanda tangan pembeli (ProveDlog)
  val swapCondition = OUTPUTS.size > 0 && {       // mengamankan akses OUTPUTS
    val buyerOut = OUTPUTS(0)                     // dari buyerOut@0
    buyerOut.tokens.size > TID && {               // mengamankan akses token
      val tid = buyerOut.tokens(TID)
      val regR4 = buyerOut.R4[Coll[Byte]]
      regR4.isDefined && {                        // mengamankan akses R4
        val R4 = regR4.get
        tid._2 == tAmt &&                             // dari tAmt: TID 
        R4 == SELF.id &&                              // dari R4 == bid.id
        buyerOut.propositionBytes == buyer.propBytes  // dari script == buyer
      }
    } 
  }
  cancelCondition || swapCondition
}

Skrip serupa untuk kotak sellOrder dapat diperoleh menggunakan aturan terjemahan yang sama.
Dengan bantuan alat, kode kontrak dapat dihasilkan secara mekanis dari spesifikasi diagram.

Kesimpulan

Model pemrograman deklaratif telah memenangkan pertempuran melawan pemrograman imperatif
di banyak domain aplikasi seperti Big Data, Pemrosesan Aliran, Pembelajaran Mendalam, Basis Data,
dll. Ergo mempelopori model deklaratif pengembangan dApp sebagai alternatif yang lebih baik dan lebih aman
dari model imperatif kontrak pintar yang kini populer.

Konsep FlowCard mengalihkan fokus dari menulis kontrak ErgoScript ke
aliran nilai secara keseluruhan (dari sinilah namanya), sedemikian rupa, bahwa ErgoScript dapat selalu
dihasilkan dari mereka. Anda tidak akan pernah perlu melihat kode ErgoScript setelah alat bantu
tersedia.

Berikut adalah langkah-langkah selanjutnya yang mungkin untuk pekerjaan di masa depan:

1. Format penyimpanan untuk Spesifikasi FlowCard dan format file standar EIP yang sesuai
   (Json/XML/Protobuf). Ini akan memungkinkan berbagai alat (Editor Diagram, Runtime, dApps dll)
   untuk membuat dan menggunakan file *.flowcard.

2. Penampil FlowCard, yang dapat menghasilkan diagram dari file *.flowcard.

3. Runtime FlowCard, yang dapat menjalankan file *.flowcard, membuat dan mengirim transaksi ke jaringan Ergo.

4. Alat Desainer FlowCard, yang dapat menyederhanakan pengembangan diagram yang kompleks. Ini akan
   membuat perancangan dan validasi kontrak Ergo menjadi pengalaman yang menyenangkan, lebih mirip menggambar
   daripada pengkodean. Selain itu, kebenaran seluruh skenario dApp dapat
   verifikasi dan dikendalikan oleh alat bantu.

Referensi

• Ergo
• Ergo Appkit
• Pengenalan ke Appkit
• Contoh Appkit
• ErgoDex ScalaDocs
• Spesifikasi ErgoTree