دليل تطوير مشروع TON (1): كيفية إنشاء NFT على سلسلة TON من وجهة نظر رمز المصدر

** المؤلف **: @Web3Mario (_mario)

موجز : بعد أخذ الاقتباس من المقال السابق حول تقديم تقنية TON ، قمت بالبحث العميق في الوثائق الرسمية لتطوير TON خلال هذه الفترة. أجد أنه من الصعب بعض الشيء تعلمها ، حيث يبدو محتوى الوثائق الحالية وكأنه وثيقة تطوير داخلية بالفعل. بالنسبة للمطورين الجدد ، فإنها ليست ودية جدًا. لذلك حاولت تنظيم سلسلة من المقالات حول تطوير مشروع TON Chain وفقًا لمسار تعلمي الخاص ، عسى أن تكون مفيدة للجميع في الدخول السريع لتطوير تطبيقات TON. نرحب بكل تصحيح للأخطاء في الكتابة ، ونتعلم معًا.

ما هي الاختلافات بين تطوير NFT على EVM وتطوير NFT على TON Chain

إصدار FT أو NFT هو طلب أساسي بالنسبة لمطوري DApp. لذلك ، سأستخدم ذلك كنقطة البدء في التعلم. دعنا نتعرف أولاً على الفرق بين تطوير NFT في EVM وعلى TON Chain. عادةً ما يختار NFT القائم على EVM استدعاء معيار ERC-721. يشير مصطلح NFT إلى نوع من الأصول المشفرة غير القابلة للتجزئة ، ويتمتع كل منها بالفرادة ، أي بعض الخصائص الحصرية. ويعد ERC-721 نموذجًا عامًا لتطوير هذا النوع من الأصول. لنلقي نظرة على الدوال التي يحتاج عقد ERC721 الشائع إلى تنفيذها وتسجيل أي معلومات. الشكل أدناه هو واجهة ERC721. يمكن ملاحظة الاختلاف بينه وبين FT في واجهة التحويل حيث يحتاج الإدخال إلى رقم tokenId المراد نقله بدلاً من الكمية. يعد هذا الرقم المعرف للأصول NFT أساسيًا للغاية لفرادتها. بالطبع ، ولكي تحمل المزيد من السمات ، يتم تسجيل بيانات وصفية لكل tokenId وهو رابط خارجي يحتوي على بيانات NFT القابلة للتوسيع الأخرى ، مثل رابط صورة PFP وأسماء الخصائص الأخرى.

بالنسبة للمطورين الذين يعرفون جيدًا Solidity أو يفهمون البرمجة الشيئية، فإن تنفيذ عقد ذكي من هذا النوع أمر سهل، بمجرد تحديد أنواع البيانات اللازمة في العقد، مثل بعض العلاقات الرئيسية للتعيينات mapping، وتطوير المنطق المناسب لتعديل هذه البيانات وفقًا للوظائف المطلوبة، يمكن تنفيذ NFT.

ولكن في سلسلة TON ، تتغير كل هذه الأمور بشكل مختلف ، وهناك سببان رئيسيان لذلك:

• تخزين البيانات في TON يعتمد على الخلية ، ويتم تحقيق خلية نفس الحساب من خلال الرسم البياني الحلقي الموجه. وهذا يؤدي إلى عدم قدرة البيانات التي تحتاج إلى التخزين الدائم على النمو بلا حدود ، لأن العمق في الرسم البياني الحلقي الموجه يحدد تكلفة الاستعلام ، وعندما يمتد العمق بشكل لا محدود ، فقد يؤدي ذلك إلى تكلفة استعلام مرتفعة ، مما يؤدي إلى مشكلة العقد الميت.
• لتحقيق أداء عالي للتزامن ، أسقط TON الهندسة المعمارية التسلسلية واعتمد بدلاً من ذلك نموذجًا مخصصًا للتوازي والنموذج التنفيذي ** نموذج الممثل **. هذا يؤدي إلى تأثير واحد ، وهو أن العقود الذكية يمكنها الاتصال ببعضها البعض بطريقة غير متزامنة فقط عن طريق إرسال ما يسمى رسائل داخلية ، لاحظ أنه من الضروري اتباع هذا المبدأ بغض النظر عن نوع الاستدعاء سواء كان نوع تعديل الحالة أو نوع القراءة فقط ، بالإضافة إلى ذلك ، يجب التفكير بعناية في كيفية معالجة عمليات الرجوع في حال فشل الاستدعاء الغير متزامن.

