ما هو العقد الذكي؟

يمتلك الإيثيريوم نوعين شائعين من الحسابات: الحسابات المملوكة خارجيًا (EOA) وحسابات العقود الذكية (SCA).

تشبه الحسابات المملوكة خارجيًا (EOA) إلى حد كبير الحسابات المالية الإلكترونية التي نستخدمها عادة لتخزين الأموال والتفاعل مع التطبيقات. على سبيل المثال، يقوم المستخدمون بإيداع العملات الورقية عبر PayPal والتفاعل مع مواقع الويب والمتاجر والتطبيقات المختلفة للمدفوعات. عادة ما يقوم عمال التعدين في التمويل اللامركزي (DeFi) بتخزين العملات المشفرة في حساباتهم المملوكة خارجيًا، والتفاعل مع تطبيقات DeFi اللامركزية، وإيداع الأموال في هذه التطبيقات للحصول على الأرباح. ومع ذلك، تتميز الحسابات المملوكة خارجيًا بميزة لا تمتلكها الحسابات المالية الإلكترونية: يجب على المستخدمين التحقق من سيطرتهم على الحسابات المملوكة خارجيًا من خلال ملكية المفاتيح الخاصة - ليست مفاتيحك، ليست عملاتك.

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

هجمات العقود الذكية الشائعة

1. هجوم إعادة الدخول

الهجوم الأكثر شيوعًا وسمعة سيئة هو هجوم إعادة الدخول، والذي كان مسؤولاً عن انقسام الإيثيريوم الذي أدى إلى إنشاء إيثيريوم كلاسيك. في عام 2016، نفذ المتسللون هجوم إعادة الدخول على عقد DAO، وسرقوا 3,600,000 إيثر بقيمة تزيد عن 150 مليون دولار في ذلك الوقت. هذا الهجوم، الذي حدث خلال المراحل الأولى من الإيثيريوم، دمر النظام البيئي وحطم ثقة المستثمرين، مما أدى في النهاية إلى انقسام.

المنطق المحدد

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

الخطوة 1: يطلب البنك B سحب الأموال

الخطوة 2: يقوم البنك A بتحويل الأموال إلى البنك B

الخطوة 3: يؤكد البنك A نجاح التحويل إلى البنك B

الخطوة 4: يقوم البنك أ بتحديث رصيد حساب البنك ب.

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

العقود الذكية ذات الصلة

يتضمن عقد البنك أ وظيفتين:

deposit(): وظيفة إيداع تودع الأموال في البنك أ وتحدث رصيد المستخدم؛
withdraw(): وظيفة سحب تسمح للمستخدمين بسحب جميع أموالهم من البنك أ.

يتضمن عقد الهجوم الخاص بالبنك ب بشكل أساسي حلقة تطلق وظيفة الاستقبال receive() الاسترجاعية، والتي بدورها تستدعي وظيفة السحب withdraw() من عقد البنك لاستنزاف أصول البنك أ من خلال سلسلة من عمليات الإيداع الواحدة والسحب الواحدة واستدعاءات وظيفة الاستقبال الاسترجاعية، وأخيرًا تحديث رصيد ب في أ. وهو يتضمن وظيفتين:receive(): وظيفة استرجاعية يتم تشغيلها عند استلام الإيثيريوم، والتي تستدعي بشكل متكرر وظيفة السحب withdraw() من عقد البنك لإجراء عمليات السحب.
attack(): تقوم أولاً باستدعاء وظيفة الإيداع deposit() من عقد البنك لتحديث الرصيد ثم وظيفة السحب withdraw() لبدء عملية السحب الأولى، وتطلق وظيفة الاستقبال الاسترجاعية receive() لاستدعاء withdraw() بشكل متكرر لاستنزاف أصول عقد البنك.

الحل

تنفيذ قفل إعادة الدخول

قفل إعادة الدخول هو معدِّل يُستخدم لمنع إعادة الدخول، مما يضمن أن الاستدعاء يجب أن يكمل تنفيذه قبل أن يتم استدعاؤه مرة أخرى. على سبيل المثال، نظرًا لأن الهجوم من قبل البنك B يتطلب استدعاء دالة withdraw() الخاصة بعقد البنك عدة مرات، فإنه سيفشل مع تنفيذ قفل إعادة الدخول.

كيفية استخدامه

2. سوء استخدام tx.origin

