كيفية استخدام OPStack لبناء دورة الساعة للعبة السلسلة الكاملة؟

المؤلف: Gametaverse

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

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

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

طورtherealbytes سلسلة تجزئة لإثبات المفهوم (سلسلة مع دورات ساعة) استنادًا إلى OP Stack ، الذي يدير تنفيذًا آليًا للعلامة التجارية لـ Conway's Game of Life ، دعنا نرى كيف قام بتنفيذه.

للإبقاء على الترجمة بسيطة ، نترجم حرفياً علامة التجزئة إلى "علامة" ، والتي تعني "دورة الساعة الدورية".

Ticking-Optimism هو تطبيق لإثبات صحة مفهوم "Ticking Blockchain" استنادًا إلى بنية مجموعة التفاؤل الأساسية.

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

كيفية تحقيق

تقدم بنية التجميع المعيارية الجديدة في Optimism ، Optimism Bedrock ، نوع معاملة جديد يسمى "معاملة الإيداع". على عكس المعاملات العادية ، معاملات الإيداع:

• كتل من الطبقة 1.

• لا يلزم التحقق من التوقيع.

• شراء غاز L2 على L1 ، لذلك فإن غاز L2 غير قابل للاسترداد.

في Bedrock الأصلي ، تم استخدام معاملات الإيداع لأمرين:

• تنفيذ المعاملات المرسلة مباشرة إلى L1.

• قم بتعيين خصائص L1 (الرقم ، الطابع الزمني ، التجزئة ، إلخ) لعقود L2 التي تم نشرها مسبقًا في كل كتلة.

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

يقوم Ticking-Optimism بتعديل عقدة التجميع وينشئ أيضًا "معاملة التجزئة" التي تعمل بنفس الطريقة ، ولكن بدلاً من تعيين خاصية L1 ، فإنها تستدعي وظيفة tick () في العقد المنشور مسبقًا إلى العنوان 0x42000000000000000000000000000000000000A0. يمكن لهذا العقد استدعاء عقد آخر من خلال تحديد المتغير المستهدف.

تحفيز

لتوضيح قوة سلاسل التجزئة ، تخيل لعبة على blockchain حيث يتحرك العديد من الشخصيات غير القابلة للعب (شخصيات غير لاعبين) حول الخريطة. بدون سلسلة علامات ، لدينا طريقتان رئيسيتان للتصميم:

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

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

باستخدام tickchain ، يشبه الحل وضع التجزئة اليدوي ، لكن عقد التجزئة يستدعي وظيفة التحديث تلقائيًا بدلاً من يدويًا.

مزايا استخدام "العلامة التلقائية" لسلسلة التجزئة بدلاً من العلامات اليدوية هي:

• التحديثات مضمونة بالاتفاق.

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

• تحديث معاملات عدم المشاركة في سوق الغاز العادي.

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

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

على الرغم من هذه العيوب الضخمة ، تعتبر العلامات التلقائية أكثر ملاءمة من التحديثات البطيئة لأنواع معينة من التطبيقات.

1. تكون الحالة دائمًا متصلة بشكل صريح ومحدّثة

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

الحالة (في المثال أعلاه ، موقع NPC) يمكن قراءتها دائمًا على السلسلة بتكلفة غاز ثابتة ومنخفضة نسبيًا. لكن تكلفة حساب الحالة الحالية ستزداد مع زيادة عدد الكتل منذ التحديث الأخير ، وستزيد تكلفة الغاز أكثر.

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

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

2. وظائف مختلفة للعملاء

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

3. الشفرة أبسط وأسهل في المراجعة

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

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

4. لا يدفع المستخدمون تكلفة التحديث

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

عرض لعبة الحياة كونواي

لقد أنشأت عرضًا تجريبيًا لـ tickchain يدير نسخة تفاعلية من Conway's Game of Life. تم تعديل السلسلة لتتضمن منطقًا آليًا خلويًا في محرك التنفيذ ، مما يجعلها أكثر كفاءة ، مما يسمح بلوحة ألعاب أكبر مما يمكن تنفيذه كرمز ثنائي للعقد الذكي.

الكود المصدري للعرض التوضيحي:

فيديو تجريبي: