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

ما هو توقيع المعاملات؟

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

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

يمكن بث المعاملة الموقعة إلى شبكة بلوكشين كي يتحقق المدققون أو المعدّنون منها ويقرروا ما إذا كانت صالحة.

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

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

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

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

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

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

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

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

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

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

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

وهذا يجعل خطوة التوقيع بالغة الأهمية.

يمكن للتوقيع الصالح تفويض تحويل توكن، أو بيع NFT، أو موافقة DeFi، أو إجراء Staking، أو تصويت حوكمة، أو تحويل عبر جسر بين الشبكات، أو استدعاء عقد ذكي، أو تفويض محفظة.

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

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

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

لذلك، يُعد توقيع المعاملات ميزة أمان ونقطة مخاطر رئيسية للمستخدم في الوقت ذاته.

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

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

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

قد تشمل هذه البيانات المرسل والمستلم والمبلغ والرسوم والـ nonce ومعرف السلسلة وعنوان العقد واستدعاء الدالة وحقولًا أخرى بحسب البلوكشين.

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

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

تتضمن المعاملة الموقعة بيانات المعاملة الأصلية والتوقيع معًا.

بعد ذلك، يمكن إرسال المعاملة إلى شبكة الند للند أو إلى نقطة نهاية RPC.

تتحقق العُقد من صلاحية التوقيع بالنسبة إلى المرسل المُدعى.

كما تتحقق العُقد من امتلاك المرسل أموالًا كافية، وصحة الـ nonce أو التسلسل، وكفاية الرسوم، وامتثال المعاملة لقواعد البروتوكول.

إذا اجتازت المعاملة التحقق، فيمكن تضمينها في كتلة.

ويحوّل التوقيع المعاملة المُعدّة إلى معاملة مفوّضة.

المفاتيح الخاصة والمفاتيح العامة

المفتاح الخاص قيمة سرية تُستخدم لتوقيع المعاملات.

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

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

يجب أن يظل المفتاح الخاص سريًا إلى الأبد.

أما المفتاح العام أو العنوان فيمكن مشاركته كي يتحقق الآخرون من التوقيعات أو يرسلوا الأموال.

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

تظهر الفكرة الأساسية نفسها عبر العديد من شبكات الكريبتو، رغم اختلاف تنسيقات العناوين وخوارزميات التوقيع.

إذا فُقد مفتاح خاص، فقد يفقد المستخدم الوصول إلى الأموال.

وإذا سُرق، فقد يتمكن المهاجم من توقيع المعاملات ونقل الأموال.

لا يكون توقيع المعاملات آمنًا إلا عندما تُنشأ المفاتيح الخاصة وتُخزّن وتُستخدم بأمان.

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

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

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

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

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

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

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

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

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

وهذا يتيح التحقق اللامركزي دون خادم تسجيل دخول مركزي.

التوقيعات الرقمية هي الأساس العملي لملكية الكريبتو.

توقيع المعاملات على Ethereum

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

توضح وثائق معاملات Ethereum الرسمية أن المعاملة عبارة عن تعليمة موقعة تشفيريًا من حساب.

قد تشمل بيانات معاملة Ethereum nonce، والمستلم، والقيمة، وبيانات الإدخال، وحد الغاز، وحقول الرسوم، ومعرف السلسلة، وحقول التوقيع.

يساعد الـ nonce في ترتيب معاملات الحساب نفسه ويمنع قبول المعاملة نفسها مرارًا ضمن تسلسل الحساب ذاته.

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

قد يكون حقل البيانات فارغًا لتحويل ETH بسيط، أو يتضمن بيانات استدعاء عقد ذكي.

يكون تحويل التوكن على Ethereum عادةً معاملة تستدعي عقد التوكن، وليس نقلًا بسيطًا لـ ETH الأصلي.

وهذا يعني أن المستخدم قد يوقّع معاملة تستدعي

أو أو أو أو دالة عقد أخرى.

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

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

توقيع المعاملات على Bitcoin

يعمل توقيع معاملات Bitcoin بشكل مختلف عن السلاسل القائمة على الحسابات لأن Bitcoin تستخدم نموذج UTXO.

UTXO هو مخرج معاملة غير منفق يمكن استخدامه كإدخال في معاملة مستقبلية.

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

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

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

وهذا يعني أن محفظة Bitcoin قد توقّع عدة أجزاء من المعاملة إذا أنفقت عدة UTXO.

تُفحص توقيعات Bitcoin مقابل شروط القفل للمخرجات التي يجري إنفاقها.

إذا كانت التوقيعات والبرامج النصية المطلوبة صالحة، فيمكن للمعاملة إنفاق تلك المخرجات.

