ผู้เขียนต้นฉบับ: @ Web3 Mario (https://x.com/web3_mario)
จากบทความก่อนหน้านี้เกี่ยวกับการแนะนำเทคโนโลยี TON ฉันได้ศึกษาเอกสารการพัฒนา TON อย่างเป็นทางการในช่วงเวลานี้ ฉันรู้สึกว่ายังมีอุปสรรคบางประการในการเรียนรู้ เนื้อหาเอกสารในปัจจุบันดูเหมือนจะคล้ายกับเอกสารการพัฒนาภายใน ซึ่งเหมาะสำหรับนักพัฒนาใหม่ ไม่ค่อยเป็นมิตร ดังนั้นฉันจึงพยายามจัดเรียงบทความเกี่ยวกับการพัฒนาโครงการ TON Chain ตามวิถีการเรียนรู้ของฉันเอง ฉันหวังว่ามันจะเป็นประโยชน์สำหรับทุกคนในการเริ่มต้นพัฒนา TON DApp อย่างรวดเร็ว . หากเขียนผิดพลาดประการใด ยินดีแก้ไขและเรียนรู้ร่วมกันครับ
อะไรคือความแตกต่างระหว่างการพัฒนา NFT ใน EVM และการพัฒนา NFT บน TON Chain?
โดยปกติแล้ว การออก FT หรือ NFT ถือเป็นความต้องการขั้นพื้นฐานที่สุดสำหรับนักพัฒนา DApp ฉันจึงใช้สิ่งนี้เป็นจุดเริ่มต้นในการเรียนรู้ด้วย ก่อนอื่น ให้เราเข้าใจความแตกต่างต่อไปนี้ระหว่างการพัฒนา NFT ในสแต็กเทคโนโลยี EVM และ TON Chain NFT ที่ใช้ EVM มักจะเลือกที่จะสืบทอดมาตรฐาน ERC-721 สิ่งที่เรียกว่า NFT หมายถึงประเภทสินทรัพย์ที่เข้ารหัสซึ่งแบ่งแยกไม่ได้ และแต่ละสินทรัพย์จะมีเอกลักษณ์เฉพาะตัว กล่าวคือ มีลักษณะเฉพาะบางประการ ERC-721 เป็นกระบวนทัศน์การพัฒนาทั่วไปสำหรับสินทรัพย์ประเภทนี้ มาดูกันว่าฟังก์ชันใดที่สัญญา ERC 721 ทั่วไปจำเป็นต้องนำไปใช้ และข้อมูลใดบ้างที่บันทึกไว้ ภาพด้านล่างคืออินเทอร์เฟซ ERC 721 จะเห็นได้ว่าสิ่งที่ต้องป้อนในอินเทอร์เฟซการถ่ายโอนต่างจาก FT คือ tokenId ที่จะถ่ายโอนแทนที่จะเป็นจำนวนเงิน tokenId นี้ยังเป็นศูนย์รวมพื้นฐานที่สุดของความเป็นเอกลักษณ์ของสินทรัพย์ NFT อีกด้วย แน่นอนว่าเพื่อให้มีแอตทริบิวต์มากขึ้น โดยปกติแล้ว metadata จะถูกบันทึกสำหรับแต่ละ tokenId เป็นลิงก์ไปยังรูปภาพ PFP ชื่อของคุณสมบัติบางอย่าง ฯลฯ
สำหรับนักพัฒนาที่คุ้นเคยกับ Solidity หรือคุ้นเคยกับ Object-Oriented เป็นเรื่องง่ายที่จะนำ Smart Contract ดังกล่าวไปใช้ คุณเพียงแค่ต้องกำหนดประเภทข้อมูลที่จำเป็นในสัญญา เช่น ความสัมพันธ์ในการแมปคีย์ และพัฒนาสิ่งที่เกี่ยวข้องตามนั้น ไปยังฟังก์ชันที่ต้องการ ตรรกะการแก้ไขข้อมูลเหล่านี้สามารถรับรู้ NFT ได้
อย่างไรก็ตาม สิ่งนี้ไม่เหมือนกันใน TON Chain มีสองเหตุผลหลักสำหรับความแตกต่าง:
การจัดเก็บข้อมูลใน TON จะดำเนินการตามเซลล์ และเซลล์ของบัญชีเดียวกันจะถูกนำไปใช้ผ่านกราฟอะไซคลิกโดยตรง ซึ่งหมายความว่าข้อมูลที่จำเป็นต้องจัดเก็บไม่สามารถเติบโตได้โดยไม่มีขอบเขต เนื่องจากสำหรับกราฟอะไซคลิกโดยตรง ต้นทุนการสืบค้นจะถูกกำหนดโดยความลึกของข้อมูล เมื่อความลึกขยายออกไปอย่างไม่สิ้นสุด ต้นทุนการสืบค้นอาจสูงเกินไป ซึ่งนำไปสู่ สัญญาติดอยู่ในปัญหาการหยุดชะงัก
เพื่อที่จะติดตามประสิทธิภาพการทำงานพร้อมกันในระดับสูง TON จึงละทิ้งสถาปัตยกรรมการประมวลผลแบบอนุกรม และนำกระบวนทัศน์การพัฒนาที่ออกแบบมาสำหรับการขนานโดยเฉพาะ ซึ่งเป็นโมเดลนักแสดง มาใช้แทน เพื่อสร้างสภาพแวดล้อมการดำเนินการขึ้นใหม่ สิ่งนี้มีผลกระทบ Smart Contract สามารถเรียกแบบอะซิงโครนัสได้โดยการส่งข้อความภายในเท่านั้น โปรดทราบว่าไม่ว่าจะเป็นประเภทการแก้ไขสถานะหรือประเภทการโทรแบบอ่านอย่างเดียว นอกจากนี้ จะต้องปฏิบัติตามหลักการนี้ด้วย จำเป็นต้องได้รับการพิจารณาอย่างรอบคอบ วิธีจัดการกับการย้อนกลับข้อมูลหากการโทรแบบอะซิงโครนัสล้มเหลว
แน่นอนว่าความแตกต่างทางเทคนิคอื่นๆ ได้รับการกล่าวถึงโดยละเอียดในบทความที่แล้ว บทความนี้หวังว่าจะมุ่งเน้นไปที่การพัฒนาสัญญาอัจฉริยะ ดังนั้นจึงไม่มีการกล่าวถึง หลักการออกแบบสองประการข้างต้นสร้างความแตกต่างอย่างมากระหว่างการพัฒนาสัญญาอัจฉริยะใน TON และ EVM ในการสนทนาเบื้องต้น เรารู้ว่าสัญญา NFT จำเป็นต้องกำหนดความสัมพันธ์ในการทำแผนที่บางอย่าง ซึ่งก็คือ การทำแผนที่ เพื่อบันทึกข้อมูลที่เกี่ยวข้องกับ NFT สิ่งที่สำคัญที่สุดคือเจ้าของ การแมปนี้จะจัดเก็บความสัมพันธ์การแมปของที่อยู่ของเจ้าของ NFT ที่สอดคล้องกับโทเค็น ID ที่กำหนดซึ่งกำหนดความเป็นเจ้าของ NFT การโอนคือการแก้ไขความเป็นเจ้าของ เนื่องจากนี่คือโครงสร้างข้อมูลที่ไม่มีขอบเขตในทางทฤษฎี จึงจำเป็นต้องหลีกเลี่ยงให้มากที่สุด ดังนั้นจึงขอแนะนำอย่างเป็นทางการให้ใช้การมีอยู่ของโครงสร้างข้อมูลที่ไม่จำกัดเป็นมาตรฐานสำหรับการแบ่งส่วน นั่นคือ เมื่อมีข้อกำหนดในการจัดเก็บข้อมูลที่คล้ายกัน จะใช้กระบวนทัศน์สัญญาหลัก-รองแทน และข้อมูลที่สอดคล้องกับแต่ละคีย์จะได้รับการจัดการโดยการสร้างสัญญาย่อย และจัดการพารามิเตอร์ส่วนกลางผ่านสัญญาหลัก หรือช่วยจัดการการโต้ตอบข้อมูลภายในระหว่างสัญญาย่อย
ซึ่งหมายความว่า NFT ใน TON จำเป็นต้องได้รับการออกแบบโดยใช้สถาปัตยกรรมที่คล้ายกัน NFT แต่ละรายการเป็นสัญญาย่อยอิสระซึ่งจะบันทึกข้อมูลพิเศษ เช่น ที่อยู่ของเจ้าของ ข้อมูลเมตา ฯลฯ และจัดการสถานการณ์โดยรวมผ่านข้อมูลสัญญาหลัก เช่น ชื่อ NFT, สัญลักษณ์, อุปทานทั้งหมด เป็นต้น
หลังจากชี้แจงสถาปัตยกรรมแล้ว ขั้นตอนต่อไปคือการแก้ไขข้อกำหนดการทำงานหลัก เนื่องจากมีการใช้วิธีสัญญาหลัก-รอง จึงจำเป็นต้องชี้แจงว่าฟังก์ชันใดดำเนินการตามสัญญาหลัก และฟังก์ชันใดดำเนินการโดยสัญญาย่อย และทั้งสองถูกส่งผ่านข้อมูลภายในใดที่มีการสื่อสาร และวิธีย้อนกลับข้อมูลก่อนหน้าเมื่อเกิดข้อผิดพลาดในการดำเนินการ โดยปกติ ก่อนที่จะพัฒนาโครงการขนาดใหญ่ที่ซับซ้อน จำเป็นต้องส่งคลาสไดอะแกรมและชี้แจงการไหลของข้อมูลระหว่างกัน และคิดอย่างรอบคอบเกี่ยวกับตรรกะการย้อนกลับหลังจากการเรียกภายในล้มเหลว แน่นอนว่าการพัฒนา NFT ข้างต้นนั้นเรียบง่าย แต่ก็สามารถทำการตรวจสอบที่คล้ายกันได้เช่นกัน
เรียนรู้การพัฒนาสัญญาอัจฉริยะ TON จากซอร์สโค้ด
TON เลือกออกแบบภาษาที่พิมพ์แบบคงที่คล้าย C ชื่อ Func เป็นภาษาการพัฒนาสัญญาอัจฉริยะ จากนั้นให้เราเรียนรู้วิธีพัฒนาสัญญาอัจฉริยะของ TON จากซอร์สโค้ด ฉันเลือกตัวอย่าง NFT ในเอกสารอย่างเป็นทางการของ TON . เพื่อนๆ ที่สนใจสามารถตรวจสอบได้ด้วยตนเอง ในกรณีนี้ จะมีการนำตัวอย่าง TON NFT แบบธรรมดามาใช้ มาดูโครงสร้างสัญญาซึ่งแบ่งออกเป็นสัญญาการทำงานสองสัญญาและไลบรารีที่จำเป็นสามแห่ง
สัญญาการทำงานหลักทั้งสองนี้ได้รับการออกแบบตามหลักการข้างต้น ขั้นแรกให้เราดูที่โค้ดของสัญญาหลัก nft-collection:
นี่เป็นการแนะนำประเด็นความรู้แรก วิธีจัดเก็บข้อมูลอย่างต่อเนื่องในสัญญาอัจฉริยะ TON เรารู้ว่าการจัดเก็บข้อมูลแบบถาวรใน Solidity จะได้รับการจัดการโดยอัตโนมัติโดย EVM ตามประเภทของพารามิเตอร์ โดยปกติแล้ว ตัวแปรสถานะของสัญญาอัจฉริยะ จะถูกคงอยู่และจัดเก็บโดยอัตโนมัติตามค่าล่าสุดหลังการดำเนินการ และนักพัฒนาไม่จำเป็นต้องพิจารณากระบวนการนี้ แต่นี่ไม่ใช่กรณีใน Func นักพัฒนาจำเป็นต้องใช้ตรรกะการประมวลผลที่เกี่ยวข้องด้วยตนเอง สถานการณ์นี้ค่อนข้างคล้ายกับวิธีที่ C และ C++ จำเป็นต้องพิจารณากระบวนการ GC แต่ภาษาการพัฒนาใหม่อื่น ๆ มักจะทำให้ส่วนนี้ของตรรกะเป็นแบบอัตโนมัติ . มาดูโค้ดกันก่อน อันดับแรก เราจะแนะนำไลบรารีที่จำเป็น จากนั้นเราจะเห็นว่าฟังก์ชันแรก load_data ถูกใช้เพื่ออ่านข้อมูลที่เก็บไว้อย่างต่อเนื่อง เสร็จสิ้นโดยมาตรฐานที่ดำเนินการโดยไลบรารี stdlib.fc ฟังก์ชันบางอย่างมักจะสามารถใช้เป็นฟังก์ชันของระบบได้
ประเภทค่าตอบแทนของฟังก์ชันนี้คือเซลล์ ซึ่งเป็นประเภทเซลล์ใน TVM ในบทนำก่อนหน้านี้ เราทราบแล้วว่าข้อมูลถาวรทั้งหมดในบล็อกเชน TON ถูกจัดเก็บไว้ในแผนผังเซลล์ แต่ละเซลล์มีข้อมูลที่กำหนดเองได้สูงสุด 1,023 บิตและมีการอ้างอิงถึงเซลล์อื่นได้สูงสุดสี่รายการ เซลล์ถูกใช้เป็นหน่วยความจำใน TVM แบบสแต็ก สิ่งที่เก็บไว้ในเซลล์คือข้อมูลที่เข้ารหัสแบบกะทัดรัด เพื่อให้ได้ข้อมูลข้อความธรรมดาที่เฉพาะเจาะจง เซลล์จะต้องถูกแปลงเป็นประเภทที่เรียกว่าสไลซ์ เซลล์สามารถแปลงเป็นประเภทสไลซ์ได้โดยใช้ฟังก์ชัน beginning_parse จากนั้นสามารถรับข้อมูลในเซลล์ได้โดยการโหลดบิตข้อมูลจากสไลซ์และอ้างอิงไปยังเซลล์อื่น โปรดทราบว่าวิธีการเรียกในบรรทัดที่ 15 คือ syntactic sugar ใน func ซึ่งช่วยให้คุณสามารถเรียกใช้ฟังก์ชันที่สองที่คืนค่าของฟังก์ชันแรกได้โดยตรง และสุดท้ายก็โหลดข้อมูลที่เกี่ยวข้องตามลำดับการคงอยู่ของข้อมูล โปรดทราบว่ากระบวนการนี้แตกต่างจากความแข็ง และไม่ได้ถูกเรียกตามแฮชแมป ดังนั้นจึงไม่สามารถทำให้ลำดับการโทรยุ่งเหยิงได้
ในฟังก์ชัน save_data ตรรกะจะคล้ายกัน ยกเว้นว่านี่เป็นกระบวนการย้อนกลับ ซึ่งแนะนำจุดความรู้ถัดไป ตัวสร้างชนิดใหม่ ซึ่งเป็นประเภทของตัวสร้างเซลล์ บิตข้อมูลและการอ้างอิงไปยังเซลล์อื่นสามารถจัดเก็บไว้ในตัวสร้าง ซึ่งสามารถสรุปเป็นเซลล์ใหม่ได้ ขั้นแรกให้สร้างตัวสร้างผ่านฟังก์ชันมาตรฐาน beginning_cell และจัดเก็บฟังก์ชันที่เกี่ยวข้องผ่านฟังก์ชันที่เกี่ยวข้องกับร้านค้าตามลำดับ โปรดทราบว่าลำดับการเรียกด้านบนจะต้องสอดคล้องกับลำดับการจัดเก็บข้อมูลที่นี่ ในที่สุด เซลล์ใหม่จะถูกสร้างขึ้นผ่าน end_cell ในเวลานี้ เซลล์ได้รับการจัดการในหน่วยความจำ สุดท้ายนี้ สามารถจัดเก็บข้อมูลถาวรของเซลล์ได้ผ่าน set_data
ต่อไป เรามาดูฟังก์ชันที่เกี่ยวข้องกับธุรกิจกันก่อน อันดับแรก เราต้องแนะนำประเด็นความรู้ถัดไป วิธีสร้างสัญญาใหม่ผ่านสัญญา ซึ่งจะใช้บ่อยในสถาปัตยกรรมแบบ master-slave ที่เพิ่งเปิดตัว เรารู้ว่าใน TON การโทรระหว่างสัญญาอัจฉริยะจะดำเนินการโดยการส่งข้อความภายใน ซึ่งทำได้ผ่านข้อความที่เรียกว่า send_raw_message โปรดทราบว่าพารามิเตอร์แรกคือเซลล์ที่เข้ารหัสข้อความ และพารามิเตอร์ตัวที่สองคือบิตระบุตัวตน ซึ่งใช้เพื่อระบุความแตกต่างในวิธีดำเนินการของธุรกรรม ใน TON ขณะนี้มีโหมดข้อความ 3 โหมดและแฟล็กข้อความ 3 โหมดสำหรับโหมดการดำเนินการส่งข้อความ โหมดเดียวสามารถรวมกับแฟล็กหลายตัว (อาจไม่มีเลย) เพื่อให้ได้โหมดที่ต้องการ การรวมหมายถึงเพียงการเติมผลรวมของค่าเหล่านั้น ตารางคำอธิบายของโหมดและแฟล็กแสดงไว้ด้านล่าง:
มาดูฟังก์ชันหลักแรกกันดีกว่า คือ upload_nft_item ตามชื่อ นี่คือฟังก์ชันที่ใช้ในการสร้างหรือส่งอินสแตนซ์ NFT ใหม่ หลังจากเข้ารหัสข้อความแล้ว สัญญาภายในจะถูกส่งผ่าน send_raw_message และเลือกสถานะการส่ง บิตธง 1 ใช้เฉพาะค่าธรรมเนียมที่ระบุในการเข้ารหัสเป็นค่าธรรมเนียมแก๊สสำหรับการดำเนินการนี้ หลังจากการแนะนำข้างต้น เราสามารถทราบได้อย่างง่ายดายว่ากฎการเข้ารหัสนี้ควรสอดคล้องกับวิธีสร้างสัญญาอัจฉริยะใหม่ มาดูกันว่ามีการใช้งานอย่างไร
ลองดูที่บรรทัดที่ 51 กัน ทั้งสองฟังก์ชันข้างต้นเป็นฟังก์ชันเสริมที่ใช้ในการสร้างข้อมูลที่จำเป็นสำหรับข้อความ ดังนั้นเราจะดูในภายหลัง นี่คือกระบวนการเข้ารหัสสำหรับการสร้างข้อความภายในของสัญญาอัจฉริยะ ตรงกลางเป็นบิตระบุตัวตนบางส่วนใช้เพื่ออธิบายข้อกำหนดของข้อความภายใน TON เลือกภาษาไบนารี่ที่เรียกว่า TL-B เพื่ออธิบายวิธีการดำเนินการของข้อความและนำไปใช้โดยการตั้งค่าสถานะที่แตกต่างกัน บิต สำหรับข้อมูลภายในเกี่ยวกับฟังก์ชันเฉพาะบางอย่าง สองสถานการณ์การใช้งานที่ง่ายที่สุดที่ควรนึกถึงคือการสร้างสัญญาใหม่และปรับใช้การเรียกใช้ฟังก์ชันสัญญา วิธีการในบรรทัด 51 สอดคล้องกับวิธีแรก โดยสร้างสัญญารายการ nft ใหม่ ซึ่งส่วนใหญ่จะระบุด้วยบรรทัด 55, 56 และ 57 ประการแรก ชุดตัวเลขขนาดใหญ่ในบรรทัด 55 คือชุดของบิตระบุตัวตน โปรดทราบว่าพารามิเตอร์อินพุตแรกของ store_uint คือค่า และตัวที่สองคือความยาวบิต ซึ่งกำหนดว่าข้อความภายในถูกสร้างขึ้นโดยสัญญาหรือไม่ บิตการทำเครื่องหมายสามบิตสุดท้ายและบิตที่สอดคล้องกัน บิตค่าไบนารี่คือ 111 (4+ 2+ 1 เป็นทศนิยม) สองบิตแรกระบุว่าข้อความจะมาพร้อมกับข้อมูล StateInit ซึ่งเป็นซอร์สโค้ดของใหม่ สัญญาและข้อมูลที่จำเป็นสำหรับการเริ่มต้น บิตแฟล็กหลังบ่งชี้ถึงสิ่งที่แนบข้อความภายใน นั่นคือ ตรรกะที่เกี่ยวข้องและพารามิเตอร์ที่จำเป็นคาดว่าจะดำเนินการ ดังนั้น คุณจะเห็นว่าข้อมูลสามหลักไม่ได้ถูกตั้งค่าไว้ในบรรทัดที่ 66 ของโค้ด ซึ่งบ่งชี้ถึงการเรียกใช้ฟังก์ชันไปยังสัญญาที่ปรับใช้ กฎการเข้ารหัสโดยละเอียดสามารถพบได้ที่นี่
จากนั้น กฎการเข้ารหัสของ StateInit จะสอดคล้องกับโค้ด 49 บรรทัด ซึ่งคำนวณผ่าน Calculator_nft_item_state_init โปรดทราบว่าการเข้ารหัสข้อมูล stateinit ยังเป็นไปตามกฎการเข้ารหัส TL-B ที่กำหนดไว้อีกด้วย นอกเหนือจากบิตแฟล็กบางส่วนแล้ว ส่วนใหญ่จะเกี่ยวข้องกับสัญญาใหม่สองส่วน รหัสและและเริ่มต้นข้อมูล ลำดับการเข้ารหัสข้อมูลจะต้องสอดคล้องกับลำดับการจัดเก็บของเซลล์คงอยู่ที่ระบุในสัญญาใหม่ ดังที่คุณเห็นในบรรทัดที่ 36 ข้อมูลการเริ่มต้นประกอบด้วย item_index ซึ่งคล้ายกับ tokenId ใน ERC 721 และที่อยู่สัญญาปัจจุบันที่ส่งคืนโดยฟังก์ชันมาตรฐาน my_address ซึ่งเป็น collection_address ลำดับของข้อมูลนี้สอดคล้องกับการประกาศ ใน nft-item
จุดความรู้ถัดไปคือใน TON สัญญาอัจฉริยะที่ยังไม่ได้สร้างทั้งหมดสามารถคำนวณที่อยู่ที่สร้างขึ้นล่วงหน้าได้ ซึ่งคล้ายกับฟังก์ชัน create 2 ใน Solidity การสร้างที่อยู่ใหม่ใน TON ประกอบด้วยสองส่วนคือ workchain บิตระบุตัวตนจะถูกต่อเข้าด้วยกัน ด้วยค่าแฮชของ stateinit ดังที่เราได้เห็นในบทนำก่อนหน้านี้ จำเป็นต้องระบุค่าแรกเพื่อให้สอดคล้องกับสถาปัตยกรรมการแบ่งส่วนแบบไม่สิ้นสุดของ TON ซึ่งปัจจุบันเป็นค่าแบบรวม ได้มาจากเวิร์กเชนฟังก์ชันมาตรฐาน อย่างหลังได้มาจากฟังก์ชันมาตรฐาน cell_hash กลับมาที่ตัวอย่างนี้ Calculator_nft_item_address เป็นฟังก์ชันที่คำนวณที่อยู่สัญญาใหม่ล่วงหน้า และเข้ารหัสค่าที่สร้างขึ้นลงในข้อความในบรรทัด 53 เป็นที่อยู่รับของข้อความภายใน nft_content สอดคล้องกับการเรียกการเริ่มต้นของสัญญาที่สร้างขึ้น เราจะแนะนำการใช้งานเฉพาะในบทความถัดไป
สำหรับ send_royalty_params นั้น จะต้องเป็นการตอบสนองต่อข้อความภายในของคำขอแบบอ่านอย่างเดียว ในบทนำก่อนหน้านี้ เราเน้นเป็นพิเศษว่าข้อความภายในใน TON ไม่เพียงแต่ประกอบด้วยการดำเนินการที่อาจแก้ไขข้อมูลเท่านั้น แต่ยังรวมถึงการอ่าน- การดำเนินการจะต้องดำเนินการในลักษณะนี้เท่านั้น การดำเนินการตามสัญญานี้จึงเป็นการดำเนินการดังกล่าว ก่อนอื่น ควรสังเกตว่าบรรทัดที่ 67 แสดงถึงเครื่องหมายของฟังก์ชันการโทรกลับของผู้ร้องขอหลังจากตอบกลับคำขอแล้ว จะเป็นข้อมูลที่ส่งคืนซึ่งเป็นดัชนีรายการที่ร้องขอและข้อมูลค่าลิขสิทธิ์ที่เกี่ยวข้อง
ต่อไป ให้เราแนะนำจุดความรู้ถัดไป มีทางเข้าแบบรวมเพียงสองทางสำหรับสัญญาอัจฉริยะใน TON ชื่อ recv_internal และ recv_external ข้อความ การพัฒนา ผู้ดำเนินการจำเป็นต้องใช้วิธีเหมือนสวิตช์เพื่อตอบสนองต่อคำขอที่แตกต่างกันโดยยึดตามบิตสถานะที่แตกต่างกันที่ระบุโดยข้อความภายในฟังก์ชันตามข้อกำหนด บิตสถานะที่นี่คือการตั้งค่าสถานะฟังก์ชันการเรียกกลับในบรรทัดที่ 67 ข้างต้น กลับไปที่ตัวอย่างนี้ ขั้นแรกให้ทำการตรวจสอบตำแหน่งว่างในข้อความ จากนั้นแยกวิเคราะห์ข้อมูลในข้อความตามลำดับ ขั้นแรก ให้แยกวิเคราะห์ในบรรทัด 83 เพื่อรับ sender_address นี่เป็นของน้ำตาลไวยากรณ์อื่น ฉันจะไม่ขยายความที่นี่ ถัดไป บิตแฟล็กการดำเนินการ op จะถูกแยกวิเคราะห์ จากนั้นคำขอที่เกี่ยวข้องจะถูกประมวลผลตามบิตแฟล็กที่แตกต่างกัน ในหมู่พวกเขาฟังก์ชันข้างต้นจะถูกเรียกตามลำดับตามตรรกะบางอย่าง ตัวอย่างเช่น ตอบสนองต่อคำขอพารามิเตอร์ค่าลิขสิทธิ์ หรือส่ง nft ใหม่และเพิ่มดัชนีส่วนกลาง
จุดความรู้ถัดไปสอดคล้องกับบรรทัดที่ 108 ฉันคิดว่าคุณสามารถทราบตรรกะการประมวลผลของฟังก์ชันนี้ได้ด้วยการตั้งชื่อ คล้ายกับฟังก์ชัน need ใน Solidity ข้อยกเว้นจะถูกส่งใน Func ผ่านฟังก์ชันมาตรฐาน Throw_unless พารามิเตอร์อินพุตแรกคือ รหัสข้อผิดพลาด ประการที่สองคือการตรวจสอบค่าบูลีนของบิต หากบิตเป็นเท็จ ข้อยกเว้นจะถูกส่งออกไปพร้อมกับรหัสข้อผิดพลาด ในบรรทัดนี้ จะใช้เท่ากับ _slices เพื่อพิจารณาว่า sender_address ที่แยกวิเคราะห์ข้างต้นนั้นเท่ากับ Owner_address ของที่เก็บข้อมูลถาวรของสัญญาหรือไม่ และจะมีการตัดสินสิทธิ์
สุดท้ายนี้ เพื่อให้โครงสร้างโค้ดชัดเจนขึ้น ชุดฟังก์ชันเสริมได้รับการพัฒนาเพื่อช่วยให้รับข้อมูลการคงอยู่ ซึ่งจะไม่ถูกนำมาใช้ในที่นี้ นักพัฒนาสามารถอ้างถึงโครงสร้างนี้เพื่อพัฒนาสัญญาอัจฉริยะของตนเองได้
การพัฒนา DApp ในระบบนิเวศ TON นั้นน่าสนใจจริงๆ และแตกต่างจากกระบวนทัศน์การพัฒนาของ EVM มาก ดังนั้นฉันจะแนะนำวิธีพัฒนา DApp ใน TON Chain ผ่านบทความชุดต่างๆ เรียนรู้ร่วมกับทุกคนและคว้าโอกาสนี้ คุณสามารถโต้ตอบกับฉันบน Twitter เพื่อคิดไอเดีย DApp ใหม่ๆ ที่น่าสนใจและพัฒนาร่วมกันได้
