Tutorial pembangunan projek TON (1): Cara mencipta NFT pada Rantaian TON dari perspektif kod sumber

Abstrak: Berikutan artikel sebelumnya tentang pengenalan teknologi TON, saya telah mengkaji secara mendalam dokumen pembangunan TON sepanjang tempoh ini dokumen pembangunan, yang sesuai untuk pemula Ia tidak begitu mesra kepada pembangun, jadi saya cuba menyusun satu siri artikel tentang pembangunan projek TON Chain berdasarkan trajektori pembelajaran saya sendiri bermula dengan pembangunan TON DApp. Jika terdapat sebarang kesilapan dalam penulisan, anda dialu-alukan untuk membetulkan saya dan belajar bersama.

Apakah perbezaan antara membangunkan NFT dalam EVM dan membangunkan NFT pada Rantaian TON

Mengeluarkan FT atau NFT biasanya merupakan keperluan paling asas untuk pembangun DApp? Jadi saya juga menggunakan ini sebagai pintu masuk untuk belajar. Mula-mula, mari kita fahami perbezaan berikut antara membangunkan NFT dalam tindanan teknologi EVM dan dalam Rantaian TON. NFT berasaskan EVM biasanya memilih untuk mewarisi standard ERC-721. Apa yang dipanggil NFT merujuk kepada jenis aset yang disulitkan yang tidak boleh dibahagikan, dan setiap aset adalah unik, iaitu, ia mempunyai ciri eksklusif tertentu. ERC-721 ialah paradigma pembangunan biasa untuk jenis aset ini. Mari kita lihat apakah fungsi kontrak ERC721 biasa yang perlu dilaksanakan dan maklumat yang direkodkan. Gambar di bawah ialah antara muka ERC721. Ia boleh dilihat bahawa tidak seperti FT, apa yang perlu dimasukkan dalam antara muka pemindahan ialah tokenId yang akan dipindahkan dan bukannya jumlah. TokenId ini juga merupakan manifestasi paling asas bagi keunikan aset NFT Sudah tentu, untuk membawa lebih banyak atribut, metadata biasanya direkodkan untuk setiap tokenId Metadata ini ialah pautan luaran yang menyimpan data berskala NFT, seperti sebagai Pautan ke imej PFP, nama atribut tertentu, dsb.

Bagi pembangun yang biasa dengan Solidity atau biasa dengan berorientasikan objek, adalah mudah untuk melaksanakan kontrak pintar sedemikian asalkan jenis data yang diperlukan dalam kontrak ditentukan, seperti beberapa hubungan pemetaan utama dan berdasarkan yang diperlukan Ia adalah perlu untuk membangunkan logik pengubahsuaian yang sepadan secara berfungsi untuk data ini untuk merealisasikan NFT.

Walau bagaimanapun, ini tidak sama dalam Rantaian TON Terdapat dua sebab utama untuk perbezaan:

• Dalam TON, penyimpanan data adalah berdasarkan Sel, dan Sel akaun yang sama dilaksanakan melalui Rajah Acyclic Terarah. untuk mencapai. Ini bermakna bahawa data yang perlu disimpan tidak boleh berkembang tanpa sempadan, kerana untuk graf akiklik terarah, kos pertanyaan ditentukan oleh kedalaman data Apabila kedalaman meluas tanpa had, kos pertanyaan mungkin terlalu tinggi, membawa kepada Kontrak tersekat dalam masalah kebuntuan.

• Untuk mengejar prestasi konkurensi yang tinggi, TON meninggalkan seni bina pelaksanaan bersiri dan sebaliknya menggunakan paradigma pembangunan yang direka khusus untuk selari, model Aktor, untuk membina semula persekitaran pelaksanaan. Ini mempunyai kesan. Kontrak pintar hanya boleh dipanggil secara tak segerak dengan menghantar apa yang dipanggil mesej dalaman Ambil perhatian bahawa sama ada ia adalah jenis pengubahsuaian keadaan atau jenis panggilan baca sahaja, prinsip ini juga perlu dipatuhi perlu dipertimbangkan dengan teliti Cara mengendalikan rollback data jika panggilan tak segerak gagal.

Sudah tentu, perbezaan teknikal lain telah dibincangkan secara terperinci dalam artikel sebelum ini diharap dapat memberi tumpuan kepada pembangunan kontrak pintar, jadi ia tidak akan dibincangkan. Kedua-dua prinsip reka bentuk di atas membuat perbezaan besar antara pembangunan kontrak pintar dalam TON dan EVM. Dalam perbincangan awal, kita tahu bahawa kontrak NFT perlu menentukan beberapa hubungan pemetaan, iaitu, pemetaan, untuk menyimpan data berkaitan NFT. Yang paling penting ialah pemilik. Pemetaan ini menyimpan hubungan pemetaan alamat pemilik NFT yang sepadan dengan tokenID tertentu, yang menentukan pemilikan NFT Pemindahan adalah pengubahsuaian pemilikan. Oleh kerana ini adalah struktur data yang boleh menjadi tidak terbatas dalam teori, ia perlu dielakkan sebanyak mungkin. Oleh itu, secara rasmi disyorkan untuk menggunakan kewujudan struktur data tidak terhad sebagai piawaian untuk sharding. Iaitu, apabila terdapat keperluan penyimpanan data yang serupa, paradigma kontrak tuan-hamba digunakan sebaliknya, dan data yang sepadan dengan setiap kunci diuruskan dengan mencipta sub-kontrak. Dan mengurus parameter global melalui kontrak utama, atau membantu mengendalikan interaksi maklumat dalaman antara sub-kontrak.

Ini bermakna NFT dalam TON juga perlu direka bentuk dengan seni bina yang serupa Setiap NFT ialah sub-kontrak bebas, yang menyimpan data eksklusif seperti alamat pemilik, metadata, dsb., dan diuruskan melalui kontrak utama data global seperti nama NFT, simbol, jumlah bekalan, dsb.

Selepas menjelaskan seni bina, langkah seterusnya ialah menyelesaikan keperluan fungsi teras Memandangkan kaedah kontrak tuan-hamba ini diguna pakai, adalah perlu untuk menjelaskan fungsi mana yang dibawa oleh kontrak utama dan fungsi mana yang dibawa oleh sub-. kontrak, dan fungsi mana yang dibawa oleh sub-kontrak, dan fungsi mana yang dibawa oleh sub-kontrak Apakah maklumat dalaman yang digunakan untuk berkomunikasi antara mereka, dan cara untuk melancarkan semula data sebelumnya apabila ralat pelaksanaan berlaku. Biasanya, sebelum membangunkan projek berskala besar yang kompleks, adalah perlu untuk lulus gambar rajah kelas dan menjelaskan aliran maklumat antara satu sama lain, dan berhati-hati memikirkan logik rollback selepas panggilan dalaman gagal Sudah tentu, pembangunan NFT di atas adalah mudah , tetapi ia juga boleh Lakukan pengesahan serupa.

Belajar untuk membangunkan kontrak pintar TON daripada kod sumber

TON telah memilih untuk mereka bentuk bahasa bertaip statik seperti C yang dinamakan Func sebagai bahasa pembangunan kontrak pintar, kemudian mari kita belajar cara membangunkan kontrak pintar TON daripada kod sumber. Saya memilih contoh NFT dalam dokumentasi rasmi TON untuk memperkenalkannya. Rakan-rakan yang berminat boleh menyemaknya sendiri. Dalam kes ini, contoh TON NFT mudah dilaksanakan. Mari kita lihat struktur kontrak, yang dibahagikan kepada dua kontrak berfungsi dan tiga perpustakaan yang diperlukan.

Dua kontrak berfungsi utama direka mengikut prinsip di atas Pertama, mari kita lihat kod kontrak utama nft-collection:

Ini memperkenalkan titik pengetahuan pertama, cara penyimpanan Berterusan. data dalam kontrak pintar TON Kami tahu bahawa penyimpanan data yang berterusan dalam Solidity dikendalikan secara automatik oleh EVM berdasarkan jenis parameter Biasanya, pembolehubah keadaan kontrak pintar akan dikekalkan secara automatik mengikut nilai terkini selepas pelaksanaan . Storan, pembangun tidak perlu mempertimbangkan proses ini. Tetapi ini tidak berlaku dalam Func Pembangun perlu melaksanakan sendiri logik pemprosesan yang sepadan Keadaan ini agak serupa dengan keperluan untuk mempertimbangkan proses GC dalam C dan C++, tetapi bahasa pembangunan baharu yang lain biasanya mengautomasikan bahagian ini. logik. Mari kita lihat kod tersebut Mula-mula, kami memperkenalkan beberapa perpustakaan yang diperlukan, dan kemudian kita melihat bahawa fungsi pertama load_data digunakan untuk membaca data yang disimpan secara berterusan Logiknya adalah untuk memulangkan sel penyimpanan kontrak yang berterusan melalui get_data ini dilakukan oleh standard yang Dilaksanakan oleh perpustakaan stdlib.fc, beberapa fungsi ini biasanya boleh digunakan sebagai fungsi sistem.

Jenis nilai pulangan bagi fungsi ini ialah sel, iaitu jenis sel dalam TVM. Dalam pengenalan sebelum ini, kita sudah tahu bahawa semua data berterusan dalam blok TON disimpan dalam pokok sel. Setiap sel mempunyai sehingga 1023 bit data arbitrari dan sehingga empat rujukan kepada sel lain. Sel digunakan sebagai memori dalam TVM berasaskan tindanan. Apa yang disimpan dalam sel adalah data yang dikodkan padat Untuk mendapatkan data teks biasa, sel perlu ditukar kepada jenis yang dipanggil hirisan. Sel boleh ditukar kepada jenis kepingan melalui fungsi begin_parse, dan kemudian data dalam sel boleh diperolehi dengan memuatkan bit data daripada kepingan dan rujukan kepada sel lain. Ambil perhatian bahawa kaedah panggilan dalam baris 15 ini ialah gula sintaktik dalam func dan anda boleh terus memanggil fungsi kedua yang mengembalikan nilai fungsi pertama. Dan akhirnya muatkan data yang sepadan mengikut susunan mengikut susunan kegigihan data. Ambil perhatian bahawa proses ini berbeza daripada kekukuhan dan tidak dipanggil berdasarkan peta hash, jadi susunan panggilan tidak boleh dikacau.

Dalam fungsi save_data, logiknya adalah serupa, kecuali ini adalah proses terbalik, yang memperkenalkan titik pengetahuan seterusnya, pembina jenis baharu, iaitu jenis pembina sel. Bit data dan rujukan kepada sel lain boleh disimpan dalam pembina, yang kemudiannya boleh dimuktamadkan ke dalam sel baharu. Mula-mula buat pembina melalui fungsi standard begin_cell, dan simpan fungsi berkaitan melalui fungsi berkaitan kedai secara bergilir Ambil perhatian bahawa susunan panggilan di atas perlu konsisten dengan susunan storan di sini. Akhirnya, pembinaan sel baharu selesai melalui end_cell Pada masa ini, sel diuruskan dalam memori Akhirnya, melalui set_data terluar, storan berterusan sel boleh dilengkapkan.

Seterusnya, mari kita lihat fungsi berkaitan perniagaan Pertama, kita perlu memperkenalkan titik pengetahuan seterusnya, cara membuat kontrak baharu melalui kontrak, yang akan kerap digunakan dalam seni bina tuan-hamba sahaja. diperkenalkan. Kami tahu bahawa dalam TON, panggilan antara kontrak pintar dilaksanakan dengan menghantar mesej dalaman. Ini dicapai melalui mesej yang dipanggil send_raw_message Ambil perhatian bahawa parameter pertama ialah sel berkod mesej, dan parameter kedua ialah bit pengenalan, yang digunakan untuk menunjukkan perbezaan dalam kaedah pelaksanaan urus niaga yang berbeza ditetapkan dalam TON Pada masa ini terdapat 3 Mod mesej dan 3 Bendera mesej untuk kaedah pelaksanaan penghantaran mesej. Mod tunggal boleh digabungkan dengan bendera berbilang (mungkin tiada) untuk mendapatkan mod yang diingini. Menggabungkan hanya bermakna mengisi jumlah nilai mereka. Jadual penerangan Mod dan Bendera diberikan di bawah:

Jadi mari kita lihat fungsi utama pertama, deploy_nft_item Seperti namanya, ini ialah fungsi yang digunakan untuk mencipta atau menghantar contoh NFT baharu Selepas beberapa operasi untuk mengekod mesej, kontrak dalaman dihantar melalui send_raw_message Bendera penghantaran bendera 1 hanya menggunakan yuran yang dinyatakan dalam pengekodan sebagai yuran gas untuk pelaksanaan ini. Selepas pengenalan di atas, kita boleh dengan mudah menyedari bahawa peraturan pengekodan ini harus sepadan dengan cara untuk mencipta kontrak pintar baharu. Jadi mari kita lihat bagaimana ia dilaksanakan.

Mari kita lihat terus di baris 51. Dua fungsi di atas adalah fungsi tambahan yang digunakan untuk menjana maklumat yang diperlukan untuk mesej, jadi kita akan melihatnya kemudian. Ini adalah proses pengekodan untuk mencipta mesej dalaman beberapa nombor dalam tengah Malah, mereka juga beberapa bit pengenalan yang digunakan untuk menerangkan keperluan mesej dalaman. Titik pengetahuan seterusnya diperkenalkan di sini TON memilih bahasa binari yang dipanggil TL-B untuk menerangkan kaedah pelaksanaan mesej, dan bit bendera yang berbeza. ditetapkan mengikut Untuk melaksanakan mesej dalaman untuk fungsi tertentu tertentu, dua senario penggunaan paling biasa yang terlintas di fikiran ialah penciptaan kontrak baharu dan panggilan fungsi kontrak yang digunakan. Kaedah pada baris 51 sepadan dengan yang pertama, mewujudkan kontrak item nft baharu, yang terutamanya ditentukan melalui baris 55, 56, dan 57. Pertama sekali, siri nombor besar dalam baris 55 ialah siri bit pengenalan Perhatikan bahawa parameter input pertama store_uint ialah nilai, dan yang kedua ialah panjang bit, yang menentukan sama ada mesej dalaman dicipta oleh kontrak. , tiga bit penanda terakhir, dan nilai perduaan yang sepadan ialah 111 (4+2+1 dalam perpuluhan), dua yang pertama menunjukkan bahawa mesej akan disertakan dengan data StateInit Data ini ialah kod sumber baharu kontrak dan data yang diperlukan untuk permulaan. Bit bendera terakhir menunjukkan lampiran mesej dalaman, iaitu logik yang berkaitan dan parameter yang diperlukan dijangka akan dilaksanakan. Oleh itu, anda akan melihat bahawa data tiga digit tidak ditetapkan dalam baris 66 kod, yang menunjukkan panggilan fungsi kepada kontrak yang digunakan. Peraturan pengekodan terperinci boleh didapati di sini.

Kemudian peraturan pengekodan StateInit sepadan dengan 49 baris kod, dikira melalui calculate_nft_item_state_init Ambil perhatian bahawa pengekodan data stateinit juga mengikut peraturan pengekodan TL-B yang ditetapkan sebagai tambahan kepada beberapa bit bendera, ia melibatkan dua bahagian kod kontrak baharu dan data yang dimulakan. Susunan pengekodan data perlu konsisten dengan susunan storan sel kegigihan yang ditentukan oleh kontrak baharu. Seperti yang anda lihat pada baris 36, data permulaan termasuk item_index, yang serupa dengan tokenId dalam ERC721, dan alamat kontrak semasa yang dikembalikan oleh fungsi standard my_address, iaitu collection_address Susunan data ini adalah konsisten dengan pengisytiharan dalam nft-item.

Maklumat pengetahuan seterusnya ialah dalam TON, semua kontrak pintar yang tidak dijana boleh mengira alamat terjananya Ini serupa dengan fungsi create2 dalam Solidity Penjanaan alamat baharu dalam TON terdiri daripada dua bahagian disambungkan dengan nilai hash stateinit Seperti yang telah kita lihat dalam pengenalan sebelum ini, yang pertama perlu ditentukan untuk sepadan dengan seni bina sharding tak terhingga TON Ia kini merupakan nilai bersatu. Diperolehi daripada rantai kerja fungsi standard. Yang terakhir diperolehi oleh fungsi standard cell_hash. Jadi kembali kepada contoh ini, hitung_nft_item_address ialah fungsi yang pra-mengira alamat kontrak baharu. Dan kodkan nilai yang dijana ke dalam mesej pada baris 53 sebagai alamat penerima mesej dalaman. nft_content sepadan dengan panggilan permulaan kepada kontrak yang dibuat Pelaksanaan khusus akan diperkenalkan dalam artikel seterusnya.

