اختيار الواجهة الخلفية

يوفّر Keychain واجهة أساسية واحدة هي SolanaSigner لجميع الواجهات الخلفية، لذا فإن الاختيار في معظم الواجهات الخلفية تشغيلي وليس معماريًا: يمكنك تغييره لاحقًا عبر الإعدادات. والاستثناء هو شكل المعاملة. فوضع Crossmint والوضع التلقائي الأصلي (native auto) في Fordefi يوقّعان ويبثّان من جهة الخادم، أما وضع Fordefi الأصلي اليدوي (native manual) فيعيد كتابة المعاملة قبل توقيعها، وبالتالي فإن الانتقال إلى أحدها أو منه يغيّر طريقة استدعائك للموقِّع. ولهذا السبب، ابدأ من متطلباتك أنت، لا من منتج بعينه. يحسم معظم الأمر سؤالان: أين يوجد المفتاح الخاص، ومن المسموح له بالموافقة على توقيع به؟

تتوفر كل واجهة خلفية، باستثناء Ledger، بجميع اللغات الأربع (Rust وTypeScript وPython وGo). أما Ledger فهي متاحة بلغة Rust فقط، خلف الميزة الاختيارية ledger.

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

مخطط القرار

تتبع الأسئلة

نماذج الحضانة

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

• الحفظ الذاتي (داخل العملية): يحتفظ تطبيقك بالمفتاح الخاص الخام. مناسب للتطوير، لكنه غير مناسب للإنتاج. الواجهة الخلفية: Memory.
• الحفظ الذاتي (محفظة أجهزة): لا يغادر المفتاح جهاز Ledger أبدًا، ويؤكد شخص ما كل توقيع على شاشته. مناسب للتوقيع التفاعلي من قِبل المشغّل، وليس للخدمات التي تعمل دون إشراف. يعمل بلغة Rust فقط، وهو اختياري، وغير مشمول بالتدقيق. الواجهة الخلفية: Ledger.
• إدارة المفاتيح ذاتيًا: أنت من يشغّل البنية التحتية للمفاتيح؛ ويبقى المفتاح داخلها ويوقّع عند الطلب. الواجهة الخلفية: HashiCorp Vault.
• KMS / HSM السحابي: يخزّن المزوّد السحابي المفتاح في بنية تحتية مدعومة بالأجهزة؛ ولا يغادر المفتاح الخدمة أبدًا، وتتحكم سياسة IAM لديك في من يمكنه التوقيع. الواجهات الخلفية: AWS KMS وGCP KMS.
• MPC والحفظ المؤسسي: يُجزَّأ المفتاح أو يُحفظ لدى مزوِّد يشارك في التوقيع وفقًا لسياستك (الموافقات، الحدود). الواجهات الخلفية: Fireblocks وDfns وPara وUtila وFordefi.
• المحافظ المدمجة والمُدارة: يدير المزوِّد المحافظ نيابةً عنك، غالبًا لتأهيل المستخدمين النهائيين. الواجهات الخلفية: Privy وTurnkey وCDP و Crossmint وOpenfort.

مقارنة الواجهات الخلفية

شكل القدرات

إلى جانب الحفظ، لكل واجهة خلفية شكل معاملة واحد، وهو الذي يحدد كيف تستدعي الموقِّع:

• التوقيع: يوقّع المزوِّد البايتات التي أنشأتها وأنت تبثّها. أغلب الواجهات الخلفية، بما فيها Ledger ووضع الصندوق الأسود في Fordefi.
• إعادة الكتابة والتوقيع: يعيد المزوِّد كتابة المعاملة ثم يوقّعها دون بثّها. تابع من المعاملة التي يعيدها. وضع Fordefi الأصلي اليدوي.
• التوقيع والبثّ: يوقّع المزوِّد ويبثّ من جهة الخادم، لذا فإن حدوث فشل لا يعني أن شيئًا لم يصل إلى الشبكة. Crossmint ووضع Fordefi الأصلي التلقائي.

يسرد جدول قدرات الموقِّعين في ملف README الخاص بكل لغة شكل كل واجهة خلفية؛ ويشرح نموذج الأمان ما الذي يضمنه كل شكل.

سيناريوهات المؤسسات

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

• عمليات الخزينة — فصل موقّع "ساخن" تشغيلي عن موقّع خزينة "بارد". دعم الخزينة بحضانة MPC أو HSM سحابي، واشتراط سياسات موافقة قبل التوقيعات عالية القيمة.
• سير عمل الموافقة — تفرض خلفيات MPC والحضانة (مثل Fireblocks) موافقة متعددة الأطراف قبل إنتاج التوقيع.
• الامتثال والتدقيق — يُصدر KMS السحابي (AWS/GCP) وVault سجلات تدقيق للتوقيع؛ وتضيف الجهات الوصائية المؤسسية تطبيق السياسات وإعداد التقارير.
• البيئات الخاضعة للتنظيم — الاحتفاظ بمواد المفاتيح في HSM أو KMS أو جهة وصاية مؤسسية حتى لا تلمس المفاتيح الخام تطبيقك أبدًا.

راجع أفضل ممارسات الإنتاج للتشغيل الآمن لهذه الخلفيات.