كيفية تطوير ألعاب داخل السلسلة يمكن التحقق منها باستخدام Zypher؟

منذ أن اقترح Dojo من نظام Starknet البيئي مفهوم ألعاب داخل السلسلة التي يمكن إثباتها ، بدأت العديد من الفرق في الاستكشاف في هذا المجال ، مثل paima باستخدام ضغط الحالة NFT ، والإعادة باستخدام شجرة Merkle ونقوش الحالة ، وما إلى ذلك. أصدرت Zypher Network (@Zypher_Network) أيضا سلسلة من مجموعات المطورين القائمة على تقنية zk-SNARKs للمساعدة في جعل ألعاب داخل السلسلة قابلة للتحقق.

ما هي لعبة داخل السلسلة التي يمكن التحقق منها

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

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

مستوحاة من مجموعة layer2 ، حيث يمكن التحقق من عمليات النقل على نطاق واسع خارج السلسلة الحساب داخل السلسلة داخل السلسلة لماذا لا تتعامل مع تنفيذ منطق اللعبة بنفس الطريقة؟ على الرغم من أن منطق اللعبة يتم حسابه خارج السلسلة ، إلا أنه يمكن التحقق من كل خطوة من خطوات العملية على داخل السلسلة ، مما يضمن أيضا اللامركزية وعدم الثقة في اللعبة ، وهو المكان الذي تأتي منه كلمة “يمكن التحقق منه” ، وحتى يمكننا ببساطة التشبيه: TX في مجموعة layer2 هي معاملة نقل عادية ، و TX في لعبة داخل السلسلة التي يمكن التحقق منها هي داخل السلسلة معاملة للعبة.

اعتمادا على طريقة التحقق من داخل السلسلة ، يتم تقسيم مجموعات إلى OP-مجموعات و ZK-مجموعات. وبالمثل ، تتمتع ألعاب داخل السلسلة التي يمكن التحقق منها باستخدام zk-SNARKs بمزايا بارزة من حيث نهائية وأداء التحقق من الحالة ، ولهذا السبب اختارت Dojo و Zypher Network ZKP لتطوير ألعاب داخل السلسلة يمكن التحقق منها.

مجموعة مطوري شبكة Zypher

تتكون مجموعة مطوري Zypher Network من 3 أجزاء ، وهي محرك AW والمحرك السري ومجموعة Zytron.

1. AW Engine: يستفيد من قدرات ضغط المعلومات في ZKP لتوفير قابلية التوسع. إطار معياري يمكن اللعبة من أن تكون قابلة للتطوير عموديا. قابل للبرمجة عبر الدائرة أو zkVM. يمكن ل z4 SDK الدعم أحداث الشوق في الوقت الفعلي داخل اللعبة (لاعب مقابل لاعب).

