التوقيع

ما هو التوقيع في الكريبتو؟

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

على عكس التوقيع بخط اليد، يُنشأ توقيع الكريبتو باستخدام التشفير، ويمكن للبرامج التحقق منه دون الكشف عن المفتاح الخاص.

يوضح معيار NIST الرسمي للتوقيع الرقمي أن التوقيعات الرقمية تُستخدم لاكتشاف التغييرات غير المصرح بها في البيانات ومصادقة هوية الموقّع.

في أنظمة البلوكشين، يثبت التوقيع أن الشخص أو النظام الذي يتحكم في مفتاح خاص قد فوّض بيانات محددة.

ولهذا يمكن للمستخدمين إرسال العملات المشفرة دون إدخال اسم مستخدم أو كلمة مرور أو رمز تفويض شبيه بالرموز المصرفية في البلوكشين نفسها.

توقّع المحفظة المعاملة، وتتحقق الشبكة من أن التوقيع يطابق الحساب الذي يحاول إنفاق الأموال أو تنفيذ إجراء.

لا يثبت التوقيع أن الموقّع فهم المعاملة.

إنما يثبت أن المفتاح الخاص أو المحفظة أو الحساب القائم على عقد أنتج تفويضًا صالحًا للبيانات الموقعة.

بعبارات بسيطة، توقيع الكريبتو هو الموافقة الرياضية التي تخبر البلوكشين أو التطبيق بأن «هذه المحفظة فوّضت هذا الإجراء المحدد بالضبط».

لماذا تهم التوقيعات في الكريبتو؟

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

توضح وثائق حسابات Ethereum الرسمية أن الحسابات تستخدم أزواج المفاتيح العامة والخاصة، وأن المفاتيح الخاصة تُستخدم لتوقيع الرسائل والمعاملات.

عندما يوقّع المستخدم معاملة، تستطيع البلوكشين تأكيد أن مالك الحساب فوّضها دون الاطلاع على المفتاح الخاص.

وهذا يجعل التوقيعات أحد أهم أسس الحفظ الذاتي.

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

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

يمكن للعقد الذكي قبول تصريح أو طلب أو موافقة أو تصويت موقّع وتنفيذ منطق برمجي بناءً على هذا التفويض.

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

بالنسبة للمستخدمين، تهم التوقيعات لأن التوقيع غالبًا ما يكون الخطوة الأخيرة قبل تغيير الأصول الفعلية أو الأذونات أو الحقوق.

وبالنسبة للمطورين، تهم التوقيعات لأن تدفق توقيع ضعيفًا واحدًا قد يعرّض بروتوكولًا كاملًا لهجمات إعادة التشغيل أو التصيد الاحتيالي أو التنفيذ غير المصرح به.

كيف يعمل توقيع الكريبتو؟

يُنشأ توقيع الكريبتو عندما تستخدم برمجية المحفظة مفتاحًا خاصًا لتوقيع معاملة أو رسالة محددة.

تُعِدّ المحفظة أولًا البيانات التي تحتاج إلى موافقة.

ثم تُجزّئ المحفظة تلك البيانات أو ترمّزها وفقًا لقواعد التوقيع الخاصة بالبلوكشين.

يُستخدم المفتاح الخاص ضمن خوارزمية توقيع رقمي لإنتاج التوقيع.

ويُرفق التوقيع بالمعاملة أو يُرسَل مع الرسالة.

يمكن لبرامج أخرى استخدام التوقيع والبيانات الموقعة ومفتاح عام أو عنوان للتحقق من صلاحية التوقيع.

إذا تغيرت البيانات، فلا ينبغي أن يظل التوقيع نفسه قابلًا للتحقق للبيانات المعدلة.

وهذا يعني أن التوقيع يحمي التفويض وسلامة البيانات معًا.

يثبت التوقيع الصالح أن الموقّع وافق على حمولة بيانات محددة، لا على نية عامة غامضة.

ولهذا ينبغي للمستخدمين الاهتمام بما تطلب منهم محافظهم توقيعه تحديدًا.

المفتاح الخاص

المفتاح الخاص هو القيمة السرية التي تُنشئ توقيعات الكريبتو.

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

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

غالبًا ما تحوّل المحافظ التحكم بالمفتاح الخاص إلى عبارة أولية أو عبارة استرداد كي يتمكن المستخدمون من عمل نسخة احتياطية من حساباتهم.

يحذر دليل أمان محفظة Bitcoin الرسمي المستخدمين من ضرورة تأمين محافظهم لأن التحكم بالمفتاح الخاص ضروري للتحكم بالأموال.

عندما يوقّع مفتاح خاص بيانات، لا يحتاج المفتاح الخاص إلى مغادرة المحفظة أو جهاز التوقيع.

ولهذا يمكن للمحافظ الباردة إنشاء التوقيعات مع إبقاء المفتاح الخاص معزولًا عن الكمبيوتر أو الهاتف.

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

لذلك يبدأ أمان التوقيع بأمان المفتاح الخاص.

المفتاح العام

