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

TON مبادئ التصميم الأساسية - التزامن العالي وقابلية التوسع

يمكن القول أن الغرض من جميع اختيارات التكنولوجيا المعقدة في TON يأتي من السعي لتحقيق التزامن العالي وقابلية التوسع العالية. بالطبع ، ليس من الصعب علينا فهم هذا من خلفية ولادته. TON ، أو الشبكة المفتوحة ، هي شبكة حوسبة لامركزية تتضمن L1 blockchain ومكونات متعددة. تم تطوير TON في الأصل من قبل مؤسس Telegram نيكولاي دوروف وفريقه ، ويتم دعمه وصيانته الآن من قبل مجتمع عالمي من المساهمين المستقلين. يعود تاريخ ولادتها إلى عام 2017 ، عندما بدأ فريق Telegram في استكشاف حلول blockchain لأنفسهم. نظرا لعدم وجود بلوكتشين L1 موجود في ذلك الوقت يمكن أن الدعم قاعدة مستخدمي Telegram المكونة من تسعة أرقام ، فقد قرروا تصميم blockchain الخاص بهم ، ثم أطلق عليهم اسم Telegram Open Network. حان الوقت في عام 2018. في طلب للحصول على الموارد اللازمة لتنفيذ TON ، أطلقت Telegram عملية بيع رموز Gram (أعيدت تسميتها لاحقا Toncoin) في الربع الأول من عام 2018. في عام 2020 ، انسحب فريق Telegram من مشروع TON بسبب مشكلات تنظيمية. بعد ذلك ، استحوذت مجموعة صغيرة من مطوري البرامج مفتوحة المصدر والفائزين في مسابقة Telegram على قاعدة شفرة TON ، وأعادوا تسمية المشروع إلى الشبكة المفتوحة ، واستمروا في تطوير blockchain بنشاط حتى يومنا هذا ، مع الالتزام بالمبادئ الموضحة في الورقة البيضاء TON الأصلية.

نظرا لأن TON تم تصميمه ليكون بيئة تنفيذ لامركزية في Telegram ، كان عليه معالجة تحديين رئيسيين: الطلبات المتزامنة العالية والبيانات الضخمة. حتى أعلى TPS اختبارية (المعاملات في الثانية) من Solana ، والتي تدعي أنها الأسرع ، هي 65000 فقط ، وهي قصير بكثير من TPS مستوى المليون اللازمة ل Telegram. بالإضافة إلى ذلك ، لا يمكن إدارة الكمية الهائلة من البيانات التي تم إنشاؤها بواسطة Telegram بواسطة blockchain حيث تخزن كل عقدة نسخة كاملة من البيانات.

لمواجهة هذه التحديات ، TON تحسين بروتوكولات blockchain السائدة بطريقتين:

ل يستخدم "نموذج مشاركة اللانهائي" لتقليل تكرار البيانات ، مما يمكنه من التعامل مع كميات كبيرة من البيانات وتخفيف اختناقات الأداء.

(ل) من خلال إدخال بيئة تنفيذ متوازية تماما على أساس نموذج الفاعل، تم تحسين TPS الشبكة بشكل كبير؛

بناء البلوكتشين من السلاسل - تزويد كل حساب بسلسلة مخصصة خاصة به من خلال مشاركة اللانهائي

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

في جوهرها ، يتكون هيكل سلسلة TON من أربع طبقات

AccountChain: تمثل هذه الطبقة سلسلة من المعاملات المرتبطة الحساب معين. تشكل المعاملات سلسلة لأنه في آلة الحالة ، تضمن قواعد التنفيذ المتسقة أن آلة الحالة تنتج نفس النتائج عند معالجة التعليمات في نفس طلب. لذلك ، تتطلب جميع أنظمة blockchain ربط المعاملات في سلسلة ، ولا يختلف TON. سلسلة الحساب هي الوحدة الأساسية في شبكة TON. عادة ما تكون سلسلة الحسابات مفهوما ظاهريا ، ومن غير المحتمل أن توجد سلسلة حسابات مستقلة.

ShardChain: في معظم السياقات ، تكون ShardChain هي الوحدة الفعلية داخل TON. ShardChain هي في الأساس مجموعة من سلاسل الحسابات.

WorkChain: تعرف أيضا باسم مجموعة من سلاسل الأجزاء ذات القواعد المخصصة، مثل إنشاء WorkChain استنادا إلى EVM تشغيل Solidity العقود الذكية. من الناحية النظرية، يمكن لأي شخص في المجتمع إنشاء سلسلة العمل الخاصة به. ومع ذلك ، فإن بناء واحد معقد للغاية ويتطلب دفع رسوم الإنشاء (العالية) والحصول على موافقة من 2/3 من المدققون.

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

يمنح هذا النموذج شبكة TON ثلاث ميزات رئيسية:

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

قابلية عالية للتوسع: بفضل نموذج التجزئة اللانهائي ، يمكن TON الدعم عدد غير محدود تقريبا من الأجزاء ، نظريا ما يصل إلى 2 ^ 60 WorkChains.

القدرة على التكيف: عندما يواجه جزء من الشبكة حملا متزايدا ، يمكن تقسيمه إلى المزيد من الأجزاء للتعامل مع الحجم المعاملات الأعلى. على العكس من ذلك ، عندما ينخفض الحمل ، يمكن دمج الأجزاء لتحسين الكفاءة.

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

افترض أن الحساب A في WorkChain 1 يريد إرسال رسالة إلى الحساب C في WorkChain 3. وهذا يتطلب تصميم حل توجيه الرسائل. في هذا المثال، يوجد مساران للتوجيه: WorkChain 1 -> WorkChain 2 -> WorkChain 3، وWorkChain 1 -> WorkChain 4 -> WorkChain 3.

في السيناريوهات الأكثر تعقيدا ، تعد خوارزمية التوجيه الفعالة ومنخفضة التكلفة ضرورية لتوصيل الرسائل بسرعة. يستخدم TON "خوارزمية توجيه hypercube" لاكتشاف توجيه الرسائل عبر السلاسل. بنية المكعب الفائق هي طوبولوجيا شبكة خاصة حيث يحتوي المكعب الفائق ذو الأبعاد n على رؤوس 2 ^ n ، يتم تحديد كل منها بشكل فريد بواسطة رقم ثنائي n-bit. في هذا الهيكل ، يكون أي رأسين متجاورين إذا كانت تمثيلاتهما الثنائية تختلف بمقدار بت واحد فقط. على سبيل المثال ، في المكعب الفائق ثلاثي الأبعاد ، يكون الرأس 000 والرأس 001 متجاورين لأنهما يختلفان فقط في البت الأخير. المثال أعلاه هو hypercube 2 الأبعاد.

في بروتوكول التوجيه hypercube ، يتم توجيه رسالة من WorkChain المصدر إلى WorkChain الهدف عن طريق مقارنة عناوينها الثنائية. تعثر الخوارزمية على الحد الأدنى للمسافة بين هذه العناوين (أي عدد وحدات البت المختلفة) وتعيد توجيه الرسالة عبر WorkChains المجاورة حتى تصل إلى وجهتها. وهذا يضمن أن حزمة البيانات تتبع أقصر مسار ، مما يعزز كفاءة اتصال الشبكة. لتبسيط هذه العملية ، تقدم TON أيضا حلا متفائلا. إذا كان بإمكان المستخدم تقديم دليل صالح على مسار التوجيه ، وعادة ما يكون جذر Merkle trie ، فيمكن للعقدة التحقق على الفور من صحة الرسالة. يعرف هذا باسم التوجيه الفائق الفوري. نتيجة لذلك ، تختلف عناوين TON اختلافا كبيرا عن تلك الموجودة في بروتوكولات blockchain الأخرى. تستخدم معظم بروتوكولات blockchain التجزئة المفتاح العام الذي تم إنشاؤه بواسطة خوارزميات التشفير الإهليلجية كعنوان ، مع التركيز على التفرد دون الحاجة إلى وظائف التوجيه. في TON ، تتكون العناوين من جزأين: (workchain_id ، الحساب_id) ، مع ترميز workchain_id وفقا لخوارزمية توجيه hypercube. قد يتساءل المرء لماذا لا تنقل جميع المعلومات عبر السلاسل خلال MasterChain ، على غرار Cosmos. في تصميم TON ، تتعامل MasterChain فقط مع المهمة الأكثر أهمية المتمثلة في الحفاظ على نهائية سلاسل العمل. في حين أنه من الممكن توجيه الرسائل عبر السلسلة الرئيسية ، فإن الرسوم المرتبطة بها ستكون باهظة للغاية.

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

