في هذه الحلقة الخاصة من Devs on Devs، دعونا نرحب بمطور البروتوكول الأساسي لشبكة Plasma Mode tdot(، والذي هو أيضًا مطور Redstone )، ومؤسس مشارك لمشروع Layer 2 المعروف Ben Jones. يعد مشروع Layer 2 المعروف من الداعمين الرئيسيين لـ OP Stack. يسمح Plasma Mode للمطورين بالبناء على OP Stack، ولكن دون الحاجة لنشر البيانات على L1، بل يمكنهم التحول بمرونة إلى مزودي البيانات خارج السلسلة، مما يوفر التكاليف ويعزز القابلية للتوسع. في هذه المحادثة، ناقشوا أصول التعاون بين Redstone ومشروع Layer 2، وأهمية إحياء Plasma، وضرورة إدخال البروتوكولات التجريبية إلى بيئات الإنتاج، وخارطة الطريق المستقبلية لـ Plasma Mode و OP Stack، فضلاً عن مشاعرهم الحماسية بشأن تطوير مجال الألعاب الكاملة.
كيفية استخدام وضع بلازما لتحسين OP Stack
Ben: كيف كانت عملية بدء تحسين OP Stack؟
tdot: انضممت إلى Lattice منذ حوالي عام، وأنا مسؤول بشكل خاص عن وضع Plasma. الهدف واضح جدًا: لدينا العديد من تطبيقات MUD التي تستهلك كمية كبيرة من الغاز، وفي نفس الوقت نحاول وضع كمية كبيرة من البيانات على السلسلة، لذا نحتاج إلى حل يدعم هذه الاحتياجات ويكون رخيصًا. لقد قام فريق Lattice ببعض التجارب على OP Stack، مثل تصميم نماذج أولية لبعض العوالم على السلسلة ونشرها على OP Stack. لقد وجدنا أن OP Stack قد أصبح مفيدًا جدًا.
لذلك نسأل أنفسنا: "كيف يمكننا جعله أرخص؟" الفرضية الأساسية هي: "نعتقد أن OP Stack هو الإطار الأكثر توافقًا مع فكرة الإيثريوم والمتوافق تمامًا مع EVM." ما يعمل على الشبكة الرئيسية يمكن أن يعمل أيضًا على OP Stack، وهذه هي الحل المثالي. لكننا نريد أن يكون أرخص.
في ذلك الوقت، كانت calldata لا تزال مصدر بيانات قابلية الاستخدام لشبكة OP Stack (DA)، وهذا كان مكلفًا للغاية. لذلك، من الواضح أننا لا نستطيع استخدام calldata لبدء L2، لأن ألعابنا الشاملة وعالم MUD يحتاجان إلى سعة معالجة أعلى. لذلك، قررنا البدء في تجربة حلول أخرى لبيانات القابلية للاستخدام (Alt DA). في الواقع، تم الإشارة بالفعل إلى استكشاف Alt DA في الوثائق الأولية لـ OP Stack.
لذلك سألنا أنفسنا، "ماذا لو بدأنا من DA خارج السلسلة؟" نأمل أن يعتمد نموذج الأمان بالكامل وكل شيء على إيثيريوم L1. لذلك تجنبنا حلول DA البديلة الأخرى، وقررنا تخزين البيانات في تخزين DA مركزي، ثم العثور على نموذج أمان فعال على L1.
هذا هو السبب في أننا نحتاج إلى إعادة استخدام بعض المفاهيم القديمة لـ Plasma ووضعها فوق rollup. هناك بعض الاختلافات هنا. أكبر سؤال هو، كيف يمكن تنفيذ DA خارج السلسلة والتحديات البيانية على السلسلة على OP Stack الحالي؟ هدفنا هو إحداث أقل قدر ممكن من التغييرات على OP Stack، دون التأثير على مسار rollup، لأننا لا نريد التأثير على أمان سلاسل rollup الأخرى التي تستخدم OP Stack.
عند تصميم rollup، لن تفكر في "ماذا سيحدث إذا قام شخص ما بتغيير عملية توليد البيانات لتخزين البيانات من مكان آخر؟" حتى مع هذه التغييرات، لا يزال OP Stack قويًا جدًا، ويعمل بشكل جيد خارج الصندوق. هذا هو التغيير الأول الذي قمنا به.
بعد ذلك، نحتاج إلى كتابة العقد لإنشاء هذه التحديات. هناك تحديات DA تُستخدم لإجبار البيانات على الانتقال إلى السلسلة. هذه هي الخطوة الثانية، دمج العقد في العملية. يجب أن نبني نظام التكامل بالكامل في عملية الاشتقاق، بحيث يمكنك اشتقاق البيانات من مصدر DA خارج السلسلة ومن عقد تحدي L1 DA، في حال تم تقديم البيانات إلى السلسلة خلال عملية حل التحدي.
هذه هي النقطة الأساسية. الأمر معقد لأنه نريد الحفاظ على الأشياء بأناقة وثبات. في نفس الوقت، هو مفهوم بسيط نسبيًا. لم نحاول إعادة اختراع كل شيء أو تغيير مجموعة OP بالكامل، بل حاولنا الحفاظ على الأمور بسيطة في بيئة معقدة. لذا، بشكل عام، هذه رحلة هندسية رائعة جدًا.
Ben: يمكنني التحدث عن ذلك من منظور OP. لقد ذكرت بعض الأعمال المبكرة في Lattice. في نفس الوقت تقريبًا، قمنا بإعادة كتابة كاملة تقريبًا لهيكل OP بأكمله، وهذه النسخة التي أطلقنا عليها اسم Bedrock.
أساسًا، بعد بناء الـ rollup لمدة عامين، نأخذ خطوة إلى الوراء ونتأمل قائلين: "حسنًا، إذا كنا سنستخدم جميع الخبرات التي تعلمناها إلى أقصى حد، كيف سيبدو ذلك؟" وقد تطور هذا ليصبح المكتبة البرمجية المعروفة أخيرًا باسم Bedrock، والتي تمثل أكبر ترقية لشبكتنا.
في ذلك الوقت، تعاونّا معكم في مشروع يسمى OPCraft، وأعتقد أن Biomes هو الوريث الروحي له، حيث كانت هذه أكثر مرة استمتعنا فيها باللعب على السلسلة. في نفس الوقت، تنفسنا الصعداء، لأن الآخرين يمكنهم أيضًا استخدام OP Stack للتطوير. أعتقد أن نقطة التحول المهمة الأخرى في التوسع خلال السنوات القليلة الماضية هي أن الكثير من الناس يمكنهم تشغيل السلسلة.
ليس فقط أولئك الذين قاموا بتطوير مكتبات كود ضخمة ومعقدة هم من يمكنهم القيام بذلك. عندما بدأنا التعاون، كان من الرائع رؤية الآخرين قادرين على استلام هذه المكتبة البرمجية وقيامهم ببعض الأشياء الرائعة للغاية، وهذا كان تأكيدًا كبيرًا. ثم رؤية هذا الوضع يتوسع في التطبيقات العملية على Plasma، كان حقًا رائعًا. يمكنني حتى التحدث قليلاً عن تلك الفترة.
قبل تأسيس مشروع Layer 2 المعروف، كنا في الواقع نبحث في تقنية تُدعى Plasma. كانت المهمة التي كنا نتحملها تتجاوز بكثير قدرة مجتمع التوسع في ذلك الوقت. التصميم الذي رأيته في التصميم المبكر لـ Plasma قد لا يكون له علاقة مباشرة بـ Plasma اليوم.
بلازما اليوم أسهل بكثير. نحن نفصل بين إثبات وتحدي التحقق من الحالة وتحديات البيانات. في النهاية، أدركنا قبل بضع سنوات أن Rollups أبسط بكثير من بلازما. أعتقد أن استنتاج المجتمع في ذلك الوقت كان "بلازما ميتة". هذه كانت نكتة في تاريخ توسيع إيثريوم في ذلك الوقت.
لكننا نعتقد دائمًا أن "Plasma لم تمت، فقط يمكننا تجربة مهمة أبسط أولاً". الآن نحن نستخدم مصطلحات مختلفة. على سبيل المثال، كان هناك وقت للخروج من (exits) وما إلى ذلك، الآن يمكنك أن تنظر إلى الوراء وتقول "أوه، كانت تلك تحديات توفر البيانات مع بعض الخطوات الإضافية". لذا، من الرائع أن نرى أن OP Stack لا يُستخدم فقط من قبل الآخرين، بل تطور ليصبح ما حاولنا القيام به في البداية ولكن بطريقة مشوشة وغير ناضجة للغاية. لقد أكملنا دورة كاملة، وأنتم حوله قمتم بعمل تجريدي رائع وجعلتموه يعمل بطريقة معقولة وعقلانية. هذا حقًا رائع.
الأهم هو الدخول إلى بيئة الإنتاج في أقرب وقت ممكن
tdot: لا تزال هناك بعض التحديات والمشكلات غير المحلولة في وضع Plasma، ونحن نعمل على حلها. المفتاح هو كيفية تجنب قضاء عشر سنوات في ذلك؟ هل تفهم ما أعنيه؟ نحتاج إلى الوصول إلى مرحلة يمكننا فيها تقديم النتائج في أقرب وقت ممكن.
هذه هي فكرتنا. لدينا العديد من التطبيقات التي تم تطويرها بناءً على MUD ونريد إطلاقها على الشبكة الرئيسية فورًا. نحن بحاجة إلى إعداد شبكة رئيسية لهذه الألعاب في أسرع وقت ممكن. لقد انتظر الناس وهم مستعدون. تحتاج إلى شبكة سريعة وفعالة لتشغيل جميع هذه التطبيقات، حتى تتمكن هذه التطبيقات من التطور بشكل متوازي أثناء حل مشكلاتنا، وتصبح أفضل. يستغرق الأمر وقتًا طويلاً من البحث والتطوير إلى تحقيق الاستقرار الإنتاجي.
لإطلاق شيء ما على الشبكة الرئيسية، وجعله غير مصرح به، ومستقر وآمن، يتطلب الأمر وقتًا طويلاً. من المدهش رؤية العملية الكاملة لتحقيق هذا الهدف. وهذا هو السبب في أننا بحاجة إلى الحفاظ على مستوى عالٍ من المرونة، لأن الأمور كثيرة جدًا. يتطور النظام البيئي بسرعة كبيرة. أعتقد أن الجميع يقدمون الكثير من الابتكارات. وهذا هو السبب في أنك يجب أن تواكب ذلك، لكن لا يمكنك المساومة على الأمان والأداء، وإلا فلن يعمل النظام.
Ben: أو يمكن القول إنها عبء تقني. المبدأ الذي ذكرته حول الحد الأدنى من التغييرات، هو أحد المفاهيم الأساسية التي اعتمدناها أثناء إعادة كتابة Bedrock. لقد تحدثت عن إعادة الكتابة الشاملة من البداية إلى النهاية، لكن الأهم من ذلك هو أننا قللنا حوالي 50,000 سطر من الشيفرة، وهذا بحد ذاته قوي جداً. لأنك محق، هذه الأمور صعبة جداً.
كل سطر إضافي من الشيفرة يجعلك بعيدًا عن بيئة الإنتاج، مما يجعل الأمور أكثر صعوبة في الاختبار العملي، ويزيد من فرص الأخطاء. لذلك، نشكركم جميعًا على جهودكم في دفع هذه العملية، وخاصةً على المساهمة في نمط التشغيل الجديد لـ OP Stack.
tdot: OP Stack بالتأكيد خلق وسيلة تتيح لك التقدم بسرعة في مثل هذه الأمور. من الصعب للغاية تنسيق الجميع، لأننا بوضوح شركتان مختلفتان. في Lattice، نحن نبني لعبة، ومحرك لعبة، وسلسلة.
أنتم تبنون مئات وآلاف الأشياء، وتقومون بتسليم جميع هذه المنتجات بشكل دوري. من حيث التنسيق، فإن هذا ليس بالأمر السهل حقًا.
Ben: نعم، لا يزال هناك طريق طويل لنقطعه. لكن هذه هي السمة الأساسية لسحر النظام المعياري. بالنسبة لي، من منظور OP Stack، هذا أحد أكثر الأمور إثارة، ناهيك عن الألعاب والعوالم الافتراضية المذهلة التي تُبنى الآن على Redstone. من منظور OP Stack فقط، هذه مثال قوي جدًا يثبت أن العديد من المطورين الأساسيين الرائعين قد انضموا وساهموا في تحسين هذه البنية، وهذا أمر رائع.
هذه هي المرة الأولى، يمكنك من خلال قيمة بوليانية رئيسية تغيير خصائص النظام بشكل كبير. القدرة على القيام بذلك تمامًا، كما قلت، لا يزال هناك طريق طويل لنقطعه. لكن حتى الاقتراب من القيام بذلك بشكل فعال، يتطلب دعمًا معياريًا، أليس كذلك؟ بالنسبة لنا، كان من المريح رؤية أنكم حققتم ذلك، دون الحاجة إلى إعادة كتابة L2 Geth، صحيح؟ بالنسبة لي، هذا يثبت أن المعيارية تعمل.
tdot: الوضع الآن أصبح أفضل. من خلال هذا المثال، لقد حولتم كل شيء إلى وحدات صغيرة مستقلة يمكن تعديلها وتغيير خصائصها. لذلك، أنا متحمس جداً لرؤية الميزات الجديدة التي سيتم دمجها. أتذكر أننا كنا نشعر بالقلق من أن لدينا تفرعاً يحتوي على جميع التعديلات على OP Stack، ويجب دمجه في الرئيسية. كنا نفكر حينها، "يا إلهي، سيكون من الجنون مراجعة كل شيء."
كان علينا تفكيكها إلى أجزاء أصغر، لكن العملية برمتها تسير بسلاسة شديدة. كانت أجواء التعاون بيننا وبين الفريق جيدة جداً، لذا كانت عملية المراجعة ممتعة أيضاً. كان ذلك شعوراً طبيعياً جداً. وأعتقد أن هذه العملية تسير بسرعة كبيرة في مراجعة وحل بعض المشكلات المحتملة. كل شيء كان يسير بشكل غير متوقع.
Ben: هذا رائع حقًا. هذا العام أحد تركيزاتنا هو إنشاء مسار للمساهمات لـ OP Stack. لذلك أنا ممتن حقًا لمشاركتكم في الاختبار، ودفع هذه العمليات. أنا سعيد أن هذه العمليات لم تكن صعبة على الناس، وأننا حققنا بعض النتائج. بالحديث عن ذلك، أنا فضولي حقًا، من وجهة نظرك، كيف ستتطور هذه العمل في المستقبل؟ ما الذي تتطلع إلى تطويره بعد ذلك؟
tdot: هناك العديد من الاتجاهات الوظيفية المختلفة. التركيز الرئيسي هو على دمج آلية إثبات العطل. نحن نتبنى نهجًا تدريجيًا لامركزية كامل تقنية النطاق وزيادة ميزاتها غير المصرح بها، والهدف النهائي هو تحقيق ميزات مثل عدم الحاجة إلى الإذن وفرض الخروج.
لدينا هذا الهدف النهائي، وسنسعى لتحقيقه تدريجياً مع الحفاظ على الأمان. أحد التحديات هو أنه في بعض الأحيان يكون من الأسهل عدم الذهاب إلى الشبكة الرئيسية، لأن ذلك يعني أنه لا حاجة لإجراء انقسام صلب. قد تفكر، "أوه، سأنتظر حتى يكون كل شيء جاهز تمامًا للإصدار، حتى لا أحتاج إلى إجراء انقسام صلب، ولا يوجد عبء تقني." لكن، إذا كنت ترغب في إطلاق الشبكة الرئيسية بسرعة، يجب عليك التعامل مع هذه التحديثات المعقدة، وإصدارها بشكل متكرر. إنجاز ذلك مع الحفاظ على توفر عالي دائمًا ما يمثل تحديًا.
أعتقد أنه بعد أن يكون آلية إثبات العطل وجميع هذه الأجزاء جاهزة، سيكون هناك الكثير من التحديثات في جانب نموذج بلازما. أعتقد أنه لا يزال هناك مجال للتحسين في تقديم الالتزام الجماعي. الآن نحن نقوم بذلك ببساطة، التزام واحد لكل معاملة. والالتزام هو مجرد قيمة هاش لبيانات الإدخال المخزنة خارج السلسلة.
نحن نحتفظ بالبساطة قدر الإمكان حتى يكون المراجعة بسيطة وسريعة، ولا يوجد اختلاف كبير على OP Stack. لكن الآن هناك بعض التحسينات التي يمكن أن تجعل الأمر أرخص، مثل تنفيذ الالتزام بشكل جماعي أو تقديمها.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 17
أعجبني
17
6
إعادة النشر
مشاركة
تعليق
0/400
EyeOfTheTokenStorm
· 08-08 19:42
القدرة على التوسع لا تزال في المضاربة، لا تتفاخر بالبيانات، انظر إلى المنحنى ثم تحدث.
شاهد النسخة الأصليةرد0
SchroedingerAirdrop
· 08-06 13:05
لقد جلست في المكان الصحيح هذه المرة
شاهد النسخة الأصليةرد0
LayerZeroEnjoyer
· 08-06 03:11
靠 这波 رائع了呀
شاهد النسخة الأصليةرد0
MetaMisery
· 08-06 03:09
شاهد المسرحية وتناول البطيخ أثناء انتظار العرض الكبير
تصادم وضع بلازما مع مجموعة OP: الطريق إلى مستقبل الألعاب على السلسلة الكاملة
مطورو المطورين: حوار بين tdot وبن جونز
في هذه الحلقة الخاصة من Devs on Devs، دعونا نرحب بمطور البروتوكول الأساسي لشبكة Plasma Mode tdot(، والذي هو أيضًا مطور Redstone )، ومؤسس مشارك لمشروع Layer 2 المعروف Ben Jones. يعد مشروع Layer 2 المعروف من الداعمين الرئيسيين لـ OP Stack. يسمح Plasma Mode للمطورين بالبناء على OP Stack، ولكن دون الحاجة لنشر البيانات على L1، بل يمكنهم التحول بمرونة إلى مزودي البيانات خارج السلسلة، مما يوفر التكاليف ويعزز القابلية للتوسع. في هذه المحادثة، ناقشوا أصول التعاون بين Redstone ومشروع Layer 2، وأهمية إحياء Plasma، وضرورة إدخال البروتوكولات التجريبية إلى بيئات الإنتاج، وخارطة الطريق المستقبلية لـ Plasma Mode و OP Stack، فضلاً عن مشاعرهم الحماسية بشأن تطوير مجال الألعاب الكاملة.
كيفية استخدام وضع بلازما لتحسين OP Stack
Ben: كيف كانت عملية بدء تحسين OP Stack؟
tdot: انضممت إلى Lattice منذ حوالي عام، وأنا مسؤول بشكل خاص عن وضع Plasma. الهدف واضح جدًا: لدينا العديد من تطبيقات MUD التي تستهلك كمية كبيرة من الغاز، وفي نفس الوقت نحاول وضع كمية كبيرة من البيانات على السلسلة، لذا نحتاج إلى حل يدعم هذه الاحتياجات ويكون رخيصًا. لقد قام فريق Lattice ببعض التجارب على OP Stack، مثل تصميم نماذج أولية لبعض العوالم على السلسلة ونشرها على OP Stack. لقد وجدنا أن OP Stack قد أصبح مفيدًا جدًا.
لذلك نسأل أنفسنا: "كيف يمكننا جعله أرخص؟" الفرضية الأساسية هي: "نعتقد أن OP Stack هو الإطار الأكثر توافقًا مع فكرة الإيثريوم والمتوافق تمامًا مع EVM." ما يعمل على الشبكة الرئيسية يمكن أن يعمل أيضًا على OP Stack، وهذه هي الحل المثالي. لكننا نريد أن يكون أرخص.
في ذلك الوقت، كانت calldata لا تزال مصدر بيانات قابلية الاستخدام لشبكة OP Stack (DA)، وهذا كان مكلفًا للغاية. لذلك، من الواضح أننا لا نستطيع استخدام calldata لبدء L2، لأن ألعابنا الشاملة وعالم MUD يحتاجان إلى سعة معالجة أعلى. لذلك، قررنا البدء في تجربة حلول أخرى لبيانات القابلية للاستخدام (Alt DA). في الواقع، تم الإشارة بالفعل إلى استكشاف Alt DA في الوثائق الأولية لـ OP Stack.
لذلك سألنا أنفسنا، "ماذا لو بدأنا من DA خارج السلسلة؟" نأمل أن يعتمد نموذج الأمان بالكامل وكل شيء على إيثيريوم L1. لذلك تجنبنا حلول DA البديلة الأخرى، وقررنا تخزين البيانات في تخزين DA مركزي، ثم العثور على نموذج أمان فعال على L1.
هذا هو السبب في أننا نحتاج إلى إعادة استخدام بعض المفاهيم القديمة لـ Plasma ووضعها فوق rollup. هناك بعض الاختلافات هنا. أكبر سؤال هو، كيف يمكن تنفيذ DA خارج السلسلة والتحديات البيانية على السلسلة على OP Stack الحالي؟ هدفنا هو إحداث أقل قدر ممكن من التغييرات على OP Stack، دون التأثير على مسار rollup، لأننا لا نريد التأثير على أمان سلاسل rollup الأخرى التي تستخدم OP Stack.
عند تصميم rollup، لن تفكر في "ماذا سيحدث إذا قام شخص ما بتغيير عملية توليد البيانات لتخزين البيانات من مكان آخر؟" حتى مع هذه التغييرات، لا يزال OP Stack قويًا جدًا، ويعمل بشكل جيد خارج الصندوق. هذا هو التغيير الأول الذي قمنا به.
بعد ذلك، نحتاج إلى كتابة العقد لإنشاء هذه التحديات. هناك تحديات DA تُستخدم لإجبار البيانات على الانتقال إلى السلسلة. هذه هي الخطوة الثانية، دمج العقد في العملية. يجب أن نبني نظام التكامل بالكامل في عملية الاشتقاق، بحيث يمكنك اشتقاق البيانات من مصدر DA خارج السلسلة ومن عقد تحدي L1 DA، في حال تم تقديم البيانات إلى السلسلة خلال عملية حل التحدي.
هذه هي النقطة الأساسية. الأمر معقد لأنه نريد الحفاظ على الأشياء بأناقة وثبات. في نفس الوقت، هو مفهوم بسيط نسبيًا. لم نحاول إعادة اختراع كل شيء أو تغيير مجموعة OP بالكامل، بل حاولنا الحفاظ على الأمور بسيطة في بيئة معقدة. لذا، بشكل عام، هذه رحلة هندسية رائعة جدًا.
Ben: يمكنني التحدث عن ذلك من منظور OP. لقد ذكرت بعض الأعمال المبكرة في Lattice. في نفس الوقت تقريبًا، قمنا بإعادة كتابة كاملة تقريبًا لهيكل OP بأكمله، وهذه النسخة التي أطلقنا عليها اسم Bedrock.
أساسًا، بعد بناء الـ rollup لمدة عامين، نأخذ خطوة إلى الوراء ونتأمل قائلين: "حسنًا، إذا كنا سنستخدم جميع الخبرات التي تعلمناها إلى أقصى حد، كيف سيبدو ذلك؟" وقد تطور هذا ليصبح المكتبة البرمجية المعروفة أخيرًا باسم Bedrock، والتي تمثل أكبر ترقية لشبكتنا.
في ذلك الوقت، تعاونّا معكم في مشروع يسمى OPCraft، وأعتقد أن Biomes هو الوريث الروحي له، حيث كانت هذه أكثر مرة استمتعنا فيها باللعب على السلسلة. في نفس الوقت، تنفسنا الصعداء، لأن الآخرين يمكنهم أيضًا استخدام OP Stack للتطوير. أعتقد أن نقطة التحول المهمة الأخرى في التوسع خلال السنوات القليلة الماضية هي أن الكثير من الناس يمكنهم تشغيل السلسلة.
ليس فقط أولئك الذين قاموا بتطوير مكتبات كود ضخمة ومعقدة هم من يمكنهم القيام بذلك. عندما بدأنا التعاون، كان من الرائع رؤية الآخرين قادرين على استلام هذه المكتبة البرمجية وقيامهم ببعض الأشياء الرائعة للغاية، وهذا كان تأكيدًا كبيرًا. ثم رؤية هذا الوضع يتوسع في التطبيقات العملية على Plasma، كان حقًا رائعًا. يمكنني حتى التحدث قليلاً عن تلك الفترة.
قبل تأسيس مشروع Layer 2 المعروف، كنا في الواقع نبحث في تقنية تُدعى Plasma. كانت المهمة التي كنا نتحملها تتجاوز بكثير قدرة مجتمع التوسع في ذلك الوقت. التصميم الذي رأيته في التصميم المبكر لـ Plasma قد لا يكون له علاقة مباشرة بـ Plasma اليوم.
بلازما اليوم أسهل بكثير. نحن نفصل بين إثبات وتحدي التحقق من الحالة وتحديات البيانات. في النهاية، أدركنا قبل بضع سنوات أن Rollups أبسط بكثير من بلازما. أعتقد أن استنتاج المجتمع في ذلك الوقت كان "بلازما ميتة". هذه كانت نكتة في تاريخ توسيع إيثريوم في ذلك الوقت.
لكننا نعتقد دائمًا أن "Plasma لم تمت، فقط يمكننا تجربة مهمة أبسط أولاً". الآن نحن نستخدم مصطلحات مختلفة. على سبيل المثال، كان هناك وقت للخروج من (exits) وما إلى ذلك، الآن يمكنك أن تنظر إلى الوراء وتقول "أوه، كانت تلك تحديات توفر البيانات مع بعض الخطوات الإضافية". لذا، من الرائع أن نرى أن OP Stack لا يُستخدم فقط من قبل الآخرين، بل تطور ليصبح ما حاولنا القيام به في البداية ولكن بطريقة مشوشة وغير ناضجة للغاية. لقد أكملنا دورة كاملة، وأنتم حوله قمتم بعمل تجريدي رائع وجعلتموه يعمل بطريقة معقولة وعقلانية. هذا حقًا رائع.
الأهم هو الدخول إلى بيئة الإنتاج في أقرب وقت ممكن
tdot: لا تزال هناك بعض التحديات والمشكلات غير المحلولة في وضع Plasma، ونحن نعمل على حلها. المفتاح هو كيفية تجنب قضاء عشر سنوات في ذلك؟ هل تفهم ما أعنيه؟ نحتاج إلى الوصول إلى مرحلة يمكننا فيها تقديم النتائج في أقرب وقت ممكن.
هذه هي فكرتنا. لدينا العديد من التطبيقات التي تم تطويرها بناءً على MUD ونريد إطلاقها على الشبكة الرئيسية فورًا. نحن بحاجة إلى إعداد شبكة رئيسية لهذه الألعاب في أسرع وقت ممكن. لقد انتظر الناس وهم مستعدون. تحتاج إلى شبكة سريعة وفعالة لتشغيل جميع هذه التطبيقات، حتى تتمكن هذه التطبيقات من التطور بشكل متوازي أثناء حل مشكلاتنا، وتصبح أفضل. يستغرق الأمر وقتًا طويلاً من البحث والتطوير إلى تحقيق الاستقرار الإنتاجي.
لإطلاق شيء ما على الشبكة الرئيسية، وجعله غير مصرح به، ومستقر وآمن، يتطلب الأمر وقتًا طويلاً. من المدهش رؤية العملية الكاملة لتحقيق هذا الهدف. وهذا هو السبب في أننا بحاجة إلى الحفاظ على مستوى عالٍ من المرونة، لأن الأمور كثيرة جدًا. يتطور النظام البيئي بسرعة كبيرة. أعتقد أن الجميع يقدمون الكثير من الابتكارات. وهذا هو السبب في أنك يجب أن تواكب ذلك، لكن لا يمكنك المساومة على الأمان والأداء، وإلا فلن يعمل النظام.
Ben: أو يمكن القول إنها عبء تقني. المبدأ الذي ذكرته حول الحد الأدنى من التغييرات، هو أحد المفاهيم الأساسية التي اعتمدناها أثناء إعادة كتابة Bedrock. لقد تحدثت عن إعادة الكتابة الشاملة من البداية إلى النهاية، لكن الأهم من ذلك هو أننا قللنا حوالي 50,000 سطر من الشيفرة، وهذا بحد ذاته قوي جداً. لأنك محق، هذه الأمور صعبة جداً.
كل سطر إضافي من الشيفرة يجعلك بعيدًا عن بيئة الإنتاج، مما يجعل الأمور أكثر صعوبة في الاختبار العملي، ويزيد من فرص الأخطاء. لذلك، نشكركم جميعًا على جهودكم في دفع هذه العملية، وخاصةً على المساهمة في نمط التشغيل الجديد لـ OP Stack.
tdot: OP Stack بالتأكيد خلق وسيلة تتيح لك التقدم بسرعة في مثل هذه الأمور. من الصعب للغاية تنسيق الجميع، لأننا بوضوح شركتان مختلفتان. في Lattice، نحن نبني لعبة، ومحرك لعبة، وسلسلة.
أنتم تبنون مئات وآلاف الأشياء، وتقومون بتسليم جميع هذه المنتجات بشكل دوري. من حيث التنسيق، فإن هذا ليس بالأمر السهل حقًا.
Ben: نعم، لا يزال هناك طريق طويل لنقطعه. لكن هذه هي السمة الأساسية لسحر النظام المعياري. بالنسبة لي، من منظور OP Stack، هذا أحد أكثر الأمور إثارة، ناهيك عن الألعاب والعوالم الافتراضية المذهلة التي تُبنى الآن على Redstone. من منظور OP Stack فقط، هذه مثال قوي جدًا يثبت أن العديد من المطورين الأساسيين الرائعين قد انضموا وساهموا في تحسين هذه البنية، وهذا أمر رائع.
هذه هي المرة الأولى، يمكنك من خلال قيمة بوليانية رئيسية تغيير خصائص النظام بشكل كبير. القدرة على القيام بذلك تمامًا، كما قلت، لا يزال هناك طريق طويل لنقطعه. لكن حتى الاقتراب من القيام بذلك بشكل فعال، يتطلب دعمًا معياريًا، أليس كذلك؟ بالنسبة لنا، كان من المريح رؤية أنكم حققتم ذلك، دون الحاجة إلى إعادة كتابة L2 Geth، صحيح؟ بالنسبة لي، هذا يثبت أن المعيارية تعمل.
tdot: الوضع الآن أصبح أفضل. من خلال هذا المثال، لقد حولتم كل شيء إلى وحدات صغيرة مستقلة يمكن تعديلها وتغيير خصائصها. لذلك، أنا متحمس جداً لرؤية الميزات الجديدة التي سيتم دمجها. أتذكر أننا كنا نشعر بالقلق من أن لدينا تفرعاً يحتوي على جميع التعديلات على OP Stack، ويجب دمجه في الرئيسية. كنا نفكر حينها، "يا إلهي، سيكون من الجنون مراجعة كل شيء."
كان علينا تفكيكها إلى أجزاء أصغر، لكن العملية برمتها تسير بسلاسة شديدة. كانت أجواء التعاون بيننا وبين الفريق جيدة جداً، لذا كانت عملية المراجعة ممتعة أيضاً. كان ذلك شعوراً طبيعياً جداً. وأعتقد أن هذه العملية تسير بسرعة كبيرة في مراجعة وحل بعض المشكلات المحتملة. كل شيء كان يسير بشكل غير متوقع.
Ben: هذا رائع حقًا. هذا العام أحد تركيزاتنا هو إنشاء مسار للمساهمات لـ OP Stack. لذلك أنا ممتن حقًا لمشاركتكم في الاختبار، ودفع هذه العمليات. أنا سعيد أن هذه العمليات لم تكن صعبة على الناس، وأننا حققنا بعض النتائج. بالحديث عن ذلك، أنا فضولي حقًا، من وجهة نظرك، كيف ستتطور هذه العمل في المستقبل؟ ما الذي تتطلع إلى تطويره بعد ذلك؟
tdot: هناك العديد من الاتجاهات الوظيفية المختلفة. التركيز الرئيسي هو على دمج آلية إثبات العطل. نحن نتبنى نهجًا تدريجيًا لامركزية كامل تقنية النطاق وزيادة ميزاتها غير المصرح بها، والهدف النهائي هو تحقيق ميزات مثل عدم الحاجة إلى الإذن وفرض الخروج.
لدينا هذا الهدف النهائي، وسنسعى لتحقيقه تدريجياً مع الحفاظ على الأمان. أحد التحديات هو أنه في بعض الأحيان يكون من الأسهل عدم الذهاب إلى الشبكة الرئيسية، لأن ذلك يعني أنه لا حاجة لإجراء انقسام صلب. قد تفكر، "أوه، سأنتظر حتى يكون كل شيء جاهز تمامًا للإصدار، حتى لا أحتاج إلى إجراء انقسام صلب، ولا يوجد عبء تقني." لكن، إذا كنت ترغب في إطلاق الشبكة الرئيسية بسرعة، يجب عليك التعامل مع هذه التحديثات المعقدة، وإصدارها بشكل متكرر. إنجاز ذلك مع الحفاظ على توفر عالي دائمًا ما يمثل تحديًا.
أعتقد أنه بعد أن يكون آلية إثبات العطل وجميع هذه الأجزاء جاهزة، سيكون هناك الكثير من التحديثات في جانب نموذج بلازما. أعتقد أنه لا يزال هناك مجال للتحسين في تقديم الالتزام الجماعي. الآن نحن نقوم بذلك ببساطة، التزام واحد لكل معاملة. والالتزام هو مجرد قيمة هاش لبيانات الإدخال المخزنة خارج السلسلة.
نحن نحتفظ بالبساطة قدر الإمكان حتى يكون المراجعة بسيطة وسريعة، ولا يوجد اختلاف كبير على OP Stack. لكن الآن هناك بعض التحسينات التي يمكن أن تجعل الأمر أرخص، مثل تنفيذ الالتزام بشكل جماعي أو تقديمها.