p-ISSN : 2460-3562 / e-ISSN : 2620-8989

## Pengembangan Bahasa Pemodelan dan Code Generation untuk Smart Contract
Labib Izzatur Rahman a1 , Muhammad Zuhri Catur Candra a2
a Institut Teknologi Bandung Jl, Ganesa 10 Bandung, Jawa Barat, Indonesia
1 labibizzatur@gmail.com
2 catur@informatika.org

## Abstrak
Smart Contract merupakan konsep yang dicetus oleh Nick Szabo (Szabo, 1997) yang merupakan kontrak berbentuk elektronik. Dengan berkembangnya blockchain konsep tersebut dikonkritkan dengan bentuk code yang terpasang di jaringan blockchain yang disebut smart contract juga. Penelitian ini menggunakan definisi smart contract yang dicetus oleh Nick Szabo yang merupakan alternatif kontrak konvensional. Dalam membuat Smart Contract terdapat kesulitan karena menggabungkan dua domain pengetahuan yaitu kontrak dan informatika. Sebuah bahasa pemodelan dapat dikembangkan untuk memudahkan proses pengembangan Smart Contract. Bahasa pemodelan dapat dijadikan sebagai alat spesifikasi kontrak bahkan sampai generasi implementasi source code. Penelitian ini bertujuan membuat bahasa pemodelan yang mampu menyebutkan spesifikasi smart contract sekaligus cukup mudah digunakan oleh pengguna non-IT. Bahasa pemodelan yang dibuat juga mampu menghasilkan skeleton implementasi untuk source code smart contract.
Kata kunci: Smart Contract, modelling language, Domain-specific language, Contract, Code Generation

## Development Of Modelling Language and Code Generation for Smart Contract

## Abstract
Smart Contract is a concept coined by Nick Szabo[1] which is an electronic contract. With the development of blockchain, the concept is concreted in the form of code installed on the blockchain network, which is also called a smart contract. This study uses the definition of a smart contract coined by Nick Szabo which is an alternative to conventional contracts. In making Smart Contracts there are difficulties because it combines two knowledge domains, namely contracts and informatics. A modeling language can be developed to facilitate the Smart Contract development process. The modeling language can be used as a contract specification tool even to the generation of source code implementations. This study aims to create a modeling language that is able to state smart contract specifications and is also quite easy to use by non-IT users. The modeling language created is also capable of producing an implementation skeleton for the smart contract source code.
Keywords: Smart Contract, modelling language, Domain-specific language, Contract, Code Generation