الوظيفة الرئيسية لـ tx.origin في العقد الذكي هي استرداد الحساب الأصلي الذي بدأ المعاملة. هنا، سنناقش متغيرين شائعين في العقود الذكية: msg.sender و tx.origin. يسترجع msg.sender الحساب الذي يقوم بالاتصال المباشر بالعقد الذكي، بينما في عالم البلوكتشين، وبسبب التداخل والاستدعاءات المتبادلة بين العقود الذكية المختلفة (مثل DeFi Lego)، هناك حاجة إلى tx.origin للحصول على الحساب الأصلي الذي بدأ المعاملة. تنشأ ثغرة أمنية عندما يقوم مطورو التطبيقات اللامركزية بالتحقق من أمان tx.origin فقط في الكود، مهملين التحقق الأمني من المهاجمين الذين ينشرون عقودًا وسيطة لتجاوز tx.origin وشن هجمات.

المنطق المحدد

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

عقد المحفظة الذكية

يتضمن عقد المحفظة الذكية وظيفة واحدة:

transfer(): وظيفة سحب لا يمكن أن يبدأها إلا مالك المحفظة، وهو في هذه الحالة بيل.

عقد هجوم التصيد الاحتيالي

في عقد هجوم التصيد، تحث وظيفة Mint() المستخدمين على تحويل الأموال إلى عنوان المخترق. وهي تتضمن وظيفة واحدة:

Mint(): بمجرد استدعائها، تنفذ وظيفة التصيد داخليًا transfer() لعقد المحفظة. نظرًا لأن المبادر الأصلي هو المستخدم نفسه (في هذا المثال، بيل)، فإن التحقق require(tx.origin == owner, "Not owner") ; لن يكون مشكلة. ومع ذلك، تم التلاعب بالعنوان المستهدف للتحويل بالفعل إلى عنوان المخترق، مما أدى إلى سرقة الأموال.

الحلول

1. استخدام msg.sender بدلاً من tx.origin

بغض النظر عن عدد استدعاءات العقود المشاركة (العقد A → العقد B →...→ العقد المستهدف)، يتم التحقق فقط من msg.sender، أي المتصل المباشر، لتجنب الهجمات الناجمة عن العقود الوسيطة الخبيثة.

2. التحقق من tx.origin == msg.sender

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

3. هجوم مولد الأرقام العشوائية (RNG)

يعود هذا إلى اتجاه تطبيقات المقامرة أو الرهان اللامركزية حوالي عامي 2018 و2019. عادةً ما يستخدم المطورون بذورًا معينة في العقود الذكية لتوليد أرقام عشوائية لاختيار الفائزين أثناء السحوبات. تشمل البذور الشائعة block.number و block.timestamp و blockhash و keccak256. ومع ذلك، يمكن للمعدنين التحكم الكامل في هذه البذور، لذلك في بعض الحالات، قد يتلاعب المعدنون الخبيثون بالمتغيرات لجني الفوائد.

عقود النرد الشائعة

يتضمن عقد النرد وظيفة واحدة:

Bet(): وظيفة رهان حيث يقوم المستخدمون بإدخال رقم رهان ودفع ETH. يتم إنشاء رقم عشوائي باستخدام بذور متعددة، وإذا تطابق رقم الرهان مع الرقم العشوائي، يفوز المستخدم بالجائزة الكاملة.

عقد هجوم المعدن

يمكن للمعدنين الفوز طالما أنهم يقومون بحساب الرقم العشوائي الفائز مسبقًا وتنفيذه في نفس الكتلة. يتضمن هذا وظيفة واحدة:

attack(): وظيفة هجوم الرهان، حيث يقوم المعدن بحساب الرقم العشوائي الفائز مسبقًا. نظرًا لأنه يتم تنفيذه في نفس الكتلة، فإن blockhash(block.number - 1) و block.timestamp في نفس الكتلة متماثلان. ثم يقوم المعدن باستدعاء Bet() من عقد النرد لإكمال الهجوم.

الحل

استخدام أرقام عشوائية خارج السلسلة مقدمة من مشاريع أوراكل

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

4. هجوم إعادة التشغيل

هجوم إعادة التشغيل ينطوي على إعادة بدء معاملة باستخدام توقيع تم استخدامه سابقًا لسرقة الأموال. أحد أشهر هجمات إعادة التشغيل في السنوات الأخيرة كانت سرقة 20 مليون رمز $OP من صانع السوق Wintermute على شبكة Optimism، والتي كانت هجوم إعادة تشغيل عبر السلاسل. نظرًا لأن حساب المحفظة متعددة التوقيعات الخاص بـ Wintermute تم نشره مؤقتًا على الشبكة الرئيسية لإيثيريوم فقط، استخدم المتسلل توقيع المعاملة لنشر Wintermute لعنوان متعدد التوقيعات على إيثيريوم لإعادة تنفيذ نفس المعاملة على سلسلة Optimism، وبالتالي اكتساب السيطرة على حساب المحفظة متعددة التوقيعات على Optimism. حساب المحفظة متعددة التوقيعات هو في الأساس حساب عقد ذكي، مما يوضح أيضًا فرقًا كبيرًا بين SCA و EOA. بالنسبة لـ EOA، يحتاج المستخدم العادي فقط إلى مفتاح خاص واحد للتحكم في جميع العناوين على إيثيريوم والسلاسل المتوافقة مع EVM (سلاسل العناوين متطابقة تمامًا)، بينما يكون SCA فعالًا على سلسلة واحدة فقط بعد نشره.

