Autors: @Web3Mario

Kopsavilkums: Pēc iepriekšējā raksta par TON tehnoloģiju ieviešanu, šajā periodā esmu padziļināti izpētījis oficiālos TON izstrādes dokumentus, man šķiet, ka joprojām pastāv daži šķēršļi, lai mācītos dokuments jaunam sākuma līmeņa izstrādei. Tas nav īpaši draudzīgs lasītājiem, tāpēc es cenšos sakārtot rakstu sēriju par TON Chain projekta attīstību, pamatojoties uz manu mācību trajektoriju sākās ar TON DApp izstrādi. Ja rakstā ir kļūdas, laipni lūdzam mani labot un mācīties kopā.

Kādas ir atšķirības starp NFT izstrādi EVM un NFT izstrādi TON ķēdē?

FT vai NFT izdošana parasti ir visvienkāršākā DApp izstrādātāju nepieciešamība. Tāpēc es to izmantoju arī kā ieejas punktu mācībām. Pirmkārt, ļaujiet mums saprast šādas atšķirības starp NFT izstrādi EVM tehnoloģiju kaudzē un TON ķēdē. Uz EVM balstīti NFT parasti izvēlas mantot ERC-721 standartu. Tā sauktais NFT attiecas uz nedalāmu šifrētu līdzekļu veidu, un katrs līdzeklis ir unikāls, tas ir, tam ir noteiktas ekskluzīvas īpašības. ERC-721 ir izplatīta šāda veida aktīvu attīstības paradigma. Apskatīsim, kādas funkcijas ir jāievieš kopējam ERC721 līgumam un kāda informācija tiek reģistrēta. Zemāk redzamajā attēlā ir ERC721 interfeiss. Redzams, ka atšķirībā no FT pārsūtīšanas saskarnē jāievada nevis summa, bet gan pārskaitāmais tokenId. Šis marķiera ID ir arī visvienkāršākā NFT līdzekļu unikalitātes izpausme. Protams, katram tokenId parasti tiek ierakstīti metadati, kas saglabā citus mērogojamus NFT datus kā Saites uz PFP attēliem, noteiktiem atribūtu nosaukumiem utt.

Izstrādātājiem, kuri ir pazīstami ar Solidity vai objektorientētu, ir viegli ieviest šādu viedo līgumu. Jums tikai jādefinē līgumā nepieciešamie datu tipi, piemēram, dažas galvenās kartēšanas attiecības, un jāizstrādā atbilstošie atbilstoši nepieciešamajiem. Šo datu modifikācijas loģika var realizēt NFT.

Tomēr TON ķēdē viss ir atšķirīgs. Atšķirībai ir divi galvenie iemesli.

l Datu glabāšana TON ir balstīta uz šūnu, un tā paša konta šūna tiek ieviesta, izmantojot virzītu aciklisku grafiku. Tas nozīmē, ka dati, kas jāuzglabā, nevar augt bez robežām, jo ​​virzītam acikliskam grafikam vaicājuma izmaksas nosaka datu dziļums Līgums ir iestrēdzis strupceļā.

l Lai sasniegtu augstu vienlaicīgu veiktspēju, TON atteicās no seriālās izpildes arhitektūras un tā vietā pieņēma izstrādes paradigmu, kas īpaši izstrādāta paralēlismam, Actor modeli, lai rekonstruētu izpildes vidi. Tam ir ietekme. Viedos līgumus var izsaukt tikai asinhroni, nosūtot tā sauktos iekšējos ziņojumus. Ņemiet vērā, ka tas ir zvana veids vai tikai lasāms. Turklāt tas ir jāievēro rūpīgi jāapsver, kā rīkoties, ja asinhronais zvans neizdodas.