## I. P ENDAHULUAN
Smart  Contract  pertama  diusulkan  oleh  Nick  Szabo pada  1997  sebagai  alternatif  kontrak  konvensional[1]. Konsep  Smart  Contract  menggunakan  kombinasi  dari protokol,  interface,  dan  promises  diekspresikan  melalui interface  untuk  mendigitalkan  sebuah  kontrak  pada jaringan  publik.  Konsep  Smart  Contract  melejit  seiring berkembangnya teknologi Blockchain. Blockchain sendiri merupakan salah satu jenis Distributed Ledger Technology  (DLT)  yang  merupakan  sebuah  teknologi untuk  menyimpan  record  transaction  pada  jaringan terdistribusi  dan  record  transaction  tersebut  bersifat immutable atau tidak dapat dirubah.
Dengan  perkembangan  Blockchain,  Smart  Contract diimplementasikan sebagai kode program atau script yang terpasang  di  jaringan  Blockchain  yang  akan  dijalankan oleh  peers  dari  Blockchain  tersebut[2].  Smart  Contract bertindak  sebagai  logic  dari  aplikasi  yang  dikembangan dengan  teknologi  Blockchain.  Walaupun  konsep  Smart Contract  sebagai  logic  dari  aplikasi  dan  konsep  Smart Contract  sebagai  alternatif  kontrak  konvensional  oleh Nick  Szabo  dapat  ditarik  benang  merah,  namun  terdapat perbedaan yang mendasar. Tesis ini menggunakan definisi Smart  Contract  oleh  Nick  Szabo  yang  bertujuan  untuk memformalkan sebuah kontrak dalam bentuk digital.
Sudah disebutkan bahwa Smart Contract dalam konteks Blockchain  hakikatnya  adalah  kode  program  yang terpasang  di  jaringan  Blockchain[2],  yang  berarti  dalam pembuatan Smart Contract perlu keterlibatan professional yang ahli dalam pembuatan kode program yang kita sebut developer  dan  keterlibatan  pihak  umumnya  non-IT  yang menguasai  domain  masalah  disebut  domain  expert. Menggabungkan keduanya  untuk membuat  Smart Contract  merupakan  tantangan  yang  cukup  sulit. Developer  dapat  menerjemahkan  dari  requirement menjadi  code  yang  benar,  sehingga  besar  kemungkinan ada  konsep  yang  tidak  ada  di  implementasi  Smart Contract namun ada di requirement Smart Contract.
Untuk  meringankan  beban  Developer  Smart  Contract, bahasa  pemodelan  dapat  dikembangkan  yang  berfokus untuk  memodelkan  Smart  Contract.  Bahasa  pemodelan yang  tepat  mampu  mengekspresikan  abstraksi-abstraksi penting  dalam  pembuatan  Smart  Contract.  Bahasa pemodelan  juga  sanggup  menjadi  alat  komunikasi  antara stakeholder  untuk  menyebutkan  requirement.  Bahasa pemodelan dapat menghasilkan model yang menggambarkan  struktur  dan  behaviour  dari  Smart Contract. Apabila dipadukan dengan code generator, maka juga  mampu  membantu  dalam  implementasi  Smart Contract tersebut.
Luaran tesis ini adalah merumuskan bahasa pemodelan untuk Smart Contract yang dapat menggambarkan kontrak konvensional  secara  umum  dan  code  generator  yang mampu mengubah model dengan Bahasa pemodelan yang dirancang  menjadi  skeleton  class  yang  menggambarkan struktur dari implementasi Smart Contract yang dirancang.

## II. M ETODOLOGI

## A. Metodologi Penelitian
Metode penelitian DSL yang dibuat mengikuti yang telah dicanangkan oleh [3] yaitu :
a) Analisis
Fase Analisis bertujuan untuk membangun pemahaman terhadap domain masalah. Hal yang perlu dilakukan  di  fase  ini  adalah  mengidentifikasi  domain masalah  dan  mengumpulkan  pengetahuan  terkait domain  masalah.  Pengetahuan  terhadap  domain masalah  dapat  bersumber  dari  dokumen  teknis, pengetahuan  oleh  domain  expert,  source  code,  dan survei  customer.  Ouput  dari  fase  ini  berupa terminology dan semantik terkait domain masalah.
b) Desain
Fase Desain bertujuan untuk mendesain DSL sesuai spesifikasi  yang  didapatkan  dari  fase  analisis.  Tipe desain  DSL  dapat  dibagi  menjadi  dua,  yaitu  informal design  atau  formal  design.  Pada  informal  design spesifikasi DSL dijabarkan dalam suatu bentuk natural language.  Formal  design  menggunakan  spesifikasi definisi  semantik  yang  sudah  ada  seperti  regular expressions  dan  abstract  state  machines  for  semantic specification.Implementasi.
c) Implementasi
Fase  implementasi    membuat  library  yang  dapat mengimplementasi  desain  DSL  yang  sudah  dibuat. Selain  itu  juga  membuat  generator  yang  dapat mengubah  model  DSL  menjadi  implementasi  source code.

## B. Kerangka Teori
Pada  subbab  ini  disebutkan  beberapa  landasan  teori yang akan menjadi fondasi dalam penelitian.