المنطق المحدد

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

مثال

يتكون العقد الذي يحتوي على ثغرات من ثلاث وظائف:

checkSig(): وظيفة التحقق من ECDSA، تضمن أن نتيجة التحقق هي الموقّع المحدد أصلاً.
getMsgHash(): وظيفة لإنشاء التجزئة، والتي تجمع بين المستلم والمبلغ لتشكيل التجزئة.
transfer(): وظيفة تحويل الأصول، تسمح للمستخدمين بسحب الأموال من مجمع السيولة. نظرًا لعدم وجود قيود على التوقيع، يمكن إعادة استخدام نفس التوقيع، مما يسمح للمتسللين بسرقة الأموال باستمرار.

الحل

تضمين الرقم العشوائي (nonce) في تركيبة التوقيع لمنع هجمات إعادة التشغيل. مبدأ المعلمة كما يلي:

الرقم العشوائي (nonce): يصف متغير عدد المعاملات لحساب EOA في شبكة البلوكتشين. له ترتيب وتفرد. مع كل معاملة إضافية، ستزداد قيمة الرقم العشوائي بمقدار 1. ستتحقق شبكة البلوكتشين مما إذا كان الرقم العشوائي للمعاملة متوافقًا مع الرقم العشوائي الحالي للحساب. لذلك، سيفشل المتسلل إذا استخدم توقيعًا مستخدمًا لأن قيمة الرقم العشوائي في تركيبة التوقيع أقل من قيمة الرقم العشوائي الحالية لحساب EOA.

5. هجوم حجب الخدمة (DoS)

هجوم حجب الخدمة (DoS) ليس جديدًا في عالم الويب التقليدي (Web2). يشير إلى أي تدخل في الخادم، مثل إرسال كمية كبيرة من المعلومات غير المرغوب فيها أو المعطلة، مما يعيق أو يدمر تمامًا توفر الخدمة. وبالمثل، تعاني العقود الذكية من مثل هذه الهجمات، والتي تهدف في جوهرها إلى جعل العقد الذكي يعمل بشكل خاطئ.

المنطق المحدد

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

مثال عقد الاكتتاب العام

مثال

يتضمن عقد الاكتتاب العام وظيفتين:

deposit(): وظيفة الإيداع، تسجل عنوان المودع والمبلغ المساهم به.
refund(): وظيفة الاسترداد، التي يعيد بها فريق المشروع الأموال إلى المستثمرين.

عقد هجوم حجب الخدمة (DoS)

يتضمن عقد هجوم حجب الخدمة وظيفة واحدة:

attack(): على الرغم من كونها وظيفة هجوم، إلا أنها لا تحتوي على أي مشاكل. المشكلة الرئيسية تكمن في وظيفة استدعاء الدفع receive() المدمجة في عقد Hacker، والتي تتضمن حكمًا للاستثناءات. أي عقد خارجي يقوم بتحويل الأموال إلى عقد Hacker سيؤدي إلى إثارة استثناء من خلال revert()، وبالتالي منع اكتمال العملية.

الحلول

1. تجنب تعطل الوظائف الحرجة عند استدعاء العقود الخارجية

قم بإزالة require(success, "Refund Fail!"); من وظيفة refund() المذكورة أعلاه في عقد PublicSale، مما يضمن استمرار عملية الاسترداد حتى إذا فشل الاسترداد لعنوان واحد.

2. فصل المسؤوليات

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

6. هجوم التصريح (permit)

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

في عقد ERC20 الشائع، يمكن للحساب A استدعاء approve() لتفويض كمية معينة من الرموز للحساب B، مما يمكّن الأخير من نقل تلك الرموز من الأول. بالإضافة إلى ذلك، تم إدخال permit() في عقود ERC20 في EIP-2612، وقد أصدرت Uniswap معيارًا جديدًا لتفويض الرموز، يسمى Permit2، في نوفمبر 2022.

المنطق المحدد