المفتاح العام هو القيمة التي تتيح للآخرين التحقق من التوقيعات التي أنشأها المفتاح الخاص المطابق.

يمكن مشاركة المفتاح العام لأنه، وفقًا لافتراضات التشفير المعتادة، لا ينبغي أن يكشف المفتاح الخاص.

تُشتق عناوين بلوكشين كثيرة من المفاتيح العامة أو تجزئات المفاتيح العامة.

يمكن للتوقيع إثبات أن الموقّع كان يتحكم في المفتاح الخاص المرتبط بالمفتاح العام أو العنوان.

لكن هذا لا يثبت هوية الموقّع في العالم الحقيقي، ما لم يكن ذلك العنوان مرتبطًا بهوية عبر عملية منفصلة.

فعلى سبيل المثال، قد يثبت توقيع صالح التحكم في عنوان محفظة، لكنه لا يثبت أن الموقّع جدير بالثقة.

تعمل المفاتيح العامة والتوقيعات معًا لدعم الملكية دون سلطة مركزية للحسابات.

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

يتحقق المفتاح العام من التحكم، بينما ينشئ المفتاح الخاص هذا التحكم.

توقيع المعاملة

توقيع المعاملة هو توقيع مرفق بمعاملة على البلوكشين.

وهو يثبت أن الموقّع المطلوب وافق على محتويات المعاملة.

في Bitcoin، تساعد التوقيعات في إثبات أن المنفق مخول بإنفاق مخرجات محددة وفق قواعد النص البرمجي.

تنص إرشادات مطوري معاملات Bitcoin على أن Bitcoin تستخدم ECDSA مع منحنى secp256k1.

في الأنظمة المشابهة لـ Ethereum، يفوّض توقيع المعاملة حسابًا لاستخدام nonce الخاص به، ودفع الرسوم، وإرسال القيمة، واستدعاء بيانات العقد.

في Solana، قد تتطلب المعاملات توقيعات من حسابات متعددة بحسب التعليمات الجاري تنفيذها.

تنص وثائق معاملات Solana الرسمية على أن كل موقّع يقدم توقيع Ed25519 بحجم 64 بايت.

إذا كان توقيع المعاملة المطلوب مفقودًا أو غير صالح، فينبغي للشبكة رفض المعاملة.

ولهذا تُعد توقيعات المعاملات أساسية لمنع التحويلات غير المصرح بها.

توقيع الرسالة

توقيع الرسالة هو توقيع على رسالة قد لا تتحول فورًا إلى معاملة على السلسلة.

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

قد يبدو توقيع الرسالة غير ضار لأنه لا يبث معاملة فورًا.

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

على سبيل المثال، قد يسمح تصريح موقّع لعنوان آخر بإنفاق التوكنات وفق قواعد محددة.

وقد يسمح طلب موقّع بتنفيذ صفقة لاحقًا.

وقد تسمح مطالبة موقعة لشخص ما بتلقي توكنات من عقد توزيع.

ينبغي للمستخدمين قراءة مطالبات الرسائل بعناية، لأن توقيعات الرسائل قد تنطوي على معنى مالي حقيقي.

التوقيع دون رسوم غاز لا يعني توقيعًا خاليًا من المخاطر.

التوقيع مقابل التحقق من التوقيع

التوقيع هو الإثبات الذي ينشئه الموقّع.

التحقق من التوقيع هو عملية فحص ما إذا كان ذلك الإثبات صالحًا.

يحدث التوقيع عندما تستخدم المحفظة مفتاحًا خاصًا أو قاعدة حساب للموافقة على البيانات.

ويحدث التحقق عندما تفحص عقدة أو محفظة أو تطبيق أو عقد ذكي أو خادم تطابق التوقيع مع الموقّع والرسالة المتوقعين.

كلتا الخطوتين ضروريتان لتفويض آمن في الكريبتو.

التوقيع الذي لا يجري التحقق منه غير مفيد.

وينبغي لعملية تحقق بلا توقيع صحيح أن ترفض الإجراء.

يختبر المستخدمون التوقيع عادةً عبر مطالبات المحفظة، بينما يحدث التحقق في الخلفية.

ويجب أن يفهم المطورون كليهما، لأن قاعدة تحقق سيئة قد تقبل توقيعات لا ينبغي قبولها.

توقيع ECDSA

يرمز ECDSA إلى Elliptic Curve Digital Signature Algorithm.

تستخدم Bitcoin والأنظمة المشابهة لـ Ethereum عادةً ECDSA فوق منحنى secp256k1 لتوقيعات الحسابات والمعاملات.

يُمثل توقيع ECDSA عادةً بقيم توقيع تتيح للبرامج التحقق من أن مفتاحًا خاصًا وافق على البيانات الموقعة.

غالبًا ما تتضمن التوقيعات المشابهة لـ Ethereum قيمة استرداد تساعد على استعادة المفتاح العام أو عنوان الموقّع من التوقيع.

استُخدم ECDSA على نطاق واسع في الكريبتو، لكنه يجب أن يُنفذ بعناية.

