كيفية توسيع نطاق مجموعات التطبيقات

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

تعد مجموعات التطبيقات بالفعل التطبيق الأمثل للعديد من حالات الاستخدام هذه. ومع ذلك، لا تزال تطبيقات التجميع القياسية، أي مجموعات EVM، تحتوي على حدود مهمة لقابلية التوسع. من المحتمل أن يتمكنوا من تحقيق إنتاجية تبلغ حوالي 100 معاملة في الثانية. يمكن أن تكون هذه الإنتاجية كافية لبعض الألعاب على السلسلة، اعتمادًا على نوع اللعبة. ومع ذلك، تحتاج معظم الألعاب إلى إنتاجية أعلى بكثير لدعم عدد كبير (> 1000) من اللاعبين المتزامنين. تركز هذه المقالة على أساليب توسيع نطاق مجموعات التطبيقات للوصول إلى مئات الآلاف من المشاركين المتزامنين. بالنسبة لكل نهج، أناقش النوع المناسب من التطبيقات/الألعاب والتحديات التي تواجهها.

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

التحجيم الأفقي

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

تعني قابلية التوسع الأفقية ببساطة نشر مجموعات تطبيقات متعددة (OP أو ZK) بنفس العقد الذكي الذي تم نشره على جميع المجموعات. تقوم الواجهة الأمامية للتطبيق بتوجيه المستخدم بسلاسة إلى إحدى المجموعات اعتمادًا على السعة أو الموقع أو خيارات التطبيق المحددة. أظهرت Alt Layer مؤخرًا هذا المفهوم من خلال إطلاق 2048 FOCG القابل للتطوير. في الواجهة الأمامية للعبة، يتوفر للمستخدم خيار تحديد المجموعة التي سينضم إليها بناءً على موقعه الجغرافي. نظرًا لبساطة وتوافر مزودي خدمة Rolup-as-a-Service مثل Caldera الذين يتعاملون مع جميع أعمال البنية التحتية المتعلقة بتدوير وإدارة هذه المجموعات، يمكن لمطوري الألعاب اعتماد هذا النهج بسهولة.

على الرغم من البساطة، هناك بعض المشكلات في نهج التحجيم متعدد المجموعات. الأول هو تحويل الشبكة التراكمي. تتطلب المحافظ الحالية، مثل Metamask، الموافقة اليدوية للاتصال بشبكة جديدة، أي مثيل التجميع. يؤدي هذا إلى تجربة مستخدم صعبة ومربكة للاعبين الذين يحتاجون إلى الاتصال يدويًا بـ «شبكات» متعددة للعب نفس اللعبة. لحسن الحظ، من الممكن التخلص من هذا التعقيد باستخدام حلول AA. على سبيل المثال، EIP 4337 والمحافظ المضمنة مثل Privy و 0xPass.

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

قنوات ولاية ZK

هناك طريقة أخرى لتوسيع مجموعة التطبيقات الأكثر ملاءمة للألعاب متعددة اللاعبين، على سبيل المثال، لعبة البوكر، وهي قنوات zk state. في هذه الألعاب، تحدث تفاعلات اللاعب بين عدد صغير من اللاعبين، على سبيل المثال، 2-10. اللعب بين هؤلاء اللاعبين مهم فقط أثناء تقدم اللعبة. ومع ذلك، تعتبر النتيجة النهائية للعبة أكثر أهمية لأنها تؤثر على رصيد أصول كل لاعب. وبالتالي، من المهم تخزين النتيجة في طبقة ثابتة مشتركة.

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

تقوم قنوات ZK الحكومية بنقل تفاعلات اللعبة خارج السلسلة. وبالتالي، لا يتم احتساب الأنشطة والمعاملات داخل اللعبة ضمن معدل نقل مجموعة التطبيقات. باستخدام هذا الأسلوب، يمكن توسيع مجموعات التطبيقات بشكل كبير لدعم عشرات أو مئات الآلاف من اللاعبين المتزامنين. ستتمثل معاملات مجموعة التطبيقات فقط في التحقق من ملفات ZKPs التي تم إنشاؤها ومعاملات تحديث الحالة مما يؤدي إلى عامل تحجيم يتراوح بين 100 و 1000x. ركزت فرق متعددة بما في ذلك Ontropy على تطوير هذه التكنولوجيا.

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

