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

Penulis: @Web3Mario（_mario）

Ringkasan: Meneruskan artikel sebelumnya tentang pengenalan teknologi TON, saya telah melakukan penelitian mendalam tentang dokumen pengembangan resmi TON selama periode ini. Saya merasa bahwa mempelajarinya masih agak sulit karena 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 pengalaman belajar saya sendiri, dengan harapan dapat membantu Anda memahami pengembangan TON DApp dengan cepat. Jika ada kesalahan dalam penulisan, saya sangat mengharapkan koreksi dari semua orang. Mari kita belajar bersama.

Apa Perbedaan Antara Mengembangkan NFT di EVM dan Mengembangkan NFT di TON Chain

Menerbitkan FT atau NFT biasanya merupakan kebutuhan paling dasar bagi pengembang DApp. Oleh karena itu, saya juga menggunakannya sebagai titik awal pembelajaran. Pertama-tama, 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 yang unik. Sedangkan ERC-721 adalah paradigma pengembangan umum untuk jenis aset ini. Mari kita lihat fungsi-fungsi apa yang perlu diimplementasikan oleh kontrak ERC721 yang umum dan informasi apa yang perlu dicatat. Gambar di bawah ini adalah antarmuka ERC721. Anda dapat melihat bahwa berbeda dengan FT, antarmuka transfer menuntut input tokenId yang akan ditransfer daripada jumlah. TokenId ini juga merupakan bentuk dasar dari keunikan aset NFT, dan tentu saja, untuk membawa lebih banyak atribut, biasanya setiap tokenId akan mencatat metadata, yang merupakan tautan eksternal yang menyimpan data yang dapat diperluas dari NFT tersebut, seperti tautan gambar PFP, beberapa nama atribut, dan sebagainya.

Bagi pengembang yang terbiasa dengan Solidity atau berpengalaman dalam pemrograman berorientasi objek, mengimplementasikan smart contract semacam ini adalah hal yang mudah, asalkan tipe data yang diperlukan dalam kontrak didefinisikan dengan baik, seperti beberapa hubungan pemetaan kunci, dan logika modifikasi data yang sesuai dengan fungsi yang diperlukan dikembangkan, maka NFT dapat diimplementasikan.

Namun, di TON Chain, semuanya menjadi agak berbeda, disebabkan oleh dua alasan inti yang berbeda:

• Penyimpanan data dalam TON didasarkan pada Sel, sementara Sel dalam akun yang sama diimplementasikan melalui Graf Berarah dan Tak Berlingkar. Hal ini menyebabkan data yang perlu disimpan dalam waktu yang lama tidak dapat terus tumbuh tanpa batas, karena dalam hal Graf Berarah dan Tak Berlingkar, kedalaman data menentukan biaya kueri, dan ketika kedalaman terus diperluas tanpa batas, dapat menyebabkan biaya kueri yang terlalu tinggi, yang pada gilirannya dapat menyebabkan kontrak mengalami masalah mati suri.
• Untuk mencapai kinerja yang tinggi dalam hal keterlibatan, TON mengabaikan arsitektur eksekusi serial dan beralih ke paradigma pengembangan yang didesain khusus untuk paralelisme, yaitu Model Aktor, untuk membangun kembali lingkungan eksekusi. Ini mengakibatkan satu dampak, yaitu kontrak pintar hanya dapat saling memanggil secara asinkron melalui pengiriman pesan internal. Perlu diketahui bahwa baik panggilan yang mengubah status maupun panggilan tipe hanya membaca harus mengikuti prinsip ini. Selain itu, perlu dipertimbangkan dengan seksama bagaimana menangani rollback data jika panggilan asinkron gagal.

Tentu saja, tentang perbedaan teknis lainnya telah dijelaskan secara rinci dalam artikel sebelumnya, artikel ini berfokus pada pengembangan smart contract, jadi tidak akan membahasnya lebih lanjut. Prinsip desain di atas membuat pengembangan smart contract di TON sangat berbeda dengan EVM. Dalam pembahasan awal, kita tahu bahwa kontrak NFT perlu mendefinisikan beberapa pemetaan, yaitu mapping, untuk menyimpan data terkait NFT. Salah satu yang paling penting adalah owners, pemetaan ini menyimpan pemetaan antara alamat pemilik NFT dengan tokenID tertentu, yang menentukan kepemilikan NFT tersebut. Transfer adalah modifikasi kepemilikan tersebut. Karena secara teoritis ini adalah struktur data tanpa batas, perlu dihindari sebisa mungkin. Oleh karena itu, disarankan oleh pihak resmi untuk menggunakan kriteria pemecahan masalah sebagai acuan keberadaan struktur data tanpa batas. Artinya, ketika ada kebutuhan penyimpanan data serupa, digantikan dengan paradigma kontrak induk-anak, dengan menciptakan subkontrak untuk mengelola data yang sesuai dengan setiap kunci. Dan menggunakan kontrak induk untuk mengelola parameter global atau membantu memproses interaksi informasi internal antara subkontrak.

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

