Dipublikasikan pada tanggal 19 Jan 2022
Disadur oleh andre cahyadi (@prosperaan)
Untuk komunitas Cardano Indonesia
Referensi:
(Merging formal methods and agile development to build Cardano - IOHK Blog)
Standard di dunia startup ketika membuat sebuah produk adalah membuat Minimum Viable Product (MVP) terlebih dahulu untuk kemudian dilakukan iterasi secara terus menerus sampai produk tersebut diterima oleh pasar. Konsep ini dikenal sebagai proses Agile .
Namun di dalam proses Agile, diharapkan adanya bug dan kelemahan dalam setiap iterasi yang dapat terus menerus diperbaiki. Hal ini baik – baik saja jika tidak ada ‘value’ yang dipertaruhkan, namun tidak untuk asset digital seperti Cardano dimana jumlah uang dan kepercayaan milik para stakeholders dipertaruhkan.
Membangun sebuah aset digital memiliki beberapa tantangan tersendiri ketika mengatur fase pengembangannya. Sebagai Proof Of Stake (PoS) cryptocurrency, sistem Cardano terdistribusi melalui node – node server yang ada di jaringan. Ketika ingin diterapkan sebuah perubahan, harus diperhatikan betul bahwa perubahan tersebut tidak akan membuat celah yang dapat diserang oleh aktor jahat. Oleh karena itu, seharusnya tidak ada seorang pun yang dapat berkata ‘build quickly and deal with problems later’. Terlebih, ‘trust’ adalah hal mandatori dari sebuah currency agar dapat diterima penggunaannya, yang dibuktikan dengan kebenaran sistemnya.
Code di dalam sistem cryptocurrency bukan saja harus benar, melainkan juga harus dapat dibuktikan melalui test secara menyeluruh dengan bukti matematis. Ketika ada fitur - fitur baru yang ingin ditambahkan, Tim IOHK harus mampu menjaga kebenaran sistem yang sudah ada di versi sebelumnya . Inilah mengapa para developer di dalam tim meringkas metodologi yang digunakan, menggabungkan berbagai tool mulai dari property-based testing hingga machine verifiable proof dengan tujuan untuk menjamin kualitas sistem bahkan ketika ada persyaratan perubahan.
Dari Riset hingga ke Code
Metodologi pengembangan Cardano dimulai dari riset. Sampai saat ini, Tim IOHK telah mempublikasi lebih dari 60 jurnal riset yang telah berkontribusi dalam pembuatan sistem Cardano. Setiap jurnal meneliti aspek kritikal blockchain dari prinsip yang paling mendasar seperti, Bagaimana kita memperoleh konsensus secara terdesentralisasi? Bagaimana cara mendesain smart contract? Struktur rewards seperti apa yang tepat untuk memberikan insentif kepada para pelaku good behavior? Para periset di Tim IOHK menganalisa pertanyaan ini dan mempublikasikan hasil riset mereka ke jurnal scientific dan conferences. Jurnal – jurnal ini harus lulus peer review secara ketat. Kemudian, untuk menjamin software sesuai dengan hasil peer review, maka penulisan code dilakukan dengan formal method.
Formal Method berarti para engineer dan developer harus membuat spesifikasi code secara matematis. Dengan ini menjamin saat code dijalankan, hasilnya sesuai dengan desain yang diharapkan. Code tersebut ditulis dalam Haskell (a high-assurance functional programming language with a strong type system) . Walaupun Haskell merupakan bahasa pemrograman yang tepat, namun masih belum dapat dipercayai sepenuhnya sehingga masih perlu ditesting. Oleh karena itu, digunakan sebuah tool lagi bernama QuickCheck (automatic testing of Haskell programs) yang dapat menghasilkan banyak test case dan menguji properti – properti yang harus tetap ada ketika program dijalankan.
Ilustrasi Pengembangan Sistem di Cardano
Ilustrasi 1. Membangun Jembatan dengan metode tim insinyur (Formal Method)
-
Bayangkan tim insinyur bangunan yang ingin membangun jembatan.
-
Sebagian besar waktu mereka dihabiskan di belakang meja untuk membuat perencanaan desain, melakukan survey keadaan geografis, menghitung variabel – variabel struktur; gempa; angin, dll.
-
Di periode ini, tidak ada aktivitas apapun yang terjadi di site lokasi jembatan.
-
Seorang observer (misalnya dari masyarakat) tidak dapat melihat setiap progress yang sedang dikerjakan.
-
Dalam membangun jembatan, cara seperti ini adalah metode yang paling tepat.
-
Jika perencanaannya salah, maka akan sangat sulit dan mahal perbaikannya nanti. Proyek menjadi tertunda dan biayanya naik, bahkan bukan tidak mungkin proyek tersebut dinyatakan gagal.
Ilustrasi 2. Membangun Jembatan dengan proses Agile
-
Ketika membangun atau membuat software, perubahan yang dilakukan di fase – fase akhir lebih mudah dilakukan daripada saat pengembangan.
-
Hal inilah yang memungkinkan pengembangan dengan proses Agile.
-
Seandainya developer software membangun jembatan, maka yang terjadi adalah:
-
Membangun satu pilar jembatan di dalam satu sprint (batasan waktu tertentu yang ditetapkan untuk men-deliver sebuah progress atau memecahkan sebuah masalah).
-
Membangun pilar jembatan lainnya di sprint berikutnya.
-
Jika pembangunan jembatan belum selesai, maka dapat ditambahkan sesi – sesi sprint lainnya.
-
Seorang observer (misalnya dari masyarakat) dapat melihat setiap progress yang sedang dikerjakan
-
Hasil akhir dari pembangunan jembatan kemungkinan besar menemui banyak kendala dan jauh dari sempurna. Akan muncul banyak hal yang harus di-clean up atau dirapikan kembali di fase akhir sebagai akibat dari hasil sprint yang kemungkinan berbeda dalam setiap sesi.
-
Hal ini seharusnya dapat dicegah dengan perencanaan yang matang di awal pengembangan.
Ketika mendengar kata Formal Method, banyak developer menganggapnya seperti yang dilakukan oleh insinyur bangunan (metode kerja seperti air terjun/waterfall yang linear dan sequential), karena sudah terbiasa dengan proses Agile yang incremental dan iterative.
Apa yang dilakukan oleh Tim IOHK?
Teknik yang dipakai adalah executable specifications (spesifikasi code yang dapat dieksekusi) yang berfokus pada high level design dahulu ketimbang low level design, dimana hasil dari pengembangan ini ditunjukkan sebagai progress untuk diuji dengan beberapa test case dan mendapatkan feedback dari pengguna.
Apa itu high level design?
Dalam bahasa awam, high level design berarti fokus pada gambaran besar terlebih dahulu, bagaimana sistem berjalan, dan apakah hasilnya sesuai dengan yang direncanakan.
Bagaimana dengan low level design?
Low level design adalah fitur – fitur umum yang biasa ada di dalam sistem dan dapat ditambahkan nanti di tahap iterasi selanjutnya atau di tahap finalisasi sesuai kebutuhan.
Hal ini pada akhirnya dapat mencegah kendala – kendala yang biasa muncul di tahap akhir proses Agile. Tim IOHK mendapatkan keuntungan melalui perencanaan yang baik tanpa perlu mengorbankan fleksibilitas. Oleh karena itu statement Formal vs Agile dalam pengembangan Cardano bukanlah istilah yang tepat, melainkan Formal Techniques within an Agile Delivery Framework.
Note:
Bagi kita semua yang merasa atau berpikir kenapa pengembangan Cardano lama sekali dibandingkan dengan project blockchain lainnya, well, semoga artikel di atas mampu memberikan penjelasan di balik semuanya itu. Semoga tercerahkan!