قد تكشف العشوائية الضعيفة أو إعادة استخدام nonce أثناء التوقيع المفاتيح الخاصة.

وقد يؤدي التحقق السيئ من التوقيع إلى مشكلات القابلية للتعديل أو إعادة التشغيل.

ينبغي للمطورين استخدام مكتبات تشفير ناضجة بدلًا من كتابة كود ECDSA مخصص.

ينبغي للمستخدمين فهم أن توقيع ECDSA الصالح دليل قوي على التحكم بالمفتاح، لكنه ليس دليلًا على أن الإجراء الموقّع آمن.

توقيع Schnorr

توقيع Schnorr هو نوع آخر من التوقيع الرقمي يُستخدم في بعض السياقات المرتبطة بـ Bitcoin وأنظمة تشفير أخرى.

تحدد مواصفة توقيعات BIP-340 Schnorr مخطط توقيع Schnorr لمنحنى secp256k1.

يمكن لتوقيعات Schnorr دعم مزايا مثل خصائص التجميع الأبسط وتصميم توقيع أنظف في أنظمة معينة.

في Bitcoin، ترتبط توقيعات Schnorr بتحسينات عصر Taproot.

قد يساعد تجميع التوقيعات والتصاميم ذات الصلة في خفض حجم البيانات وتحسين الخصوصية في بعض حالات الاستخدام المتقدمة.

لا يختار المستخدمون عادةً بين ECDSA وSchnorr يدويًا أثناء استخدام المحفظة المعتاد.

تحدد المحفظة ونوع النص البرمجي وقواعد الشبكة طريقة التوقيع المنطبقة.

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

تنسيق التوقيع جزء من بنية أمان البلوكشين.

توقيع Ed25519

Ed25519 هو مخطط توقيع رقمي تستخدمه عدة أنظمة بلوكشين، ومنها Solana لتوقيعات المعاملات العادية.

توقيعات Ed25519 مدمجة وفعالة، ما يجعلها مفيدة لبيئات البلوكشين عالية الإنتاجية.

تتطلب معاملات Solana توقيعات من الحسابات المعلّمة كموقّعين في رسالة المعاملة.

وتثبت هذه التوقيعات أن السلطات المطلوبة وافقت على التعليمات.

بالنسبة لمطوري Solana، لا يكفي افتراض تمرير حساب إلى برنامج بشكل صحيح.

يجب على البرنامج أيضًا التحقق من أن الحساب الصحيح وقّع عندما تكون سلطة الموقّع مطلوبة.

قد يتحول غياب فحص الموقّع إلى ثغرة خطيرة في العقد الذكي أو البرنامج.

ينبغي للمستخدمين تذكر أن توقيع Ed25519 يظل حدث تفويض.

وقد تؤدي الموافقة على المعاملة الخاطئة إلى نقل الأصول أو منح أذونات.

حمولة التوقيع

حمولة التوقيع هي البيانات الدقيقة التي يجري توقيعها.

بالنسبة إلى معاملة، قد تتضمن الحمولة معلومات المرسل والمستلم والقيمة والرسوم وnonce ومعرّف السلسلة والتعليمات وبيانات العقد أو حقولًا أخرى بحسب الشبكة.

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

يمكن للمفتاح الخاص نفسه توقيع حمولات كثيرة مختلفة، ولذلك يأتي المعنى من الحمولة الدقيقة.

ولهذا يجب ألا يوقّع المستخدم بيانات غامضة أو غير مقروءة إذا لم يفهم ما الذي تفوضه.

لا ينبغي أن يكون التوقيع على حمولة واحدة صالحًا لحمولة أخرى.

تجعل معايير التوقيع الجيدة الحمولة واضحة ومحددة بالسياق.

وقد يجعل تصميم التوقيع السيئ التوقيعات قابلة لإعادة الاستخدام أو مربكة أو خطرة.

في الكريبتو، الحمولة هي التعليمات والتوقيع هو الموافقة.

هاش التوقيع

هاش التوقيع هو تجزئة للبيانات التي يجري توقيعها.

تحوّل التجزئة البيانات إلى ملخص ثابت الحجم قبل أن تعالجها خوارزمية التوقيع.

وهذا يجعل التوقيع فعالًا ويساعد على ضمان أن يؤدي حتى التغيير الطفيف في البيانات إلى نتيجة توقيع مختلفة.

تستخدم البلوكشينات والمعايير المختلفة قواعد تجزئة وترميز مختلفة.

لا تُنسق جميعها بالطريقة نفسها: توقيع معاملة Bitcoin، وتوقيع البيانات المهيكلة في Ethereum، وتوقيع معاملة Solana.

يجب على المطورين استخدام قواعد التجزئة الصحيحة للشبكة المستهدفة ومعيار التوقيع.

إذا وُقّع أو جرى التحقق من هاش خاطئ، فقد يفشل التوقيع أو ينشئ عدم تطابق خطيرًا.

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

لا يكون للتوقيع معنى إلا إذا جرى تجزئة البيانات الصحيحة وتوقيعها.