التعديل على هذا النهج الذي يمكن أن يخفف من هذه المشكلة هو تعيين أحد المشاركين في قناة zk state كمسلسل مؤقت. سيستلم جهاز التسلسل هذا معاملات كل لاعب ويقوم بإنشاء ملفات ZKP المقابلة ومشاركة ZKP مع جميع المشاركين في القناة. يمكن اعتبار هذا التعديل بمثابة ZK L3s سريعة الزوال تستقر في مجموعة التطبيقات. قام فريق Cartridge بتنفيذ هذه البنية من خلال تصميم جهاز تسلسل متخصص يسمى Katana.

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

تغيير بيئة التنفيذ

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

الميزة الرئيسية لهذا النهج هي أن تحسين معدل نقل المجموعة لا يتطلب التضحية بالتركيب أو تقييد عدد حالات الاستخدام. يمكن أن يعمل هذا الأسلوب مع أي تطبيق Web 3 طالما أن بيئة التنفيذ يمكنها تحقيق الإنتاجية المطلوبة من قبل التطبيق. وهذا يجعلها الحل الوحيد القابل للتطبيق للتطبيقات التي تتطلب الوصول إلى حالة مشتركة مثل AMMs وبروتوكولات الإقراض وتطبيقات DeFi الأخرى.

توسيع وظيفة EVM عبر الترجمة المسبقة

تتمثل الطريقة الأولى في أن تظل المجموعة المجمعة متوافقة مع EVM وتعالج بعض قيود الإنتاجية عبر عمليات التحويل البرمجي المسبقة. الفكرة هنا بسيطة. إن الترجمة المسبقة هي ببساطة نقل عمليات EVM المكلفة حسابيًا إلى مستوى العقدة. يمكن تبسيط العملية التي تتطلب مئات أو آلاف عمليات EVM وتستهلك أكثر من 100 ألف من الغاز في عملية واحدة بتكاليف غاز أقل بمقدار 100 مرة. غالبًا ما يُطلق على توسيع بيئة التجميع باستخدام عمليات التحويل البرمجي المسبق اسم EVM+. تتضمن أمثلة هذا النهج دعم الخصوصية على السلسلة ودعم مخططات التوقيع الأكثر كفاءة، على سبيل المثال، توقيعات BLS. على سبيل المثال، تستخدم لعبة البوكر ZKholdem عمليات FHE و zk المتخصصة لتحقيق التعامل مع بطاقات البوكر الخاصة والكشف عنها. غالبًا ما يكون تطوير هذه المجموعات المسبقة المتخصصة جهدًا مشتركًا بين مطور مجموعة التطبيقات وموفري Raas الذين يديرون نشر وصيانة مجموعات التطبيقات أدناه.

استخدام بيئة تنفيذ غير EVM

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

اليوم لدينا تطبيقات تراكمية تعمل على WASM و SVM و Cairo وحتى أوقات تشغيل Linux. تسمح معظم هذه الأساليب للمطورين بكتابة عقدهم الذكي بلغات عالية المستوى مثل Rust أو C. الجانب السلبي هو أن قابلية التشغيل البيني مع عقود Solidity الحالية غالبًا ما تُفقد. ومع ذلك، لا يزال من الممكن إنشاء التوافق مع EVM. على سبيل المثال، يستخدم قلم Aributrum معالجًا مشتركًا لجعل عقود Stylus متوافقة مع EVM. هذا التصميم يجعل Stylus أقرب إلى بنية EVM+ من غير EVM.

بيئات التنفيذ المختلطة

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

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

ومن الأمثلة على هذا النهج وورلد إنجين من أرغوس وكيستون من كوريو. يفصل World Engine تنفيذ منطق اللعبة إلى طبقة منفصلة تسمى Game Shard تعمل فوق الطبقة المتوافقة مع EVM. تم تصميم Game Shard أيضًا للسماح بالتحجيم الأفقي لضبط إجمالي إنتاجية التجميع بناءً على الطلب. وبالمثل، تجمع بنية Keystone من Curio بين محرك ألعاب عالي الإنتاجية مع EVM كبيئة تنفيذ مجمعة. يتمثل التحدي هنا في تحقيق قابلية التشغيل البيني السلس بين محرك EVM ومحرك اللعبة.