يختلف هذا التصميم عن نموذج nonce الحسابي في Ethereum، لكن الفكرة الجوهرية متشابهة.

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

توقيع المعاملات على Solana

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

تنص وثائق معاملات Solana الرسمية على أن المعاملة تتضمن تعليمة واحدة أو أكثر، وتوقيعات الحسابات التي تفوض التغييرات، وblockhash حديثًا.

قد تتطلب معاملات Solana أكثر من مُوقّع واحد إذا كان يلزم أن تفوض عدة حسابات التعليمات.

تعالج Solana التعليمات في المعاملة معًا.

إذا فشلت تعليمة واحدة، تفشل المعاملة بأكملها وتُعكس تغييرات الحالة.

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

ولهذا يرى مستخدمو Solana غالبًا كلمة «توقيع» حيث قد تقول منظومات أخرى هاش المعاملة أو معرف المعاملة.

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

يمكن لتوقيع معاملة Solana تحديد المعاملة على الشبكة.

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

توقيع المعاملات مقابل توقيع الرسائل

يرتبط توقيع المعاملات بتوقيع الرسائل، لكنهما مختلفان.

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

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

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

قد يكون توقيع الرسائل مفيدًا لأنه قد لا يكلّف رسوم الغاز ولا ينقل الأموال مباشرةً.

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

يحدد معيار EIP-712 الرسمي طريقة لتجزئة البيانات المنظمة ذات الأنواع وتوقيعها بدل توقيع سلاسل البايت الخام فقط.

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

بالنسبة إلى Bitcoin، يحدد BIP-322 تنسيقات عامة لتوقيع الرسائل لإثبات التحكم في عناوين Bitcoin.

ليست الرسالة الموقعة آمنة تلقائيًا لمجرد أنها لا تبث معاملة.

ما الذي يوقّعه المستخدمون فعليًا؟

يوقّع المستخدمون بيانات منظمة تعتمد على البلوكشين ونوع الإجراء.

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

بالنسبة إلى تحويل توكن، قد تتضمن البيانات الموقعة استدعاء عقد ذكي لنقل التوكنات.

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

وبالنسبة إلى صفقة DeFi، قد تتضمن البيانات تفاصيل مسار المبادلة وحدود الانزلاق السعري والمواعيد النهائية وموافقات التوكنات.

وبالنسبة إلى إدراج NFT، قد تفوض البيانات طلبًا بأسلوب السوق أو إذن تحويل.

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

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

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

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

الحماية من إعادة التشغيل

تمنع الحماية من إعادة التشغيل إعادة استخدام توقيع صالح في سياق خاطئ.

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

أدخل معيار الحماية من إعادة التشغيل EIP-155 في Ethereum معرف السلسلة في توقيع المعاملات، بحيث لا تعمل معاملة لسلسلة ما على سلسلة متوافقة أخرى تستخدم معرف سلسلة مختلفًا.

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

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

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

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

ينبغي للمطورين تضمين معرفات السلسلة وnonces والمواعيد النهائية والنطاقات وعناوين العقود عند الاقتضاء.

الحماية من إعادة التشغيل ليست تفصيلًا تقنيًا فحسب.

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

Nonces وترتيب المعاملات

الـ nonce رقم يساعد على منع التنفيذ المكرر للمعاملات وعلى ترتيب معاملات الحساب نفسه.

في Ethereum، تستخدم كل معاملة من حساب مملوك خارجيًا nonce.

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

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

والاستبدال ليس سحرًا.

إنه معاملة موقعة أخرى تستخدم الـ nonce نفسه بشروط رسوم أو تفاصيل إجراء مختلفة.

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

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

قد تؤدي أخطاء nonce إلى معاملات عالقة أو عمليات بث فاشلة أو عمليات استبدال غير مقصودة.

يساعد التوقيع مع nonce الصحيح الشبكة على فهم تسلسل المعاملات المقصود.

الغاز والرسوم والمعاملات الموقعة

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

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

في Bitcoin، ترتبط رسوم المعاملة بحجمها ومعدل الرسوم.

في Solana، يوقّع دافع الرسوم المعاملة ويدفع الرسوم الأساسية وأي رسوم أولوية.

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

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

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

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

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

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

التوقيع باستخدام محفظة الأجهزة

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

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

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

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

لكن محافظ الأجهزة لا تجعل كل توقيع آمنًا.

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

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

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

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

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

التوقيع باستخدام المحفظة الساخنة

توقّع المحفظة الساخنة المعاملات من جهاز متصل بالإنترنت.