Setelah arsitektur ditetapkan, langkah selanjutnya adalah menyelesaikan kebutuhan dari fitur inti. Karena menggunakan kontrak induk-anak, perlu ditentukan fungsi mana yang akan ditangani oleh kontrak induk, fungsi mana yang akan ditangani oleh kontrak anak, dan bagaimana komunikasi internal antara keduanya dilakukan. Selain itu, jika terjadi kesalahan eksekusi, perlu dipertimbangkan bagaimana data sebelumnya dapat digulirkan kembali. Biasanya, sebelum mengembangkan proyek besar dan kompleks, membuat diagram kelas dan menetapkan aliran informasi antara kelas-kelas tersebut, serta mempertimbangkan logika penggulungan kembali setelah gagalnya pemanggilan internal, adalah langkah yang perlu dilakukan. Tentu saja, meskipun pengembangan NFT di atas sederhana, langkah serupa juga dapat dilakukan untuk memverifikasi.

Belajar Mengembangkan Kontrak Cerdas TON dari Kode Sumber

TON memilih untuk mendesain bahasa pengembangan kontrak pintar yang mirip dengan bahasa C, dengan tipe statis yang disebut Func. Mari kita pelajari bagaimana mengembangkan kontrak pintar TON dari kode sumber. Saya akan menggunakan contoh NFT dari dokumen resmi TON untuk menjelaskannya. Jika Anda tertarik, Anda dapat mencarinya sendiri. Dalam contoh ini, terdapat sebuah kontrak TON NFT sederhana. Mari kita lihat struktur kontraknya, terdiri dari dua kontrak fungsi dan tiga pustaka yang diperlukan.

Dua kontrak fungsi utama ini dirancang berdasarkan prinsip di atas, pertama-tama mari kita lihat kode kontrak utama nft-collection:

Ini memperkenalkan poin pengetahuan pertama, bagaimana menyimpan data secara persisten dalam kontrak pintar TON. Kita tahu bahwa dalam Solidity, penyimpanan data yang persisten ditangani secara otomatis oleh EVM berdasarkan tipe parameter. Biasanya, variabel status kontrak pintar akan secara otomatis disimpan secara persisten setelah eksekusi selesai berdasarkan nilai terbaru, pengembang tidak perlu memikirkan proses ini. Namun, dalam Func, situasinya berbeda, pengembang perlu mengimplementasikan logika penanganan yang sesuai sendiri. Situasi ini sedikit mirip dengan pemikiran GC dalam C dan C++, tetapi bahasa pengembangan baru lainnya biasanya mengotomatisasi logika ini. Mari kita lihat kode, pertama-tama memperkenalkan beberapa pustaka yang diperlukan, lalu kita melihat fungsi pertama load_data digunakan 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, biasanya beberapa fungsi di dalamnya dapat digunakan sebagai fungsi sistem.

Jenis nilai kembalian fungsi ini adalah sel, yaitu jenis sel dalam TVM. Dalam pengenalan sebelumnya, kita sudah tahu bahwa semua data persisten dalam Blockchain TON disimpan dalam pohon sel. Setiap sel dapat memiliki maksimal 1023 bit data sembarang dan maksimal empat referensi ke sel lainnya. Sel digunakan sebagai memori dalam TVM berbasis tumpukan. Sel menyimpan data yang dienkripsi rapat, untuk mendapatkan data plaintext yang spesifik, sel perlu dikonversi menjadi jenis yang disebut slice. Sel dapat diubah menjadi jenis slice melalui fungsi begin_parse, kemudian data bit dan referensi ke sel lainnya dapat dimuat dari slice untuk mendapatkan data dalam sel. Perhatikan bahwa pemanggilan dalam baris 15 adalah gula sintaksis di dalam func, yang memungkinkan pemanggilan langsung ke fungsi kedua dari nilai kembalian fungsi pertama. Dan akhirnya, data yang sesuai dimuat secara berurutan sesuai dengan urutan persistensi data. Perhatikan bahwa proses ini berbeda dengan solidity, bukan berdasarkan pemanggilan hashmap, oleh karena itu urutan pemanggilan ini tidak boleh sembarangan.

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