العقود الذكية التي تستخدم نموذج الفاعل ضمن بيئة تنفيذ متوازية تماما

الاختلاف الرئيسي الآخر في TON مقارنة ببروتوكولات blockchain السائدة هو بيئة تنفيذ العقود الذكية. للتغلب على القيود TPS التي تواجهها بروتوكولات blockchain السائدة ، تستخدم TON نهج تصميم من أسفل إلى أعلى وتوظف نموذج Actor لإعادة بناء العقود الذكية وتنفيذها ، مما يتيح قدرات التنفيذ المتوازية بالكامل.

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

ومع ذلك ، فإن هذه البنية لها أيضا قيود واضحة ، لا سيما عنق الزجاجة TPS ، والذي يبدو قديما مع المعالجات الحديثة متعددة النواة. إنه مشابه للعب ألعاب الكمبيوتر القديمة مثل Red Alert على جهاز كمبيوتر جديد تماما. عندما يصل عدد الوحدات القتالية إلى مستوى معين ، لا تزال تواجه تأخرا كبيرا. هذا بسبب مشكلات هندسة البرمجيات.

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

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

التغليف والاستقلالية: يعمل كل ممثل بشكل مستقل تماما عند معالجة الرسائل ، مما يسمح بمعالجة الرسائل المتوازية دون تدخل.

تمرير الرسالة: تتفاعل الجهات الفاعلة فقط من خلال إرسال الرسائل واستلامها ، مع كون تمرير الرسائل غير متزامن.

الهيكل الديناميكي: يمكن للممثلين إنشاء ممثلين إضافيين في وقت التشغيل ، مما يسمح لنموذج الممثل بتوسيع النظام ديناميكيا حسب الحاجة.

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

1. مكالمات العقد الذكي غير المتزامنة: في TON ، من المستحيل استدعاء العقود الخارجية ذريا أو الوصول إلى بيانات العقد الخارجية داخل العقود الذكية. في Solidity ، على سبيل المثال ، من السهل على وظيفة العقد A1 استدعاء وظيفة العقد B2 أو الوصول إلى بيانات حالة معينة من خلال وظيفة القراءة فقط في العقد C 3 ، كل ذلك في معاملة واحدة. ومع ذلك ، في TON ، لا يمكن تحقيق ذلك. سيتم تنفيذ أي تفاعل مع العقود الذكية الخارجية بشكل غير متزامن عن طريق إنشاء معاملات جديدة ، يشار إليها باسم الرسائل الداخلية التي بدأتها العقود الذكية. لا يمكن حظر عملية التنفيذ لانتظار النتيجة.

على سبيل المثال ، إذا كنا نطور DEX ونتبع نموذج EVM المشترك ، فعادة ما يكون لدينا عقد جهاز توجيه موحد لإدارة توجيه المعاملات ، بينما يدير كل تجمع بشكل مستقل بيانات LP لأزواج تداول محددة. لنفترض أن لدينا مجموعتين: USDT-DAI و DAI-ETH. عندما يرغب المستخدم في شراء ETH مباشرة باستخدام USDT ، يمكنه استخدام عقد جهاز التوجيه للتفاعل بالتتابع مع هذين التجمعين في معاملة ذرية واحدة. ومع ذلك ، في TON ، هذه العملية ليست مباشرة وتتطلب نهجا إنمائيا مختلفا. إذا حاولنا إعادة استخدام نموذج EVM هذا ، فإن تدفق المعلومات سيتضمن رسالة خارجية بدأها المستخدم وثلاث رسائل داخلية لإكمال المعاملة (لاحظ أن هذا المثال هو لتسليط الضوء على الاختلافات ؛ في التطوير الفعلي ، حتى نموذج ERC20 سيحتاج إلى إعادة تصميم).

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

