في محفظة متعددة التوقيع 2 من 3، يحتاج الإنفاق إلى توقيعين مقبولين من ثلاثة مفاتيح مستقلة وفق سياسة المحفظة. فقدان مفتاح واحد قد يترك طريقًا للإنفاق بالمفتاحين الآخرين، لكن ذلك يعتمد أيضًا على امتلاك معلومات الإعداد والقدرة على تشغيل أدوات متوافقة. ثلاث نسخ من العبارة نفسها ليست هذا النوع من التوزيع.
جدول المحتويات
كيف تعمل قاعدة 2 من 3؟
لنفترض وجود مفاتيح مستقلة نرمز إليها بالحروف أ وب وج. تسمح السياسة المفترضة بالإنفاق عند توفير توقيعي «أ» و«ب»، أو «أ» و«ج»، أو «ب» و«ج». عدد الأزواج الممكنة هنا ثلاثة، وكل زوج يحقق الحد المطلوب. هذا مثال تعليمي لسياسة بسيطة، لا وصف لكل عقد أو منتج يحمل اسم متعدد التوقيع.
المهم أن الاستقلال يتعلق بالمفاتيح والسيطرة عليها. إذا وضعت العبارة نفسها على ثلاثة أجهزة، فقد يحصل أي جهاز على سلطة المفاتيح نفسها، بدل توزيع ثلاثة أطراف مستقلة. كذلك فإن شخصًا يسيطر على مفتاحين في مثالنا يستطيع توفير الحد المطلوب من دون الطرف الثالث.
يفصل هذا التصميم بين تحمل فقدان جزء من وسائل الوصول وبين منع جهة واحدة من الإنفاق، لكن تحقيق الهدفين يتطلب توزيعًا مناسبًا. لا تحكم على الترتيب من الرقم المكتوب في اسمه قبل معرفة من يحتفظ بكل مفتاح وأين توجد نسخه الاحتياطية.
ماذا يحدث عند فقدان مفتاح واحد؟
إذا ضاع المفتاح «أ» وبقي المفتاحان «ب» و«ج» متاحين وقابلين للاستخدام، فما زال في المثال طريق يحقق السياسة. لكن «متاح» تعني أكثر من معرفة مكان جهازين: يجب إمكان تشغيلهما والوصول إلى أسرارهما أو استعادتهما، وإعداد المعاملة التي يفهمان سياقها وتوقيعها بالطريقة المدعومة.
ويجب أيضًا التمييز بين ضياع نسخة محلية وضياع جميع نسخ المفتاح. تلف جهاز لا يعني بالضرورة فقدان المفتاح إذا كانت له نسخة استعادة سليمة. وفي المقابل، وجود جهاز في صندوق لا يجعله متاحًا إذا كانت متطلبات فتحه أو استعادته مفقودة ولا يوجد مسار بديل.
بعد فقدان مفتاح، لا تفترض أن البقاء على الترتيب نفسه إلى أجل غير محدد مناسب. راجع أثر الفقد وهل المفتاح ضاع فقط أم ربما وصل إلى طرف آخر، ثم افهم مسار تغيير الإعداد أو نقل الأصول وفق المنتج. هذه عملية لها متطلبات وتكاليف، وليست مجرد إعادة تسمية شريك في الواجهة.
جدول حالات الفقد والسيطرة
| الحالة | هل يبقى مسار توقيع؟ | ما الذي تراجعه؟ |
|---|---|---|
| فقدان «أ» فقط | قد يكتمل بتوقيعي «ب» و«ج» | قابلية استخدام المفتاحين وسلامة الإعداد |
| فقدان «أ» و«ب» | «ج» وحده لا يحقق الحد | وجود نسخ صحيحة للمفاتيح المفقودة |
| طرف يسيطر على «أ» و«ب» | قد يوقّع دون «ج» | الاستقلال الفعلي بين المسؤولين |
| موقع واحد يحتوي «أ» و«ب» | فقدان الموقع قد يزيل مفتاحين | توزيع النسخ بحسب حوادث الموقع |
| مفتاحان موجودان والإعداد ناقص | قد تتعقد إعادة بناء الحساب | وصف السياسة والبيانات العامة المطلوبة |
مرّر الجدول أفقيًا على الهاتف عند الحاجة.
ما الذي تحفظه غير العبارات السرية؟
قد تحتاج المحفظة إلى بيانات المفاتيح العامة للشركاء ووصف سياسة الإنفاق ومسارات الاشتقاق ونوع العناوين، بحسب البرنامج والتنسيق. وجود أسرار بعض الأطراف لا يعني أن البرنامج يستطيع تخمين جميع تفاصيل الإعداد الأصلي بالطريقة التي تتوقعها.
توضح وثائق Electrum الخاصة بإنشاء محفظة مشتركة أن المشاركين يتبادلون البيانات العامة اللازمة لبناء المحفظة، ثم يتحققون من تطابق العناوين. كما يشرح دليل مطوري بيتكوين فصل شروط الإنفاق عن حفظ المفاتيح. لا تحذف ملف إعداد معروفًا قبل فهم ما يلزم لإعادة بناء الحساب المتوافق.
واحفظ معلومات السياسة مع مراعاة الخصوصية. عدم كونها مفاتيح إنفاق لا يجعل نشر كل بيانات الشركاء والتسميات أمرًا مناسبًا. أنشئ خطة تتيح للأشخاص المعنيين الوصول إلى ما يلزم عند الطوارئ، دون تجميع الأسرار كلها في ملف مكشوف بحجة تسهيل الاستعادة.
مثال: ثلاثة أجهزة في موقعين
لنفترض أن سليم وضع الجهازين أ وب ونسختيهما الاحتياطيتين في مكتب واحد، ووضع ج في المنزل. يبدو أن لديه ثلاثة أجهزة وموقعين، لكن حريق المكتب قد يزيل وسيلتي توقيع معًا. في المثال البسيط سيبقى ج وحده، وهو أقل من الحد المطلوب.
لذلك يختبر سليم الخطة بسيناريو فقدان موقع كامل، لا تلف جهاز واحد فقط. يكتب لكل حادث ما المفاتيح والنسخ التي تبقى متاحة، ثم يفحص هل تحقق الحد وكيف يصل إلى بيانات السياسة. هذه المراجعة تكشف اعتمادًا مشتركًا لا يظهر عند عد الأجهزة.
وفي سيناريو مختلف، يدير سليم الأجهزة الثلاثة بنفسه ويحفظ جميع نسخها في حساب تخزين واحد. قد يتغير شكل الترتيب دون أن يتغير اعتمادها على وسيلة وصول واحدة. المقارنة المفيدة تسأل ما الحادث الذي يستطيع إسقاط أكثر من جزء في الوقت نفسه.
كيف تختبر التوقيع دون الاعتماد على التخمين؟
- حدّد السياسة المقصودة: عدد المفاتيح والحد المطلوب ودور كل مشارك ومكان معلومات الإعداد.
- ابدأ ببيئة تعليمية مناسبة: استخدم المسار التجريبي أو قيمة محدودة وفق توثيق المنتج، بعد فهم الشبكة والرسوم.
- طابق عناوين الاستقبال: تحقق من أن المشاركين يبنون الحساب نفسه، لا ملفات تحمل الاسم نفسه فقط.
- راجع معاملة واضحة: الوجهة والمبلغ والرسوم وعنوان الباقي عند انطباقه، عبر وسائل التحقق التي يدعمها الترتيب.
- اختبر بدائل التشغيل: افهم كيف تكمل العملية عند غياب مشارك، دون حذف مفاتيح عاملة لاختبار قدرتك على تعويضها.
الهدف ليس جمع تواقيع بأسرع وقت، بل التأكد من فهم كل طرف لما يوافق عليه. إذا كانت الواجهة لا تعرض تفاصيل كافية أو اختلفت الحسابات الناتجة، فتوقف قبل استخدام مبالغ أكبر. توقيعان على طلب خاطئ لا يصبحان صحيحين لأنهما يحققان الحد العددي.
هل يزيد تعدد التوقيع الرسوم دائمًا؟
لا توجد نسبة ثابتة يمكن إسنادها إلى الاسم وحده. قد تختلف أحجام المعاملات وآليات التوقيع وأنواع المخرجات والمنتجات المستخدمة. راجع تقدير البرنامج للعملية الفعلية بدل نسخ مقارنة قديمة أو افتراض أن كل إعداد 2 من 3 ينتج التكلفة نفسها.
وقارن تكلفة التشغيل أيضًا: تحديث الأدوات والتنسيق مع الأطراف وحفظ السياسة واختبار الاستعادة. قد يكون ترتيب أبسط أكثر قابلية للتنفيذ لدى مستخدم، بينما يحتاج آخر إلى فصل صلاحيات حقيقي. الاختيار يبدأ بالتهديد الذي تريد تقليله وقدرتك على إدارة الحل.
ما الأسئلة التي تحسم جاهزية الخطة؟
من يستطيع التوقيع اليوم؟ من يستطيع استعادة كل مفتاح؟ ماذا يحدث إذا غاب شخص أو فُقد موقع؟ أين توجد بيانات إعادة البناء؟ وكيف تتحقق من أن الأطراف تقرأ المعاملة نفسها؟ اكتب إجابات قابلة للتنفيذ بدل الاكتفاء بعنوان «2 من 3».
إذا لم تستطع الإجابة، فلا تعتبر الترتيب جاهزًا لمجرد نجاح إنشاء المحفظة. فائدة الحد العددي تظهر عندما تبقى المسارات المقصودة متاحة وتظل السيطرة موزعة كما خططت، بما في ذلك بعد حادث أو انقطاع طويل عن الاستخدام.
