في هذه الحلقة الخاصة من حوار Devs on Devs، دعونا المطور الرئيسي للبروتوكول في Plasma Mode tdot( وهو أيضاً مطور Redstone )، ومؤسس مشارك في Optimism بن جونز. تعتبر Optimism الداعم الرئيسي لـ OP Stack. يسمح Plasma Mode للمطورين بالبناء على OP Stack، ولكن دون الحاجة لنشر البيانات على L1، بل يمكنهم التبديل بشكل مرن إلى مزودي البيانات خارج السلسلة، مما يوفر التكاليف ويعزز القابلية للتوسع. في هذا الحوار، استكشفوا أصل التعاون بين Redstone وOptimism، وأهمية إحياء Plasma، وضرورة إدخال البروتوكولات التجريبية إلى بيئة الإنتاج، وخارطة الطريق المستقبلية لـ Plasma Mode وOP Stack، بالإضافة إلى حماسهم لتطور مجال الألعاب الكاملة.
01. كيفية استخدام وضع Plasma لتحسين 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 خارج السلسلة؟" نأمل أن يعتمد نموذج الأمان الكامل وكل شيء على Ethereum L1. لذلك، تجنبنا حلول DA البديلة الأخرى، وقررنا تخزين البيانات في تخزين DA مركزي، ثم العثور على نموذج أمان فعال على L1.
هذا هو السبب في أننا نعيد استخدام بعض المفاهيم القديمة لـ Plasma ونضعها فوق rollup. هناك بعض الاختلافات هنا. أكبر سؤال هو كيفية تنفيذ DA خارج السلسلة وتحديات البيانات على السلسلة على OP Stack الحالي؟ هدفنا هو إجراء أقل قدر ممكن من التعديلات على OP Stack، دون التأثير على مسار rollup، لأننا لا نريد التأثير على أمان سلاسل rollup الأخرى التي تستخدم OP Stack.
عند تصميم rollup، لن تفكر في "ماذا سيحدث إذا قام شخص ما بتغيير عملية توليد البيانات لتخزين البيانات من مكان آخر؟" حتى مع هذه التغييرات، لا يزال OP Stack قويًا جدًا، ويعمل بشكل جيد خارج الصندوق. هذا هو أول تغيير قمنا به.
بعد ذلك، نحتاج إلى كتابة عقد لإنشاء هذه التحديات. هناك تحديات DA تُستخدم لإجبار البيانات على الدخول في السلسلة. هذه هي الخطوة الثانية، وهي دمج العقد في العملية. يجب علينا بناء نظام التكامل الكامل خلال عملية الاشتقاق، بحيث يمكنك اشتقاق البيانات من مصدر DA خارج السلسلة وعقد تحدي DA على L1، في حال تم تقديم البيانات إلى السلسلة خلال عملية حل التحدي.
هذه هي النقطة الجوهرية. إنها معقدة، لأننا نريد الحفاظ على أناقة الأمور وثباتها. في نفس الوقت، إنها فكرة بسيطة نسبياً. لم نحاول إعادة اختراع كل شيء أو تغيير كامل OP Stack، بل حاولنا الحفاظ على بساطة الأمور في بيئة معقدة. لذا بشكل عام، إنها رحلة هندسية رائعة جداً.
Ben: يمكنني التحدث من منظور OP. لقد ذكرت بعض الأعمال المبكرة لـ Lattice. في نفس الوقت تقريبًا، قمنا بإعادة كتابة كاملة تقريبًا لـ OP Stack من البداية إلى النهاية، وهذا الإصدار الذي أطلقنا عليه اسم Bedrock.
بشكل أساسي، بعد عامين من بناء الـrollup، نأخذ خطوة إلى الوراء ونتأمل قائلين: "حسناً، إذا كنا سنستخدم كل الخبرات التي اكتسبناها إلى أقصى حد، ماذا سيكون شكل ذلك؟" وقد تطور هذا إلى المكتبة البرمجية التي تُعرف في النهاية باسم Bedrock، وهي أكبر ترقية قمنا بها للشبكة.
في ذلك الوقت، تعاوننا معكم في مشروع يسمى OPCraft، وأعتقد أن Biomes هو الوريث الروحي له، وكانت تلك أكثر مرة استمتعنا فيها باللعب على السلسلة. في نفس الوقت، تنفسنا الصعداء لأن الآخرين يمكنهم أيضًا استخدام OP Stack للتطوير. أعتقد أن نقطة التحول المهمة الأخرى في التوسع خلال السنوات القليلة الماضية هي أن العديد من الأشخاص يمكنهم تشغيل السلسلة.
ليس فقط أولئك الذين قاموا بتطوير مكتبات كود ضخمة ومعقدة هم من يمكنهم القيام بذلك. عندما بدأنا التعاون، كان من الرائع رؤية الآخرين قادرين على تولي هذه المكتبة و القيام ببعض الأمور الرائعة حقًا. ثم رؤية هذا الوضع يتوسع في التطبيق العملي إلى Plasma، كان أمرًا رائعًا. يمكنني حتى التحدث قليلاً عن تلك الفترة التاريخية.
قبل أن تصبح Optimism هي Optimism، كنا في الواقع نبحث في تقنية تسمى Plasma. كانت المهمة التي تحملناها في ذلك الوقت تفوق بكثير قدرة مجتمع التوسع في ذلك الوقت. التصميم الذي قد تراه في تصميم Plasma المبكر قد لا يكون له علاقة مباشرة بـ Plasma اليوم.
اليوم Plasma أسهل بكثير. سننظر إلى إثباتات التحقق من الحالة والتحديات بشكل منفصل عن تحديات البيانات. في النهاية، أدركنا منذ بضع سنوات أن Rollups أسهل بكثير من Plasma. أعتقد أن استنتاج المجتمع في ذلك الوقت كان "Plasma ماتت". هذه كانت نكتة في تاريخ توسيع نطاق Ethereum في تلك الفترة.
لكننا دائما نعتقد أن "Plasma لم تمت، فقط يمكننا تجربة مهمة أبسط أولا". الآن نحن نستخدم مصطلحات مختلفة. على سبيل المثال، في ذلك الوقت كانت هناك مفاهيم مثل exits(، والآن يمكنك أن تنظر إلى الوراء وتقول "أوه، كانت تلك تحدي توفر البيانات مع بعض الخطوات الإضافية". لذلك من الرائع رؤية أن OP Stack لا يُستخدم فقط من قبل الآخرين، بل تطور إلى شيء حاولنا القيام به في البداية ولكن بطريقة فوضوية وغير ناضجة للغاية، إنه حقا مدهش. لقد أكملنا دورة كاملة، وأنتم قمتم بعمل تجريدي رائع حولها، وجعلتم الأمر يعمل بطريقة معقولة وعقلانية. هذا حقا رائع.
02. الأهم هو الدخول إلى بيئة الإنتاج في أقرب وقت ممكن
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. ولكن الآن هناك بعض التحسينات التي يمكن أن تجعل ذلك أرخص، مثل تجميع الالتزامات أو تقديمها في blob، أو اعتماد طرق مختلفة أخرى. لذا، سنبحث بالتأكيد في ذلك لتقليل تكاليف L1.
هذا شيء نحن متحمسون له حقًا. بالطبع، نحن نتطلع أيضًا إلى جميع المحتويات المتعلقة بالتشغيل البيني القادمة، والقدرة على التفاعل بين جميع الشبكات. سيكون من الرائع معرفة كيف ستكون هذه خطوة كبيرة للمستخدمين.
الكثير من هذه الأعمال يجب أن يتم تنفيذها من قبلكم. لكننا نرغب في فهم كيف تبدو هذه الأمور تحت وضع Plasma، ولديها فرضيات أمان مختلفة.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 16
أعجبني
16
6
مشاركة
تعليق
0/400
GateUser-0717ab66
· منذ 5 س
كم هو السعر؟
شاهد النسخة الأصليةرد0
ImpermanentPhobia
· منذ 19 س
فريق الأجواء جاء لمشاهدة المسرحية
شاهد النسخة الأصليةرد0
just_another_wallet
· منذ 20 س
هل يمكن أن ينقذ البلازما؟
شاهد النسخة الأصليةرد0
BlockchainDecoder
· منذ 20 س
من الناحية التقنية، هل من المعقول حقًا اختيار نشر بيانات L1 الانتقائية كحل وسط؟
شاهد النسخة الأصليةرد0
GetRichLeek
· منذ 20 س
الترصد في الكمينop半年了 到底能不能爆呀
شاهد النسخة الأصليةرد0
SchrodingerGas
· منذ 20 س
من سيحسب كم يوفر هذا الشيء من الغاز انتظر حتى أرسم نموذجًا
محادثة مبتكري OP Stack: كيف يغير وضع Plasma مستقبل ألعاب السلسلة
المطورون على المطورين: محادثة TDOT وبن جونز
في هذه الحلقة الخاصة من حوار Devs on Devs، دعونا المطور الرئيسي للبروتوكول في Plasma Mode tdot( وهو أيضاً مطور Redstone )، ومؤسس مشارك في Optimism بن جونز. تعتبر Optimism الداعم الرئيسي لـ OP Stack. يسمح Plasma Mode للمطورين بالبناء على OP Stack، ولكن دون الحاجة لنشر البيانات على L1، بل يمكنهم التبديل بشكل مرن إلى مزودي البيانات خارج السلسلة، مما يوفر التكاليف ويعزز القابلية للتوسع. في هذا الحوار، استكشفوا أصل التعاون بين Redstone وOptimism، وأهمية إحياء Plasma، وضرورة إدخال البروتوكولات التجريبية إلى بيئة الإنتاج، وخارطة الطريق المستقبلية لـ Plasma Mode وOP Stack، بالإضافة إلى حماسهم لتطور مجال الألعاب الكاملة.
01. كيفية استخدام وضع Plasma لتحسين 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 خارج السلسلة؟" نأمل أن يعتمد نموذج الأمان الكامل وكل شيء على Ethereum L1. لذلك، تجنبنا حلول DA البديلة الأخرى، وقررنا تخزين البيانات في تخزين DA مركزي، ثم العثور على نموذج أمان فعال على L1.
هذا هو السبب في أننا نعيد استخدام بعض المفاهيم القديمة لـ Plasma ونضعها فوق rollup. هناك بعض الاختلافات هنا. أكبر سؤال هو كيفية تنفيذ DA خارج السلسلة وتحديات البيانات على السلسلة على OP Stack الحالي؟ هدفنا هو إجراء أقل قدر ممكن من التعديلات على OP Stack، دون التأثير على مسار rollup، لأننا لا نريد التأثير على أمان سلاسل rollup الأخرى التي تستخدم OP Stack.
عند تصميم rollup، لن تفكر في "ماذا سيحدث إذا قام شخص ما بتغيير عملية توليد البيانات لتخزين البيانات من مكان آخر؟" حتى مع هذه التغييرات، لا يزال OP Stack قويًا جدًا، ويعمل بشكل جيد خارج الصندوق. هذا هو أول تغيير قمنا به.
بعد ذلك، نحتاج إلى كتابة عقد لإنشاء هذه التحديات. هناك تحديات DA تُستخدم لإجبار البيانات على الدخول في السلسلة. هذه هي الخطوة الثانية، وهي دمج العقد في العملية. يجب علينا بناء نظام التكامل الكامل خلال عملية الاشتقاق، بحيث يمكنك اشتقاق البيانات من مصدر DA خارج السلسلة وعقد تحدي DA على L1، في حال تم تقديم البيانات إلى السلسلة خلال عملية حل التحدي.
هذه هي النقطة الجوهرية. إنها معقدة، لأننا نريد الحفاظ على أناقة الأمور وثباتها. في نفس الوقت، إنها فكرة بسيطة نسبياً. لم نحاول إعادة اختراع كل شيء أو تغيير كامل OP Stack، بل حاولنا الحفاظ على بساطة الأمور في بيئة معقدة. لذا بشكل عام، إنها رحلة هندسية رائعة جداً.
Ben: يمكنني التحدث من منظور OP. لقد ذكرت بعض الأعمال المبكرة لـ Lattice. في نفس الوقت تقريبًا، قمنا بإعادة كتابة كاملة تقريبًا لـ OP Stack من البداية إلى النهاية، وهذا الإصدار الذي أطلقنا عليه اسم Bedrock.
بشكل أساسي، بعد عامين من بناء الـrollup، نأخذ خطوة إلى الوراء ونتأمل قائلين: "حسناً، إذا كنا سنستخدم كل الخبرات التي اكتسبناها إلى أقصى حد، ماذا سيكون شكل ذلك؟" وقد تطور هذا إلى المكتبة البرمجية التي تُعرف في النهاية باسم Bedrock، وهي أكبر ترقية قمنا بها للشبكة.
في ذلك الوقت، تعاوننا معكم في مشروع يسمى OPCraft، وأعتقد أن Biomes هو الوريث الروحي له، وكانت تلك أكثر مرة استمتعنا فيها باللعب على السلسلة. في نفس الوقت، تنفسنا الصعداء لأن الآخرين يمكنهم أيضًا استخدام OP Stack للتطوير. أعتقد أن نقطة التحول المهمة الأخرى في التوسع خلال السنوات القليلة الماضية هي أن العديد من الأشخاص يمكنهم تشغيل السلسلة.
ليس فقط أولئك الذين قاموا بتطوير مكتبات كود ضخمة ومعقدة هم من يمكنهم القيام بذلك. عندما بدأنا التعاون، كان من الرائع رؤية الآخرين قادرين على تولي هذه المكتبة و القيام ببعض الأمور الرائعة حقًا. ثم رؤية هذا الوضع يتوسع في التطبيق العملي إلى Plasma، كان أمرًا رائعًا. يمكنني حتى التحدث قليلاً عن تلك الفترة التاريخية.
قبل أن تصبح Optimism هي Optimism، كنا في الواقع نبحث في تقنية تسمى Plasma. كانت المهمة التي تحملناها في ذلك الوقت تفوق بكثير قدرة مجتمع التوسع في ذلك الوقت. التصميم الذي قد تراه في تصميم Plasma المبكر قد لا يكون له علاقة مباشرة بـ Plasma اليوم.
اليوم Plasma أسهل بكثير. سننظر إلى إثباتات التحقق من الحالة والتحديات بشكل منفصل عن تحديات البيانات. في النهاية، أدركنا منذ بضع سنوات أن Rollups أسهل بكثير من Plasma. أعتقد أن استنتاج المجتمع في ذلك الوقت كان "Plasma ماتت". هذه كانت نكتة في تاريخ توسيع نطاق Ethereum في تلك الفترة.
لكننا دائما نعتقد أن "Plasma لم تمت، فقط يمكننا تجربة مهمة أبسط أولا". الآن نحن نستخدم مصطلحات مختلفة. على سبيل المثال، في ذلك الوقت كانت هناك مفاهيم مثل exits(، والآن يمكنك أن تنظر إلى الوراء وتقول "أوه، كانت تلك تحدي توفر البيانات مع بعض الخطوات الإضافية". لذلك من الرائع رؤية أن OP Stack لا يُستخدم فقط من قبل الآخرين، بل تطور إلى شيء حاولنا القيام به في البداية ولكن بطريقة فوضوية وغير ناضجة للغاية، إنه حقا مدهش. لقد أكملنا دورة كاملة، وأنتم قمتم بعمل تجريدي رائع حولها، وجعلتم الأمر يعمل بطريقة معقولة وعقلانية. هذا حقا رائع.
02. الأهم هو الدخول إلى بيئة الإنتاج في أقرب وقت ممكن
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. ولكن الآن هناك بعض التحسينات التي يمكن أن تجعل ذلك أرخص، مثل تجميع الالتزامات أو تقديمها في blob، أو اعتماد طرق مختلفة أخرى. لذا، سنبحث بالتأكيد في ذلك لتقليل تكاليف L1.
هذا شيء نحن متحمسون له حقًا. بالطبع، نحن نتطلع أيضًا إلى جميع المحتويات المتعلقة بالتشغيل البيني القادمة، والقدرة على التفاعل بين جميع الشبكات. سيكون من الرائع معرفة كيف ستكون هذه خطوة كبيرة للمستخدمين.
الكثير من هذه الأعمال يجب أن يتم تنفيذها من قبلكم. لكننا نرغب في فهم كيف تبدو هذه الأمور تحت وضع Plasma، ولديها فرضيات أمان مختلفة.
بن: