باحثة سيليستيا: تفسير 4 مخططات تراكم جديدة

المؤلف: NashQ، Celestia؛ Compiler: Link، "Geek web3"

مقدمة: تتكون هذه المقالة من الخطب المتناثرة للباحث Celestia NashQ حول تحليل نموذج Rollup ، بما في ذلك 4 متغيرات Rollup جديدة. سابقًا ، في مقالة "تحليل التراكمية من منظور Celestia: مقاومة الرقابة ونشاط 6 متغيرات" ، قام بإدراج 6 نماذج مختلفة من Rollup ، وهذه المقالة هي فئاته الأربعة المستخرجة حديثًا بناءً على نموذج التراكمية هذا.

في السابق ، قسمت NashQ جهاز التسلسل إلى وحدتين: المجمع + Header Producer. بدءًا من دورة حياة تعليمات المعاملة ، أوضح مبدأ التشغيل الخاص بـ Celestia's السيادية التراكمية ، وناقش مكافحة الرقابة ونشاط متغيرات Rollup المختلفة ، وتجربة المستخدم . الحد الأدنى من التكوين في إطار فرضية تقليل الثقة (أي لتحقيق Trustless ، ما هي أنواع العقد التي يجب على المستخدمين تشغيلها على الأقل).

المتغير 7: تراكمي + منتجو رؤوس متعددة + "أعلى بروتوكول MEV"

! [الباحث Celestia: تفسير 4 مخططات تجميع جديدة] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-935a57640d-dd1a6f-7649e1)

في متغير التجميع هذا ، ينشر مستخدمو شبكة التراكم بيانات المعاملات مباشرة إلى كتل طبقة DA ، ثم يكون Header Producer مسؤولاً عن فرز المعاملات ، ويتم استخراج MEV بواسطته. من الواضح أن عملية تجميع / تضمين المعاملات الخاصة بـ Rollup Variant 7 هي نفس عملية التجميع المستندة التي تم تقديمها مسبقًا ، وهي مسؤولية طبقة DA (يرسل المستخدمون المعاملات مباشرة إلى طبقة DA) ، لكن ترتيب المعاملات يختلف عن المستند المستند التراكمي ، وعقد طبقة DA ليست مسؤولة. الفرز هو مسؤولية HP (Header Producer).

يفترض التالي أن هناك ثلاث جهات صحية تتنافس مع بعضها البعض وتلتزم ببروتوكول تخصيص MEV المسمى "أعلى بروتوكول MEV". تم اقتراح هذا البروتوكول من خلال بروتوكول Skip الخاص بالنظام البيئي Cosmos. على عكس مخطط Ethereum PBS ، يحتاج Block Builder إلى دفع "نصيحة" إضافية إلى أداة التحقق من شبكة blockchain ، وستقوم الكتلة التي تم إنشاؤها بواسطة Builder مع معظم النصائح يتم اعتمادها من قبل المدققين. في الوقت نفسه ، اقترح بروتوكول SKIP مفهوم "MEV السيادي" ، بهدف السماح لجميع المصادقين والمجتمعات في شبكة السلسلة العامة بالحصول على استقلالية لتخصيص MEV ، وحل المشكلة التي أصبح بناؤها في Ethereum PBS أكثر وأكثر أكثر مركزية بسبب تأثير دولاب الموازنة (ولكن هذا ليس جوهر هذه المقالة).

! [الباحث Celestia: تفسير 4 مخططات تجميع جديدة] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-787acec3dd-dd1a6f-7649e1)

في متغير التجميع المقدم في هذه المقالة ، يحتاج منتجو الرؤوس المختلفون إلى الإعلان عن مبلغ الإكرامية في رأس الدُفعة الذي تم إنشاؤه بأنفسهم ، ويتم قبول رأس الدُفعة الصادر عن HP والذي يدفع معظم النصائح تلقائيًا بواسطة عقد التجميع (من خلال دفتر الأستاذ مكتوب في رمز العقدة. يتم إجراء خوارزمية اختيار الشوكة تلقائيًا).

! [الباحث Celestia: تفسير 4 مخططات تجميع جديدة] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-edc35b22ee-dd1a6f-7649e1)

بالإضافة إلى ذلك ، يجب أن يكون رأس الدُفعة الصادر عن HP قادرًا على التوافق مع دفعة المعاملة الكاملة على طبقة DA.