البيانات الموقعة في Ethereum

تدعم Ethereum عدة تنسيقات توقيع للرسائل والبيانات المهيكلة.

يحدد معيار البيانات الموقعة ERC-191 تنسيقًا معياريًا لمعالجة البيانات الموقعة في عقود Ethereum.

يساعد ERC-191 على التمييز بين الرسائل الموقعة والمعاملات الخام، ويدعم معالجة أكثر أمانًا للبيانات الموقعة.

يحدد معيار البيانات المهيكلة المكتوبة EIP-712 طريقة لتجزئة البيانات المهيكلة المكتوبة وتوقيعها.

يكتسب EIP-712 أهمية لأنه قد يجعل مطالبات التوقيع أكثر قابلية للقراءة وأكثر تحديدًا بالسياق.

قد يتضمن توقيع البيانات المكتوبة معلومات النطاق، مثل التطبيق والسلسلة والعقد والإصدار وتفاصيل الإجراء.

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

ينبغي للمستخدمين مراجعة توقيعات البيانات المكتوبة بعناية، لأن المطالبة القابلة للقراءة قد تظل تفوض إجراءً محفوفًا بالمخاطر.

تحسن المعايير الوضوح، لكنها لا تغني عن الحذر.

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

قد تستخدم محافظ العقود الذكية منطق توقيع يختلف عن حساب بسيط بمفتاح خاص.

يحدد معيار التحقق من التوقيع ERC-1271 طريقة للعقود لتأكيد صلاحية توقيع لهاش معين.

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

يمكن للحساب العادي المملوك خارجيًا إنتاج توقيع مباشرةً بمفتاح خاص.

أما محفظة العقد الذكي فقد تتحقق من التفويض عبر منطق العقد.

قد تفشل التطبيقات التي تدعم توقيعات الحسابات البسيطة فقط مع محافظ العقود الذكية.

ومع نمو تجريد الحساب، تصبح أنظمة التوقيع أكثر مرونة.

يوضح مسار تجريد الحساب في Ethereum أن تجريد الحساب يمكن أن يجعل المحافظ أكثر قابلية للبرمجة.

في هذه البيئة، قد يعني التوقيع موافقة مفتاح أو مجموعة أو مجموعة قواعد أو سياسة حساب عقد ذكي.

التوقيع المتعدد

تتطلب المحفظة متعددة التوقيعات أكثر من توقيع أو موافقة واحدة قبل تنفيذ إجراء.

على سبيل المثال، قد تتطلب المحفظة توقيعين من ثلاثة موقّعين أو ثلاثة من خمسة.

تقلل أنظمة التوقيع المتعدد مخاطر المفتاح الواحد، لأن سرقة مفتاح واحد قد لا تكفي لنقل الأموال.

وهي تُستخدم على نطاق واسع للخزائن وأدوار إدارة البروتوكولات وتدفقات الحفظ والأموال الخاضعة لتحكم الفرق.

لكن إعداد التوقيع المتعدد يظل معتمدًا على مراجعة واضحة للمعاملات واستقلالية الموقّعين.

إذا وافق عدة موقّعين على المعاملة الضارة نفسها، فقد تُنفذ المعاملة رغم ذلك.

لذلك فإن أمان التوقيع المتعدد تقني وتشغيلي معًا.

تشمل الممارسة الجيدة للتوقيع المتعدد أجهزة منفصلة وأشخاصًا منفصلين وسياسات واضحة ومحاكاة المعاملات والتحقق الدقيق من العناوين.

قد تحسن التوقيعات المتعددة الأمان، لكنها لا تلغي الحاجة إلى الحكم البشري.

توقيع العتبة

توقيع العتبة هو نظام تشفيري يتعاون فيه عدد مطلوب من المشاركين لإنتاج توقيع صالح واحد.

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

وقد يحسن هذا الخصوصية أو يخفض حجم البيانات أو يدعم تصاميم الحفظ المؤسسي بحسب السلسلة والتنفيذ.

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

لكنه قد يضيف تعقيدًا تشغيليًا لأن على المشاركين التنسيق بشكل صحيح.

وقد يفشل نظام العتبة إذا كان عدد كبير جدًا من المشاركين غير متصلين أو مخترقين أو غير متاحين.

ينبغي للمستخدمين فهم نموذج الحفظ وراء أي محفظة أو خدمة تستخدم توقيع العتبة.

الفكرة الأساسية هي توزيع سلطة التوقيع دون منح جهاز أو شخص واحد تحكمًا كاملًا.

توضح توقيعات العتبة أن توقيعات الكريبتو يمكن أن تدعم تصاميم أمان متقدمة تتجاوز مفتاحًا واحدًا ومحفظة واحدة.

التوقيع والموافقة على التوكنات

يمكن للتوقيع تفويض موافقة على توكن عندما يدعم التوكن أو التطبيق تدفقات موافقات موقعة.

غالبًا ما تُرسل الموافقة العادية على التوكن كمعاملة على السلسلة.

