مقدمه للموضوع

دعونا نواجه الأمر: تطوير blockchain لا يزال صعبًا ومحدودًا في مرحلته الحالية. وعلى الرغم من صحة أن مجتمع blockchain قد بذل قدرًا هائلاً من الطاقة والجهود لمعالجة بعض هذه المشكلات ، إلا أن عددًا منها ظل دون معالجة إلى حد كبير حتى الآن.
بالنسبة للمبتدئين ، نظرًا للقيود المتأصلة في تقنيات blockchain الحالية ، لا تزال التطبيقات اللامركزية في العالم الحقيقي أو DApps محدودة للغاية من حيث التعقيد.
إن عدم القدرة على المرور عبر عمليه متكرره عدة مرات ، أو إجراء عمليات سلسلة ، أو ببساطة استخدام قاعدة بيانات ، هي قيود ترهق أي مطور يجرؤ على المغامرة في عالم blockchain.
علاوة على ذلك ، عند مقارنتها بما تتمتع به صناعة البرمجيات السائدة ، فإن التكنولوجيا والأدوات المتاحة لبناء DApps كلها جديدة وغير ناضجة نسبيًا ، حتى بالنسبة للنظام البيئي Ethereum.
من الناحية العملية ، كل هذا يعني أن هناك عائقًا كبيرًا أمام دخول الغالبية العظمى من المطورين هناك ، مما يعيق بشدة نمو واعتماد تقنية blockchain بشكل عام.
في Cartesi ، نعتقد أن إنشاء تطبيقات لامركزية يجب ألا يختلف كثيرًا عن إنشاء تطبيقات سطح المكتب أو الويب أو الأجهزة المحمولة.
في هذه المقالة ، نوضح كيف يمكن لـ Cartesi Rollups تحقيق هذه الرؤية ، مما يتيح للمطورين الوصول إلى نظام تشغيل كامل على blockchain لأول مرة ، إلى جانب المرونة في استخدام حزم البرامج والأدوات التي يختارونها.

الخلفية التكنولوجية لشركه كارتيزي.

كما تم وصفه في الأصل في مقالة
Erick de Moura "Cartesi Rollups -
هيىعقود ذكية قابلة للتطوير تم إنشاؤها باستخدام حزم البرامج السائدة" ، فإن Cartesi Rollups عبارة عن إطار عمل من الطبقة الثانية يمكن من خلاله تطوير منطق التطبيق فوق نظام تشغيل فعلي مثل Linux ، ولكن لا يزال متكامل مع blockchain من الطبقة الأولى ومضمون بواسطته.
خلال العام الماضي ، عملنا في Cartesi بجد لتنفيذ هذا الإطار.
لقد أصدرنا العديد من المقالات التي تصف أجزائها ، وتشرح أسباب قرارات التصميم التي اتخذناها وتوضح كيف يعمل كل شيء معًا.
يمكنك التحقق من هؤلاء لتفهم بالتفصيل كيف تم تنفيذ عقودنا الذكية على السلسلة وكذلك كيفية عمل عقد Layer-2 خارج السلسلة ، والتي تستفيد من RISC-V Cartesi Machine للسماح بتنفيذ الحوسبة القابلة للتحقق فوقها لينكس.
الآن ، يسعدنا أن نعلن أن إصدار ألفا من الحل بأكمله قد تم طرحه علنًا وأننا وصلنا إلى النقطة التي تحقق فيها حلمنا: وهي تمكين أي شخص من تطوير التطبيقات اللامركزية ذات التعقيد العشوائي ، باستخدام أدوات التطوير السائدة و مكدسات البرامج ، وكلها موجودة على رأس شبكات blockchain القائمة مثل Ethereum أو Polygon أو Avalanche أو Binance Smart Chain.

الهندسة المعمارية لي Cartesi DApp

بشكل عام ، من وجهة نظر المطور ، يتكون Cartesi DApp من جزأين رئيسيين:
▪️واجهة أمامية ونهاية خلفية▪️
بالاقتراض من المصطلحات السائدة المألوفة ، تتوافق الواجهة الأمامية مع الواجهة التي تواجه المستخدم ، والتي غالبًا ما توفر واجهة المستخدم الرسومية (على سبيل المثال ، تطبيق ويب) ولكنها قد تكون أيضًا مجرد واجهة سطر أوامر (على سبيل المثال ، مهمة Hardhat باستخدام الإيثرات. js ، أو أداة سطر أوامر مكتوبة بلغة Python).
من ناحية أخرى ، تحتوي الواجهة الخلفية لـ Cartesi DApp على منطق الأعمال الخاص بالتطبيق ، على غرار الأنظمة التقليدية التي يمكن تشغيلها داخل الخادم. الاختلاف هنا - وسبب استخدام تقنية blockchain بشكل عام - هو أنه بالنسبة للتطبيقات اللامركزية ، هناك حاجة إلى أن يكون منطق النهاية الخلفية هذا قابلاً للتحقق وبالتالي لا يثق به.
على هذا النحو ، يتم تنفيذه داخل Cartesi Rollups ، الذي يخزن حالة التطبيق ويحدّثها عند استلام مدخلات المستخدم ، مما ينتج عنه مخرجات مقابلة.
يمكن أن تأتي هذه المخرجات في شكل قسائم (معاملات يمكن إجراؤها على الطبقة 1 ، مثل نقل الأصول) وإشعارات (بيانات إعلامية ، مثل النتيجة الناتجة من اللعبة).
من الناحية العملية ، يمكن اعتبار الواجهة الخلفية لـ Cartesi DApp بمثابة عقد ذكي ، ولكن على المنشطات.
بصرف النظر عن هذين المكونين الرئيسيين ، يمكن للواجهة الأمامية لـ DApp بالطبع الاستفادة من الموارد الخارجية مثل خدمات الجهات الخارجية. في الواقع ، بالنسبة إلى DApps الأكثر تعقيدًا ، من المتوقع أن يكون هناك أطراف خلفية أخرى إلى جانب تلك التي تعمل داخل Cartesi Rollups.
يمكن استخدامها عندما لا يحتاج التطبيق حقًا إلى خدمة لا مركزية وقابلة للتحقق ، مثل توفير مخابئ بيانات سريعة ويمكن الوصول إليها ، أو مساعدة المستخدمين على التواصل مع بعضهم البعض ، أو التفاعل مع خدمات أخرى غير blockchain.
عند مقارنتها بتطوير البرامج التقليدية ، فإن الاختلاف الرئيسي في Cartesi DApp هو أن النهاية الخلفية يتم نشرها على شبكة لامركزية من عقد Layer-2 ، والتي تتحقق باستمرار من صحة جميع نتائج المعالجة.
نتيجة لذلك ، لا تتواصل الواجهة الأمامية والخلفية مباشرة مع بعضها البعض. بدلاً من ذلك ، ترسل الواجهة الأمامية مدخلات إلى إطار عمل Cartesi Rollups ، والذي بدوره يجعلها متاحة لمثيلات النهاية الخلفية التي تعمل داخل كل عقدة. بعد معالجة المدخلات من خلال منطق النهاية الخلفية ، يتم إبلاغ المخرجات المقابلة مرة أخرى إلى إطار Rollups ، الذي يفرض صحتها قبل إتاحتها للواجهة الأمامية وأي أطراف أخرى معنية.
يوضح الرسم البياني أدناه كيفية عمل كل هذا من وجهة نظر المطور:

هنا ، تمثل المربعات الخضراء الأجزاء التي يحتاج المطور إلى تنفيذها لبناء DApp ، بينما تتوافق الأجزاء باللون الأرجواني مع إطار عمل Rollups العام الذي توفره Cartesi. يتضمن هذا الإطار كلاً من blockchain الأساسي Layer-1 ، مع نشر عقود Cartesi Rollups الذكية ، وعقد Layer-2 خارج السلسلة.

واجهة برمجة تطبيقات HTTP

كما يتضح من الشكل المعماري أعلاه ، في Cartesi DApp ،
تتواصل الأجزاء الأمامية (Front-end) والأجزاء الخلفية (Back-end) للتطبيق مع بعضها البعض من خلال إطار عمل Cartesi Rollups.
عند تصميم واجهة برمجة التطبيقات (API) لهذا الاتصال مع إطار العمل ، أردنا التأكد من قدرة المطورين على إنشاء تطبيقاتهم دون الحاجة إلى القلق كثيرًا بشأن خصوصيات تقنية blockchain أو حل التجميع لدينا. على وجه الخصوص ، أردنا السماح للكود الخلفي بالتجريد بعيدًا عما إذا كان يعمل داخل جهاز افتراضي معين أم لا.
مع وضع ذلك في الاعتبار ، قررنا تقديم واجهة برمجة تطبيقات HTTP كطبقة ملائمة لهذا الاتصال ، والاستفادة من معيار معروف وواسع الانتشار بدلاً من جعل التطبيقات تتعامل مع أي أجهزة على مستوى النواة أو أجهزة خاصة بـ VM ، أو الاضطرار إلى فهم كيفية عملنا.

لمقاله القادمه سنعرفكم تفاصيل الاجزاء الأماميه (Front-end) و الأجزاء الخلفيه (Back-end) الخاصه ب Cartesi DApp.