وتشمل الأمثلة محافظ المتصفح ومحافظ الهاتف الجوال ومحافظ سطح المكتب والمحافظ القائمة على التطبيقات.

تتميز المحافظ الساخنة بالسهولة لأنها تجعل المعاملات المتكررة ميسرة.

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

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

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

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

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

كما ينبغي فصل محافظ النشاط اليومي عن محافظ التخزين طويل الأجل.

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

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

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

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

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

يمكن لـ multisig تقليل مخاطر فشل مفتاح واحد.

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

وقد يحمي ذلك من مفتاح مسروق أو جهاز مفقود أو مشغّل ضار.

لكن multisig يضيف تعقيدًا في التنسيق والتشغيل.

ويجب أن يفهم الموقّعون ما يوافقون عليه.

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

ولا يكون نظام multisig أقوى من عملية توقيعه وانضباط حوكمته.

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

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

ويمكن أن يدعم ذلك موافقات multisig وحدود الإنفاق ومفاتيح الجلسات والاسترداد الاجتماعي ودافعي الرسوم والإجراءات المجمعة.

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

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

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

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

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

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

تجعل محافظ العقود الذكية التوقيع أكثر مرونة، لكنها تجعل معنى التوقيع أكثر تعقيدًا أيضًا.

قد يوقّع المستخدم عملية تنفذها محفظة العقد لاحقًا وفق قواعد محددة.

EIP-7702 وتوقيع التفويض

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

توضح وثائق معاملات Ethereum الرسمية أن معاملات النوع 4 قُدمت مع EIP-7702 ضمن ترقية Pectra في Ethereum.

يوضح دليل Ethereum EIP-7702 الرسمي أن EIP-7702 يتيح للحسابات المملوكة خارجيًا التصرف مؤقتًا كحسابات عقود ذكية عبر تعيين مؤشر إلى رمز منشور باستخدام نوع معاملة جديد.

قد يتيح ذلك ميزات مفيدة مثل التجميع والرعاية والترقيات بأسلوب الحسابات.

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

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

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

ولا ينبغي توقيع هذه الطلبات إلا من تطبيقات موثوقة وبعد فهم نطاقها.

ينبغي للمحافظ أن تشرح بوضوح ما يفعله التفويض وكيفية إلغائه.

ومع تطور ميزات الحساب، يتطلب التوقيع الآمن أكثر من التحقق من عنوان المستلم.

التوقيع الأعمى

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

قد يحدث ذلك عندما لا تتمكن المحفظة من فك ترميز بيانات استدعاء العقد بوضوح.

وقد يحدث أيضًا عندما تعرض محفظة الأجهزة هاشًا فقط أو حقولًا غير واضحة.

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

قد يعرض موقع خبيث زرًا يبدو غير ضار بينما توقع المحفظة موافقة خطرة أو تحويل أصل.

ينبغي للمستخدمين تجنب التوقيع الأعمى كلما أمكن.

وينبغي استخدام محافظ تفكك ترميز المعاملات بوضوح.

كما ينبغي التحقق من الموقع وعنوان العقد والتوكن والمبلغ والشبكة والأذونات.

وينبغي رفض المطالبات التي لا يمكن فهمها.

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

توقيع البيانات ذات الأنواع

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

يُعد EIP-712 أشهر معيار في Ethereum لتوقيع البيانات المنظمة ذات الأنواع.

ينص معيار EIP-712 الرسمي على أنه معيار لتجزئة البيانات المنظمة ذات الأنواع وتوقيعها بدل سلاسل البايت فقط.

وهذا يساعد المحافظ على عرض تفاصيل مثل النطاق والمنفق والمبلغ والموعد النهائي والتوكن وحقول الطلب.

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

لكن قابلية قراءة البيانات لا تعني تلقائيًا أنها آمنة.

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

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

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

يقلل التصميم الجيد للبيانات ذات الأنواع مخاطر التصيد الاحتيالي لكنه لا يلغيها.

توقيعات Permit

توقيع Permit هو توقيع خارج السلسلة يمكن أن يوافق على إنفاق التوكنات من دون أن يرسل مالك التوكن أولًا معاملة موافقة منفصلة على السلسلة.

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

وهي شائعة في موافقات التوكنات ومبادلات DeFi وتكاملات المحافظ.

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

يتضمن Permit عادةً تفاصيل مثل المالك والمنفق والقيمة والـ nonce والموعد النهائي وعقد التوكن.

إذا كان المنفق خبيثًا وكان Permit صالحًا، فقد يستخدمه لنقل التوكنات ضمن النطاق المعتمد.

ينبغي للمستخدمين التعامل مع توقيع Permit كما يتعاملون مع موافقة التوكن.

