Versi dokumen orisinil: Plutus: what you need to know
Dipublikasikan pada tanggal 13 April 2021
Ditulis oleh Lars Brünjes
Terjemahan ke dalam Bahasa Indonesia oleh @andreassosilo
(Translated to Indonesian language by @andreassosilo)
Plutus: apa yang perlu Anda ketahui
Developer sekarang sedang mempersiapkan kedatangan smart contract Cardano, yang diaktifkan oleh Plutus dan peningkatan protokol Alonzo
13 April 2021 Lars Brünjes bacaan 9 menit
Di postingan blog sebelumnya, kita membahas Alonzo - nama yang kami berikan untuk peningkatan protokol, yang akan memperkenalkan dukungan smart contract di Cardano. Alonzo akan membangun infrastruktur dan menambahkan alat untuk pengembangan smart contract fungsional menggunakan Plutus.
Platform Plutus menyediakan bahasa smart contract asli untuk blockchain Cardano. Untuk memahami dan menjadi mahir dalam Plutus, seseorang harus memahami tiga konsep:
- Model Extended UTXO (EUTXO)
- Plutus Core ‒ bagian ‘on-chain’ dari Plutus
- Plutus Application Framework (PAF) ‒ bagian ‘off-chain’ dari Plutus yang memungkinkan interaksi dengan smart contract.
Kontrak Plutus terdiri dari bagian-bagian yang berjalan di blockchain (kode on-chain) dan bagian-bagian yang berjalan di mesin pengguna (off-chain atau kode klien). Baik kode on-chain dan off-chain ditulis di Haskell, dan kontrak pintar Plutus secara efektif adalah program Haskell. Kode off-chain dapat ditulis menggunakan PAF dan kode ini kemudian dikompilasi oleh GHC (Glasgow Haskell Compiler), sedangkan kode on-chain (ditulis menggunakan Plutus Core) dikompilasi oleh compiler Plutus.
Sangat penting untuk memahami hubungan antara konsep Plutus ini dan fungsionalitas token asli untuk melihat bagaimana interaksi mereka mengubah yang terakhir menjadi fitur yang lebih berguna dan kuat.
Model Extended UTXO
Cardano (seperti Bitcoin) menggunakan model akuntansi transaksi (TX) output (O) yang tidak terpakai (U). Dalam model UTXO, transaksi memiliki input dan output, di mana input adalah output yang tidak terpakai dari transaksi sebelumnya. Begitu sebuah keluaran digunakan sebagai masukan dalam sebuah transaksi, ia menjadi * dibelanjakan * dan tidak dapat digunakan lagi. Output ditentukan oleh alamat (kunci publik atau hash kunci publik) dan nilai (terdiri dari jumlah yang ada dan opsional, jumlah token asli tambahan). Alamat keluaran menentukan transaksi mana yang diizinkan untuk ‘membuka’ keluaran dan menggunakannya sebagai masukan. Transaksi harus ditandatangani oleh pemilik kunci pribadi yang sesuai dengan alamat tersebut. Bayangkan sebuah alamat sebagai ‘gembok’ yang hanya bisa ‘dibuka’ dengan ‘kunci’ yang benar - tanda tangan yang benar.
Model EUTXO memperluas model ini dalam dua arah:
- Ini menggeneralisasi konsep ‘alamat’ dengan menggunakan analogi gembok-dan-kunci. Alih-alih membatasi gembok ke kunci publik dan kunci untuk tanda tangan, alamat dalam model EUTXO dapat berisi logika arbitrer dalam bentuk skrip. Misalnya, ketika sebuah node memvalidasi sebuah transaksi, node tersebut menentukan apakah transaksi tersebut diperbolehkan untuk menggunakan output tertentu sebagai input atau tidak. Transaksi akan mencari skrip yang disediakan oleh alamat keluaran dan akan mengeksekusi skrip jika transaksi dapat menggunakan keluaran sebagai masukan.
- Perbedaan kedua antara UTXO dan EUTXO adalah bahwa output dapat membawa (hampir) data sembarang selain alamat dan nilai. Ini membuat skrip jauh lebih kuat dengan memungkinkan mereka membawa status.
Saat memvalidasi alamat, skrip akan mengakses data yang dibawa oleh output, transaksi yang divalidasi, dan beberapa data tambahan yang disebut redeemers, yang disediakan oleh transaksi untuk setiap input. Dengan mencari semua informasi ini, skrip memiliki konteks yang cukup untuk memberikan jawaban ‘ya’ atau ‘tidak’ dalam situasi dan kasus penggunaan yang sangat kompleks.
Singkatnya, EUTXO memperluas model UTXO dengan mengizinkan alamat keluaran berisi logika kompleks untuk memutuskan transaksi mana yang dapat membukanya, dan dengan menambahkan data khusus ke semua keluaran.
Model EUTXO menawarkan keunggulan unik dibandingkan model akuntansi lainnya. Keberhasilan atau kegagalan validasi transaksi hanya bergantung pada transaksi itu sendiri dan inputnya, dan bukan pada hal lain di blockchain. Akibatnya, validitas transaksi dapat diperiksa off-chain, sebelum transaksi dikirim ke blockchain. Transaksi masih bisa gagal jika beberapa transaksi lain secara bersamaan mengkonsumsi input yang diharapkan transaksi, tetapi jika semua input masih ada, transaksi dijamin akan berhasil.
Ini berbeda dengan model berbasis akun (seperti yang digunakan oleh Ethereum), di mana transaksi bisa gagal dalam eksekusi mid-script. Ini tidak akan pernah terjadi di EUTXO. Selain itu, biaya eksekusi transaksi dapat ditentukan off-chain sebelum transmisi - fitur lain yang tidak mungkin dilakukan di Ethereum.
Akhirnya, karena sifat ‘lokal’ dari validasi transaksi, tingkat paralelisme yang tinggi dimungkinkan: node dapat, pada prinsipnya, memvalidasi transaksi secara paralel, jika transaksi tersebut tidak mencoba untuk mengkonsumsi input yang sama. Ini bagus untuk efisiensi dan penalaran, menyederhanakan analisis kemungkinan hasil, dan membuktikan bahwa ‘tidak ada hal buruk’ yang bisa terjadi. Anda dapat mempelajari lebih dalam tentang model EUTXO di entri blog sebelumnya.
Plutus Core
Untuk mengimplementasikan model EUTXO, istilah script dan data harus didefinisikan dengan jelas. Skrip memerlukan bahasa skrip yang pasti dan ditentukan dengan baik, dan juga penting untuk menentukan jenis data yang dilampirkan ke keluaran dan digunakan sebagai penebus.
Di sinilah Plutus Core masuk. Plutus Core adalah bahasa skrip yang digunakan oleh Cardano. Ini adalah bahasa fungsional sederhana yang mirip dengan Haskell, dan sebagian besar Haskell dapat digunakan untuk menulis skrip Plutus Core. Sebagai penulis kontrak, Anda tidak boleh menulis Plutus Core apa pun. Semua program Plutus Core dihasilkan oleh plugin compiler Haskell.
Skrip ini akan dieksekusi oleh node selama validasi transaksi ‘langsung’ di rantai. Mereka akan mengunci UTXO dalam bentuk skrip validator atau sebagai pembuatan kebijakan, yang mengontrol pembuatan dan pembakaran token asli (lihat di bawah).
Data penebus adalah tipe data sederhana (aljabar) yang dapat didefinisikan dengan mudah di Haskell, yang merupakan alasan lain mengapa Haskell adalah pilihan yang baik untuk menulis skrip Plutus Core. Dalam praktiknya, developer smart contract akan menulis skrip validator di Haskell, yang kemudian akan secara otomatis dikompilasi menjadi Plutus Core.
Pustaka Haskell yang sesuai menyederhanakan penulisan logika validasi tersebut dengan menyediakan tipe data inti untuk pemeriksaan transaksi selama validasi, dan dengan menawarkan banyak fungsi pembantu dan abstraksi tingkat yang lebih tinggi, memungkinkan penulis kontrak untuk berkonsentrasi pada logika bisnis dan tidak perlu khawatir terlalu banyak mengenai detail tingkat rendah.
Plutus Application Framework (PAF)
Status skrip validator on-chain hanya dapat diubah oleh transaksi yang menghabiskan dan menghasilkan keluaran skrip. Saat menulis aplikasi Plutus, kita perlu mempertimbangkan tidak hanya bagian on-chain dari aplikasi (skrip Plutus Core) tetapi juga bagian off-chain yang membangun dan mengirimkan transaksi.
Kode off-chain ditulis di Haskell, sama seperti kode on-chain. Dengan begitu kita hanya perlu menulis logika bisnis satu kali. Kemudian kita bisa menggunakannya di skrip validator dan di kode yang membangun transaksi yang menjalankan skrip validator.
Banyak aplikasi perlu mengawasi UTXO yang disetel untuk perubahan ke alamat tertentu, jadi jika kita menulis kontrak kita sebagai state machine, kita perlu melacak keluaran yang tidak terpakai yang mewakili keadaan mesin saat ini dan memperbarui keadaan lokal kita saat on-chain perubahan state. Demikian pula, banyak aplikasi perlu berkomunikasi dengan backend wallet untuk mengakses mata uang kripto yang mereka gunakan untuk transaksi.
PAF menyediakan akses mudah ke layanan yang biasa digunakan oleh aplikasi Plutus. Aplikasi yang diterapkan menggunakan pustaka framework dapat dijalankan di backend aplikasi Plutus, yang menyediakan dukungan waktu proses untuk akses ke blockchain dan masalah lain seperti persistensi, logging, dan pemantauan. Aplikasi yang ditulis di atas PAF secara otomatis menyediakan antarmuka HTTP dan WebSocket yang dapat digunakan untuk berinteraksi dengan aplikasi dari browser web.
Native tokens
Native tokens tersedia di Cardano melalui hard fork Mary bulan Februari. Setiap pengguna dapat membuat token mereka sendiri, dan token dapat dikirim dan diterima dengan bebas, seperti halnya ADA. Setiap native token dilengkapi dengan kebijakan pembuatan sendiri, yang menentukan kondisi di mana token dapat dicetak dan dibakar.
Saat ini, kebijakan pembuatan ini terdiri dari kombinasi aturan sederhana yang menetapkan tanda tangan dan garis waktu. Misalnya, kebijakan dapat menyatakan bahwa hanya transaksi yang ditandatangani oleh dua dari lima kemungkinan tanda tangan yang diizinkan untuk membuat atau membakar token. Kebijakan lain dapat mengizinkan pencetakan hanya sebelum atau setelah slot waktu tertentu.
Sekuat apa pun bahan penyusun dasar ini, mereka tidak mencakup semua kemungkinan penggunaan. Misalnya, mungkin, tetapi canggung, untuk membuat model token non-fungible (NFT) menggunakan kebijakan sederhana seperti itu. Ini dapat dilakukan dengan menggunakan kunci waktu untuk membuat NFT, dengan membatasi operasi pencetakan ke titik waktu tertentu. Jika hanya satu token yang dicetak sebelum titik waktu tersebut tercapai, token secara teknis tidak dapat dipertukarkan (karena hanya ada satu). Tetapi untuk memeriksa ini, tidak cukup hanya dengan memeriksa kebijakan pencetakan. Kami perlu melihat riwayat pembuatan token untuk memastikan bahwa memang hanya pernah dicetak sekali.
Dengan penerapan Plutus, pengguna akan dapat menulis kebijakan pembuatan menggunakan Plutus Core. Selama pencetakan atau pembakaran, skrip kebijakan Plutus Core akan dijalankan dalam konteks transaksi pembuatan atau pembakaran, dan skrip harus menyetujui atau melarang tindakan tersebut. Hal ini selanjutnya akan mempercepat pertumbuhan NFT di Cardano dengan memungkinkan pembuatan kebijakan pencetakan yang jauh lebih kompleks, dan memungkinkan pembuatan NFT dengan cara trustless.
Alonzo secara bertahap diterapkan ke mainnet melalui beberapa testnet, jadi partner kami dan pelopor Plutus akan dapat menguji Plutus Core dengan menulis aplikasi di Cardano sepanjang Mei dan Juni sebelum kode dibekukan. Ini juga akan menjadi periode jaminan kualitas dan pengujian penerimaan pengguna oleh bursa untuk memastikan bahwa platform sepenuhnya siap pada saat peningkatan mainnet Alonzo. Jika Anda seorang developer dan ingin mempelajari lebih lanjut tentang Plutus, pertimbangkan untuk bergabung dengan kelompok perintis masa depan. Atau, lihat repositori Plutus GitHub, dan ikuti diskusi tentang Plutus di Cardano Forum.
Saya ingin mengucapkan terima kasih kepada Jann Müller atas masukan dan kontribusi tambahan untuk entri blog ini.