أعلن فريق Lattice مؤخرًا عن Redstone - تم تصميم L2 الجديد باستخدام مساهمته الجديدة في OP Stack (المكدس الذي يدعم Optimism L2).

لذلك فإن السؤال الذي يدور في أذهان الجميع هو «هل يجب بناء ألعاب onchain على هذا L2، وكيف يمكن مقارنتها بالبدائل؟». لقد تواصل الكثيرون مع فريقنا في Paima Studios للحصول على رأينا نظرًا لأننا أحد أفضل صانعي ألعاب onchain حيث توجد ألعاب مباشرة على سلاسل متعددة، ولذا سنبذل قصارى جهدنا للتعمق في الفروق الدقيقة.

ملاحظة

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

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

حيث بدأ كل شيء​

هل تريد بناء لعبة onchain؟ نظرًا لأن ريدستون هو إيثريوم L2، سنفترض أنك قد قررت بالفعل الاستفادة من إيثريوم.

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

التجميعات كحل للتحجيم​

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

1. مجموعات متفائلة: قم بتشغيل الحساب خارج السلسلة، ثم قم بتخزين جميع البيانات المطلوبة لتنفيذ الوظيفة (بيانات فقط، بدون تنفيذ) جنبًا إلى جنب مع القيمة المحسوبة محليًا للنتيجة. قم بتشغيل التنفيذ فعليًا فقط إذا اعتقد شخص ما أن النتيجة التي نشرتها غير صحيحة («إثبات الاحتيال»). \
   أمثلة شائعة: التحكيم والتفاؤل
2. مجموعات ZK: قم بتشغيل الحساب خارج السلسلة، ثم قم بتخزين جميع البيانات المطلوبة لتنفيذ الوظيفة (فقط البيانات، بدون تنفيذ) جنبًا إلى جنب مع إثبات ZK المحسوب محليًا للنتيجة. \
   أمثلة شائعة: زد كيه سينك، ستاركنيت، بوليجون زيفيم
3. التجميع السيادي: قم بتشغيل الحساب خارج السلسلة، ثم قم بتخزين جميع البيانات المطلوبة لتنفيذ الوظيفة (بيانات فقط، بدون تنفيذ). \
   أمثلة شائعة: رولكيت، محرك بايما

تؤدي الاستفادة من هذه الحلول إلى خفض تكلفة المعاملة الخاصة بلعبتك إلى حوالي 0.05 دولار (انظر l2fees للحصول على القيم المحدثة)، وهي بالتأكيد خطوة كبيرة في الاتجاه الصحيح.

تقليل تكلفة L2s​

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

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

يأتي EIP4844 مع بعض الجوانب السلبية على الرغم من ذلك:

• البيانات مؤقتة فقط (ستحتاج إلى إيجاد حل تخزين آخر لإبقائها مستضافة بعد ذلك)
• البيانات محدودة، ويبلغ الحد الأقصى لها حوالي 2 ميغابايت لكل كتلة (مشتركة بين جميع المجموعات على Ethereum)

لذلك، كما ترون، على الرغم من الجهود المبذولة لخفض التكاليف، إلا أنها لن تكون كافية لجعل ألعاب onchain مجدية على L2 نظرًا للنمو المستمر في الاهتمام بمجال بلوكتشين (سرعة التبني أسرع من سرعة الابتكار التقني)

البديل #1: تخزين البيانات على خادم مركزي (أو مجموعة من الخوادم)​

أحد البدائل للحفاظ على انخفاض التكلفة هو ببساطة تخزين البيانات في خادم مركزي يثق الناس في تشغيله، ونشر تجزئة البيانات فقط على السلسلة. يتمثل أحد أشكال هذه الأفكار في استخدام مجموعة من الآلات التي تعمل بشكل مستقل والمجمعة كوحدة متعددة. يُطلق على هذا المخطط اسم «لجنة توافر البيانات» (DAC) وهذا ما تستخدمه Arbitrum Nova و Arbitrum Orbit و Polygon CDK.

هذه المخططات أرخص بكثير (0.001 دولار/tx لـ Arbitrum Nova إذا تجاهلت سوق الرسوم) مقابل أن تكون الشبكة أكثر مركزية. يتمثل الخطر الرئيسي في أنه إذا توقفت DAC عن استضافة البيانات (على سبيل المثال: تقوم بنشر تجزئة ولا تشارك البيانات الخاصة بهذا الهاش أبدًا)، فإن الشبكة تتوقف.

ملاحظة خاصة حول Arbitrum​

قد تشعر بالفضول حول سبب ظهور Arbitrum مرتين في القائمة. تقدم Arbitrum 3 عروض رئيسية في الوقت الحالي:

• Arbitrum One (شبكة Arbitrum الرئيسية وهي عبارة عن مجموعة كاملة من البيانات على Ethereum)
• أربيتروم نوفا (L2 يستخدم DAC)
• أربيتروم أوربت (مكدس لإنشاء L3s لـ Arbitrum One)

