شرح مفتاح العرض ومفتاح الإنفاق في Monero

إذا سبق لك أن حاولت إرسال إثبات إيداع Monero إلى محاسبك دون أن تسلّمه مدخراتك بأكملها، فأنت قد التقيت بالمشكلة التي يحلّها هذان المفتاحان. على خلاف Bitcoin، حيث يتحكم مفتاح خاص واحد بكل شيء من الأرصدة وحتى الإنفاق، يقوم Monero عن قصد بتقسيم السلطة بين مفتاح العرض (view key) ومفتاح الإنفاق (spend key). هذا التقسيم هو ما يجعل عملة الخصوصية قابلة للتدقيق عند الطلب، ويدعم صفحات التبرعات ذات الأرصدة العامة، ويشغّل محافظ الهواتف خفيفة الوزن التي لا تلامس أموالك أبداً. ومع ذلك يخلط معظم المبتدئين بين الاثنين، أو يلصقون أحدهما في الحقل الخطأ، أو يفترضون أن مشاركة أحدهما تُسرّب الآخر. في عام 2026، ومع وصول FCMP++ إلى خارطة طريق شبكة الاختبار، وتعامل منصات مثل MoneroSwapper مع آلاف عمليات التبادل دون KYC يومياً، لم يعد فهم الفصل بين المفتاحين تمريناً أكاديمياً. إنه الفرق بين مسار تدقيق نظيف ومحفظة مستنزفة. يأخذك هذا الدليل عبر ما يفعله كل مفتاح بالضبط، وما لا يستطيع فعله، وكيف تحوّل البدائيات التشفيرية في Monero هذا الزوج إلى شيء لا يستطيع نموذج المفتاح الواحد في Bitcoin محاكاته.

لماذا يستخدم Monero مفتاحين خاصين بدلاً من مفتاح واحد

يعود نموذج الحساب في Monero إلى بروتوكول CryptoNote الصادر عام 2013، الذي قدّم توقيعات الحلقة (ring signatures) وعناوين التخفي ذات الاستخدام الواحد إلى عالم العملات المشفّرة. لكي تعمل هذه البدائيات، تحتاج المحفظة إلى إنجاز مهمتين مختلفتين تماماً: مسح سلسلة الكتل بكاملها للتعرف على المخرجات الموجهة إليها، والإذن بإنفاق هذه المخرجات. أدرك مؤلفو CryptoNote أنه يمكن تقسيم دور المسح ودور الإنفاق بين قيمتين عدديتين مستقلتين، كل منهما مشتقّة من بذرة عشوائية بطول 32 بايت لكنها غير مرتبطة تشفيرياً في تأثيراتها العامة.

النتيجة هي هوية محفظة مكوّنة من أربعة أرقام — مفتاح إنفاق خاص، ومفتاح عرض خاص، ونظيراهما العامان — تُسلسل وتُرمّز بنظام base58 لتشكّل عنوان Monero المألوف بطول 95 حرفاً. يحقق هذا الفصل ثلاث فوائد ملموسة:

• الشفافية الانتقائية: يمكنك تسليم مفتاح العرض إلى هيئة ضريبية، أو فريق الامتثال في منصة تبادل، أو مدقق حسابات جمعية خيرية، ليتحققوا من الأموال الواردة، دون منحهم أي قدرة على تحريك العملات.
• عملاء خفيفو الوزن: محافظ الجوال وعقد سطح المكتب للمراقبة فقط تحتاج فقط إلى مفتاح العرض لعرض الرصيد، ما يجعل تخزين مفتاح الإنفاق البارد على جهاز معزول عن الإنترنت أمراً عملياً للاستخدام اليومي.
• الدفاع المتعدد الطبقات: مفتاح عرض مُخترَق يُسرّب تاريخ المعاملات لكن لا يُسرّب الأموال؛ يصبح التعافي من جهاز مسروق حادثة خصوصية وليس خسارة مالية.

