في هذه الحلقة الخاصة من برنامج 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
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. لذلك تجنبنا حلول Alt DA الأخرى، وقررنا تخزين البيانات في تخزين DA مركزي، ثم العثور على نموذج أمان فعال على L1.
هذا هو السبب في أننا نحتاج إلى إعادة استخدام بعض المفاهيم القديمة لـ Plasma ووضعها فوق rollup. هنا بعض الاختلافات. أكبر سؤال هو: كيف يمكن تنفيذ DA خارج السلسلة وتحديات البيانات على السلسلة على OP Stack الحالي؟ هدفنا هو إجراء أقل قدر ممكن من التعديلات على OP Stack دون أي تأثير على مسار rollup، لأننا لا نريد التأثير على أمان سلاسل rollup الأخرى التي تستخدم OP Stack.
عند تصميم rollup، لن تفكر في: "ماذا سيحدث إذا قام شخص ما بتغيير عملية توليد البيانات لتخزين البيانات من مكان آخر؟" حتى مع هذه التغييرات، فإن OP Stack لا يزال قويًا جدًا، ويعمل بشكل جيد خارج الصندوق. هذا هو التغيير الأول الذي قمنا به.
بعد ذلك، نحتاج إلى كتابة عقد لإنشاء هذه التحديات. هناك تحدي DA يُجبر على رفع البيانات إلى السلسلة. هذه هي الخطوة الثانية، وهي دمج العقد في العملية. يجب أن نبني نظام التكامل بالكامل خلال عملية الاشتقاق، بحيث يمكنك اشتقاق البيانات من مصدر DA خارج السلسلة وكذلك من عقد تحدي DA من المستوى 1، في حال تم رفع البيانات إلى السلسلة خلال عملية حل التحدي.
هذه هي النقطة الأساسية في الأمر. إنه معقد للغاية لأننا نريد الحفاظ على أناقة الأمور وقوتها. في الوقت نفسه، إنها فكرة بسيطة نسبيًا. لم نحاول إعادة اختراع كل شيء أو تغيير مجموعة OP بالكامل، بل حاولنا الحفاظ على بساطة الأمور في بيئة معقدة. لذلك بشكل عام، كانت هذه رحلة هندسية رائعة للغاية.
Ben: يمكنني التحدث من وجهة نظر OP. لقد ذكرت بعض الأعمال المبكرة لـ Lattice. في نفس الوقت تقريبًا، قمنا بإعادة كتابة شاملة تقريبًا لكامل OP Stack من Optimism، ونطلق على هذا الإصدار اسم Bedrock.
بشكل أساسي، بعد بناء الـ rollup لمدة عامين، أخذنا خطوة للوراء، وتفكرنا قائلين: "حسناً، إذا كنا نريد استخدام كل ما تعلمناه إلى أقصى حد، كيف سيكون شكل ذلك؟" تطور هذا إلى مستودع الشيفرة الذي أطلق عليه في النهاية اسم Bedrock، وهو أكبر ترقية قمنا بها للشبكة.
في ذلك الوقت، تعاونّا معكم في مشروع يسمى OPCraft، وأعتقد أن Biomes هو الوريث الروحي له، حيث كانت هذه أفضل تجربة لنا على السلسلة. في نفس الوقت، شعرنا بالراحة لأن الآخرين يمكنهم أيضًا استخدام OP Stack للتطوير. أعتقد أن نقطة التحول المهمة الأخرى في التوسع خلال السنوات القليلة الماضية هي قدرة الكثير من الأشخاص على تشغيل السلسلة.
ليس من الضروري أن يكون أولئك الذين قاموا بتطوير مكتبات الشيفرة المعقدة الكبيرة هم فقط من يمكنهم القيام بذلك. عندما بدأنا التعاون، كان من الرائع رؤية الآخرين قادرين على تولي هذه المكتبة البرمجية والقيام ببعض الأشياء الرائعة جداً. ثم رؤية هذا يتوسع في التطبيق العملي على Plasma، كان حقاً رائعاً. يمكنني حتى التحدث قليلاً عن تلك الفترة التاريخية.
قبل أن تصبح Optimism Optimism، كنا في الواقع نبحث في تقنية تسمى Plasma. كانت المهمة التي承担ناها آنذاك تتجاوز بكثير قدرة مجتمع التوسيع في ذلك الوقت. قد لا تكون التصميمات التي تراها في تصميمات Plasma المبكرة مرتبطة مباشرة بـ Plasma اليوم.
اليوم ، أصبح Plasma أسهل بكثير. سننظر في إثبات حالة التحقق والتحديات بشكل منفصل عن تحديات البيانات. في النهاية ، أدركنا قبل بضع سنوات أن Rollups أسهل بكثير من Plasma. أعتقد أن استنتاج المجتمع في ذلك الوقت كان "Plasma ميتة". هذه كانت نكتة في تاريخ توسيع Ethereum في تلك الفترة.
لكننا دائمًا ما اعتقدنا أن "بلزما لم تمت، بل يمكننا محاولة مهمة أبسط أولاً". الآن نحن نستخدم مصطلحات مختلفة. على سبيل المثال، كان هناك مفهوم الخروج (exits) في ذلك الوقت، والآن يمكنك العودة إلى الوراء وتقول "أوه، كانت تلك تحديًا لمدى توفر البيانات مع بعض الخطوات الإضافية". لذلك، من الرائع أن نرى أن OP Stack ليس فقط مستخدمًا من قبل الآخرين، بل تطور أيضًا إلى الشيء الذي حاولنا القيام به في البداية ولكن بطريقة غير مرتبة وغير ناضجة جدًا. لقد أكملنا دورة كاملة، وقد قمتم بعمل تجريدي رائع حولها وجعلتموها تعمل بطريقة معقولة وعقلانية. هذا حقًا رائع.
الأهم هو الدخول إلى بيئة الإنتاج في أقرب وقت ممكن
tdot: لا يزال وضع بلازما يواجه بعض التحديات والمشاكل غير المحلولة، ونحن نعمل على حلها. المفتاح هو كيفية تجنب قضاء عشر سنوات في ذلك؟ هل تفهم ما أعنيه؟ نحتاج إلى الوصول سريعًا إلى مرحلة يمكننا فيها تقديم النتائج.
هذه هي فكرتنا. لدينا العديد من التطبيقات المبنية على 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، أو استخدام خيارات أخرى.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
مؤسس Optimism يتحدث بالتفصيل مع مطوري Plasma Mode عن تحسينات OP Stack والمستقبل
المطورون يتحدثون: تود و بن جونز في حوار
في هذه الحلقة الخاصة من برنامج 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
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. لذلك تجنبنا حلول Alt DA الأخرى، وقررنا تخزين البيانات في تخزين DA مركزي، ثم العثور على نموذج أمان فعال على L1.
هذا هو السبب في أننا نحتاج إلى إعادة استخدام بعض المفاهيم القديمة لـ Plasma ووضعها فوق rollup. هنا بعض الاختلافات. أكبر سؤال هو: كيف يمكن تنفيذ DA خارج السلسلة وتحديات البيانات على السلسلة على OP Stack الحالي؟ هدفنا هو إجراء أقل قدر ممكن من التعديلات على OP Stack دون أي تأثير على مسار rollup، لأننا لا نريد التأثير على أمان سلاسل rollup الأخرى التي تستخدم OP Stack.
عند تصميم rollup، لن تفكر في: "ماذا سيحدث إذا قام شخص ما بتغيير عملية توليد البيانات لتخزين البيانات من مكان آخر؟" حتى مع هذه التغييرات، فإن OP Stack لا يزال قويًا جدًا، ويعمل بشكل جيد خارج الصندوق. هذا هو التغيير الأول الذي قمنا به.
بعد ذلك، نحتاج إلى كتابة عقد لإنشاء هذه التحديات. هناك تحدي DA يُجبر على رفع البيانات إلى السلسلة. هذه هي الخطوة الثانية، وهي دمج العقد في العملية. يجب أن نبني نظام التكامل بالكامل خلال عملية الاشتقاق، بحيث يمكنك اشتقاق البيانات من مصدر DA خارج السلسلة وكذلك من عقد تحدي DA من المستوى 1، في حال تم رفع البيانات إلى السلسلة خلال عملية حل التحدي.
هذه هي النقطة الأساسية في الأمر. إنه معقد للغاية لأننا نريد الحفاظ على أناقة الأمور وقوتها. في الوقت نفسه، إنها فكرة بسيطة نسبيًا. لم نحاول إعادة اختراع كل شيء أو تغيير مجموعة OP بالكامل، بل حاولنا الحفاظ على بساطة الأمور في بيئة معقدة. لذلك بشكل عام، كانت هذه رحلة هندسية رائعة للغاية.
Ben: يمكنني التحدث من وجهة نظر OP. لقد ذكرت بعض الأعمال المبكرة لـ Lattice. في نفس الوقت تقريبًا، قمنا بإعادة كتابة شاملة تقريبًا لكامل OP Stack من Optimism، ونطلق على هذا الإصدار اسم Bedrock.
بشكل أساسي، بعد بناء الـ rollup لمدة عامين، أخذنا خطوة للوراء، وتفكرنا قائلين: "حسناً، إذا كنا نريد استخدام كل ما تعلمناه إلى أقصى حد، كيف سيكون شكل ذلك؟" تطور هذا إلى مستودع الشيفرة الذي أطلق عليه في النهاية اسم Bedrock، وهو أكبر ترقية قمنا بها للشبكة.
في ذلك الوقت، تعاونّا معكم في مشروع يسمى OPCraft، وأعتقد أن Biomes هو الوريث الروحي له، حيث كانت هذه أفضل تجربة لنا على السلسلة. في نفس الوقت، شعرنا بالراحة لأن الآخرين يمكنهم أيضًا استخدام OP Stack للتطوير. أعتقد أن نقطة التحول المهمة الأخرى في التوسع خلال السنوات القليلة الماضية هي قدرة الكثير من الأشخاص على تشغيل السلسلة.
ليس من الضروري أن يكون أولئك الذين قاموا بتطوير مكتبات الشيفرة المعقدة الكبيرة هم فقط من يمكنهم القيام بذلك. عندما بدأنا التعاون، كان من الرائع رؤية الآخرين قادرين على تولي هذه المكتبة البرمجية والقيام ببعض الأشياء الرائعة جداً. ثم رؤية هذا يتوسع في التطبيق العملي على Plasma، كان حقاً رائعاً. يمكنني حتى التحدث قليلاً عن تلك الفترة التاريخية.
قبل أن تصبح Optimism Optimism، كنا في الواقع نبحث في تقنية تسمى Plasma. كانت المهمة التي承担ناها آنذاك تتجاوز بكثير قدرة مجتمع التوسيع في ذلك الوقت. قد لا تكون التصميمات التي تراها في تصميمات Plasma المبكرة مرتبطة مباشرة بـ Plasma اليوم.
اليوم ، أصبح Plasma أسهل بكثير. سننظر في إثبات حالة التحقق والتحديات بشكل منفصل عن تحديات البيانات. في النهاية ، أدركنا قبل بضع سنوات أن Rollups أسهل بكثير من Plasma. أعتقد أن استنتاج المجتمع في ذلك الوقت كان "Plasma ميتة". هذه كانت نكتة في تاريخ توسيع Ethereum في تلك الفترة.
لكننا دائمًا ما اعتقدنا أن "بلزما لم تمت، بل يمكننا محاولة مهمة أبسط أولاً". الآن نحن نستخدم مصطلحات مختلفة. على سبيل المثال، كان هناك مفهوم الخروج (exits) في ذلك الوقت، والآن يمكنك العودة إلى الوراء وتقول "أوه، كانت تلك تحديًا لمدى توفر البيانات مع بعض الخطوات الإضافية". لذلك، من الرائع أن نرى أن OP Stack ليس فقط مستخدمًا من قبل الآخرين، بل تطور أيضًا إلى الشيء الذي حاولنا القيام به في البداية ولكن بطريقة غير مرتبة وغير ناضجة جدًا. لقد أكملنا دورة كاملة، وقد قمتم بعمل تجريدي رائع حولها وجعلتموها تعمل بطريقة معقولة وعقلانية. هذا حقًا رائع.
الأهم هو الدخول إلى بيئة الإنتاج في أقرب وقت ممكن
tdot: لا يزال وضع بلازما يواجه بعض التحديات والمشاكل غير المحلولة، ونحن نعمل على حلها. المفتاح هو كيفية تجنب قضاء عشر سنوات في ذلك؟ هل تفهم ما أعنيه؟ نحتاج إلى الوصول سريعًا إلى مرحلة يمكننا فيها تقديم النتائج.
هذه هي فكرتنا. لدينا العديد من التطبيقات المبنية على 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، أو استخدام خيارات أخرى.