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

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

المشكلة التي تحلها MPC فعليًا

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

تقسيم السر لدى شامير (SSS) محاولة مبكرة لتوزيع هذا الخطر. يُقسَّم السر إلى N حصة باستخدام الاستيفاء متعدد الحدود، ويمكن لأي M حصة إعادة تكوينه (نظام عتبة M-of-N). في إعداد 2-of-3، تحتاج إلى أي حصتين من أصل ثلاث لإعادة تكوين السر الأصلي. لكن المشكلة أن توقيع معاملة يتطلب من SSS إعادة تكوين المفتاح الخاص كاملًا أولًا على جهاز واحد. ولحظة إعادة التكوين نفسها نقطة فشل وحيدة؛ فالمهاجم الذي يسيطر على ذلك الجهاز في تلك اللحظة يستطيع سرقة المفتاح. يوزع SSS تخزين المفتاح، لا إجراء العمليات الحسابية عليه.

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

لا يتمثل الوعد الأساسي لـ MPC في توزيع أماكن تخزين المفتاح، بل في توزيع عملية الحساب نفسها، بحيث لا يكتمل المفتاح أبدًا.

SSS وTSS: الفرق في إعادة التكوين

من المهم فهم الفرق بين تقسيم السر لدى شامير ومخططات التوقيع بعتبة (TSS)، لأن لغة التسويق المستخدمة لوصفهما كثيرًا ما تخلط بينهما.

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

TSS عند التوقيع: يحتفظ كل طرف بحصة من المفتاح ويستخدمها لإنتاج توقيع جزئي. ثم تُجمع هذه التوقيعات الجزئية، باستخدام استيفاء لاغرانج، لتكوين توقيع نهائي صالح على السلسلة. وتوضح وثائق Web3Auth أن الأطراف «تنشئ توقيعات جزئية بالتزامن، ثم تجمعها عبر استيفاء لاغرانج للتحقق من صحة التوقيع النهائي من دون إعادة تكوين المفتاح». ولا يرى أي جهاز المفتاح كاملًا.

إنشاء المفاتيح الموزع (DKG) يوسع هذا المفهوم أكثر. ففي إعداد حقيقي يجمع بين TSS وMPC، لا يُجمع زوج المفاتيح حتى عند إنشائه؛ بل تنفذ الأطراف بروتوكولًا تفاعليًا ينتهي بامتلاك كل طرف حصة من زوج مفاتيح يُعرف عنوانه العام، فيما لا يوجد مفتاحه الخاص كاملًا في أي مكان.

للتوضيح بمثال: يشبه SSS إعطاء ثلاثة زملاء ثلثًا من تركيبة خزنة لكل منهم؛ إذ لا يزال عليهم الاجتماع في غرفة واحدة وإدخال التركيبة نفسها لفتحها. أما TSS فيشبه إعطاء كل شخص جزءًا منفصلًا من قفل لا يُفتح إلا بتعاونهم؛ فيمكنهم فتح الخزنة معًا من دون أن يعرف أي منهم التركيبة كاملة.

يتيح تقسيم السر القابل للتحقق (VSS)، وهو تطوير لـ SSS الأساسي، للمشاركين التحقق من صحة حصصهم من دون إعادة تكوين السر. وهذا يقلل خطر قيام جهة توزيع خبيثة بالتلاعب، لكنه لا يزيل قابلية التعرض للخطر الناجمة عن إعادة التكوين عند التوقيع.

ترتيبات الحصص: 2-of-2 و2-of-3 وأهمية الحسابات

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

2-of-2: يجب أن يوقّع الطرفان، ولا يستطيع أي منهما التصرف بمفرده. تستخدم ZenGo هذا النموذج: حصة على جهاز المستخدم المحمول، وأخرى على خادم ZenGo. ويتطلب التوقيع تواصل الطرفين. ميزته البساطة، أما عيبه فهو أن تعطل أي حصة نهائيًا يؤدي إلى قفل المحفظة. ويعتمد استرداد ZenGo على ثلاثة عوامل: نسخة احتياطية مشفرة من حصة الجهاز يحتفظ بها خادم ZenGo، ورمز فك تشفير محفوظ في خدمة التخزين السحابي الشخصية للمستخدم (iCloud أو Google Drive)، ومسح الوجه بالمقاييس الحيوية.

2-of-3: توجد ثلاث حصص، ويمكن لأي حصتين التوقيع. يضيف هذا الترتيب قدرًا من التكرار. وتطبق Binance Web3 Wallet هذا النموذج بتوزيع الحصص على: (1) جهاز المستخدم، و(2) خادم Binance، و(3) نسخة احتياطية سحابية مشفرة يحميها سر استرداد في iCloud أو Google Drive. إذا فقد المستخدم هاتفه، يمكن للحصتين 2 و3، أي الخادم والنسخة الاحتياطية السحابية، التوقيع معًا على معاملة نقل من دون الحصة 1.

توزع محفظة MPC من Coinbase، وهي من أوائل المحافظ على نطاق المستهلكين وقد أُنشئت منها أكثر من 5 ملايين محفظة حتى يونيو 2023، الحصص بين جهاز المستخدم وبنية Coinbase التحتية وخدمة نسخ احتياطي. ويستخدم نموذج Web3Auth ذي 2-of-3 حصة تسجيل دخول عبر OAuth (تديرها شبكة Web3Auth)، وحصة على الجهاز، وحصة احتياطية أو حصة للمصادقة الثنائية (2FA)، ويدعم بروتوكولات توقيع تشمل GG19 وGG20 وEdDSA وDKLS19.

كانت OKX Wallet من أوائل محافظ منصات التداول الكبرى التي دمجت MPC عبر 37 بلوكتشين في الوقت نفسه، مستخدمةً أيضًا بنية حصص من ثلاثة أجزاء.

أما المؤسسات، فتستفيد من عتبات أعلى، مثل 3-of-5، لإضافة موقّعين لأغراض الامتثال أو الحوكمة. وتطبق Fireblocks، التي عالجت معاملات أصول رقمية تتجاوز قيمتها 10 تريليونات دولار عبر أكثر من 150 بلوكتشين، نموذج 2-of-3 يمكن فيه تخزين الحصة 3 على جهاز محمول معزول عن الشبكة، ما يتيح مستوى للتوقيع البارد من دون جهاز مادي منفصل.

تحديث المفتاح: ميزة لا يضاهيها SSS

من أهم المزايا التشغيلية لـ TSS-MPC مقارنةً بأي نظام SSS تقسيم السر الاستباقي، ويُسمى أيضًا تحديث المفتاح أو تدويره.

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

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

يحقق بروتوكول MPC-CMP من Fireblocks التوقيع في جولة اتصال واحدة، مقارنةً بتسع جولات في معيار GG18 الأقدم، أي أسرع بنحو 8 مرات، ما يجعل التحديث المتكرر للمفتاح عمليًا تشغيليًا على نطاق واسع.

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

دقة الحفظ الذاتي: هل MPC غير وصائية حقًا؟

هنا غالبًا ما تتباعد لغة التسويق عن الواقع التقني. وتعتمد الإجابة على من يحتفظ بالحصص وما يحدث إذا اختفى مزوّد الخدمة.

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

في نموذج 2-of-3، تعتمد الصورة على الأطراف التي تحتفظ بكل حصة. إذا احتفظ المستخدم بحصتين بشكل مستقل (حصة الجهاز ونسخة احتياطية شخصية في السحابة)، تصبح حصة المزوّد اختيارية لاستعادة الوصول. لكن في معظم محافظ MPC الموجّهة للمستهلكين، تشارك حصة المزوّد في كل جولة توقيع، ما يجعل هذه المحافظ وصائية عمليًا في حالات تعطل الخادم أو إنهاء الحساب.

السؤال الأساسي الذي ينبغي لكل مستخدم طرحه هو: إذا أغلقت هذه الشركة أبوابها غدًا، فهل سأظل قادرًا على الوصول إلى أموالي؟ بالنسبة إلى معظم منتجات MPC الموجّهة للمستهلكين، الإجابة الصريحة هي: فقط إذا توفرت آلية لاستعادة كلتا الحصتين بشكل مستقل عن المزوّد. صُمم نموذج النسخ الاحتياطي للحصص المشفّرة لدى ZenGo ليصمد أمام إغلاق الشركة؛ أما بعض المنتجات الأخرى فلا توضح هذا الأمر بالقدر نفسه.