إذا كان هناك خطأ في الرأس الصادر عن HP ، على سبيل المثال ، نتيجة تنفيذ المعاملة Stateroot غير صحيحة ، أو لم يتم تضمين معاملة في الدفعة (معاملة مفقودة) ، فإن العقدة الكاملة الصادقة ستبث إثبات الاحتيال إلى العقدة الخفيفة . لكن عادةً (بشكل متفائل) ، يمكن أن تقبل العقد الضوئية الرأس الصادر عن HP وتعتقد أنه لا توجد مشكلة في ذلك.

! [الباحث Celestia: تفسير 4 مخططات تجميع جديدة] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-2de43bc187-dd1a6f-7649e1)

** مقاومة تحليل الرقابة: ** هناك نقطتان في هذا التراكمي يمكنهما إجراء مراجعة للمعاملات. الأول موجود في طبقة DA ، والتي يمكنها مراقبة محتوى المعاملات ورفض المعاملات التي تنطوي على مستخدمين معينين. لا يزال المكان الثاني موجودًا في طبقة DA ، والتي يمكنها مراجعة الرأس المقدم من HP ورفض تضمين رأس معين ، بحيث يمكنه التآمر مع الرأس لاحتكار MEV من خلال هجمات المراجعة.

! [الباحث Celestia: تفسير 4 مخططات تجميع جديدة] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-935a57640d-dd1a6f-7649e1)

في الوقت نفسه ، تعتبر HP مسؤولة عن ترتيب المعاملات. نظرًا لوجود أدلة ضد الاحتيال (يمكن استهدافها في الموقف الذي تفقد فيه HP المعاملات) ، لا تشن HP نفسها في كثير من الأحيان هجمات الرقابة ، ولكن يمكنها رشوة العقد من طبقة DA للقيام بذلك (أو تشغيل بعض طبقات DA بنفسها) عقدة). يتمثل الحل في تمديد فترة النافذة حتى يتم الانتهاء من تسلسل معاملة التراكمية ، بحيث يمكن تضمين الرأس المرفوض من قبل عقد طبقة DA الخبيثة في السلسلة عن طريق عقد طبقة DA صادقة قبل نهاية فترة النافذة ، وبالتالي زيادة مراجعة عقدة طبقة DA صعوبة الهجوم.

** النشاط: ** L = L \ _da && (L \ _hp1 || L \ _hp2 || L \ _hp3)

إذا تعرضت طبقة DA لفشل حيوي ، فسيكون لدى Rollup أيضًا فشل حيوي. بناءً على ذلك ، لن يفشل التراكمي في الحياة إلا عندما تفشل جميع HPs في الحياة.

المتغير 8: ZK Rollup من المُجمِّع المشترك + المُثبِّت اللامركزي

! [الباحث Celestia: تفسير 4 مخططات تجميع جديدة] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-5e8d74fed0-dd1a6f-7649e1)

يستخدم المتغير 8 المُجمّع المشترك المُجمّع المشترك (SA) لإدراج المعاملة + الفرز. تنشر SA تسلسل المعاملة دفعة إلى طبقة DA. بعد إرسال تسلسل المعاملة إلى طبقة DA ، لن يتغير أمر المعاملة نظريًا.

قبل إرسال الدُفعة إلى طبقة DA ، يمكن للمجمع المشترك SA بث رأس Batch + SA أولاً إلى العقدة الكاملة والمُثبِت ، وبث رأس SA إلى العقدة الضوئية ، ولكن الدُفعة غير الموجودة على طبقة DA هي لا يزال غير مستقر في هذا الوقت وقد يتم حظره في أي وقت.

وتجدر الإشارة إلى أن الرأس الصادر عن المجمع المشترك SA ليس هو نفسه رأس الدُفعة الصادر عن HP. يحتوي رأس SA على أدلة تشفير للتأكد من أن المجموعة التي تقرأها عقدة Rollup من طبقة DA يتم إنشاؤها بالفعل بواسطة SA ، وليس من قِبل الآخرين.

يقرأ Prover دفعة المعاملة دفعة من طبقة DA (يمكن أيضًا مزامنتها مباشرة مع المُجمِّع المشترك) ، ويُنشئ ZK Proof + Batch Header ، وينشره على طبقة DA. من الواضح أن Prover لعب دور HP.

! [الباحث Celestia: تفسير 4 مخططات تجميع جديدة] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-7d5728f58f-dd1a6f-7649e1)

بالنسبة للعقد الخفيفة الخاصة بـ Rollup ، بعد تلقي ZKProof ، يتم تأكيد تسلسل المعاملة الموجود في هذه الدفعة أخيرًا. بالطبع ، يمكن لـ Prover أيضًا بث ZKP من خلال شبكة Rollup p2p ضمن سلسلة طبقات DA ، بحيث يمكن استقبالها بواسطة العقد الضوئية بشكل أسرع ، ولكن في هذا الوقت لم يتم إرسال ZKP إلى طبقة DA ، وليس لديها " النهائية".

• ** مقاومة الرقابة: ** في المتغير 8 ، لا يمكن لطبقة DA إجراء هجمات رقابة على معاملات محددة معينة ، ولكن يمكنها فقط إجراء هجمات مراجعة على مجموعة المعاملات الكاملة المقدمة من قبل المجمّع المشترك. في الوقت نفسه ، يمكن للمجمعين المشتركين رفض حزم معاملات مستخدمين معينين.
• ** النشاط: ** L = L \ _da && L \ _sa && L \ _pm. في هذا المتغير ، إذا كان أي جزء به فشل في الأداء ، فسيكون لدى Rollup فشل في النشاط. إذا فشل Prover ، فلن تتمكن العقد الضوئية من مزامنة تقدم دفتر الأستاذ التراكمي بشكل فعال. ومع ذلك ، نظرًا لأن العقدة الكاملة تزامن جميع دفعات تسلسل المعاملات ، فيمكنها مواكبة تقدم دفتر الأستاذ. في هذا الوقت ، لن تتأثر جميع العقد ، وستفشل جميع العقد الضوئية ، وهو ما يعادل حالة التجميع المستند إلى التجميع باستخدام مُجمِّع مشترك تم تقديمه مسبقًا.
• ** الحد الأدنى من التكوين لتقليل الثقة: ** عقدة ضوء طبقة DA + عقدة ضوء شبكة مجمّع مشترك + عقدة ضوئية تراكمية

المتغير 9: مُجمِّع مشترك + مُثبِت لا مركزية + ZK-Rollup مع داس متعددة

! [الباحث Celestia: تفسير 4 مخططات تجميع جديدة] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-5119f66c7e-dd1a6f-7649e1)

يعتمد Variant 9 فعليًا على المتغير 8 أعلاه ، ولكنه يحتوي على أكثر من طبقة DA ، والتي يمكنها تحسين نشاط Rollup بشكل فعال. في Variant 9 ، يمكن للمُجمِّع المشترك SA نشر تسلسل المعاملة Batch إلى أي طبقة DA ، ويمكنه اختيار طبقات DA مختلفة لنشر البيانات وفقًا لاحتياجاته الخاصة ، بحيث يمكنه تحسين المعلمات ذات الصلة من Rollup ديناميكيًا ، مثل: تكلفة البيانات والأمان والفعالية ووقت استجابة المعاملات والنهائية.

وفقًا لاحتياجات طرف مشروع Rollup ، يمكن تخصيص Rollup الأرخص والأكثر أمانًا والأكثر نشاطًا وسرعة التسوية ، ويمكن تحديد طبقة DA ذات أعلى إنتاجية. بشكل عام ، لا يلزم وجود دفعات من ارتفاع كتلة Rollup معين (مثل 10000) على طبقات DA مختلفة في نفس الوقت ، ولكن إذا كانت موجودة ، يجب أن تكون محتوياتها متسقة. إذا ظهرت دفعتان بنفس الارتفاع ومحتوى مختلف على طبقات DA مختلفة ، فهذا يعني أن المُجمِّع المشترك يتفرع عن عمد دفتر الأستاذ.

هنا ، نختار نفس سوق Prover اللامركزي مثل Variant 8 ، حيث يعمل Prover كمنتج Header ويصدر Batch Header و ZKProof. في هذه المرحلة ، يحتاج Prover إلى التنافس من خلال آلية المزاد العلني المذكورة في البديل 7 (مقترح بواسطة بروتوكول SKIP).

تتأثر سرعة تسوية المعاملة (سرعة التأكيد النهائي) للمتغير 9 بطبقة DA ذات أسرع إنشاء كتلة.

** مقاومة الرقابة: ** يمكن للمجمعين المشتركين الانخراط في هجمات الرقابة ، ولكن مع المزيد من طبقات DA الاختيارية ، تقل احتمالية هجمات الرقابة المتعلقة بطبقات DA.

** 活性 ： ** L = (L \ _da1 || L \ _da2) && L \ _sa && L \ _pm。

كان الخيار 9 أكثر نشاطًا من المتغير السابق. طالما لم تتعرض جميع شبكات طبقة DA لفشل مباشر ، فسيعمل كل شيء بشكل جيد.