## B.1 Smart Contract
Smart Contract adalah sebuah code yang berjalan di  atas  platform  blockchain  dan  eksekusinya  dapat dipicu  oleh  client  external  dari  network  blockchain atau  dari  smart  contract  lain[4].  Smart  Contract ditujukan untuk secara otomatis mampu mengeksekusi perintah  tertentu  relatif  terhadap  suatu  kontrak  atau perjanjian[5].  Karena  Smart  Contract  berupa  code, maka  Smart  Contract  mempunyai  banyak  aplikasi. Umumnya Smart Contract digunakan untuk melakukan suatu transaksi apabila persyaratan tertentu terpenuhi.  Beberapa  penggunaan  lain  bisa  berupa sebagai  instrumen  finansial  dan  sebagai  sebuah contract yang mampu menjalankan eksekusinya secara otomatis[4].
Tidak semua platform public blockchain mendukung implementasi Smart Contract dan platform  blockchain  yang  menyediakan  implementasi Smart  Contract  pun  berbeda  fitur-fitur  satu  platform dengan  yang  lain.  Pada  saat  ini,  Bitcoin  sebagai platform  blockchain  yang  paling  besar  dan  paling umum  digunakan  tidak  dapat  mendukung  Smart Contract  yang  kompleks  dan  dinilai  kurang  efisien dalam  mengimplementasikan  Smart  Contract.  Untuk saat  ini  ada  dua  platform  blockchain  yang  umum digunakan yaitu Ethereum dan Hyperledger Fabric[6]. Ethereum menggunakan bahasa pemrograman Solidity untuk membuat smart contract, sedangkan Hyperledger  Fabric  uniknya  mampu  menggunakan bahasa  pemrograman  yang  sudah  ada  untuk  membuat smart contract. Hyperledger Fabric saat ini mendukung  bahasa  pemrograman  Go,  nodeJS  dan Java[2].

## B.2 Kontrak
Di  dalam  sebuah  kontrak,  tertulis  hak  dan kewajiban  dari  pihak  yang  terkait  dalam  kontrak tersebut.  Sering  kali  tertulis  juga  tindakan  yang  harus dilakukan  atau  konsekuensi  yang  akan  terjadi  apabila hak  atau  kewajiban  tidak  terpenuhi.  Dengan  begitu juga,  terdapat  batasan  sehingga  pihak  tidak  perlu melakukan  apa  yang  bukan  menjadi  kewajiban  dalam kontrak[7].  Menurut  KUH  Perdata,  syarat  sah  sebuah kontrak  adalah  :  Kesepakatan  antar  pihak,  kecakapan dari pihak terkait, suatu pokok persoalan tertentu, dan suatu sebab yang tidak terlarang[8].
Elemen-elemen  yang    dapat  hadir  dalam  suatu kontrak adalah sebagai berikut[9]:
1. Parties
Parties  atau  pihak  adalah  pihak  yang  terkait dengan  kontrak.  Pada  dasarnya,  pihak  dalam  suatu
kontrak bisa sebanyak 2 atau lebih. Pihak dapat berupa seorang  individu,  sekelompok  orang,  atau  sebuah korporasi.  Setiap  kontrak  harus  melibatkan  minimal dua  pihak  yang  mempunyai    hak  dan  kewajiban  yang berbeda,  yaitu  :  Offeror  sebagai  pihak  yang  harus melakukan atau  memberi sesuatu, dan offeree sebagai penerima jasa atau barang dari offeror.
2. Covenants
Covenants    atau  perjanjian  adalah  pernyataan janji  untuk  melakukan  sesuatu  atau  untuk  tidak melakukan  sesuatu  di  masa  yang  akan  datang. Covenants  merupakan  bagian  paling  utama  dari sebuah kontrak.
3. Conditions
Conditions merupakan prasyarat untuk perjanjian tertentu.  Sebagai  contoh,  “Pihak  pertama  akan membeli  properti  apabila  property  lulus  inspeksi keamanan  lingkungan”.  Dalam  hal  ini,  klien  hanya akan  membayar  apabila  properti  lulus  suatu  uji tertentu.  Umumnya  terdapat  kata  if/then  pada conditions.
4. Considerations Consideration merupakan “Sesuatu yang berharga  yang  belum  dipunyai  suatu  pihak,  diberikan kepada  pihak  tersebut  sebagai  imbalan  janji-janji kontrak”[10].Sebuah  consideration  atau  hal  serupa merupakan syarat utama pembuatan kontrak.
Consideration dapat berupa :
• Nominal Uang
• Suatu barang atau properti • Janji untuk melakukan sesuatu
• Janji untuk tidak melakukan sesuatu
5. Warranty
Warranty  atau  garansi  merupakan    salah  satu perjanjian  dalam  kontrak  yang  menyatakan  jaminan akan  suatu  kualitas  produk  tertentu[11].    Apabila terjadi  pelanggaran  warranty,  maka  pihak  yang dirugikan  dapat  menuntut  ke  pihak  yang  bertanggung jawab,  akan  tetapi  pihak  yang  dirukan  tidak  boleh membatalkan kontrak tersebut.
B.3 Bahasa Pemodelan
Bahasa  pemodelan  atau  modelling  language adalah  bahasa  komputer  grafis  atau  tekstual  yang menjadi  dasar  dalam  mendesain  dan  konstruksi struktur  dan  model  dari  suatu  sistem  mengikuti seperangkat aturan dan kerangka kerja yang sistematis. B.3.1 Bahasa Pemodelan Grafis
Bahasa  pemodelan  grafis  yang  populer  sampai saat  ini  adalah  Unified  Modeling  Language  (UML) yang  merupakan  general-purpose  modeling  language. General-purpose berarti UML mampu menggambarkan  abstraksi  structural  atau  behavioural dari  suatu  sistem  secara  umum[12].  Contoh  umum adalah class diagram dan state diagram . B.3.2 Bahasa Pemodelan Tekstual Bahasa pemodelan tekstual menggunakan machine-readable text atau natural language-like untuk memodelkan  sistem  yang  akan  dibangun.    Salah  satu yang termasuk bahasa pemodelan tekstual yang umum digunakan  adalah  Domain-specific  language  (DSL).
DSL  adalah  bahasa  yang  dikhususkan  untuk menjelaskan  aspek  tertentu  pada  suatu  sistem software[13]. DSL  memiliki  cakupan  yang lebih  kecil dibandingkan bahasa pemrograman general purpose. B.4 Language Workbench
Language  Workbench  merupakan  sebuah  tool atau  serangkaian  tool  yang  memungkinkan  language- oriented  programming  (LOP)[14].  Language-oriented programming  merupakan  paradigma  pemrograman dimana  bahasa  merupakan  fondasi  utama  dalam membangun  suatu  software.  Contoh  sederhana  yang relevan  dengan  penelitian  ini  adalah  pengembangan software menggunakan DSL.