لا شيء من هذا ممكن في نموذج UTXO الخاص بـ Bitcoin دون أطراف ثالثة موثوقة أو إضافات معرفة صفرية. أمّا Monero فيخبز هذه الميزة في صلب البروتوكول، ولهذا السبب فإن كل محفظة Monero — من واجهة الأوامر الرسمية إلى محرّك التبادل المستضاف في MoneroSwapper — تُظهر المفتاحين ككائنين من الدرجة الأولى يمكن تصديرهما واستيرادهما وتدقيقهما بشكل مستقل.

مفتاح العرض الخاص بالتعمق

مفتاح العرض الخاص هو قيمة عددية بطول 32 بايت، تُعرض بصيغة 64 حرفاً سداسياً عشرياً في أدوات مثل monero-wallet-cli أو Feather Wallet. وظيفته التشفيرية الوحيدة هي حساب السر المشترك بين المرسِل والمستلم في كل معاملة قد تخصّ المحفظة. عندما يرسل لك أحدهم XMR، يولّد المرسل عنوان تخفّي ذا استخدام واحد باستخدام مفتاح إنفاقك العام، ومفتاح عرضك العام، ومفتاح معاملة عشوائي جديد. يبدو المخرج الناتج كضجيج لكل مراقب على الشبكة — إلا لك، لأن مفتاح العرض الخاص بك يتيح لك إعادة بناء السر المشترك نفسه والتعرف على المخرج باعتباره ملكك.

ما يمكن لمفتاح العرض فعله

بمجرد امتلاك عنوانك العام ومفتاح العرض الخاص، يستطيع البرنامج مسح السلسلة وفك تشفير ثلاث معلومات لكل مخرج: عنوان التخفي الخاص بالمستلم (ما يثبت أن المخرج يخصّك)، والمبلغ (المفكوك من التزام RingCT)، ومعرّف الدفع إن كان مرفقاً. هذا كافٍ لبناء سجل معاملات وارد كامل. تستخدمه الشركات لمراقبة المبيعات، وتنشر صفحات التبرعات مفاتيح العرض الخاصة بها ليتمكن أي شخص من التحقق من الإجماليات في الوقت الفعلي، وتستخدمه برامج الضرائب لإنشاء تقارير أساس التكلفة دون طلب صلاحية الإنفاق أبداً.

ما لا يستطيع مفتاح العرض فعله

لا يستطيع مفتاح العرض توقيع معاملة. ولا يستطيع توليد صورة مفتاح (key image)، ما يعني أنه لا يستطيع إثبات أن مخرجاً قد أُنفِق. في محفظة العرض فقط، تكون المعاملات الصادرة غير مرئية إلى أن يستورد المستخدم ملف صور مفاتيح موقّعاً من محفظة الإنفاق غير المتصلة، عندئذٍ يُسوّى الرصيد. هذا أنظف إثبات على الفصل بين المفتاحين في العمل — يرى مفتاح العرض المال يدخل، لكنه يفقد رؤيته في اللحظة التي يغادر فيها، إلا إذا تعاون جانب الإنفاق بمشاركة صور المفاتيح.

الأخطاء الشائعة المتعلقة بمفتاح العرض

الخطأ الأكثر تكراراً هو لصق مفتاح العرض في حقل "استعادة المحفظة" الذي يتوقع بذرة استعادية (mnemonic seed). ستقبله المحفظة، وتشتق مفتاح إنفاق مختلفاً تماماً من إنتروبيا خاطئة، وتقدم لك محفظة نظيفة لكنها عديمة الفائدة، لا ترى أبداً أموال المستخدم الحقيقية. الفخّ الثاني هو نشر مفتاح العرض على صفحة عامة دون إدراك أن ذلك يربط بشكل دائم كل معاملة واردة سابقة ومستقبلية بهوية واقعية. لا تتدوّر مفاتيح العرض؛ إذا تسرّبت مرة، تسرّبت إلى الأبد. تعامل معها كرمز API للقراءة فقط لكشف حساب بنكي: مفيد للمدققين، كارثي للمتربصين.

مفتاح الإنفاق الخاص بالتعمق

مفتاح الإنفاق الخاص هو القيمة العددية الأخرى بطول 32 بايت، وهو الذي يتحكم فعلياً بالعملات. من هذا الرقم الواحد تشتق المحفظة صورة المفتاح لكل مخرج تملكه، وتوقّع كل توقيع حلقي بنظام CLSAG، وتنتج براهين النطاق Bulletproofs+ التي تثبت أن المبالغ غير سالبة دون الكشف عنها. اخسر مفتاح الإنفاق، تخسر المال. لا توجد استعادة، ولا مكتب دعم، ولا تراجع على السلسلة.

