Panduan Pengembangan Proyek TON (Bagian 1): Melihat Kode Sumber Bagaimana Membuat NFT di TON Chain

Penulis asli: @Web3 Mario (_mario)

Meneruskan artikel sebelumnya tentang pengenalan teknologi TON, pada periode ini saya telah melakukan penelitian mendalam tentang dokumen pengembangan resmi TON. Saya merasa bahwa mempelajarinya masih memiliki beberapa hambatan, konten dokumen saat ini tampaknya lebih seperti dokumen pengembangan internal yang kurang ramah bagi pengembang pemula. Oleh karena itu, saya mencoba menyusun serangkaian artikel tentang pengembangan proyek TON Chain berdasarkan jejak belajar saya sendiri, dengan harapan dapat membantu Anda memulai pengembangan TON DApp dengan cepat. Jika ada kesalahan dalam penulisan, silakan beri tahu saya agar kita dapat belajar bersama.

Apa perbedaan antara mengembangkan NFT di EVM dan mengembangkan NFT di TON Chain

Menerbitkan sebuah FT atau NFT biasanya merupakan kebutuhan dasar bagi pengembang DApp. Oleh karena itu, saya menganggap ini sebagai titik awal untuk belajar. Pertama, mari kita pahami perbedaan antara mengembangkan NFT dalam tumpukan teknologi EVM dan di TON Chain. NFT berbasis EVM biasanya akan memilih untuk mewarisi standar ERC-721. NFT merujuk pada jenis aset enkripsi yang tidak dapat dibagi, dan setiap aset memiliki keunikan, yaitu memiliki beberapa fitur eksklusif. ERC-721 adalah paradigma pengembangan umum untuk jenis aset ini. Mari kita lihat fungsi-fungsi apa saja yang perlu diimplementasikan dalam kontrak ERC-721 yang umum dan informasi apa yang perlu dicatat. Gambar di bawah ini menunjukkan antarmuka ERC-721. Dapat dilihat bahwa berbeda dengan FT, antarmuka transfer memerlukan input tokenId yang akan ditransfer daripada jumlah. TokenId ini juga merupakan manifestasi dasar dari keunikan aset NFT. Tentu saja, untuk membawa lebih banyak atribut, biasanya akan dicatat metadata untuk setiap tokenId, yang merupakan tautan eksternal yang menyimpan data ekstensif lainnya dari NFT tersebut, seperti tautan gambar PFP, beberapa nama atribut, dan sebagainya.

Bagi pengembang yang akrab dengan Solidity atau berpengalaman dalam pemrograman berorientasi objek, mengimplementasikan smart contract semacam ini adalah hal yang mudah, selama mereka mendefinisikan tipe data yang diperlukan dalam kontrak, misalnya hubungan pemetaan kunci-kunci yang penting (mapping), dan mengembangkan logika modifikasi data yang sesuai dengan fungsi yang dibutuhkan, mereka dapat mengimplementasikan NFT.

Namun, di TON Chain, semuanya menjadi sedikit berbeda, ada dua alasan inti yang menyebabkannya berbeda:

• Di TON, penyimpanan data didasarkan pada Cell, dan Cell dari akun yang sama diimplementasikan melalui directed acyclic graph. Ini menyebabkan data yang perlu disimpan tidak dapat berkembang tanpa batas, karena dalam sebuah directed acyclic graph, kedalaman data menentukan biaya kueri. Ketika kedalaman terus berkembang tanpa batas, kemungkinan besar akan menyebabkan biaya kueri yang terlalu tinggi, yang pada akhirnya dapat menyebabkan kontrak mengalami masalah deadlock.
• Untuk mencapai kinerja paralel yang tinggi, TON meninggalkan arsitektur eksekusi serial dan beralih ke paradigma pengembangan yang dirancang khusus untuk paralel, yaitu Model Aktor, untuk membangun ulang lingkungan eksekusi. Ini mengakibatkan satu dampak, yaitu kontrak pintar hanya dapat dipanggil secara asinkron melalui pengiriman pesan internal. Perlu diperhatikan bahwa baik pemanggilan tipe modifikasi status maupun tipe hanya baca harus mengikuti prinsip ini. Selain itu, perlu juga mempertimbangkan bagaimana menangani rollback data jika pemanggilan asinkron gagal.

Tentu saja, ada banyak perbedaan dalam artikel sebelumnya mengenai poin-poin teknis lainnya, tetapi artikel ini akan fokus pada pengembangan kontrak pintar, jadi tidak akan membahas lebih lanjut. Prinsip-prinsip desain di atas membuat pengembangan kontrak pintar di TON sangat berbeda dengan EVM. Dalam pembahasan awal, kita tahu bahwa kontrak NFT perlu mendefinisikan beberapa hubungan pemetaan, yang disebut mapping, untuk menyimpan data terkait NFT. Yang paling penting adalah pemetaan owners, yang menyimpan hubungan antara tokenID tertentu dan alamat pemilik NFT tersebut, yang menentukan kepemilikan NFT tersebut. Transfer adalah modifikasi kepemilikan ini. Karena ini adalah struktur data yang teoritis tak berbatas, ini harus dihindari sebisa mungkin. Oleh karena itu, disarankan oleh pihak resmi untuk menggunakan kriteria pemisahan berdasarkan apakah ada struktur data yang tak berbatas. Jadi, ketika ada kebutuhan penyimpanan data serupa, gunakan pola kontrak utama-dan-anak sebagai pengganti, dengan cara membuat kontrak anak untuk mengelola data setiap kunci. Dan gunakan kontrak utama untuk mengelola parameter global atau membantu dalam interaksi informasi internal antara kontrak anak.

Ini juga berarti bahwa NFT dalam TON perlu menggunakan arsitektur serupa, di mana setiap NFT adalah subkontrak independen yang menyimpan data eksklusif seperti alamat pemilik, metadata, dan dikelola oleh kontrak induk untuk data global seperti nama NFT, simbol, total pasokan, dll.

Setelah arsitektur dijelaskan dengan jelas, langkah selanjutnya adalah menyelesaikan kebutuhan fungsi inti. Karena menggunakan kontrak induk-anak ini, maka perlu jelas fungsi mana yang dibawa oleh kontrak induk, fungsi mana yang dibawa oleh kontrak anak, dan bagaimana informasi internal antara keduanya dikomunikasikan, sambil mempertimbangkan bagaimana mengembalikan data sebelumnya ketika terjadi kesalahan eksekusi. Biasanya, sebelum mengembangkan proyek besar yang kompleks, diagram kelas diperlukan untuk menjelasakan aliran informasi antara mereka dan mempertimbangkan logika rollback ketika panggilan internal gagal. Tentu saja, walaupun pengembangan NFT di atas sederhana, verifikasi serupa dapat dilakukan.

Belajar Mengembangkan Smart Contract TON dari Source Code

TON memilih untuk menggunakan bahasa pemrograman statis bertipe C yang disebut Func sebagai bahasa pengembangan smart contract. Selanjutnya, mari kita pelajari bagaimana mengembangkan smart contract TON dari kode sumber. Saya memilih contoh NFT dari dokumen resmi TON untuk dijelaskan di sini. Jika Anda tertarik, silakan merujuk ke dokumen tersebut. Dalam kasus ini, sebuah contoh sederhana TON NFT diimplementasikan. Mari kita lihat struktur kontraknya, terdiri dari dua kontrak fungsi dan tiga perpustakaan yang diperlukan.

Kontrak fungsi utama kedua ini dirancang sesuai dengan prinsip-prinsip yang disebutkan di atas. Pertama, mari kita lihat kode kontrak utama nft-collection:

Ini memperkenalkan titik pengetahuan pertama, yaitu bagaimana menyimpan data secara persisten dalam smart contract TON. Kita tahu bahwa dalam Solidity, penyimpanan data dilakukan secara otomatis oleh EVM berdasarkan jenis parameter. Biasanya, variabel status smart contract akan secara otomatis disimpan secara persisten setelah eksekusi selesai berdasarkan nilai terbaru, dan pengembang tidak perlu memikirkan proses ini. Namun, dalam Func, situasinya tidak demikian. Pengembang perlu mengimplementasikan logika penanganan yang sesuai sendiri. Situasi ini agak mirip dengan kebutuhan C dan C++ untuk mempertimbangkan proses GC, tetapi bahasa pemrograman baru lainnya biasanya menangani bagian ini secara otomatis. Mari kita lihat kode, pertama-tama kita perkenalkan beberapa pustaka yang diperlukan, lalu kita lihat fungsi pertama load_data untuk membaca data yang disimpan secara persisten. Logikanya adalah pertama-tama mengembalikan sel penyimpanan kontrak persisten melalui get_data, perhatikan bahwa ini diimplementasikan oleh stdlib.fc, dan biasanya beberapa fungsi di dalamnya dapat digunakan sebagai fungsi sistem.

Tipe nilai kembali fungsi ini adalah cell, yang merupakan tipe cell dalam TVM. Seperti yang kita ketahui sebelumnya, semua data persisten dalam Blockchain TON disimpan dalam pohon cell. Setiap cell memiliki maksimal 1023 bit data sembarang dan maksimal empat referensi ke cell lain. Sel dalam TVM berfungsi sebagai memori yang didasarkan pada tumpukan. Data yang tersimpan dalam cell disandikan secara rapat, dan untuk mendapatkan data plaintext yang spesifik, cell harus dikonversi menjadi tipe yang disebut slice. Cell dapat dikonversi menjadi tipe slice melalui fungsi begin_parse, dan kemudian data dalam cell dapat diambil dengan memuat bit data dan referensi ke cell lain dari slice. Perlu diperhatikan bahwa metode panggilan pada baris ke-15 adalah gula sintaksis dalam fungsi, yang dapat memanggil langsung fungsi nilai kembali pertama ke fungsi kedua. Kemudian, data sesuai dengan urutan persistensi akan dimuat secara berurutan. Perhatikan bahwa proses ini berbeda dengan solidity, dan bukan berdasarkan hashmap untuk memanggil, sehingga urutan pemanggilan ini tidak boleh acak.

Dalam fungsi save_data, logikanya mirip, hanya saja ini adalah proses Reverse, yang memperkenalkan titik pengetahuan berikutnya, yaitu jenis builder baru, yang merupakan jenis pembangun sel. Bit data dan referensi ke sel lain dapat disimpan dalam pembangun, kemudian pembangun dapat diakhiri menjadi sel baru. Pertama, buat pembangun dengan fungsi standar begin_cell, dan simpan fungsi terkait secara berurutan melalui fungsi store terkait, perhatikan urutan pemanggilan dalam teks sebelumnya harus tetap sama dengan urutan penyimpanan di sini. Terakhir, selesaikan pembangunan sel baru melalui end_cell, pada saat itu sel tersebut dikelola di memori, dan terakhir melalui set_data lapisan luar, Anda dapat menyelesaikan penyimpanan persisten sel tersebut.

Selanjutnya mari kita lihat fungsi terkait bisnis, pertama-tama perlu memperkenalkan satu titik pengetahuan, yaitu bagaimana membuat kontrak baru melalui kontrak, ini akan sering digunakan dalam arsitektur utama yang baru saja dijelaskan. Kita tahu di TON, panggilan antara smart contract dilakukan melalui pengiriman pesan internal. Ini dilakukan melalui sesuatu yang disebut send_raw_message, perhatikan bahwa parameter pertama adalah sel kode pesan, parameter kedua adalah bit penanda yang digunakan untuk menunjukkan perbedaan dalam cara eksekusi transaksi, TON memperkenalkan beberapa cara eksekusi pesan internal yang berbeda, saat ini ada 3 Mode pesan dan 3 Flags pesan. Anda dapat mengkombinasikan Mode tunggal dengan beberapa (mungkin tidak ada) bendera untuk mendapatkan mode yang diinginkan. Kombinasi hanya berarti menambahkan nilai mereka dan memasukkannya.

