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

المؤلف الأصلي: @Web3 Mario (_mario)

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

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

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

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

ومع ذلك، في سلسلة TON، يصبح كل ذلك مختلفًا إلى حد ما، وهناك سببان رئيسيان لهذا التغيير:

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

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

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

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

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

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

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

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

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

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

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

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

لنلق نظرة مباشرة على السطر 51 ، الوظيفتان السابقتان هما وظائف مساعدة لتوليد المعلومات المطلوبة للرسالة ، لذلك سننظر إليها لاحقا ، هذه عملية ترميز لإنشاء رسائل داخلية العقود الذكية ، بعض الأرقام في المنتصف هي في الواقع بعض بتات التعريف ، تستخدم لشرح احتياجات الرسالة الداخلية ، هنا لتقديم نقطة المعرفة التالية ، TON اختار لغة ثنائية تسمى TL-B لوصف تنفيذ الرسالة ، ووفقا للرسائل الداخلية التي تحدد بتات علامات مختلفة لتحقيق بعض الوظائف المحددة ، فإن حالتي الاستخدام الأكثر شيوعا هما إنشاء عقد جديد واستدعاء وظيفة العقد المنشور. تتوافق طريقة السطر 51 هذه مع الطريقة السابقة ، مما يؤدي إلى إنشاء عقد بند NFT جديد ، ويتم تحديد ذلك بشكل أساسي بواسطة الأسطر 55 و 56 و 57. بادئ ذي بدء ، فإن الأسطر ال 55 لهذه السلسلة الكبيرة من الأرقام عبارة عن سلسلة من بتات التعريف ، لاحظ أن معلمة الإدخال الأولى ل store_uint هي القيمة الرقمية ، والثانية هي طول البت ، والتي تحدد أن الرسالة الداخلية تم إنشاؤها بواسطة العقد هي آخر ثلاث بتات علامة ، والقيمة الثنائية المقابلة هي 111 (العلامة العشرية هي 4+ 2 + 1) ، حيث يشير الأولان إلى أن الرسالة ستكون مصحوبة ببيانات StateInit ، وهي الكود المصدري للعقد الجديد ، والبيانات المطلوبة للتهيئة. تشير العلامة الأخيرة إلى أن الرسالة الداخلية مرفقة ، أي المنطق الذي تريد تنفيذه والمعلمات التي تحتاجها. لذلك سترى أن الأرقام الثلاثة لم يتم تعيينها في السطر 66 ، مما يشير إلى استدعاء دالة للعقد المنشور. يمكن العثور على قواعد الترميز المحددة هنا.

لذلك، تتوافق قواعد ترميز StateInit مع 49 سطرًا من الكود، ويتم حسابها من خلال calculate_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 المتعددة الفروع ، وهي قيمة موحدة حاليًا. يمكن الحصول على العلامة الأولى باستخدام الدالة القياسية workchain. يمكن الحصول على الجزء الثاني باستخدام الدالة القياسية cell_hash. لذلك ، في هذا المثال ، تُعد calculate_nft_item_address وظيفة لحساب عنوان العقد الجديد مسبقًا. وسيتم ترميز قيمة الإنشاء في السطر 53 كرسالة في الرسالة ، كعنوان استلام للرسالة الداخلية. بينما يُشار إلى nft_content كما يُشار إلى استدعاء التهيئة للعقد الذي تم إنشاؤه ، وسيتم شرح التفاصيل في المقالة التالية.

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

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

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

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

TON النسيج DApp التنمية مثالية حقائقية مثيرة للإهمام، وهناك فرق كبير التنمية EVM، لذلك سأقوم بالتعريف على كيفية تطوير DApp في TON Chain عبر سلسلة من المقالات، مع الجميع لتعلم واستغلال هذه الفرصة، وكذلك نحن ندعو الجميع للتفاعل معنا عبر التويتر، والاصطدام ببعض الأفكار DApp الجديدة مارسلة، معا لتطوير