كيف يولّد مفتاح الإنفاق صور المفاتيح

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

مفتاح الإنفاق وعبارة الاستعادة

لا يرى معظم المستخدمين مفتاح الإنفاق الخام بصيغة 64 حرفاً سداسياً عشرياً. بل يرون عبارة استعادة من 25 كلمة (أو Polyseed من 16 كلمة في المحافظ الأحدث) ترمّز مفتاح الإنفاق إضافة إلى مجموع تحقق وتاريخ ميلاد. ثم يُشتقّ مفتاح العرض حتمياً من مفتاح الإنفاق بتجزئته بـ Keccak-256 واختزال النتيجة بمقياس مجموعة Ed25519. هذا الاشتقاق هو السبب في أن النسخ الاحتياطي لمفتاح الإنفاق (أو بذرته) كافٍ لاستعادة المحفظة بأكملها — يسقط مفتاح العرض مجاناً.

لماذا لا تشارك مفتاح الإنفاق أبداً

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

مفتاح العرض في مواجهة مفتاح الإنفاق: مقارنة جنباً إلى جنب

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

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

كيف تنشئ محفظة للعرض فقط، خطوة بخطوة

السبب الأكثر شيوعاً للتفكير في هذه المفاتيح هو بناء محفظة للمراقبة فقط — مثلاً، على هاتف يراقب رصيداً مخزّناً بشكل بارد على حاسوب محمول معزول عن الإنترنت. إليك سير العمل باستخدام monero-wallet-cli الرسمي، رغم أن Feather Wallet وCake Wallet وMyMonero جميعها تقدّم مكافئات بواجهة رسومية.

1. على الجهاز غير المتصل، افتح محفظتك الكاملة ونفّذ الأمر viewkey عند المُحث. انسخ سلسلة الأحرف السداسية الـ 64. نفّذ الأمر address وانسخ العنوان الأساسي البالغ 95 حرفاً. لا تصدّر مفتاح الإنفاق أو البذرة أو أي شيء آخر.
2. انقل السلسلتين إلى الجهاز المتصل عبر رمز QR أو USB من جهاز معزول. لا تكتب مفتاح الإنفاق أو البذرة على الجهاز المتصل أبداً.
3. على الجهاز المتصل، نفّذ monero-wallet-cli --generate-from-view-key <name>. عندما يُطلب منك ذلك، الصق العنوان ومفتاح العرض الخاص. عيّن كلمة مرور قوية للمحفظة.
4. دع المحفظة تتزامن من ارتفاع السلسلة الذي تلقيت فيه أموالك للمرة الأولى. سترى المعاملات الواردة تظهر بمبالغ صحيحة. ستظهر المعاملات الصادرة بصيغة "(unknown sent)" حتى تستورد صور المفاتيح.
5. لتسوية الأرصدة الصادرة، نفّذ بشكل دوري export_key_images على المحفظة غير المتصلة وimport_key_images على المتصلة. هذا لا يشارك أي قدرة على الإنفاق — فقط حقيقة أن بعض المخرجات قد أُنفقت بالفعل.

مفتاح العرض يجيب عن السؤال "ما الذي دخل؟" مفتاح الإنفاق يجيب عن السؤال "ما الذي يستطيع الخروج؟" إذا طلبت منك خدمة الإجابة عن السؤال الثاني، فابتعد عنها — لا يوجد سير عمل نزيه يتطلب ذلك.

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

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

سيناريو مختلف: صحفي مستقل يعمل في منطقة الخليج العربي حيث تتطلب اللوائح الجديدة لهيئة تنظيم الأصول الافتراضية (VARA) في دبي إثبات مصادر الدخل المشفّر، يريد أن يثبت لمستشاره الضريبي أن دخله السنوي من XMR يقع تحت عتبة الإبلاغ. ينشئ محفظة للعرض فقط على حاسوب التدقيق الخاص بالمستشار باستخدام عنوانه ومفتاح العرض، ويتركها تتزامن إلى الكتلة الحالية، ويصدّر ملف CSV بالمبالغ الواردة المفكوكة التشفير. يرى المستشار الإجماليات؛ يحتفظ هو بسلطة الإنفاق. إذا انتهت العلاقة، يدوّر الأموال إلى محفظة جديدة — لكن فقط لأنه يريد فصلاً نظيفاً، لا لأن المستشار كان قادراً يوماً على تحريك العملات.

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

