وظائف العقود الذكية – كيف تكتشف عملية احتيال

وظائف العقود الذكية هي في الوقت الحالي الطريقة رقم 1 التي يخدع بها المحتالون الأشخاص لتجريدهم من أصولهم المشفرة ورموزهم غير القابلة للاستبدال التي اكتسبوها بجهدهم – ألا تعتقد أن الوقت قد حان لتتعلم كيفية قراءتها؟

فضاء الأصول المشفرة مليء بفرص جديدة وأنواع جديدة من التفاعلات – ومعظمها تعمل بواسطة العقد الذكي المتواضع. العقود الذكية هي ما تُملي تفاعل محفظتك مع منصات وخدمات ويب 3.0، مما يعطيك حريةً غير مسبوقة في استخدام أصولك الرقمية، ويفتح عالماً رقمياً جديداً بالكامل مدعوم بملكية مفاتيحك الخاصة.

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

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

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

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

لنبدأ بالأساسيات – ما هي وظائف العقد الذكي بالضبط؟

ببساطة، الوظائف هي أجزاء من كود برمجي داخل عقد ذكي تُمكِّنه من تنفيذ إجراءات محددة، – “استدعاء وظائف” يبدأ تفاعلاً معيناً بين محفظتك وأياً كانت المنصة التي تستخدمها.

التفاعل مع العقود الذكية هو جزء غير قابل للتفاوض من ويب 3.0، والعقود الذكية بطبيعتها ليست خطرةً.

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

إشارات الخطر لوظائف العقد الذكي: فهرس

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

1) SetApprovalforAll (تعيين الموافقة للكل)

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

الأمر يبدو منطقياً أليس كذلك؟ لكن هذا له بعض التداعيات أيضاً.

المخاطر المرتبطة بـ SetApprovalforAll

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

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

إنها مثل كتابة شيك مفتوح لصديق. فأنت في الأساس تقول “أنا أثق أن هذه المنصة ستفعل ما تقول إنها ستفعله، وأن تتصرف في نطاق الحدود التي أتوقعها”. لكن ماذا لو ارتكبتَ خطأً؟

الاحتيالات – وكيفية اكتشافها

SetApprovalforAll هي شيء هام عندما يتعلق الأمر باحتيالات الأصول المشفرة، لذا من الضروري أن تكون قادراً على تحديد الأوقات التي يكون فيها التوقيع آمناً – ومتى يكون شيء ما مريباً.

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

دائماً اسأل نفسك: لماذا أحوِّل رموزي إلى شخص آخر؟ التفكير في الأمر بهذه الطريقة يجعل الحكم أسهل على مما إذا كانت المعاملة مشروعةً أم لا.

تقوم بسكّ رمز غير قابل للاستبدال؟ – يجب ألا ترى هذه الوظيفة.

تقوم بشراء رمز غير قابل للاستبدال؟ – يجب ألا ترى هذه الوظيفة.

تقوم بالتسجيل في قائمة سماح؟ – أصبت التخمين – يجب ألا ترى هذه الوظيفة!

أنت الآن تفهم بالضبط ما يعنيه توقيع هذا النوع من المعاملات، أنت مؤهل لتقييم كل حالة تظهر فيها، وأن تقرر بنفسك إذا كانت إشارة إنذار.

2) SafeTransferFrom (تحويل آمن من)

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

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

المخاطر المرتبطة بـ SafeTransferFrom

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

الاحتيالات – وكيف تكتشفها

إذاً ما أنواع الاحتيالات التي تستخدم استدعاء هذه الوظيفة لخداع الأشخاص وتجريدهم من أصولهم المشفرة؟

مثال حديث يُرَى في موقع Momoco الذي يوفر سكّاً مجانياً لرموزه غير القابلة للاستبدال، والذي يقود أشخاص مقامرين غير ذوي خبرة إلى الموقع أملاً في المطالبة بالسكّ. المشكلة؟ لم يكن هناك سكّ.

بدلاً من ذلك، الضغط على زر “سكّ” أدى إلى ظهور استدعاء SafeTransferFrom (والتي وافق عليها المستخدمون اعتقاداً منهم أنها جزء من عملية السكّ، بفضل الهندسة الاجتماعية!). هذا أعطى موافقةً للعقد الذكي بتحويل رمز غير قابل للاستبدال خارج المحفظة المُستهدَفة – مما أدى إلى خسارة مئات الأشخاص لرمز غير قابل للاستبدال بسبب الاحتيال.

كيف كان من الممكن لهؤلاء الأشخاص اكتشاف الاحتيال قبل الوقوع فيه؟

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

هذه إشارة إنذار فورية: إذا كنت تقوم بالسكّ، ما يجب أن تراه هو وظيفة استدعاء “للسكّ”، وليس تحويلاً. في هذه الحالة، المعاملة تُظهر بوضوح تحويلاً. الرمز غير القابل للاستبدال ينتقل أيضاً من محفظة Ledger إلى عنوان محفظة آخر – مما يعني أن محفظتك ترسل رمزاً غير قابل للاستبدال، لا تستقبله.

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

3) SendEth (إرسال Eth)

وأخيراً! إذا كنت قد تفاعلت على ويب 3.0، فمن المحتمل أنك رأيت بالفعل وظيفة SendEth – هذا حرفياً يعني أنك تُرسل إيثر إلى محفظة أخرى. قد يكون هذا لأنك ترسل Eth بين عناوين محافظ مختلفة خاصة بك (على سبيل المثال، إذا اشتريت Ledger للتو، وتقوم بتحويل أموالك إلى مكان آمن)، أو إذا كنت تقوم بعملية شراء على سوق تجاري.

المخاطر المرتبطة بـ SendEth

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

الاحتيالات وكيفية اكتشافها

يمكنك رؤية هذا ليس فقط بالنظر إلى استدعاء الوظيفة (الذي كان يجب أن ينص “سكّ” إذا كانت حقيقةً عملية سكّ) ولكن أيضاً بالنظر إلى عنوان التلقي في أعلى اليمين – السكّ هو معاملة مباشرة مع سلسلة الكتل (blockchain) نفسها، وليس مع محفظةً أخرى، لذا مجدداً إن وجود عنوان تلقي هنا ينبغي أن يكون إشارة إنذار كبيرة أخرى.

احتيالات العقود الذكية: لا تثق – ولكن تحقق

إذاً إليك هذا: فهرس للوظائف الرئيسية للعقود الذكية (ومخاطرها) التي قد تواجهها بينما تتعامل مع ويب 3.0.

الآن بعد أن عرفت معاني هذه الوظائف المختلفة، على الأرجح ستكون الاحتيالات المرتبطة بها أكثر وضوحاً – لكن قوة الهندسة الاجتماعية قد تكون فعالةً جداً، خاصةً عندما تقترن بمعايير ويب 3.0 الجديدة الصعبة. لهذا السبب من المهم جداً أن تُسلِّح نفسك بالمعرفة قبل أن تبدأ رحلتك.

لذا انطلق، واستمر في التعلم، واستمتع بغمس نفسك في الإمكانات اللانهائية لويب 3.0! القوة بين يديك، وأكاديمية ليدجر (Ledger Academy) هنا لتضمن بقائها كذلك.

المعرفة قوة