## III. H ASIL DAN PEMBAHASAN
Bab ini  membahas tiap hasil  dari metode penelitian. Terdiri atas tiga Langkah.

## A.. Analisis
Secara  hukum  kontrak  memiliki  sedikit  sekali persyaratan.  Menurut  KUH  Perdata  Pasal  1320,  sebuah kontrak atau persetujuan dianggap sah apabila ada :
-  Terdapat dua atau lebih pihak
-  Kesepakatan yang mengikat antara pihak tersebut
-  Kecakapan untuk membuat kesepakatan tersebut
-  Suatu pokok persoalan tertentu
-  Suatu sebab yang tidak terlarang
Berdasarkan pasal tersebut, dapat ditarik dua elemen dasar  yaitu  adanya  pihak  dan  adanya  kesepakatan.  Dua elemen  ini  akan  selalu  hadir  di  segala  kontrak.  Untuk setiap  kesepakatan  tidak  jarang  terdapat  prasyarat (conditions) yang diminta suatu pihak agar pihak tersebut bersedia  untuk  menjalankan  kontrak  tersebut.  Definisi prasyarat  yang  dimaksud  adalah  suatu  pihak  hanya  akan menjalankan  suatu  obligasi  apabila  satu  atau  lebih  syarat yang diminta terpenuhi.
Berdasarkan  literatur  lain[15],  elemen  lain  yang disebutkan adalah consideration. Consideration merupakan  “Sesuatu  yang berharga  yang belum dipunyai suatu  pihak,  diberikan  kepada  pihak  tersebut  sebagai imbalan  janji-janji  kontrak”[10]  Sebuah  consideration atau  hal  serupa  merupakan  syarat  utama  pembuatan kontrak. Consideration dapat berupa :
•  Nominal Uang
•  Suatu barang atau properti
•  Janji untuk melakukan sesuatu
•  Janji untuk tidak melakukan sesuatu
Melihat  beberapa  model  kontrak  penjualan  barang [16]pembayaran  menjadi  salah  satu  concern  utama. Pembayaran  dapat  dilakukan  sebagian  di  muka  oleh pembeli,  lalu  sisanya  setelah  barang  dikirim,  atau pembayaran  dapat  melalui  kredit  dengan  bank  sebagai pihak  ke-3.  Setiap  pembayaran  memiliki  tenggat  waktu dan  bila  berasa  butuh  dapat  memberlakukan  penalti apabila ada keterlambatan pembayaran.
Untuk meringkas ulang, beberapa elemen pada suatu kontrak secara umum adalah sebagai berikut :
-  Pihak / party
-  Kesepakatan / term
-  Prasyarat / conditions
-  Considerations
-  Pembayaran / payment
B . Desain
Rencana  struktur  SL4SC  tergambar  pada  gambar  1. Metamodel terdiri dari Contract, Party, Term, Consideration, Struct, dan Payment. •  Contract : Merupakan
entitas
yang merepresentasikan  sebuah  smart  contract.  Contract  akan menaungi elemen-elemen yang lain.
•  Party  :  Party  merepresentasikan  pihak  yang terkait kontrak. Party dapat mempunyai name dan action.
•  Term : Merepresentasikan kesepakatan.
•  Consideration  :  Merepresentasikan  barang  atau sesuatu yang dijanjikan.
•  Payment : Merepresentasikan pembayaran.
•  Struct  :  Merupakan  custom  type  untuk memperkenalkan  variable  lain  di  luar  yang  telah disebutkan.
•  Conditions  :  Merupakan  prasyarat  yang  harus dilakukan  suatu  pihak  agar  pihak  lain  setuju  untuk melaksanakan suatu term tertentu.
•  Warranty  :  Merupakan  jaminan  oleh  pihak tertentu. Apabila jaminan ini rusak, maka pihak lain boleh mendapatkan semacam kompensasi.

