Embark Framework

ما هو Embark Framework؟

Embark Framework هو إطار تطوير مفتوح المصدر أُنشئ لمساعدة المطورين على بناء التطبيقات اللامركزية واختبارها ونشرها وإدارتها.

صُمم أساساً للتطبيقات التي تستخدم العقود الذكية المتوافقة مع Ethereum Virtual Machine، وواجهات أمامية تعمل عبر المتصفح، والتخزين اللامركزي، وتقنيات الاتصال من نظير إلى نظير.

يصف المستودع الرسمي لـ Embark Framework الإطار بأنه أداة لتطوير التطبيقات اللامركزية ونشرها.

أتمت Embark كثيراً من المهام التي كان على المطورين تنفيذها يدوياً لولا ذلك.

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

تميّز الإطار على نحو خاص بمحاولته إدارة مجموعة تقنيات التطبيق اللامركزي كاملةً بدلاً من التركيز على ترجمة العقود الذكية وحدها.

كان بإمكان مشروع Embark الجمع بين عقود البلوكشين، وشيفرة تطبيق JavaScript، وتخزين الملفات اللامركزي، وخدمات التسمية، والرسائل اللامركزية ضمن سير عمل واحد قائم على الإعدادات.

كان Embark أداة مهمة لتطوير Ethereum خلال مرحلة النمو الأولى للتطبيقات اللامركزية.

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

ما الغرض الذي صُمم Embark لتحقيقه؟

صُمم Embark للحد من أعمال الإعداد والتنسيق اللازمة لتطوير التطبيقات اللامركزية.

غالباً ما يتكون التطبيق اللامركزي من أجزاء عدة يجب أن تعمل معاً على نحو صحيح.

قد يشمل ذلك عقود Solidity، وعقدة بلوكشين، ونصوص نشر العقود، وواجهات التطبيقات الثنائية المولّدة، ومكتبات JavaScript، وواجهة ويب، وتخزيناً لامركزياً، واختبارات، وإعدادات خاصة بكل شبكة.

من دون إطار تطوير، يتعين على المطورين إعداد كل مكوّن وربطه بأنفسهم.

سعى Embark إلى توفير بيئة واحدة تفهم هذه المكونات وتحدّثها عند تغيّر المشروع.

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

كان الهدف من سير العمل الآلي هذا تقصير دورات التطوير وتقليل أخطاء الإعداد اليدوي.

هل لا يزال Embark Framework يخضع للصيانة؟

ينبغي اعتبار Embark إطار تطوير قديماً للعملات المشفرة، لا خياراً يخضع للصيانة النشطة لمشروع إنتاجي جديد.

يحدد المستودع الرسمي الإصدار 6.0.0، الصادر في 27 أبريل 2020، بوصفه أحدث إصدار مستقر.

يسجل سجل التغييرات الرسمي إصدارين ليليين لاحقين بتاريخ 8 أغسطس 2020 و8 أكتوبر 2020.

ويُظهر سجل حزمة Embark العام أيضاً أن الحزمة الرئيسية لم تتلقَّ إصداراً مستقراً حديثاً.

يوضح دليل أطر التطوير الحالي من Ethereum دور أطر تطوير التطبيقات المتكاملة، لكنه لم يعد يدرج Embark ضمن الأطر المذكورة.

يعني غياب الإصدارات الحديثة أن التبعيات القديمة وأنظمة البناء وعملاء البلوكشين وواجهات JavaScript البرمجية والافتراضات المتعلقة بالشبكات قد لا تعمل بأمان على أجهزة التطوير الحالية.

قد تظل مشاريع Embark القائمة تحتوي على شيفرة وعقود واختبارات وسجل نشر مفيد.

لكن على الفرق التي تتولى صيانتها تدقيق كل تبعية والنظر في نقل سير العمل الحيوي إلى مكونات تخضع للصيانة النشطة.

من أنشأ Embark؟

أنشأ المطور Iuri Matias مشروع Embark في الأصل، ثم تولى تطويره فريق أوسع من مطوري المصادر المفتوحة.

انتقل المشروع بين مؤسسات GitHub مع تغير القائمين على صيانته والدعم المؤسسي له.

يوجد شيفره المصدرية العامة الرئيسية الآن ضمن مؤسسة Embark Labs على GitHub.

يحتوي المستودع على آلاف الالتزامات التاريخية وحزم معيارية كثيرة تغطي التفاعل مع البلوكشين والنشر والاختبار والتخزين والاتصال وتوليد الشيفرة وأدوات واجهات المستخدم.

صدر Embark بموجب رخصة MIT، التي تتيح للمطورين دراسة الشيفرة وتعديلها وإعادة توزيعها وفق شروط الرخصة.

ما إطار تطوير التطبيقات اللامركزية؟

إطار تطوير التطبيقات اللامركزية هو مجموعة أدوات تنسق مهام تطوير البلوكشين الشائعة.

توضح وثائق تطوير Ethereum أن الأطر تتضمن عادةً أدوات البلوكشين المحلي، وترجمة العقود، والاختبار، وتكاملات الواجهة الأمامية، وإعداد الشبكات، والنشر، ودعم التوزيع اللامركزي.

لا يحل الإطار محل المعرفة بالعقود الذكية أو أمن البلوكشين.

إنما يوفر الأتمتة لمراحل التطوير.

قد ينشئ الإطار الإعدادات، لكن تظل مسؤولية فهم الشيفرة والمعاملات الناتجة على عاتق المطور.

