تقدم Spritely تصوراً لبناء تطبيقات لامركزية وآمنة افتراضياً، انطلاقاً من معالجة ثلاث مشكلات أساسية في الأنظمة الموزعة: التحكم في الوصول، وتواصل العمليات، وتسمية الموارد. جاء ذلك في عرض قدمته Christine Lemmer-Webber، المديرة التنفيذية لـ Spritely Institute، وDavid Thompson، المدير التقني في المعهد.
تنطلق الفكرة من أن الخدمات المركزية أسهل هندسياً، لكنها تمنح الجهة المشغلة قدرة كبيرة على تغيير الخدمة أو مراقبة المستخدمين أو إيقاف المنتج بالكامل. وترى Spritely أن الاعتماد على منصات مركزية يترك المستخدمين أمام خيارات محدودة، كما أن بعض القوانين المصممة لاستهداف الشركات الكبرى قد تتحول إلى «خنادق تشريعية» تجعل الامتثال مكلفاً على المشاريع الصغيرة والاستضافة الذاتية.
الأمن يبدأ من القدرات لا من الصلاحيات العامة
تنتقد المادة نماذج قوائم التحكم في الوصول والأدوار، لأنها تعتمد غالباً على مجموعات وصلاحيات واسعة وعلى جهة إدارية مركزية لمنح التفويض. البديل الذي تعرضه Spritely هو أمن القدرات، حيث تمثل القدرة مرجعاً غير قابل للتزوير يجمع بين تحديد المورد ومنح صلاحية استخدامه.
عملياً، لا يحصل البرنامج إلا على القدرات التي تمرر إليه صراحة. فإذا شُغّل تطبيق غير موثوق، يمكن منحه مثلاً صلاحية التعامل مع لوحة العرض ولوحة المفاتيح فقط، بدلاً من تشغيله بكل صلاحيات المستخدم. ويسمح هذا النموذج بتقليص الصلاحية عند تفويضها، وتمريرها إلى طرف آخر دون الرجوع إلى مدير مركزي، كما يمكن إبطالها لاحقاً.
تترجم Spritely هذه المبادئ في Goblins، وهي بيئة برمجة موزعة آمنة تعتمد على القدرات. وتربط المادة بين تمرير القدرات وتمرير الوسائط في لغات البرمجة، بحيث يصبح الوصول إلى الموارد نتيجة مباشرة لما تتلقاه الدالة أو العملية، لا لما تستطيع الوصول إليه ضمنياً. يدعم Goblins أيضاً التزامن، والاستمرارية، والمعاملات، بما في ذلك التراجع إلى حالة سابقة عند فشل العملية.
نموذج الممثلين وبروتوكول OCapN
لتنظيم الاتصال بين العمليات، تعتمد Spritely على نموذج الممثلين، حيث يستقبل كل ممثل رسالة واحدة في كل مرة، ويمكنه إرسال رسائل إلى ممثلين آخرين، أو إنشاء ممثلين جدد، أو تغيير سلوكه للرسالة التالية. ويجمع هذا النموذج بين الاتصال غير المتزامن وإدارة الحالة بطريقة تقلل الاعتماد على الأقفال المشتركة.
ترى Spritely أن REST مناسب أساساً لتطبيقات العميل والخادم، بينما لا يلائم شبكة نظير إلى نظير تتكون من أطراف لا يثق بعضها ببعض. أما OCapN، أو Object-Capability Network، فيضيف تمرير مراجع آمنة إلى استدعاءات الإجراءات البعيدة. البروتوكول مستقل عن وسيلة النقل، ويمكن تشغيله عبر WebSockets أو خدمات Tor onion أو وسائل أخرى، كما يدعم الاتصال بين طرفين وتمرير الكائنات إلى طرف ثالث.
يعتمد OCapN نموذج بيانات بلا مخطط مفروض في الطبقة الأساسية، ويدعم الاستدعاءات غير المتزامنة وقيم الوعود. وتذكر المادة أن له تطبيقات حالية في Scheme وJavaScript وDart.
التسمية المحلية بدلاً من الثقة العمياء بالأسماء العامة
تتناول Spritely مشكلة تسمية الموارد عبر أنظمة petname، التي تمنح المستخدم أسماء محلية يختارها للجهات أو الكائنات التي يعرفها. يأتي ذلك استجابة لمشكلات أسماء النطاقات، مثل التصيد الإلكتروني، والاختطاف الاسمي، وهجمات التشابه البصري.
تربط المادة هذا التحدي بما يعرف بمثلث Zooko، الذي يفترض صعوبة الجمع في نظام واحد بين الاسم المفهوم للبشر، واللامركزية، والأمان. وبدلاً من تقديم اسم عالمي باعتباره دليلاً كافياً على الهوية، يركز نموذج petname على علاقة المستخدم المحلية بالمورد.
ما الذي يتغير عملياً؟
تقدم Spritely حزمة مبادئ وأدوات أكثر من كونها منتجاً جاهزاً بديلاً للخدمات المركزية. القيمة الأساسية هي محاولة جعل الأمن واللامركزية افتراضيين للمطور، بدلاً من مطالبته بإعادة اكتشاف عقود من أبحاث الأنظمة الموزعة والأمنية. لكن العرض نفسه لا يحسم أسئلة التبني واسع النطاق، وتجربة المستخدم، والتوافق مع التطبيقات الحالية، أو كيفية إدارة الموارد عند انقطاع الأطراف أو اختلافها.
بالنسبة إلى معماريي البرمجيات، تكمن أهمية المقاربة في جمع التحكم الدقيق في الصلاحيات مع الاتصال غير المتزامن وتمرير المراجع. أما المطورون، فيبقى التحدي هو مدى نضج الأدوات والبروتوكولات وتوافر نماذج تشغيل أبسط من البنى المركزية المعتادة.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.