Bagi send_royalty_params, ia perlu menjadi respons kepada mesej dalaman permintaan baca sahaja Dalam pengenalan sebelum ini, kami secara khusus menekankan bahawa mesej dalaman dalam TON bukan sahaja mengandungi operasi yang boleh mengubah suai data, tetapi juga bacaan. -hanya operasi yang perlu lulus ini Ia dilaksanakan dengan cara, jadi kontrak adalah operasi sedemikian Pertama sekali, perlu diperhatikan bahawa baris 67 menunjukkan tanda fungsi panggil balik peminta selepas menjawab permintaan itu dan ia akan mengembalikan data, iaitu indeks item yang diminta dan data royalti yang sepadan.

Mari kami memperkenalkan titik pengetahuan seterusnya Terdapat hanya dua pintu masuk bersatu ke kontrak pintar di TON, bernama recv_internal dan recv_external Yang pertama ialah pintu masuk panggilan bersatu untuk semua mesej dalaman, dan pintu masuk panggilan bersatu untuk semua luaran. , pembangun perlu menggunakan kaedah seperti suis untuk membalas permintaan yang berbeza berdasarkan bit bendera berbeza yang ditentukan oleh mesej dalam fungsi mengikut keperluan Bit bendera di sini ialah bendera fungsi panggil balik dalam baris 67 di atas. Kembali ke contoh ini, mula-mula lakukan semakan kekosongan pada mesej, dan kemudian menghuraikan maklumat dalam mesej masing-masing Mula-mula, menghuraikan pada baris 83 untuk mendapatkan alamat_pengirim Parameter ini akan digunakan untuk semakan kebenaran berikutnya di sini tergolong dalam sintaks lain. Saya tidak akan mengembangkannya di sini. Seterusnya, bit bendera operasi op dihuraikan, dan kemudian permintaan yang sepadan diproses mengikut bit bendera yang berbeza. Antaranya, fungsi di atas dipanggil masing-masing mengikut logik tertentu. Contohnya, balas permintaan untuk parameter royalti atau hantar nft baharu dan naikkan indeks global.

Titik pengetahuan seterusnya sepadan dengan baris 108. Saya rasa anda juga boleh mengetahui logik pemprosesan fungsi ini dengan menamakannya Ia serupa dengan fungsi memerlukan dalam Solidity melalui fungsi standard throw_unless parameter adalah kod ralat, yang kedua adalah untuk memeriksa nilai Boolean bit, jika bit itu palsu, pengecualian akan dilemparkan dengan kod ralat. Dalam baris ini, equal_slices digunakan untuk menentukan sama ada alamat_pengirim yang dihuraikan di atas adalah sama dengan alamat_pemilik storan berterusan kontrak dan pertimbangan kebenaran dibuat.

Akhir sekali, untuk menjadikan struktur kod lebih jelas, satu siri fungsi tambahan telah dibangunkan untuk membantu mendapatkan maklumat kegigihan, yang tidak akan diperkenalkan di sini Pembangun boleh merujuk kepada struktur ini untuk membangunkan kontrak pintar mereka sendiri.

Pembangunan DApp dalam ekosistem TON sungguh menarik Ia sangat berbeza dengan paradigma pembangunan EVM, jadi saya akan memperkenalkan cara membangunkan DApp dalam Rantaian TON melalui satu siri artikel. Belajar bersama-sama dengan semua orang dan rebut gelombang peluang ini. Anda juga dialu-alukan untuk berinteraksi dengan saya di twitter untuk menghasilkan beberapa idea dapp yang baharu dan menarik dan membangunkannya bersama-sama.

Atas ialah kandungan terperinci Tutorial pembangunan projek TON (1): Cara mencipta NFT pada Rantaian TON dari perspektif kod sumber. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!