في هذه الحلقة الخاصة من Devs on Devs، قمنا بدعوة المطور الأساسي لبروتوكول Plasma Mode tdot( وأيضًا المطور في Redstone )، بالإضافة إلى المؤسس المشارك لOptimism Ben Jones. تعتبر 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 Mode. الهدف واضح: لدينا العديد من تطبيقات 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 Stack، بل حاولنا الحفاظ على بساطة الأمور في بيئة معقدة. لذا بشكل عام، كانت هذه رحلة هندسية رائعة.
Ben: يمكنني التحدث من منظور 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 مستخدم من قبل الآخرين، بل أيضًا تطور إلى ما حاولنا القيام به في البداية لكن بطريقة فوضوية وغير ناضجة حقًا، هو أمر مذهل. لقد أكملنا دورة كاملة، وأنتم قمتم بعمل تجريدي رائع حولها، وجعلتموها تعمل بطريقة معقولة وعقلانية. هذا حقًا رائع.
02.الأهم هو الدخول إلى بيئة الإنتاج في أقرب وقت ممكن
tdot: لا تزال هناك بعض التحديات والمشكلات غير المُعالجة في وضع Plasma، ونحن نعمل على حلها. المفتاح هو كيفية تجنب إضاعة ما يصل إلى عشر سنوات؟ هل تفهم ما أعنيه؟ نحتاج إلى الوصول بسرعة إلى مرحلة يمكننا فيها تقديم النتائج.
هذه هي فكرتنا. لدينا العديد من التطبيقات القائمة على MUD التي نريد إطلاقها على الشبكة الرئيسية فورًا. نحتاج إلى إعداد شبكة رئيسية لهذه الألعاب في أقرب وقت ممكن. الناس في انتظار ومستعدون. تحتاج إلى سلسلة تعمل بسرعة ويمكن تشغيلها لتشغيل جميع هذه التطبيقات، بحيث يمكن لهذه التطبيقات أن تتطور بشكل متوازي وتصبح أفضل بينما نحل المشاكل. من البحث والتطوير إلى تحقيق الاستقرار في الإنتاج يستغرق وقتًا طويلاً.
لنشر شيء ما على الشبكة الرئيسية، وجعله غير مصرح به، وموثوقًا وآمنًا، يتطلب الكثير من الوقت. إن رؤية العملية الكاملة لتحقيق هذا الهدف مذهلة للغاية. لهذا السبب نحتاج إلى الحفاظ على مستوى عالٍ من المرونة، لأن هناك الكثير من الأشياء. يتطور النظام البيئي بسرعة كبيرة. أعتقد أن الجميع يقدمون الكثير من الابتكارات. لهذا السبب يجب عليك مواكبة ذلك، ولكن لا يمكنك المساومة على الأمان والأداء، وإلا فلن يعمل النظام.
Ben: أو بمعنى آخر، عبء تقني. مبدأ الحد الأدنى من التغييرات الذي ذكرته هو أحد المفاهيم الأساسية التي اعتمدناها أثناء إعادة كتابة Bedrock. لقد تحدثت عن إعادة الكتابة الكاملة من البداية إلى النهاية، لكن الأهم من ذلك هو أننا قللنا حوالي 50,000 سطر من الشيفرة، وهذا بحد ذاته قوي جداً. لأنك محق، هذه الأمور صعبة جداً.
كلما زادت سطرًا من الكود، كلما ابتعدت عن بيئة الإنتاج، مما يجعل من الصعب اختبار الأمور عمليًا، ويزيد من فرص الأخطاء. لذلك، نحن ممتنون جدًا لكل جهودكم في دفع هذه العملية، خاصةً للم contributions التي قدمتموها لنمط التشغيل الجديد لـ OP Stack.
tdot: إن OP Stack قد خلق بالفعل وسيلة تمكنك من التقدم بسرعة في مثل هذه الأمور. من الصعب جداً تنسيق الجميع، لأننا من الواضح شركتان مختلفتان. في Lattice، نحن نقوم ببناء لعبة، ومحرك لعبة، وسلسلة.
وأنتما تبنيان مئات وآلاف الأشياء، وتقومون بتسليم كل هذه المنتجات بانتظام. من حيث التنسيق، فإن هذا ليس سهلاً حقًا.
Ben: نعم، لا يزال هناك طريق طويل لنقطعه. ولكن هذه هي الجاذبية الأساسية للتجزئة. بالنسبة لي، من منظور OP Stack، هذه واحدة من أكثر الأمور إثارة، دون الإشارة إلى تلك الألعاب والعوالم الافتراضية الرائعة التي يتم بناؤها حاليًا على Redstone. من منظور OP Stack فقط، هذه مثال قوي جدًا يثبت أن العديد من المطورين الأساسيين الممتازين قد انضموا وعملوا على تحسين هذه الطبقة، وهذا أمر رائع.
هذه هي المرة الأولى، يمكنك من خلال قيمة بوليانية رئيسية أن تحدث تغييراً ملحوظاً في خصائص النظام. القدرة على القيام بذلك تماماً، كما قلت، لا يزال أمامنا طريق طويل لنقطعه. ولكن حتى الاقتراب من القيام بذلك بشكل فعال يحتاج إلى دعم معياري، أليس كذلك؟ بالنسبة لنا، رؤية أنكم قد حققتم ذلك دون الحاجة إلى إعادة كتابة L2 Geth على سبيل المثال، هو شيء يبعث على الارتياح حقاً. بالنسبة لي، هذا يثبت أن المعيارية تعمل.
tdot: الوضع الآن أفضل. من هذه الحالة، أنتم حولتم كل شيء إلى وحدات صغيرة مستقلة، يمكن تعديلها وتغيير خصائصها. لذلك أنا متحمس جدًا لرؤية الوظائف الجديدة التي سيتم دمجها. أتذكر أننا كنا نشعر بالقلق من أن لدينا تفرعًا، يحتوي على جميع التعديلات على OP Stack، ويحتاج إلى دمجه في السلسلة الرئيسية. كنا نفكر آنذاك، "يا إلهي، سيكون من الجنون مراجعة كل شيء."
لقد اضطررنا إلى تقسيمه إلى أجزاء أصغر، لكن العملية برمتها كانت تسير بسلاسة كبيرة. كانت أجواء التعاون مع الفريق رائعة، لذا كانت عملية المراجعة ممتعة أيضًا. كان هذا الشعور طبيعيًا جدًا. وأعتقد أن العملية كانت سريعة جدًا في مراجعة وحل بعض المشاكل المحتملة. كل شيء سار بشكل غير متوقع.
Ben: هذا رائع حقًا. هذا العام، أحد أولوياتنا هو إنشاء مسار للمساهمة في OP Stack. لذلك أنا ممتن جدًا لمشاركتكم في الاختبار، ودفع هذه العمليات. أنا سعيد لأن هذه العمليات لم تكن صعبة التحمل، وقد حققنا بعض الإنجازات. وبالحديث عن ذلك، أنا فضولي جدًا، من وجهة نظرك، كيف ستتطور هذه العمل في المستقبل؟ ما الذي تتطلع إلى تطويره بعد ذلك؟
tdot: هناك الكثير من الاتجاهات الوظيفية المختلفة. يتعلق الأمر بشكل أساسي بتكامل آلية إثبات العطل. نتبنى نهجًا تدريجيًا لامركزية كامل مجموعة التكنولوجيا وزيادة خصائصها غير المصرح بها، والهدف النهائي هو تحقيق وظائف غير مصرح بها وإجبار الخروج.
لدينا هذا الهدف النهائي، وسنقوم بتحقيقه تدريجياً مع الحفاظ على الأمان. أحد التحديات هو أنه في بعض الأحيان يكون من الأسهل عدم الانتقال إلى الشبكة الرئيسية، لأن ذلك لا يتطلب القيام بتقسيم صلب. قد تفكر، "أوه، سأنتظر حتى يكون كل شيء جاهزًا تمامًا قبل النشر، حتى لا أحتاج إلى تقسيم صلب، ولا توجد أعباء تقنية." ولكن، إذا كنت تريد بسرعة إطلاق الشبكة الرئيسية، يجب عليك التعامل مع هذه التحديثات المعقدة وإصدارها بشكل متكرر. إنجاز ذلك مع الحفاظ على توفر عالي دائمًا هو تحدٍ.
أعتقد أنه بعد أن تصبح آلية إثبات العطل وجميع هذه الأجزاء جاهزة، سيكون هناك الكثير من التحديثات في جانب نموذج Plasma. أعتقد أن هناك مجالًا لبعض التحسينات في تقديم الالتزامات دفعة واحدة. نحن الآن نقوم بذلك بطريقة بسيطة، حيث يتم تقديم التزام واحد لكل معاملة. والالتزام هو مجرد قيمة تجزئة لبيانات الإدخال المخزنة خارج السلسلة.
نحن نحافظ على البساطة قدر الإمكان مؤقتًا، بحيث يمكن أن يكون التدقيق بسيطًا وسريعًا، ولا يوجد فرق كبير في OP Stack. لكن الآن هناك بعض التحسينات التي يمكن أن تجعل الأمر أرخص، مثل تجميع الالتزامات أو تقديمها في blob، أو استخدام طرق مختلفة أخرى. لذا سنقوم بالتأكيد بدراسة هذا لتقليل تكلفة L1.
هذا شيء نحن متحمسون له للغاية. بالطبع، نحن نتطلع أيضًا إلى جميع المحتويات المتعلقة بالتشغيل البيني التي ستأتي قريبًا، وقدرتنا على التفاعل بين جميع الشبكات. سيكون من الرائع معرفة أن هذا سيكون تقدمًا كبيرًا للمستخدمين.
بالطبع، يجب أن يتم تنفيذ العديد من هذه المهام من قبلكم. ولكننا نأمل أن نفهم كيف تبدو هذه الأمور في وضع Plasma، مع افتراضات أمان مختلفة.
Ben: عندما يتعلق الأمر بذلك، سيكون ذلك لـ OP Stack
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 22
أعجبني
22
7
إعادة النشر
مشاركة
تعليق
0/400
OnchainHolmes
· 08-08 11:27
أخيرًا تم تخفيض تكلفة البيانات
شاهد النسخة الأصليةرد0
MEVSandwichVictim
· 08-08 09:11
أريد الذهاب إلى ديسان للبحث عن بن لعزف البيانو والغناء.
شاهد النسخة الأصليةرد0
ColdWalletGuardian
· 08-08 08:29
يبدو أن بلازما ستعود أخيرًا.
شاهد النسخة الأصليةرد0
CodeZeroBasis
· 08-05 12:03
لقد أدرك بلازما أخيرًا.
شاهد النسخة الأصليةرد0
ProxyCollector
· 08-05 11:58
استعادة البلازما وما إلى ذلك يبدو غريباً جداً.
شاهد النسخة الأصليةرد0
BottomMisser
· 08-05 11:57
فقط للعب لا يهم إذا ارتفع أو لم يرتفع، أي بروتوكول ليس هو نفسه؟
مؤسس مشارك في Optimism ومطور Plasma Mode يناقشان تحسينات OP Stack ومستقبل التوسع
المطورون على المطورين: محادثة TDOT وبن جونز
في هذه الحلقة الخاصة من Devs on Devs، قمنا بدعوة المطور الأساسي لبروتوكول Plasma Mode tdot( وأيضًا المطور في Redstone )، بالإضافة إلى المؤسس المشارك لOptimism Ben Jones. تعتبر 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 Mode. الهدف واضح: لدينا العديد من تطبيقات 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 Stack، بل حاولنا الحفاظ على بساطة الأمور في بيئة معقدة. لذا بشكل عام، كانت هذه رحلة هندسية رائعة.
Ben: يمكنني التحدث من منظور 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 مستخدم من قبل الآخرين، بل أيضًا تطور إلى ما حاولنا القيام به في البداية لكن بطريقة فوضوية وغير ناضجة حقًا، هو أمر مذهل. لقد أكملنا دورة كاملة، وأنتم قمتم بعمل تجريدي رائع حولها، وجعلتموها تعمل بطريقة معقولة وعقلانية. هذا حقًا رائع.
02.الأهم هو الدخول إلى بيئة الإنتاج في أقرب وقت ممكن
tdot: لا تزال هناك بعض التحديات والمشكلات غير المُعالجة في وضع Plasma، ونحن نعمل على حلها. المفتاح هو كيفية تجنب إضاعة ما يصل إلى عشر سنوات؟ هل تفهم ما أعنيه؟ نحتاج إلى الوصول بسرعة إلى مرحلة يمكننا فيها تقديم النتائج.
هذه هي فكرتنا. لدينا العديد من التطبيقات القائمة على MUD التي نريد إطلاقها على الشبكة الرئيسية فورًا. نحتاج إلى إعداد شبكة رئيسية لهذه الألعاب في أقرب وقت ممكن. الناس في انتظار ومستعدون. تحتاج إلى سلسلة تعمل بسرعة ويمكن تشغيلها لتشغيل جميع هذه التطبيقات، بحيث يمكن لهذه التطبيقات أن تتطور بشكل متوازي وتصبح أفضل بينما نحل المشاكل. من البحث والتطوير إلى تحقيق الاستقرار في الإنتاج يستغرق وقتًا طويلاً.
لنشر شيء ما على الشبكة الرئيسية، وجعله غير مصرح به، وموثوقًا وآمنًا، يتطلب الكثير من الوقت. إن رؤية العملية الكاملة لتحقيق هذا الهدف مذهلة للغاية. لهذا السبب نحتاج إلى الحفاظ على مستوى عالٍ من المرونة، لأن هناك الكثير من الأشياء. يتطور النظام البيئي بسرعة كبيرة. أعتقد أن الجميع يقدمون الكثير من الابتكارات. لهذا السبب يجب عليك مواكبة ذلك، ولكن لا يمكنك المساومة على الأمان والأداء، وإلا فلن يعمل النظام.
Ben: أو بمعنى آخر، عبء تقني. مبدأ الحد الأدنى من التغييرات الذي ذكرته هو أحد المفاهيم الأساسية التي اعتمدناها أثناء إعادة كتابة Bedrock. لقد تحدثت عن إعادة الكتابة الكاملة من البداية إلى النهاية، لكن الأهم من ذلك هو أننا قللنا حوالي 50,000 سطر من الشيفرة، وهذا بحد ذاته قوي جداً. لأنك محق، هذه الأمور صعبة جداً.
كلما زادت سطرًا من الكود، كلما ابتعدت عن بيئة الإنتاج، مما يجعل من الصعب اختبار الأمور عمليًا، ويزيد من فرص الأخطاء. لذلك، نحن ممتنون جدًا لكل جهودكم في دفع هذه العملية، خاصةً للم contributions التي قدمتموها لنمط التشغيل الجديد لـ OP Stack.
tdot: إن OP Stack قد خلق بالفعل وسيلة تمكنك من التقدم بسرعة في مثل هذه الأمور. من الصعب جداً تنسيق الجميع، لأننا من الواضح شركتان مختلفتان. في Lattice، نحن نقوم ببناء لعبة، ومحرك لعبة، وسلسلة.
وأنتما تبنيان مئات وآلاف الأشياء، وتقومون بتسليم كل هذه المنتجات بانتظام. من حيث التنسيق، فإن هذا ليس سهلاً حقًا.
Ben: نعم، لا يزال هناك طريق طويل لنقطعه. ولكن هذه هي الجاذبية الأساسية للتجزئة. بالنسبة لي، من منظور OP Stack، هذه واحدة من أكثر الأمور إثارة، دون الإشارة إلى تلك الألعاب والعوالم الافتراضية الرائعة التي يتم بناؤها حاليًا على Redstone. من منظور OP Stack فقط، هذه مثال قوي جدًا يثبت أن العديد من المطورين الأساسيين الممتازين قد انضموا وعملوا على تحسين هذه الطبقة، وهذا أمر رائع.
هذه هي المرة الأولى، يمكنك من خلال قيمة بوليانية رئيسية أن تحدث تغييراً ملحوظاً في خصائص النظام. القدرة على القيام بذلك تماماً، كما قلت، لا يزال أمامنا طريق طويل لنقطعه. ولكن حتى الاقتراب من القيام بذلك بشكل فعال يحتاج إلى دعم معياري، أليس كذلك؟ بالنسبة لنا، رؤية أنكم قد حققتم ذلك دون الحاجة إلى إعادة كتابة L2 Geth على سبيل المثال، هو شيء يبعث على الارتياح حقاً. بالنسبة لي، هذا يثبت أن المعيارية تعمل.
tdot: الوضع الآن أفضل. من هذه الحالة، أنتم حولتم كل شيء إلى وحدات صغيرة مستقلة، يمكن تعديلها وتغيير خصائصها. لذلك أنا متحمس جدًا لرؤية الوظائف الجديدة التي سيتم دمجها. أتذكر أننا كنا نشعر بالقلق من أن لدينا تفرعًا، يحتوي على جميع التعديلات على OP Stack، ويحتاج إلى دمجه في السلسلة الرئيسية. كنا نفكر آنذاك، "يا إلهي، سيكون من الجنون مراجعة كل شيء."
لقد اضطررنا إلى تقسيمه إلى أجزاء أصغر، لكن العملية برمتها كانت تسير بسلاسة كبيرة. كانت أجواء التعاون مع الفريق رائعة، لذا كانت عملية المراجعة ممتعة أيضًا. كان هذا الشعور طبيعيًا جدًا. وأعتقد أن العملية كانت سريعة جدًا في مراجعة وحل بعض المشاكل المحتملة. كل شيء سار بشكل غير متوقع.
Ben: هذا رائع حقًا. هذا العام، أحد أولوياتنا هو إنشاء مسار للمساهمة في OP Stack. لذلك أنا ممتن جدًا لمشاركتكم في الاختبار، ودفع هذه العمليات. أنا سعيد لأن هذه العمليات لم تكن صعبة التحمل، وقد حققنا بعض الإنجازات. وبالحديث عن ذلك، أنا فضولي جدًا، من وجهة نظرك، كيف ستتطور هذه العمل في المستقبل؟ ما الذي تتطلع إلى تطويره بعد ذلك؟
tdot: هناك الكثير من الاتجاهات الوظيفية المختلفة. يتعلق الأمر بشكل أساسي بتكامل آلية إثبات العطل. نتبنى نهجًا تدريجيًا لامركزية كامل مجموعة التكنولوجيا وزيادة خصائصها غير المصرح بها، والهدف النهائي هو تحقيق وظائف غير مصرح بها وإجبار الخروج.
لدينا هذا الهدف النهائي، وسنقوم بتحقيقه تدريجياً مع الحفاظ على الأمان. أحد التحديات هو أنه في بعض الأحيان يكون من الأسهل عدم الانتقال إلى الشبكة الرئيسية، لأن ذلك لا يتطلب القيام بتقسيم صلب. قد تفكر، "أوه، سأنتظر حتى يكون كل شيء جاهزًا تمامًا قبل النشر، حتى لا أحتاج إلى تقسيم صلب، ولا توجد أعباء تقنية." ولكن، إذا كنت تريد بسرعة إطلاق الشبكة الرئيسية، يجب عليك التعامل مع هذه التحديثات المعقدة وإصدارها بشكل متكرر. إنجاز ذلك مع الحفاظ على توفر عالي دائمًا هو تحدٍ.
أعتقد أنه بعد أن تصبح آلية إثبات العطل وجميع هذه الأجزاء جاهزة، سيكون هناك الكثير من التحديثات في جانب نموذج Plasma. أعتقد أن هناك مجالًا لبعض التحسينات في تقديم الالتزامات دفعة واحدة. نحن الآن نقوم بذلك بطريقة بسيطة، حيث يتم تقديم التزام واحد لكل معاملة. والالتزام هو مجرد قيمة تجزئة لبيانات الإدخال المخزنة خارج السلسلة.
نحن نحافظ على البساطة قدر الإمكان مؤقتًا، بحيث يمكن أن يكون التدقيق بسيطًا وسريعًا، ولا يوجد فرق كبير في OP Stack. لكن الآن هناك بعض التحسينات التي يمكن أن تجعل الأمر أرخص، مثل تجميع الالتزامات أو تقديمها في blob، أو استخدام طرق مختلفة أخرى. لذا سنقوم بالتأكيد بدراسة هذا لتقليل تكلفة L1.
هذا شيء نحن متحمسون له للغاية. بالطبع، نحن نتطلع أيضًا إلى جميع المحتويات المتعلقة بالتشغيل البيني التي ستأتي قريبًا، وقدرتنا على التفاعل بين جميع الشبكات. سيكون من الرائع معرفة أن هذا سيكون تقدمًا كبيرًا للمستخدمين.
بالطبع، يجب أن يتم تنفيذ العديد من هذه المهام من قبلكم. ولكننا نأمل أن نفهم كيف تبدو هذه الأمور في وضع Plasma، مع افتراضات أمان مختلفة.
Ben: عندما يتعلق الأمر بذلك، سيكون ذلك لـ OP Stack