يمكن أحيانًا إنشاء موافقة موقعة خارج السلسلة وإرسالها لاحقًا من طرف آخر أو عقد.

قد يوفر ذلك الوقت والرسوم، لكنه قد يربك المستخدمين أيضًا.

قد يعتقد المستخدم أنه يوقّع رسالة فقط، بينما هو يمنح فعليًا إذن إنفاق.

ينبغي أن تتضمن الموافقات الموقعة التوكن والمالك والمنفق والمبلغ وnonce والموعد النهائي والسلسلة وعقد التحقق عند الحاجة.

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

ينبغي للمستخدمين التعامل مع توقيعات الموافقة بالحذر نفسه الذي يتعاملون به مع معاملات الموافقة.

قد يكون التوقيع الذي يمنح حقوق الإنفاق خطيرًا بقدر معاملة مباشرة.

التوقيع والحوكمة

يمكن لأنظمة الحوكمة استخدام التوقيعات لجمع الأصوات أو تفويض قوة التصويت أو تفويض إجراءات المقترحات.

يعتمد التصويت خارج السلسلة غالبًا على توقيع المستخدمين رسائل مهيكلة تمثل اختيارهم.

قد يخفض ذلك رسوم المعاملات ويجعل المشاركة أسهل.

لكن توقيعات الحوكمة قد تؤثر في قرارات بروتوكول حقيقية.

قد يؤثر التصويت الموقّع في إنفاق الخزينة أو الترقيات أو تغييرات المعلمات أو قرارات المجتمع.

ينبغي للمستخدمين قراءة مطالبات توقيع الحوكمة بعناية قبل الموافقة عليها.

ينبغي للمطورين تضمين معرفات المقترحات ومعلومات السلسلة وخيار التصويت والموعد النهائي وبيانات نطاق الحوكمة في الحمولة الموقعة.

تقلل أنظمة توقيع الحوكمة الجيدة الغموض وخطر إعادة التشغيل.

يثبت توقيع الحوكمة الصالح تفويض المحفظة، لا الموافقة المستنيرة.

التوقيع والجسور

تستخدم أنظمة جسور كثيرة التوقيعات لتفويض الرسائل عبر السلاسل أو عمليات السحب أو السك أو الحرق أو الإفراج عن الأصول المقفلة.

قد يعتمد الجسر على توقيعات المدققين أو المرحّلين أو اللجان أو موقّعي العتبة أو نظام تحقق آخر.

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

ينبغي أن تتضمن حمولة توقيع الجسر السلسلة المصدر وسلسلة الوجهة ومعرف الرسالة والتوكن والمبلغ والمستلم وnonce وسياق النطاق.

تنطوي الجسور على مخاطر مرتفعة لأنها تصل أنظمة مختلفة بافتراضات أمان مختلفة.

لا تكون قوة توقيع الجسر الصالح أكبر من قوة مجموعة موقّعي الجسر وقواعد التحقق ونموذج الحفظ وأمان العقد الذكي.

ينبغي للمستخدمين عدم افتراض أن الجسر آمن لمجرد أنه يستخدم التوقيعات.

التوقيعات ضرورية لتصاميم جسور كثيرة، لكنها ليست ضمانًا كاملًا لأمان الجسر.

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

خطر إعادة تشغيل التوقيع

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

قد يعاد استخدام توقيع مخصص لسلسلة واحدة على سلسلة أخرى إذا لم تتضمن البيانات الموقعة معرّف السلسلة.

وقد يعاد استخدام توقيع مخصص لعقد واحد على عقد آخر إذا لم تتضمن البيانات الموقعة عنوان عقد التحقق.

وقد يعاد استخدام توقيع مخصص لطلب واحد مرارًا إذا لم تتضمن البيانات الموقعة nonce أو إذا لم يُعلّم nonce كمستخدم.

يُعد خطر إعادة التشغيل من أهم الأخطار في تصميم التوقيعات.

يقلل المطورون هذا الخطر باستخدام nonces والمواعيد النهائية وفواصل النطاق ومعرفات السلاسل وعناوين العقود وأنواع الإجراءات وتتبع التوقيعات المستخدمة.

ويقلل المستخدمون الخطر بتجنب التوقيعات غير الواضحة واستخدام واجهات موثوقة تعرض تفاصيل التوقيع.

قد يكون التوقيع صالحًا رياضيًا لكنه خطير إذا قُبل في سياق خاطئ.

التوقيعات الجيدة محددة ومقيدة ويصعب إعادة استخدامها خارج غرضها المقصود.

قابلية تعديل التوقيع

تعني قابلية تعديل التوقيع أن أكثر من قيمة توقيع قد تكون صالحة للرسالة والموقّع نفسيهما في ظروف معينة.

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

في الأنظمة القائمة على ECDSA، يستخدم المطورون غالبًا قواعد التوقيع المعيارية لتقليل خطر القابلية للتعديل.

قد تؤثر القابلية للتعديل في تتبع إعادة التشغيل ومعرفات المعاملات ومطابقة الطلبات وافتراضات تفرد التوقيع.

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

