! [تفسير تقنية Dapp Rollup: كيفية جعل التطبيق عالي الإنتاجية سائدا؟] ] (https://cdn-img.panewslab.com//panews/2022/10/20/images/f8bb1f8b126f9f3317749e6564bff7e7.jpg)
يظهر تطبيق Rollup كفائز واضح في توسيع نطاق مجموعة محددة من تطبيقات Ethereum. تستفيد هذه التطبيقات من ضمانات ملكية قوية بدون إذن ، ولكنها لا تتطلب تفاعلا متزامنا بين جميع مستخدمي التطبيق. الألعاب الكاملة على السلسلة هي أفضل مثال. تستفيد الألعاب على السلسلة من الملكية القوية لأصول اللعبة ، مما يسمح بالمشاركة المجهولة في اللعبة والسماح بتعديل مجهول للعبة. ومع ذلك ، لا تتطلب معظم الألعاب تفاعل جميع اللاعبين في نفس الوقت. تشمل التطبيقات الأخرى التي يمكن أن تستفيد من استراتيجية توسيع نطاق Rollup الخاصة بالتطبيق أسواق NFT والتبادلات الدائمة والاستدلال الذكاء الاصطناعي على السلسلة.
! [تفسير تقنية Dapp Rollup: كيفية جعل التطبيق عالي الإنتاجية سائدا؟] ] (https://cdn-img.panewslab.com//panews/2022/10/20/images/f20241526a9e4945c106e2f36e2dc54b.jpg)
مجموعة التطبيقات هي بالفعل التنفيذ المفضل للعديد من حالات الاستخدام هذه. ومع ذلك ، لا يزال تطبيق Rollup القياسي ، EVMRollup ، يحتوي على قيود مهمة على قابلية التوسع. قد تصل إلى إنتاجية تبلغ حوالي 100 معاملة في الثانية. قد يكون معدل النقل هذا كافيا لبعض الألعاب على السلسلة ، اعتمادا على نوع اللعبة. ومع ذلك ، تتطلب معظم الألعاب إنتاجية أعلى لدعم عدد كبير من اللاعبين المتزامنين (أكثر من 1000). تركز هذه المقالة على كيفية توسيع نطاق مجموعة التطبيقات للوصول إلى مئات الآلاف من المشاركين المتزامنين. لكل نهج ، أناقش النوع المناسب من التطبيق / اللعبة والتحديات التي تواجهها.
مقياس أفقيا
قابلية التوسع الأفقي هي أسهل طريقة لتوسيع نطاق مجموعة التطبيقات الخاصة بك. ومع ذلك ، تأتي هذه البساطة على حساب قابلية التركيب ، مما يجعلها مناسبة لمجموعة فرعية صغيرة فقط من التطبيقات ، مثل ألعاب اللاعب الفردي.
تعني قابلية التوسع الأفقي ببساطة نشر مجموعات تطبيقات متعددة (متفائل أو ZK) ونشر نفس العقد الذكي في جميع عمليات التراكم. توجه الواجهة الأمامية للتطبيق المستخدم بسلاسة إلى إحدى المجموعات بناء على السعة أو الموقع أو خيارات التطبيق المحددة. أظهرت Alt Layer مؤخرا هذا المفهوم من خلال إطلاق لعبة FOCG 2048 قابلة للتطوير. في الواجهة الأمامية للعبة ، يمكن للمستخدمين اختيار مجموعة التحديثات للانضمام بناء على موقعهم الجغرافي. نظرا لبساطته وتوافر موفري مجموعة التحديثات كخدمة مثل Caldera ، الذين يتعاملون مع جميع أعمال البنية التحتية المرتبطة بتدوير وإدارة هذه المجموعات ، يمكن لمطوري الألعاب اعتماد هذا النهج بسهولة.
! [تفسير تقنية Dapp Rollup: كيفية جعل التطبيق عالي الإنتاجية سائدا؟] ] (https://cdn-img.panewslab.com//panews/2022/10/20/images/b872ea4023eb627e81fc61022f05f2bc.jpg)
ومع ذلك ، هناك بعض المشاكل في نهج التمديد متعدد التراكمات. المشكلة الأولى هي مفتاح شبكة التراكم. تتطلب المحافظ الحالية، مثل Metamask، موافقة يدوية للاتصال بشبكة جديدة، مثيل الإظهار التراكمي. هذا يخلق تجربة مستخدم صعبة ومربكة للاعبين ، حيث يحتاج اللاعبون إلى الاتصال يدويا ب "شبكات" متعددة للعب نفس اللعبة. لحسن الحظ ، يمكن مسح هذا التعقيد باستخدام حل تجريد الحساب (AA). ومن الأمثلة على ذلك EIP 4337 والمحافظ المضمنة مثل Privy و 0xPass.
التحدي الآخر هو إدارة حالة اللاعب أثناء الانتقالات بين عمليات التراكم. في بعض الحالات، مثل انخفاض السعة، قد يحتاج التطبيق إلى دمج مثيلات مجموعة بيانات متعددة في مثيل واحد للحفاظ على الموارد. في هذه الحالة، يجب ترحيل حالة جميع اللاعبين النشطين إلى المثيل الجديد. يمكن أن تلعب حلول الجسور الحالية ، وخاصة جسور ZK ، دورا رئيسيا في حل هذه المشكلة. باستخدام هذه الحلول، يمكنك ربط حالة لعبة اللاعب بمثيل تراكمي جديد مع الحفاظ على إثبات صحة تلك الحالة. ومع ذلك ، قد لا يكون زمن انتقال حلول التجسير الحالية هو الأمثل لحالات استخدام الألعاب.
قناة حالة ZK
امتداد آخر لمجموعة التطبيقات أكثر ملاءمة للألعاب متعددة اللاعبين ، مثل البوكر ، هو قناة ZK state. في هذه الألعاب ، يحدث تفاعل اللاعب بين عدد صغير من اللاعبين ، مثل 2-10 أشخاص. طريقة اللعب بين هؤلاء اللاعبين مهمة فقط أثناء استمرار اللعبة. ومع ذلك ، فإن النتيجة النهائية للعبة أكثر أهمية لأنها تؤثر على رصيد أصول كل لاعب. لذلك ، من المهم تخزين النتائج في طبقة ثبات مشتركة.
في هذه الحالة، تمثل مجموعة التحديثات طبقة معلومات مشتركة، حيث يتم تخزين نتائج اللعبة وحيث توجد أصول اللعبة أيضا. لكل لعبة على مجموعة التحديثات ، يمكنك بدء قناة حالة ZK لخدمة اللعبة. أثناء اللعب ، يقوم كل لاعب بإنشاء معاملات وإنشاء ZKP ، مما يثبت أنهم اتبعوا قواعد اللعبة. تقوم إثباتات تفاعلات اللاعبين الآخرين بتجميع البرهان السابق باستخدام البراهين المتكررة. عندما تنتهي اللعبة ، يتم تقديم ZKP النهائي إلى التطبيق Rollup لإثبات صحة طريقة اللعب والنتيجة النهائية. تغيير الحالة التي تنتجها اللعبة يغير حالة اللاعب على التطبيق التراكمي.
! [تفسير تقنية Dapp Rollup: كيفية جعل التطبيق عالي الإنتاجية سائدا؟] ] (https://cdn-img.panewslab.com//panews/2022/10/20/images/279d2bd0b1395674a145b42e73523ce3.jpg)
تنقل قناة حالة ZK تفاعلات اللعبة خارج السلسلة. لذلك، لا يتم احتساب النشاط والمعاملات داخل اللعبة ضمن إنتاجية مجموعة التطبيقات. باستخدام هذا النهج ، يمكن لتطبيق Rollup التوسع بشكل كبير لدعم الآلاف من اللاعبين المتزامنين. ستقوم معاملة مجموعة التطبيقات فقط بالتحقق من صحة معاملات ZKP وتحديث الحالة التي تم إنشاؤها بعامل تحجيم من 100-1000x. قامت العديد من الفرق ، بما في ذلك Ontropy ، بتطوير التكنولوجيا.
أحد عيوب هذا النهج هو أنه يتطلب من اللاعبين تشغيل منطق اللعبة على أجهزتهم الخاصة وإنشاء ZKPs. غالبا ما تكون هذه البراهين خفيفة الوزن ويمكن إكمالها في ثوان باستخدام أنظمة إثبات متطورة مثل Halo2. ومع ذلك ، لا يزال من الممكن أن يؤدي ذلك إلى تقليل تجربة اللاعب للأجهزة ذات الموارد المحدودة.
تتمثل إحدى طرق التخفيف من هذه المشكلة في تعيين أحد المشاركين في قناة حالة zk كجهاز تسلسل مؤقت. سيتلقى جهاز التسلسل معاملة كل لاعب وينشئ ZKP المقابل ، ويشارك ZKP مع جميع المشاركين في القناة. يمكن اعتبار هذا التعديل بمثابة تسوية ZK L3 قصيرة الأجل لتطبيق Rollup. نفذ فريق Cartridge هذه البنية من خلال تصميم جهاز تسلسل مخصص يسمى Katana.
نهج قناة الدولة zk لديه إمكانات كبيرة. ومع ذلك ، هناك العديد من المشكلات المفتوحة المتعلقة ببيئة التنفيذ داخل قناة حالة zk وكيفية تحسين الدليل المتكرر. بيئات zkEVM الحالية ليست فعالة ، ومعظمها حاليا لا يدعم تكرار الإثبات. تشمل البدائل zkVM خفيفة الوزن ، أو حتى استخدام دوائر zk المتخصصة للتعامل مع تفاعل اللاعب إذا كان لدى اللاعب عدد محدود من الحركات الممكنة.
تغيير بيئة التنفيذ
هناك طريقة ثالثة لتوسيع مجموعة التطبيقات وهي تغيير بيئة تنفيذ مجموعة التحديثات. على الرغم من نضجها ووفرة أدوات تطوير EVM ، إلا أنها ليست مناسبة للتطبيقات عالية الأداء مثل الألعاب. بالإضافة إلى ذلك، يؤدي نموذج التنفيذ والتخزين أحادي الخيوط في EVM إلى تقليل الإنتاجية، والتي يمكن تحسينها من خلال التحسينات.
الميزة الرئيسية لهذا النهج هي أن زيادة إنتاجية Rollup لا تتطلب التضحية بقابلية التركيب أو الحد من عدد حالات الاستخدام. يمكن استخدام هذا النهج لأي تطبيق Web 3 طالما أن بيئة التنفيذ يمكنها تحقيق الإنتاجية التي يتطلبها التطبيق. وهذا يجعلها الحل الوحيد القابل للتطبيق للتطبيقات التي تحتاج إلى الوصول إلى الحالة المشتركة ، مثل AMMs وبروتوكولات الإقراض وتطبيقات DeFi الأخرى.
**توسيع وظائف EVM مع التجميع المسبق **
أولا ، تحافظ مجموعة التحديثات على توافق EVM وتمرر بعض القيود على معدل نقل العنوان المترجم مسبقا. الفكرة هنا بسيطة. التحويل البرمجي المسبق هو الحركة الهبوطية لعمليات EVM كثيفة الحوسبة إلى مستوى العقدة. يمكن تبسيط العملية التي تتطلب مئات أو آلاف من أكواد عمليات EVM وتستهلك 100,000+ غاز إلى عملية واحدة مع تخفيض 100x في تكاليف الغاز. غالبا ما يشار إلى التحويل البرمجي المسبق الذي يوسع بيئة Rollup باسم EVM +. تتضمن أمثلة هذا النهج دعم الخصوصية على السلسلة ودعم مخططات التوقيع الأكثر كفاءة مثل توقيعات BLS. على سبيل المثال ، يستخدم بوكر zkHoldem عمليات FHE و zk مخصصة لتمكين التعامل والعرض التقديمي للبطاقات الخاصة. عادة ما يكون تطوير هذه التجميعات المسبقة المتخصصة جهدا مشتركا بين مطور مجموعة التطبيقات ومزود Raas الذي يدير نشر وصيانة البنية التحتية لمجموعة التطبيقات.
استخدام بيئة تنفيذ غير EVM
هناك طريقة أخرى لتحسين بيئة تنفيذ Rollup وهي التخلص من EVM. يكتسب هذا النهج شعبية بين المطورين الجدد في نظام Ethereum البيئي ، وكذلك بين المطورين الذين يعتقدون أن Solidity ليست أفضل لغة لتطوير التطبيقات المعقدة.
اليوم ، لدينا تطبيقات تراكمية تعمل على أوقات تشغيل WASM و SVM و Cairo وحتى Linux. تسمح معظم هذه الطرق للمطورين بكتابة عقود ذكية باستخدام لغات عالية المستوى مثل Rust أو C. الجانب السلبي هو أن قابلية التشغيل البيني مع عقود الصلابة الحالية غالبا ما تضيع. ومع ذلك ، لا يزال من الممكن إنشاء التوافق مع EVM. على سبيل المثال ، يستخدم قلم Aributrum معالجا مساعدا لجعل عقد Stylus EVM متوافقا. هذا التصميم يجعل Stylus أقرب إلى بنية EVM + من غير EVM.
! [تفسير تقنية Dapp Rollup: كيفية جعل التطبيق عالي الإنتاجية سائدا؟] ] (https://cdn-img.panewslab.com//panews/2022/10/20/images/be666ff84c513ab1de2a247236a723a2.jpg)
** بيئة تنفيذ مختلطة **
النهج الثالث ، الذي يحظى بشعبية خاصة مع FOGs ، هو أفضل ميزة تجمع بين الأولين. يجمع هذا النهج بين توافق EVM وبيئة تنفيذ مخصصة غير EVM. تركز البيئات غير EVM على التنفيذ عالي الأداء لأوليات اللعبة الأساسية. يمكن التعامل مع إدارة أصول اللعبة ، مثل معاملات NFT داخل اللعبة ، من خلال عقود Solidity القياسية.
تتمثل ميزة هذا النهج في أن توافق EVM يضمن التوافق مع النظام البيئي الأكبر للمطورين والمنتجات الحالية. كما يسمح بالتركيب بدون إذن. يمكن للمطورين تعديل منطق اللعبة وتوسيعه عن طريق إضافة عقود EVM / Solidity الذكية. في الوقت نفسه ، تحقق محركات الألعاب المصممة لهذا الغرض وغير EVM إنتاجية عالية لا تستطيع EVM القيام بها.
ومن الأمثلة على هذا النهج محرك Argus العالمي و Curio's Keystone. يفصل World Engine تنفيذ منطق اللعبة إلى طبقة منفصلة ، تسمى Game Shard ، والتي تعمل أعلى الطبقة المتوافقة مع EVM. تم تصميم Game Shard أيضا للسماح بالقياس الأفقي لضبط إجمالي إنتاجية الإظهار بناء على الطلب. وبالمثل ، تجمع بنية Keystone من Curio محرك ألعاب عالي الإنتاجية مع EVM كبيئة تنفيذ Rollup. يتمثل التحدي هنا في تحقيق قابلية التشغيل البيني السلس بين محركات EVM ومحركات الألعاب.
! [تفسير تقنية Dapp Rollup: كيفية جعل التطبيق عالي الإنتاجية سائدا؟] ] (https://cdn-img.panewslab.com//panews/2022/10/20/images/246295e5b8867825147e0129ef32c4d9.jpg)
اعتبارات توافر البيانات
في المناقشة السابقة ، كان التركيز على زيادة إنتاجية المعاملات التراكمية ، وهو الجانب الرئيسي لتوسيع نطاق التطبيق التراكمي. تشمل الموضوعات الأخرى المتعلقة بهذا الإنتاجية المتزايدة توافر البيانات (DA) ، ولامركزية الطلب ، وسرعة التسوية. بالنسبة إلى مجموعات التطبيقات عالية الإنتاجية ، يعد توفر البيانات هو أكثر هذه المشكلات إلحاحا.
يمكن أن يكون لمجموعة التحديثات لتطبيق واحد معدل نقل يزيد عن 10000 معاملة في الثانية. من المستحيل استخدام Ethereum كطبقة توفر البيانات لهذه المعاملات. أولا ، يمكن أن يتجاوز متوسط تكلفة نشر بيانات نقل L2 ETH البسيطة على L2 0.1 USD. هذه التكاليف مرتفعة للغاية بالنسبة لمعظم مجموعات التطبيقات. علاوة على ذلك ، لا يمكن ل L1 من Ethereum حاليا دعم عمليات التجميع التي تستفيد من L1 لتوافر البيانات مع حوالي 8000 معاملة في الثانية.
ستعتمد مجموعات التطبيقات بشكل أساسي على حلول DA الخارجية. يتم وضع Celestia و EigenDA حاليا كأكثر الخيارات قابلية للتطبيق لتطبيق Rollup. على سبيل المثال ، تخطط Eclipse لاستخدام Celestia كطبقة توفر البيانات لمجموعة SVM الأساسية عالية الإنتاجية. ومن المقرر أيضا أن تستخدم Argus ومحركات الألعاب عالية الإنتاجية Celestia في البداية. وبالمثل ، يعد EigenDA بإنتاجية بيانات تصل إلى 10 ميجابايت في الثانية ويمكنه أيضا توفير حل قابل للتطبيق لعمليات تجميع التطبيقات المتعددة.
ومع ذلك ، فإن العيب الرئيسي لدمج Celestia أو EigneDA هو تسرب القيمة الاقتصادية. يجب أن تدفع مجموعات التطبيقات رسوما لطبقة DA ، بالإضافة إلى رسوم التسوية على Ethereum L1. رسوم التسوية هي مفتاح التطبيق التراكمي لأنه يربط أمان Rollup بأمان Ethereum. ضمانات DA أقل أهمية في سياق FOG حيث تكون قيمة المعاملة أصغر بكثير من هذه الشبكات. بالإضافة إلى ذلك ، تعد Celestia و EigenDA برسوم منخفضة لأن هذه الشبكات تعمل للتو وسيكون الاستخدام منخفضا في البداية. عندما تحقق شبكات DA هذه استخداما عاليا ، يمكن أن تصبح رسوم DA باهظة أيضا. في رأيي ، يجب أن تستخدم مجموعة التطبيقات لوحة توفر البيانات البسيطة (DAC) لإثبات توفر بيانات التراكم.
في الختام ، أعتقد أن مجموعات التطبيقات هي أفضل حل موجود لتوسيع نطاق التطبيقات عالية الإنتاجية ، وخاصة الألعاب على السلسلة بالكامل. يعد توسيع هذه التطبيقات باستخدام Rollup أمرا أساسيا لتحقيق التبني السائد خارج مستخدمي التشفير الأصليين.
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تفسير تقنية Dapp Rollup: كيفية جعل التطبيق عالي الإنتاجية سائدا؟
كتب بواسطة محمد فودة
تجميع: ديب تايد تك فلو
! [تفسير تقنية Dapp Rollup: كيفية جعل التطبيق عالي الإنتاجية سائدا؟] ] (https://cdn-img.panewslab.com//panews/2022/10/20/images/f8bb1f8b126f9f3317749e6564bff7e7.jpg)
يظهر تطبيق Rollup كفائز واضح في توسيع نطاق مجموعة محددة من تطبيقات Ethereum. تستفيد هذه التطبيقات من ضمانات ملكية قوية بدون إذن ، ولكنها لا تتطلب تفاعلا متزامنا بين جميع مستخدمي التطبيق. الألعاب الكاملة على السلسلة هي أفضل مثال. تستفيد الألعاب على السلسلة من الملكية القوية لأصول اللعبة ، مما يسمح بالمشاركة المجهولة في اللعبة والسماح بتعديل مجهول للعبة. ومع ذلك ، لا تتطلب معظم الألعاب تفاعل جميع اللاعبين في نفس الوقت. تشمل التطبيقات الأخرى التي يمكن أن تستفيد من استراتيجية توسيع نطاق Rollup الخاصة بالتطبيق أسواق NFT والتبادلات الدائمة والاستدلال الذكاء الاصطناعي على السلسلة.
! [تفسير تقنية Dapp Rollup: كيفية جعل التطبيق عالي الإنتاجية سائدا؟] ] (https://cdn-img.panewslab.com//panews/2022/10/20/images/f20241526a9e4945c106e2f36e2dc54b.jpg)
مجموعة التطبيقات هي بالفعل التنفيذ المفضل للعديد من حالات الاستخدام هذه. ومع ذلك ، لا يزال تطبيق Rollup القياسي ، EVMRollup ، يحتوي على قيود مهمة على قابلية التوسع. قد تصل إلى إنتاجية تبلغ حوالي 100 معاملة في الثانية. قد يكون معدل النقل هذا كافيا لبعض الألعاب على السلسلة ، اعتمادا على نوع اللعبة. ومع ذلك ، تتطلب معظم الألعاب إنتاجية أعلى لدعم عدد كبير من اللاعبين المتزامنين (أكثر من 1000). تركز هذه المقالة على كيفية توسيع نطاق مجموعة التطبيقات للوصول إلى مئات الآلاف من المشاركين المتزامنين. لكل نهج ، أناقش النوع المناسب من التطبيق / اللعبة والتحديات التي تواجهها.
مقياس أفقيا
قابلية التوسع الأفقي هي أسهل طريقة لتوسيع نطاق مجموعة التطبيقات الخاصة بك. ومع ذلك ، تأتي هذه البساطة على حساب قابلية التركيب ، مما يجعلها مناسبة لمجموعة فرعية صغيرة فقط من التطبيقات ، مثل ألعاب اللاعب الفردي.
تعني قابلية التوسع الأفقي ببساطة نشر مجموعات تطبيقات متعددة (متفائل أو ZK) ونشر نفس العقد الذكي في جميع عمليات التراكم. توجه الواجهة الأمامية للتطبيق المستخدم بسلاسة إلى إحدى المجموعات بناء على السعة أو الموقع أو خيارات التطبيق المحددة. أظهرت Alt Layer مؤخرا هذا المفهوم من خلال إطلاق لعبة FOCG 2048 قابلة للتطوير. في الواجهة الأمامية للعبة ، يمكن للمستخدمين اختيار مجموعة التحديثات للانضمام بناء على موقعهم الجغرافي. نظرا لبساطته وتوافر موفري مجموعة التحديثات كخدمة مثل Caldera ، الذين يتعاملون مع جميع أعمال البنية التحتية المرتبطة بتدوير وإدارة هذه المجموعات ، يمكن لمطوري الألعاب اعتماد هذا النهج بسهولة.
! [تفسير تقنية Dapp Rollup: كيفية جعل التطبيق عالي الإنتاجية سائدا؟] ] (https://cdn-img.panewslab.com//panews/2022/10/20/images/b872ea4023eb627e81fc61022f05f2bc.jpg)
ومع ذلك ، هناك بعض المشاكل في نهج التمديد متعدد التراكمات. المشكلة الأولى هي مفتاح شبكة التراكم. تتطلب المحافظ الحالية، مثل Metamask، موافقة يدوية للاتصال بشبكة جديدة، مثيل الإظهار التراكمي. هذا يخلق تجربة مستخدم صعبة ومربكة للاعبين ، حيث يحتاج اللاعبون إلى الاتصال يدويا ب "شبكات" متعددة للعب نفس اللعبة. لحسن الحظ ، يمكن مسح هذا التعقيد باستخدام حل تجريد الحساب (AA). ومن الأمثلة على ذلك EIP 4337 والمحافظ المضمنة مثل Privy و 0xPass.
التحدي الآخر هو إدارة حالة اللاعب أثناء الانتقالات بين عمليات التراكم. في بعض الحالات، مثل انخفاض السعة، قد يحتاج التطبيق إلى دمج مثيلات مجموعة بيانات متعددة في مثيل واحد للحفاظ على الموارد. في هذه الحالة، يجب ترحيل حالة جميع اللاعبين النشطين إلى المثيل الجديد. يمكن أن تلعب حلول الجسور الحالية ، وخاصة جسور ZK ، دورا رئيسيا في حل هذه المشكلة. باستخدام هذه الحلول، يمكنك ربط حالة لعبة اللاعب بمثيل تراكمي جديد مع الحفاظ على إثبات صحة تلك الحالة. ومع ذلك ، قد لا يكون زمن انتقال حلول التجسير الحالية هو الأمثل لحالات استخدام الألعاب.
قناة حالة ZK
امتداد آخر لمجموعة التطبيقات أكثر ملاءمة للألعاب متعددة اللاعبين ، مثل البوكر ، هو قناة ZK state. في هذه الألعاب ، يحدث تفاعل اللاعب بين عدد صغير من اللاعبين ، مثل 2-10 أشخاص. طريقة اللعب بين هؤلاء اللاعبين مهمة فقط أثناء استمرار اللعبة. ومع ذلك ، فإن النتيجة النهائية للعبة أكثر أهمية لأنها تؤثر على رصيد أصول كل لاعب. لذلك ، من المهم تخزين النتائج في طبقة ثبات مشتركة.
في هذه الحالة، تمثل مجموعة التحديثات طبقة معلومات مشتركة، حيث يتم تخزين نتائج اللعبة وحيث توجد أصول اللعبة أيضا. لكل لعبة على مجموعة التحديثات ، يمكنك بدء قناة حالة ZK لخدمة اللعبة. أثناء اللعب ، يقوم كل لاعب بإنشاء معاملات وإنشاء ZKP ، مما يثبت أنهم اتبعوا قواعد اللعبة. تقوم إثباتات تفاعلات اللاعبين الآخرين بتجميع البرهان السابق باستخدام البراهين المتكررة. عندما تنتهي اللعبة ، يتم تقديم ZKP النهائي إلى التطبيق Rollup لإثبات صحة طريقة اللعب والنتيجة النهائية. تغيير الحالة التي تنتجها اللعبة يغير حالة اللاعب على التطبيق التراكمي.
! [تفسير تقنية Dapp Rollup: كيفية جعل التطبيق عالي الإنتاجية سائدا؟] ] (https://cdn-img.panewslab.com//panews/2022/10/20/images/279d2bd0b1395674a145b42e73523ce3.jpg)
تنقل قناة حالة ZK تفاعلات اللعبة خارج السلسلة. لذلك، لا يتم احتساب النشاط والمعاملات داخل اللعبة ضمن إنتاجية مجموعة التطبيقات. باستخدام هذا النهج ، يمكن لتطبيق Rollup التوسع بشكل كبير لدعم الآلاف من اللاعبين المتزامنين. ستقوم معاملة مجموعة التطبيقات فقط بالتحقق من صحة معاملات ZKP وتحديث الحالة التي تم إنشاؤها بعامل تحجيم من 100-1000x. قامت العديد من الفرق ، بما في ذلك Ontropy ، بتطوير التكنولوجيا.
أحد عيوب هذا النهج هو أنه يتطلب من اللاعبين تشغيل منطق اللعبة على أجهزتهم الخاصة وإنشاء ZKPs. غالبا ما تكون هذه البراهين خفيفة الوزن ويمكن إكمالها في ثوان باستخدام أنظمة إثبات متطورة مثل Halo2. ومع ذلك ، لا يزال من الممكن أن يؤدي ذلك إلى تقليل تجربة اللاعب للأجهزة ذات الموارد المحدودة.
تتمثل إحدى طرق التخفيف من هذه المشكلة في تعيين أحد المشاركين في قناة حالة zk كجهاز تسلسل مؤقت. سيتلقى جهاز التسلسل معاملة كل لاعب وينشئ ZKP المقابل ، ويشارك ZKP مع جميع المشاركين في القناة. يمكن اعتبار هذا التعديل بمثابة تسوية ZK L3 قصيرة الأجل لتطبيق Rollup. نفذ فريق Cartridge هذه البنية من خلال تصميم جهاز تسلسل مخصص يسمى Katana.
نهج قناة الدولة zk لديه إمكانات كبيرة. ومع ذلك ، هناك العديد من المشكلات المفتوحة المتعلقة ببيئة التنفيذ داخل قناة حالة zk وكيفية تحسين الدليل المتكرر. بيئات zkEVM الحالية ليست فعالة ، ومعظمها حاليا لا يدعم تكرار الإثبات. تشمل البدائل zkVM خفيفة الوزن ، أو حتى استخدام دوائر zk المتخصصة للتعامل مع تفاعل اللاعب إذا كان لدى اللاعب عدد محدود من الحركات الممكنة.
تغيير بيئة التنفيذ
هناك طريقة ثالثة لتوسيع مجموعة التطبيقات وهي تغيير بيئة تنفيذ مجموعة التحديثات. على الرغم من نضجها ووفرة أدوات تطوير EVM ، إلا أنها ليست مناسبة للتطبيقات عالية الأداء مثل الألعاب. بالإضافة إلى ذلك، يؤدي نموذج التنفيذ والتخزين أحادي الخيوط في EVM إلى تقليل الإنتاجية، والتي يمكن تحسينها من خلال التحسينات.
الميزة الرئيسية لهذا النهج هي أن زيادة إنتاجية Rollup لا تتطلب التضحية بقابلية التركيب أو الحد من عدد حالات الاستخدام. يمكن استخدام هذا النهج لأي تطبيق Web 3 طالما أن بيئة التنفيذ يمكنها تحقيق الإنتاجية التي يتطلبها التطبيق. وهذا يجعلها الحل الوحيد القابل للتطبيق للتطبيقات التي تحتاج إلى الوصول إلى الحالة المشتركة ، مثل AMMs وبروتوكولات الإقراض وتطبيقات DeFi الأخرى.
**توسيع وظائف EVM مع التجميع المسبق **
أولا ، تحافظ مجموعة التحديثات على توافق EVM وتمرر بعض القيود على معدل نقل العنوان المترجم مسبقا. الفكرة هنا بسيطة. التحويل البرمجي المسبق هو الحركة الهبوطية لعمليات EVM كثيفة الحوسبة إلى مستوى العقدة. يمكن تبسيط العملية التي تتطلب مئات أو آلاف من أكواد عمليات EVM وتستهلك 100,000+ غاز إلى عملية واحدة مع تخفيض 100x في تكاليف الغاز. غالبا ما يشار إلى التحويل البرمجي المسبق الذي يوسع بيئة Rollup باسم EVM +. تتضمن أمثلة هذا النهج دعم الخصوصية على السلسلة ودعم مخططات التوقيع الأكثر كفاءة مثل توقيعات BLS. على سبيل المثال ، يستخدم بوكر zkHoldem عمليات FHE و zk مخصصة لتمكين التعامل والعرض التقديمي للبطاقات الخاصة. عادة ما يكون تطوير هذه التجميعات المسبقة المتخصصة جهدا مشتركا بين مطور مجموعة التطبيقات ومزود Raas الذي يدير نشر وصيانة البنية التحتية لمجموعة التطبيقات.
استخدام بيئة تنفيذ غير EVM
هناك طريقة أخرى لتحسين بيئة تنفيذ Rollup وهي التخلص من EVM. يكتسب هذا النهج شعبية بين المطورين الجدد في نظام Ethereum البيئي ، وكذلك بين المطورين الذين يعتقدون أن Solidity ليست أفضل لغة لتطوير التطبيقات المعقدة.
اليوم ، لدينا تطبيقات تراكمية تعمل على أوقات تشغيل WASM و SVM و Cairo وحتى Linux. تسمح معظم هذه الطرق للمطورين بكتابة عقود ذكية باستخدام لغات عالية المستوى مثل Rust أو C. الجانب السلبي هو أن قابلية التشغيل البيني مع عقود الصلابة الحالية غالبا ما تضيع. ومع ذلك ، لا يزال من الممكن إنشاء التوافق مع EVM. على سبيل المثال ، يستخدم قلم Aributrum معالجا مساعدا لجعل عقد Stylus EVM متوافقا. هذا التصميم يجعل Stylus أقرب إلى بنية EVM + من غير EVM.
! [تفسير تقنية Dapp Rollup: كيفية جعل التطبيق عالي الإنتاجية سائدا؟] ] (https://cdn-img.panewslab.com//panews/2022/10/20/images/be666ff84c513ab1de2a247236a723a2.jpg)
** بيئة تنفيذ مختلطة **
النهج الثالث ، الذي يحظى بشعبية خاصة مع FOGs ، هو أفضل ميزة تجمع بين الأولين. يجمع هذا النهج بين توافق EVM وبيئة تنفيذ مخصصة غير EVM. تركز البيئات غير EVM على التنفيذ عالي الأداء لأوليات اللعبة الأساسية. يمكن التعامل مع إدارة أصول اللعبة ، مثل معاملات NFT داخل اللعبة ، من خلال عقود Solidity القياسية.
تتمثل ميزة هذا النهج في أن توافق EVM يضمن التوافق مع النظام البيئي الأكبر للمطورين والمنتجات الحالية. كما يسمح بالتركيب بدون إذن. يمكن للمطورين تعديل منطق اللعبة وتوسيعه عن طريق إضافة عقود EVM / Solidity الذكية. في الوقت نفسه ، تحقق محركات الألعاب المصممة لهذا الغرض وغير EVM إنتاجية عالية لا تستطيع EVM القيام بها.
ومن الأمثلة على هذا النهج محرك Argus العالمي و Curio's Keystone. يفصل World Engine تنفيذ منطق اللعبة إلى طبقة منفصلة ، تسمى Game Shard ، والتي تعمل أعلى الطبقة المتوافقة مع EVM. تم تصميم Game Shard أيضا للسماح بالقياس الأفقي لضبط إجمالي إنتاجية الإظهار بناء على الطلب. وبالمثل ، تجمع بنية Keystone من Curio محرك ألعاب عالي الإنتاجية مع EVM كبيئة تنفيذ Rollup. يتمثل التحدي هنا في تحقيق قابلية التشغيل البيني السلس بين محركات EVM ومحركات الألعاب.
! [تفسير تقنية Dapp Rollup: كيفية جعل التطبيق عالي الإنتاجية سائدا؟] ] (https://cdn-img.panewslab.com//panews/2022/10/20/images/246295e5b8867825147e0129ef32c4d9.jpg)
اعتبارات توافر البيانات
في المناقشة السابقة ، كان التركيز على زيادة إنتاجية المعاملات التراكمية ، وهو الجانب الرئيسي لتوسيع نطاق التطبيق التراكمي. تشمل الموضوعات الأخرى المتعلقة بهذا الإنتاجية المتزايدة توافر البيانات (DA) ، ولامركزية الطلب ، وسرعة التسوية. بالنسبة إلى مجموعات التطبيقات عالية الإنتاجية ، يعد توفر البيانات هو أكثر هذه المشكلات إلحاحا.
يمكن أن يكون لمجموعة التحديثات لتطبيق واحد معدل نقل يزيد عن 10000 معاملة في الثانية. من المستحيل استخدام Ethereum كطبقة توفر البيانات لهذه المعاملات. أولا ، يمكن أن يتجاوز متوسط تكلفة نشر بيانات نقل L2 ETH البسيطة على L2 0.1 USD. هذه التكاليف مرتفعة للغاية بالنسبة لمعظم مجموعات التطبيقات. علاوة على ذلك ، لا يمكن ل L1 من Ethereum حاليا دعم عمليات التجميع التي تستفيد من L1 لتوافر البيانات مع حوالي 8000 معاملة في الثانية.
ستعتمد مجموعات التطبيقات بشكل أساسي على حلول DA الخارجية. يتم وضع Celestia و EigenDA حاليا كأكثر الخيارات قابلية للتطبيق لتطبيق Rollup. على سبيل المثال ، تخطط Eclipse لاستخدام Celestia كطبقة توفر البيانات لمجموعة SVM الأساسية عالية الإنتاجية. ومن المقرر أيضا أن تستخدم Argus ومحركات الألعاب عالية الإنتاجية Celestia في البداية. وبالمثل ، يعد EigenDA بإنتاجية بيانات تصل إلى 10 ميجابايت في الثانية ويمكنه أيضا توفير حل قابل للتطبيق لعمليات تجميع التطبيقات المتعددة.
ومع ذلك ، فإن العيب الرئيسي لدمج Celestia أو EigneDA هو تسرب القيمة الاقتصادية. يجب أن تدفع مجموعات التطبيقات رسوما لطبقة DA ، بالإضافة إلى رسوم التسوية على Ethereum L1. رسوم التسوية هي مفتاح التطبيق التراكمي لأنه يربط أمان Rollup بأمان Ethereum. ضمانات DA أقل أهمية في سياق FOG حيث تكون قيمة المعاملة أصغر بكثير من هذه الشبكات. بالإضافة إلى ذلك ، تعد Celestia و EigenDA برسوم منخفضة لأن هذه الشبكات تعمل للتو وسيكون الاستخدام منخفضا في البداية. عندما تحقق شبكات DA هذه استخداما عاليا ، يمكن أن تصبح رسوم DA باهظة أيضا. في رأيي ، يجب أن تستخدم مجموعة التطبيقات لوحة توفر البيانات البسيطة (DAC) لإثبات توفر بيانات التراكم.
في الختام ، أعتقد أن مجموعات التطبيقات هي أفضل حل موجود لتوسيع نطاق التطبيقات عالية الإنتاجية ، وخاصة الألعاب على السلسلة بالكامل. يعد توسيع هذه التطبيقات باستخدام Rollup أمرا أساسيا لتحقيق التبني السائد خارج مستخدمي التشفير الأصليين.