وينبغي التحقق من عنوان المنفق والتوكن والمبلغ والموعد النهائي والموقع.

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

توضح توقيعات Permit لماذا قد يحمل توقيع الرسائل معنى ماليًا حتى من دون معاملة فورية على السلسلة.

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

تُعد موافقات التوكنات من أهم مخاطر التوقيع في الكريبتو.

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

قد يبدأ إجراء DeFi صغير بمعاملة موافقة كبيرة.

إذا كان العقد خبيثًا، فيمكن استخدام الموافقة لاستنزاف التوكنات المعتمدة.

وإذا تعرض العقد للاختراق لاحقًا، فقد تصبح الموافقات القديمة خطرة.

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

كما ينبغي مراجعة الموافقات القديمة وإلغاؤها عندما لا تعود ضرورية.

وينبغي استخدام محافظ منفصلة لنشاط dApp عالي المخاطر وللتخزين طويل الأجل.

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

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

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

قد يفوض توقيع معاملات NFT عمليات التحويل والإدراج والموافقات والعروض والسك والحرق وطلبات السوق.

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

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

وقد يوقع إدراجًا خارج السلسلة يسمح للمشتري بشراء NFT وفق شروط محددة.

قد يطلب موقع سك مزيف من المستخدمين توقيع معاملة تنقل في الواقع NFTs قيّمة.

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

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

قد تساعد محفظة الأجهزة في حماية المفتاح، لكنها لا تستطيع تقرير ما إذا كانت موافقة NFT آمنة.

تعتمد سلامة توقيع NFT على قراءة المطالبة وفهم الإذن الممنوح.

غالبًا ما تكون أخطر توقيعات NFT هي التي تبدو روتينية.

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

يتضمن توقيع معاملات DeFi غالبًا استدعاءات عقود ذكية معقدة.

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

تكون كثير من معاملات DeFi ذرية، أي إما أن تنجح جميع الخطوات المضمنة أو تفشل المعاملة بأكملها.

قد يكون هذا مفيدًا، لكنه يجعل مطالبة التوقيع أصعب فهمًا.

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

كما ينبغي الحذر من التوكنات ومجمعات السيولة غير المألوفة.

وينبغي تجنب توقيع معاملات من روابط منسوخة أو رسائل مباشرة.

وينبغي التفكير في المحاكاة ومعاينات المعاملات عند توفرها.

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

يحوّل DeFi توقيع المعاملات إلى قرار مالي، وليس مجرد إجراء تقني.

توقيع المعاملات والجسور بين الشبكات

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

وقد يشمل ذلك معاملات وتوقيعات متعددة.

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

لكل خطوة توقيع مخاطرها الخاصة.

قد تكشف الموافقة التوكنات.

وقد يرسل الإيداع الأصول إلى عقد.

وقد تتفاعل المطالبة مع سلسلة وتنسيق عنوان مختلفين.

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

وينبغي إرسال مبلغ اختبار صغير عند الإمكان.

يضيف توقيع الجسر تعقيدًا عبر السلاسل، لذا لا ينبغي للمستخدمين الاستعجال في المطالبات.

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

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

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

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

يمكن أن ينجح التصيد الاحتيالي حتى لو لم يغادر المفتاح الخاص المحفظة.

كل ما يحتاجه المهاجم هو أن يوقّع المستخدم البيانات الخاطئة.

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

ولا ينبغي ربط المحافظ بمواقع لا يثقون بها.

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

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

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

توقيع المعاملات والبرمجيات الخبيثة

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

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

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

وقد ينشئ برنامج محفظة مزيف مطالبات معاملات خبيثة.

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

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

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

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

لكن يجب على المستخدمين التحقق من العنوان والمبلغ على شاشة الجهاز الموثوقة.

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

توقيع المعاملات والإلغاء

لا يمكن عادةً إلغاء معاملة موقعة بعد تأكيدها على السلسلة.

لكن يمكن تقليل بعض الأذونات التي تنشئها التوقيعات لاحقًا.

يمكن غالبًا إلغاء موافقات التوكنات أو خفضها بإرسال معاملة أخرى.

وقد يمكن إزالة مفاتيح الجلسات من خلال إعدادات المحفظة.

وقد تتوفر مسارات إلغاء للتفويضات بحسب نظام الحساب.

وقد يمكن إلغاء إدراجات السوق إذا كان تصميم السوق يدعم الإلغاء ولم يُنفذ الطلب بالفعل.

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

كما ينبغي مراجعة الموافقات والأذونات النشطة بانتظام.

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

يفيد الإلغاء، لكنه لا يستطيع التراجع عن الأصول التي نُقلت بالفعل بتوقيع صالح.

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

