"في هذه الحلقة الخاصة من Devs on Devs، دعونا نرحب بالمطور الرئيسي لبروتوكول Plasma Mode tdot( وأيضًا المطور لـ Redstone )، بالإضافة إلى المؤسس المشارك لـ Optimism بن جونز. تعد Optimism المحرك الرئيسي لـ OP Stack. يسمح Plasma Mode للمطورين بالبناء على OP Stack دون الحاجة إلى نشر البيانات على L1، بل يمكنهم التبديل بمرونة إلى مزودي البيانات خارج السلسلة، مما يوفر التكاليف ويزيد من قابلية التوسع. في المحادثة، استكشفوا أصول التعاون بين Redstone وOptimism، وأهمية إحياء Plasma، وضرورة إدخال البروتوكولات التجريبية إلى بيئة الإنتاج، وخارطة الطريق المستقبلية لـ Plasma Mode وOP Stack، بالإضافة إلى حماسهم لتطور مجال الألعاب على السلسلة بالكامل."
كيفية تحسين OP Stack باستخدام وضع Plasma
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). في الواقع، تم الإشارة بالفعل في الوثائق الأولية لـ OP Stack إلى استكشاف Alt DA.
لذا طرحنا على أنفسنا، "ماذا لو بدأنا من 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 بالكامل، بل حاولنا الحفاظ على الأمور بسيطة في بيئة معقدة. لذا، بشكل عام، كانت هذه رحلة هندسية رائعة جداً.
بين: يمكنني التحدث من وجهة نظر OP. لقد ذكرت بعض الأعمال المبكرة لـ Lattice. في نفس الوقت تقريبًا، قامت Optimism بإعادة كتابة كاملة تقريبًا لـ OP Stack، وأطلقنا على هذا الإصدار اسم Bedrock.
بشكل أساسي، بعد بناء rollup لمدة عامين، نأخذ خطوة إلى الوراء ونتأمل قائلين: "حسناً، إذا كنا سنستخدم كل الخبرات التي تعلمناها إلى أقصى حد، كيف ستبدو هذه التجربة؟" وقد تطور هذا إلى المكتبة البرمجية التي تُعرف في النهاية باسم Bedrock، وهي أكبر ترقية قمنا بها للشبكة.
في ذلك الوقت، تعاوننا معكم في مشروع يسمى OPCraft، وأعتقد أن Biomes هو الوريث الروحي له، كانت هذه هي المرة التي استمتعنا فيها باللعب على السلسلة أكثر. في نفس الوقت، شعرنا بالارتياح لأن الآخرين يمكنهم أيضًا استخدام OP Stack للتطوير. أعتقد أن نقطة التحول المهمة الأخرى في التوسع على مدار السنوات القليلة الماضية هي أن الكثير من الناس يمكنهم تشغيل السلسلة.
ليس فقط أولئك الذين طوروا مكتبات التعليمات البرمجية الضخمة والمعقدة هم من يمكنهم القيام بذلك. عندما بدأنا التعاون، كان من الرائع رؤية الآخرين يستطيعون تولي هذه المكتبة البرمجية والقيام بأشياء مذهلة حقًا، وهذا كان تأكيدًا كبيرًا. ثم رؤية هذا الوضع يتوسع في التطبيق العملي على Plasma، كان حقًا رائعًا. يمكنني حتى التحدث قليلاً عن تلك الفترة التاريخية.
قبل أن تصبح Optimism Optimism، كنا في الواقع نبحث في تقنية تُسمى Plasma. كانت المهمة التي تحملناها آنذاك تتجاوز بكثير قدرة مجتمع التوسع في ذلك الوقت. التصميم الذي رأيته في التصميم المبكر لـ Plasma، قد لا يكون له علاقة مباشرة بـ Plasma اليوم.
اليوم Plasma أسهل بكثير. سننظر إلى إثبات حالة التحقق والتحدي بشكل منفصل عن تحديات البيانات. في النهاية، أدركنا قبل بضع سنوات أن Rollups أسهل بكثير من Plasma. أعتقد أن استنتاج المجتمع في ذلك الوقت كان "Plasma ميتة". كانت هذه نكتة في تاريخ توسيع Ethereum في تلك الفترة.
لكننا دائما نعتقد أن "Plasma لم تموت، بل يمكننا فقط تجربة مهمة أبسط". الآن نحن نستخدم مصطلحات مختلفة. على سبيل المثال، كانت هناك مفاهيم مثل exits( في ذلك الوقت، الآن يمكنك أن تعود وتنظر وتقول "أوه، كانت تلك تحديات توفر البيانات مع بعض الخطوات الإضافية". لذلك من الرائع رؤية أن OP Stack لا يستخدمه الآخرون فقط، بل تطور إلى شيء حاولنا القيام به في البداية ولكن بطريقة فوضوية وغير ناضجة للغاية. لقد أكملنا دورة كاملة، وأنتم قد قمتم بعمل تجريدي رائع حولها، وجعلتموها تعمل بطريقة معقولة وعقلانية. هذا حقا رائع.
الأهم هو الدخول إلى بيئة الإنتاج في أقرب وقت ممكن
tdot: لا تزال هناك بعض التحديات والمشاكل غير المحلولة في وضع Plasma، ونحن نعمل على حلها. المفتاح هو كيفية تجنب قضاء ما يصل إلى عشر سنوات في هذا؟ هل تفهم ما أعنيه؟ نحتاج إلى الوصول إلى مرحلة يمكننا فيها تقديم النتائج في أسرع وقت ممكن.
هذه هي فكرتنا. لدينا العديد من التطبيقات المبنية على MUD التي نريد إطلاقها على الشبكة الرئيسية على الفور. نحتاج إلى إعداد شبكة رئيسية لهذه الألعاب في أقرب وقت ممكن. الناس في انتظار ذلك، وهم مستعدون. تحتاج إلى سلسلة يمكن إطلاقها بسرعة وتشغيلها لتشغيل جميع هذه التطبيقات، حتى تتمكن هذه التطبيقات من التطور بشكل متوازي أثناء حل مشكلاتنا، لتصبح أفضل. من البحث والتطوير إلى تحقيق الاستقرار الإنتاجي يستغرق وقتًا طويلاً.
لنشر شيء ما على الشبكة الرئيسية، وجعله بدون إذن، ومستقر وآمن، يتطلب ذلك الكثير من الوقت. إن رؤية العملية الكاملة لتحقيق هذا الهدف كانت مثيرة للإعجاب. هذا هو السبب في أننا بحاجة إلى الحفاظ على مستوى عالٍ من المرونة، لأن هناك الكثير من الأمور. النظام البيئي بأكمله يتطور بسرعة كبيرة. أعتقد أن الجميع يقدمون الكثير من الابتكارات. هذا هو السبب في أنه يجب عليك مواكبة ذلك، لكن لا يمكنك المساومة على الأمان والأداء، وإلا فلن يعمل النظام.
بن: أو لنقل العبء الفني. المبدأ الذي ذكرته حول التعديلات الأدنى هو أحد المبادئ الأساسية التي اتبعناها أثناء إعادة كتابة Bedrock. لقد تحدثت عن إعادة الكتابة الشاملة من البداية إلى النهاية، ولكن الأهم من ذلك أننا قللنا حوالي 50,000 سطر من الشيفرة، وهذا بحد ذاته قوي جداً. لأنك محق، هذه الأمور صعبة جداً.
كل سطر إضافي من الشيفرة يجعلك أبعد عن بيئة الإنتاج، مما يجعل من الصعب اختبار الأمور في الممارسة العملية، ويزيد من فرص الأخطاء. لذا، نحن نقدر جميع جهودكم في دفع هذه العملية، وخاصة المساهمات التي قدمتموها لنموذج التشغيل الجديد لـ OP Stack.
tdot: OP Stack بالتأكيد أنشأ طريقة تتيح لك التقدم بسرعة في مثل هذه الأمور. التنسيق بين الجميع أمر صعب للغاية، لأننا بوضوح شركتان مختلفتان. في Lattice، نحن نبني لعبة، محرك لعبة، وسلسلة.
أنتم تبنون مئات وآلاف الأشياء، وتقدمون كل هذه المنتجات بشكل دوري. من حيث التنسيق، هذا ليس بالأمر السهل حقًا.
بن: نعم، لا يزال هناك طريق طويل يجب قطعه. ولكن هذه هي الجاذبية الأساسية للتجزئة. بالنسبة لي، من وجهة نظر OP Stack، هذه واحدة من أكثر الأشياء إثارة، ناهيك عن الألعاب المذهلة والعوالم الافتراضية التي تُبنى حاليًا على Redstone. من منظور OP Stack فقط، هذه مثال قوي جدًا يثبت أن العديد من مطوري النواة الممتازين قد انضموا وأجروا تحسينات على هذه المجموعة، وهذا أمر رائع.
هذه هي المرة الأولى، يمكنك من خلال قيمة بوليانية رئيسية أن تغير خصائص النظام بشكل كبير. القدرة على القيام بذلك تمامًا، كما قلت، لا يزال هناك طريق طويل لنقطعه. ولكن حتى الاقتراب من القيام بذلك بفعالية يتطلب دعمًا معياريًا، أليس كذلك؟ بالنسبة لنا، رؤية أنكم حققتم ذلك دون الحاجة على سبيل المثال إلى إعادة كتابة L2 Geth، كانت حقًا مصدر ارتياح. بالنسبة لي، هذا يثبت أن المعيارية تعمل.
tdot: الوضع الآن أصبح أفضل. من هذا المثال، لقد جعلتم كل شيء وحدات صغيرة مستقلة يمكن تعديلها وتغيير خصائصها. لذلك أنا متحمس جداً لرؤية ما هي الميزات الجديدة التي سيتم دمجها. أتذكر أننا كنا نشعر بالقلق من أن لدينا انقساماً يحتوي على جميع التغييرات المتعلقة بـ OP Stack، والتي تحتاج إلى دمجها في الخط الرئيسي. كنا نفكر في ذلك، "يا إلهي، سيكون جنونياً مراجعة كل شيء."
كان علينا تقسيمها إلى أجزاء أصغر، لكن العملية برمتها سارت بسلاسة كبيرة. كانت أجواء التعاون مع الفريق جيدة جداً، لذا كانت عملية المراجعة ممتعة أيضاً. شعرت أن كل شيء يأتي بشكل طبيعي. وأعتقد أن العملية كانت سريعة جداً في مراجعة وحل بعض المشاكل المحتملة. كل شيء سار بطريقة غير متوقعة.
بن: هذا رائع حقًا. هذا العام، أحد أولوياتنا هو إنشاء مسارات المساهمة لـ OP Stack. لذلك، أنا ممتن جدًا لمشاركتكم في الاختبار ودفع هذه العمليات. أنا سعيد لأن هذه العمليات لم تكن مرهقة، وأننا حققنا بعض النتائج. وعلى ذكر ذلك، أنا فضولي جدًا، من وجهة نظرك، كيف ستتطور هذه الأعمال في المستقبل؟ ما الذي تتطلع إليه أكثر في تطويره؟
tdot: هناك العديد من الاتجاهات المختلفة للعمل. يتمحور الأمر بشكل رئيسي حول تكامل آلية إثبات الفشل. نحن نتبنى نهجًا تدريجيًا لامركزية كامل مجموعة التقنيات وزيادة ميزاتها غير القابلة للإذن، والهدف النهائي هو تحقيق ميزات مثل عدم الحاجة إلى إذن والخروج الإلزامي.
لدينا هذا الهدف النهائي، ونعمل على تحقيقه تدريجياً مع الحفاظ على الأمان. أحد التحديات هو أنه في بعض الأحيان يكون من الأسهل عدم الانتقال إلى الشبكة الرئيسية، لأن ذلك يعني أنه لا حاجة لإجراء انقسام صعب. قد تفكر، "أوه، سأنتظر حتى تكون كل شيء جاهز تماماً للإطلاق، حتى لا أحتاج إلى إجراء انقسام صعب، ولا أتحمل عبء تقني." ولكن، إذا كنت تريد الانتقال بسرعة إلى الشبكة الرئيسية، فعليك التعامل مع هذه التحديثات المعقدة، وإطلاقها بشكل متكرر. إن القيام بذلك مع الحفاظ على توفر عالي دائماً ما يكون تحدياً.
أعتقد أنه بعد أن يتم إعداد آلية إثبات الفشل وكل هذه الأجزاء، سيكون هناك الكثير من التحديثات في جانب نموذج بلازما. أعتقد أنه لا يزال هناك مجال للتحسين في تقديم الالتزامات بالجملة. حاليا نحن نفعلها بشكل بسيط، كل معاملة لديها التزام واحد. والالتزام هو مجرد قيمة هاش لبيانات المدخلات المخزنة خارج السلسلة.
نحن نحتفظ بالبساطة قدر الإمكان مؤقتاً، بحيث يمكن أن يكون التدقيق بسيطاً وسريعاً، وبدون اختلاف كبير على OP Stack. لكن الآن هناك بعض التحسينات التي يمكن أن تجعلها أقل تكلفة، مثل معالجة الالتزامات بشكل مجمع أو تقديمها في blob، أو استخدام طرق مختلفة أخرى. لذلك، سنقوم بالتأكيد بدراسة ذلك لتقليل تكاليف L1.
هذا شيء مثير للغاية بالنسبة لنا. بالطبع، نحن أيضاً متحمسون جداً لكل ما يتعلق بالتشغيل المتداخل القادم، وأن نتمكن من التفاعل بين جميع الشبكات. سيكون من الرائع أن نكتشف أن هذا سيكون تقدماً هائلاً للمستخدمين.
الكثير من هذه المهام بالتأكيد يجب أن تقوموا بها. ولكننا نأمل في فهم كيف تبدو هذه في وضع Plasma ، ولها افتراضات أمان مختلفة.
بن: عندما نتحدث عن ذلك، ستكون هذه اختباراً آخر لوحدة OP Stack.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 15
أعجبني
15
6
مشاركة
تعليق
0/400
YieldHunter
· منذ 20 س
تقنيًا... لست مقتنعًا بموثوقية البيانات خارج السلسلة،
شاهد النسخة الأصليةرد0
DaoResearcher
· منذ 20 س
من استنتاج مثلث توفر البيانات، هذه الفكرة رائعة حقًا
ناقش المؤسسون المشاركون في Optimism مع مطوري Plasma Mode مستقبل OP Stack
المطورون على المطورين: تحدث إلى tdot و Ben Jones
"في هذه الحلقة الخاصة من Devs on Devs، دعونا نرحب بالمطور الرئيسي لبروتوكول Plasma Mode tdot( وأيضًا المطور لـ Redstone )، بالإضافة إلى المؤسس المشارك لـ Optimism بن جونز. تعد Optimism المحرك الرئيسي لـ OP Stack. يسمح Plasma Mode للمطورين بالبناء على OP Stack دون الحاجة إلى نشر البيانات على L1، بل يمكنهم التبديل بمرونة إلى مزودي البيانات خارج السلسلة، مما يوفر التكاليف ويزيد من قابلية التوسع. في المحادثة، استكشفوا أصول التعاون بين Redstone وOptimism، وأهمية إحياء Plasma، وضرورة إدخال البروتوكولات التجريبية إلى بيئة الإنتاج، وخارطة الطريق المستقبلية لـ Plasma Mode وOP Stack، بالإضافة إلى حماسهم لتطور مجال الألعاب على السلسلة بالكامل."
كيفية تحسين OP Stack باستخدام وضع Plasma
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). في الواقع، تم الإشارة بالفعل في الوثائق الأولية لـ OP Stack إلى استكشاف Alt DA.
لذا طرحنا على أنفسنا، "ماذا لو بدأنا من 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 بالكامل، بل حاولنا الحفاظ على الأمور بسيطة في بيئة معقدة. لذا، بشكل عام، كانت هذه رحلة هندسية رائعة جداً.
بين: يمكنني التحدث من وجهة نظر OP. لقد ذكرت بعض الأعمال المبكرة لـ Lattice. في نفس الوقت تقريبًا، قامت Optimism بإعادة كتابة كاملة تقريبًا لـ OP Stack، وأطلقنا على هذا الإصدار اسم Bedrock.
بشكل أساسي، بعد بناء rollup لمدة عامين، نأخذ خطوة إلى الوراء ونتأمل قائلين: "حسناً، إذا كنا سنستخدم كل الخبرات التي تعلمناها إلى أقصى حد، كيف ستبدو هذه التجربة؟" وقد تطور هذا إلى المكتبة البرمجية التي تُعرف في النهاية باسم Bedrock، وهي أكبر ترقية قمنا بها للشبكة.
في ذلك الوقت، تعاوننا معكم في مشروع يسمى OPCraft، وأعتقد أن Biomes هو الوريث الروحي له، كانت هذه هي المرة التي استمتعنا فيها باللعب على السلسلة أكثر. في نفس الوقت، شعرنا بالارتياح لأن الآخرين يمكنهم أيضًا استخدام OP Stack للتطوير. أعتقد أن نقطة التحول المهمة الأخرى في التوسع على مدار السنوات القليلة الماضية هي أن الكثير من الناس يمكنهم تشغيل السلسلة.
ليس فقط أولئك الذين طوروا مكتبات التعليمات البرمجية الضخمة والمعقدة هم من يمكنهم القيام بذلك. عندما بدأنا التعاون، كان من الرائع رؤية الآخرين يستطيعون تولي هذه المكتبة البرمجية والقيام بأشياء مذهلة حقًا، وهذا كان تأكيدًا كبيرًا. ثم رؤية هذا الوضع يتوسع في التطبيق العملي على Plasma، كان حقًا رائعًا. يمكنني حتى التحدث قليلاً عن تلك الفترة التاريخية.
قبل أن تصبح Optimism Optimism، كنا في الواقع نبحث في تقنية تُسمى Plasma. كانت المهمة التي تحملناها آنذاك تتجاوز بكثير قدرة مجتمع التوسع في ذلك الوقت. التصميم الذي رأيته في التصميم المبكر لـ Plasma، قد لا يكون له علاقة مباشرة بـ Plasma اليوم.
اليوم Plasma أسهل بكثير. سننظر إلى إثبات حالة التحقق والتحدي بشكل منفصل عن تحديات البيانات. في النهاية، أدركنا قبل بضع سنوات أن Rollups أسهل بكثير من Plasma. أعتقد أن استنتاج المجتمع في ذلك الوقت كان "Plasma ميتة". كانت هذه نكتة في تاريخ توسيع Ethereum في تلك الفترة.
لكننا دائما نعتقد أن "Plasma لم تموت، بل يمكننا فقط تجربة مهمة أبسط". الآن نحن نستخدم مصطلحات مختلفة. على سبيل المثال، كانت هناك مفاهيم مثل exits( في ذلك الوقت، الآن يمكنك أن تعود وتنظر وتقول "أوه، كانت تلك تحديات توفر البيانات مع بعض الخطوات الإضافية". لذلك من الرائع رؤية أن OP Stack لا يستخدمه الآخرون فقط، بل تطور إلى شيء حاولنا القيام به في البداية ولكن بطريقة فوضوية وغير ناضجة للغاية. لقد أكملنا دورة كاملة، وأنتم قد قمتم بعمل تجريدي رائع حولها، وجعلتموها تعمل بطريقة معقولة وعقلانية. هذا حقا رائع.
الأهم هو الدخول إلى بيئة الإنتاج في أقرب وقت ممكن
tdot: لا تزال هناك بعض التحديات والمشاكل غير المحلولة في وضع Plasma، ونحن نعمل على حلها. المفتاح هو كيفية تجنب قضاء ما يصل إلى عشر سنوات في هذا؟ هل تفهم ما أعنيه؟ نحتاج إلى الوصول إلى مرحلة يمكننا فيها تقديم النتائج في أسرع وقت ممكن.
هذه هي فكرتنا. لدينا العديد من التطبيقات المبنية على MUD التي نريد إطلاقها على الشبكة الرئيسية على الفور. نحتاج إلى إعداد شبكة رئيسية لهذه الألعاب في أقرب وقت ممكن. الناس في انتظار ذلك، وهم مستعدون. تحتاج إلى سلسلة يمكن إطلاقها بسرعة وتشغيلها لتشغيل جميع هذه التطبيقات، حتى تتمكن هذه التطبيقات من التطور بشكل متوازي أثناء حل مشكلاتنا، لتصبح أفضل. من البحث والتطوير إلى تحقيق الاستقرار الإنتاجي يستغرق وقتًا طويلاً.
لنشر شيء ما على الشبكة الرئيسية، وجعله بدون إذن، ومستقر وآمن، يتطلب ذلك الكثير من الوقت. إن رؤية العملية الكاملة لتحقيق هذا الهدف كانت مثيرة للإعجاب. هذا هو السبب في أننا بحاجة إلى الحفاظ على مستوى عالٍ من المرونة، لأن هناك الكثير من الأمور. النظام البيئي بأكمله يتطور بسرعة كبيرة. أعتقد أن الجميع يقدمون الكثير من الابتكارات. هذا هو السبب في أنه يجب عليك مواكبة ذلك، لكن لا يمكنك المساومة على الأمان والأداء، وإلا فلن يعمل النظام.
بن: أو لنقل العبء الفني. المبدأ الذي ذكرته حول التعديلات الأدنى هو أحد المبادئ الأساسية التي اتبعناها أثناء إعادة كتابة Bedrock. لقد تحدثت عن إعادة الكتابة الشاملة من البداية إلى النهاية، ولكن الأهم من ذلك أننا قللنا حوالي 50,000 سطر من الشيفرة، وهذا بحد ذاته قوي جداً. لأنك محق، هذه الأمور صعبة جداً.
كل سطر إضافي من الشيفرة يجعلك أبعد عن بيئة الإنتاج، مما يجعل من الصعب اختبار الأمور في الممارسة العملية، ويزيد من فرص الأخطاء. لذا، نحن نقدر جميع جهودكم في دفع هذه العملية، وخاصة المساهمات التي قدمتموها لنموذج التشغيل الجديد لـ OP Stack.
tdot: OP Stack بالتأكيد أنشأ طريقة تتيح لك التقدم بسرعة في مثل هذه الأمور. التنسيق بين الجميع أمر صعب للغاية، لأننا بوضوح شركتان مختلفتان. في Lattice، نحن نبني لعبة، محرك لعبة، وسلسلة.
أنتم تبنون مئات وآلاف الأشياء، وتقدمون كل هذه المنتجات بشكل دوري. من حيث التنسيق، هذا ليس بالأمر السهل حقًا.
بن: نعم، لا يزال هناك طريق طويل يجب قطعه. ولكن هذه هي الجاذبية الأساسية للتجزئة. بالنسبة لي، من وجهة نظر OP Stack، هذه واحدة من أكثر الأشياء إثارة، ناهيك عن الألعاب المذهلة والعوالم الافتراضية التي تُبنى حاليًا على Redstone. من منظور OP Stack فقط، هذه مثال قوي جدًا يثبت أن العديد من مطوري النواة الممتازين قد انضموا وأجروا تحسينات على هذه المجموعة، وهذا أمر رائع.
هذه هي المرة الأولى، يمكنك من خلال قيمة بوليانية رئيسية أن تغير خصائص النظام بشكل كبير. القدرة على القيام بذلك تمامًا، كما قلت، لا يزال هناك طريق طويل لنقطعه. ولكن حتى الاقتراب من القيام بذلك بفعالية يتطلب دعمًا معياريًا، أليس كذلك؟ بالنسبة لنا، رؤية أنكم حققتم ذلك دون الحاجة على سبيل المثال إلى إعادة كتابة L2 Geth، كانت حقًا مصدر ارتياح. بالنسبة لي، هذا يثبت أن المعيارية تعمل.
tdot: الوضع الآن أصبح أفضل. من هذا المثال، لقد جعلتم كل شيء وحدات صغيرة مستقلة يمكن تعديلها وتغيير خصائصها. لذلك أنا متحمس جداً لرؤية ما هي الميزات الجديدة التي سيتم دمجها. أتذكر أننا كنا نشعر بالقلق من أن لدينا انقساماً يحتوي على جميع التغييرات المتعلقة بـ OP Stack، والتي تحتاج إلى دمجها في الخط الرئيسي. كنا نفكر في ذلك، "يا إلهي، سيكون جنونياً مراجعة كل شيء."
كان علينا تقسيمها إلى أجزاء أصغر، لكن العملية برمتها سارت بسلاسة كبيرة. كانت أجواء التعاون مع الفريق جيدة جداً، لذا كانت عملية المراجعة ممتعة أيضاً. شعرت أن كل شيء يأتي بشكل طبيعي. وأعتقد أن العملية كانت سريعة جداً في مراجعة وحل بعض المشاكل المحتملة. كل شيء سار بطريقة غير متوقعة.
بن: هذا رائع حقًا. هذا العام، أحد أولوياتنا هو إنشاء مسارات المساهمة لـ OP Stack. لذلك، أنا ممتن جدًا لمشاركتكم في الاختبار ودفع هذه العمليات. أنا سعيد لأن هذه العمليات لم تكن مرهقة، وأننا حققنا بعض النتائج. وعلى ذكر ذلك، أنا فضولي جدًا، من وجهة نظرك، كيف ستتطور هذه الأعمال في المستقبل؟ ما الذي تتطلع إليه أكثر في تطويره؟
tdot: هناك العديد من الاتجاهات المختلفة للعمل. يتمحور الأمر بشكل رئيسي حول تكامل آلية إثبات الفشل. نحن نتبنى نهجًا تدريجيًا لامركزية كامل مجموعة التقنيات وزيادة ميزاتها غير القابلة للإذن، والهدف النهائي هو تحقيق ميزات مثل عدم الحاجة إلى إذن والخروج الإلزامي.
لدينا هذا الهدف النهائي، ونعمل على تحقيقه تدريجياً مع الحفاظ على الأمان. أحد التحديات هو أنه في بعض الأحيان يكون من الأسهل عدم الانتقال إلى الشبكة الرئيسية، لأن ذلك يعني أنه لا حاجة لإجراء انقسام صعب. قد تفكر، "أوه، سأنتظر حتى تكون كل شيء جاهز تماماً للإطلاق، حتى لا أحتاج إلى إجراء انقسام صعب، ولا أتحمل عبء تقني." ولكن، إذا كنت تريد الانتقال بسرعة إلى الشبكة الرئيسية، فعليك التعامل مع هذه التحديثات المعقدة، وإطلاقها بشكل متكرر. إن القيام بذلك مع الحفاظ على توفر عالي دائماً ما يكون تحدياً.
أعتقد أنه بعد أن يتم إعداد آلية إثبات الفشل وكل هذه الأجزاء، سيكون هناك الكثير من التحديثات في جانب نموذج بلازما. أعتقد أنه لا يزال هناك مجال للتحسين في تقديم الالتزامات بالجملة. حاليا نحن نفعلها بشكل بسيط، كل معاملة لديها التزام واحد. والالتزام هو مجرد قيمة هاش لبيانات المدخلات المخزنة خارج السلسلة.
نحن نحتفظ بالبساطة قدر الإمكان مؤقتاً، بحيث يمكن أن يكون التدقيق بسيطاً وسريعاً، وبدون اختلاف كبير على OP Stack. لكن الآن هناك بعض التحسينات التي يمكن أن تجعلها أقل تكلفة، مثل معالجة الالتزامات بشكل مجمع أو تقديمها في blob، أو استخدام طرق مختلفة أخرى. لذلك، سنقوم بالتأكيد بدراسة ذلك لتقليل تكاليف L1.
هذا شيء مثير للغاية بالنسبة لنا. بالطبع، نحن أيضاً متحمسون جداً لكل ما يتعلق بالتشغيل المتداخل القادم، وأن نتمكن من التفاعل بين جميع الشبكات. سيكون من الرائع أن نكتشف أن هذا سيكون تقدماً هائلاً للمستخدمين.
الكثير من هذه المهام بالتأكيد يجب أن تقوموا بها. ولكننا نأمل في فهم كيف تبدو هذه في وضع Plasma ، ولها افتراضات أمان مختلفة.
بن: عندما نتحدث عن ذلك، ستكون هذه اختباراً آخر لوحدة OP Stack.