## Gambar 1. Metamodel DSL SL4SC

## C.  Implementasi
Berdasarkan analisis perlu dipilih language workbench yang mendukung notasi tekstual. Terdapat dua language workbench berbasis tekstual yang cukup dikenal dan  mempunyai  dokumentasi  yang  cukup  lengkap sehingga  lebih  mudah  bagi  pemula  untuk  mulai mengembangkan  DSL.  Language  workbench  tersebut adalah  Jetbrains  MPS  dan  Xtext.  Xtext  merupakan  open- source  language  workbench  yang  dapat  ditemukan  di Eclipse[17].
SL4SC  dikembangkan  menggunakan  Jetbrains  MPS dengan  pertimbangan  bahwa  MPS  merupakan language workbench untuk  DSL  yang  bersifat  proyeksional[18] yang  berarti  mendukung  notasi  tekstual,  simbolik,  tabel, dan  grafis.  Kemampuan  MPS  untuk  mendukung  notasi- notasi  tersebut  berpotensi  memudahkan end-user dalam mengoperasikan DSL yang dikembangkan.
Membangun DSL dengan MPS utamanya membutuhkan  dua  komponen  yaitu concept dan editor . Concept menggambarkan  struktur  dari  suatu  konsep layaknya class pada  umumnya  dan editor menjelaskan bagaimana end-user melihat  dan  berinteraksi  dengan DSL.
Hasil  akhir  dari  penelitian  tergambarkan  di  gambar 2. Pengguna dapat memasukkan informasi terkait kontrak
di  kolom  yang  disediakan.  Informasi  yang  dapat dimasukkan  ada kontrak,  party,  consideration,  term, struct, dan payment yang  berdasarkan  rancangan metamodel dari fas analisis. MPS mendukung highlighting di  mana  seorang  pengembang  DSL  dapat men- highlight komponen  yang  harus  dimasukkan  untuk memudahkan pengguna.
Gambar 2 Tampilan user ketika menggunakan DSL
Salah  satu  konsep  yang  merupakan  pusat  perhatian DSL merupakan konsep term. Concept Term merepresentasikan  ketentuan  pada  suatu  kontrak.  Term dapat  diberi  keterangan  melalui  abstraksi  interface afterTerm di  mana  termasuk  keterangan  waktu  dan prakondisi.  Sebuah  contoh  pengisian term dengan berbagai  keterangan  tergambarkan  pada  gambar  3. Dengan  struktur  sedemikian term mampu  mendukung warranty dan conditions yang  didefinisikan  pada  fase desain.

