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

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

تتوفر جميع الواجهات الخلفية باستثناء 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 أو جهة وصاية مؤسسية حتى لا تلمس المفاتيح الخام تطبيقك أبدًا.

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