Selanjutnya, kami akan mempertimbangkan secara rinci karakteristik utama bahasa Move dan apa perbedaan utamanya dengan bahasa lain yang sudah populer untuk kontrak pintar - Solidity (pada platform Ethereum). Materi ini didasarkan pada studi whitepaper 26 halaman online yang tersedia.
pengenalan
Move adalah bahasa bytecode yang dapat dieksekusi yang digunakan untuk mengeksekusi transaksi pengguna dan kontrak pintar. Harap perhatikan dua poin:
- Sementara Move adalah bahasa bytecode yang dapat langsung dieksekusi di mesin virtual Move, Solidity (bahasa kontrak pintar Ethereum) adalah bahasa tingkat tinggi yang pertama kali dikompilasi ke dalam bytecode sebelum dieksekusi pada EVM (Ethereum Virtual Machine ).
- Move dapat digunakan tidak hanya untuk mengimplementasikan kontrak pintar, tetapi juga untuk transaksi khusus (lebih lanjut tentang ini nanti), sementara Solidity adalah bahasa khusus kontrak pintar.
Penerjemahan dilakukan oleh tim proyek Protokol INDEX. Kami sudah menerjemahkannya , sekarang saatnya melihat bahasa Move lebih detail. Penerjemahan dilakukan bersama dengan Habrauser
Fitur utama Move adalah kemampuan untuk menentukan jenis sumber daya khusus dengan semantik berdasarkan logika linier: sumber daya tidak pernah dapat disalin atau dihapus secara implisit, hanya dipindahkan. Secara fungsional, ini mirip dengan kemampuan bahasa Rust. Nilai di Rust hanya dapat ditetapkan ke satu nama dalam satu waktu. Menetapkan nilai ke nama yang berbeda membuatnya tidak tersedia dengan nama sebelumnya.
Misalnya, cuplikan kode berikut akan memunculkan kesalahan: Penggunaan nilai yang dipindahkan 'x'. Ini karena tidak ada pengumpulan sampah di Rust. Ketika variabel keluar dari ruang lingkup, memori yang mereka rujuk juga dibebaskan. Sederhananya, hanya ada satu "pemilik" data. Dalam contoh ini x adalah pemilik asli dan kemudian y menjadi pemilik baru. .
Representasi aset digital dalam sistem terbuka
Ada dua properti aset fisik yang sulit direpresentasikan secara digital:
- Rarity (Kelangkaan, awalnya kelangkaan). Jumlah aset (emisi) dalam sistem harus dikendalikan. Duplikasi aset yang ada harus dilarang, dan membuat yang baru adalah operasi istimewa.
- Kontrol akses... Peserta sistem harus dapat melindungi aset menggunakan kebijakan kontrol akses.
Kedua karakteristik ini, yang alami untuk aset fisik, harus diterapkan untuk objek digital jika kita ingin menganggapnya sebagai aset. Misalnya, logam langka memiliki kelangkaan alami, dan hanya Anda yang memiliki akses ke sana (memegangnya, misalnya) dan Anda dapat menjual atau membelanjakannya.
Untuk mengilustrasikan bagaimana kita sampai pada dua sifat ini, mari kita mulai dengan kalimat berikut:
Saran #1: Aturan Paling Sederhana Tanpa Kelangkaan dan Kontrol Akses
- G [K]: = n menunjukkan pembaruan ke nomor yang dapat diakses oleh kunci Π dalam keadaan global blockchain, dengan makna baru n.
- transaksi Alice, 100β© berarti mengatur saldo akun Alice menjadi 100.
Solusi di atas memiliki beberapa masalah utama:
- Alice dapat menerima jumlah koin yang tidak terbatas hanya dengan mengirim transaksi Alice, 100β©.
- Koin yang Alice kirim ke Bob tidak berguna, karena Bob bisa mengirim sendiri koin dalam jumlah tak terbatas menggunakan teknik yang sama.
Saran #2: Memperhitungkan defisit
Sekarang kami memantau situasi sehingga jumlah koin Ka setidaknya sama n sebelum transaksi transfer. Namun, sementara ini memecahkan masalah kelangkaan, tidak ada informasi tentang siapa yang dapat mengirim koin Alice (untuk saat ini, siapa pun dapat melakukan ini, hal utama adalah tidak melanggar aturan membatasi jumlah).
Proposal # 3: Menggabungkan kelangkaan dan kontrol akses
Kami memecahkan masalah ini dengan mekanisme tanda tangan digital verifikasi_sig sebelum memeriksa saldo, yang berarti Alice menggunakan kunci pribadinya untuk menandatangani transaksi dan mengonfirmasi bahwa dia adalah pemilik koinnya.
Bahasa pemrograman Blockchain
Bahasa blockchain yang ada menghadapi masalah berikut (semuanya diselesaikan di Move (catatan: sayangnya, penulis artikel hanya menarik Ethereum dalam perbandingannya, jadi ada baiknya mengambilnya hanya dalam konteks ini. Misalnya, sebagian besar hal berikut juga diselesaikan di EOS.)):
Representasi tidak langsung dari aset. Aset dikodekan menggunakan bilangan bulat, namun bilangan bulat tidak sama dengan aset. Faktanya, tidak ada jenis atau nilai yang mewakili Bitcoin/Ether/<Koin Apa Pun>! Hal ini membuat penulisan program yang menggunakan aset menjadi sulit dan rawan kesalahan. Pola seperti meneruskan aset ke/dari prosedur atau menyimpan aset dalam struktur memerlukan dukungan khusus dari bahasa tersebut.
Defisit tidak dapat diperluas... Bahasa hanya mewakili satu aset yang langka. Selain itu, solusi terhadap kelangkaan tertanam langsung ke dalam semantik bahasa itu sendiri. Pengembang, jika ingin membuat aset khusus, harus mengontrol sendiri semua aspek sumber daya dengan hati-hati. Ini persis masalah kontrak pintar Ethereum.
Pengguna mengeluarkan aset mereka, token ERC-20, menggunakan bilangan bulat untuk menentukan nilai dan total pasokan. Setiap kali token baru dibuat, kode kontrak pintar harus secara independen memverifikasi kepatuhan terhadap aturan emisi. Selain itu, penyajian aset secara tidak langsung menyebabkan, dalam beberapa kasus, kesalahan serius - duplikasi, pengeluaran ganda, atau bahkan kehilangan aset sepenuhnya.
Kurangnya kontrol akses yang fleksibel... Satu-satunya kebijakan kontrol akses yang digunakan saat ini adalah skema tanda tangan menggunakan kriptografi asimetris. Seperti perlindungan kelangkaan, kebijakan kontrol akses sangat tertanam dalam semantik bahasa. Tetapi bagaimana memperluas bahasa untuk memungkinkan pemrogram untuk menentukan kebijakan kontrol akses mereka sendiri seringkali merupakan tugas yang sangat rumit.
Hal ini juga berlaku pada Ethereum, di mana kontrak pintar tidak memiliki dukungan kriptografi asli untuk kontrol akses. Pengembang harus mengatur kontrol akses secara manual, misalnya menggunakan pengubah onlyOwner.
Meskipun saya penggemar berat Ethereum, saya percaya bahwa properti aset harus didukung secara asli oleh bahasa tersebut untuk tujuan keamanan. Secara khusus, mentransfer Ether ke kontrak pintar melibatkan pengiriman dinamis, yang telah memperkenalkan kelas bug baru yang dikenal sebagai kerentanan re-entrancy. Pengiriman dinamis di sini berarti logika eksekusi kode akan ditentukan pada saat runtime (dinamis) dan bukan pada waktu kompilasi (statis).
Jadi, dalam Soliditas, ketika kontrak A memanggil fungsi dalam kontrak B, kontrak B dapat menjalankan kode yang tidak dimaksudkan oleh pengembang kontrak A, yang dapat mengakibatkan (kontrak A secara tidak sengaja bertindak sebagai kontrak B untuk menarik uang sebelum saldo rekening benar-benar terpotong).
Pindahkan Dasar-dasar Desain Bahasa
Sumber daya tingkat pertama
Pada level tinggi, interaksi antara modul/sumber daya/prosedur dalam bahasa Move sangat mirip dengan hubungan antara kelas/objek dan metode dalam bahasa OOP.
Modul bergerak mirip dengan kontrak pintar di blockchain lain. Modul mendeklarasikan jenis sumber daya dan prosedur yang menentukan aturan untuk membuat, menghancurkan, dan memperbarui sumber daya yang dideklarasikan. Tapi semua ini hanyalah kesepakatan (βjargonβ) Untuk Bergerak. Kami akan mengilustrasikan poin ini nanti.
Keluwesan
Move menambah fleksibilitas pada Libra melalui pembuatan skrip. Setiap transaksi di Libra menyertakan skrip, yang pada dasarnya merupakan prosedur inti transaksi. Skrip dapat melakukan satu tindakan tertentu, misalnya, pembayaran ke daftar penerima tertentu, atau menggunakan kembali sumber daya lain - misalnya, dengan memanggil prosedur yang logika umum ditentukan. Inilah sebabnya mengapa skrip transaksi Pindahkan menawarkan fleksibilitas yang lebih besar. Sebuah skrip dapat menggunakan perilaku satu kali dan berulang, sedangkan Ethereum hanya dapat mengeksekusi skrip yang dapat diulang (memanggil satu metode pada metode kontrak pintar). Alasan mengapa kontrak ini disebut "dapat digunakan kembali" adalah karena fungsi kontrak pintar dapat dijalankan berkali-kali. (catatan: Intinya di sini sangat halus. Di satu sisi, skrip transaksi berupa pseudo-bytecode juga ada di Bitcoin. Di sisi lain, seperti yang saya pahami, Move memperluas bahasa ini, pada kenyataannya, ke tingkat bahasa kontrak pintar yang lengkap.).
keamanan
Format Move yang dapat dieksekusi adalah bytecode, yang, di satu sisi, merupakan bahasa tingkat yang lebih tinggi daripada bahasa rakitan, tetapi tingkatnya lebih rendah dari kode sumber. Bytecode diperiksa saat run-time (on-chain) untuk sumber daya, jenis, dan keamanan memori menggunakan pemverifikasi bytecode, dan kemudian dieksekusi oleh penerjemah. Pendekatan ini memungkinkan Move untuk memberikan keamanan kode sumber, tetapi tanpa proses kompilasi dan kebutuhan untuk menambahkan kompiler ke sistem. Menjadikan Move sebagai bahasa bytecode adalah solusi yang sangat bagus. Itu tidak perlu dikompilasi dari sumber, seperti halnya Solidity, dan tidak perlu khawatir tentang kemungkinan kegagalan atau serangan pada infrastruktur kompiler.
Verifikasi
Kami bertujuan untuk melakukan pemeriksaan semudah mungkin, karena semua ini dilakukan secara on-chain (catatan: online, selama pelaksanaan setiap transaksi, sehingga penundaan apa pun menyebabkan perlambatan seluruh jaringan), namun, pada awalnya desain bahasa siap menggunakan alat verifikasi statis off-chain. Meskipun hal ini lebih disukai, untuk saat ini pengembangan alat verifikasi (sebagai perangkat terpisah) telah ditunda di masa mendatang, dan sekarang hanya verifikasi dinamis pada saat run-time (on-chain) yang didukung.
Modularitas
Modul bergerak menyediakan abstraksi data dan melokalisasi operasi kritis pada sumber daya. Enkapsulasi yang disediakan oleh modul, dikombinasikan dengan perlindungan yang diberikan oleh sistem tipe Move, memastikan bahwa properti yang diatur pada tipe modul tidak dapat dilanggar oleh kode di luar modul. Ini adalah desain abstraksi yang dipikirkan dengan baik, artinya data di dalam kontrak hanya dapat berubah di dalam kerangka kontrak, tetapi tidak di luar.
Pindahkan ikhtisar
Contoh skrip transaksi menunjukkan bahwa tindakan jahat atau ceroboh oleh programmer di luar modul tidak dapat membahayakan keamanan sumber daya modul. Selanjutnya, kita akan melihat contoh bagaimana modul, sumber daya, dan prosedur digunakan untuk memprogram blockchain Libra.
Pembayaran peer-to-peer
Jumlah koin yang ditentukan jumlahnya akan ditransfer dari saldo pengirim ke penerima.
Ada beberapa hal baru di sini (disorot dengan warna merah):
- 0x0: alamat akun tempat modul disimpan
- Currency: nama modul
- Koin: jenis sumber daya
- Nilai koin yang dikembalikan oleh prosedur adalah nilai sumber daya bertipe 0x0.Currency.Coin
- pindah (): nilai tidak dapat digunakan lagi
- salinan(): nilai dapat digunakan nanti
Parsing kode: pada langkah pertama, pengirim memanggil prosedur bernama tarik_dari_pengirim dari modul yang disimpan di 0x0.Mata Uang. Pada langkah kedua, pengirim mentransfer dana ke penerima dengan memindahkan nilai sumber daya koin ke dalam prosedur setoran modul 0x0.Mata Uang.
Berikut tiga contoh kesalahan dalam kode yang akan ditolak melalui pemeriksaan:
Duplikat dana dengan mengubah panggilan bergerak (koin) pada salinan (koin). Sumber daya hanya dapat dipindahkan. Mencoba menduplikasi sejumlah sumber daya (misalnya, dengan menelepon salinan (koin) pada contoh di atas) akan menghasilkan kesalahan saat memeriksa bytecode.
Penggunaan kembali dana dengan menentukan bergerak (koin) Π΄Π²Π°ΠΆΠ΄Ρ . Menambahkan garis 0x0.Currency.deposit (salin (some_other_payee), pindahkan (koin)) misalnya, hal di atas akan memungkinkan pengirim untuk βmenghabiskanβ koin dua kali - pertama kali dengan penerima pembayaran, dan yang kedua dengan beberapa_penerima_lainnya. Ini adalah perilaku yang tidak diinginkan yang tidak mungkin dilakukan dengan aset fisik. Untungnya, Move akan menolak program ini.
Kehilangan dana karena penolakan bergerak (koin). Jika Anda tidak memindahkan sumber daya (misalnya dengan menghapus baris yang berisi bergerak (koin)), kesalahan verifikasi bytecode akan terjadi. Ini melindungi pemrogram Move dari kehilangan dana yang tidak disengaja atau berbahaya.
Modul mata uang
Setiap akun dapat berisi 0 atau lebih modul (ditampilkan sebagai persegi panjang) dan satu atau lebih nilai sumber daya (ditampilkan sebagai silinder). Misalnya, akun di 0x0 berisi modul 0x0.Mata Uang dan nilai jenis sumber daya 0x0.Mata Uang.Koin. Rekening di alamat 0x1 memiliki dua sumber daya dan satu modul; Rekening di alamat 0x2 memiliki dua modul dan satu nilai sumber daya.
Momen nekotori:
- Skrip transaksi bersifat atomik - dijalankan sepenuhnya atau tidak dijalankan sama sekali.
- Modul adalah bagian kode berumur panjang yang dapat diakses secara global.
- Status global disusun sebagai tabel hash, dengan kuncinya adalah alamat akun
- Akun tidak boleh berisi lebih dari satu nilai sumber daya dari jenis tertentu dan tidak lebih dari satu modul dengan nama tertentu (akun di 0x0 tidak dapat berisi sumber daya tambahan 0x0.Mata Uang.Koin atau modul lain bernama Currency)
- Alamat modul yang dideklarasikan adalah bagian dari tipe (0x0.Mata Uang.Koin ΠΈ 0x1.Mata Uang.Koin adalah tipe terpisah yang tidak dapat digunakan secara bergantian)
- Pemrogram dapat menyimpan beberapa contoh sumber daya jenis ini dalam satu akun dengan menentukan sumber daya khusus mereka - (sumber daya TwoCoins {c1: 0x0.Currency.Coin, c2: 0x0.Currency.Coin})
- Anda dapat merujuk ke sumber daya berdasarkan namanya tanpa konflik, misalnya Anda dapat merujuk ke dua sumber daya menggunakan Dua Koin.c1 ΠΈ Dua Koin.c2.
Pengumuman sumber daya koin
Modul bernama Currency dan jenis sumber daya bernama Koin
Momen nekotori:
- Koin adalah struktur dengan satu tipe bidang u64 (Bilangan bulat 64-bit yang tidak ditandatangani)
- Prosedur modul saja Currency dapat membuat atau menghancurkan nilai tipe Koin.
- Modul dan skrip lain hanya dapat menulis atau mereferensikan bidang nilai melalui prosedur publik yang disediakan oleh modul.
Penjualan deposit
Prosedur ini menerima sumber daya Koin sebagai masukan dan menggabungkannya dengan sumber daya Koindisimpan di akun penerima:
- Menghancurkan sumber daya masukan Koin dan mencatat nilainya.
- Menerima tautan ke sumber daya Koin unik yang disimpan di akun penerima.
- Mengubah nilai jumlah Koin dengan nilai yang diteruskan pada parameter saat memanggil prosedur.
Momen nekotori:
- Buka kemasannya, PinjamGlobal - prosedur bawaan
- Membongkar Ini adalah satu-satunya cara untuk menghapus sumber daya bertipe T. Prosedur ini mengambil sumber daya sebagai masukan, menghancurkannya, dan mengembalikan nilai yang terkait dengan bidang sumber daya.
- Pinjam Global mengambil alamat sebagai masukan dan mengembalikan referensi ke instance unik T yang diterbitkan (dimiliki) oleh alamat itu
- &mut Koin ini adalah tautan ke sumber daya Koin
Implementasi penarikan_dari_pengirim
Prosedur ini:
- Mendapat tautan ke sumber daya unik Koin, ditautkan ke akun pengirim
- Mengurangi nilai sumber daya Koin melalui tautan untuk jumlah yang ditentukan
- Membuat dan mengembalikan sumber daya baru Koin dengan saldo yang diperbarui.
Momen nekotori:
- Deposito bisa disebabkan oleh siapa saja, tapi tarik_dari_pengirim hanya memiliki akses ke koin akun pemanggil
- DapatkanTxnSenderAddress mirip dengan pesan.pengirim dalam Soliditas
- TolakKecuali mirip dengan membutuhkan dalam Soliditas. Jika pemeriksaan ini gagal, transaksi dihentikan dan semua perubahan dibatalkan.
- Mengemas ini juga merupakan prosedur bawaan yang membuat sumber daya baru bertipe T.
- Sebaik Membongkar, Mengemas hanya dapat dipanggil di dalam modul tempat sumber daya dijelaskan T
Kesimpulan
Kami memeriksa karakteristik utama bahasa Move, membandingkannya dengan Ethereum, dan juga mengenal sintaks dasar skrip. Terakhir, saya sangat merekomendasikan untuk memeriksanya . Ini mencakup banyak detail mengenai prinsip-prinsip desain bahasa pemrograman, serta banyak tautan bermanfaat.
Sumber: www.habr.com