تظل المقارنة مع محفظة أجهزة ذات صلة عند الاحتفاظ بأصول عالية القيمة. يتيح جهاز محفظة الأجهزة إنشاء المفاتيح والتوقيع دون اتصال، ومن دون سر مشترك؛ فنموذج الأمان أبسط ولا يتطلب الثقة بتوافر أي مزوّد. وتقدّم محافظ MPC سهولة أكبر في الاستعادة وتجربة UX أفضل عبر أجهزة متعددة مقابل هذه البساطة.

الارتباط بمزوّد واحد سمة بنيوية في معظم منتجات MPC الحالية، وليس أمرًا عارضًا. فبروتوكولات التوقيع الخاصة (MPC-CMP وGG20 وDKLS19) تعني أن تنسيقات حصص المفاتيح لا يمكن نقلها بين المزوّدين. لا يمكن استيراد حصة من Fireblocks إلى ZenGo، ولا العكس. أما عبارة الاسترداد فتضمن إمكانية النقل إلى أي محفظة متوافقة. مع MPC، يزول هذا الضمان. ولا يمكن للمستخدمين الانتقال بحرية بين منتجات MPC كما يمكنهم الانتقال بين محافظ HD باستخدام عبارة الاسترداد. وبحلول عام 2026، جرى تحديد هذا الارتباط بمزوّد واحد عبر منطق التوقيع الخاص بوصفه خطرًا جوهريًا في محافظ MPC المقدّمة كبرمجيات خدمية.

مخاطر ينبغي فهمها قبل الالتزام

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

اختراق حصتين في الوقت نفسه: لا يفيد نموذج 2-of-2 أو 2-of-3 إلا إذا خُزّنت الحصص في أنظمة مستقلة فعلًا. فإذا اخترق مهاجم خادم المزوّد وجهاز المستخدم في الوقت نفسه، فسيتمكن من الوصول إلى الأموال.
إغلاق المزوّد أو مصادرة الأصول بأمر تنظيمي: لا تعالج MPC مخاطر استمرارية العمل. إذا توقف خادم المزوّد عن العمل نهائيًا ولم يكن لدى المستخدم مسار مستقل للاستعادة، فقد يتعذر الوصول إلى الأموال.
وتيرة تحديث الحصص: تصبح الحصة المسروقة قبل التحديث عديمة الفائدة بعده؛ لكن إذا لم يحدث التحديث إلا عند الاستعادة أو كان متباعدًا، فستظل فترة التعرض واسعة.
غموض محافظ منصات التداول: تُطمس محافظ MPC التي تقدمها منصات التداول (Binance وOKX وCoinbase) الحدود بين الحفظ الذاتي والحفظ لدى جهة وصائية. وعند الإلزام بموجب الأنظمة، يمكن لمنصة التداول التي تحتفظ بحصة أن ترفض المشاركة في التوقيع. وقد لا يفصل المستخدمين الذين يظنون أنهم يحتفظون بأصولهم بأنفسهم عن تعطل محافظهم سوى أمر قضائي واحد.

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

الخطوات التالية

حدّد الجهة التي تحتفظ بكل حصة في أي محفظة MPC تستخدمها. حصة الجهاز وحصة المزوّد وحصة النسخ الاحتياطي السحابي مختلفة؛ تعرّف إلى كل منها.
اختبر الاستعادة قبل أن تحتاج إليها. توفر معظم محافظ MPC وضعًا لمحاكاة الاستعادة. استخدمه.
اسأل المزوّد صراحةً عما يحدث إذا أغلق أبوابه. تحقّق مما إذا كانت المحفظة قد أعلنت عن آلية «تصدير المفتاح» أو «الاستعادة المستضافة ذاتيًا».
راجع إعدادات تحديث المفتاح. عندما تكون فترات التحديث قابلة للضبط، يقلل تقصيرها مدة التعرض لأي حصة مسروقة.
وازن بين أصولك ونموذج الحفظ. بالنسبة إلى الأصول الكبيرة، تظل محفظة الأجهزة التي لا تعتمد على سر مشترك الخيار الأساسي الأبسط والأسهل نقلًا؛ فسهولة الاستعادة في MPC تأتي على حساب قابلية النقل والاعتماد على المزوّد.