عبر السيناريوهات الثلاثة، تبقى الخاصية نفسها صحيحة: مفتاح العرض يجيب عن الأسئلة التاريخية والحالية حول المال المستلَم؛ مفتاح الإنفاق وحده يجيب عن السؤال عن وجهة المال التالية. يعتمد سير عمل التبادل في MoneroSwapper على نفس الخاصية — يستقبل العملاء XMR في عناوين يتحكمون فيها من البداية إلى النهاية، ولا تطلب المنصة في أي لحظة مفتاحاً يتيح لها الإنفاق نيابة عن العميل.

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

هل يستطيع شخص ما سرقة عملات Monero الخاصة بي إذا حصل فقط على مفتاح العرض؟

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

لماذا لا تستطيع محفظتي للعرض فقط رؤية المعاملات الصادرة؟

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

هل مفتاح العرض مشتق من مفتاح الإنفاق، أم أنهما مستقلان؟

في محافظ Monero القياسية، يُشتقّ مفتاح العرض حتمياً من مفتاح الإنفاق بتجزئته بـ Keccak-256 واختزال النتيجة بمقياس مجموعة Ed25519. لهذا السبب فإن عبارة الاستعادة المؤلفة من 25 كلمة ترمّز مفتاح الإنفاق فقط — يسقط مفتاح العرض تلقائياً. بعض الإعدادات المتقدمة تستخدم مفاتيح عرض مستقلة، لكن كل محفظة استهلاكية تستخدم الصيغة المشتقة.

هل يجب علي عمل نسخة احتياطية لكلا المفتاحين بشكل منفصل؟

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

هل يمكنني تدوير مفتاح العرض إذا تسرّب؟

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

هل تتعامل محافظ العتاد مثل Ledger أو Trezor مع مفتاح الإنفاق بشكل مختلف؟

نعم. على Ledger أو Trezor يعمل عليهما تطبيق Monero، لا يغادر مفتاح الإنفاق العنصر الآمن أبداً. يحمل الحاسوب المضيف مفتاح العرض (حتى يتمكن من مسح السلسلة) ويرسل المعاملات غير الموقّعة إلى الجهاز، الذي يوقّعها داخلياً. هذا أنظف تجسيد فيزيائي للفصل بين المفتاحين: مفتاح العرض يعيش حيث تعيش الراحة، ومفتاح الإنفاق يعيش حيث يعيش الأمن.

الخلاصة

مفتاح العرض ومفتاح الإنفاق ليسا نصفين من سرّ واحد — هما سرّان مختلفان لهما وظيفتان مختلفتان، ويكتسب البروتوكول خصائصه الأكثر فائدة من رفضه دمجهما. بمجرد أن يستقرّ هذا الفصل في الذهن، تتوقف محافظ العرض فقط، وسير عمل التدقيق، وشفافية التبرعات، وبنى محافظ العتاد عن الإحساس بأنها حيل ذكية وتبدأ بالشعور بأنها النتيجة البديهية لتصميم مدروس. إذا كنت تعدّ محفظة جديدة اليوم، فاكتب البذرة دون اتصال، واشتقّ مفتاح عرض لأي جهاز لا يحتاج إلى الإنفاق، ولا تلصق أيّاً من القيمتين في حقل لا تستطيع التعرف عليه بثقة كاملة. عندما تكون مستعداً للحصول على XMR لتلك المحفظة، يقدّم MoneroSwapper عمليات تبادل دون KYC من الأصول الكبرى مباشرة إلى عنوان تتحكم فيه، دون طلب أي مفتاح في أي لحظة من السير — وهو، بعد قراءة هذا الدليل، السلوك الذي يجب أن تتوقعه بالضبط من أي خدمة تستحق الاستخدام.