Selanjutnya, mari kita lihat fungsi terkait bisnis, pertama-tama perlu memperkenalkan satu poin pengetahuan, yaitu bagaimana membuat kontrak baru melalui kontrak, ini akan sering digunakan dalam arsitektur master-slave yang baru saja diperkenalkan. Kita tahu bahwa dalam TON, panggilan antara kontrak cerdas dilakukan melalui pengiriman pesan internal. Ini dilakukan melalui fungsi yang disebut send_raw_message, dengan catatan bahwa parameter pertama adalah sel yang dienkripsi pesan, parameter kedua adalah tanda yang menunjukkan perbedaan dalam cara eksekusi transaksi ini, TON mengatur berbagai cara eksekusi pengiriman pesan internal, saat ini ada 3 mode pesan dan 3 flag pesan. Anda dapat menggabungkan satu mode dengan beberapa (mungkin tidak ada) flag untuk mendapatkan mode yang diinginkan. Kombinasi hanya berarti mengisi nilai-nilai mereka dan menambahkannya. Berikut adalah tabel deskripsi Mode dan Flag:

Jadi mari kita lihat fungsi utama pertama, deploy_nft_item, seperti namanya, ini adalah fungsi untuk membuat atau mencetak contoh NFT baru, setelah melakukan beberapa operasi encoding msg, mengirim kontrak internal ini melalui send_raw_message dan memilih flag 1 sebagai tanda pengiriman, hanya menggunakan biaya gas yang ditentukan dalam encoding sebagai biaya gas eksekusi kali ini. Berdasarkan penjelasan sebelumnya, kita dengan mudah menyadari bahwa aturan encoding ini harus sesuai dengan cara membuat kontrak pintar baru. Jadi mari kita lihat bagaimana hal ini diimplementasikan.

Mari kita langsung melihat baris 51, dua fungsi di atas adalah fungsi bantu untuk menghasilkan informasi yang diperlukan untuk pesan, jadi kita akan melihatnya nanti, ini adalah proses pengkodean pesan internal untuk membuat smart contract, beberapa angka di tengah-tengah sebenarnya adalah tanda identifikasi untuk menjelaskan kebutuhan pesan internal ini, di sini kita akan memperkenalkan satu lagi poin pengetahuan, TON memilih bahasa biner bernama TL-B untuk menggambarkan cara eksekusi pesan, dan menggunakan tanda identifikasi yang berbeda untuk mengimplementasikan fungsi khusus pesan internal, dua skenario penggunaan yang paling umum adalah pembuatan kontrak baru dan panggilan fungsi kontrak yang telah dideploy. Sedangkan cara ini pada baris 51 sesuai dengan yang pertama, yaitu membuat kontrak item nft baru, yang utamanya ditentukan oleh baris 55, 56, 57. Pertama, deretan angka panjang ini adalah serangkaian tanda identifikasi, perhatikan bahwa parameter pertama dari store_uint adalah nilai, sedangkan parameter kedua adalah panjang bit, yang menentukan bahwa pesan internal ini adalah pembuatan kontrak dengan tiga tanda identifikasi terakhir, dan nilai biner yang sesuai adalah 111 (dalam desimal, 4+2+1), di mana dua yang pertama menunjukkan bahwa pesan ini akan dilengkapi dengan data StateInit, yang merupakan kode sumber kontrak baru dan data inisialisasi yang diperlukan. Sedangkan tanda identifikasi terakhir menunjukkan pesan internal terlampir, yaitu ingin mengeksekusi logika terkait dan argumen yang diperlukan. Oleh karena itu, Anda akan melihat bahwa pada baris kode 66 tidak ada pengaturan tiga data ini, yang berarti ini adalah panggilan fungsi kontrak yang telah dideploy. Aturan pengkodean yang lebih spesifik dapat dilihat di sini.

Jadi aturan encoding StateInit sesuai dengan baris kode 49, dihitung melalui calculate_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 perlu disesuaikan 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 ERC721, serta alamat kontrak saat ini yang dikembalikan oleh fungsi standar my_address, yaitu collection_address, urutan data ini sesuai dengan deklarasi nft-item.

