ناقش العلاقة بين مجموعة التحديثات وتطوير التطبيقات: هل يمثل نظام Micro-Rollup المستقبل؟

بقلم: KAUTUK، مطور Stackr

تم تجميعه بواسطة: لوفي، فورسايت نيوز

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

ظهور مجموعات التحديثات الخاصة بالتطبيقات

الإظهار العام أمر محبط

إن Universal Rollup يشبه النظام المدرسي في الهند (أنا متأكد من أن لديهم خصائص مشابهة لأنظمة المدارس الأخرى، لكن لدي خبرة مباشرة به فقط).

يحتاج الرياضيون والمغنون وعلماء الرياضيات والمفكرون والاقتصاديون إلى المرور بنفس العملية للحصول على درجة النجاح. النظام ليس "منحازًا" لأي فئة معينة، ولكنه ليس "عادلاً" للجميع أيضًا. ولكن مهلا، لقد أصبحنا أصدقاء! (هذا وسوف يكون من المهم في وقت لاحق).

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

المجموعات الخاصة بالتطبيقات مربكة

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

من الصعب تصنيف مجموعة البيانات المجمعة بشكل واضح

** هيا نلعب لعبة **

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

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

فهل من العدل تصنيفهما معًا؟

أجوبة التمرين أعلاه:

Group1: Celo هو خيار غريب لأنه يسمح للمطورين الآخرين ببناء تطبيقات يمكن للمطورين الآخرين استخدامها مباشرة. المشاريع الأخرى التي يجب مراعاتها في المجموعة 1 هي Fuel-v1، وAevo، وRhinoFi، وما إلى ذلك.

المجموعة 2: تعد Loopring خيارًا غريبًا لأنها المجموعة الوحيدة المصممة لهذا الغرض والتي تعمل خارج الصندوق، في حين أن الباقي عبارة عن شبكات محسنة لميزات محددة مثل الخصوصية وNFTs وTPS للتطبيقات المنشورة عليها. وارث. المشاريع الأخرى التي يمكن اعتبارها في المجموعة 2 هي Kinto وKroma وPublic Goods Network وما إلى ذلك.

مشاكل في نشر العقود في الأجهزة الافتراضية العامة المعدلة

هذه الأجهزة الافتراضية التي تنشر فيها العقود الذكية ليست أكثر من أجهزة Turing ذات الحالة الكاملة. تعمل العقود التي تنشرها عليها على تعديل الحالة نفسها فقط، ولا تؤثر حقًا على قواعد انتقال الحالة الأساسية للجهاز الافتراضي. إن Rollup هو في الأساس جهاز افتراضي يوجد فوقه منطق عملك.

منطق عملك منفصل عن وظائف انتقال الحالة في مجموعة التحديثات.

أسمي هذا أيضًا "نموذج العقد الذكي لبناء التطبيقات" لأنك تنشر بعض المنطق الإضافي أعلى جهاز افتراضي. لا يهتم الإظهار "بشكل مباشر" بإثبات منطق التطبيق. VM هو التراكمي، وليس التطبيق الخاص بك.

بالطبع، أنت المالك الوحيد للجهاز الظاهري، وتطبيقك هو المواطن الوحيد، ويمكنك تحسين القاعدة نفسها باستمرار لجعلها مناسبة لتطبيقك. يمكنك الاستمرار في تحسين وظيفة انتقال الحالة (STF) وإضافة/إزالة أكواد التشغيل لتحسين أداء التطبيق، ولكن يظل التطبيق مستقلاً ومحدودًا بواسطة الجهاز الظاهري نفسه.

مثل لامبورجيني أوروس تسحب لامبورجيني هوراكان

يمكن لتطبيق منفصل على تطبيق محدد أن يعمل بشكل أفضل. ماذا لو واصلت تعزيز STF بحيث أصبح نطاق STF أصغر فأصغر ليناسب منطق الأعمال الخاص بتطبيقك؟ في نهاية المطاف، عندما تصبح أقوى، سوف تتقارب STF إلى نقطة يتداخل فيها منطق العمل مع STF، وعند هذه النقطة تدرك... أوه، انتظر لحظة!

ولادة تقنية Micro-Rollup

ولذلك، فإن Micro-Rollup ليس أكثر من مجرد مجموعة تراكمية تكون فيها وظيفة انتقال حالة التطبيق هي منطق الأعمال نفسه.

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

Micro-Rollup غير مقيد فيما يتعلق بتجربة المطور. يمكنك بنائها باستخدام أي أدوات تريدها لأنها لا تقتصر على الأجهزة الافتراضية. إنها تبدو مثل تطبيقات الواجهة الخلفية لـ web2، ولكنها تنشر بشكل دوري إثبات المعاملات إلى L1. أعتقد أن هذا سيكون عاملاً رئيسياً في التأثير على مطوري web2 للانتقال إلى مساحة web3.

في الواقع، أفضل مثال هو Rimac Nevera لأنه أسرع وكهربائي، لذا ربما يكون أرخص في التشغيل

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

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

هذه هي مهمة Stackr Labs: نحن نبني إطار عمل Micro-Rollup وSDK حتى يتمكن أي شخص وكل شخص من إنشاء تطبيقاته بأي لغة يريدها دون قيود، تمامًا مثل إنشاء تطبيقات web2 الخلفية، الإجراء هو نفسه. إن جعل تطوير Micro-Rollup سهلاً مثل كتابة العقود الذكية ونشرها، ناهيك عن النمطية، يزيد من قدرة المطورين على اختيار أي نظام بيئي.

إذن، هل تقنية Micro-Rollup حقيقية؟

لقد كان الأمر دائمًا حقيقيًا مثل Rollup نفسه.

تطبيقات مثل Loopring وdYdX وFuel-v1 موجودة بالفعل أو كانت موجودة منذ فترة طويلة. هذه عبارة عن مجموعات مجمعة محسّنة للغاية مع منطق مخصص يعمل خصيصًا لخدمة حالة الاستخدام الخاصة بها. أول مجموعة تطبيقات محددة أعرفها وعملت عليها شخصيًا والتي لا تعتمد على جهاز افتراضي هي Hubble Optimistic Rollup، وهو مشروع عمره 3 سنوات كان في وقت ما بمثابة البنية التحتية الأساسية لرمز Worldcoin.

ومن المهم الآن بشكل متزايد التمييز بين هذه المصطلحات.

حالات استخدام Micro-Rollups لا حصر لها:

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

ختاماً

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

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

لذا، إذا قمنا بتقليم الشجرة، فستبدو الشجرة النهائية بهذا الشكل. ولهذا السبب أعتقد أن App-Rollup أو Micro-Rollup أو RollApp سيتم تسميتها بالتطبيق في المستقبل القريب.