## Gambar 3 Penggunaan Term
Setelah  definisi  DSL  selesai  MPS  mendukung code generation  model-to-text yang  berarti  DSL  dapat  diubah menjadi  implementasi source  code .  Target source  code adalah  Solidity  yang  merupakan  bahasa smart  contract untuk  platform  Ethereum.  Untuk  melakukan code generation pada  MPS  minimal  dibutuhkan  dua,  yaitu mapping dan template . Mapping adalah  definisi concept apa yang akan dilakukan transformasi dan template adalah bagaimana  melakukan  transformasi  tersebut. Template dibuat  berdasarkan  Solidity  dan  didefinisikan macro . Macro adalah  definisi  bagian  apa  di- template tersebut yang akan disisipkan berdasarkan input DSL. Membangun DSL  dengan  MPS  utamanya membutuhkan  dua komponen yaitu concept dan editor . Concept menggambarkan struktur dari suatu konsep layaknya class
Setiap Party, dan Consideration akan  dijadikan sebuah  Struct  pada  Solidity  dan  setiap Action yang didefinisikan  akan  dijadikan  declarative  method  tanpa implementasi  dengan  tambahan  keterangan  di  atas  fungsi tersebut.  Gambar  4  merupakan  contoh  cuplikan  dari sebuah code generation .
Gambar 4 Hasil Code generation

## D. Evaluasi
Evaluasi dilakukan dengan memodelkan suatu sampel kontrak diambil dari website konsultasi legalitas. Gambar 5 merupakan kontrak yang akan dievaluasi.

## Gambar 5 Kontrak Penjualan
Hasil  dari  SL4SC  digambarkan  oleh  gambar  6. SL4SC  mampu  menjelaskan  kontrak  pada  gambar  5 dengan  bentuk  tertentu.  Walaupun  tidak  100%  sama dengan kontrak konvensional, akan tetapi SL4SC  mampu memodelkan kontrak penjualan konvensional sampai pada tingkat tertentu.

## Gambar 6 SL4SC memodelkan kontrak penjualan

## IV. K ESIMPULAN
Berdasarkan  hasil  penelitian  yang  telah  dilakukan, kesimpulan penelitian ini adalah
1. Sebuah  DSL  yang  dibuat  dengan  editor projectional  mampu  memodelkan  requirement  dari  suatu kontrak konvensional. Dalam hal ini kontrak konvensional yang digambarkan adalah kontrak penjualan.
2. Dengan  menggunakan  editor  projectional,  DSL yang  dibuat  dapat  secara  mudah  di  extend  untuk memperluas kosakata DSL.
3.
DSL  dan  code  generator  yang  dicipkan  dapat memodelkan  kontrak  konvensional  dan  mentransformasi menjadi implementasi skeleton untuk smart contract yang dalam hal ini menjadi file Solidity.

## V. S ARAN
Untuk  penelitian  selanjutnya,  pengembangan  DSL dapat dikembangkan lagi kosakatanya untuk memodelkan kontrak  yang  lain.  Dalam  mengembangkan  Bahasa dimudahkan dalam DSL dengan editor projectional karena kemampuannya  dalam  meng-extend  DSL  yang  telah  ada. Pengembangan  juga  dapat  dilakukan  di  sisi  code generation untuk dapat men-genereate fungis konkret dari smart contract.