Protams, citas tehniskās atšķirības ir detalizēti apspriestas iepriekšējā rakstā. Šis raksts cer koncentrēties uz viedo līgumu izstrādi, tāpēc tas netiks apspriests. Iepriekš minētie divi projektēšanas principi ievērojami atšķir viedo līgumu izstrādi un EVM TON. Sākotnējā diskusijā mēs zinām, ka NFT līgumā ir jādefinē dažas kartēšanas attiecības, tas ir, kartēšana, lai saglabātu ar NFT saistītus datus. Vissvarīgākais no tiem ir īpašnieki. Šī kartēšana saglabā NFT īpašnieka adreses kartēšanas attiecības, kas nosaka NFT īpašumtiesības. Tā kā šī ir datu struktūra, kas teorētiski var būt neierobežota, no tās ir pēc iespējas jāizvairās. Tāpēc oficiāli ir ieteicams izmantot neierobežotu datu struktūru esamību kā sharding standartu. Tas ir, ja ir līdzīgas datu uzglabāšanas prasības, tā vietā tiek izmantota galvenā un pakārtotā līguma paradigma, un katrai atslēgai atbilstošie dati tiek pārvaldīti, izveidojot apakšlīgumus. Un pārvaldiet globālos parametrus, izmantojot galveno līgumu, vai palīdziet apstrādāt iekšējo informācijas mijiedarbību starp apakšlīgumiem.

Tas nozīmē, ka TON NFT ir jāveido, izmantojot līdzīgu arhitektūru. Katrs NFT ir neatkarīgs apakšlīgums, kas saglabā ekskluzīvus datus, piemēram, īpašnieka adresi, metadatus utt., un pārvalda vispārējo situāciju, izmantojot galveno līgumu piemēram, NFT nosaukums, simbols, kopējais piedāvājums utt.

Pēc arhitektūras precizēšanas nākamais solis ir atrisināt galvenās funkcionālās prasības. Sakarā ar šī galvenā un pakārtotā līguma pieņemšanu,

Tāpēc ir jāprecizē, kuras funkcijas veic galvenais līgums un kuras funkcijas veic apakšlīgums, un kāda iekšējā informācija tiek izmantota abu savstarpējai saziņai. Tajā pašā laikā, kad notiek izpildes kļūda lai atgrieztu iepriekšējos datus. Parasti pirms sarežģīta liela mēroga projekta izstrādes ir jāiziet klašu diagramma un jānoskaidro informācijas plūsma savā starpā, un rūpīgi jādomā par atgriešanas loģiku pēc iekšējā zvana, protams, iepriekš minētā NFT izstrāde ir vienkārša, taču tā var arī veikt līdzīgu pārbaudi.

Iemācieties izstrādāt TON viedos līgumus no pirmkoda

TON izvēlējās izveidot C veida, statiski drukātu valodu ar nosaukumu Func. Pēc tam iemācīsimies izstrādāt TON viedos līgumus no avota koda. Es izvēlējos NFT piemēru TON oficiālajā dokumentā Ieinteresētie draugi var to pārbaudīt paši. Šajā gadījumā tiek īstenots vienkāršs TON NFT piemērs. Apskatīsim līguma struktūru, kas ir sadalīta divos funkcionālajos līgumos un trīs nepieciešamajās bibliotēkās.

Šie divi galvenie funkcionālie līgumi ir izstrādāti saskaņā ar iepriekš minētajiem principiem. Vispirms apskatīsim galvenā līguma nft-kolekcijas kodu.

Tas iepazīstina ar pirmo zināšanu punktu, kā pastāvīgi uzglabāt datus TON viedajos līgumos. Mēs zinām, ka pastāvīgo datu glabāšanu Solidity automātiski apstrādā atbilstoši parametru veidam. Parasti viedo līgumu stāvokļa mainīgie automātiski tiek saglabāta un saglabāta, pamatojoties uz jaunāko vērtību pēc izpildes, un izstrādātājiem nav jāņem vērā šis process. Bet tas tā nav Func gadījumā. Izstrādātājiem pašiem ir jāievieš atbilstošā apstrādes loģika. Šī situācija ir nedaudz līdzīga nepieciešamībai apsvērt GC procesu C un C++, taču citas jaunās izstrādes valodas parasti automatizē šo programmas daļu. loģika. Apskatīsim kodu. Vispirms mēs ieviešam dažas obligātās bibliotēkas, un pēc tam redzam, ka pirmā funkcija load_data tiek izmantota, lai nolasītu pastāvīgi saglabāto datu bāzi. Ņemiet vērā, ka šī tiek veikts ar standartu, ko īsteno bibliotēka stdlib.fc, dažas no šīm funkcijām parasti var izmantot kā sistēmas funkcijas.

Šīs funkcijas atgriešanas vērtības veids ir šūna, kas ir šūnas tips TVM. Iepriekšējā ievadā mēs jau zinām, ka visi pastāvīgie dati TON blokķēdē tiek glabāti šūnu kokā. Katrā šūnā ir līdz 1023 bitiem patvaļīgu datu un līdz četrām atsaucēm uz citām šūnām. Šūnas tiek izmantotas kā atmiņa uz steku balstītā TVM. Šūnā glabātie ir kompakti kodēti dati. Šūnu var pārveidot par slāņa tipu, izmantojot funkciju begin_parse, un pēc tam datus šūnā var iegūt, ielādējot datu bitus no šķēluma un atsauces uz citām šūnām. Ņemiet vērā, ka šī izsaukšanas metode 15. rindā ir sintaktiskais cukurs in func, un jūs varat tieši izsaukt otro funkciju, kas atgriež pirmās funkcijas vērtību. Un visbeidzot ielādējiet atbilstošos datus kārtībā atbilstoši datu noturības secībai. Ņemiet vērā, ka šis process atšķiras no solidity un netiek izsaukts, pamatojoties uz hashmap, tāpēc zvanu secību nevar sajaukt.

Funkcijā save_data loģika ir līdzīga, izņemot to, ka šis ir apgriezts process, kas ievieš nākamo zināšanu punktu, jauna tipa veidotāju, kas ir šūnu veidotāja veids. Datu biti un atsauces uz citām šūnām var tikt saglabāti veidotājos, kurus pēc tam var pabeigt jaunās šūnās. Vispirms izveidojiet veidotāju, izmantojot standarta funkciju begin_cell, un pēc kārtas saglabājiet saistītās funkcijas, izmantojot ar veikalu saistītās funkcijas. Ņemiet vērā, ka iepriekš norādītajam izsaukšanas pasūtījumam ir jāatbilst šeit norādītajam krātuves pasūtījumam. Visbeidzot, jaunā šūna tiek konstruēta, izmantojot end_cell. Šajā laikā šūna tiek pārvaldīta, izmantojot attālāko set_data, šūnas pastāvīgo glabāšanu.

Tālāk apskatīsim ar uzņēmējdarbību saistītās funkcijas. Pirmkārt, mums ir jāiepazīstina ar nākamo zināšanu punktu, kā izveidot jaunu līgumu, izmantojot līgumu, kas tiks bieži izmantots tikko ieviestajā master-slave arhitektūrā. Mēs zinām, ka TON zvani starp viedajiem līgumiem tiek īstenoti, nosūtot iekšējus ziņojumus. Tas tiek panākts, izmantojot ziņojumu send_raw_message. Ņemiet vērā, ka pirmais parametrs ir ziņojuma kodētā šūna, bet otrais parametrs ir identifikācijas bits, kas tiek izmantots, lai norādītu atšķirību darījuma izpildes metodē in TON Pašlaik ir 3 ziņojumu režīmi un 3 ziņojumu karodziņi ziņojumu nosūtīšanas izpildes metodei. Lai iegūtu vēlamo režīmu, vienu režīmu var apvienot ar vairākiem (varbūt nevienam) karodziņiem. Apvienot tikai nozīmē aizpildīt to vērtību summu. Režīmu un karogu apraksta tabula ir sniegta zemāk:

Apskatīsim pirmo galveno funkciju deploy_nft_item, kā norāda nosaukums, šī funkcija tiek izmantota, lai izveidotu vai pārraidītu jaunu NFT gadījumu karoga bits 1 izmanto tikai kodējumā norādīto maksu kā gāzes maksu par šo izpildi. Pēc iepriekš minētā ievada mēs varam viegli saprast, ka šim kodēšanas noteikumam jāatbilst jauna viedā līguma izveides veidam.

Tāpēc apskatīsim, kā tas tiek īstenots.

Apskatīsim tieši 51. rindu. Iepriekš minētās funkcijas ir palīgfunkcijas, ko izmanto ziņojumam nepieciešamās informācijas ģenerēšanai, tāpēc mēs to aplūkosim vēlāk. Šis ir kodēšanas process viedo līgumu iekšējo ziņojumu izveidei vidus faktiski ir daži identifikācijas biti, kas tiek izmantoti, lai aprakstītu iekšējā ziņojuma prasības. Šeit tiek ieviests nākamais zināšanu punkts, lai aprakstītu ziņojuma izpildes metodi, un ievieš to, iestatot citu karogu. biti Lai iegūtu iekšēju informāciju par noteiktām specifiskām funkcijām, divi vienkāršākie lietošanas scenāriji ir jauna līguma izveide un izvietotie līguma funkciju izsaukumi. Metode 51. rindā atbilst pirmajai, izveidojot jaunu nft preču līgumu, kas galvenokārt norādīts 55., 56. un 57. rindā. Pirmkārt, lielā skaitļu sērija 55. rindā ir identifikācijas bitu sērija. Ņemiet vērā, ka pirmais store_uint ievades parametrs ir vērtība, bet otrais ir bitu garums, kas nosaka, vai iekšējais ziņojums ir izveidots ar līgumu. , pēdējie trīs marķēšanas biti un attiecīgie Binārā vērtība ir 111 (4+2+1 decimāldaļās), no kurām pirmie divi norāda, ka ziņojumam tiks pievienoti StateInit dati Šie dati ir jaunā avota kods līgumu un inicializācijai nepieciešamos datus. Pēdējais karoga bits norāda iekšējo ziņojuma pielikumu, tas ir, ir paredzēts, ka tiks izpildīta attiecīgā loģika un nepieciešamie parametri. Tāpēc jūs redzēsiet, ka trīsciparu dati nav iestatīti koda 66. rindā, kas norāda uz funkcijas izsaukumu izvietotajam līgumam. Detalizētus kodēšanas noteikumus var atrast šeit.

Tad StateInit kodēšanas kārtulas atbilst 49 koda rindām, kas aprēķinātas, izmantojot parametru Calculate_nft_item_state_init. Ņemiet vērā, ka stateinit datu kodēšana tiek veikta papildus dažiem karoga bitiem kods un Un inicializēt datus. Datu kodēšanas secībai ir jāatbilst jaunajā līgumā norādītajai noturības šūnu glabāšanas secībai. Kā redzat 36. rindiņā, inicializācijas datos ir iekļauts item_index, kas ir līdzīgs tokenId ERC721, un pašreizējā līguma adrese, ko atgriež standarta funkcija my_address, kas ir collection_address. Šo datu secība atbilst deklarācijai nft-item.

Nākamais zināšanu punkts ir tāds, ka programmā TON visi neģenerētie viedie līgumi var iepriekš aprēķināt savas ģenerētās adreses. Tas ir līdzīgs Solidity funkcijai Create2. Jaunu adrešu ģenerēšana programmā TON sastāv no divām daļām: darba ķēdes identifikatora Bit un statusinit. Iepriekšējā ievadā mēs jau zinām, ka tie ir jāprecizē, lai tie atbilstu TON bezgalīgas sadalīšanas arhitektūrai. Iegūts no standarta funkciju darba ķēdes. Pēdējo iegūst ar standarta funkciju cell_hash. Tātad, atgriežoties pie šī piemēra, Calculate_nft_item_address ir funkcija, kas iepriekš aprēķina jauno līguma adresi. Un iekodējiet ģenerēto vērtību ziņojumā 53. rindā kā iekšējā ziņojuma saņemšanas adresi. nft_content atbilst izveidotā līguma inicializācijas izsaukumam. Konkrētā ieviešana tiks iepazīstināta nākamajā rakstā.

Kas attiecas uz send_royalty_params, tai ir jābūt atbildei uz tikai lasāma pieprasījuma iekšējo ziņojumu. Iepriekšējā ievadā mēs īpaši uzsvērām, ka TON iekšējais ziņojums satur ne tikai darbības, kas var mainīt datus, bet arī lasīšanas. tikai operācija ir jāveic šādā veidā, tāpēc šis līgums ir pirmkārt, ir vērts atzīmēt, ka 67. rindā ir norādīta pieprasītāja atzvanīšanas funkcija pēc atbildes uz pieprasījumu būs atgrieztie dati, kas ir pieprasītais preces indekss un attiecīgie autoratlīdzības dati.

Pēc tam iepazīstināsim ar nākamo zināšanu punktu. TON ir tikai divas vienotas ieejas viedajiem līgumiem ar nosaukumu recv_internal.

un recv_external, kur pirmā ir vienota izsaukšanas ieeja visiem iekšējiem ziņojumiem, bet otrā ir vienota izsaukšanas ieeja visiem ārējiem ziņojumiem biti, kas norādīti ziņojumā, atzīmes bits šeit ir atzvanīšanas funkcijas atzīme 67. rindā. Atgriežoties pie šī piemēra, vispirms veiciet ziņojuma vakances pārbaudi un pēc tam attiecīgi parsējiet 83. rindā, lai iegūtu sūtītāja_adresi. Ņemiet vērā, ka ~ operators šeit pieder citai sintaksei. Šeit es to neizvērsīšu. Pēc tam tiek parsēti operācijas karodziņa biti, un pēc tam atbilstošie pieprasījumi tiek apstrādāti atbilstoši dažādiem karoga bitiem. Starp tiem iepriekš minētās funkcijas tiek izsauktas attiecīgi saskaņā ar noteiktu loģiku. Piemēram, atbildiet uz autoratlīdzības parametra pieprasījumu vai ievadiet jaunu nft un palieliniet globālo indeksu.

Nākamais zināšanu punkts atbilst 108. rindiņai. Es domāju, ka varat uzzināt arī šīs funkcijas apstrādes loģiku. Tas ir līdzīgs funkcijai, kas tiek izmantota programmā Func, izmantojot standarta funkciju throw_unless ir kļūdas kods, otrais ir pārbaudīt bitu Būla vērtību, ja bits ir nepatiess, ar kļūdas kodu tiks izmests izņēmums. Šajā rindā tiek izmantots vienāds_slices, lai noteiktu, vai iepriekš parsētā sūtītāja_adrese ir vienāda ar līguma pastāvīgās krātuves īpašnieka_adresi, un tiek pieņemts lēmums par atļauju.

Visbeidzot, lai padarītu koda struktūru skaidrāku, ir izstrādāta virkne palīgfunkciju, kas palīdz iegūt noturības informāciju, kas šeit netiks ieviesta. Izstrādātāji var atsaukties uz šo struktūru, lai izstrādātu savus viedos līgumus.

DApp izstrāde TON ekosistēmā ir patiešām interesanta, un tā ļoti atšķiras no EVM attīstības paradigmas, tāpēc es iepazīstināšu ar rakstu sēriju, kā izstrādāt DApp TON ķēdē. Mācieties kopā ar visiem un izmantojiet šo iespēju vilni. Esiet laipni aicināti arī sazināties ar mani Twitter, lai izdomātu jaunas un interesantas dapp idejas un tās kopīgi attīstītu.