قد يؤدي استخدام إطار تطوير إلى تحسين الإنتاجية، لكنه قد يضيف أيضاً تبعيات وافتراضات خاصة بالإطار.

ما المقصود بـ Serverless في Embark؟

كثيراً ما وصف Embark التطبيقات اللامركزية بأنها تطبيقات HTML5 بلا خادم تستخدم تقنية لامركزية واحدة أو أكثر.

في هذا السياق، لم يكن مصطلح بلا خادم يعني بالضرورة عدم وجود خوادم أو أجهزة حاسوب.

فلا بد من تشغيل عُقد البلوكشين ونظراء التخزين والبوابات وخدمات المحافظ والبنية التحتية لتوصيل الويب في مكان ما.

كان المقصود بالمصطلح أن التطبيق قد يقلل اعتماده على خادم تطبيقات تقليدي واحد يتحكم به مشغّل واحد.

يمكن للعقود الذكية استضافة منطق التطبيق وحالته المشتركة.

ويمكن للتخزين اللامركزي توزيع الملفات على العُقد المشاركة.

كما يمكن لواجهة أمامية ثابتة التواصل مباشرةً مع خدمات البلوكشين أو التخزين عبر متصفح المستخدم.

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

إدارة العقود الذكية في Embark

كانت إدارة العقود الذكية إحدى الميزات الرئيسية في Embark.

كان الإطار قادراً على تحديد ملفات مصدر العقود وترجمتها وتحديد تبعياتها ونشرها على شبكة EVM مهيأة.

كما كان يتتبع العقود المنشورة مسبقاً ويحاول تجنب إعادة نشرها دون حاجة.

إذا كان أحد العقود يعتمد على عنوان عقد آخر، أمكن لـ Embark ترتيب عملية النشر وتمرير العنوان المطلوب إلى العقد التابع.

كان ذلك مفيداً للتطبيقات التي تضم عقود توكنات وسجلات وعقود تحكم في الوصول ومصانع ومكتبات ومكونات مترابطة أخرى.

أنشأ النظام أيضاً ملفات للعقود يمكن لشيفرة JavaScript استخدامها لاستدعاء العقود المنشورة.

قلل النشر الآلي الأعمال المتكررة، لكن ظل على المطورين التحقق من معاملات المُنشئ والعناوين ذات الامتيازات ومعرّفات الشبكات وإعدادات الغاز وحسابات النشر.

إعادة نشر العقود تلقائياً

كان Embark قادراً على مراقبة ملفات العقود الذكية بحثاً عن التغييرات أثناء تشغيل بيئة التطوير.

عند تغيير عقد، كان الإطار يستطيع إعادة ترجمته وتحديد ما إذا كان يلزم نشره مجدداً.

ثم كان بإمكانه تحديث ملفات التطبيق وإعادة بناء الواجهة الأمامية.

أدى ذلك إلى تسريع دورة التطوير، إذ لم يكن المطور بحاجة إلى تكرار كل أمر يدوياً.

كانت إعادة النشر التلقائية ملائمة أساساً على شبكات التطوير المحلية أو المؤقتة.

ينشئ نشر عقد إنتاجي مجدداً عنواناً جديداً، ولا ينقل تلقائياً حالة العقد الأصلي أو أصوله.

يجب ألا يتعامل المطور مطلقاً مع إعادة نشر عقد إنتاجي على أنها تحديث بسيط لتطبيق ويب.

تتطلب العقود غير القابلة للتغيير والأنظمة القابلة للترقية إجراءات مختلفة للترحيل والحوكمة والأمان.

إعداد العقود

استخدمت مشاريع Embark ملفات إعداد لوصف العقود وسلوك النشر.

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

وكان بالإمكان استخدام إعدادات بيئة منفصلة للتطوير المحلي والشبكات الخاصة وبيئات الاختبار العامة وشبكات الإنتاج.

ساعد الفصل بين البيئات الفرق على تجنب استخدام العناوين أو بيانات الاعتماد أو قواعد النشر نفسها في كل مكان.

ومع ذلك، قد تصبح ملفات الإعداد خطرة إذا احتوت على مفاتيح خاصة أو عبارات استرداد أو كلمات مرور أو نقاط نهاية بعيدة غير مقيدة.

يجب عدم إدراج بيانات الاعتماد الحساسة مطلقاً في مستودع شيفرة مصدرية عام.

EmbarkJS

كان EmbarkJS طبقة تكامل JavaScript التي استخدمتها التطبيقات الأمامية المبنية بواسطة Embark.

أتاح لشيفرة المتصفح الوصول إلى العقود الذكية المنشورة والخدمات اللامركزية الأخرى المهيأة.

أنشأ Embark كائنات للعقود استناداً إلى واجهات التطبيقات الثنائية المولّدة والعناوين المنشورة.

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

وفر EmbarkJS أيضاً وحدات للتكامل مع التخزين والاتصال والتسمية عند تفعيل هذه الميزات.

قللت الكائنات المولّدة الحاجة إلى إدارة العناوين وواجهات التطبيقات الثنائية يدوياً.

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

وعود JavaScript والعمليات غير المتزامنة

أتاح Embark كثيراً من عمليات العقود عبر وعود JavaScript.

وتوافق ذلك مع الطبيعة غير المتزامنة لتطوير تطبيقات البلوكشين.

قد يتطلب استدعاء عقد إرسال طلب RPC إلى عقدة بعيدة.

وقد تتطلب المعاملة التي تغيّر الحالة موافقة المستخدم وبثها وإدراجها في كتلة وعدة تأكيدات.

كان على المطورين التمييز بين إرسال المعاملة بنجاح وتنفيذها بنجاح والحصول على عدد كافٍ من التأكيدات.

لم يكن اكتمال وعد إرسال المعاملة يعني دائماً نجاح إجراء العقد المقصود.

كان على التطبيقات فحص الإيصالات وحالة التنفيذ والأحداث المنبعثة ومعلومات الأخطاء.

Embark وشبكات EVM

صُمم Embark أساساً لـ Ethereum وغيرها من سلاسل البلوكشين المتوافقة مع Ethereum Virtual Machine.

تنفذ EVM شيفرة بايت العقود الذكية وتوفر نموذجاً مشتركاً للحسابات والتخزين والرسائل والغاز واستدعاءات العقود.

كان بإمكان Embark الاتصال بالعُقد المحلية أو الشبكات الخاصة أو بيئات الاختبار أو الشبكات العامة عبر مزودين مهيئين.

استخدم أساليب JSON-RPC المتوافقة مع Ethereum للتواصل مع عُقد البلوكشين.

تصف وثائق Ethereum JSON-RPC واجهة الطلبات القياسية التي تستخدمها التطبيقات للاستعلام من العُقد وإرسال المعاملات.

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

تطوير البلوكشين المحلي

كان Embark قادراً على بدء بيئة بلوكشين محلية أو الاتصال بها لأغراض التطوير والاختبار.

أتاحت الشبكة المحلية للمطورين نشر العقود بسرعة من دون إنفاق أصول على شبكة عامة.

وكان من الممكن أن توفر حسابات اختبار بأرصدة محاكاة وإنتاجاً أسرع للكتل.

كان التطوير المحلي مفيداً للتحقق من منطق العقود وتكامل الواجهة الأمامية وترتيب النشر وتدفقات المعاملات.

لكن البلوكشين المحلي لا يحاكي كل الظروف الموجودة على شبكة عامة.

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

تتطلب أنظمة الإنتاج اختبارات إضافية في بيئات وافتراضات واقعية.

الاختبار في Embark

دعم Embark التطوير القائم على الاختبارات للعقود الذكية باستخدام JavaScript.

كان بإمكان المطورين كتابة اختبارات تنشر العقود وتستدعي الدوال وترسل المعاملات وتتحقق من الحالة الناتجة.

أدار الإطار حسابات الاختبار وكان قادراً على إعادة ضبط بلوكشين التطوير أو تهيئته عند إجراء الاختبارات.

كان بإمكان اختبارات العقود التحقق من سلوك النشر وضوابط الوصول وأرصدة التوكنات والأحداث والعمليات المرتجعة والتفاعلات بين العقود.

كانت الاختبارات الآلية من أكثر ميزات Embark قيمة، لأن أخطاء العقود الذكية قد تصبح دائمة بعد النشر.

لكن اجتياز الاختبارات لا يثبت أن العقد آمن.

فالاختبارات لا تغطي إلا السيناريوهات والافتراضات التي أدرجها المطور.

ما الجوانب التي ينبغي أن تغطيها اختبارات العقود الذكية؟

ينبغي لمجموعة الاختبارات المتينة أن تشمل سلوك المستخدم المتوقع والسلوك العدائي المتعمد.

وينبغي اختبار المتصلين المصرح لهم وغير المصرح لهم.

كما ينبغي اختبار القيم الصفرية والقصوى والاستدعاءات المتكررة والترتيب غير المتوقع والعناوين غير الصالحة والاستدعاءات الخارجية الفاشلة والحالات الحدية.

ويجب التحقق من بقاء تغييرات الحالة صحيحة عند ارتجاع معاملة.

ينبغي اختبار إعادة الدخول عندما يرسل العقد أصولاً أو يستدعي عقوداً غير موثوق بها.

ويجب اختبار الدوال الإدارية ومسارات الترقية وضوابط الإيقاف وعمليات السحب في حالات الطوارئ ونقل الملكية.

تشرح إرشادات Solidity الأمنية مخاطر شائعة، منها إعادة الدخول والحلقات المقيدة بالغاز والوكلاء المصرح لهم والمعلومات الخاصة والاستدعاءات الخارجية.

ملفات العقود في Embark

ملف العقد الناتج هو ملف مولّد يحتوي على المعلومات اللازمة لنشر عقد ذكي أو التفاعل معه.

قد يتضمن واجهة العقد الثنائية وشيفرة البايت والعنوان المنشور ومعلومات الشبكة ومخرجات المترجم ومراجع المصدر.

أنشأ Embark ملفات ناتجة تتيح لشيفرة الواجهة الأمامية والاختبارات الوصول إلى العقود دون نسخ عناوينها وواجهاتها يدوياً.

كان يجب أن تتطابق الملفات الناتجة مع شبكة النشر المقصودة.

قد يؤدي استخدام عنوان من شبكة خاطئة إلى استدعاء التطبيق عقداً غير ذي صلة أو عنواناً لا يحتوي على شيفرة.

ينبغي لتطبيقات الإنتاج التحقق من معرّف سلسلة البلوكشين وشيفرة العقد بدلاً من الاعتماد على ملف محلي ناتج فقط.

خط أنابيب البناء في Embark

تضمن Embark خط أنابيب بناء لإعداد أصول الواجهة الأمامية للتطبيق اللامركزي.

كان من الممكن أن ينسخ خط الأنابيب ملفات JavaScript وHTML وأوراق الأنماط والصور وملفات البلوكشين الناتجة أو يحولها أو يجمعها.

وكان بإمكانه العمل مع أدوات تطوير الويب الشائعة ومكتبات الواجهة الأمامية بدلاً من فرض تقنية واحدة لواجهة المستخدم.

أتاحت هذه المرونة للمطورين مواصلة استخدام أساليب تطوير المتصفح المألوفة وإضافة تكاملات البلوكشين.

تنطوي خطوط أنابيب البناء على مخاطر في سلسلة توريد البرمجيات لأنها تنفذ الحزم والنصوص أثناء التثبيت أو الترجمة.

قد يعتمد المشروع القديم على حزم متقادمة تحتوي على ثغرات أو لم تعد تُثبت على نحو صحيح أو أزيلت من مصدرها الأصلي.

Embark Cockpit

تضمن Embark واجهة تطوير رسومية تُعرف عادةً باسم Cockpit.

كان الغرض من Cockpit إتاحة عرض مرئي لبيئة التطبيق اللامركزي قيد التشغيل للمطورين.

كان بإمكانه عرض العقود والمعاملات والسجلات والعمليات والخدمات وحالة التطوير.

كما تضمنت الواجهة أدوات للتفاعل مع العقود واستكشاف النشاط أثناء التطوير.

قد تكون لوحة المعلومات المرئية أسهل استخداماً من مجموعة نوافذ منفصلة لسطر الأوامر.

ومع ذلك، ظل على المطورين فهم المعاملات الأساسية، لأن لوحة المعلومات قد تبسط تفاصيل مهمة أو تحذفها.

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

وحدة تحكم Embark

وفرت وحدة تحكم Embark بيئة أوامر تفاعلية متصلة بمشروع وشبكة بلوكشين مهيأين.

كان بإمكان المطورين استخدامها لفحص الحسابات والوصول إلى كائنات العقود المولّدة واستدعاء دوال القراءة وإرسال المعاملات.

كانت وحدة التحكم التفاعلية مفيدة لتصحيح الأخطاء والاختبار اليدوي.

لكنها كانت خطرة أيضاً عند الاتصال بحساب إنتاجي يحتفظ بأصول قيّمة.

قد تنشر الأوامر العقود أو تغيّر الحالة أو تنقل الأصول أو تمنح الأذونات.

يجب عدم كشف المفاتيح الخاصة والحسابات المفتوحة عبر وحدة تحكم غير مؤمّنة أو نقطة نهاية RPC متاحة للعامة.

Embark والتخزين اللامركزي

تكامل Embark مع أنظمة التخزين اللامركزي كي تتمكن التطبيقات من رفع الملفات واسترجاعها ونشرها خارج البلوكشين.

يكون تخزين ملفات التطبيقات الكبيرة مباشرةً في مساحة تخزين عقود EVM مكلفاً عادةً.

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

قدم EmbarkJS واجهة تطبيق مشتركة لخدمات التخزين المدعومة.

وكان Embark قادراً أيضاً على نشر الواجهة الأمامية الثابتة للتطبيق عبر التخزين اللامركزي.

قلل ذلك الاعتماد على خادم ويب تقليدي واحد، لكنه لم يضمن بقاء المحتوى متاحاً إلى الأبد.

Embark وIPFS

كان IPFS أحد أبرز تكاملات التخزين اللامركزي في Embark.

يستخدم IPFS عنونة المحتوى، أي إن الملف يمكن تحديده بوصف محتواه تشفيرياً بدلاً من تحديده بموقعه على خادم فحسب.

تشرح وثائق IPFS الرسمية كيف تتيح معرّفات المحتوى طلب البيانات استناداً إلى محتواها.

عادةً ما يؤدي تغيير الملف إلى معرّف محتوى مختلف.

يساعد ذلك المستخدمين على اكتشاف تغييرات المحتوى.

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

تحتاج المشاريع إلى خطة لتثبيت الملفات أو نسخها أو ضمان استمرارها من أجل ملفات التطبيقات المهمة.

Embark وSwarm

تضمن Embark أيضاً دعماً تاريخياً للتخزين والنشر المعتمدين على Swarm.

كان الإطار قادراً على نشر ملفات الواجهة الأمامية واسترجاع مصادر العقود أو محتوى التطبيق عبر تكاملات التخزين المدعومة.

تطورت واجهات التخزين وسلوك الشبكات منذ آخر إصدار مستقر لـ Embark.

لذلك قد لا يكون الإعداد القديم متوافقاً مع العُقد أو البوابات أو إصدارات الحزم أو قواعد العنونة الحالية.

ينبغي للمطورين الذين يصونون مشروعاً قديماً اختبار كل عملية تخزين على حدة قبل الاعتماد عليها في الإنتاج.

الاتصال اللامركزي

تضمن Embark تكاملات مع أنظمة اتصال لامركزية أو من نظير إلى نظير.

أشارت وثائق المشروع إلى Whisper وOrbit بوصفهما تقنيتين مدعومتين للاتصال.

كان الهدف من هذه التكاملات تمكين التطبيقات اللامركزية من إرسال الرسائل واستقبالها عبر القنوات من دون الاعتماد كلياً على خادم مراسلة تقليدي واحد.

قد تدعم طبقة الاتصال الإشعارات أو المحادثات أو التنسيق أو تبادل البيانات الخاصة بالتطبيق.

ظل تسليم الرسائل والحماية من الرسائل المزعجة والهوية والتشفير والوصول دون اتصال والتخزين طويل الأمد مسائل تصميم منفصلة.

قد لا تعمل تكاملات الاتصال القديمة مع برامج الشبكات الحالية.

إضافات Embark

استخدم Embark بنية إضافات معيارية لتوسيع ميزاته الأساسية.

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

جعل نظام الإضافات الإطار أكثر مرونة، إذ لم يكن على المطورين تعديل المشروع الأساسي لكل خدمة جديدة.

لكن الإضافات زادت أيضاً مخاطر سلسلة التوريد والتوافق.

قد تنفذ الإضافة شيفرة محلية أو تقرأ الإعدادات أو تصل إلى الحسابات أو تعدّل الملفات المولّدة أو تؤثر في سلوك النشر.

ينبغي للمطورين مراجعة شيفرة الإضافة والقائمين على صيانتها وسجل إصداراتها وتبعياتها وأذوناتها قبل تثبيتها.

أوامر Embark

وفّر Embark أوامر لسطر الأوامر لإنشاء المشاريع وتشغيلها واختبارها وبنائها والتفاعل معها.

كان أمر التثبيت التاريخي

.

كان بإمكان الأمر

إنشاء نموذج لتطبيق لامركزي.

بدأ الأمر

خدمات التطوير المهيأة وراقب المشروع بحثاً عن التغييرات.

شغّل الأمر

اختبارات العقود الذكية.

أعد الأمر

ملفات التطبيق للنشر.

فتح الأمر

بيئة تفاعلية متصلة بإعداد محدد.

قد تفشل هذه الأوامر التاريخية على أنظمة التشغيل أو بيئات تشغيل الحزم الحالية، لأن البرنامج وتبعياته قديمان.

إعداد بيئات Embark

كان بإمكان مشروع Embark تحديد بيئات مختلفة لأهداف بلوكشين متعددة.

قد تستخدم البيئة المحلية حسابات مولّدة تلقائياً وبلوكشين محاكاة.

وقد تتصل بيئة اختبار عامة بعقدة بعيدة وتنشر باستخدام حساب اختبار ممول.

وقد تستخدم بيئة الإنتاج ضوابط توقيع أكثر صرامة وعناوين عقود ثابتة وإعدادات غاز خضعت لمراجعة دقيقة.

قلل فصل البيئات خطر استخدام إعداد الاختبار في الإنتاج عن طريق الخطأ.

لكن أسماء البيئات وحدها لا توفر الأمان.

ظلت نصوص النشر بحاجة إلى فحوص صريحة لمعرّف السلسلة وإجراءات آمنة لإدارة المفاتيح.

Embark وتبعيات العقود

غالباً ما تضم التطبيقات اللامركزية الكبيرة عقوداً تعتمد على عقود أخرى.

قد يتطلب المُنشئ عنوان توكن أو سجل أو مكتبة أو مسؤول أو أوراكل.

أتاح Embark لإعدادات النشر الإشارة إلى عقود أخرى وحل عناوينها المنشورة.

وكان بإمكانه استخدام معلومات التبعية لتحديد ترتيب النشر الصحيح.

قللت أتمتة التبعيات النسخ اليدوي، لكنها قد تخفي علاقات ثقة مهمة.

ظل على المطورين التحقق من أن العقد المشار إليه هو الإصدار المقصود وأن أذوناته تتوافق مع تصميم أمان التطبيق.

Embark وتسمية التطبيقات

تضمن Embark تكاملات تاريخية مع أنظمة التسمية اللامركزية.

يمكن لنظام التسمية ربط اسم يسهل على البشر قراءته بحساب أو عقد أو معرّف محتوى أو مورد بلوكشين آخر.

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

قد تنتهي صلاحية الأسماء أو تُنقل أو تُحل إلى وجهة جديدة أو تتحكم بها حسابات مخترقة.

يجب ألا يتعامل التطبيق مع الاسم المقروء على أنه إثبات دائم لهوية العقد.

ينبغي التحقق من العنوان الذي تم حله والشبكة قبل تنفيذ العمليات ذات القيمة العالية.

ما مزايا Embark Framework؟

قدم Embark سير عمل موحداً للعقود والشيفرة الأمامية والاختبار والنشر والتخزين والاتصال.

ولّد تلقائياً كائنات العقود في JavaScript وملفات النشر.

راقب ملفات المصدر وأعاد بناء المكونات أو نشرها عند الحاجة.

دعم إدارة تبعيات العقود المتعددة.

وفر شبكات تطوير محلية واختبارات JavaScript.

وأتاح إعدادات مختلفة لبيئات بلوكشين متعددة.

كما وفر لوحة معلومات مرئية ووحدة تحكم تفاعلية.

وساعد المطورين أيضاً على استيعاب فكرة أن التطبيق اللامركزي يمكن أن يستخدم تقنيات تتجاوز البلوكشين وحده.

ما قيود Embark Framework؟

حاول Embark تنسيق تقنيات كثيرة ومختلفة، ما جعل الإطار كبيراً ومعقداً.

اعتمد سلوكه على حزم Node.js عديدة وعملاء بلوكشين ومترجمات وأدوات تخزين ومكتبات واجهات أمامية وإضافات.

قد يؤثر تغيير غير متوافق في أي تبعية رئيسية على بيئة التطوير بأكملها.

قد تصعّب عمليات النشر الآلية وتوليد الشيفرة على المبتدئين فهم الأوامر والمعاملات التي تُنفذ بدقة.

كما زادت مجموعة الميزات الواسعة مدة التثبيت وتعقيد استكشاف الأخطاء وإصلاحها.

ويثير غياب الإصدارات المستقرة الحديثة الآن مخاوف جدية بشأن التوافق وسلسلة توريد البرمجيات.

لماذا تشكل أطر التطوير القديمة مخاطر أمنية؟

قد يحتوي الإطار القديم على تبعيات متقادمة ذات ثغرات موثقة للعامة.

وقد تتضمن شجرة تبعياته حزمًا لم تعد تخضع للصيانة.

وقد تعتمد نصوص التثبيت على مستودعات أو تنزيلات ثنائية أو أوامر نظام قديمة.

وقد لا يفهم الإطار سلوك مترجمات Solidity الحالية أو ميزات EVM الحديثة.

وقد يولّد افتراضات غير آمنة بشأن الغاز أو يستخدم خيارات عُقد تم إيقافها.

وقد تحتوي مكتبات الواجهة الأمامية القديمة على ثغرات للمتصفحات أو سلوك غير متوافق مع تكاملات المحافظ.

لا يثبت نجاح التثبيت أن بيئة التطوير الناتجة آمنة.

مخاطر سلسلة توريد البرمجيات

قد يؤدي تثبيت إطار تطوير JavaScript إلى تنفيذ شيفرة من حزم مباشرة وغير مباشرة عديدة.

قد تقرأ حزمة مخترقة متغيرات البيئة أو تعدّل ملفات المصدر أو تسرق بيانات اعتماد التوقيع أو تدرج شيفرة خبيثة في عمليات البناء الناتجة.

قد تُحل التبعيات على نحو مختلف عند فقدان إصدارات الحزم التاريخية في ملفات القفل القديمة.

ينبغي للمطورين تثبيت المشاريع القديمة في بيئة معزولة لا تحتوي على مفاتيح خاصة قيّمة.

كما ينبغي لهم مراجعة ملف القفل وبصمات الحزم ونصوص التثبيت ورسم التبعيات.

يجب أن تظل عمليات توقيع الإنتاج منفصلة عن بيئة بناء قديمة غير موثوق بها أو أعيد إنشاؤها حديثاً.

سلامة المفاتيح الخاصة

احتاج Embark إلى الوصول إلى حساب عند نشر العقود أو إرسال معاملات التطوير.

يشكل تخزين مفتاح خاص أو عبارة استرداد غير مشفرة في إعدادات المشروع خطراً أمنياً جسيماً.

قد يؤدي تسريب مستودع الشيفرة المصدرية إلى كشف جميع الأصول التي يتحكم بها ذلك المفتاح.

ويمكن لتبعية خبيثة أيضاً قراءة ملفات الإعداد المحلية أو متغيرات البيئة.

ينبغي أن تستخدم عمليات النشر الإنتاجية إجراء توقيع مضبوطاً بأموال محدودة ومراجعة واضحة للمعاملات.

يجب عدم إعادة استخدام حساب التطوير بوصفه حساب خزينة طويل الأمد أو حساباً إدارياً.

التحقق من العقود الذكية

لم يكن نشر عقد عبر Embark يثبت تلقائياً أن المصدر العام يطابق شيفرة البايت المنشورة.

يتيح التحقق من العقود للمستخدمين مقارنة الشيفرة المصدرية المنشورة وإعدادات المترجم بالشيفرة على السلسلة.

ينبغي للمطورين الاحتفاظ بإصدار المترجم الدقيق وإعدادات التحسين ومعاملات المُنشئ والمكتبات وملفات المصدر المستخدمة في النشر.

قد يصعب إعادة إنتاج ملفات المشاريع القديمة الناتجة عند اختفاء ملفات المترجمات القديمة أو التبعيات.

لذلك، تكتسب عمليات البناء القابلة لإعادة الإنتاج وسجلات النشر المؤرشفة أهمية عند صيانة مشروع Embark.

الانتقال من Embark

لا يتطلب الانتقال من Embark بالضرورة إعادة نشر كل عقد ذكي.

يمكن للفريق الإبقاء على العقود المنشورة واستبدال سير العمل المحلي للترجمة والاختبار والنشر وبناء الواجهة الأمامية.

تتمثل الخطوة الأولى في جرد عناوين العقود وملفات المصدر وواجهات التطبيقات الثنائية وإعدادات المترجم ومعاملات المُنشئ والمكتبات والحسابات الإدارية.

والخطوة التالية هي إعادة إنتاج العقود في بيئة بناء حديثة ومعزولة.

ينبغي للاختبارات مقارنة الملفات الجديدة الناتجة بالشيفرة المنشورة تاريخياً، حيثما أمكن.

بعد ذلك يمكن تحديث شيفرة الواجهة الأمامية لتحميل واجهات تطبيق ثنائية وعناوين تم التحقق منها، دون الاعتماد على ملفات Embark المولّدة.

ينبغي ألا تحدث إعادة النشر إلا عند الحاجة إلى تغيير العقود نفسها وبعد فهم مخاطر الانتقال.

الحفاظ على مشروع Embark قائم

ينبغي للفريق الذي يصون تطبيق Embark قديماً أرشفة مستودع المصدر الكامل وملف القفل.

كما ينبغي له تسجيل إصدار Node.js المطلوب ونظام التشغيل وإصدار المترجم وعميل البلوكشين ومتغيرات البيئة وسلوك مدير الحزم.

قد تساعد صور الحاويات أو الآلات الافتراضية على حفظ بيئة تاريخية قابلة لإعادة الإنتاج.

لكن ينبغي فحص هذه الصور وعزلها، لأن حفظ البيئة يحفظ ثغراتها أيضاً.

ينبغي توثيق العقود المهمة بمعزل عن الإطار كي يتمكن المطورون من التفاعل معها حتى إذا لم يعد Embark يعمل.

ويجب التحقق من عناوين النشر وأدوار المسؤولين مباشرةً على السلسلة.

هل ينبغي للمطورين بدء مشروع جديد باستخدام Embark؟

ينبغي للمطورين عموماً ألا يختاروا Embark أساساً لتطبيق عملات مشفرة إنتاجي جديد في عام 2026.

لم يتلقَّ الإطار إصداراً مستقراً منذ أبريل 2020.

وصُممت تكاملاته وتبعياته الموثقة وفق نسخة أقدم من بيئة تطوير Ethereum.

يحتاج المشروع الجديد إلى أدوات تخضع للصيانة النشطة وتدعم إصدارات المترجمات الحالية وصيغ المعاملات وسلوك الشبكات وأساليب الاختبار والممارسات الأمنية.

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

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

الأهمية التاريخية لـ Embark

ساعد Embark على ترسيخ فكرة إطار متكامل للتطبيقات اللامركزية.

وتعامل مع العقود الذكية وشيفرة الواجهة الأمامية والتخزين والاتصال والاختبار والنشر وواجهات المطورين على أنها أجزاء من تطبيق واحد.

كان ذلك مهماً في فترة كانت فيها أدوات تطوير البلوكشين مجزأة ويصعب إعدادها.

كما أتاح Embark لمزيد من مطوري JavaScript استخدام توليد ملفات العقود آلياً والنشر الذي يراعي التبعيات.

وشجع تكامله مع التخزين اللامركزي المطورين على التفكير في ما يتجاوز استخدام حالة البلوكشين لكل نوع من البيانات.

لا تزال كثير من عمليات التطوير الحديثة تعالج المشكلات نفسها، وإن كانت تستخدم بنيات وأدوات مختلفة.

مثال على سير عمل التطوير في Embark

لنفترض أن مطوراً أراد إنشاء تطبيق تصويت بسيطاً قائماً على التوكنات.

يمكن للمطور إنشاء عقود Solidity للتوكن وقواعد التصويت.

وقد يصف إعداد Embark عقد التوكن ويمرر عنوانه المنشور إلى عقد التصويت.

يمكن لـ Embark بدء بلوكشين محلي، وترجمة العقدين، ونشرهما بالترتيب المطلوب، وإنشاء ملفات الواجهة الأمامية.

يمكن لتطبيق المتصفح استخدام EmbarkJS لعرض أرصدة التوكنات وإرسال معاملات التصويت.

ويمكن لاختبارات JavaScript التحقق من أن حاملي التوكنات المؤهلين وحدهم قادرون على التصويت، وأن الحساب الواحد لا يستطيع التصويت مرتين.

يمكن بناء الواجهة الأمامية المكتملة ورفعها عبر تكامل التخزين اللامركزي المهيأ.

مع ذلك، يتطلب كل جزء من سير العمل مراجعة أمنية قبل النشر العام.

أخطاء شائعة عند استخدام Embark Framework

من الأخطاء الشائعة افتراض أن Embark لا يزال يخضع للصيانة النشطة لمجرد أن مستودعه لا يزال متاحاً للعامة.

ومنها أيضاً تثبيت الحزمة العامة القديمة مباشرةً على جهاز يحتوي على مفاتيح عملات مشفرة قيّمة.

والخطأ الثالث هو اعتبار نشر العقود آلياً آمناً من دون مراجعة معاملات المُنشئ والحسابات ذات الامتيازات.

والخطأ الرابع هو افتراض أن الاختبارات المحلية تحاكي كل ظروف الشبكة العامة.

والخامس هو تخزين مفاتيح النشر الخاصة في ملفات الإعداد أو في مستودع الشيفرة المصدرية.

والسادس هو افتراض أن التخزين اللامركزي يضمن توفر الملفات دائماً.

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

والثامن هو استخدام ملفات مولّدة من شبكة بلوكشين خاطئة.

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

والعاشر هو إعادة نشر عقد إنتاجي من دون التخطيط لنقل المستخدمين والأصول والأذونات وحالة التطبيق.

الأسئلة الشائعة

ما هو Embark Framework؟

Embark Framework أداة قديمة مفتوحة المصدر لتطوير التطبيقات اللامركزية المتوافقة مع Ethereum واختبارها ونشرها وإدارتها.

ما لغات البرمجة التي استخدمها Embark؟

عمل Embark أساساً مع العقود الذكية المكتوبة بلغة Solidity وشيفرة التطبيقات المكتوبة بـ JavaScript أو TypeScript.

ما سلاسل البلوكشين التي دعمها Embark؟

صُمم أساساً لـ Ethereum والشبكات الأخرى المتوافقة مع Ethereum Virtual Machine وواجهات JSON-RPC المشابهة لـ Ethereum.

هل لا يزال Embark Framework نشطاً؟

لم يتلقَّ الإطار إصداراً مستقراً منذ الإصدار 6.0.0 الصادر في 27 أبريل 2020، لذا ينبغي التعامل معه بوصفه برنامجاً قديماً.

ما أحدث إصدار مستقر من Embark؟

يحدد المستودع الرسمي الإصدار 6.0.0 بوصفه أحدث إصدار مستقر.

هل صدرت إصدارات بعد الإصدار 6.0.0؟

يسجل سجل التغييرات الرسمي إصدارين ليليين 6.0.1 في أغسطس وأكتوبر 2020، لكن لم يصدر بعدهما إصدار مستقر.

ما المهام التي أتمتها Embark؟

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

ما EmbarkJS؟

EmbarkJS هي طبقة تكامل JavaScript التي أتاحت لشيفرة التطبيقات استخدام العقود الذكية والتخزين والاتصال والخدمات ذات الصلة المهيأة.

ما Embark Cockpit؟

كانت Cockpit لوحة تطوير رسومية في Embark لعرض العقود والمعاملات والخدمات والسجلات ونشاط المشروع.

هل كان Embark قادراً على تشغيل بلوكشين محلي؟

نعم، كان بإمكانه بدء شبكة تطوير EVM محلية أو الاتصال بها لنشر العقود واختبارها.

هل دعم Embark اختبار العقود الذكية؟

نعم، دعم اختبارات العقود المعتمدة على JavaScript وسير عمل التطوير القائم على الاختبارات.

هل دعم Embark التخزين اللامركزي؟

نعم، تضمن تكاملات تاريخية مع IPFS وتخزين الملفات والنشر المعتمدين على Swarm.

هل دعم Embark الرسائل اللامركزية؟

نعم، تضمنت الإصدارات التاريخية تكاملات مع تقنيات اتصال من نظير إلى نظير مثل Whisper وOrbit.

هل استطاع Embark نشر عدة عقود مترابطة؟

نعم، أمكنه تتبع تبعيات العقود ونشرها بترتيب يمرر العناوين المطلوبة إلى العقود التابعة.

هل دعم Embark أطر الواجهة الأمامية؟

نعم، صُمم خط أنابيب الويب فيه للعمل مع تقنيات المتصفح وعمليات البناء المختلفة.

هل كان Embark بلوكشين؟

لا، كان برنامج تطوير يتصل بالبلوكشين وتقنيات لامركزية أخرى.

هل كان Embark عملة مشفرة؟

لا، كان إطار تطوير مفتوح المصدر ولم يتطلب عملة مشفرة أصلية.

هل جعل Embark العقود الذكية آمنة؟

لا، فقد دعم التطوير والاختبار، لكنه لم يضمن أمان شيفرة العقود أو أذوناتها أو منطقها الاقتصادي.

هل يمكن للعقود التي نُشرت عبر Embark أن تظل عاملة على السلسلة؟

نعم، يمكن للعقود المنشورة عبر Embark مواصلة العمل بصورة مستقلة ما دامت شبكتها وشيفرة بايتها متاحتين.

هل يحتاج عقد Embark قائم إلى تشغيل Embark؟

لا، تنفذ البلوكشين عقود EVM المنشورة، ويمكن الوصول إليها بأي واجهة متوافقة باستخدام العنوان وواجهة التطبيق الثنائية الصحيحين.

هل يمكن للفريق الانتقال من Embark من دون نقل عقوده؟

نعم، يمكن للفريق استبدال سير عمل البناء والنشر المحلي ومواصلة التفاعل مع العقود القائمة.

هل تثبيت Embark اليوم آمن؟

ينبغي التثبيت في بيئة معزولة فقط، وبعد مراجعة التبعيات القديمة ومن دون كشف مفاتيح خاصة قيّمة.

هل ينبغي لمشروع عملات مشفرة جديد استخدام Embark؟

ينبغي للمشروع الإنتاجي الجديد عموماً استخدام مكونات تطوير تخضع للصيانة النشطة بدلاً من الاعتماد على مجموعة تبعيات Embark القديمة.

لماذا يحظى Embark بأهمية تاريخية؟

كان أحد الأطر الأولى التي جمعت العقود الذكية وتطوير الواجهات الأمامية والنشر الآلي والاختبار والتخزين والاتصال والأدوات المرئية في سير عمل واحد لتطبيق لامركزي.

الخلاصة

Embark Framework بيئة تطوير قديمة مفتوحة المصدر، أُنشئت لتبسيط تطوير التطبيقات اللامركزية المتكاملة.

أتمت ترجمة Solidity ونشر العقود وإدارة التبعيات وتوليد الملفات وبناء الواجهة الأمامية والاختبار والتفاعل مع البلوكشين.

كما دمجت تقنيات التخزين والاتصال اللامركزية عبر EmbarkJS وبنية قائمة على الإضافات.

جعلت ميزات مثل إعادة النشر الآلية وإدارة البلوكشين المحلي واختبارات JavaScript ووحدة التحكم التفاعلية ولوحة Cockpit منه إطاراً مؤثراً خلال التوسع المبكر لتطبيقات Ethereum.

كان أحدث إصدار مستقر له هو الإصدار 6.0.0 الصادر في 27 أبريل 2020، وتلاه إصداران ليليان في وقت لاحق من ذلك العام.

يعني غياب الإصدارات الحديثة أن تبعياته وتكاملات العُقد ووحدات التخزين وأدوات البناء وافتراضاته بشأن المحافظ قد لا تتوافق مع الأنظمة الحالية.

لا تحتاج العقود القائمة المنشورة عبر Embark إلى الإطار كي تواصل عملها على السلسلة.

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

ينبغي للمطورين الذين يفحصون Embark عزل البيئة وتدقيق التبعيات وحماية المفاتيح الخاصة والتحقق من شيفرة العقود واختبار كل تكامل تاريخي.

يظل Embark مهماً في تاريخ تطوير العملات المشفرة، لكن لا ينبغي اعتباره إطار إنتاج يخضع للصيانة حالياً.