التوقيع الأعمى هو الموافقة على معاملة أو رسالة لا تستطيع محفظتك عرضها في صورة يقرأها الإنسان — calldata خام، أو كتلة سداسية معتمة، أو هاش من 32 بايت بدل جملة صريحة تبيّن ما الذي يخوّله التوقيع. وهو ليس إخفاقًا في التعمية: فالتوقيع صحيح تمامًا ويحمل صلاحية كاملة على السلسلة، ومن ثمّ فإن توقيع بيانات غير مقروءة يمنح أذونات لم تفحصها قط، ولهذا يكاد كل مستنزِف محافظ أن يُبنى حول هذه الفكرة. والعلاج هو التوقيع الواضح — أن تفكّ المحفظة الطلب إلى جملة تستطيع التحقق منها، وأن تحاكيه لتريك أي الأصول ستتحرك فعلًا — إضافةً إلى عادة لا يستطيع أي برنامج أن يوفّرها عنك: ارفض ما لا تستطيع قراءته. ولأن التوقيع هو بالضبط اللحظة التي تنتقل فيها الصلاحية، يهمّ أيضًا أن يكون المفتاح الذي ينتجه ملكك وحدك: المحفظة الساخنة من WATS غير وصائية عبر Ethereum وArbitrum وOptimism وBase وPolygon وBNB Chain وSolana وTON، فلا يتحرك شيء دون توقيع وافقتَ عليه بنفسك.
ما هو التوقيع الأعمى؟
التوقيع الأعمى هو أي موافقة انفصل فيها الطلب عن طريقة عرضه. تنفّذ السلسلة ما تقوله البايتات الموقّعة، وشاشتك هي المكان الوحيد الذي يمكن فيه مقارنة نيّتك بالمحتوى الفعلي. وحين تعرض الشاشة سداسيًا تصبح تلك المقارنة مستحيلة — والمهاجمون يبنون على هذه الاستحالة بالذات.
الفجوة فجوة معلومات لا فجوة رياضيات. فالتوقيع لا يرمّز "وافقتُ على مبادلة 100 USDC"، بل يرمّز "هذا المفتاح يخوّل هذه البايتات". أما إن كانت تلك البايتات تعني مبادلة، أو موافقة غير محدودة، أو أمرًا خارج السلسلة يبيع NFT الخاص بك بلا مقابل، فذلك سؤال لا تجيب عنه إلا الواجهة — والتوقيع الأعمى هو ما يحدث حين تمتنع الواجهة عن الإجابة.
أين يظهر التوقيع الأعمى
التوقيع الأعمى ليس خاصية واحدة، بل عائلة من المواقف يخذل فيها العرضُ البيانات. وهذه أشهر الحالات:
| نوع الطلب | ما تراه عادةً | الخطر |
|---|---|---|
| eth_sign | هاش خام أو كتلة سداسية | حرج — غير قابل للتحقق بحكم التصميم؛ ارفضه دائمًا |
| بيانات مُهيكلة خام (EIP-712) | حقول مُهيكلة — المنفِق (spender) والمقدار والموعد النهائي | مرتفع حين يكون المعنى غامضًا — الحقل المقروء ليس بالضرورة حقلًا مفهومًا |
| معاملة عقد | إجراء مفكوك، أو calldata خام حين تعجز المحفظة عن فكّه | يتوقف كليًا على قدرة المحفظة على الفك |
| شاشة عتاد لا تعرض سوى هاش | هاش فقط على شاشة الجهاز | مرتفع — يؤكد الجهاز حضورك لا فهمك |
والنمط الجامع للصفوف الأربعة: الخطر يسير مع القابلية للقراءة. وحيثما رقّ العرض، غلُظ الخطر.
لماذا eth_sign بهذه الخطورة؟
بين طرق التوقيع، يمثّل eth_sign أنقى صور المشكلة: فهو يطلب من محفظتك توقيع قيمة عشوائية من 32 بايت، تُعرض عليك سداسيًا خامًا، دون أي من البادئات التي تُعلّم الرسالة بأنها "مجرد رسالة". ولأن المُدخل لا يحمل فصلًا للنطاق، فقد يكون أي شيء — بما في ذلك هاش معاملة تُخرج الأصول من حسابك. ولا سبيل، ولو لخبير متأنٍّ، للتحقق من الطلب من الرسالة وحدها؛ إنه غير قابل للتحقق بحكم التصميم. لهذا أهملت المحافظ الكبرى هذه الطريقة أو أزالتها كليًا، ولهذا لا استثناء في القاعدة العملية: حتى عام 2026، الموقع الذي يطلب eth_sign إما متقادم إلى حدّ الخطر وإما معادٍ عن قصد، وكلا الجوابين يعني الرفض.
ماذا تعرض عليك محفظة العتاد فعلًا؟
تُبقي محفظة العتاد المفاتيح خارج الاتصال وتعرض الطلبات على شاشة لا تستطيع البرمجيات الخبيثة تغييرها — لكن تلك الشاشة لا تنفع إلا بقدر ما يُعرض عليها. ففي تفاعلات العقود التي لا يفهمها الجهاز، تراجعت أجهزة كثيرة تاريخيًا إلى عرض هاش فحسب، خلف مفتاح إعدادات اسمه حرفيًا التوقيع الأعمى. وتأكيد هاش على شاشة موثوقة يثبت أنك ضغطت الزر، ولا يثبت شيئًا عمّا وافقت عليه. وعْد أمان العتاد هو ما تراه هو ما توقّعه — وهو وعد ينهار بهدوء حين يكون ما تراه اثنين وثلاثين بايتًا من الضجيج. عزل العتاد يحمي المفتاح، لا القرار.
كيف تستغل المستنزِفات التوقيع الأعمى؟
عدّة المستنزِف هي، قبل أي شيء آخر، هجوم على تجربة التوقيع. يبدو الموقع كصفحة سكّ، أو مطالبة بإسقاط جوي، أو بوابة دعم؛ أما الطلب الذي يطلقه فهو موافقة توكن غير محدودة، أو setApprovalForAll يغطي مجموعة NFT بأكملها، أو توقيع Permit أو أمر خارج السلسلة يحرّك الأصول لاحقًا دون أي مطالبة إضافية. وما يجمع هذه جميعًا هو طريقة العرض: وقّع الضحية طلبًا لم يستطع قراءته — أو قرأه ولم يفهمه — ثم جاء التفريغ. الخطة كاملةً مشروحة في ما هو مستنزِف المحافظ، وآليات الموافقة — بما في ذلك كيف يُفرّغ توقيع واحد بلا غاز رصيد توكن — في شرح موافقات التوكنات وPermit. وكلاهما يصل إلى السبب الجذري نفسه: السرقة تقع لحظة التوقيع، والتوقيع الأعمى هو ما يجعل تلك اللحظة قابلة للنجاة بالنسبة إلى المهاجم.
ما هو التوقيع الواضح — وإلى أين وصل؟
جواب القطاع هو التوقيع الواضح — المبدأ القائل بأن على المحفظة أن تترجم كل طلب إلى عبارات يستطيع الإنسان التحقق منها قبل أن تطلب توقيعًا. وحتى عام 2026 يقوم هذا على آليتين. الفك: تتعرّف المحفظة على العقد والدالة المستدعاة وتعرضهما كجملة — الموافقة على التوكن X، المنفِق Y، المقدار غير محدود — مع جهود مثل ERC-7730 التي تبني سجلات بيانات وصفية مفتوحة كي تستطيع حتى شاشات محافظ العتاد عرض استدعاءات العقود بلغة البشر بدل هاش. المحاكاة: تشغّل المحفظة، أو خدمة تستدعيها، المعاملة على حالة السلسلة الراهنة قبل أن توقّع، وتعرض النتيجة سلفًا — أي الأصول تخرج، وأيها تدخل، وأي الموافقات تتغيّر. والمحاكاة تنبؤ لا ضمان — فقد تتبدّل الحالة بين المعاينة والإدراج، وقد يسلك عقد معادٍ سلوكًا مختلفًا بعد التعدين — لكن معاينةً تُظهر NFT الخاص بك مغادرًا إلى عنوان مجهول توقف معظم عمليات التفريغ في مكانها. ولا يزال التبني متفاوتًا بين المحافظ والسلاسل حتى عام 2026، فتحقّق مما تعرضه محفظتك أنت فعلًا في إجراء روتيني قبل أن تأتمنها على تحذيرك.
قواعد عملية: عامِل غير المقروء كغير موثوق
لست بحاجة إلى قراءة calldata لتبقى آمنًا — بل إلى عادات تجعل الطلبات غير المقروءة تفشل بأمان:
- لا توافق أبدًا على طلب eth_sign. لم يبقَ له استخدام مشروع شائع — عامِل الطلب نفسه كعلامة إنذار.
- فضّل المحافظ التي تفكّ وتحاكي. إن عرضت محفظتك سداسيًا خامًا في إجراء روتيني، فتلك مشكلة محفظة تستحق التبديل.
- اقرأ الحقول التي تهم في طلبات البيانات المُهيكلة: المنفِق، والمقدار، والموعد النهائي، والمشغّل (operator). المقدار غير المحدود أو المنفِق المجهول علامة توقف.
- أبقِ أوضاع التوقيع الأعمى في العتاد مغلقة ما لم تفهم تمامًا لماذا تحتاجها معاملة بعينها — ثم أعد إغلاقها بعدها.
- اتصل عن قصد. معظم الطلبات السيئة تصل عبر اتصالات متعجّلة — والروتين الوارد في كيفية ربط محفظتك بتطبيق dApp بأمان يبقي الباب الأمامي محروسًا.
- غير المقروء يساوي غير الموثوق. رفض توقيع لا يكلّفك سوى محاولة جديدة، أما توقيع خاطئ فقد يكلّفك كل شيء. هذا التفاوت يحسم الأمر عنك.
أين تقع WATS
التوقيع الأعمى مشكلة عرض. يستطيع الفك والمحاكاة تقديم الطلب بعبارات مقروءة، لكن لا محفظة — بما فيها WATS — تستطيع أن تقرر عنك ما إذا كان الطلب هو ما تريده فعلًا. أما ما تحسمه المحفظة فهو من يتحكم في المفتاح الذي يحوّل ذلك القرار إلى صلاحية. المحفظة الساخنة من WATS غير وصائية بالكامل: أنت تحتفظ بمفاتيحك، وWATS لا تحتفظ بمفتاح أبدًا، ولا يغادر حسابك أي تحويل دون توقيع وافقت عليه على Ethereum أو Arbitrum أو Optimism أو Base أو Polygon أو BNB Chain أو Solana أو TON. هذا يقطع صنفًا كاملًا من الخطر — فلا أحد يستطيع التوقيع نيابةً عنك — بينما يترك انضباط القراءة الموصوف أعلاه على عاتقك وحدك.
وبطاقة WATS NFC المعدنية تقف في الموضع الصادق نفسه. فهي لا تخزّن مفاتيح خاصة ولا تفكّ calldata: إنها جهاز مصادقة باللمس، له معرّف بطاقة فريد، ويقترن بجهاز واحد بالضبط، ويصادق على مفاتيح تعيش داخل تطبيقات WATS. وهذا يضيف عاملًا ماديًا — شيئًا تمسكه، لا شيئًا على شاشتك فحسب — لكنه لا يستطيع أن يجعل طلبًا غير مقروء مقروءًا. لا شيء يستطيع ذلك سوى الرسالة نفسها.
فعامِل النصفين على حدة. نصف القراءة عادة: لا توقّع أبدًا ما لا تستطيع قراءته، وارفض كل ما يصلك سداسيًا عاريًا. ونصف الوصاية خيار تتخذه مرة واحدة: أبقِ مفاتيحك في محفظة غير وصائية، وأبقِ صلاحية التوقيع حيث تنتمي. ثبّت المحفظة الساخنة من WATS، واجعل كل رسالة غير مقروءة رفضًا تلقائيًا، واقرن بطاقة WATS NFC المعدنية بجهازك إن أردت عاملًا ماديًا يصادقك على المفاتيح داخل تطبيقات WATS.
الأسئلة الشائعة
هل التوقيع الأعمى هو نفسه eth_sign؟
لا — eth_sign أشدّ حالاته تطرفًا. التوقيع الأعمى هو أي موافقة لا تستطيع فيها قراءة ما تخوّله: calldata خام، أو بيانات مُهيكلة معتمة، أو شاشة عتاد لا تعرض سوى هاش. ويمضي eth_sign أبعد بكونه غير قابل للتحقق من حيث المبدأ، ولهذا أهملته المحافظ الكبرى أو أزالته. كل طلب eth_sign توقيع أعمى، لكن كثيرًا من التوقيع الأعمى يقع أيضًا في رسائل المعاملات العادية.
هل تحميني محفظة العتاد من التوقيع الأعمى؟
جزئيًا فقط. تُبقي محفظة العتاد مفاتيحك خارج الاتصال وتعرض الطلبات على شاشة لا تعبث بها البرمجيات الخبيثة — لكن إن عجز الجهاز عن فك استدعاء عقد فقد لا يعرض سوى هاش، وتأكيد الهاش لا يخبرك بشيء عمّا وافقت عليه. وتتحسّن الحماية مع وصول معايير البيانات الوصفية للتوقيع الواضح إلى شاشات الأجهزة حتى عام 2026. العتاد يعزل المفتاح؛ وهو لا يشرح المعاملة بذاته.
هل تحميني محفظة غير وصائية من التوقيع الأعمى؟
إنها تحمي المفتاح لا القرار. كونها غير وصائية يعني أنك وحدك من يستطيع إنتاج توقيع — والمحفظة الساخنة من WATS مثال على ذلك: أنت تحتفظ بمفاتيحك، وWATS لا تحتفظ بمفتاح أبدًا، ولا يتحرك شيء على Ethereum أو Arbitrum أو Optimism أو Base أو Polygon أو BNB Chain أو Solana أو TON دون موافقتك. وهذا يزيل خطر أن يوقّع أحد غيرك نيابةً عنك، لكن التوقيع الذي توافق عليه بنفسك يبقى ملزِمًا، فتظل قراءة الطلب قبل الموافقة عليه مهمتك أنت. وتضيف بطاقة WATS NFC المعدنية عامل مصادقة ماديًا باللمس للمفاتيح التي تعيش داخل تطبيقات WATS — وهي لا تخزّن مفاتيح خاصة ولا تفكّ calldata.
ماذا أفعل حين لا تعرض المحفظة سوى سداسي خام؟
ارفضه. طلب توقيع لا تستطيع قراءته هو طلب لا تستطيع تقييمه، والرفض لا يكلّفك سوى محاولة جديدة. ثم تحقّق: هل تطبيق الـ dApp أصلي، وهل تدعم محفظتك الفك والمحاكاة على تلك السلسلة، وهل يحتاج الإجراء فعلًا إلى تلك الطريقة؟ فإن وُجد مسار مقروء — رسالة مفكوكة أو معاينة محاكاة — فاستخدمه. وإن لم يوجد أي مسار، فعامِل الطلب كغير موثوق وامضِ بعيدًا.