لكن على المطورين فهمها عند بناء العقود الذكية أو أنظمة الطلبات أو منطق التحقق.

استخدام المكتبات الناضجة أكثر أمانًا من تنفيذ قواعد التوقيع يدويًا.

تذكّر قابلية تعديل التوقيع بأن التفاصيل التشفيرية الصغيرة قد تخلق مشكلات كبيرة في البروتوكول.

يجب أن يكون التوقيع صالحًا من الناحية الرياضية ومن الناحية الخاصة بالبروتوكول.

التوقيع والتصيد الاحتيالي

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

قد يخدع موقع تصيد المستخدم لتوقيع معاملة أو تصريح أو رسالة أو موافقة أو طلب يفيد مهاجمًا.

قد يكون التوقيع صالحًا تمامًا رغم تعرض المستخدم للخداع.

يحذر تنبيه SEC للمستثمرين بشأن عمليات الاحتيال على الأصول المشفرة من أن المحتالين يستخدمون شعبية الكريبتو لاستدراج الضحايا إلى الاحتيال.

يعتمد التصيد الاحتيالي في الكريبتو غالبًا على الاستعجال والمكافآت المزيفة والدعم المزيف والإيردروبات المزيفة وصفحات الاسترداد المزيفة وتصاميم المواقع المنسوخة.

يجب ألا يفترض المستخدمون أن التوقيع آمن لأن الموقع يبدو احترافيًا.

ينبغي لهم التحقق من النطاق وعنوان العقد ومطالبة المحفظة وعنوان المنفق ومبلغ التوكن والغرض من الرسالة.

إذا عرضت المحفظة بيانات سداسية عشرية خام أو نصًا غير واضح، ينبغي للمستخدمين توخي حذر إضافي.

ينجح التصيد عبر التوقيع لأن البلوكشين تقبل التوقيعات الصالحة، لا النوايا الحسنة.

التوقيع والمحافظ الباردة

المحفظة الباردة هي جهاز ينشئ التوقيعات مع إبقاء المفتاح الخاص معزولًا عن الكمبيوتر أو الهاتف المتصل.

قد يقلل ذلك خطر سرقة البرمجيات الخبيثة للمفتاح الخاص.

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

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

ولهذا تهم شاشات المحافظ الباردة ومعاينات المعاملات وتفاصيل التوقيع الواضحة.

التوقيع الأعمى محفوف بالمخاطر لأن المستخدمين قد يوافقون على بيانات لا يمكن قراءتها بالكامل على الجهاز.

تحسن المحفظة الباردة حماية المفتاح، لكنها لا تضمن فهم المعاملة.

ينبغي للمستخدمين التحقق من عناوين المستلمين وموافقات التوكنات واستدعاءات العقود والمبالغ على الجهاز كلما أمكن.

أكثر التوقيعات أمانًا هو ما ينشئه مفتاح محمي بعد أن يفهم المستخدم الطلب.

التوقيع وتجريد الحساب

يغير تجريد الحساب طريقة عمل التوقيعات في أنظمة المحافظ.

فبدلًا من اعتماد كل حساب على تنسيق توقيع قياسي واحد بمفتاح خاص، يمكن للحساب الذكي تحديد قواعد تفويض مخصصة.

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

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

لكنه قد يجعل التحقق أكثر تعقيدًا لأن التطبيقات يجب أن تفهم قواعد التوقيع القائمة على العقود.

يساعد ERC-1271 والأساليب المشابهة التطبيقات على التحقق من توقيعات محافظ العقود الذكية.

ومع شيوع الحسابات الذكية، قد يتوسع معنى التوقيع من موافقة مفتاح واحد على إجراء واحد إلى موافقة سياسة محفظة على إجراء.

ينبغي للمستخدمين التعامل مع كل عملية معتمدة بجدية، لأن المحافظ القابلة للبرمجة قد تظل تفوض نقل أصول فعلية.

يجعل تجريد الحساب التوقيعات أكثر مرونة، لا خالية من المخاطر تلقائيًا.

التوقيع وأمان العقود الذكية

يجب كتابة العقود الذكية التي تقبل التوقيعات بعناية.

ينبغي للعقد التحقق من الموقّع المتوقع والإجراء الموقّع والمبلغ والمستلم وnonce والموعد النهائي ومعرّف السلسلة وعقد التحقق عند الحاجة.

إذا غاب أي من هذه الحقول، فقد يصبح التوقيع قابلًا لإعادة الاستخدام أو التفسير الخاطئ.

ينبغي للعقود رفض التوقيعات منتهية الصلاحية ووضع علامة صحيحة على nonces المستخدمة.

وينبغي للعقود أيضًا دعم محافظ العقود الذكية عندما يتوقع التطبيق استخدامها.

قد تسمح ثغرة في التحقق من التوقيع للمهاجمين بالمطالبة بالمكافآت أو تنفيذ الطلبات أو تفويض الإنفاق أو التصويت أو سحب الأموال دون تفويض مناسب.