كما ترى، تكمن مشكلة Nova في أنه لا توجد طريقة جيدة للاستفادة من DeFi في لعبتك (سيتعين على المستخدمين الذهاب إلى (Nova - > ETH L1 - > One) وإنفاق الكثير على الغاز لمجرد الجسر)، في حين أن مكدس Orbit الجديد يسمح لك بالانتقال بسهولة (Orbit - > One). بالإضافة إلى ذلك، نظرًا لأن Orbit عبارة عن مكدس لإنشاء L3s، فيمكنك استخدام L3 موجود مثل Xai Games الذي يشغل DAC الخاص به، أو تدوير L3 الخاص بك (على الرغم من أنه إذا كان لديك L3 خاص باللعبة والذي يكون اتصاله الوحيد بـ Ethereum هو نشر التجزئات من حين لآخر، فقد تكون أفضل حالًا مع web2.5)

البديل #2: تخزين البيانات في شبكة لامركزية أخرى​

بدلاً من انتظار تنفيذ EIP4844 بنطاق ترددي محدود في الشبكة الرئيسية، قررت مشاريع أخرى مثل Celestia و Avail و eiGenda تنفيذ مفهوم مماثل كسلسلة منفصلة (تسمى طبقة توفر البيانات («DA»)، ومن خلال التركيز فقط على حالة الاستخدام هذه، فإنها توفر حدود بيانات أعلى من خطط شبكة إيثريوم الرئيسية لدعمها أيضًا. لا تدعم هذه المنصات العقود الذكية، بل يُقصد بها استخدامها فقط كطبقة بيانات لـ L2s.

والجدير بالذكر أنه من الممكن إنشاء مكدس OP مع بيانات عن Celestia بالإضافة إلى Arbitrum Orbit مع بيانات عن Celestia أيضًا. يأتي هذا مع بعض المقايضات:

1. الثقة. تعتمد مجموعتك الآن على طبقة DA للأمان فوق Ethereum (ولكن يمكن القول إنها أفضل من DAC)
2. التكلفة. تحتاج المجموعة الخاصة بك الآن إلى الدفع لشبكة DA مقابل أمانها (الذي يتعين عليك دفعه بالرمز الأصلي لطبقة DA)
3. السرعة. أوقات كتلة سيليستيا هي 15 ثانية، وأوقات كتل Avail هي 20 ثانية. على سبيل المثال، يجب أن تستقر البيانات على Celestia قبل أن يتم ربطها بـ EVM من خلال عقد blobstream الخاص بـ Celestia. ومع ذلك، خذ هذه النقطة ببعض التحفظ، حيث أن جميع L2 بشكل عام تحاكي أوقات الكتل بشكل أسرع مما يمكن أن توفره Ethereum حقًا (نظرًا لأن أوقات حظر Ethereum هي 15 ثانية فقط على الرغم من استخدام Arbitrum لوقت الكتلة بشكل أسرع من هذا).

يتم استخدام هذا النوع من الإعداد بشكل ملحوظ من قبل مانتل (OP Stack + EigenLayer DA) ومانتا باسيفيك (OP Stack + Celestia). لا يزال يتعين رؤية تكلفة ذلك، لكن فريق Celestia يطالب بحوالي 0.001 دولار، مما يعني أن تكلفة التخزين على طبقة DA (بالنسبة إلى تكلفة التنفيذ من سوق الرسوم على جانب EVM) ضئيلة.

البديل #3: قم بتخزين البيانات في DAC التي يمكن تحديها​

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

للمساعدة في فهم معنى ذلك، دعنا نراجع كيفية عمل بروتوكول DAC:

كيفية كتابة البيانات​

1. يتلقى جهاز التسلسل لـ Redstone معاملتك
2. يرسل جهاز التسلسل البيانات إلى DAC ليتم تخزينها
3. تقوم DAC بإرجاع إقرار بأن البيانات مخزنة
4. يقوم جهاز التسلسل بنشر تجزئة البيانات إلى L1

كيفية قراءة البيانات​

1. قم بمزامنة سلسلة Ethereum بحثًا عن التجزئات التي تم تقديمها إلى عقد التجميع
2. استعلم عن بيانات التجزئة من DAC
3. احسب حالة L2 بناءً على هذه البيانات

إذن ما الذي يغيره ريدستون؟​

عند قراءة البيانات، إذا لم تكن البيانات متاحة، يمكنك تحدي DAC من خلال الادعاء بأنها لم تجعل البيانات متاحة (ويعرف أيضًا أن البيانات غير قابلة للتنزيل من الخادم الخاص بها).

لتحفيز الجميع بشكل صحيح على أن يكونوا صادقين، قمنا بإعداد قواعد القطع التالية:

1. إذا كان المنافس غير أمين (كانت البيانات متاحة بالفعل)، فسيتم خفضه (وإلا، يمكنك مهاجمة الشبكة ماليًا من خلال تحدي كل كتلة)
2. إذا كانت DCA غير شريفة (البيانات غير متوفرة)، فسيتم خفضها.

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

1. يقوم Sequencer بنشر تجزئة دون مشاركة البيانات الحقيقية
2. شخص ما يتحدى المنظم
3. المُسلِس، الذي يرى التحدي، ويجعل البيانات متاحة

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

إذا كان الحل الخاص بك لهذه المشكلة هو افتراض أن منظم التسلسل لن يكذب أبدًا لمجرد لعبة، فلماذا لا تستخدم DAC القياسي بدلاً من ذلك. بالإضافة إلى ذلك، فإن افتراض أن منظم التسلسل صادق لا يتوافق جيدًا مع مفهوم جهاز التسلسل المشترك «superchain»، مما يعني أن الأصول لا يمكنها استخدام جهاز التسلسل المشترك ليتم نقله بين سلاسل OP Stack (لذلك تواجه نفس المشكلة مثل Arbitrum Nova ما لم يتم نشر Redstone كـ L3)

ستكون الطريقة التي يخطط بها فريق Lattice للتعامل مع هذا هي النقطة الرئيسية التي يجب البحث عنها مع توفر المزيد من الوثائق ومعلومات خارطة الطريق.

البديل #4: استخدم ZK​

لاحظ أن مشكلة عدم مشاركة البيانات (هجمات حجب البيانات) التي تؤثر على Redstone لا تقتصر على المجموعات المتفائلة. تعاني ZK Rollups التي يتم تخزين بياناتها خارج السلسلة (تسمى «Validiums») من نفس المشكلة، وهذا هو سبب اهتمام الناس عمومًا بالتراميات (التي تنشر جميع البيانات إلى سلسلة).

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

كيف يمكنني خفض تكاليف لعبتي إذا كانت Solidity نفسها هي المشكلة؟ ​

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

يسمح Paima Engine بإنشاء أجهزة الحالة الخاصة بالتطبيق في Javascript والتي يمكنك نشرها في أي سلسلة EVM من اختيارك (بما في ذلك Redstone!). يمكن لهذه المجموعات السيادية الوصول إلى معلومات EVM (بما في ذلك بيانات محرك MUD)، وبالتالي يمكن أن تكون بمثابة طريقة رائعة لجعل أي جزء من لعبتك يعمل بشكل أسرع وأرخص.

الخاتمة​

في الختام، يعد خفض تكلفة البيانات الخطوة الأكثر أهمية لخفض تكاليف ألعاب onchain. هناك العديد من الحلول الحالية المختلفة ذات المقايضات المختلفة الموجودة اليوم، وتصور Redstone نفسها على أنها أكثر أمانًا من DAC القياسي، ولكن يبقى أن نرى ما إذا كانت أكثر أمانًا بشكل هادف، وما إذا كان الفرق ذا مغزى بما يكفي ليكون بديلاً قابلاً للتطبيق للحلول المدعومة بطبقة DA. بالنسبة للمشاريع التي تحتاج إلى توسيع نطاق الحساب فوق البيانات، توجد حلول مثل Paima Engine لمعالجة المشكلة.

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

استوديوهات بايما​

تعد Paima Studios، التي تأسست في أبريل 2022، المطورين الأساسيين لمحرك Paima: محرك Web3 تم إنشاؤه باستخدام تقنية الطبقة الثانية الجديدة التي تسمح ببناء ألعاب على السلسلة وألعاب وعوالم مستقلة. يعد Paima Engine طريقة آمنة وسهلة للدخول إلى Web3 حيث يمكن استخدامه مع مهارات Web2 ولا يعرض المستخدمين أو المطورين لمخاطر واختراقات Web3 الشائعة.

• قاعدة بيانات محرك بيما: https://github.com/PaimaStudios/paima-engine
• وثائق بيما: https://docs.paimastudios.com/
• قالب بيما: https://github.com/PaimaStudios/paima-game-templates
• حزمة بايما NPM: < a href= " https://www.npmjs.com/package/@paima/sdk " " > https://www.npmjs.com/package/@paima/sdk

يمكنك أيضًا معرفة المزيد من وسائل التواصل الاجتماعي الخاصة بنا:

• يوتيوب: < a href= " https://www.youtube.com/@paimastudios" " > https://www.youtube.com/@paimastudios
• ديسكورد: http://discord.gg/jZ59ArVaxv
• موقع ريديت: https://reddit.com/r/paima
• تويتر: https://twitter.com/PaimaStudios

هل تريد العمل معًا؟ لا تتردد في التواصل معنا من خلال صفحة الاتصال الخاصة بنا: https://paimastudios.com/contact/

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

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