** الحد الأدنى من التكوين لتقليل الثقة: ** العقد الخفيفة لطبقات DA المختلفة + العقد الضوئية لشبكة التجميع المشترك + العقد الضوئية التراكمية.

من الواضح أنه كلما زاد عدد طبقات DA التي نعتمدها ، زاد عدد العقد الخفيفة التي يتعين علينا تشغيلها. لكن فوائد القيام بذلك قد تفوق التكاليف.

** البديل 10: اثنان من ZK-Rollups + Prover اللامركزي ، مع عقدة ضوئية على السلسلة (يمكن جسرها) بين بعضها البعض **

! [الباحث Celestia: تفسير 4 مخططات تجميع جديدة] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-b3f01038ad-dd1a6f-7649e1)

Variant 10 هو امتداد لـ Variant 5 لإنشاء 2 ZK-Rollups يمكنهما ربط بعضهما البعض. بالمقارنة مع Variant 5 (Based Rollup + ZKP + Decentralized Prover) ، فإن Variant 10 لديه دور مُرحِّل إضافي ، والذي يلف Batch Header + ZK-Proof في معاملة. طالما يتم إرسال هذه المعاملة إلى عقدة الضوء Rollup1 التي تعمل على Rollup2 ، فيمكن أن تثبت أن ارتفاعًا معينًا للدفعة صالح. بالطبع ، يتطلب Rollup2 أيضًا عقدًا ضوئية تقوم بتشغيل طبقة DA.

هذا شرط أساسي للحفاظ على الثقة عبر جسور السلسلة إلى الحد الأدنى. ولكن إذا كانت سلسلة متقاطعة من Ethereum Rollup (SC Rollup قائم على العقد الذكي) إلى Ethereum ، فلا داعي لتشغيل العقدة الخفيفة لطبقة DA من Rollup ، لأن طبقة DA هي Ethereum نفسها. هذا مختلف تمامًا عن مجموعة البيانات الشاملة الخاصة بـ Celestia ، والتي تمتد مجموعاتها التراكمية مع بعضها البعض ويجب أن تشغل العقد الخفيفة لطبقة DA للطرف الآخر.

! [الباحث Celestia: تفسير 4 مخططات تجميع جديدة] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-8f13b6f1a4-dd1a6f-7649e1)

عندما يرسل Relayer معاملة عبر سلسلة ، ستتم معالجتها بواسطة Rollup2's Aggregator 2 و HP2. نضيف كلاهما إلى الرسم البياني لفهم كيفية معالجة عقد Rollup2 للمعاملات عبر Rollups.

! [الباحث Celestia: تفسير 4 مخططات تجميع جديدة] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-9a7ac0c7f4-dd1a6f-7649e1)

سيحصل Relayer of Rollup2 على Batch Header و ZKP من Rollup 2 ويرسلهما مرة أخرى إلى Rollup1. يحتوي Rollup 1 أيضًا على عقدة ضوء Rollup 2 وعقدة ضوئية لطبقة DA.

يمكننا أن نجعل النموذج أكثر بساطة. افترض أن اثنين من Rollups يستخدمان نفس المُجمع المشترك و Header Producer ، بمعنى آخر ، طبقات DA التي يستخدمونها متداخلة.

! [PO3lMNvBRAgiaGTyTdxm7LnMW4JGJavQnbJU6lkd.png] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-d97c6a166e-dd1a6f-7649e1 "7072609

في هذه الحالة ، يمكن حظر Relayer مباشرة. نظرًا لأن HP Batch Header و ZK Proof قد تم نشرهما من قبل HP إلى نفس طبقة DA ، يمكن قراءة البيانات مثل Header و ZKP لمجموعة أخرى مباشرةً على طبقة DA ، ولم تعد هناك حاجة لتمريرها إلى المُجمِّع المشترك من خلال ريلاير.

! [الباحث Celestia: تفسير 4 مخططات تجميع جديدة] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-a02c04c6b6-dd1a6f-7649e1)

من الواضح أن التجميع باستخدام نفس طبقة DA لا يحتاج إلى الاعتماد على Relayer (تعتمد العديد من الجسور عبر السلسلة على عقد الترحيل). يمكن أن يحل هذا مشكلة أمان الجسر المتقاطع (من وجهة النظر هذه ، يكون الامتداد المتقاطع بين SC Rollups في Ethereum أكثر أمانًا من السلسلة المتقاطعة بين السلاسل العامة المختلفة).

في هذا الوقت ، ** الحد الأدنى من التكوين لتقليل الثقة: ** عقدة ضوء طبقة DA + عقدة ضوئية تراكمية.