بالطبع، يوجد تفصيل مفصل حول النقاط المختلفة الأخرى من الناحية التقنية في المقالة السابقة، ويأمل هذا المقال في التركيز على تطوير العقود الذكية، لذا لن نناقش ذلك. تجعل مبادئ التصميم السابقة الاثنين تطوير العقود الذكية في TON مختلفًا إلى حد كبير عن EVM. في بداية التحليل، نعرف أن عقد NFT يحتاج إلى تعريف بعض العلاقات التبادلية، أي mapping، لحفظ البيانات ذات الصلة بـ NFT. من بينها الأهم هو owners، هذا ال mapping يحفظ العلاقات التبادلية لعنوان مالك NFT المرتبط بـ tokenID معين، ويحدد ملكية NFT، حيث يعد التحويل تعديلًا لهذه الملكية. نظرًا لأن هذا هيكل بيانات يمكن أن يكون لا حدود له في النظرية، فيجب تجنبه قدر الإمكان. ولذلك، يُوصَى رسميًا بأن يُعتَبَرَ وجود هيكل بيانات لا حدود له معيارًا للتقسيم. أي عندما يكون هناك حاجة مماثلة لتخزين البيانات، يُفضل تعويضها بنمط العقد الفرعي، عن طريق إنشاء العقود الفرعية لإدارة البيانات المرتبطة بكل مفتاح. وعن طريق إدارة المعلمات العامة من خلال العقد الرئيسي، أو مساعدة تبادل المعلومات الداخلية بين العقود الفرعية.

وهذا يعني أيضًا أن الـ NFT في TON يجب أن تستخدم نفس الهيكل المعماري للتصميم ، حيث يتم حفظ كل NFT كعقد فرعي مستقل يحتوي على بيانات حصرية مثل عنوان المالك والبيانات الوصفية ويتم إدارة البيانات العالمية عن طريق عقد أساسي ، مثل اسم NFT ورمزها وإجمالي العرض ، وما إلى ذلك.

بعد تحديد الهيكل، يجب حل متطلبات الوظائف الأساسية. نظرًا لاستخدام العقد الرئيسي / الفرعي، يجب تحديد الوظائف التي يتم تحملها بواسطة العقد الرئيسي وتلك التي يتم تحملها بواسطة العقد الفرعي، وكيفية التواصل بينهما عن طريق المعلومات الداخلية. وفي نفس الوقت، عند حدوث خطأ في التنفيذ، مثل كيفية التراجع عن البيانات السابقة. عادةً ما يكون من الضروري قبل تطوير مشروع كبير ومعقد أن يتم تحديد تدفق المعلومات بينها من خلال الرسم البياني للفئة والتفكير بعناية في منطق التراجع بعد فشل الاستدعاء الداخلي. بالطبع، على الرغم من أن تطوير NFT المذكور أعلاه بسيط، يمكن أيضًا القيام بالتحقق المماثل.

من دراسة الشفرة المصدرية لتطوير عقود TON الذكية

TONاختار تصميم لغة مثل C جامعة النوع الثابتة التي تدعى Func كلغة تطوير العقد الذكية، ثم لنتعلم كيف نقوم بتطوير عقد TON الذكي من المصدر المائي، قد اختارت المثال الخاص بالنقل الغير منتبه في وثائق TON الرسمية، يمكن للزملاء الصغر الموافقة على البحث بنفسهم، في هذا الحالة تم تنفيذ مثال نقل TON نفذاً للعقد، شاهدنا الهيكل العقدي، يتكون من عقدين وظائف ثلاثة مطلوبة.

هذان العقدين الذكيين الرئيسيين مصممان وفقًا للمبادئ المذكورة أعلاه، دعونا نلقي نظرة على كود العقد الرئيسي nft-collection أولاً:

هذا يدخلنا في أول نقطة معرفية، وهي كيفية الحفاظ على تخزين البيانات في عقود TON الذكية، نحن نعلم أن تخزين البيانات في Solidity يتم تلقائياً بواسطة EVM وفقًا لنوع المعلمة، وعادة ما يتم حفظ متغيرات حالة العقد الذكية تلقائياً بناءً على قيمتها الأحدث بعد انتهاء التنفيذ، وبالتالي لا يحتاج المطورون إلى النظر في هذه العملية. ومع ذلك، في Func الأمر ليس كذلك، حيث يحتاج المطورون إلى تنفيذ المنطق المقابل بأنفسهم، وهذا الحال يشبه إلى حد ما حاجة لغة C وC++ إلى النظر في عملية GC، ولكن اللغات البرمجية الجديدة الأخرى عادة ما تعالج هذا الجزء تلقائياً. دعونا نلقي نظرة على الشيفرة، أولاً يتم استيراد بعض المكتبات اللازمة، ثم نرى الدالة الأولى load_data المستخدمة لقراءة البيانات المُحفوظة، حيث يتم الحصول على خلية تخزين العقد المُحفوظة أولاً من خلال get_data، يرجى ملاحظة أن هذا مُنجز بواسطة مكتبة stdlib.fc القياسية، وعادةً ما يمكن اعتبار بعض هذه الدوال كدوال نظامية للاستخدام.