ينبغي اختبار التدفقات القائمة على التوقيع مع المستخدمين العاديين والضارين ومحاولات إعادة التشغيل والمواعيد المنتهية والسلاسل والعقود والموقّعين الخطأ.

ينبغي للمدققين مراجعة منطق التوقيع بوصفه مجالًا عالي المخاطر.

في أمان العقود الذكية، تمثل التوقيعات غالبًا التحكم في الوصول بصيغة تشفيرية.

أخطاء التوقيع الشائعة

من الأخطاء الشائعة افتراض أن توقيع رسالة غير ضار دائمًا.

وخطأ آخر هو الموافقة على بيانات خام دون فهم معناها.

والخطأ الثالث هو الخلط بين ربط المحفظة وتوقيعها.

والخطأ الرابع هو منح إذن إنفاق توكن عبر تصريح موقّع دون ملاحظة المنفق.

والخطأ الخامس هو الثقة في مطالبة توقيع لأن الموقع يستخدم شعارًا مألوفًا.

والخطأ السادس هو إنشاء رسائل موقعة من دون nonces أو مواعيد نهائية.

والخطأ السابع هو عدم تضمين معرّف السلسلة وعنوان العقد في الحمولة الموقعة.

والخطأ الثامن هو عدم دعم توقيعات محافظ العقود الذكية.

والخطأ التاسع هو استخدام كود توقيع مخصص بدلًا من مكتبات مدققة.

والخطأ العاشر هو الاعتقاد بأن التوقيع الصالح يثبت أن الموقّع قصد النتيجة أو فهم كل المخاطر.

فوائد التوقيعات

الفائدة الأولى للتوقيعات هي تفويض المعاملات بأمان دون كشف المفاتيح الخاصة.

والفائدة الثانية هي إثبات ملكية المحفظة.

والفائدة الثالثة هي الحماية من التعديلات غير المصرح بها في البيانات الموقعة.

والفائدة الرابعة هي دعم الحفظ الذاتي.

والفائدة الخامسة هي التوافق مع العقود الذكية وDeFi وNFTs والحوكمة وStaking وتسجيل الدخول بالمحفظة.

والفائدة السادسة هي التفويض دون رسوم غاز لبعض الإجراءات خارج السلسلة أو المؤجلة.

والفائدة السابعة هي دعم تصاميم أمان التوقيع المتعدد والعتبة.

والفائدة الثامنة هي مصادقة لامركزية أفضل من دون قاعدة بيانات تقليدية لكلمات المرور.

والفائدة التاسعة هي التنسيق عبر الأنظمة عندما تصمم التوقيعات بحماية قوية من إعادة التشغيل.

والفائدة العاشرة هي أن التوقيعات تجعل الملكية الرقمية قابلة للإنفاذ بالتشفير.

مخاطر التوقيعات وحدودها

الخطر الأول هو أن المفتاح الخاص المسروق يمكنه إنشاء توقيعات صالحة.

والخطر الثاني هو أن المستخدم المخدوع قد يوقّع معاملة أو رسالة ضارة.

والخطر الثالث هو إعادة التشغيل إذا لم تتضمن البيانات الموقعة سياقًا كافيًا.

والخطر الرابع هو مطالبات المحافظ غير القابلة للقراءة.

والخطر الخامس هو قابلية تعديل التوقيع أو منطق التحقق الضعيف.

والخطر السادس هو برمجيات المحفظة الضعيفة أو أجهزة التوقيع غير الآمنة.

والخطر السابع هو التصيد عبر مواقع وحسابات دعم مزيفة.

والخطر الثامن هو الالتباس عبر السلاسل عندما لا تكون التوقيعات محددة بالنطاق.

والخطر التاسع هو أخطاء العقود الذكية في قبول التوقيعات.

والخطر العاشر هو الثقة الزائفة، لأن التوقيع الصالح يثبت التفويض لا الأمان أو العدالة أو الربحية.

أفضل الممارسات للمستخدمين

اقرأ كل مطالبة في المحفظة قبل التوقيع.

تحقق من نطاق الموقع قبل الموافقة على أي طلب توقيع.

تحقق مما إذا كان التوقيع لتسجيل الدخول أو الموافقة أو التحويل أو التصريح أو الطلب أو التصويت أو إجراء مالي آخر.

توخ الحذر مع الرسائل السداسية العشرية الخام والمطالبات غير الواضحة.

راجع عناوين منفق التوكن ومبالغ الموافقة بعناية.

تجنب توقيع الطلبات العاجلة الواردة من روابط غير معروفة أو إيردروبات مزيفة أو حسابات دعم مزيفة أو رسائل خاصة.

استخدم محافظ باردة أو ترتيبات حفظ أقوى للأرصدة الكبيرة عند الاقتضاء.

افصل محافظ التخزين عالية القيمة عن محافظ التفاعل اليومي عندما يكون ذلك عمليًا.

ألغِ الموافقات غير الضرورية عندما يناسب ذلك نشاط محفظتك.