## VI. U CAPAN TERIMA KASIH
Terima  kasih  saya  ucapkan  kepada  pak  Catur  selaku pembimbing  saya,  kedua  orang  tua  saya,  dan  teman- teman yang saling mendukung. Tanpa mereka saya tidak akan dapat menyelesaikan tulisan ini.
VII. DAFTAR PUSTAKA [1] N. Szabo, “Formalizing and Securing Relationships on Public Network,” 1997. [Online]. Available: https://nakamotoinstitute.org/formalizing- securing-relationships/. [Accessed: 29-Mar-2022].
[2] E. Androulaki et al. , “Hyperledger Fabric: A

## Distributed Operating System for Permissioned
Blockchains,” Proc. 13th EuroSys Conf. EuroSys
2018 , vol. 2018-Janua, Apr. 2018.
[3] M. Mernik, J. Heering, and A. M. Sloane, “When and how to develop domain-specific languages,” ACM Comput. Surv. , vol. 37, no. 4, pp. 316–344, 2005.
[4] L. Luu, D. H. Chu, H. Olickel, P. Saxena, and A. Hobor, “Making smart contracts smarter,” in Proceedings of the ACM Conference on Computer and Communications Security , 2016, vol. 24-28-
Octo, pp. 254–269.
[5] A. Savelyev, “Contract law 2.0: ‘Smart’ contracts as the beginning of the end of classic contract law,” Inf. Commun. Technol. Law , vol. 26, no. 2, pp. 116–134, 2017.
[6] P. Das et al. , “Fastkitten: Practical smart contracts on bitcoin,” in Proceedings of the 28th USENIX Security Symposium , 2019, pp. 801–818.
[7] G. F. Schuppert, A Global History of Ideas in the Language of Law . Max Planck Institute for Legal
History and Legal Theory, 2021.
[8] Subekti, R, dan R. Tjitrosudibio, “Kitab Undang- undang Hukum Perdata (KUH Perdata),” Angew. Chemie Int. Ed. 6(11), 951–952. , pp. 11–28, 2019.
[9] L. D. Johnson, “One Hour Cle Credit Effective Contract Drafting : Identifying the Building Blocks of Contracts,” no. October, pp. 24–25, 2013.
[10] Thomson Reuters, “Consideration - Practical Law
Definition,” 2022. [Online]. Available: https://uk.practicallaw.thomsonreuters.com/Docu ment/I8abcb5601c9a11e38578f7ccc38dcbee/View /FullText.html?navigationPath=Search%2Fv1%2 Fresults%2Fnavigation%2Fi0ad740360000017b9 82bc85771e68c2d%3Fppcid%3Dc14c980603964 e0f874a89789c7d454b%26Nav%3DKNOWHOW _UK%26. [Accessed: 18-Apr-2022].
[11] W. Kenton, “Warranty Definition,” 23-Apr-2021. [Online]. Available: https://www.investopedia.com/terms/w/warranty.a sp. [Accessed: 01-May-2022].
[12] OMG Object Management Group, “An OMG ®
Unified Modeling Language ® Publication,” no.
December, 2017.
[13] M. Fowler and R. Parson, “Domain Specific Languages,” 2010. [Online]. Available: https://martinfowler.com/books/dsl.html. [Accessed: 19-Apr-2022].
[14] M. Fowler, “A Language Workbench in Action - MPS,” 2005. [Online]. Available: https://martinfowler.com/articles/mpsAgree.html. [Accessed: 12-May-2022].
[15] S. Sharifi, A. Parvizimosaed, D. Amyot, L.
Logrippo, and J. Mylopoulos, “Symboleo: Towards a Specification Language for Legal Contracts,” Proc. IEEE Int. Conf. Requir. Eng. , vol. 2020-Augus, pp. 364–369, 2020.
[16] F. Emmert, “Model Contract for International Sales Transactions (Manufactured Goods),” no.
October, 2015.
[17] S. Erdweg et al. , “Evaluating and comparing language workbenches: Existing results and benchmarks for the future,” Comput. Lang. Syst.
Struct. , vol. 44, pp. 24–47, 2015.
[18] Jetbrains, “MPS: The Domain-Specific Language Creator by JetBrains,” 2022. [Online]. Available: https://www.jetbrains.com/mps/. [Accessed: 08- Jun-2022].