نوع قيمة الإرجاع لهذه الدالة هو الخلية ، وهو نوع الخلية في TVM. في المقدمة السابقة ، نعلم بالفعل أن جميع البيانات الثابتة في TON البلوكتشين مخزنة في شجرة الخلية. تحتوي كل خلية على طويل 1023 بت من البيانات التعسفية طويل أربعة مراجع لخلايا أخرى. يتم استخدام الخلية كذاكرة في TVM المستند إلى المكدس. تحتوي الخلية على بيانات مشفرة بإحكام ، وفي طلب للحصول على بيانات النص العادي المحددة فيها ، تحتاج إلى تحويل الخلية إلى نوع يسمى شريحة. يمكن تحويل الخلية إلى نوع شريحة بواسطة الدالة start_parse ، ومن ثم يمكن الحصول على البيانات الموجودة في الخلية عن طريق تحميل بتات البيانات والمراجع إلى خلايا أخرى من الشريحة. لاحظ أن طريقة الاستدعاء هذه في السطر 15 من الكود هي سكر نحوي في func يمكنه استدعاء الوظيفة الثانية مباشرة لقيمة إرجاع الوظيفة الأولى. في النهاية ، يتم تحميل البيانات المقابلة في طلب ثبات البيانات. لاحظ أن هذه العملية تختلف عن الصلابة ، فهي لا تعتمد على hashmap ، لذلك لا ينبغي إفساد طلب هذه المكالمة.

في دالة save_data، العملية مشابهة للعملية اللوجيكية، ولكن هذه هي عملية عكسية، وهذا يقدم نقطة معرفة جديدة، وهي نوع جديد من البنّاء، وهو بنّاء الخلية. يمكن تخزين بتات البيانات والإشارات إلى الخلايا الأخرى في البنّاء، ثم يمكن تحويل البنّاء إلى خلية جديدة في النهاية. أولاً، يتم إنشاء بنّاء باستخدام الدالة begin_cell، ثم يتم تخزين البيانات بالتسلسل باستخدام دوال التخزين ذات الصلة، يجب ملاحظة أن ترتيب الاستدعاء في النص السابق يجب أن يكون متسقاً مع ترتيب التخزين هنا. في النهاية، يتم الانتهاء من بناء الخلية الجديدة باستخدام دالة end_cell، وهنا يتم تخزين الخلية في الذاكرة، وأخيراً، باستخدام دالة set_data الخارجية، يتم الانتهاء من تخزين الخلية بشكل دائم.

ثم دعونا نلقي نظرة على الدوال المتعلقة بالعملية ، أولاً يجب أن نقدم نقطة معرفة واحدة ، كيفية إنشاء عقد جديد من خلال عقد ، وهذا سيكون مفيدًا في الهندسة المعمارية الرئيسية والفرعية التي تمت مناقشتها للتو. نعلم أن الاتصال بين العقود الذكية في TON يتم عن طريق إرسال رسائل داخلية. يتم تنفيذ ذلك باستخدام دالة تسمى send_raw_message. يتم تمرير البرنامج النصي المشفر بالخلية كمعامل أول ، ويتم استخدام العلامة التجارية كمعامل ثاني للإشارة إلى الفروق في طريقة تنفيذ المعاملة ، تم تعيين طرق تنفيذ مختلفة لإرسال الرسائل الداخلية في TON ، حاليًا يوجد 3 أوضاع للرسائل و 3 أعلام للرسائل. يمكنك دمج وضع واحد فقط مع العديد من العلامات (ربما لا تكون) للحصول على الوضع المطلوب. المزيج يعني فقط ملء قيمهما. يتم تقديم جدول يصف وضع وعلامات كما يلي:

لذا دعونا نلقي نظرة على الدالة الرئيسية الأولى، deploy_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 سطرا من التعليمات البرمجية ، محسوبة عن طريق حساب \ _nft \ _item \ _state \ _init ، لاحظ أن ترميز بيانات stateInit يتبع أيضا قاعدة ترميز TL-B ثابتة ، باستثناء بعض بتات العلامة ، فإنه يتضمن بشكل أساسي جزأين من رمز العقد الجديد وبيانات التهيئة. يجب أن يكون طلب تشفير البيانات متسقا مع طلب التخزين للخلية الثابتة المحددة في العقد الجديد. في السطر 36 ، يمكنك أن ترى أن بيانات التهيئة تحتوي على item_index ، وهو مشابه ل tokenId في ERC721 ، العنوان إرجاع العقد الحالي بواسطة الدالة القياسية my \ _address ، أي collection \ _address ، ويتوافق طلب هذه البيانات مع الإعلان في nft-item.