تذكر أن التوقيع تفويض، وليس نقرة عابرة.

أفضل الممارسات للمطورين

استخدم معايير توقيع راسخة بدلًا من التنسيقات المخصصة كلما أمكن.

استخدم بيانات EIP-712 المكتوبة للموافقات المعقدة المشابهة لـ Ethereum عندما يكون التوقيع المهيكل القابل للقراءة مناسبًا.

ضمّن معرّف السلسلة وعقد التحقق وnonce والموعد النهائي والموقّع والمستلم والمبلغ ونوع الإجراء عندما تكون هذه الحقول ذات صلة.

ارفض التوقيعات المنتهية وnonces المستخدمة مسبقًا.

استخدم مكتبات تشفير موثوقة وتجنب كتابة منطق مخصص لاستعادة التوقيع دون خبرة قوية.

ادعم ERC-1271 عندما قد يتفاعل المستخدمون عبر محافظ العقود الذكية.

اختبر التوقيعات عبر المحافظ والشبكات والمتصفحات والمكتبات والحالات الطرفية.

اجعل مطالبات المستخدمين واضحة بما يكفي ليفهمها غير الخبراء.

دقق مسارات التفويض القائمة على التوقيع بعناية.

تعامل مع التوقيعات كجزء من التحكم في الوصول، لا كميزة لواجهة المستخدم فقط.

الأسئلة الشائعة

ماذا يعني التوقيع في الكريبتو؟

التوقيع في الكريبتو هو دليل رقمي على أن محفظة أو مفتاحًا خاصًا أو حسابًا مخولًا وافق على بيانات محددة، مثل معاملة أو رسالة.

هل توقيع الكريبتو هو نفسه التوقيع بخط اليد؟

لا، توقيع الكريبتو تفويض رياضي يُنشأ بمفتاح خاص، بينما التوقيع بخط اليد علامة مادية مرتبطة بهوية قانونية أو شخصية.

هل يكشف التوقيع مفتاحي الخاص؟

لا، يثبت التوقيع الرقمي السليم التحكم في المفتاح الخاص دون كشفه.

هل يمكن للتوقيع نقل عملاتي المشفرة؟

نعم، يمكن لتوقيع المعاملة نقل الكريبتو، كما يمكن لبعض توقيعات الرسائل تفويض إجراءات لاحقة، مثل إنفاق التوكنات أو تنفيذ الطلبات.

ما الفرق بين توقيع المعاملة وتوقيع الرسالة؟

يفوض توقيع المعاملة معاملة على السلسلة، بينما يوافق توقيع الرسالة على بيانات قد تستخدم لتسجيل الدخول أو التصاريح أو الأصوات أو الطلبات أو إجراءات أخرى خارج السلسلة أو مؤجلة.

ما خوارزمية التوقيع التي تستخدمها Bitcoin؟

استخدمت Bitcoin تاريخيًا ECDSA مع منحنى secp256k1، كما تدعم توقيعات Schnorr في السياقات المرتبطة بـ Taproot.

ما خوارزمية التوقيع التي تستخدمها Solana؟

يستخدم توقيع معاملات Solana توقيعات Ed25519 من الموقّعين المطلوبين.

هل قد يكون التوقيع الصالح خطيرًا؟

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

ما هي إعادة تشغيل التوقيع؟

إعادة تشغيل التوقيع هي إعادة استخدام توقيع صالح في مكان أو وقت أو سلسلة أو عقد أو إجراء لا ينبغي أن يكون صالحًا فيه.

كيف أحافظ على الأمان عند التوقيع؟

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

الخلاصة

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

التوقيعات أساس ملكية البلوكشين لأنها تتيح للشبكات التحقق ممن فوّض إجراءً دون كشف المفاتيح الخاصة.

تُستخدم في المعاملات وتسجيل الدخول بالرسائل وتصاريح التوكنات والطلبات خارج السلسلة وأصوات الحوكمة ورسائل الجسور والمحافظ متعددة التوقيعات ومحافظ العقود الذكية وأنظمة تجريد الحساب.

تستخدم البلوكشينات المختلفة مخططات توقيع مختلفة، تشمل ECDSA وSchnorr وEd25519، حسب الشبكة والسياق.

يثبت التوقيع تفويضًا قائمًا على المفتاح، لكنه لا يثبت أن الموقّع فهم الإجراء أو أن العقد آمن.

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

ينبغي للمطورين تصميم تدفقات التوقيع بحمولات واضحة وفصل للنطاق وحماية من إعادة التشغيل ومواعيد نهائية وnonces ومكتبات ناضجة ومطالبات مستخدم قابلة للقراءة.

بالنسبة للمبتدئين، يُفهم توقيع الكريبتو على أفضل وجه بوصفه موافقة المحفظة التشفيرية.

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

في سياق معجم الكريبتو، يعني التوقيع الدليل الرقمي الذي يفوض إجراءات البلوكشين ويجعل الحفظ الذاتي والمعاملات والتفاعل مع العقود الذكية والهوية اللامركزية ممكنة.

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