Versi dokumen orisinil: A comprehensive guide to Marlowe’s security: audit outcomes, built-in functional restrictions, and ledger security features
Dipublikasikan pada tanggal 27 Juni 2023
Ditulis oleh Fernando Sanchez
Terjemahan ke dalam 
Bahasa Indonesia oleh @andreassosilo
(Translated to Indonesian language by @andreassosilo)
Panduan komprehensif untuk keamanan Marlowe: hasil audit, batasan fungsional bawaan, dan fitur keamanan ledger
Pelajari tentang apa yang membuat Marlowe menjadi platform pengembangan smart contract yang aman
27 Juni 2023 | Fernando Sanchez | bacaan 19 menit
Disclaimer: Isi artikel Keamanan Marlowe ini disediakan “SEBAGAIMANA ADANYA” tanpa jaminan apapun. Tidak ada yang dimaksudkan sebagai saran profesional, termasuk namun tidak terbatas pada saran keuangan, investasi, hukum, atau pajak. Input Output Global tidak bertanggung jawab atas penggunaan atau ketergantungan Anda pada informasi dalam dokumen ini.
Pendahuluan
Pada kebanyakan blockchain, kontrak pintar (smart contract) adalah program komputer yang dieksekusi secara otomatis begitu kondisi-kondisi yang telah ditentukan terpenuhi. Namun, di Cardano, cara kerjanya sedikit berbeda, karena eksekusi kontrak pintar terjadi dalam transaksi yang diajukan secara eksternal ke node Cardano. Namun, terlepas dari bagaimana cara kerjanya di balik layar, kontrak pintar sangat berguna untuk berbagai industri, termasuk keuangan, perumahan, perdagangan, dan banyak lagi.
Transaksi yang menggunakan kontrak pintar mungkin melibatkan perpindahan dan transfer nilai yang substansial, yang bisa menjadi sasaran yang bernilai bagi pelaku jahat. Nilai ini juga bisa terkunci atau hilang sama sekali karena cacat atau kerentanannya dalam kode.
Menghindari hasil yang tidak diinginkan memerlukan penerapan kerangka keamanan yang kokoh, yang melibatkan kombinasi prinsip desain, audit, dan praktik terbaik oleh para developer, bursa, dan pihak lain yang menangani kontrak pintar.
Sebagai tambahan dari beragam sumber daya yang terus berkembang dari komunitas teknis Cardano, Marlowe adalah ekosistem alat dan bahasa yang dibuat oleh Input Output Global (IOG) untuk memungkinkan pengembangan kontrak pintar keuangan dan transaksional di blockchain Cardano.
Marlowe suite telah dirancang dan dikembangkan dengan fokus keamanan. Para pencipta Marlowe telah membatasi fungsionalitas untuk memastikan bahwa kontrak bersifat terbatas dan selalu berakhir, sebagai salah satu contoh. Marlowe juga menghindari beberapa konstruksi pemrograman untuk mencegah hasil yang tidak diinginkan, misalnya rekursi dan looping. Pihak ketiga, Tweag, melakukan audit statis dan dinamis sebelum Marlowe diterapkan di mainnet. Hasil dari semua fitur keamanan ini, dan banyak hal lainnya lagi, adalah platform penciptaan dan pengembangan kontrak pintar yang aman.
Artikel ini membahas keamanan Marlowe, menjelaskan temuan dari audit keamanan, bagaimana tim menanggapi temuan tersebut, batasan fungsional bawaan, alat analisis keamanan yang disertakan dalam implementasi, serta beberapa tindakan pencegahan dan pertimbangan yang harus diambil saat menggunakan Marlowe.
Struktur dokumen ini
Dokumen ini terbagi menjadi enam bagian yang jelas dan terdefinisi:
- Audit kontrak pintar
- Serangan berbasis kontrak pintar
- Audit Tweag
- Batasan fungsional yang meningkatkan keamanan bawaan di Marlowe
- Validasi transaksi
- Kebijakan moneter
Secara keseluruhan, dokumen ini bermaksud menyediakan pemahaman menyeluruh tentang pentingnya audit kontrak pintar dan berbagai jenis serangan berbasis kontrak pintar yang ada saat ini, sebelum secara khusus membahas bagaimana rangkaian alat Marlowe menggunakan audit dan prinsip keamanan yang kuat untuk menjaga lingkungan pengembangan kontrak pintar yang aman dan terjamin.
Audit kontrak pintar
Ikhtisar
Otonomi bawaan dari kontrak pintar dan nilai transaksi yang relatif tinggi berarti menjamin konsistensi dan keamanannya sangat penting. Hal ini memerlukan pemahaman tentang bagaimana kontrak pintar akan berperilaku saat dieksekusi sehingga potensi cacat atau kode berbahaya yang disengaja dapat terdeteksi dan diatasi. Audit kontrak pintar dari sudut pandang keamanan adalah cara terbaik untuk mencegah kegagalan atau kerusakan selanjutnya. Audit secara menyeluruh memeriksa kode dan kondisi kontrak pintar sebelum diterapkan, untuk memastikan kontrak berperilaku sesuai harapan.
Metode audit
Meskipun pendekatan untuk audit kontrak pintar dapat berbeda dan bervariasi dari proyek ke proyek, kontrak pintar dapat dianalisis menggunakan metode manual atau otomatis. Biasanya, sebagian besar proyek menggunakan kombinasi keduanya.
Pengumpulan dokumentasi
Sebelum proses audit dimulai, auditor mungkin akan menghabiskan waktu untuk mengumpulkan semua dokumentasi terkait proyek. Hal ini mungkin mencakup dokumen teknis, whitepaper, codebase, dan materi lain yang relevan dan membantu dalam proses audit.
Audit manual
Metode audit kontrak pintar ini melibatkan sekelompok orang yang menganalisis setiap baris kode, logika kontrak, arsitektur kontrak, dan langkah-langkah keamanan yang telah dibangun untuk memastikan desain yang efisien dan benar. Selain mengungkapkan kesalahan pemrograman, audit manual juga dapat menemukan cacat desain. Audit manual cenderung dianggap sebagai metode yang sangat teliti dan akurat.
Audit otomatis
Berbeda dengan audit manual, audit otomatis biasanya menggunakan pendekatan berbasis perangkat lunak untuk pengujian. Alat audit perangkat lunak, baik yang properti maupun yang tersedia di pasaran, dapat membantu mendeteksi bug, tetapi beberapa kerentanan mungkin tidak terlihat.
Karena sifat komplementer dari kedua metode ini, praktik audit terbaik melibatkan kombinasi audit manual dan otomatis untuk memastikan bahwa semua potensi cacat, bug, dan kerentanan terdeteksi dan diperbaiki.
Tindakan setelah audit
Setelah proses audit selesai, auditor akan membuat laporan yang mendetailkan temuan mereka. Laporan ini mungkin mencakup klasifikasi kesalahan berdasarkan tingkat keparahan dan serangkaian rekomendasi.
Kesalahan kontrak dapat diklasifikasikan sebagai berikut:
- Kritis: jenis cacat ini kemungkinan akan mencegah fungsi kontrak dan/atau protokol yang aman.
- Mayor: beberapa kesalahan dalam pemrograman atau logika mungkin menyebabkan kehilangan dana, atau keadaan protokol yang tidak terkendali.
- Sedang: meskipun dana mungkin tidak berisiko, jenis kesalahan ini dapat mempengaruhi kinerja atau keandalan kontrak.
- Minor: klasifikasi ini biasanya mencakup kode yang tidak efisien dengan sedikit atau tanpa dampak pada keamanan. Informatif: biasanya mengacu pada masalah gaya pemrograman atau praktik terbaik.
Keuntungan dari audit kontrak pintar
Meskipun audit penting untuk setiap aplikasi, hal ini sangat krusial untuk kontrak pintar dan aplikasi terdesentralisasi (DApps) yang berjalan pada blockchain karena sifat yang tidak dapat diubah dari buku besar terdesentralisasi ini.
Keuntungan dari audit kontrak pintar meliputi identifikasi risiko secara proaktif, menghindari kesalahan yang berpotensi mahal, lingkungan pengembangan yang lebih baik secara keseluruhan, dan memperoleh wawasan tentang kerentanannya, serta cara untuk menghilangkannya.
Identifikasi risiko secara proaktif
Penyelenggaraan kontrak pintar yang belum diaudit adalah spekulasi yang tidak boleh diambil oleh developer atau perusahaan manapun. Beberapa kontrak pintar mungkin melibatkan dana yang besar, yang jika hilang atau terancam, dapat menyebabkan tanggung jawab yang lebih besar. Dengan bekerja secara proaktif untuk menangani risiko-risiko ini, kemungkinan terjadinya masalah besar dapat dikurangi secara signifikan.
Menghindari kesalahan yang berpotensi mahal
Dana yang terkunci selamanya karena kesalahan pemrograman atau logika, atau akibat gangguan jahat dalam sebuah kontrak, adalah sesuatu yang tidak ingin dihadapi oleh pelanggan atau developer. Kerugian keuangan hanyalah satu sisi dari masalah tersebut. Ada juga dampak hukum yang serius.
Lingkungan pengembangan yang lebih baik secara keseluruhan
Penggunaan perangkat lunak audit bukan hanya direkomendasikan, tetapi menjadi keharusan. Menjamin keamanan dari suatu aplikasi atau kumpulan aplikasi dan mengikuti praktik terbaik akan memperkuat tawaran produk dan menciptakan lingkungan pengembangan yang lebih sehat.
Memperoleh wawasan tentang kerentanannya, dan bagaimana menghilangkannya
Dalam pengembangan perangkat lunak, pencegahan lebih baik daripada perbaikan. Dan ketika berbicara tentang kontrak pintar, tidak ada kesempatan untuk perbaikan karena sifat yang tidak dapat diubah dari blockchain. Audit yang mendalam akan memberikan banyak informasi tentang kode, logika kontrak, arsitektur, dan banyak parameter lainnya, memungkinkan para developer untuk menyempurnakan dan menghasilkan kontrak yang terbaik.
Serangan berbasis kontrak pintar
Serangan re-entrancy
Dalam serangan ini, fungsi kontrak pintar sementara melepaskan kendali dari transaksi dengan melakukan panggilan ke kontrak kedua, yang kemudian mulai melakukan panggilan penarikan rekursif ke kontrak pertama, menguras dana sebelum kontrak pertama memperbarui state-nya. Serangan semacam ini menjadi mungkin karena adanya bug dalam pemrograman kontrak pintar. Kejadian DAO tahun 2016 melibatkan serangan re-entrancy.
Desain blockchain Cardano membuat serangan re-entrancy menjadi tidak mungkin. Karena Cardano menggunakan model EUTXO, kontrak pintar bersifat atomik dan tidak saling memanggil satu sama lain, sehingga membuat serangan re-entrancy menjadi mustahil.
Serangan front-running
Beberapa desain blockchain memungkinkan kontrak pintar dan transaksi dapat dilihat secara publik untuk sementara waktu sebelum dikonfirmasi di blockchain. Transaksi-tansaksi yang tertunda ini dibagikan di seluruh mempool di seluruh jaringan, sehingga memungkinkan lawan untuk melihat hasil yang diinginkan dari suatu kontrak. Lawan atau pihak jahat dengan visibilitas transaksi tertunda dapat memperkenalkan perdagangan atau transaksi baru, dengan pengetahuan bahwa hal tersebut akan menghasilkan keuntungan berdasarkan transaksi tertunda, dengan mengorbankan keuntungan pengguna lainnya. Pada dasarnya, lawan memanipulasi urutan eksekusi transaksi demi keuntungan mereka sendiri.
Meskipun jenis peristiwa ini merupakan masalah besar di blockchain lain, tidak ada bukti bahwa Cardano (dan secara luas, Marlowe) rentan terhadap serangan front-running.
Manipulasi Oracle
Oracle menghubungkan blockchain dengan sistem eksternal, dan kontrak pintar mungkin dijalankan berdasarkan data yang diterima dari oracle. Ketergantungan ini pada sistem eksternal berarti jika masukan yang diterima oleh oracle telah dimanipulasi sebelum diberikan kepada oracle, keamanan dan integritas eksekusi kontrak pintar bisa terancam.
Kerentanan keamanan kontrak pintar berbasis lainnya termasuk kesalahan aritmatika, overflow dan underflow bilangan bulat, pengaturan visibilitas kontrak pintar, dan manipulasi timestamp.
Audit dari Tweag
Bagian ini berfokus pada hasil dari audit keamanan yang dilakukan oleh Tweag, tanggapan dari tim Marlowe, dan prinsip keamanan yang dibangun dalam desain Marlowe.
Temuan utama dari audit keamanan Tweag dan tanggapan internal
Tweag melakukan audit manual dan otomatis terhadap bahasa Marlowe, yang mengungkapkan beberapa masalah.
Temuan dengan tingkat keparahan tinggi meliputi penanganan deposit negatif, pencegahan ‘double satisfaction’, penerapan invarian state, perbedaan implementasi antara spesifikasi formal dan implementasi Plutus, serta teorema preservasi uang.
Penanganan deposit negatif
Pendapatan dari deposit dihitung dengan menambahkan input deposit, tanpa memperhatikan apakah mereka bersifat negatif, sementara semantiknya menganggap mereka sebagai deposit nol. Dikombinasikan dengan ketidakhadiran pemeriksaan saldo pada akhir Marlowe state, hal ini memungkinkan saldo akhir berbeda dari nilai yang dibayarkan kepada validator Marlowe. Hal ini dapat dieksploitasi oleh sebuah kontrak Marlowe yang memungkinkan deposit negatif.
Tanggapan internal
Masalah ini diselesaikan dengan menambahkan pengaman terhadap deposit negatif di validator semantik Marlowe. Pengaman ini memastikan bahwa semantik validator untuk deposit negatif sesuai dengan semantik Isabelle Marlowe. Secara khusus, deposit dengan jumlah negatif diperlakukan sebagai deposit nol. Dengan demikian, deposit negatif tidak akan mengurangi saldo akun dalam datum Plutus, dan total saldo internal akan sesuai dengan nilai yang dipegang di UTXO ke alamat skrip semantik Marlowe.
Pencegahan double satisfaction
Meskipun validator Marlowe mencegah double satisfaction di antara beberapa salinan skrip validator Marlowe yang berjalan dalam satu transaksi, hal tersebut tidak mencegahnya dalam kasus di mana validator Marlowe berjalan bersamaan dengan validator Plutus lain dalam satu transaksi.
Tanggapan internal
Double satisfaction sekarang dicegah dengan memastikan bahwa validator Marlowe adalah satu-satunya skrip Plutus yang berjalan selama transaksi yang melakukan pembayaran kepada pihak-pihak. Hal ini memungkinkan kontrak Marlowe untuk berkoordinasi dengan skrip Plutus lain, tetapi hanya dalam kondisi di mana double satisfaction tidak mungkin terjadi. Beberapa pengujian berbasis properti ditambahkan untuk memeriksa kebenaran dari mitigasi ini.
Penerapan invarian state
Awalnya, validator Marlowe membuat asumsi optimis tentang operasinya yang benar dan tidak memeriksa beberapa invarian untuk mengurangi biaya eksekusi Plutus.
Tanggapan internal
Validator semantik Marlowe sekarang secara ketat menerapkan invarian untuk state awal dan akhir, memastikan bahwa ketiga invarian state yaitu saldo akun positif, tidak adanya duplikasi entri state (akun, pilihan, dan nilai terikat), dan total nilai internal sesuai dengan nilai UTXO skrip.
Perbedaan implementasi antara spesifikasi formal dan implementasi Plutus
Audit mengungkapkan beberapa perbedaan antara spesifikasi formal dan implementasi Plutus yang sebenarnya. Secara khusus, perbedaan bahasa dan pertimbangan efisiensi terkait Isabelle, Haskell, dan Plutus Tx.
Spesifikasi formal ditulis dalam bahasa Isabelle, sebuah bahasa untuk metode formal, sementara implementasi Marlowe yang sebenarnya ditulis dalam bahasa Haskell dan Plutus Tx. Tim Marlowe berusaha untuk mengikuti spesifikasi Isabelle sebaik mungkin, tetapi beberapa deviasi tidak terhindarkan karena bahasa yang berbeda. Misalnya, beberapa aspek dari implementasi Marlowe akan tidak efisien dalam Isabelle, sehingga perubahan diperlukan untuk implementasi Haskell yang lebih efisien.
Tanggapan internal
Masalah ini diselesaikan melalui analisis kode dan pengujian berbasis properti.
Teorema keberlanjutan uang (Proof of money preservation theorem)
Teorema keberlanjutan uang hanya mempertimbangkan jumlah aset tetapi tidak memperhitungkan tipe asetnya. Ini berarti bahwa bukti tidak akan mempertimbangkan kasus di mana kontrak dapat, misalnya, menerima 20 ADA dan 15 Djed dan membayar kembali 20 Djed dan 15 ADA.
Tanggapan internal
Revisi kode Isabelle mengatasi masalah ini. Secara khusus, penambahan jenis MultiAssets yang baru dan refaktorisasi kode Isabelle (tanpa mengubah interpreter) untuk membuktikan bahwa aset-asetnya terjaga.
Batasan Fungsional yang Meningkatkan Keamanan di Marlowe
Marlowe memiliki beberapa batasan untuk memastikan bahwa risiko keamanan tertentu tidak dapat terjadi.
- Kontrak bersifat terbatas (finite)
- Kontrak akan berakhir (terminate)
- Kontrak memiliki masa hidup yang pasti
- Tidak ada aset yang dipertahankan ketika kontrak ditutup
- Nilai terpelihara (value is conserved)
Selain batasan-batasan ini, beberapa konstruksi bahasa pemrograman tidak ada dalam Marlowe untuk memastikan keselamatan:
- Rekursi tidak diizinkan
- Perulangan tidak didukung
- Fungsi atau makro tidak boleh didefinisikan
- Timeouts harus berupa konstan numerik
- Hanya kelanjutan Kasus (Case) yang dapat di-merkleize. Bahasa pemrograman Faustus mengendurkan beberapa batasan di atas, tetapi hasil kompilasinya tetap aman untuk Marlowe.
Alat Analisis Keamanan
Tim Marlowe merancang alat analisis marlowe-cli run analyze untuk memeriksa kompatibilitas kontrak Marlowe dengan aturan-aturan ledger Cardano.
Ledger Cardano memiliki batasan bawaan yang dapat mencegah kontrak Marlowe berjalan di dalam rantai (on-chain), bahkan jika kontrak itu sendiri valid dengan bahasa Marlowe. Misalnya, ledger memberlakukan batasan pada panjang nama peran dan token, dan juga membatasi biaya eksekusi Plutus. Setiap kontrak yang melanggar salah satu aturan ini tidak akan berjalan di dalam rantai, meskipun kontrak itu dibangun dengan benar. Demikian pula, meskipun kontrak dapat berjalan di Playground, mereka tidak akan berjalan di dalam rantai jika kontrak melanggar batasan ledger. Pelajari lebih lanjut tentang batasan desain ledger bawaan.
Poin penting: sementara Playground berkaitan dengan bahasa, Runtime berkaitan dengan implementasi kontrak Marlowe di blockchain Cardano secara khusus. Jika seseorang mengimplementasikan Marlowe di blockchain lain, Anda masih dapat menggunakan Playground, tetapi Anda tidak dapat menggunakan Runtime di blockchain lain.
Catatan: sebuah kontrak dapat terkunci jika data tidak sesuai dengan chain, tetapi suite Marlowe menyertakan alat-alat untuk mengevaluasi risiko ini. Alat-alat ini harus digunakan sebelum menerapkan kontrak
Validasi Transaksi
Dua jenis skrip validator Plutus terlibat dalam validasi pengeluaran UTXO:
- Validator Semantik
- Validator Payout
Praktik keamanan menentukan bahwa transaksi tidak boleh ditandatangani kecuali isi dan implikasi transaksi telah ditinjau dan dipahami dengan baik. Di lingkungan Marlowe, hal ini berarti memverifikasi kontrak Marlowe, masukan (input), dan statusnya. Ini juga berarti memastikan bahwa peran minting policy (jika ada) dan validator Marlowe yang digunakan adalah yang benar.
Pertimbangan keamanan berikut berlaku untuk kedua jenis skrip validator.
Validator Semantik
Konsep-konsep berikut harus dipahami dengan baik sebelum menandatangani transaksi Marlowe:
- Apakah transaksi mengoperasikan kontrak Marlowe?
- Apakah peran minting policy (jika ada)?
- Bagaimana role token telah didistribusikan (jika ada)?
- Apakah kontrak saat ini dan statusnya?
- Masukan apa yang diterapkan pada kontrak?
- Apa lagi yang terjadi dalam transaksi?
Apakah transaksi mengoperasikan kontrak Marlowe?
Skrip validator Plutus adalah interpreter universal untuk semua kontrak Marlowe dari versi yang ditentukan, yang berarti UTXO untuk kontrak Marlowe berada di hash skrip. Memverifikasi bahwa sebuah transaksi mengeluarkan dari alamat yang memiliki hash skrip Marlowe sebagai bagian pembayaran mengkonfirmasi bahwa validator Marlowe asli akan berjalan untuk memvalidasi pengeluaran dari UTXO tertentu itu. Dapat dihitung hash skrip validator Marlowe dari dasar-dasar pertama dengan mengkompilasi validator dan menghitung hash-nya, dengan asumsi bahwa kode sumber skrip Marlowe di repositori ini dapat dipercaya.
Apa perannya minting policy (jika ada)?
Kebijakan pencetakan (minting policy) adalah kumpulan aturan untuk penciptaan token dari tipe token tertentu, yang diidentifikasi dengan hash dari kebijakan pencetakan tersebut. Ini dikenal sebagai ID kebijakan pencetakan. Kebijakan pencetakan menentukan apakah token baru dapat dibuat, atau apakah token yang telah dibuat adalah semua token yang akan ada.
Misalnya, pihak-pihak yang terlibat dalam kontrak Marlowe, seperti pemberi pinjaman dan peminjam, dapat diwakili dengan dua cara:
- Dengan alamat: setiap pihak dari tipe alamat sesuai dengan contoh pasangan dari kunci publik dan kunci pribadi yang mungkin dipegang oleh dompet salah satu pihak. Menggunakan alamat untuk mewakili pihak lebih sederhana dan lebih murah daripada menggunakan peran. Untuk mengautentikasi diri, pihak yang diwakili oleh alamat hanya perlu menandatangani transaksi yang memerlukan mereka untuk diotentikasi (misalnya transaksi yang melakukan deposit atau pilihan untuk pihak tersebut).
- Dengan token peran (role token): setiap pihak dari tipe peran sesuai dengan token yang disimpan di blockchain. Agar kontrak dapat menggunakan token peran sebagai otorisasi, kontrak perlu menyatakan bahwa ID kebijakan pencetakan token perannya adalah ID kebijakan pencetakan dari token yang ingin digunakan sebagai token peran. Dalam hal ini, masing-masing dari nama-nama aset token yang diidentifikasi dengan ID kebijakan pencetakan mewakili pihak yang berbeda. Untuk mengotentikasi transaksi, pemilik token peran hanya perlu menyertakannya sebagai bagian dari transaksi yang memerlukan otorisasi dari pemilik token peran. Potensialnya, ada lebih dari satu token dengan nama aset yang sama, sehingga secara teknis Anda tidak benar-benar memiliki pihak peran kecuali Anda memiliki semua contoh dari token peran yang memiliki nama aset pihak tersebut.
Bagaimana role token didistribusikan?
Jika sebuah kontrak hanya menggunakan alamat untuk mewakili pihak-pihak, kebijakan pencetakan untuk peran tidak menjadi masalah. Kelemahan dari alamat adalah bahwa mereka tidak dapat ditransfer secara dapat dipertanggungjawabkan, sehingga begitu kunci pribadi untuk suatu alamat diketahui, Anda tidak dapat menunjukkan bahwa Anda telah lupa dan menghapusnya. Dari perspektif penerima alamat, alamat selalu tidak aman. Satu-satunya cara untuk memiliki alamat yang aman adalah dengan menghasilkannya sendiri.
Keuntungan dari peran adalah bahwa, karena token diperlakukan sebagai aset asli di jaringan, mereka dapat ditransfer seperti ada atau aset lainnya. Namun, siapa pun yang memiliki token dengan ID kebijakan pencetakan yang tepat dan nama aset yang cocok dapat bertindak sebagai pihak yang diwakilinya, sehingga Anda perlu memastikan bahwa Anda adalah satu-satunya yang memiliki token tersebut, jika tidak Anda tidak benar-benar mengendalikan pihak tersebut.
Tentu saja, Anda dapat memastikan bahwa Anda adalah satu-satunya yang memiliki token tersebut dengan mencetak (minting) token peran tersebut sendiri (Marlowe Runtime melakukan ini dengan aman sebagai bagian dari proses pembuatan kontrak). Jika orang lain mencetak token peran atau membuat kontrak tersebut, Anda perlu memastikan bahwa:
- Anda memiliki semua token yang ada yang mengontrol pihak tersebut
- Tidak ada lagi token semacam itu yang dapat dibuat (karena kebijakan pencetakan tidak mengizinkannya)
Jika kebijakan pencetakan cukup sederhana, cara termudah untuk memeriksa hal ini adalah dengan menggunakan pemindai Marlowe untuk mengetahui ID kebijakan pencetakan peran kontrak. Kemudian, gunakan penjelajah Cardano untuk memeriksa kebijakan di balik kebijakan pencetakan (untuk memastikan tidak ada lagi peran yang dapat diproduksi) dan untuk memeriksa distribusi saat ini dari peran-peran yang sudah dicetak (siapa yang memiliki token-tokennya, dengan kata lain).
Apa itu kontrak dan keadaan saat ini?
Keadaan pra-transaksi kontrak didefinisikan dalam Plutus datum yang terkait dengan UTXO yang dihabiskan dari alamat skrip Marlowe. Datum ini harus disediakan dalam transaksi dan harus berisi hal berikut:
- saldo akun-akun internal dari kontrak
- riwayat pilihan yang dibuat hingga saat ini dalam eksekusi kontrak
- nilai-nilai saat ini dari variabel terikat kontrak
- bagian kontrak yang masih harus dieksekusi
Datum ini dapat diekstrak dari isi transaksi yang belum ditandatangani dan didekode menjadi Language.Marlowe.Core.V1.Semantics.MarloweData menggunakan fungsi Plutus.V2.Ledger.Api.fromData.
Alternatif:
- perintah baris
marlowe log --showakan menampilkan riwayat on-chain kontrak. - Alat online ini juga memungkinkan untuk melihat kontrak dan keadaan on-chain
- Sebuah REST API menyediakan informasi yang sama yang diperoleh melalui
marlowe log --show.
Input apa yang diterapkan pada kontrak?
Plutus redeemer yang terkait dengan pengeluaran UTXO dari alamat skrip Marlowe menentukan input yang diterapkan pada kontrak, bersama dengan interval validitas slot untuk transaksi yang ditentukan dalam isi transaksi. Input ini adalah rangkaian deposit, pilihan, dan notifikasi dengan jumlah nol atau lebih. Dengan menggunakan alat seperti Marlowe Playground atau marlowe-cli run prepare, dimungkinkan untuk menganalisis konsekuensi dari penerapan input ini pada kontrak.
Redeemer dapat diekstrak dari isi transaksi yang belum ditandatangani dan didekode menjadi Language.Marlowe.Scripts.MarloweInput menggunakan fungsi Plutus.V2.Ledger.Api.fromData. Perintah baris marlowe-cli util slotting akan menghitung hubungan antara slot yang disebutkan dalam interval validitas dengan waktu POSIX dalam kontrak.
Hal apa lagi yang terjadi dalam transaksi?
Transaksi yang belum ditandatangani mungkin berisi pengeluaran dan pembayaran lain selain yang ditentukan untuk kontrak Marlowe. Hal ini dapat diperiksa dengan alat cardano-cli transaction view.
Kebijakan moneter
Umumnya, kebijakan moneter (seperti yang didukung dalam Marlowe Runtime) yang memberlakukan satu peristiwa pencetakan dan satu token untuk setiap peran sebaiknya digunakan. Kebijakan ini memastikan bahwa token peran adalah true non-fungible tokens (NFTs), sehingga pemegang token peran dapat diverifikasi sebagai satu-satunya pihak yang dapat bertindak sebagai pihak-pihak dalam kontrak.
Kebijakan moneter yang mencetak beberapa salinan token peran tertentu, atau kebijakan dengan kebijakan pencetakan terbuka, mendukung kasus penggunaan yang tidak standar. Misalnya, mencetak dua salinan setiap token peran dan mendistribusikannya ke pihak yang sama memungkinkan pihak tersebut menyimpan satu token dalam penyimpanan dingin sebagai cadangan jika dompet yang berisi token peran ‘aktif’ tidak dapat diakses. Beberapa kontrak crowdsourcing yang baru mungkin melibatkan penugasan peran (melalui token peran identik yang dapat dicetak bahkan setelah kontrak dimulai) kepada banyak peserta. Akhirnya, kebijakan pencetakan kontrak Plutus untuk token peran dapat berkoordinasi dengan operasi satu atau lebih kontrak Marlowe.
Token peran
Token peran dapat memberi izin untuk deposit dan pilihan dalam transaksi Marlowe. Memberikan izin menggunakan token peran lebih fleksibel daripada memberi izin dengan kunci publik, karena token peran (dan oleh karena itu partisipasi dalam kontrak Marlowe) dapat ditransfer antara dompet atau ke orang lain.
Skrip validator Marlowe tidak memberlakukan kebijakan moneter tertentu untuk token peran, untuk memungkinkan penggunaan kasus baru. Namun, keamanan otorisasi dalam kontrak Marlowe berbasis peran sangat bergantung pada kebijakan moneter token peran. Ini berarti bahwa baik kebijakan moneter maupun pencairan token di rantai harus diperiksa dengan cermat sebelum berpartisipasi dalam kontrak Marlowe. Memverifikasi kebijakan moneter dari skrip sederhana melibatkan pengambilan skrip dari blockchain dan mempelajarinya. Memverifikasi kebijakan moneter dari skrip Plutus melibatkan memperoleh dan mempelajari kode sumber Plutus untuk skrip dan menghash kode sumber untuk memeriksa ID kebijakan moneter.