يمكن أن تفشل المعاملة الموقعة رغم ذلك.

قد تفشل لأن الحساب لا يملك رصيد رسوم كافيًا.

وقد تفشل لأن nonce غير صحيح.

وقد تفشل لأن شرطًا في العقد لم يُستوفَ.

وقد تفشل لأن الانزلاق السعري مرتفع جدًا أو لأن الموعد النهائي انقضى.

وقد تفشل لأن حد الغاز أو تقدير الموارد كان منخفضًا جدًا.

وقد تفشل لأن المستخدم وقّع على السلسلة الخطأ.

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

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

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

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

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

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

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

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

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

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

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

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

وينبغي فهم أن توقيع المعاملات ينشئ غالبًا سجلات عامة.

تبدأ الخصوصية الجيدة بفصل المحافظ قبل بدء التوقيع.

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

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

تحقق من الشبكة قبل التوقيع.

اقرأ نوع المعاملة قبل الموافقة.

أكد عنوان المستلم والمبلغ.

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

ارفض مطالبات التوقيع الأعمى التي لا تفهمها.

استخدم محفظة أجهزة للأرصدة الأكبر.

استخدم محافظ منفصلة للتخزين طويل الأجل ونشاط dApp عالي المخاطر.

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

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

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

اجعل مطالبات التوقيع واضحة وقابلة للقراءة البشرية.

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

ضمّن معرفات السلاسل وعناوين العقود وnonces والمواعيد النهائية وفواصل النطاقات عند الاقتضاء.

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

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

اعرض المحاكاة ومعاينات المعاملات عند الإمكان.

حذر المستخدمين عندما ينشئ التوقيع سلطة مستمرة.

اختبر تدفقات التوقيع عبر المحافظ والأجهزة.

تعامل بأمان مع التوقيعات الفاشلة والمطالبات المرفوضة.

صمم تدفقات التوقيع مع مراعاة مقاومة التصيد الاحتيالي.

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

الخطأ الأول هو الاعتقاد أن التوقيع مجرد تأكيد لتسجيل الدخول.

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

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

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

الخطأ الثالث هو تجاهل الموافقات.

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

الخطأ الرابع هو التوقيع على الشبكة الخاطئة.

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

الخطأ الخامس هو الثقة بمطالبات المحافظ غير الواضحة.

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

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

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

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

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

لا، ينشئ توقيع المعاملات الصحيح توقيعًا من دون كشف المفتاح الخاص.

هل يمكن لشخص سرقة الأموال باستخدام توقيع فقط؟

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

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

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

لماذا تطلب مني المحفظة التوقيع؟

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

ما هو التوقيع الأعمى؟

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

هل التوقيع الأعمى خطر؟

نعم، لأنه قد يجعل المستخدم يوافق على تحويل أو موافقة أو استدعاء عقد من دون فهمه.

ما هي الحماية من إعادة التشغيل؟

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

ما هو nonce في توقيع المعاملات؟

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

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

نعم، قد تفشل بسبب عدم كفاية الرسوم أو nonce خاطئ أو عكس العقد للتنفيذ أو انتهاء المواعيد النهائية أو الانزلاق السعري أو قواعد شبكة أخرى.

هل يمكنني إلغاء معاملة موقعة؟

قد تتمكن من استبدال معاملة معلقة على بعض الشبكات، لكن المعاملة المؤكدة لا يمكن عكسها عادةً.

هل يمكنني إلغاء توقيع؟

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

هل التوقيع باستخدام محفظة أجهزة أكثر أمانًا؟

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

ما الذي ينبغي التحقق منه قبل التوقيع؟

ينبغي التحقق من الموقع والشبكة والمستلم والمبلغ والتوكن وعنوان العقد ومبلغ الموافقة والرسوم والموعد النهائي ونطاق الإذن.

ما القاعدة الأكثر أمانًا لتوقيع المعاملات؟

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

الخلاصة

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

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

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

تنظم شبكات البلوكشين المختلفة المعاملات الموقعة بطرق مختلفة، لكن الفكرة الأساسية واحدة عبر Bitcoin وEthereum وSolana وTRON والعديد من الشبكات الأخرى.

توقيع المعاملات قوي لأنه يلغي الحاجة إلى سلطة مركزية قائمة على كلمات المرور.

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

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

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

وينبغي للمطورين تصميم تدفقات توقيع قابلة للقراءة ومحدودة ومحمية من إعادة التشغيل ومقاومة للتصيد الاحتيالي.

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

ولا تلغي أي من هذه الأدوات الحاجة إلى المراجعة الدقيقة.

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