Selanjutnya, satu titik pengetahuan adalah bahwa dalam TON, semua kontrak pintar yang belum dibuat dapat dihitung terlebih dahulu alamatnya setelah dibuat, ini mirip dengan fungsi create2 dalam Solidity, di TON, pembuatan alamat baru terdiri dari dua bagian, yaitu bit tanda workchain dan nilai hash stateinit, yang pertama adalah sesuatu yang kita ketahui sebelumnya dari pengantar TON yang tak terbatas pada arsitektur Sharding yang perlu ditentukan, saat ini nilainya seragam. Diperoleh dari fungsi standar workchain. Yang terakhir diperoleh dari fungsi standar cell_hash. Oleh karena itu, kembali ke contoh ini, calculate_nft_item_address adalah fungsi untuk menghitung alamat kontrak baru secara prates, dan nilai yang dihasilkan dienkripsi pada baris 53 ke dalam pesan sebagai alamat penerima pesan internal ini. Sedangkan nft_content sesuai dengan panggilan inisialisasi kontrak yang dibuat, implementasinya akan dijelaskan dalam artikel berikutnya.

Untuk send_royalty_params, itu harus menjadi respons pesan internal untuk permintaan baca saja. Sebelumnya, kami dengan sengaja menekankan bahwa dalam TON, pesan internal tidak hanya mencakup operasi yang mungkin mengubah data, tetapi juga operasi baca harus diimplementasikan melalui cara ini. Oleh karena itu, kontrak ini adalah untuk operasi semacam itu. Pertama-tama yang perlu diperhatikan adalah penanda pada baris 67 yang menunjukkan callback function kepada peminta setelah permintaan. Kemudian adalah data yang dikembalikan, yaitu indeks item permintaan dan data royalti yang sesuai.

Selanjutnya, mari kita perkenalkan satu titik pengetahuan berikutnya, kontrak pintar di TON hanya memiliki dua titik masuk yang seragam, yang disebut recv_internal dan recv_external, di mana yang pertama adalah titik panggilan seragam untuk semua pesan internal, dan yang kedua adalah titik panggilan seragam untuk semua pesan eksternal, pengembang perlu di dalam fungsi menanggapi permintaan yang berbeda berdasarkan kebutuhan, dengan cara yang mirip dengan switch berdasarkan bit tanda yang berbeda yang ditentukan oleh pesan, di mana bit tanda di sini adalah tanda panggilan fungsi pada baris 67 di atas. Kembali ke contoh ini, pertama-tama melakukan pemeriksaan kekosongan pesan, setelah itu menganalisis informasi dalam pesan, pertama-tama pada baris 83 menganalisis dan mendapatkan alamat pengirim, parameter ini akan digunakan untuk pemeriksaan izin selanjutnya, perhatikan operator ~ di sini, ini adalah gula sintaksis yang berbeda. Mari kita tidak membahas ini terlebih dahulu. Selanjutnya, analisis bit tanda operasi op, dan kemudian berdasarkan bit tanda yang berbeda, memproses permintaan yang sesuai. Di antaranya, berdasarkan beberapa logika, memanggil fungsi di atas. Misalnya, merespons permintaan untuk parameter royalti, atau mencetak nft baru, dan meningkatkan indeks global secara otomatis.

Poin pengetahuan berikutnya mengacu pada baris 108, saya yakin semua orang dapat memahami logika pemrosesan fungsi ini melalui namanya. Mirip dengan fungsi require dalam Solidity, dalam Func, pengecualian dilemparkan melalui fungsi standar throw_unless, dengan argumen pertama sebagai kode kesalahan, dan argumen kedua adalah nilai boolean yang diperiksa. Jika nilai adalah false, maka pengecualian dilemparkan dengan kode kesalahan tersebut. Pada baris ini, equal_slices digunakan untuk memeriksa apakah sender_address yang telah diuraikan sebelumnya sama dengan owner_address yang disimpan secara persisten dalam kontrak ini, untuk melakukan pengecekan izin.

Akhirnya, untuk membuat struktur kode lebih jelas, mulailah dengan serangkaian fungsi bantuan untuk mendapatkan informasi persisten, yang tidak akan dijelaskan di sini, pengembang dapat merujuk pada struktur ini untuk mengembangkan kontrak pintar mereka sendiri.

Pengembangan DApp di ekosistem TON adalah hal yang sangat menarik, dengan pola pengembangan EVM yang sangat berbeda, sehingga saya akan memperkenalkan cara membangun DApp di TON Chain melalui serangkaian artikel. Mari belajar bersama dan manfaatkan peluang ini. Saya juga mengundang teman-teman untuk berinteraksi dengan saya di Twitter dan mengusulkan ide DApp yang menarik untuk dikembangkan bersama-sama.