2. في السيناريوهات المعقدة، قد لا تكتمل الحركات التي يتم استلامها أولا أولا، لذلك لا يمكنك افتراض طلب تنفيذ معين. في نظام العقود الذكية غير المتزامن والمتوازي ، قد يكون تحديد طلب المعالجة أمرا صعبا. هذا هو السبب في أن كل رسالة في TON لها وقتها المنطقي ، المعروف باسم وقت لامبورت (lt). يساعد في تحديد الحدث الذي أدى إلى حدوث حدث آخر وما المدققون بحاجة إلى معالجته أولا. في نموذج بسيط ، يتم تنفيذ المعاملات المستلمة أولا أولا.

في هذا النموذج ، يمثل A و B اثنين العقود الذكية. إذا msg1_lt < msg2_lt ، فعندئذ tx1_lt < tx2_lt من حيث التسلسل.

ومع ذلك ، في المواقف الأكثر تعقيدا ، يمكن كسر هذه القاعدة. تقدم الوثائق الرسمية مثالا: لنفترض أن لدينا ثلاثة عقود ، A و B و C. في معاملة واحدة ، يرسل A رسالتين داخليتين ، msg1 و msg2 ، واحدة إلى B والأخرى إلى C. على الرغم من أنه يتم إنشاؤها في طلب معين (msg1 أولا ، ثم msg2) ، لا يمكننا التأكد من أنه ستتم معالجة msg1 قبل msg2. ينشأ عدم اليقين هذا لأن المسارات من A إلى B ومن A إلى C قد تختلف في الطول ومجموعات المدقق. إذا كانت هذه العقود في سلاسل أجزاء مختلفة ، فقد تستغرق رسالة واحدة عدة كتل للوصول إلى العقد المستهدف. لذلك ، هناك مساران محتملان للمعاملات ، كما هو موضح.

1. في TON ، يستخدم التخزين المستمر ل العقود الذكية بنية الرسم البياني الحلقي الموجه (DAG) مع الخلايا كوحدات. يتم ضغط البيانات بشكل مضغوط في خلية وفقا لقواعد ترميز محددة وتمتد لأسفل بطريقة DAG. يتناقض هذا مع البنية المستندة إلى hashmap المستخدمة في EVM لبيانات الحالة. نظرا لخوارزميات الوصول إلى البيانات المختلفة ، TON بتعيين أسعار غاز متفاوتة لمعالجة البيانات على أعماق مختلفة ؛ تتطلب معالجة بيانات الخلايا الأعمق مزيدا من غاز. وبالتالي ، يواجه TON نوعا من الهجوم DOS ، حيث يقوم المستخدمون الضارون بإغراق عقد ذكي بعدد كبير من الرسائل غير المرغوب فيها ، وملء جميع الخلايا الضحلة. هذا يزيد من تكاليف التخزين للمستخدمين الشرفاء. في المقابل ، تحتوي hashmap الخاصة ب EVM على تعقيد استعلام O (1) ، مما يضمن اتساق تكاليف غاز وتجنب المشكلات المماثلة. لذلك ، يجب على مطوري TON Dapp تجنب استخدام أنواع البيانات غير المحدودة في العقود الذكية. عندما تكون أنواع البيانات غير المحدودة ضرورية ، يجب تقسيمها باستخدام التجزئة.

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

إخلاء المسؤولية:

1. تمت إعادة طباعة هذه المقالة من [Theblockbeats]. جميع حقوق الطبع والنشر تنتمي إلى المؤلف الأصلي [Web3Mario]. إذا كانت هناك اعتراضات على إعادة الطبع هذه ، فيرجى الاتصال بفريق Gate Learn ، وسيقومون بالتعامل معها على الفور.
2. إخلاء المسؤولية: الآراء ووجهات النظر الواردة في هذه المقالة هي آراء المؤلف فقط ولا تشكل أي نصيحة استثمارية.
3. تتم ترجمة المقالة إلى لغات أخرى من قبل فريق Gate Learn. يحظر نسخ المقالات المترجمة أو توزيعها أو سرقتها، ما لم يذكر ذلك.