2. المحرك السري: يتم استخدام قدرة إخفاء معلومات ZKP لتوفير ألعاب معلومات غير متماثلة. مجموعة تطوير برامج ل zk-SNARKs كخدمة توفر عدم تناسق المعلومات للألعاب التي تتطلب ميكانيكا استراتيجية. ZK-SNARKs (ZKPs قادرة على التنفيذ الكامل لحساب الخصوصية والعشوائية على داخل السلسلة ويمكن أن تثبت عدالتها.

3. مجموعة Zytron: مكدس الطبقة 3. مكدس سلسلة RollupL3 سيادي يوفر نشرا مناسبا للبنية التحتية للألعاب ، بما في ذلك تحسين طبقة نظير إلى نظير وتجزئة الخادم والمزيد. مصممة لألعاب الشوق الضخمة وبناء AW.

محرك AW ، إطار معياري ل zk-SNARKs

AW Engine مسؤول عن بناء دائرة ZKP ، وتوليد البراهين والتحقق من البراهين ، لذلك فهو في قلب المجموعة. يتكون من الأقسام التالية:

1. الأدوات (الأدوات): دعم الأدوات المختلفة المستخدمة في تطوير دوائر اللعبة ، بما في ذلك التجزئة الأساسية ، و ECC ، والأقنعة ، والخلط ، وما إلى ذلك.
2. الدوائر الخاصة بالتطبيق: استخدم plonk الخاص بالتطبيق كمخطط أساسي لبراهين zk ، واكتب دوائر ألعاب محددة من خلال الأدوات المختلفة التي توفرها SDK. وهو يدعم تجميع الدوائر مباشرة في wasm ويمكنه تشغيلها في متصفح أو تطبيق. في الوقت نفسه ، يوفر أيضا القدرة على العمل في الآلة الافتراضية مختلفة (EVM / WASM / … يمكن تشغيل هذه العقود في أنظمة البلوكتشين مختلفة لتحقيق خارج السلسلة إثبات والتحقق داخل السلسلة.
3. المدققون على السلسلة: تم تحسين wasm للبروفات و المدققون ، بالإضافة إلى الدعم للصلابة المشتركة المدققون لجميع سلاسل EVM ، و Move-lang المدققون للسلاسل القائمة على الحركة.
4. محرك Z4 الشوق PVP: Z4 هو نظام لألعاب الشوق في الوقت الحقيقي. إنه يوسع قدرات معالجة الأحداث المؤلمة من خلال الاستعانة بمصادر خارجية لأحداث اللاعب مقابل اللاعب (PvP) إلى عقد zk-rollup المخصصة.

يوضح الرسم البياني أعلاه مبدأ عمل وبنية AW Engine. ينقسم محرك اللعبة هذا إلى عدة أجزاء رئيسية ، وسأشرح وظيفة كل قسم خطوة بخطوة:

1. Zypher Plonk / Bulletproofs / Groth16 / STARKs: هذه كلها مخططات zk-SNARKs مختلفة. هذا يدل على أن محرك اللعبة يدعم أطول أنواع مخططات ZKP ، مما يسمح لمطوري الألعاب باختيار نظام الإثبات المناسب وفقا لاحتياجاتهم.

2. VM العام / DSL: يشير هذا إلى جهاز افتراضي للأغراض العامة أو لغة خاصة بالمجال (DSL) تستخدم لكتابة وتنفيذ منطق اللعبة. أعلنت شبكة Zypher رسميا عن شراكة استراتيجية مع Risc Zero ، والتي من المتوقع أن تدمج zkVM العام لعائلته.

3. أدوات ودوائر Zypher: هذه الأدوات والدوائر هي اللبنات الأساسية لبناء ZKPs. في zk-SNARKs ، الأدوات هي وظائف محددة مسبقا أو أجزاء من المنطق ، والدوائر هي العمليات الحسابية الأكبر التي تربط هذه الأدوات.

4. دائرة إثبات اللعبة: دائرة إثبات اللعبة هي نسخة zk-SNARKs من منطق اللعبة بأكمله. هنا ، يتم إنشاء دائرة تتحقق من صحة قواعد اللعبة دون الكشف عن الإجراءات أو الاستراتيجيات المحددة للاعب.

5. Prover API: API Prover عبارة عن واجهة يقوم المطورون من خلالها بإنشاء البراهين. في سياق اللعبة ، هذا يعني إثبات أن تصرفات اللاعب قد تم تنفيذها وفقا لقواعد اللعبة.

6. Onchain Verifier API: داخل السلسلة المدققون API هي واجهة أخرى للتحقق من الشهادات المقدمة المذكورة أعلاه. يتم ذلك على البلوكتشين لضمان أن تكون كل خطوة من خطوات اللعبة عادلة وشفافة.

7. سوق إثبات ZK: بالنسبة للاعبين على الأجهزة المحمولة ، هناك سوق حساب إثبات اللامركزية حيث يمكن للاعبين الاستعانة بمصادر خارجية لحساب الإثبات. هذا يجعل أجهزة الألعاب داخل السلسلة حيادية.

8. اللعبة: يحتوي جزء اللعبة من حساب خارج السلسلة على منطق اللعبة الفعلي وواجهة المستخدم التي تسمح للاعبين باللعب.

9. لعبة Onchain: بعد تقديم الدليل إلى البلوكتشين ، تصبح اللعبة لعبة اللامركزية و عديم الثقة داخل السلسلة. يمكن مقارنته ب DA Proof في الطبقة 2 لعملية داخل السلسلة.

بشكل عام ، يستفيد AW Engine من zk-SNARKs لضمان أمان وعدالة اللعبة. يسمح بالتحقق من منطق اللعبة دون الكشف عن أي معلومات مهمة ، مما يوفر طريقة جديدة لتطوير وتشغيل الألعاب المبنية على البلوكتشين.

أخيرا ، دعنا نلقي نظرة على سير عمل المحرك بالكامل من منظور المطور:

1. مرحلة التطوير:

• أولا ، يختار المطورون مخطط zk-SNARKs المناسب (مثل Plonk أو Bulletproofs أو Groth16 أو STARKs).

• ثم يستخدمون أحد هذه السيناريوهات لإنشاء “أدوات ودوائر Zypher” ، وهي اللبنات الأساسية لمنطق اللعبة.

• يتم دمج هذه اللبنات الأساسية في “دائرة إثبات اللعبة” الكاملة ، وهي دائرة خالية من المعرفة تثبت صحة حالة اللعبة دون الكشف عن معلومات محددة.

*2. جيل الإثبات (بروفير API) : *

• يتم تحويل كل إجراء أو تغيير حالة في اللعبة إلى دليل على الواجهة الخلفية عبر “Prover API” ، وهو أمر غير قابل للتزوير ولا يكشف عن أي بيانات مهمة للعبة.

• هذا الإثبات يعني أن حركة اللعبة أو حالة اللعبة الخاصة باللاعب تتوافق مع قواعد اللعبة.

3. مصادقة داخل السلسلة (Onchain Verifier API) :

• يتم بعد ذلك تقديم الدليل الذي تم إنشاؤه إلى البلوكتشين عبر “Onchain Verifier API”.

• سيتحقق مدقق داخل السلسلة هذا من صحة إثبات التحقق ، ويؤكد شرعية إجراء اللعبة أو حالتها ، ويضمن عدالة اللعبة وصحتها.

لا تتضمن العملية المذكورة أعلاه نظام معركة الشوق Z4 ، في الواقع ، لا يمكن ل ZKP “التحقق” من منطق اللعبة فحسب ، بل أيضا “التحقق” من “نظام معركة الشوق”.

الصورة أعلاه عبارة عن مخطط سير عمل لمحرك Z4 ، ويمكن ملاحظة أن الطريقة التي يدعم بها محرك Z4 ألعاب اللاعبين طويل في الوقت الفعلي هي إنشاء غرف عديمة الحالة لمطابقة اللاعبين واللعب ، والتي يتم العقدة الدعم بواسطة zk-rollup ، العقدة لا تحفظ البيانات. عند تشغيل منطق اللعبة على العقدة ، يتم فرز جميع العمليات وتلخيصها ، ويتم تأكيدها بواسطة zk-SNARKs. بعد انتهاء اللعبة ، يتم تحميل إثبات العملية والاستنتاج إلى داخل السلسلة للتحقق منه. يمكن ل Z4 العقدة تشغيل منطق اللعبة مباشرة دون استخدام جهاز افتراضي ، وتجنب المعاملات ورسوم غاز. يمكن أيضا استخدام الآلة الافتراضية (مثل WASM / EVM) على العقدة لتشغيل منطق اللعبة إذا لزم الأمر. تم تصميم العملية بأكملها الدعم أحجام على مستوى الشبكة من الملايين أو حتى المليارات في الثانية لضمان أداء متزامن في الوقت الفعلي وعالي للعبة.

وحدة المعلومات غير المتماثلة المحرك السري

Fog of War هو ميكانيكي شائع في الألعاب ، مع أمثلة نموذجية بما في ذلك StarCraft و Warcraft 3. يخفي هذا التصميم المعلومات من خلال تغطية مناطق معينة من خريطة اللعبة ، والتي يتم الكشف عنها فقط عندما يستكشف اللاعب تلك المناطق. يزيد هذا الميكانيكي من عدم القدرة على التنبؤ ببيئة اللعبة وهو نموذجي لما يسمى بألعاب المعلومات غير المتماثلة. تتميز معظم ألعاب MMO الشائعة طويل ميكانيكا ألعاب المعلومات غير المتماثلة ، والتي توفر للاعبين طويل قصير أكثر لاستكشافها ووضع الاستراتيجيات.

ومع ذلك ، في البلوكتشين التكنولوجيا ، عادة ما تكون البيانات مفتوحة وشفافة تماما ، مما يجعل من الصعب تنفيذ آليات المعلومات غير المتماثلة. ومع ذلك ، من خلال استخدام zkSNARKs ، وهي تقنية zk-SNARKs ، تنجح ألعاب Dark Forest في الحفاظ على حالة الخصوصية الخاصة بها بينما يحتاج اللاعبون إلى تقديم إجراءات صالحة يمكن التحقق منها علنا. بهذه الطريقة ، تخلق Dark Forest بيئة لعبة تحتوي على معلومات غير كاملة عن البلوكتشين. ومع ذلك ، تتطلب طريقة إخفاء المعلومات المعقدة هذه برمجة دائرة ZK مخصصة ، لذلك لا يمكن تنفيذ إخفاء المعلومات الشامل في ألعاب داخل السلسلة.

يحل Secret Engine هذه المشكلة جزئيا من خلال WASM المحسن والعقود المترجمة مسبقا ، وينفذ عملية خلط ورق اللعب اللامركزية عالية الأداء ومنخفضة التكلفة من خلال Shuffle SDK. يضمن خلط الدوائر بروتوكول التنفيذ الآمن لحسابات التشفير التي يمكن التحقق منها ، مما يضمن بقاء عناصر السياسة سرية في داخل السلسلة. بالإضافة إلى ألعاب البوكر والاحتكار وألعاب بطاقات التداول ، يمكن تطبيق SDK على حالات استخدام SLG الأخرى التي تتطلب عدم الثقة والعشوائية ، مثل:

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

هناك نوعان من حزم SDK التي يشيع استخدامها:

zk-Shuffle-as-a-service:* يتناوب اللاعبون على التشفير البطاقات وخلطها لإنتاج مجموعة بطاقات “مختومة” ومرتبة عشوائيا ، مما يوفر حلا لا يمكن لمولدات الأرقام العشوائية التقليدية مثل الوظائف العشوائية التي يمكن التحقق منها (VRFs) توفيرها. zk-Matchmaking-as-a-service:* يقدم اللاعبون “بذرة إثبات” لإنشاء رقم عشوائي ومطابقته داخل السلسلة ، يمكن إثبات العملية برمتها من خلال zkp.

توضح هذه الصورة سير عمل Shuffle SDK:

1. زيفر بلونك:

• Basic PlonK: هذا مخطط إثبات zk-SNARK للأغراض العامة يسمح بإنشاء البراهين للتحقق من صحة الحسابات المعقدة دون الكشف عن معلومات إضافية.

• محددات المراوغة: هذه منطق أو تكوينات خاصة بعملية الخلط تسمح لنظام إثبات PlonK بإجراء خلط البطاقات بشكل صحيح.

2. دائرة المراوغة:

• Chaum Pedersen: يستخدم هذا المكون الفرعي لضمان خصوصية عملية الخلط. عادة ما يكون مرتبطا بالتوقيعات الرقمية أو التشفير ، حيث يكون التشفير كل بطاقة آمنا.

• كشف: تتضمن هذه الخطوة الكشف الآمن عن هوية البطاقة عند الحاجة ، دون الكشف عن معلومات حول البطاقات الأخرى.

• التقليب: يشير هذا إلى العملية الفعلية لخلط البطاقات ، أي إعادة ترتيب البطاقات.

• نموذج البطاقة: يحدد هذا نموذج بيانات البطاقة ، وهو أمر ضروري في إنشاء الإصدار التشفير من البطاقة والتحقق لاحقا من المراوغة.

3. خلط SDK:

• Prover SDK (Rust / WASM): تسمح مجموعة تطوير البرامج هذه لمطوري الألعاب بإنشاء zk-SNARKs لإثبات صحة عملية الخلط دون الكشف عن طلب الفعلي للبطاقات.

• Onchain Verifier SDK (صلابة / WASM / Move): يتم استخدام SDK هذا لإنشاء داخل السلسلة المدققون والتحقق من صحة البراهين العشوائية.

قد لا تزال المقدمة أعلاه مجردة للغاية ، فلنستخدم داخل السلسلة Texas Hold’em كمثال لتوضيح مبدأ Shuffle SDK.

في اللعبة ، نحتاج إلى تخزين نتائج “الكومة المختلطة” على داخل السلسلة. لا يعمل هذا فقط كنتيجة للخلط الحالي ، ولكن أيضا كمدخل مشترك ل “عمليات الخلط” اللاحقة ، كما هو موضح في عملية Set Up Pile. في البداية، قم بتعيين المجموعة لتخزين المجموعة التي تمت تهيئتها افتراضيا. ومع ذلك ، فإن التخزين داخل السلسلة مكلف للغاية ، خاصة بالنسبة لأحجام البيانات الكبيرة. تتكون المجموعة المكونة من 52 بطاقة من إجمالي 208 نوعا من البيانات uint256 ، مما يجعل تكاليف التخزين اعتبارا مهما.

حل Zypher هو تخزين جزء فقط من البيانات على داخل السلسلة بعد الخلط ، على وجه التحديد ، تحتاج فقط إلى تخزين بطاقات 2n + 5 ، حيث n هو عدد اللاعبين. بالنظر إلى أنه طويل يتم دعم 6 لاعبين حاليا ، يتم طويل 17 بطاقة على الأكثر. هذا يعني أنه في النهاية يجب تخزين تلك البطاقات ال 17 فقط على داخل السلسلة. ولكن كما ذكرنا سابقا ، هناك غرض آخر لتخزين داخل السلسلة وهو أن هذه البطاقات ستكون أيضا بمثابة مدخل مشترك لعمليات الخلط اللاحقة. لذلك ، إذا تم تخزين 17 بطاقة فقط ، فمن المستحيل التحقق من صحة المراوغة.

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

باختصار ، جوهر العملية برمتها هو استخدام zk-SNARKs لضمان خصوصية وصحة المراوغة. بهذه الطريقة ، تظل قرارات واستراتيجيات اللاعبين خاصة ، حتى لو تم تسجيل جميع الإجراءات علنا على البلوكتشين.

السيادية L3 المكدس طقم زيترون

مجموعة Zytron عبارة عن مكدس تراكمي سيادي من الطبقة 3 قابل للتخصيص بدرجة كبيرة يدعم محرك لعبة Zypher كعقد مترجم مسبقا.

لم يكن لدى البنية التحتية الحالية ل Dapp ، وخاصة EVMs ، شمعة طويلة الفتيل لتحسين حالات الاستخدام عالية الاستجابة مثل ألعاب داخل السلسلة ، وفشلت في توفير كفاءة التكلفة المطلوبة وقابلية التوسع. تتطلب MMOs وغيرها من الألعاب عالية الأداء بنية تحتية مخصصة ومخصصة مع موارد حوسبة فعالة ويمكن التنبؤ بها. سيتم إطلاق أول شبكة ألفا من Zytron ، والتي تضم 0 غاز و 0.2S وقت الكتلة ، وهي عقود مجمعة مسبقا مصممة خصيصا للألعاب ، في المستقبل القريب ، مع التخطيط ل 10 ألعاب كمختبرين رائدين.

توفر المجموعة 4 مكونات أساسية للتوصيل والتشغيل:

Sovereign Rollup: أهم شيء في اللعبة هو إمكانية اللعب ، والتي تتطلب أعلى توافر (CAP) في نظام موزع ، ويمكن ترقية النظام بأكمله بسرعة ونشره تلقائيا. مشاركة الخادم: قم بتوزيع خريطة عالم اللعبة عبر عقد مختلفة لزيادة القدرة الاستيعابية لعقدة واحدة. في الوقت نفسه ، يوفر مجموعة من خوارزميات الاسترجاع الفعالة للتنقل بسرعة بين العقد المختلفة على الخريطة العالمية ، والتبديل بين خدمات العقد المختلفة ، ومزامنة المعلومات. توافق البيانات: يعد بروتوكول مكونا مهما لتجريد التخزين ، ويدمج قواعد بيانات علائقية وتخزين مؤقت أكثر سهولة في الاستخدام لتسريع معالجة بيانات اللعبة. تلبي هذه الميزة الحاجة إلى إدارة البيانات بكفاءة والوصول السريع ، وهو أمر ضروري للحفاظ على تجربة ألعاب سلسة. الشبكات المخصصة: نظرا لاحتياجات الشبكات العالية للعبة ، يعمل إطار العمل على تحسين طبقة الشبكة نظير إلى نظير (P2P) الأساسية لسيناريوهات الألعاب الدعم. يتضمن ذلك تحسينات للمراسلة داخل المجموعة ، باستخدام اجتياز NAT وتقنيات ثقب الثقوب للحصول على اتصالات سريعة وفعالة. بالإضافة إلى ذلك ، صممت الشبكة شمعة طويلة الفتيل بروتوكول UDP خاص للعبة ، والذي تم تصميمه للحفاظ على وقت الإستجابة أقل من 10 مللي ثانية. وهذا يضمن نقل البيانات بسرعة وموثوقية ، وهو أمر ضروري لتجارب الألعاب في الوقت الفعلي.

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

من مخطط الإطار أعلاه ، يمكننا فهم وظائف كل مكون من مكونات مجموعة Zytron:

**1. توفر المكونات الأساسية البنية التحتية لسلسلة الألعاب ، مما يسمح بدرجة عالية من التخصيص والتحسين. **

• تضمن Sovereign Rollup إمكانية اللعب والتوافر العالي للعبة ، مما يدعم الترقيات السريعة والنشر التلقائي للنظام.

• يزيد مشاركة الخادم من سعة تحميل العقدة واحد من خلال توزيع عالم اللعبة عبر طويل العقدة.

• يضمن توافق البيانات المعالجة السريعة لبيانات اللعبة من خلال دمج نظام قاعدة بيانات سهل الاستخدام.

• تعمل الشبكة المخصصة على تحسين طبقة شبكة P2P الأساسية لتلبية متطلبات الشبكة العالية للعبة ، بما في ذلك المراسلة المحسنة بين المجموعات وتقليل وقت الإستجابة.

**2. تحتوي المكونات على السلسلة على الأجزاء الأساسية التي تعمل على داخل السلسلة لضمان صحة منطق اللعبة وأمن الأصول. **

• تضمن المدققون على السلسلة أن جميع المعاملات وعمليات اللعبة صالحة وشرعية.

• تعمل العقود الذكية كحامل ترميز لقواعد اللعبة ومنطقها ، والتعامل مع التفاعل بين اللاعبين وتغيير حالة اللعبة.

**3. توفر مكونات الوحدة تنفيذ ميزات وخدمات محددة للعبة. **

• يوفر نظام ZK الدعم لحماية الخصوصية ، مثل الحوسبة والتحقق من الحفاظ على الخصوصية.

• يوفر نظام الحساب ونظام المراسلة الفورية وظائف إدارة المستخدم والاتصال في الوقت الفعلي.

• تستخدم أنظمة المراقبة لمراقبة ظروف الشبكة وصحة اللعبة.

• توفر أنظمة الغرف والأنظمة المالية وأنظمة الذكاء الاصطناعي إدارة الغرفة داخل اللعبة والمعاملات المالية الذكاء الاصطناعي الدعم.

• يسجل نظام التسجيل جميع العمليات والأحداث للتحليل والتصحيح.

يوضح الرسم البياني أعلاه سير عمل مكدس مجموعة Zytron:

• يتم إنشاء المعاملات أولا على الطبقة 3 ويتم طلبها بواسطة Sequencer.
• يستمع العقدة العداء إلى أحداث الطبقة 1/2 وإخراج جهاز التسلسل ، ويتواصلون مع بعضهم البعض لتنفيذ المعاملات والتوصل إلى توافق في الآراء لتنفيذ وظائف مشاركة الخدمة.
• يتم تقديم البيانات إلى سيليستيا على أساس منتظم لضمان توافر وأمن البيانات.
• يتفاعل العملاء مع الطبقة 3 من خلال المزامنة الخفيفة ويمكنهم استدعاء الخدمات التي توفرها الطبقة 3.

والأمر الأكثر إثارة للاهتمام هو أنه يمكن دمج أول مجموعتين من المحركات ، بما في ذلك AW Engine و Secret Engine ، مع مجموعة Zytron في شكل مجمع مسبقا لتوفير بنية تحتية فعالة وسريعة الاستجابة وغنية بالميزات لألعاب داخل السلسلة في شكل أكثر بساطة. يمكن للمطورين أيضا اختيار المكونات المناسبة وفقا لاحتياجاتهم لإنشاء بيئة سلسلة تتناسب مع تصميم لعبتهم. لا تدعم Zypher النظام البيئي ETH فحسب ، بل تستكشف أيضا بنشاط إمكانية ألعاب داخل السلسلة و L3 في النظام البيئي BTC ، أعلنت Zypher و BTC’s Layer2 B² Network رسميا أنها ستنشر داخل السلسلة Layer 3 الحصرية للألعاب استنادا إلى شبكة B² و DA Layer B² Hub ، والتي ستكون أول طبقة 3 في النظام البيئي BTC الدعم داخل السلسلة الألعاب. أصبح Zypher أول محرك لتطوير الألعاب داخل السلسلة الدعم النظام البيئي BTC.