Jadi mari kita lihat fungsi utama pertama, deploy_nft_item, seperti namanya, ini adalah fungsi yang digunakan untuk membuat atau mencetak contoh NFT baru, setelah beberapa operasi encoding pesan, kirimkan pesan mentah melalui send_raw_message, dan pilih tanda pengiriman dengan flag 1, hanya biaya yang ditentukan dalam encoding sebagai biaya gas untuk eksekusi ini. Dari penjelasan sebelumnya, kita dengan mudah menyadari bahwa aturan encoding ini seharusnya merupakan cara untuk membuat kontrak pintar baru. Jadi mari kita lihat bagaimana cara kerjanya secara spesifik.

Mari kita langsung melihat baris ke-51, dua fungsi di atas digunakan untuk menghasilkan informasi yang diperlukan untuk pesan, jadi kita akan melihat ini nanti, ini adalah proses enkode pesan internal untuk membuat smart contract, beberapa angka di tengah sebenarnya adalah beberapa bit penanda yang digunakan untuk menjelaskan kebutuhan pesan internal, di sini kita akan memperkenalkan satu poin pengetahuan berikutnya, TON memilih bahasa biner bernama TL-B untuk menggambarkan cara eksekusi pesan, dan berdasarkan penanda yang berbeda untuk mencapai fungsi khusus pesan internal, dua skenario penggunaan yang paling mudah dipikirkan, yaitu penciptaan kontrak baru dan pemanggilan fungsi kontrak yang sudah diimplementasikan. Dan cara dari baris 51 sesuai dengan yang pertama, menciptakan kontrak item nft baru, ini terutama ditentukan oleh 55, 56, 57. Pertama, angka panjang di baris 55 adalah serangkaian bit penanda, perhatikan bahwa argumen pertama dari store_uint adalah nilai, yang kedua adalah panjang bit, di antaranya menentukan bahwa pesan internal ini adalah penciptaan kontrak, adalah tiga bit penanda terakhir, dan nilai bit binernya adalah 111 (dalam desimal adalah 4 + 2 + 1), dua pertama menunjukkan bahwa pesan ini akan membawa data StateInit, data ini adalah kode sumber kontrak baru, dan data yang diperlukan untuk inisialisasi. Sedangkan bit penanda terakhir menunjukkan pesan internal terlampir, yaitu ingin mengeksekusi logika terkait dan parameter yang diperlukan. Karena itu, Anda akan melihat bahwa pada baris 66 kode tidak mengatur tiga bit data tersebut, yang berarti ini adalah pemanggilan fungsi kontrak yang sudah diimplementasikan. Aturan enkode spesifik dapat dilihat di sini.

Maka aturan encoding StateInit sesuai dengan baris kode 49, melalui perhitungan_nft_item_state_init, perhatikan bahwa encoding data stateinit juga mengikuti aturan encoding TL-B yang telah ditetapkan, selain beberapa bit penanda, terutama melibatkan dua bagian kontrak baru code dan juga inisialisasi data. Urutan encoding data harus konsisten dengan urutan penyimpanan sel persisten yang ditentukan oleh kontrak baru. Pada baris 36, dapat dilihat bahwa data inisialisasi memiliki item_index, mirip dengan tokenId dalam ERC 721, dan alamat kontrak saat ini yang dikembalikan oleh fungsi standar my_address, yaitu collection_address, urutan data ini konsisten dengan deklarasi nft-item.

Salah satu titik pengetahuan berikutnya adalah dalam TON, semua kontrak pintar yang belum dibuat dapat dihitung terlebih dahulu alamatnya setelah dibuat, ini mirip dengan fungsi create 2 dalam Solidity. Di TON, pembuatan alamat baru terdiri dari dua bagian, yaitu bit identifikasi workchain dan nilai hash stateinit yang digabungkan, yang pertama adalah sesuatu yang perlu ditentukan untuk arsitektur sharding tak terbatas TON, dan saat ini adalah nilai tunggal. Diperoleh dari fungsi standar workchain. Yang kedua diperoleh dari fungsi standar cell_hash. Oleh karena itu, kembali ke contoh, calculate_nft_item_address adalah fungsi untuk menghitung alamat kontrak baru secara praduga. Dan nilai yang dihasilkan di baris ke-53 dienkripsi ke dalam pesan sebagai alamat penerima pesan internal ini. Sedangkan nft_content sesuai dengan panggilan inisialisasi kontrak yang akan dibuat, detail implementasinya akan dijelaskan dalam artikel berikutnya.

Adapun kirim \ _royalty \ _params, itu perlu menjadi pesan internal yang sesuai dari permintaan hanya-baca, dalam pengantar sebelumnya, kami sengaja menekankan bahwa dalam TON, pesan internal tidak hanya berisi operasi yang dapat mengubah data, tetapi juga operasi hanya-baca perlu diimplementasikan dengan cara ini, sehingga kontrak adalah operasi seperti itu, pertama-tama, perlu dicatat bahwa baris 67 mewakili tanda fungsi pullback pemohon setelah menanggapi permintaan, yang merupakan data yang dikembalikan, yang merupakan item permintaan indeks, dan data royalti yang sesuai.

Selanjutnya mari kita perkenalkan satu lagi titik pengetahuan, di TON, smart contract hanya memiliki dua pintu masuk yang seragam, yang disebut recv_internal dan recv_external, di mana yang pertama adalah pintu masuk panggilan seragam untuk semua pesan internal, yang kedua adalah pintu masuk panggilan seragam untuk semua pesan eksternal, pengembang perlu di dalam fungsi sesuai dengan kebutuhan, gunakan cara yang mirip dengan switch untuk merespons permintaan yang berbeda berdasarkan bit tanda yang berbeda yang ditentukan oleh pesan, di sini bit tanda ini adalah tanda panggilan fungsi kembali di baris 67 yang disebutkan di atas. Kembali ke contoh ini, pertama-tama periksa kekosongan pesan, dan jika lolos, analisis informasi di dalam pesan, pertama-tama pada baris 83, analisis untuk mendapatkan alamat pengirim, parameter ini akan digunakan untuk pemeriksaan izin selanjutnya, perhatikan operator ~ di sini, ini adalah gula sintaksis lainnya. Mari tidak membahas ini dulu. Selanjutnya, analisis bit tanda operasi op, dan kemudian, berdasarkan bit tanda yang berbeda, masing-masing memproses permintaan yang sesuai. Di antaranya, beberapa logika memanggil fungsi-fungsi yang disebutkan sebelumnya. Misalnya, merespons permintaan parameter royalti, atau mencetak NFT baru, dan meningkatkan indeks global.

Selanjutnya, satu titik pengetahuan sesuai dengan 108 baris, tentu saja Anda dapat mengetahui logika pemrosesan fungsi melalui nama, mirip dengan fungsi require di Solidity, Func membuang pengecualian melalui standar throw_unless fungsi, parameter pertama adalah kode kesalahan, dan parameter kedua adalah nilai boolean dari bit pemeriksaan, jika bit false maka buang pengecualian dan lampirkan kode kesalahan. Sedangkan dalam baris ini, equal_slices digunakan untuk memeriksa apakah sender_address yang dianalisis di atas sama dengan owner_address yang disimpan secara persisten dalam kontrak, untuk memeriksa izin.

Akhirnya, untuk membuat struktur kode lebih jelas, beberapa fungsi bantu untuk mendapatkan informasi persisten dimulai, di sini tidak akan dijelaskan secara rinci, pengembang dapat merujuk pada struktur ini untuk mengembangkan kontrak cerdas mereka sendiri.

Mengembangkan DApp di ekosistem TON sangatlah menarik, karena memiliki perbedaan besar dengan paradigma pengembangan EVM. Oleh karena itu, saya akan menjelaskan melalui serangkaian artikel tentang cara mengembangkan DApp di TON Chain. Mari belajar bersama dan manfaatkan kesempatan ini. Juga, saya mengundang kalian untuk berinteraksi dengan saya di twitter dan berbagi ide DApp yang menarik untuk dikembangkan bersama-sama.