المقدمة الأولى لـ TON: الحساب والرمز المميز والمعاملات وأمن الأصول

بواسطة: يوهان

الخلفية

TON (الشبكة المفتوحة) هي منصة blockchain لامركزية تم تصميمها وتطويرها في الأصل بواسطة فريق Telegram. هدف TON هو توفير منصة blockchain عالية الأداء وقابلة للتطوير لدعم التطبيقات اللامركزية واسعة النطاق (DApps) والعقود الذكية.

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

ميزات TON

إنشاء الحساب< /strong>

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

هناك نوعان من المفاتيح العامة، أحدهما هو المفتاح العام الأصلي المحسوب من المفتاح الخاص، في النموذج:

E39ECDA0A7B0C60A7107EC43967829DBE8BC356A49B9DFC6186B3EAC74B5477D

والآخر هو المفتاح العام "المجمل" الذي يحمل المفتاح العام بعض المعلومات وأرقام التحقق، في شكل: Pubjns2gp7DGCnEH7EOWeCnb6Lw1akm538YYaz6sdLVHfRB2

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

كما يأتي عنوان المستخدم بعدة أشكال أولها الشكل الأصلي مثل:

0:b4c1b2ede12aa76f4a44353944258bcc8f99e9c7c474711a152c78b43218e296< /p>

ونموذج سهل الاستخدام، مثل:

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

عقد المحفظة

ما يلي هو عقد محفظة المستخدم جزء من الكود المصدري، يمكنك أن ترى أنه يقرأ 4 معلمات عند تلقي رسالة المستخدم.

نعم، عند نشر عقد المحفظة لهذا المستخدم، تحتاج إلى تمرير بعض المعلمات الأولية، والتي تتضمن معلومات المفتاح العام 256 بت، وبالتالي ضمان أن يكون لكل مستخدم عنوان عقد مستقل عند استخدام نفس رمز العقد. تحتاج جميع المعاملات التي بدأها المستخدمون إلى تسجيل الدخول `in_msg`، وبعد التحقق من التوقيع (check_signature) من خلال عقد المحفظة الخاصة بهم، سوف يستدعي العقد جميع العمليات على السلسلة. من هنا يمكننا أيضًا استنتاج أن المفتاح العام للمستخدم يمكن أن يتوافق فعليًا مع عدد لا يحصى من عناوين المحفظة. ما عليك سوى نشر محافظ برموز مصدر مختلفة أو بيانات تهيئة مختلفة للحصول على عناوين عقود مختلفة تمامًا.

Jetton Token

الرمز المميز هو أحد الأصول في السلسلة التعبير، لذلك فهو عنصر أساسي نحتاج إلى فهمه. Jetton هو الشكل القياسي لرمز TON، ويتكون Jetton من جزأين من العقد، Jetton-minter وJetton-wallet:

عند إصدار رمز مميز، سيتم إنشاء عقد Jetton-minter، وتسجل تهيئة العقد المبلغ الإجمالي للرموز والمسؤول ورمز المحفظة وغيرها من المعلومات.

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

عندما يقوم المستخدم Alice بتحويل الأموال إلى المستخدم Bob، تكون علاقة الاتصال كما يلي:

< img src= "https://img.jinse.cn/7277374_image3.png">

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

هذا هو نقل رمز Jetton المميز الذي تم تحليله بواسطة متصفح Tonviewer:

يتطلب نقل ERC20 مكالمة عقد واحدة على الأقل، ويجب أن تتصل عمليات نقل رمز Jetton على يتم ذلك بأربعة عقود على الأقل للسماح بإجراء عمليات النقل بشكل متزامن على السلسلة وتحسين كفاءة المعاملات.

المعاملة

عندما يحدث حساب في TON عندما يكون الأمر محددًا عند وقوع الأحداث، سيؤدي ذلك إلى بدء معاملة. الحدث الأكثر شيوعًا هو "تلقي رسالة". تتضمن المعاملة ما يلي:

• الرسالة الواردة التي تؤدي في البداية إلى تشغيل العقد (هناك طريقة تشغيل خاصة)

• إجراءات العقد الناتجة عن الرسائل الواردة، مثل تحديث مساحة تخزين العقد (اختياري)

• الرسائل الصادرة إلى المشاركين الآخرين (اختياري)

< img src="https:// img.jinse.cn/7277376_image3.png">

هناك العديد من الخصائص التي يجب ملاحظتها في المعاملات:

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

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

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

أمن الأصول

يحتوي TON على العديد من الميزات التي ستجلب لك المشكلات الأمنية، لذلك يحتاج المستخدمون أيضًا إلى أن يكونوا على دراية ببعض المخاطر الشائعة.

هجوم اعتراض الرسوم

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

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

صيد الرقم الأول والأخير

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

صيد التعليقات

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

يحتاج المستخدمون إلى إيلاء اهتمام خاص لرقم Telegram المجهول NFT إذا كان المستخدم يستخدم رقم Telegram المجهول لفتح حساب TG ولكنه لم يفتح التحقق من خطوتين، فبمجرد تصيد NFT، سيتمكن المتسللون من اختراقه. يمكنه تسجيل الدخول مباشرة إلى رقم TG لتنفيذ سرقة الأصول والخداع لاحقًا.

الثغرات الأمنية للعقود الذكية

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

هجوم الإيداع المزيف

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

• وهمية. العملة، الهجوم إذا أصدر المستخدم رمزًا مميزًا بنفس البيانات الوصفية مثل الرمز المميز المستهدف، وإذا لم يتحقق برنامج الإدخال الآلي مما إذا كان هذا هو عقد سك العملة الصحيح، فسيؤدي ذلك إلى إدخال غير صحيح.

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

الملخص

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