اعتبارات توفر البيانات

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

يمكن أن تحقق مجموعة تطبيقات واحدة إنتاجية تتجاوز 10 آلاف نقطة في الثانية. لا يمكن استخدام Ethereum كطبقة DA لهذه المعاملات. أولاً، يمكن أن يتجاوز متوسط تكلفة نشر بيانات تحويل L2 ETH البسيط على L1 0.10 دولارًا. هذه التكاليف مرتفعة جدًا بالنسبة لمعظم مجموعات التطبيقات. والأهم من ذلك، لا يمكن لـ L1 من Ethereum حاليًا دعم أكثر من 8k TPS تقريبًا [1] للمجموعات التي تستخدم L1 لـ DA.

ستعتمد مجموعات التطبيقات بشكل أساسي على حلول DA الخارجية. يتم وضع Celestia و eiGenda حاليًا كخيار أكثر قابلية للتطبيق لمجموعات التطبيقات. على سبيل المثال، تخطط Eclipse لاستخدام Celestia في مجموعتها عالية الإنتاجية المستندة إلى SVM. تخطط Argus ومحركات الألعاب عالية الإنتاجية أيضًا مبدئيًا لاستخدام Celestia في البداية. وبالمثل، يمكن أن تكون eiGenda التي تعد بإنتاجية بيانات تصل إلى 10 ميجابايت/ثانية حلاً قابلاً للتطبيق لمجموعات التطبيقات المتعددة.

ومع ذلك، فإن دمج Celestia أو EignedA له العيب الرئيسي المتمثل في تسرب القيمة الاقتصادية. يجب أن تدفع مجموعة التطبيقات رسومًا لطبقة DA بالإضافة إلى رسوم التسوية على Ethereum L1. تُعد رسوم التسوية أمرًا بالغ الأهمية لمجموعة التطبيقات لأنها تعمل على مواءمة أمان المجموعة مع أمان إيثريوم. تعتبر ضمانات DA أقل أهمية خاصة في سياق FOGs حيث تكون قيم المعاملات أصغر بكثير. علاوة على ذلك، تعد Celestia و eiGenda برسوم منخفضة لأن هذه الشبكات جديدة وستكون منخفضة الاستخدام في البداية. عندما تحقق شبكات DA هذه استخدامًا عاليًا، يمكن أن تصبح رسوم DA مفرطة أيضًا. في رأيي، يجب أن تستخدم مجموعات التطبيقات بدلاً من ذلك لجنة بسيطة لتوافر البيانات (DAC) لإثبات توفر بيانات المجموعة[3].

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

أود أن أشكر مات كاتز وكيفن تشانغ وتارينس فان آس ولاري ليو على ملاحظاتهم القيمة على هذه المقالة.

[1] يفترض أن 50٪ من حد غاز الكتلة الخاص بـ Ethereum سيكون فقط لتخزين البيانات باستخدام بيانات الاتصال، بمتوسط 10 بايت لحجم tx. أوقات الحظر لمدة 12 ثانية

إخلاء المسؤولية：

1. تمت إعادة طباعة هذه المقالة من [Alliance]. جميع حقوق التأليف والنشر تعود للمؤلف الأصلي [محمد فودة]. إذا كانت هناك اعتراضات على إعادة الطبع هذه، فيرجى الاتصال بفريق Gate Learn ، وسيتعاملون معها على الفور.
2. إخلاء المسؤولية: الآراء ووجهات النظر الواردة في هذه المقالة هي فقط آراء المؤلف ولا تشكل أي نصيحة استثمارية.
3. يقوم فريق Gate Learn بترجمة المقالة إلى لغات أخرى. ما لم يُذكر ذلك، يُحظر نسخ المقالات المترجمة أو توزيعها أو سرقتها.