هنا مثال. في أحد الأيام، كان بيل يتصفح موقع أخبار blockchain عندما ظهر فجأة نافذة منبثقة لتوقيع Metamask. نظرًا لأن العديد من مواقع الويب أو تطبيقات blockchain تستخدم التوقيعات للتحقق من تسجيل دخول المستخدمين، لم يفكر بيل كثيرًا في الأمر وأكمل التوقيع مباشرة. بعد خمس دقائق، تم استنزاف أصول Metamask الخاصة به. ثم اكتشف بيل في مستكشف blockchain أن عنوانًا غير معروف بدأ معاملة permit()، تبعتها معاملة transferFrom() أفرغت محفظته.

مثال

الوظيفتان هما كما يلي:

approve(): وظيفة تفويض قياسية حيث يفوض الحساب A مبلغًا معينًا من الأموال للحساب B.
permit(): وظيفة تفويض بالتوقيع حيث يقدم الحساب B ويكمل التحقق من التوقيع للحصول على المبلغ المصرح به من الحساب A. تتضمن المعلمات المالك الذي يمنح التفويض، والمنفق المصرح له، والمبلغ المصرح به، والموعد النهائي للتوقيع، وبيانات توقيع المالك v و r و s.

الحلول

1. الانتباه إلى كل توقيع في التفاعلات على السلسلة

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

2. فصل المحفظة المخصصة للتفاعل العادي عن المحفظة التي تخزن الأصول

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

7. هجوم مصيدة العسل

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

المنطق المحدد

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

مثال

الوظيفة الأساسية:

_beforeTokenTransfer(): وظيفة داخلية يتم استدعاؤها أثناء تحويلات الرموز، والتي يمكن أن تنجح فقط عند استدعائها من قبل المالك؛ ستفشل المكالمات من الحسابات الأخرى.

الحل

استخدام أدوات الفحص الأمني

أ. Token Sniffer لرموز الإيثيريوم

ب. Ave Check للرموز على السلاسل الأخرى

ج. مواقع السوق المزودة بأدوات اكتشاف مدمجة مثل Dextools

تجنب تداول الرموز ذات الدرجات المنخفضة.

8. هجوم الاستباق

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

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

المنطق المحدد

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

مثال

الوظيفة كما يلي:

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

العملية: يجد بيل الإجابة الصحيحة.
تراقب أليس مجموعة الذاكرة، في انتظار أن يقدم شخص ما الإجابة الصحيحة.
يقوم بيل باستدعاء حل() لتقديم الإجابة ويحدد سعر الغاز بـ 100 جوي.
ترى أليس المعاملة التي أرسلها بيل وتكتشف الإجابة. تحدد سعر غاز أعلى من سعر بيل بـ 200 جوي وتستدعي حل().
يتم حزم معاملة أليس من قبل عامل التعدين قبل معاملة بيل.
تفوز أليس بمكافأة قدرها 10 إيثر.

الحل

الوظائف الرئيسية الثلاث هي كما يلي:

commitSolution(): وظيفة لتقديم النتائج، حيث يتم وضع الإجابة المقدمة من المستخدم solutionHash، ووقت التقديم commitTime، والحالة revealed في بنية Commit.
getMySolution(): وظيفة للحصول على النتائج، تسمح للمستخدمين بعرض إجاباتهم المقدمة والمعلومات ذات الصلة، بما في ذلك الإجابة المقدمة من المستخدم solutionHash، ووقت التقديم commitTime، والحالة revealed.
revealSolution(): وظيفة للمطالبة بالمكافآت لتخمين اللغز، تسمح للمستخدمين بالمطالبة بالمكافآت بعد تقديم الإجابة وكلمة المرور التي قاموا بتعيينها.

العملية:

يجد بيل الإجابة الصحيحة.
يقوم بيل باستدعاء commitSolution() لتقديم الإجابة الصحيحة.
في الكتلة التالية، يقوم بيل باستدعاء revealSolution()، مقدمًا الإجابة وكلمة المرور التي وضعها للمطالبة بالمكافأة.

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

الخاتمة

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

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

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

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

المراجع:

Solidity بالمثال: https://solidity-by-example.org/

المعرفة بالبلوكتشين من SlowMist: https://mp.weixin.qq.com/mp/appmsgalbum?__biz=MzU4ODQ3NTM2OA==&action=getalbum&album_id=1378673890158936067&scene=173&from_msgid=2247498135&from_itemidx=1&count=3&nolastread=1#wechat_redirect

Chainlink - أفضل 10 ممارسات أمنية لـ DeFi: https://blog.chain.link/defi-security-best-practices/#post-title

WTF - أمان العقد في Solidity 104: https://www.wtf.academy/solidity-104/

نقاط الضعف في العقود الذكية لـ DeFi في 4 فئات مع 38 سيناريو: https://www.weiyangx.com/381670.html

OpenZeppelin: https://github.com/OpenZeppelin/

مقدمة للثغرات والهجمات الشائعة في العقود الذكية