المؤلف: PolkaWorld

غافين وود، مؤسس مشارك لEthereum، ومبدع Polkadot، ورائد رؤية Web3.

قبل أن نبدأ رسميًا، دعونا نشارك بعض الاقتباسات الشهيرة من غافين في هذا الجزء!

ما هي أكبر إنجازات Ethereum حتى الآن؟ - ربما تكون CryptoKitties، لا أدري، في الحقيقة لست متأكدًا. سمعت أن Ethereum قد أنشأت أكبر عدد من مليونيرات التاريخ.

هل Ethereum مشروع ناجح؟ - ماذا عن معايير نجاحي؟ من الواضح أن ليس كل المعايير تتطابق، وربما القليل فقط منها. بالطبع، هو ناجح من الناحية المالية.

مع إدخال JAM، تغير اتجاه Polkadot. يمكن اعتباره نوعًا من سلسلة الإيواء المصممة محليًا، بينما تقنيتنا المتطورة تتفوق بكثير على Rollup المتفائل وRollup المعرفة الصفرية في Ethereum.

ما هي أكبر إنجازات Polkadot حتى الآن؟ - تحقيق سلسلة كتل مقسمة آمنة.

ما هي أكبر مشكلة تواجه Polkadot اليوم؟ - إنها التقسيم.

كيف نحل هذه المشاكل؟ - JAM

استمر في القراءة، لترى كل المحتوى!

ما هي أكبر إنجازات Ethereum حتى الآن؟

كيفن: إذن تقول أنك شاركت في تأسيس Ethereum في عام 2014؟ لماذا انضممت إليهم كمؤسس مشارك ورئيس تقني؟

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

كيفن: وما هو ذلك؟

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

كيفن: ما هي أكبر إنجازات Ethereum حتى الآن؟

غافين: ربما تكون CryptoKitties، لا أدري، في الحقيقة لست متأكدًا. سمعت أن Ethereum قد أنشأت أكبر عدد من مليونيرات التاريخ. ربما بسبب العدد الكبير من المشاركين في حملة التمويل الجماعي، وارتفع السعر لاحقًا بشكل كافٍ. لذا قد يكون هذا هو أكبر مساهمتها. لكن بصراحة، من الصعب القول ما إذا كانت قد حققت شيئًا مفيدًا حقًا. بالتأكيد لم تصل إلى ما كنت أتوقعه قبل 10 سنوات.

كيفن: إذن إذا سألتك، هل تعتقد أن Ethereum مشروع ناجح؟ هل ستكون إجابتك بالنفي؟

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

كيفن: ما هي المعايير التي تجعلك تعتقد أنه ناجح؟

غافين: الفائدة (Utility)

كيفن: كيف تقيس الفائدة؟

غافين: يتم قياس الفائدة من خلال النظر إلى عدد الأشياء التي يمكن للناس القيام بها الآن والتي لم يكن بإمكانهم القيام بها في الماضي.

كيفن: أليس هذا هو مشكلة الصناعة بأكملها في عالم التشفير، وليس مجرد مشكلة Ethereum؟

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

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

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

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

لماذا تركت Ethereum؟

كيفن: لماذا تركت Ethereum في عام 2016؟

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

لاحقًا، لم يكن جيف متكيفًا جدًا مع حياة الشركات الناشئة. في الواقع، ترك Ethereum بسرعة، وذهب لمتابعة مسيرته في ألعاب الفيديو. وهكذا، تبقى فقط فيتاليك في النهاية. رأى فيتاليك أنه من الضروري الاستمرار في البقاء في مؤسسة Ethereum، ولعب دورًا أكاديميًا أكثر، بالإضافة إلى كونه مستشارًا للشركة الفرعية التي أسسناها آنذاك، Ethcore.

لقد جمعنا بعض الأموال، وأخذنا حوالي نصف فريق التقنية من مؤسسة Ethereum إلى Ethcore، وطورنا عميل Ethereum. في نهاية عام 2015، تركت مؤسسة Ethereum، في الواقع لتأسيس هذه الشركة الفرعية، بهدف إضافة كيان مدعوم من أموال خاصة داخل نظام Ethereum.

ومع ذلك، فإن مغادرتي الحقيقية لنظام Ethereum كانت في نهاية عام 2017، عندما أسست Polkadot.

Polkadot تعمل على تطوير تقنية Rollup

كيفن: إذا كنت ستشرح لـ والدتك ما هو Polkadot؟ ماذا ستقول؟

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

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

الآن، مع إدخال JAM، حدثت بعض التغييرات في هذا الاتجاه. يمكن اعتبار التقنية التي نطورها لـ Polkadot نوعًا من تقنية Rollup، بينما يمكن اعتبار Polkadot نفسها سلسلة إيواء مصممة خصيصًا لـ Rollup. إن تطوير وتصميم هذه التقنية ليس بالبساطة، لذا ليس من المفاجئ أن نرى تقنيتين تنافسيتين أخريين بعيدة كل البعد عن الفعالية مقارنة بتقنيتنا التي تم تطويرها لـ Polkadot. بالتحديد، Rollup المتفائل (Optimistic Rollups) وRollup المعرفة الصفرية (ZK Rollups)، وكلاهما تم استخدامه في Ethereum. لذا يمكننا وصف Polkadot على أنه سلسلة إيواء Rollup أصلية - بالطبع، قد لا يكون هذا التعبير مناسبًا لشرحه لوالدتك، لكنه يعتبر مقبولاً للناس الذين لديهم معرفة في مجال التشفير.

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

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

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

أكبر إنجازات Polkadot حتى الآن هي أكبر مشكلتها

كيفن: أعتقد أنك تشير إلى حقيقة نعرفها جميعًا، والتي تسببت بالفعل في الكثير من الارتباك في نظام Ethereum اليوم. إذن، ما هي أكبر إنجازات Polkadot حتى الآن؟

غافين: تحقيق سلسلة كتل مقسمة آمنة.

كيفن: ما هي أكبر مشكلة تواجه Polkadot اليوم؟

غافين: إنها التقسيم.

كيفن: ماذا يعني ذلك بالتحديد؟

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

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

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

لذا، من هذه الزاوية، فإن تصميم التقسيم منطقي. ومع ذلك، فإنه أيضًا يجلب مجموعة من المشاكل. على سبيل المثال، ماذا لو امتلأ درج معين؟ قد تحتاج إلى إعادة ترتيب توزيع السجلات، على سبيل المثال، تغيير السجلات التي كانت تخص A إلى E إلى A إلى D، ثم نقل السجلات التي تبدأ بـ E إلى الدرج السفلي. ولكن هذا قد يؤدي إلى عدم استيعاب الدرج التالي، لذا ستحتاج إلى إعادة ترتيب، وفي كل مرة تتطلب إعادة الترتيب تغيير الملصق الخارجي للدرج. ستصبح هذه العملية معقدة ومزعجة.

لذا، فإن التقسيم أيضًا يجلب معه مجموعة من مشاكله الخاصة.

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

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

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

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

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

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

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

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

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

الحل هو JAM

كيفن: ما هي الحلول الممكنة؟

غافين: حسنًا، JAM هو اقتراحي، أي Join Accumulate Machine (آلة الربط والتجميع).

كيفن: ما هو JAM؟

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

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

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

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

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

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