دليل المبتدئين إلى TON: الحسابات والرموز والأمان
الخلفية
TON (الشبكة المفتوحة) هي منصة بلوك تشين لامركزية تم تصميمها وتطويرها في البداية من قبل فريق Telegram. تهدف TON إلى توفير منصة بلوك تشين عالية الأداء وقابلة للتطوير لدعم التطبيقات اللامركزية واسعة النطاق (DApps) والعقود الذكية.
تُعد TON فريدة من نوعها من حيث سهولة استخدامها، فهي سهلة الاستخدام، ومتكاملة بعمق مع Telegram، مما يسمح للأشخاص العاديين باستخدام الرموز بسهولة. وفي الوقت نفسه، فهي معقدة، وتتميز بهندسة معمارية مختلفة عن سلاسل الكتل الأخرى، وتستخدم لغة عقود ذكية غير سائدة تُسمى FunC.
سنناقش اليوم خصائص TON وأمان أصول المستخدم من منظور الحسابات والرموز والمعاملات.
خصائص TON
إنشاء الحساب
تختلف طريقة إنشاء عنوان حساب على TON عن معظم سلاسل الكتل؛ فهو عنوان عقد ذكي. أولاً، يبدأ كل شيء بمفتاح خاص. تستخدم TON في المقام الأول خوارزمية إد25519 لإنشاء مفتاح عام، وتكون العملية على النحو التالي:
هناك شكلان من المفتاح العام: أحدهما هو المفتاح العام الخام المحسوب من المفتاح الخاص، والذي يبدو
E39ECDA0A7B0C60A7107EC43967829DBE8BC356A49B9DFC6186B3EAC74B5477D
والآخر هو مفتاح عام “مُجمّل”، والذي يتضمن بعض المعلومات وبتات التحقق، ويبدو أنه
Pubjns2gp7DGCnEH7EOWeCnb6Lw1akm538YYaz6sdLVHfRB2
إذا كنت تظن أن مجرد الحصول على المفتاح العام سيسمح لك بالحصول على عنوان الحساب كما هو الحال في الإيثيريوم، فأنت مخطئ. فمجرد الحصول على المفتاح العام للمستخدم لا يكفي لحساب عنوان حساب المستخدم.
كما ذكرنا، عنوان حساب المستخدم هو عنوان عقد ذكي، ولكن كيف يمكنك نشر عقد ذكي دون أن يكون لديك حساب؟
التسلسل الصحيح هو حساب العنوان أولاً، واستلام مبلغ أولي من التوكنات، ثم نشر العقد. تظهر عملية حساب عنوان الحساب في الرسم البياني التالي:
يأتي عنوان المستخدم أيضًا في أشكال متعددة. أولاً، هناك الشكل الخام، والذي يبدو كما يلي:
0:b4c1b2ede12aa76f4a44353944258bcc8f99e9c7c474711a152c78b43218e296
ثم هناك نموذج سهل الاستخدام، والذي يبدو مثل:
الشبكة الرئيسية:
- قابل للارتداد:
EQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0MhjilkPX - غير قابلة للارتداد:
UQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0Mhjilh4S
تيست نت
- قابل للارتداد:
kQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0Mhjilvhd - غير قابلة للارتداد:
0QC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0MhjilqWY
بملاحظة هذه العناوين بعناية، يمكنك أن ترى أنها تختلف فقط في الأحرف الأولى والأخيرة، مع تشابه الأحرف الوسطى account_id.
ومع ذلك، ما زلنا لا نستطيع رؤية العلاقة بين المفتاح العام وعنوان الحساب.
يكمن السر في الرقم initial data في البداية، والذي يحتوي على المفتاح العام للمستخدم، مما يسمح للمستخدم بالتحكم في عقد المحفظة. من السهل فهم الـ workchainId؛ فـ TON ليست مجرد سلسلة واحدة ولكنها تتكون من العديد من الأجزاء.
كل شظية هي جزء من الشبكة بأكملها، وتتعامل مع حسابات ومعاملات محددة. ولتحديد موقع العقود الذكية وإدارتها، من الضروري تحديد الجزء الذي توجد فيه. ما الفرق بين Bounceable و Non-bounceable؟
يتعلق هذا بالطريقة التي العقود الذكية، ولكن دعنا نواصل البحث أكثر.
عقد المحفظة
فيما يلي مقتطف من التعليمات البرمجية المصدرية لعقد محفظة المستخدم. وهو يوضح أنه عند تلقي رسالة من المستخدم، فإنه يقرأ أربع معلمات: stored_seqno و stored_subwallet و public_key و plugins:
wallet-v4-code.fc
() recv_external(slice in_msg) impure {
var signature = in_msg~load_bits(512);
var cs = in_msg;
var (subwallet_id, valid_until, msg_seqno) = (cs~load_uint(32), cs~load_uint(32), cs~load_uint(32));
throw_if(36, valid_until <= now());
var ds = get_data().begin_parse();
var (stored_seqno, stored_subwallet, public_key, plugins) = (ds~load_uint(32), ds~load_uint(32), ds~load_uint(256), ds~load_dict()); ;;##The Initial Data
ds.end_parse();
throw_unless(33, msg_seqno == stored_seqno);
throw_unless(34, subwallet_id == stored_subwallet);
throw_unless(35, check_signature(slice_hash(in_msg), signature, public_key));
//...
}في الواقع، عندما يتم نشر عقد محفظة المستخدم هذه، فإنها تتطلب بعض المعلمات الأولية، بما في ذلك 256 بت public_key. وهذا يضمن أن يكون لكل مستخدم عنوان عقد فريد حتى عند استخدام نفس رمز العقد.
يجب أن يتم توقيع كل معاملة يبدأها المستخدم بـ in_msg، ثم يتم التحقق منها بواسطة عقد المحفظة (check_signature)، وبعد ذلك يقوم العقد بإجراء عمليات على البلوك تشين. من هذا، يمكننا أن نستنتج أن المفتاح العام للمستخدم يمكن أن يتوافق مع العديد من عناوين المحفظة.
سينتج عن نشر عقود محفظة مختلفة أو استخدام بيانات تهيئة مختلفة عناوين عقود مختلفة تماماً.
جيتون توكن
يمثل الرمز المميز أحد الأصول على سلسلة الكتل، مما يجعله عنصراً أساسياً نحتاج إلى فهمه. Jetton هو الشكل القياسي لرموز TON ويتكون من عقدين: Jetton-minter و Jetton-wallet.
عند إصدار رمز مميز، يتم إنشاء عقد جيتون-مينتر. تسجل تهيئة هذا العقد معلومات مثل إجمالي المعروض من التوكنات، والمسؤول، ورمز المحفظة، وتفاصيل أخرى.
عندما يتم توزيع التوكنات على المستخدمين، ينشر عقد Minter عقد محفظة لكل مستخدم. أثناء تهيئة العقد، يقوم العقد بتسجيل رصيد المستخدم، وملكيته، وعنوان عقد Minter الرمزي، ورمز محفظة المستخدم، وغيرها من المعلومات ذات الصلة. لكل مستخدم عقد منشور بشكل فردي.
من المهم ملاحظة أن العقد الذي تم إنشاؤه هنا هو عقد محفظة لإدارة رموز Jetton مميزة، وهو مختلف عن عقد محفظة حساب المستخدم. العقد owner_address المسجل هنا هو عنوان محفظة حساب المستخدم.
عندما يقوم المستخدم أليس بتحويل الرموز إلى المستخدم بوب، تكون علاقة الاستدعاء على النحو التالي:
توقع أليس على المعاملة من خلال تطبيق خارج السلسلة وترسل أمرًا تشغيليًا عبر عقد محفظتها. ستستدعي هذه الأوامر كذلك محفظة التوكنات الخاصة بها لتنفيذ التحويل. عندما تتلقى محفظة التوكنات الخاصة ببوب التوكنات، فإنها تُخطر عقد محفظة بوب (عنوان مالك محفظة بوب الجيتونية).
إذا كان هناك أي غاز متبقٍ أثناء المعاملة، فسيتم إرجاعه إلى العنوان المناسب، وهو عادةً عقد حساب أليس.
فيما يلي مثال على نقل رمز Jetton المميز الذي تم تحليله بواسطة متصفح Tonviewer:
في حين أن نقل ERC20 لا يتطلب سوى استدعاء عقد واحد فقط، فإن نقل رمز جيتون يتطلب أربع استدعاءات للعقد على الأقل. تم تصميم هذه الطريقة لتمكين التزامن على السلسلة، مما يحسن من كفاءة المعاملات.
المعاملات
عندما يقع حدث معين في حساب TON، فإنه يؤدي إلى تشغيل معاملة. الحدث الأكثر شيوعًا هو “تلقي رسالة”. تتضمن المعاملة العناصر التالية:
- الرسالة الواردة التي تؤدي في البداية إلى تشغيل العقد (مع توفر طرق تشغيل خاصة).
- إجراءات العقد الناتجة عن الرسالة الواردة، مثل تحديث مخزن العقد (اختياري).
- الرسائل الصادرة المرسلة إلى المشاركين الآخرين (اختياري).
هناك العديد من الميزات الرئيسية التي يجب أن تكون على دراية بها فيما يتعلق بالمعاملات:
- غير متزامن: لا تكتمل معاملات TON في مكالمة واحدة؛ فقد تتطلب تمرير الرسائل إلى عدة عقود ذكية مختلفة لتنفيذ سلسلة من المكالمات. نظرًا لاختلاف التوجيه في السلاسل المجزأة، لا يمكن لـ TON ضمان ترتيب تسليم الرسائل بين العقود الذكية المتعددة.
- الرسوم: تُدخل الطبيعة غير المتزامنة للمعاملات تحدياً في تقدير الرسوم المستهلكة. ولذلك، غالبًا ما ترسل المحافظ في كثير من الأحيان رمزًا إضافيًا صغيرًا كرسوم عند بدء المعاملة. إذا كان العقد المُستدعى لديه آلية جيدة للتعامل مع الرسوم، فسيتم إعادة الرسوم المتبقية إلى محفظة المستخدم. قد يلاحظ المستخدمون انخفاض رموز محفظتهم فجأة ثم زيادتها مرة أخرى بعد بضع دقائق، وهو ما يرجع إلى هذه الآلية.
- ارتد: الارتداد هو آلية لمعالجة الأخطاء في العقود. إذا لم يكن العقد الذي تم استدعاؤه غير موجود أو ألقى خطأ، وتم تعيين المعاملة على أنها قابلة للارتداد، فسيتم إرجاع رسالة مرتدة إلى العقد المستدعي. على سبيل المثال، إذا بدأ المستخدم عملية تحويل وحدث خطأ أثناء العملية، فإن الرسالة المرتدة ضرورية حتى يتمكن عقد محفظة المستخدم من استعادة رصيده. يجب أن تكون جميع الرسائل الداخلية المرسلة بين العقود الذكية قابلة للارتداد، مما يعني أنه يجب تعيين بت “الارتداد” الخاص بها.
أمن الأصول
يحتوي TON على العديد من الميزات التي يمكن أن تؤدي إلى مشاكل أمنية، لذلك يجب أن يكون المستخدمون على دراية ببعض المخاطر الشائعة.
هجوم حجب الرسوم
كما ذكرنا، غالبًا ما تحتاج المحافظ في كثير من الأحيان إلى إرسال رسوم إضافية قليلة لمنع فشل المعاملات، مما يوفر فرصة للمهاجمين. إذا كنت من مستخدمي محفظة TON، فربما تكون قد واجهت موقفًا تتلقى فيه محفظتك بشكل متكرر العديد من NFTs أو الرموز المميزة.
في البداية، قد تبدو هذه الرموز في البداية وكأنها عملات رمزية تافهة، ولكن عند التحقق من تفاصيل المعاملة، تجد أنه يمكن بيعها مقابل مبلغ كبير من المال. ومع ذلك، عندما تحاول بدء معاملة، تلاحظ أن الرسوم المطلوبة مرتفعة للغاية (1 طن). في هذه المرحلة، يجب عليك توخي الحذر، فقد تكون هذه عملية احتيال بالرسوم.
ينشئ المهاجمون عقدًا رمزيًا مصممًا بعناية يجعل المحفظة تُقدِّر رسوم تحويل مرتفعة للغاية، ولكن في الواقع، يتم حجب الرسوم فقط، ولا يتم إرسال أي رسالة تحويل.
التصيد الاحتيالي بالأرقام الأولى والأخيرة
لا يقتصر التصيّد الاحتيالي بالرقمين الأول والأخير على TON؛ فهجوم التصيّد الاحتيالي هذا موجود في العديد من سلاسل الكتل الرئيسية. يقوم المهاجمون بإنشاء حساب مزيف لكل عنوان مستخدم على الشبكة بنفس الرقمين الأول والأخير.
عندما يبدأ المستخدم عملية تحويل، يرسل المهاجم أيضًا عملية تحويل صغيرة، بعد معاملة المستخدم، لترك سجل في سجل معاملات المستخدم. عندما يريد المستخدم المستلم إرسال الرموز مرة أخرى، قد يقوم بنسخ العنوان من سجل المعاملات، والذي قد يكون عنوان المهاجم، مما يؤدي إلى تحويل إلى عنوان خاطئ. يكون المهاجم قد استغل سلوك المستخدم بدقة.
تعليق التصيد الاحتيالي
عند تحويل التوكنات على TON، يمكن للمستخدمين إضافة تعليق للتعليق على المعاملة. وغالبًا ما تُستخدم هذه الميزة عند إجراء الإيداعات في البورصات، حيث تطلب البورصات عادةً من المستخدمين تضمين معرف المستخدم الخاص بهم في التعليق على الإيداع. ومع ذلك، كثيرًا ما يتم استغلال هذه الميزة من قِبل الجهات الخبيثة التي تكتب معلومات احتيالية في التعليقات لسرقة أصول المستخدمين. على سبيل المثال:
يجب على المستخدمين توخي الحذر بشكل خاص بشأن NFT “رقم تيليجرام المجهول”. إذا قام المستخدم بتفعيل حسابه على تيليجرام باستخدام رقم تيليجرام مجهول ولكن لم يُفعّل خاصية التحقق بخطوتين، وتمّ تصيد هذا الرقم، يمكن للمخترق تسجيل الدخول مباشرةً إلى حساب تيليجرام المستهدف ومتابعة سرقة الأصول والأنشطة الاحتيالية اللاحقة.
ثغرات العقود الذكية
يمكن أن تؤدي الثغرات الأمنية في العقود الذكية إلى فقدان الأموال المخزنة في العقد. يجب على المستخدمين اختيار المشاريع التي خضعت لتدقيق شامل. تتم برمجة عقود TON الذكية بشكل أساسي باستخدام لغة FunC، على الرغم من أن بعضها يستخدم لغة Tact الأكثر تقدماً أو لغة Fift ذات المستوى الأدنى.
جميع هذه اللغات أصلية للغاية. تجلب لغات البرمجة الجديدة مخاطر أمنية جديدة، خاصةً بالنسبة للمطورين، الذين يحتاجون إلى ممارسة عادات الترميز الآمنة، وإتقان أفضل الممارسات الأمنية، والخضوع لعمليات تدقيق أمني صارمة قبل النشر في بيئة الإنتاج. نظرًا لضيق المساحة، لن تناقش هذه المقالة أمن العقود بالتفصيل.
هجوم الإيداع الوهمي
يجب أن يكون مستخدمو المحفظة أو الصرافة على دراية بهجمات الإيداع الوهمية، والتي عادةً ما تأتي في شكلين:
- الرموز المزيفة: يصدر المهاجم رمزًا مميزًا ببيانات وصفية مطابقة للرمز المستهدف. إذا لم يتحقق برنامج الإيداع الآلي مما إذا كان الرمز المميز من عقد المُعَدِّن الصحيح، فقد يؤدي ذلك إلى إيداعات غير صحيحة.
- ارتد: تتطلب عملية تحويل TON وجود علاقة استدعاء بين عقدي محفظة مستخدمين اثنين. إذا لم يكن عقد محفظة المستلم غير موجود وتم تعيين المعاملة على أنها قابلة للارتداد، فسترتد الرسالة، وستتم إعادة الأموال الأصلية، مخصومًا منها الرسوم، إلى المرسل. يمكن للمهتمين بالتفاصيل الرجوع إلى مقالنا السابق عن الإيداعات الوهمية.
الخاتمة
عرضت هذه المقالة بعض المبادئ التقنية الأساسية لـ TON من منظور إنشاء المفتاح والمحفظة، وأشكال الرموز الرمزية، وخصائص المعاملات. كما استكشفت أيضًا مشكلات الأمان المحتملة عند استخدام TON، على أمل أن تلهمك في رحلتك التعليمية.