واحدة من نقاط المعرفة التالية هي أنه في TON ، يمكن حساب عنوان العقد الذكي الذي لم يتم توليده مسبقًا ، وهذا يشبه وظيفة create2 في Solidity. في TON ، يتكون إنشاء عنوان جديد من جزئين: واحد هو جزء تعريف workchain المميز برمز واحد وقيمة موحدة حسب الوقت الحالي ، والآخر هو قيمة دالة cell_hash المعيارية لتجزئة الحالة. لذلك ، في هذا المثال ، calculate_nft_item_address هو الدالة التي يتم بها حساب عنوان العقد الجديد مسبقًا. ويتم ترميز القيمة المحددة في السطر 53 في الرسالة ، كعنوان استقبال لهذه الرسالة الداخلية. بينما يتوافق nft_content مع استدعاء التهيئة للعقد الذي تم إنشاؤه ، وسيتم توضيح التفاصيل في المقالة التالية.

بالنسبة لـ send_royalty_params ، يجب أن يكون استجابة لرسالة داخلية لطلب قراءة ، كما أشرنا في التعريف السابق ، فإن الرسائل الداخلية في TON لا تحتوي فقط على العمليات التي قد تقوم بتعديل البيانات ، بل تحتاج أيضًا إلى تنفيذ عمليات القراءة من خلال هذا النوع من الرسائل. لذلك ، يتعلق هذا العقد بعمليات مثل هذه. يجب أن نلاحظ أولاً علامة استدعاء دالة الرد على المطالبة للمستجيب بعد الاستجابة للطلب ، وتسجيل البيانات المرتدة ، وهي فهرس العنصر المطلوب ، بالإضافة إلى بيانات royalty المقابلة.

تابع قراءة التفاصيل، إذ يوجد فقط نقطتي دخول موحدتين للعقود الذكية في TON، وتسمى recv_internal و recv_external، حيث يعد الأول نقطة الدخول الموحدة لجميع الرسائل الداخلية، والثاني نقطة الدخول الموحدة لجميع الرسائل الخارجية. يحتاج المطورون إلى استخدام switch بنفس طريقة العمل في الدالة وفقًا للعلامة المحددة بواسطة الرسالة والتي تمثل العلامة المحددة في دالة الرد الخاصة بالدالة. تتعلق تلك العلامة المحددة بالدالة التي تمت ذكرها في السطر 67. في هذا المثال، يتم التحقق أولاً من الفراغ في الرسالة، وبعد ذلك يتم تحليل المعلومات في الرسالة. في السطر 83، يتم تحليل عنوان المرسل، وسيتم استخدام هذا المعلم في التحقق من الأذونات لاحقًا. الرجاء ملاحظة عملية العمل ~ هنا، وهي عبارة عن بنية تحتية مختلفة. لن نتعمق فيها في الوقت الحالي. بعد ذلك، يتم تحليل علامة العملية op، ثم يتم التعامل مع الطلبات المختلفة وفقًا لعلامة العملية المحددة. ويتم استدعاء الدوال المذكورة سابقًا وفقًا لبعض العمليات المنطقية، مثل الاستجابة لمعلمة النصيب، أو السك، وإنتاج NFT جديد، وزيادة الفهرس العام.

النقطة المعرفة التالية تطابق الخط 108 ، ومن المؤكد أن الجميع يمكنه معرفة تفاصيل معالجة الدالة من خلال التسمية. في Func ، يتم طرح الاستثناءات باستخدام الدالة throw_unless القياسية ، حيث يكون المعلمة الأولى رمز الخطأ والمعلمة الثانية قيمة boolean للتحقق ، وإذا كانت القيمة false ، فسيتم طرح الاستثناء وتضمين رمز الخطأ. وفي هذا السطر ، يتم استخدام equal_slices للتحقق مما إذا كانت عنوان المرسل المحلل أعلاه متطابقة مع عنوان المالك المستمر لهذا العقد ، كما يتم إجراء التحقق من الصلاحية.

أخيرًا ، لجعل هيكل الشفرة أكثر وضوحًا ، بدأت سلسلة من وظائف المساعدة للحصول على معلومات مستمرة ، ولا نستعرضها هنا ، يمكن للمطورين الاستشارة هذا الهيكل لتطوير عقودهم الذكية الخاصة.

TON البيئة لتطوير التطبيقات اللامركزية هي شيء مثير حقًا، ولها اختلاف كبير مقارنة بنمط تطوير EVM، لذلك سأقوم بتقديم سلسلة من المقالات لشرح كيفية تطوير DApp في سلسلة TON. أتطلع لتعلم الجميع والاستفادة من هذه الفرصة. كما أرحب بتفاعلكم معي على تويتر، واقتراح بعض أفكار DApp الجديدة والمثيرة، والعمل معًا على تطويرها.