هناك عبارة ربما تكون قد رأيتها مرات عديدة:
“قم بتوصيل محفظتك.”
ثم تظهر عبارة أخرى:
“وقّع الرسالة.”
أو:
“موافقة.”
وأخيرًا:
“تأكيد العملية.”
يفعل الكثير من المستخدمين مجرد النقر.
ولكن خلف ذلك النقر قد توجد فروق هائلة.
لأن في Web3:
التوقيع لا يعني دائمًا الشيء نفسه.
وفهم ما الذي نُخوّلُه قد يكون بنفس أهمية حماية كلمة المرور الخاصة بنا.
🔐 ماذا يعني “التوقيع” في عالم التشفير؟
عندما تقوم المحفظة بتوقيع عملية رقميًا، فإنها تستخدم مفتاحًا تشفيريًا لإثبات أن من يتحكم في هذا المفتاح يُخوّل بياناتًا محددة.
باختصار:
المفتاح الخاص → التوقيع الرقمي → التحقق باستخدام المفتاح العام → التفويض
لا ينبغي الكشف عن المفتاح الخاص.
يستخدمه المفتاح الخاص لإنشاء التوقيع.
يمكن للشبكة التحقق من هذا التوقيع دون الحاجة إلى معرفة المفتاح الخاص.
🧠 هل هي مثل التوقيع بخط اليد؟
ليس تمامًا.
يمكن لكليهما أداء وظائف المصادقة أو التفويض، لكنهما يعملان بآليات مختلفة تمامًا.
يعتمد التوقيع بخط اليد على عناصر بشرية ووثائقية.
يستخدم التوقيع التشفيري الرياضيات والتشفير.
في سلسلة الكتل، يتيح التوقيع التحقق من أن العملية المعينة قد أُجيزت من قِبل من يتحكم بالمفتاح المقابل.
💰 ماذا يحدث عندما أرسل عملات مشفّرة؟
لنفترض أن لديك:
1 ETH
وتريد إرسال:
0,2 ETH
إلى عنوان آخر.
تُعدّ محفظتك معاملة.
أنت تؤكّدها.
تستخدم المحفظة المفتاح المقابل لتوقيعها.
تُرسل المعاملة إلى الشبكة.
يمكن لمشاركي الشبكة التحقق من التوقيع.
إذا استوفت المعاملة قواعد البروتوكول:
قد تُدرج في كتلة.
⚠️ لكن ليس كل توقيع يعني «إرسال الأموال»
وهذه إحدى أهم النقاط.
يمكنك التفاعل مع عقد ذكي دون إرسال أموالك مباشرةً إلى شخص آخر.
على سبيل المثال:
موافقة
قد يتيح ذلك لعقد معيّن استخدام كمية محددة من رمز مميّز نيابةً عنك، وفقًا للمعيار والمعاملات المستخدمة.
لذلك:
«أنا لا أرسل عملات مشفّرة» لا يعني بالضرورة «أنا لا أتحمل أي مخاطر».
🪙 ما هو «Approve»؟
في بعض أنظمة الرموز المميّزة، قد تتيح المحفظة لعقد أو عنوان إنفاق الرموز نيابةً عن مالكها حتى حدٍّ معتمد.
على سبيل المثال:
لديك:
1.000 USDT
ويطلب منك تطبيقٌ الإذنَ باستخدام رموز مميّزة معيّنة.
إذا وافقت على إذن واسع النطاق، فقد تمنح العقد صلاحية تتجاوز العملية التي كنت تقصدها.
تعتمد الطبيعة الدقيقة للإذن على الرمز المميّز والمعيار وطريقة التنفيذ.
لذلك لا ينبغي أن نقبل أي طلب تلقائيًا.
🚨 مشكلة الموافقات غير المحدودة
قد تطلب بعض التطبيقات مبلغًا كبيرًا جدًا، أو حتى موافقة تتيح إنفاق كمية كبيرة جدًا من رمز مميّز معيّن.
قد يكون ذلك ملائمًا للمستخدم.
لكن ذلك قد يزيد أيضًا من التعرض للمخاطر.
إذا ظهرت لاحقًا ثغرة في العقد الذي وافقت عليه أو استُخدم على نحو خبيث، فقد يتحول هذا الإذن إلى مشكلة.
لذلك توجد أدوات وآليات لمراجعة بعض الموافقات أو إلغائها، وفقًا لسلسلة الكتل والمعيار المستخدمين.
🦹 كيف تعمل عملية احتيال نموذجية؟
تخيّل أنك تلقيت رسالة:
«لقد ربحت إنزالًا مجانيًا!»
تدخل إلى صفحة.
تربط محفظتك.
تطلب منك الصفحة:
«وقّع للمطالبة برموزك المميّزة.»
يبدو الأمر بريئًا.
لكن قد تطلب العملية شيئًا مختلفًا تمامًا عما يعتقده المستخدم.
قد يكون هناك:
موافقة؛
تفويض؛
تفاعل مع عقد؛
توقيع بيانات؛
أو عملية خبيثة.
لذلك:
يجب ألا توقّع أبدًا على شيء لا تفهمه.
🧾 «ربط المحفظة» ليس مثل «التوقيع»
هناك تمييز مهم آخر.
ربط المحفظة
ينشئ التطبيق اتصالًا بمحفظتك للتفاعل معك.
توقيع
تطلب محفظتك إذنًا لتوقيع بيانات معيّنة.
إرسال / تأكيد المعاملة
قد تكون بصدد التصريح بمعاملة ستُرسل إلى سلسلة الكتل.
إنهما إجراءان مختلفان.
لذلك، عندما تقول صفحة ما:
«اربط محفظتك للمتابعة»
ينبغي ألا تفسّر تلقائيًا ما يلي على أنه:
«لقد سلّمته عملاتي المشفّرة.»
لكن لا ينبغي لك أيضًا قبول أي طلب لاحق دون قراءته.
🔎 ما الذي ينبغي أن أتحقق منه قبل التوقيع؟
قبل الموافقة على معاملة، حاول تحديد ما يلي:
1️⃣ ما التطبيق الذي أستخدمه؟
هل هذه فعلًا المنصة التي أظنها؟
2️⃣ ما العقد الذي أستخدمه؟
هل عنوان العقد مطابق للعنوان الرسمي؟
3️⃣ ما الذي أوقّعه؟
هل هي معاملة؟
رسالة؟
هل هي موافقة؟
4️⃣ ما الأصل المعني؟
هل هو ETH؟
هل هو USDT؟
رمز مميّز آخر؟
5️⃣ ما المبلغ؟
هل هو مبلغ محدد؟
هل هو تفويض واسع النطاق؟
6️⃣ ما الأذونات التي أمنحها؟
خصوصًا عندما يتعلق الأمر بالرموز المميّزة.
7️⃣ هل يمكنني إلغاء الإذن؟
قد يكون ذلك ممكنًا، بحسب النظام المستخدم.
🧠 لماذا يريد المحتالون منك أن تتصرف بسرعة؟
لأن المستخدم الذي لديه وقت للتفكير يستطيع اكتشاف التناقضات.
لذلك تستخدم كثير من عمليات الاحتيال ما يلي:
«عاجل»
«الفرصة الأخيرة»
«طالب بها الآن»
«وقّع خلال 30 ثانية»
يشكّل الضغط النفسي جزءًا من كثير من أساليب التصيّد.
ينبغي أن تكون القاعدة:
إذا كانت معاملة مالية تتطلب منك التصرف دون قراءة، فتوقّف.
🔑 هل تستطيع المحفظة رؤية مفتاحي الخاص؟
لا ينبغي لمحفظة مصممة بشكل سليم أن تكشف مفتاحك الخاص لصفحة ويب لمجرد أنك ربطت المحفظة.
يجب أن يظل المفتاح الخاص محميًا.
يطلب التطبيق تنفيذ إجراء.
تعرض المحفظة الطلب.
أنت تقرر ما إذا كنت ستصرّح بها.
وتوقّع المحفظة باستخدام بيانات الاعتماد المناسبة.
لذلك تعمل المحفظة كنوع من:
واجهة للتحكم بمفاتيحك.
🚨 لكن ثمة خطر
إذا وافق المستخدم على شيء خبيث، فقد يصرّح بعملية تضر بأصوله.
لا تستطيع سلسلة الكتل بالضرورة التمييز بين:
«توقيع مشروع»
من
«توقيع تم الحصول عليه بالخداع».
من الناحية التشفيرية، قد يكون التوقيع صحيحًا تمامًا.
تكمن المشكلة في:
ما الذي تم التصريح به.
⚖️ وهنا يبرز سؤال قانوني مثير للاهتمام
إذا وقّع شخص ما عمليةً توقيعًا تشفيريًا…
هل يعني ذلك تلقائيًا أنه أراد قانونيًا تنفيذ ما نفّذه الرمز البرمجي بالضبط؟
ليس بالضرورة.
يجب تحليل الظروف.
على سبيل المثال:
هل حدث خداع؟
هل هي عملية تصيّد؟
هل هي معلومات مضللة؟
هل يوجد انتحال؟
هل يوجد اختراق أمني؟
هل وُجدت موافقة مستنيرة؟
ما المعلومات التي تلقاها المستخدم؟
ما الشروط التي وافق عليها؟
ما التشريع المنطبق؟
يمكن للتوقيع التشفيري أن يثبت أن مفتاحًا ما أجاز بيانات معيّنة.
لكن النقاش القانوني قد يكون أوسع بكثير.
⚖️ التوقيع التشفيري ≠ الموافقة القانونية التلقائية
هذا التمييز مهم جدًا.
توقيع تشفيري
يثبت تشفيريًا أن مفتاحًا معيّنًا أنشأ توقيعًا صحيحًا على بيانات معيّنة.
الموافقة القانونية
يتضمن ذلك تحليل ما إذا وُجدت إرادة ذات صلة قانونية والظروف التي صدرت فيها.
قد تكون هذه الأمور مترابطة.
لكن لا ينبغي الخلط بينهما تلقائيًا.
🛡️ 7 قواعد ذهبية قبل التوقيع
1️⃣ لا توقّع ما لا تفهمه.
2️⃣ تحقّق من الموقع الإلكتروني.
3️⃣ تحقّق من العقد عند الاقتضاء.
4️⃣ تحقّق من الرمز المميّز والمبلغ المعنيين.
5️⃣ احذر من الموافقات الواسعة أكثر من اللازم.
6️⃣ لا تشارك عبارة الاسترداد أو المفتاح الخاص مطلقًا.
7️⃣ إذا بدا شيء ما عاجلًا أو جيدًا أكثر من اللازم ليكون حقيقيًا:
توقّف.
🚨 قاعدة تساوي ذهبًا
لا تُدخل مطلقًا:
عبارة الاسترداد
أو
المفتاح الخاص
لـ«التحقق من» محفظة أو «مزامنتها» أو «تفعيلها» أو «اعتمادها» أو «استعادتها» عبر موقع إلكتروني مجهول.
لا ينبغي لمنصة شرعية أن تطلب منك تسليم بيانات اعتمادك السرية كي يقوم أحدهم «بتحرير» أموالك.
🧠 وماذا عن الرسائل التي نوقّعها؟
ليس كل توقيع ينقل الأموال بالضرورة.
تستخدم بعض التطبيقات توقيعات الرسائل من أجل:
تسجيل الدخول؛
إثبات التحكم بعنوان؛
التصريح بإجراءات معيّنة؛
التفاعل مع التطبيقات.
لكن مجددًا:
يجب قراءة ما يجري توقيعه.
قد يكون توقيع الرسالة غير ضار في سياق وخطيرًا في سياق آخر، بحسب محتواه وكيفية تفسير التطبيق له.
🎯 أسئلة مثيرة للاهتمام
❓ هل يعني التوقيع دائمًا إرسال عملات مشفّرة؟
لا. يمكنك توقيع رسائل أو التصريح بإجراءات معيّنة دون إجراء تحويل مباشر.
❓ هل يعني ربط محفظة أنني سلّمت أموالي؟
لا. الربط والتصريح إجراءان مختلفان.
❓ ما الموافقة على الرموز المميّزة؟
هو إذن قد يتيح، بحسب المعيار والعقد، لعنوان أو عقد معيّن استخدام الرموز المميّزة نيابةً عن المالك حتى الحد المصرّح به.
❓ هل يمكن أن يكون التوقيع الخبيث صحيحًا؟
نعم. قد يكون التوقيع صحيحًا من الناحية التشفيرية، وفي الوقت نفسه جرى الحصول عليه بالخداع أو استخدامه في عملية ضارة.
❓ هل تستطيع سلسلة الكتل إلغاء توقيع خاطئ؟
غالبًا لا يوجد زر موحّد لـ«التراجع». إذا نُفّذت العملية وأُكّدت بالفعل، فإن فرص استردادها تعتمد على الشبكة والأصل والمتلقي والظروف.
🔥 الفكرة الأخيرة
في التمويل التقليدي تعلّمنا:
«لا توقّع أي شيء دون قراءته.»
في Web3، ينبغي أن نضيف:
«لا توقّع أي شيء لا تفهمه.»
لأنك عندما تنقر على «تأكيد»، فأنت لا تكتفي بإغلاق نافذة.
قد تكون بصدد التصريح بما يلي:
تحويلًا،
موافقة،
تفاعلًا مع عقد ذكي،
أو أي عملية أخرى.
وبمجرد أن تسجّل سلسلة الكتل عملية صحيحة…
يمكن للتقنية تنفيذ ما أجَزته بالضبط، حتى إن لم تفهم حقًا ما كنت توقّعه.
📌 مسرد مصطلحات التشفير #12
توقيع معاملة = استخدام توقيع تشفيري للتصريح ببيانات أو عمليات معيّنة باستخدام بيانات اعتماد المحفظة.
السؤال الذي ينبغي لكل مستخدم أن يطرحه على نفسه قبل التأكيد هو:
«ما الذي أصرّح به فعلًا؟»
#GlosarioCripto #CryptoSecurity #SelfCustody #SmartContract #Web3