مقدمة: منذ أن أصبحت Rollup شائعة ، كانت لا مركزية Sequencer دائمًا محور تركيز مجتمع Ethereum / Celestia ، وهي أيضًا جبل لا يمكن التغلب عليه في بحث وتطوير Layer2. في هذا الصدد ، اقترحت مخططات التجميع المختلفة أفكارًا حول لامركزية العقدة ، مما يوفر مساحة تخيل واسعة للغاية لهذا الموضوع.
يأخذ مؤلف هذه المقالة مشروع ZKRollup الشهير Aztec كمثال ، ويستخدم الاقتراحين المسمى B52 و Fernet اللذين اقترحهما Aztec Labs مؤخرًا كنقطة انطلاق لتحليل كيفية تحقيق ZKR للامركزية لعقد التسلسل للقراء.
الاقتراح B52: مخطط التسلسل غير المسموح به
** يهدف الاقتراح B52 إلى تحقيق ما يلي (بشكل مثالي): **
شبكة التسلسل اللامركزية ، تنتخب العقد L2 نفسها كل جولة من العروض
شبكة المُثبِت اللامركزية ، متطلبات الأجهزة المنخفضة لعقد المُثبِّت
التراكمي لديه مقاومة جيدة للرقابة ككل.
يتم الحصول على قيمة MEV الناتجة عن L2 بواسطة عقد L2
عندما يتم تقديم كتلة L2 إلى طبقة DA ، يمكن الحصول على نهائية أكثر فاعلية ، ويجب أن تنتظر النتيجة النهائية غير القابلة للإلغاء حتى يتم تقديم إثبات الصلاحية (إثبات الصلاحية)
يمكن أن يكون للرمز L2 نموذج اقتصادي جيد
يتم نشر كل من فدرات L2 وبيانات المعاملات في شبكة L2 p2p
يرث L2 أمان L1
[تحليل اقتراح B52 الخاص بـ Aztec Labs: كيف تدرك ZK-Rollup لامركزية عقد التسلسل؟ ] (https://img-cdn.gateio.im/resized-social/moments-69a80767fe-38bf333c5c-dd1a6f-7649e1)
** يقسم هذا المخطط عملية إنتاج بلوك L2 بأكملها إلى ثلاث مراحل زمنية: **
حظر نافذة الاقتراح (BPW)
نافذة BlockAcceptance (BAW)
تقدم الدولة
من بينها ، مرحلة BPW (اقتراح الكتلة) هي عملية يقترح فيها متسلسلون متعددون Seuqnecer كتلًا مختلفة ويتنافسون ، ويختار Prover كتلة مرشح لإعطاء تصويت.
BAW (Block Acceptance) هي العملية التي يقوم فيها Prover ببناء إثبات صحة للكتلة وإرساله.
نافذة اقتراح الكتلة (مرحلة اقتراح الكتلة):
يمكن تقسيم BPW إلى ثلاث مراحل: ** اقتراح الحظر ، كتلة التصويت ، التجميع **.
[تحليل اقتراح B52 الخاص بـ Aztec Labs: كيف يدرك ZK-Rollup لامركزية عقد التسلسل؟ ] (https://img-cdn.gateio.im/resized-social/moments-69a80767fe-bb6d6642f2-dd1a6f-7649e1)
[تحليل اقتراح B52 الخاص بـ Aztec Labs: كيف تدرك ZK-Rollup لامركزية عقد التسلسل؟ ] (https://img-cdn.gateio.im/resized-social/moments-69a80767fe-d946c2a2b6-dd1a6f-7649e1)
يمكن لأي شخص في مرحلة اقتراح الحظر (BP) جمع المعاملات وبث محتوى BP الخاص به. سيحتوي محتوى BP على ثلاثة أجزاء: تجزئة طلب txs ، ونسبة مكافأة المُثبِت ، ومقدار حرق الرمز المميز
[تحليل اقتراح B52 الخاص بـ Aztec Labs: كيف تدرك ZK-Rollup لامركزية عقد التسلسل؟ ] (https://img-cdn.gateio.im/resized-social/moments-69a80767fe-1afcb38c75-dd1a6f-7649e1)
** تجزئة ترتيب txs: ** يختار مقدم العرض ويصنف الدفعة الأكثر قيمة من المعاملات من تجمع المعاملات L2 (mempool) ، ثم يضع قيمة التجزئة لهذه المجموعة من المعاملات في الكتلة التي ينشئها.
** نسبة مكافأة المُثبِت: ** النسبة المئوية لمكافأة الكتلة التي يتقاسمها Sequencer إلى Prover
** مبلغ الرمز المميز للنسخ: ** عدد الرمز المميز L2 الذي اقترحه مقدم العرض ليتم إتلافه ، ثم يرسل BP المقترح إلى شبكة L2 p2p
** مرحلة الاقتراع: **
[تحليل اقتراح B52 الخاص بـ Aztec Labs: كيف تدرك ZK-Rollup لامركزية عقد التسلسل؟ ] (https://img-cdn.gateio.im/resized-social/moments-69a80767fe-931ecadf03-dd1a6f-7649e1)
بعد أن يتلقى Prover BP الذي اقترحه مقترحون مختلفون في شبكة p2p ، سيصوت لشركة BP التي يمكن أن تمنحه أكبر قدر من المكافأة. ومع ذلك ، فإن تكوين التصويت خاص جدًا:
** التصويت = {BlockHash ، فهرس شجرة الإثبات} **
BlockHash هو تجزئة الاقتراح الذي سيصوت عليه Prover ، وفهرس شجرة الإثبات هو قيمة فهرس الأوراق لشجرة الإثبات التي سيشارك Prover في بنائها (موضح لاحقًا)
[تحليل اقتراح B52 الخاص بـ Aztec Labs: كيف يدرك ZK-Rollup لامركزية عقد التسلسل؟ ] (https://img-cdn.gateio.im/resized-social/moments-69a80767fe-475d3d21b7-dd1a6f-7649e1)
** التجميع التجميعي: ** يجمع مقدم العرض أصوات Provers for BP في شبكة L2 p2p ، ويجمعها ويضعها في BP ، ويرسلها إلى L1 (تحتوي كل شركة BP بشكل عام على سجلات تصويت مرتبطة بنفسها فقط).
[تحليل اقتراح B52 الخاص بـ Aztec Labs: كيف تدرك ZK-Rollup لامركزية عقد التسلسل؟ ] (https://img-cdn.gateio.im/resized-social/moments-69a80767fe-9b58f874c9-dd1a6f-7649e1)
** هنا ، من الضروري التأكيد على المتطلبات الأساسية لاختيار BP وإدراجها في دفتر الأستاذ Rollp: **
NUM \ _PROVERS (x) هو عدد أصوات Prover التي حصلت عليها BP ، و BURN \ _BID هو عدد الرموز L2 المقترح تدميرها بواسطة BP. نظرًا لأنه كلما ارتفع BURN \ _BID ، قلت المكافأة التي سيحصل عليها مقدم BP في النهاية ، لذلك يجب تعيين هذه القيمة بشكل صحيح.
في الوقت نفسه ، يجب تقديم BP إلى L1 قبل نهاية نافذة اقتراح الحظر ، ويجب تحميل إثبات الصلاحية المقابل إلى L1 قبل نهاية نافذة قبول الحظر.
ملاحظة: في حساب درجات BP ، يمثل عدد الأصوات النسبة الأكبر ، متبوعًا بعدد الرموز المحترقة. في الوقت نفسه ، يسمح مخطط B52 لمقدمي العروض المتعددين (المتسلسلات في الواقع) بالتنافس على حصة BP فعالة
يتطلب مخطط B52 فقط من العارض (منظم التسلسل) تحديد عدد الرموز المميزة للنسخ في BP الخاص به (على غرار طريقة EIP1559) بدون رموز الحصة مسبقًا ، والتي يمكن أن تجعل الشبكة أكثر بدون إذن (بدون إذن وصول) ، وهي مفيد أيضًا لـ L2 Native Token ينتج الانكماش.
بالإضافة إلى ذلك ، لا تحتوي BP على بيانات المعاملات الكاملة ، ولكن فقط تجزئة تسلسل المعاملة.السبب مشابه لنظام Ethereum PBS ، الذي يهدف إلى منع MEV من التجسس عليها من قبل مقدمي العروض الآخرين.
** نافذة قبول الحظر (مرحلة قبول الحظر) شرح مفصل: **
[تحليل اقتراح B52 الخاص بـ Aztec Labs: كيف تدرك ZK-Rollup لامركزية عقد التسلسل؟ ] (https://img-cdn.gateio.im/resized-social/moments-69a80767fe-38bf333c5c-dd1a6f-7649e1)
[تحليل اقتراح B52 الخاص بـ Aztec Labs: كيف تدرك ZK-Rollup لامركزية عقد التسلسل؟ ] (https://img-cdn.gateio.im/resized-social/moments-69a80767fe-0b0d76936f-dd1a6f-7649e1)
بعد انتهاء نافذة اقتراح الحظر ، يحتاج Prover إلى الكشف عن بيانات المعاملة الكاملة المقابلة لـ BP الخاص به. إذا تم تحديد BP الذي تم التصويت عليه بواسطة Prover (يمكن الاستعلام عن أعلى درجة من خلال عقد L1) ، فسيحتاجون إلى إنشاء شجرة إثبات فرعية تتوافق مع فهرس شجرة الإثبات المقدم أثناء التصويت.
[تحليل اقتراح B52 الخاص بـ Aztec Labs: كيف تدرك ZK-Rollup لامركزية عقد التسلسل؟ ] (https://img-cdn.gateio.im/resized-social/moments-69a80767fe-475d3d21b7-dd1a6f-7649e1)
بافتراض أن كتلة Aztec تحتوي على 2 ^ 13 = 16384 معاملة وهناك 2048 مُثبِّتًا ، فإن كل مُثبِت يُنشئ شجرة إثبات فرعية تتكون من 2 ^ 3 = 8 معاملات. ثم يبث المُثبِّت شجرة الإثبات الفرعية التي أنشأها بنفسه إلى في L2 p2p شبكة. بعد أن يستلمها مقدم الطلب ، سيقوم بتجميع جميع أشجار الإثبات الفرعية في كتلة برهان.
[تحليل اقتراح B52 الخاص بـ Aztec Labs: كيف تدرك ZK-Rollup لامركزية عقد التسلسل؟ ] (https://img-cdn.gateio.im/resized-social/moments-69a80767fe-540e07d719-dd1a6f-7649e1)
ثم يقدم Propsoer الدليل المجمع إلى عقد L1 Rollup ، وسوف يتحقق العقد من صحة الإثبات ونتائج انتقال الحالة المقابلة. وتجدر الإشارة هنا إلى أنه إذا أخفق المُقَدِّم عمدًا في تقديم الدليل ، فلن يتمكن فقط من الحصول على عائد مكافأة الكتلة الذي وعد به مقدم العرض ، بل سيتم أيضًا خفضه ، لأنه لكي يصبح مُثلاً ، فإنه يحتاج إلى تعهد رمز مقدما. لذلك ، على عكس Proposer (Sequencer) ، فإن Prover ليس بدون إذن.
** سلف الدولة (مرحلة تقدم الدولة) شرح مفصل: **
[تحليل اقتراح B52 الخاص بـ Aztec Labs: كيف تدرك ZK-Rollup لامركزية عقد التسلسل؟ ] (https://img-cdn.gateio.im/resized-social/moments-69a80767fe-adbf827c5b-dd1a6f-7649e1)
بعد انتهاء نافذة قبول الحظر ، سيحدد عقد التجميع كتلة ذات أعلى درجة ليتم تضمينها في دفتر الأستاذ التجميعي ، وإرسال مكافأة مكافأة الكتلة إلى مقدم العرض والمثبّت على التوالي وفقًا للنسبة التي أعلنها مقدم العرض (منظم التسلسل) في يتقدم.
** ما ورد أعلاه هو محلول Aztec B52. ومع ذلك ، يعتقد مؤلف هذا المقال أن هناك بعض المشكلات المحتملة في اقتراح B52: **
السؤال 1: ** إذا كان إثبات صحة الكتلة الحاصلة على أعلى الدرجات غير كامل **. الحل المقدم في الاقتراح هو أنه إذا قدم مقدم العرض 50 ٪ فقط من الإثبات ، فيمكنه الحصول على 50 ٪ فقط من مكافآت الكتلة ، وذلك للتأكد من أن مقدم العرض ليس لديه دافع لعدم تقديم دليل كامل عن عمد. في الوقت نفسه ، يمكن لـ Prover أيضًا تقديم دليل مباشرة إلى العقد.
وفقًا لوصف الاقتراح ، من المقبول قبول كتلة دون إثبات صحة المعاملات الكاملة. هذا في الواقع غير معقول: لأن: zkrollup يعلن فقط أن الحالة الجديدة المقابلة لهذه الكتلة صالحة عندما يتم تقديم إثبات الصلاحية.
إذا كان الدليل الإجمالي الذي قدمه مقدم العرض إلى L1 يفتقد إلى دليل على معاملة معينة ، فمن الواضح أن أدلة انتقال الحالة لجميع المعاملات التي تحدث بعد هذه المعاملة غير صالحة (لأن المعاملات يتم تنفيذها بالتتابع ولها تبعيات حالة) ، فنحن من المستحيل أيضًا تأكيد صلاحية الحالة الجديدة المقابلة لهذه الكتلة.
لذلك ، في هذا الوقت ، يجب أن تكون الطريقة المعقولة هي الدخول إلى نافذة قبول الحظر التي تنتظر إلى ما لا نهاية حتى يتم تقديم جميع إثباتات المعاملة.
السؤال 2: ** إذا كانت الكتلة الحاصلة على أعلى درجة عبارة عن كتلة غير قانونية (لم يتم توضيح ذلك في مخطط B52). ** يحتوي BP فقط على تجزئة تسلسل المعاملة ، لذلك يمكن للمقترح الضار فعليًا إنشاء معاملات إشكالية عمداً ، مثل معاملات الإنفاق المزدوج. لذلك في هذا الوقت ، من الضروري بالفعل إضافة وظيفة في عقد L1 يمكن لأي شخص أن يقدم دليلًا غير قانوني. يتم استخدام هذا الدليل غير القانوني لإثبات أن BP ذات أعلى الدرجات هي كتلة غير قانونية.
ويجب أن يكافأ هذا النوع من التقارير ، يمكننا مكافأة رمز الحرق الذي أرسله مقدم العرض إلى العقد إلى عقدة المراسل الذي قدم الدليل غير القانوني.
** تفكير مثير للاهتمام: ** حول كتل العم و Prover Work الزائدة عن الحاجة: سيستخدم مخطط B52 بالفعل BPs الأخرى (الذين قدموا أدلة كاملة) التي تظهر في هذه الجولة كأعمام بعد BP مع أعلى الدرجات في كل جولة. تعيين مكافأة كتلة عم معينة.
يتبع هذا في الواقع نهج آلية إجماع ETH POW. من أجل تجنب التركيز المفرط لقوة الحوسبة ، من الضروري تخصيص جزء من مكافآت الكتلة لمقدمي الكتل غير المقبولين (عمال المناجم) لحماية مصالح تجمعات التعدين الصغيرة / عمال المناجم الفرديين وتجنب احتكار مجمعات التعدين الكبيرة لقوة الحوسبة. لذلك ، يعد أيضًا اختيارًا ذكيًا للغاية لاعتماد آلية حظر العم التي يعمل بها Ethereum بشكل جيد.
أهمية اقتراح B52 من حيث اللامركزية التراكمية: ** مقدم العرض لا مركزي ولا يتطلب تعهدًا ، وعتبة الدخول منخفضة ** ؛ ولكن لأنك تحتاج إلى بناء الكتل الأكثر قيمة بنفسك ، وتحتاج إلى جمع الأصوات من العارضين الآخرين ، واجمع كل الأدلة. في الواقع ، عتبة الأجهزة لمقدم العرض ليست منخفضة كما هو مذكور في الاقتراح (على سبيل المثال ، قد لا يكون النطاق الترددي منخفضًا جدًا).
لذلك ، ستصبح في النهاية شبكة مركزية نسبيًا ، على غرار Mev-Boost Builder ، لأن مقدم العرض الذي يمكنه أخيرًا إنتاج الكتل غالبًا ما يكون Block Builder الأفضل في التقاط MEV.
في الوقت نفسه ، يحتاج Prover في مخطط B52 إلى رهن الأصول ، ولكن نظرًا لأنه يجب إنشاء دليل الشجرة الفرعية فقط ، مقارنةً بتلك المخططات التي تحتاج إلى إنشاء دليل الكتلة بالكامل ، ** ستكون درجة اللامركزية في Prover أفضل (يمكن خفض متطلبات الأجهزة). **
** النشاط النشط: ** الحياة العامة للشبكة جيدة ، لأن L2 لديها شبكة p2p خاصة بها لبث المعاملات والأصوات / BP ، و Sequencer و Prover غير مركزية نسبيًا. لكننا بحاجة إلى حل المشكلتين اللتين ذكرناهما أعلاه. الأولى هي أن الكتلة الحاصلة على أعلى الدرجات يجب أن تكون كتلة قانونية ، والثانية هي أنها تحتاج إلى انتظار تقديم إثبات الكتلة الكامل إلى L1 قبل إدخال عنصر جديد. ولاية. لذلك ، هناك حاجة إلى آلية حوافز أكثر فاعلية لمنع تعطل شبكة التراكم بالكامل (التوقف عن العمل) بسبب عدم وجود جزء معين من إثبات النص.
** مقاومة الرقابة: ** إذا استطعنا أن نضمن أن أي شخص يمكنه نشر اقتراح الحظر ، والتأكد من أنه ليس فقط مقدم العرض يمكنه تقديم إثبات الحظر ، فعندئذٍ ستتمتع الشبكة بمكافحة جيدة للرقابة.
** النهاية: ** ترتبط نهائية L2 ارتباطًا وثيقًا بفاعلية الشبكة ، لأن النهاية النهائية التي تم التحقق منها لا تزال بحاجة إلى انتظار إرسال Block Proof ، ولكن في الواقع يمكنك أيضًا الوثوق بمحتوى الكتلة المقابل لـ BP حاصل على أعلى الدرجات (طالما أنه لا يحتوي على معاملات ضارة).
سيتم الكشف عن هذا الحظر في بداية نافذة قبول الحظر ، مما يعني أنه كمستخدم ، ما عليك سوى انتظار نافذة اقتراح الحظر ، والحظر حيث يمكن قبول المعاملة التي قدمتها.
** توارث أمان L1: ** بصفتها L2 تقوم بتحديث حالتها من خلال تقديم إثبات الصلاحية ، يمكنها أن ترث أمان L1.
اقتراح Fernet: تقديم VDF لاختيار مقدم العرض القانوني
** مقدمة إلى مخطط Fernet: ** حدد درجة تقديرية للعقد المختلفة في اللجنة (أي مجموعة عقد Sequencer) من خلال VDF في كل جولة من دورة إنتاج الكتل ، والكتلة التي اقترحها Sequencer مع أعلى النتيجة النهائية سوف تصبح قطعة صالحة.
** اولا كيف تنضم الى اللجنة؟ في الواقع ، أنت بحاجة إلى تعهد 16 ETH في L1 ، ** وانتظر 4 كتل L1 بعد اكتمال عملية التعهد ، ثم انضم إلى لجنة Sequencer. بالنسبة للخروج من لجنة التسلسل ، فأنت بحاجة إلى استدعاء وظيفة Unstake في العقد L1 ، ومن ثم يمكنك استعادة المبلغ المتبقي من تعهدك بعد 3 أيام أخرى.
إذن ، ما هو VDF؟ وظيفة التأخير التي يمكن التحقق منها هي وظيفة تأخير يمكن التحقق منها ، وتفي هذه الوظيفة الرياضية بخصائص التنفيذ التسلسلي الصارمة ، وستقوم ببعض خطوات الحساب وتستهلك على الأقل فترة زمنية يمكن التنبؤ بها. نسجل القيمة المحسوبة بواسطة VDF على أنها نقاط ، والتي تحقق توزيعًا طبيعيًا موحدًا ، لذلك ، بعد أن يحسب Sequencer نقاط VDF ، يمكنه الحكم على احتمالية أن يتم اختياره كطالب قانوني. **
يتم حساب VDF لجهاز التسلسل على النحو التالي:
النتيجة = VDF (مفتاح خاص ، مدخلات عامة)
المدخلات العامة = {رقم الكتلة الحالي ، randao}
randao هو رقم عشوائي يستخدم لمنع Sequencer من حساب نقاط VDF الخاصة به في جميع ارتفاعات الكتل المستقبلية مسبقًا
** تنقسم عملية Fernet بأكملها بشكل أساسي إلى 3 مراحل: **
مرحلة الاقتراح 2. إثبات المرحلة 3. الانتهاء
[تحليل اقتراح B52 الخاص بـ Aztec Labs: كيف تدرك ZK-Rollup لامركزية عقد التسلسل؟ ] (https://img-cdn.gateio.im/resized-social/moments-69a80767fe-71f4fc9e38-dd1a6f-7649e1)
** مرحلة الاقتراح: ** اقتراح \ _ PHASE \ _L1 \ _BLOCKS = كتلتان من Ethereum (ستستمر هذه المرحلة لكتلتين من L1)
في بداية هذه المرحلة ، سيستخدم كل مُسلسِل VDF لحساب نقاط VDF المقابلة في ارتفاع الكتلة الحالي. ** إذا اعتقد Sequencer أن نقاط VDF الخاصة به من المرجح أن تفوز بالحق في إنتاج كتلة هذه المرة (على افتراض أن النتيجة تفي بالتوزيع الطبيعي) ** ، فسيقوم بإرسال عقد إجمالي من الاقتراح إلى L1. يحتوي الاقتراح على: تجزئة تسلسل المعاملة ، للإشارة إلى كتلة L2 السابقة.
كتلة غير مثبتة: يتم إرسال محتويات الكتلة من عرض إلى عقد التجميع فقط. بعد ذلك ، ** يحتاج Sequencer إلى إرسال محتويات الكتلة المقابلة للكتلة غير المؤكدة وإثبات VDF إلى شبكة L2 p2p. **
مرحلة الإثبات: PROVING \ _PHASE \ _L1 \ _BLOCKS = 50 كتلة L1 (ستحتفظ هذه المرحلة بـ 50 كتلة L1 ، حوالي 10 دقائق)
يتلقى Prover جميع المعاملات المقابلة في Block Contents من شبكة L2 p2p ، وسيقوم بإنشاء إثبات للكتل ذات نقاط VDF أعلى. يعتمد إنشاء Proof أيضًا على طريقة تعاون Provers المتعددة بشكل متوازٍ (على غرار مخطط B52).
لذلك ، يحتاج Sequencer إلى تجميع الأدلة المقابلة للعديد من المعاملات المختلفة في Block Proof (بما في ذلك VDF Proof) في النهاية ، وإرساله إلى عقد التجميع L1. يمكن لأي شخص إرسال Block Contents الذي أرسل Block Proof إلى عقد Rollup.
** الإنهاء: ** من الضروري إرسال معاملة L1 لإنهاء الكتلة. يجب استيفاء الكتلة التي يمكن إتمامها: يتم إرسال محتويات الكتلة وإثبات الحظر ، ويجب إنهاء الكتلة السابقة المشار إليها. على أساس استيفاء الشروط المذكورة أعلاه ، يجب أن يكون لديك أيضًا أعلى درجة.
[تحليل اقتراح B52 الخاص بـ Aztec Labs: كيف تدرك ZK-Rollup لامركزية عقد التسلسل؟ ] (https://img-cdn.gateio.im/resized-social/moments-69a80767fe-985927a7a4-dd1a6f-7649e1)
آلية إنتاج بلوك خط الأنابيب: تجدر الإشارة إلى أن Fernet يتبنى آلية إنتاج بلوك خط الأنابيب.عند انتهاء مرحلة الاقتراح من الكتلة N ، يبدأ اقتراح المجموعة N + 1 (لدى Aptos والسلاسل العامة الأخرى أيضًا ممارسات مماثلة). ولكن بالنسبة للكتلة N + 1 ، فإنها تحتاج إلى الانتظار حتى يتم الانتهاء من الكتلة Nth قبل أن تتمكن من إرسال معاملة L1 Final Block واجتياز التحقق لتصبح الكتلة النهائية.
** أبعاد الهجوم المحتملة: ** إذا كان جهاز التسلسل الحاصل على أعلى نقاط VDF لا يبث بشكل متعمد محتويات الكتلة في L2 p2p ، فقد يؤدي ذلك إلى إعادة تنظيم الحظر.
حساب عدد كتل L2 في إعادة التسجيل: 1 + إثبات \ _ المرحلة \ _L1 \ _ BLOCKS / PROPOSAL \ _ PHASE \ _L1 \ _BLOCKS = 1 + 50/2 = 26 كتلة
الحل: قم بزيادة آلية كتلة العم لتجنب وجود كتلة مرشح كاملة واحدة فقط لكل فتحة L2s (فترة زمنية لتوليد الكتلة).
أهمية Fernet من حيث اللامركزية: ينضم Sequencer إلى لجنة Sequencer بتعهده بـ 16 ETH ، وعتبة الدخول ليست عالية (ولكن ليست منخفضة). لا يتطلب Prover أي تعهد ، ولكن لا توجد عقوبة إذا لم يقدم Prover إثباتًا. هذا هو عكس مخطط B52.
** النشاط النشط: ** يمكن ضمان فعالية الشبكة بشكل عام ، لأن آلية كتلة العم VDF + يمكن أن تضمن وجود أكثر من منتج كتلة واحد في كل جولة.
** MEV: ** اعتبارات MEV هي الأكثر خصوصية. تخطط الخطة لإدخال PBS ، بحيث بعد حساب درجة VDF عالية كمسلسل ، يمكنك العثور مباشرة على Block Builder لإنشاء كتلة أكثر قيمة.
** مقاومة الرقابة: ** سيتبنى Fernet أيضًا نفس آلية PBS مثل Ethereum ، لذلك في جوهرها ، فإن مشكلة Fernet المناهضة للرقابة تعادل تلك الخاصة بـ Ethereum's PBS.
شاهد النسخة الأصلية
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
تحليل اقتراح B52 من Aztec Labs: كيف يدرك ZK-Rollup لامركزية عقد التسلسل؟
المؤلف: 0xhhh ، EthStorage
المحرر: Faust، Geek web3
مقدمة: منذ أن أصبحت Rollup شائعة ، كانت لا مركزية Sequencer دائمًا محور تركيز مجتمع Ethereum / Celestia ، وهي أيضًا جبل لا يمكن التغلب عليه في بحث وتطوير Layer2. في هذا الصدد ، اقترحت مخططات التجميع المختلفة أفكارًا حول لامركزية العقدة ، مما يوفر مساحة تخيل واسعة للغاية لهذا الموضوع.
يأخذ مؤلف هذه المقالة مشروع ZKRollup الشهير Aztec كمثال ، ويستخدم الاقتراحين المسمى B52 و Fernet اللذين اقترحهما Aztec Labs مؤخرًا كنقطة انطلاق لتحليل كيفية تحقيق ZKR للامركزية لعقد التسلسل للقراء.
الاقتراح B52: مخطط التسلسل غير المسموح به
** يهدف الاقتراح B52 إلى تحقيق ما يلي (بشكل مثالي): **
شبكة التسلسل اللامركزية ، تنتخب العقد L2 نفسها كل جولة من العروض
شبكة المُثبِت اللامركزية ، متطلبات الأجهزة المنخفضة لعقد المُثبِّت
التراكمي لديه مقاومة جيدة للرقابة ككل.
يتم الحصول على قيمة MEV الناتجة عن L2 بواسطة عقد L2
عندما يتم تقديم كتلة L2 إلى طبقة DA ، يمكن الحصول على نهائية أكثر فاعلية ، ويجب أن تنتظر النتيجة النهائية غير القابلة للإلغاء حتى يتم تقديم إثبات الصلاحية (إثبات الصلاحية)
يمكن أن يكون للرمز L2 نموذج اقتصادي جيد
يتم نشر كل من فدرات L2 وبيانات المعاملات في شبكة L2 p2p
يرث L2 أمان L1
[تحليل اقتراح B52 الخاص بـ Aztec Labs: كيف تدرك ZK-Rollup لامركزية عقد التسلسل؟ ] (https://img-cdn.gateio.im/resized-social/moments-69a80767fe-38bf333c5c-dd1a6f-7649e1)
** يقسم هذا المخطط عملية إنتاج بلوك L2 بأكملها إلى ثلاث مراحل زمنية: **
من بينها ، مرحلة BPW (اقتراح الكتلة) هي عملية يقترح فيها متسلسلون متعددون Seuqnecer كتلًا مختلفة ويتنافسون ، ويختار Prover كتلة مرشح لإعطاء تصويت.
BAW (Block Acceptance) هي العملية التي يقوم فيها Prover ببناء إثبات صحة للكتلة وإرساله.
نافذة اقتراح الكتلة (مرحلة اقتراح الكتلة):
يمكن تقسيم BPW إلى ثلاث مراحل: ** اقتراح الحظر ، كتلة التصويت ، التجميع **.
[تحليل اقتراح B52 الخاص بـ Aztec Labs: كيف يدرك ZK-Rollup لامركزية عقد التسلسل؟ ] (https://img-cdn.gateio.im/resized-social/moments-69a80767fe-bb6d6642f2-dd1a6f-7649e1)
[تحليل اقتراح B52 الخاص بـ Aztec Labs: كيف تدرك ZK-Rollup لامركزية عقد التسلسل؟ ] (https://img-cdn.gateio.im/resized-social/moments-69a80767fe-d946c2a2b6-dd1a6f-7649e1)
يمكن لأي شخص في مرحلة اقتراح الحظر (BP) جمع المعاملات وبث محتوى BP الخاص به. سيحتوي محتوى BP على ثلاثة أجزاء: تجزئة طلب txs ، ونسبة مكافأة المُثبِت ، ومقدار حرق الرمز المميز
[تحليل اقتراح B52 الخاص بـ Aztec Labs: كيف تدرك ZK-Rollup لامركزية عقد التسلسل؟ ] (https://img-cdn.gateio.im/resized-social/moments-69a80767fe-1afcb38c75-dd1a6f-7649e1)
** تجزئة ترتيب txs: ** يختار مقدم العرض ويصنف الدفعة الأكثر قيمة من المعاملات من تجمع المعاملات L2 (mempool) ، ثم يضع قيمة التجزئة لهذه المجموعة من المعاملات في الكتلة التي ينشئها.
** نسبة مكافأة المُثبِت: ** النسبة المئوية لمكافأة الكتلة التي يتقاسمها Sequencer إلى Prover
** مبلغ الرمز المميز للنسخ: ** عدد الرمز المميز L2 الذي اقترحه مقدم العرض ليتم إتلافه ، ثم يرسل BP المقترح إلى شبكة L2 p2p
** مرحلة الاقتراع: **
[تحليل اقتراح B52 الخاص بـ Aztec Labs: كيف تدرك ZK-Rollup لامركزية عقد التسلسل؟ ] (https://img-cdn.gateio.im/resized-social/moments-69a80767fe-931ecadf03-dd1a6f-7649e1)
بعد أن يتلقى Prover BP الذي اقترحه مقترحون مختلفون في شبكة p2p ، سيصوت لشركة BP التي يمكن أن تمنحه أكبر قدر من المكافأة. ومع ذلك ، فإن تكوين التصويت خاص جدًا:
** التصويت = {BlockHash ، فهرس شجرة الإثبات} **
BlockHash هو تجزئة الاقتراح الذي سيصوت عليه Prover ، وفهرس شجرة الإثبات هو قيمة فهرس الأوراق لشجرة الإثبات التي سيشارك Prover في بنائها (موضح لاحقًا)
[تحليل اقتراح B52 الخاص بـ Aztec Labs: كيف يدرك ZK-Rollup لامركزية عقد التسلسل؟ ] (https://img-cdn.gateio.im/resized-social/moments-69a80767fe-475d3d21b7-dd1a6f-7649e1)
** التجميع التجميعي: ** يجمع مقدم العرض أصوات Provers for BP في شبكة L2 p2p ، ويجمعها ويضعها في BP ، ويرسلها إلى L1 (تحتوي كل شركة BP بشكل عام على سجلات تصويت مرتبطة بنفسها فقط).
[تحليل اقتراح B52 الخاص بـ Aztec Labs: كيف تدرك ZK-Rollup لامركزية عقد التسلسل؟ ] (https://img-cdn.gateio.im/resized-social/moments-69a80767fe-9b58f874c9-dd1a6f-7649e1)
** هنا ، من الضروري التأكيد على المتطلبات الأساسية لاختيار BP وإدراجها في دفتر الأستاذ Rollp: **
** الحصول على أعلى الدرجات: **
النتيجة (ص) = NUM \ _PROVERS (x) ^ 3 \ * BURN \ _BID (z) ^ 2
NUM \ _PROVERS (x) هو عدد أصوات Prover التي حصلت عليها BP ، و BURN \ _BID هو عدد الرموز L2 المقترح تدميرها بواسطة BP. نظرًا لأنه كلما ارتفع BURN \ _BID ، قلت المكافأة التي سيحصل عليها مقدم BP في النهاية ، لذلك يجب تعيين هذه القيمة بشكل صحيح.
في الوقت نفسه ، يجب تقديم BP إلى L1 قبل نهاية نافذة اقتراح الحظر ، ويجب تحميل إثبات الصلاحية المقابل إلى L1 قبل نهاية نافذة قبول الحظر.
ملاحظة: في حساب درجات BP ، يمثل عدد الأصوات النسبة الأكبر ، متبوعًا بعدد الرموز المحترقة. في الوقت نفسه ، يسمح مخطط B52 لمقدمي العروض المتعددين (المتسلسلات في الواقع) بالتنافس على حصة BP فعالة
يتطلب مخطط B52 فقط من العارض (منظم التسلسل) تحديد عدد الرموز المميزة للنسخ في BP الخاص به (على غرار طريقة EIP1559) بدون رموز الحصة مسبقًا ، والتي يمكن أن تجعل الشبكة أكثر بدون إذن (بدون إذن وصول) ، وهي مفيد أيضًا لـ L2 Native Token ينتج الانكماش.
بالإضافة إلى ذلك ، لا تحتوي BP على بيانات المعاملات الكاملة ، ولكن فقط تجزئة تسلسل المعاملة.السبب مشابه لنظام Ethereum PBS ، الذي يهدف إلى منع MEV من التجسس عليها من قبل مقدمي العروض الآخرين.
** نافذة قبول الحظر (مرحلة قبول الحظر) شرح مفصل: **
[تحليل اقتراح B52 الخاص بـ Aztec Labs: كيف تدرك ZK-Rollup لامركزية عقد التسلسل؟ ] (https://img-cdn.gateio.im/resized-social/moments-69a80767fe-38bf333c5c-dd1a6f-7649e1)
[تحليل اقتراح B52 الخاص بـ Aztec Labs: كيف تدرك ZK-Rollup لامركزية عقد التسلسل؟ ] (https://img-cdn.gateio.im/resized-social/moments-69a80767fe-0b0d76936f-dd1a6f-7649e1)
بعد انتهاء نافذة اقتراح الحظر ، يحتاج Prover إلى الكشف عن بيانات المعاملة الكاملة المقابلة لـ BP الخاص به. إذا تم تحديد BP الذي تم التصويت عليه بواسطة Prover (يمكن الاستعلام عن أعلى درجة من خلال عقد L1) ، فسيحتاجون إلى إنشاء شجرة إثبات فرعية تتوافق مع فهرس شجرة الإثبات المقدم أثناء التصويت.
[تحليل اقتراح B52 الخاص بـ Aztec Labs: كيف تدرك ZK-Rollup لامركزية عقد التسلسل؟ ] (https://img-cdn.gateio.im/resized-social/moments-69a80767fe-475d3d21b7-dd1a6f-7649e1)
بافتراض أن كتلة Aztec تحتوي على 2 ^ 13 = 16384 معاملة وهناك 2048 مُثبِّتًا ، فإن كل مُثبِت يُنشئ شجرة إثبات فرعية تتكون من 2 ^ 3 = 8 معاملات. ثم يبث المُثبِّت شجرة الإثبات الفرعية التي أنشأها بنفسه إلى في L2 p2p شبكة. بعد أن يستلمها مقدم الطلب ، سيقوم بتجميع جميع أشجار الإثبات الفرعية في كتلة برهان.
[تحليل اقتراح B52 الخاص بـ Aztec Labs: كيف تدرك ZK-Rollup لامركزية عقد التسلسل؟ ] (https://img-cdn.gateio.im/resized-social/moments-69a80767fe-540e07d719-dd1a6f-7649e1)
ثم يقدم Propsoer الدليل المجمع إلى عقد L1 Rollup ، وسوف يتحقق العقد من صحة الإثبات ونتائج انتقال الحالة المقابلة. وتجدر الإشارة هنا إلى أنه إذا أخفق المُقَدِّم عمدًا في تقديم الدليل ، فلن يتمكن فقط من الحصول على عائد مكافأة الكتلة الذي وعد به مقدم العرض ، بل سيتم أيضًا خفضه ، لأنه لكي يصبح مُثلاً ، فإنه يحتاج إلى تعهد رمز مقدما. لذلك ، على عكس Proposer (Sequencer) ، فإن Prover ليس بدون إذن.
** سلف الدولة (مرحلة تقدم الدولة) شرح مفصل: **
[تحليل اقتراح B52 الخاص بـ Aztec Labs: كيف تدرك ZK-Rollup لامركزية عقد التسلسل؟ ] (https://img-cdn.gateio.im/resized-social/moments-69a80767fe-adbf827c5b-dd1a6f-7649e1)
بعد انتهاء نافذة قبول الحظر ، سيحدد عقد التجميع كتلة ذات أعلى درجة ليتم تضمينها في دفتر الأستاذ التجميعي ، وإرسال مكافأة مكافأة الكتلة إلى مقدم العرض والمثبّت على التوالي وفقًا للنسبة التي أعلنها مقدم العرض (منظم التسلسل) في يتقدم.
** ما ورد أعلاه هو محلول Aztec B52. ومع ذلك ، يعتقد مؤلف هذا المقال أن هناك بعض المشكلات المحتملة في اقتراح B52: **
السؤال 1: ** إذا كان إثبات صحة الكتلة الحاصلة على أعلى الدرجات غير كامل **. الحل المقدم في الاقتراح هو أنه إذا قدم مقدم العرض 50 ٪ فقط من الإثبات ، فيمكنه الحصول على 50 ٪ فقط من مكافآت الكتلة ، وذلك للتأكد من أن مقدم العرض ليس لديه دافع لعدم تقديم دليل كامل عن عمد. في الوقت نفسه ، يمكن لـ Prover أيضًا تقديم دليل مباشرة إلى العقد.
وفقًا لوصف الاقتراح ، من المقبول قبول كتلة دون إثبات صحة المعاملات الكاملة. هذا في الواقع غير معقول: لأن: zkrollup يعلن فقط أن الحالة الجديدة المقابلة لهذه الكتلة صالحة عندما يتم تقديم إثبات الصلاحية.
إذا كان الدليل الإجمالي الذي قدمه مقدم العرض إلى L1 يفتقد إلى دليل على معاملة معينة ، فمن الواضح أن أدلة انتقال الحالة لجميع المعاملات التي تحدث بعد هذه المعاملة غير صالحة (لأن المعاملات يتم تنفيذها بالتتابع ولها تبعيات حالة) ، فنحن من المستحيل أيضًا تأكيد صلاحية الحالة الجديدة المقابلة لهذه الكتلة.
لذلك ، في هذا الوقت ، يجب أن تكون الطريقة المعقولة هي الدخول إلى نافذة قبول الحظر التي تنتظر إلى ما لا نهاية حتى يتم تقديم جميع إثباتات المعاملة.
السؤال 2: ** إذا كانت الكتلة الحاصلة على أعلى درجة عبارة عن كتلة غير قانونية (لم يتم توضيح ذلك في مخطط B52). ** يحتوي BP فقط على تجزئة تسلسل المعاملة ، لذلك يمكن للمقترح الضار فعليًا إنشاء معاملات إشكالية عمداً ، مثل معاملات الإنفاق المزدوج. لذلك في هذا الوقت ، من الضروري بالفعل إضافة وظيفة في عقد L1 يمكن لأي شخص أن يقدم دليلًا غير قانوني. يتم استخدام هذا الدليل غير القانوني لإثبات أن BP ذات أعلى الدرجات هي كتلة غير قانونية.
ويجب أن يكافأ هذا النوع من التقارير ، يمكننا مكافأة رمز الحرق الذي أرسله مقدم العرض إلى العقد إلى عقدة المراسل الذي قدم الدليل غير القانوني.
** تفكير مثير للاهتمام: ** حول كتل العم و Prover Work الزائدة عن الحاجة: سيستخدم مخطط B52 بالفعل BPs الأخرى (الذين قدموا أدلة كاملة) التي تظهر في هذه الجولة كأعمام بعد BP مع أعلى الدرجات في كل جولة. تعيين مكافأة كتلة عم معينة.
يتبع هذا في الواقع نهج آلية إجماع ETH POW. من أجل تجنب التركيز المفرط لقوة الحوسبة ، من الضروري تخصيص جزء من مكافآت الكتلة لمقدمي الكتل غير المقبولين (عمال المناجم) لحماية مصالح تجمعات التعدين الصغيرة / عمال المناجم الفرديين وتجنب احتكار مجمعات التعدين الكبيرة لقوة الحوسبة. لذلك ، يعد أيضًا اختيارًا ذكيًا للغاية لاعتماد آلية حظر العم التي يعمل بها Ethereum بشكل جيد.
أهمية اقتراح B52 من حيث اللامركزية التراكمية: ** مقدم العرض لا مركزي ولا يتطلب تعهدًا ، وعتبة الدخول منخفضة ** ؛ ولكن لأنك تحتاج إلى بناء الكتل الأكثر قيمة بنفسك ، وتحتاج إلى جمع الأصوات من العارضين الآخرين ، واجمع كل الأدلة. في الواقع ، عتبة الأجهزة لمقدم العرض ليست منخفضة كما هو مذكور في الاقتراح (على سبيل المثال ، قد لا يكون النطاق الترددي منخفضًا جدًا).
لذلك ، ستصبح في النهاية شبكة مركزية نسبيًا ، على غرار Mev-Boost Builder ، لأن مقدم العرض الذي يمكنه أخيرًا إنتاج الكتل غالبًا ما يكون Block Builder الأفضل في التقاط MEV.
في الوقت نفسه ، يحتاج Prover في مخطط B52 إلى رهن الأصول ، ولكن نظرًا لأنه يجب إنشاء دليل الشجرة الفرعية فقط ، مقارنةً بتلك المخططات التي تحتاج إلى إنشاء دليل الكتلة بالكامل ، ** ستكون درجة اللامركزية في Prover أفضل (يمكن خفض متطلبات الأجهزة). **
** النشاط النشط: ** الحياة العامة للشبكة جيدة ، لأن L2 لديها شبكة p2p خاصة بها لبث المعاملات والأصوات / BP ، و Sequencer و Prover غير مركزية نسبيًا. لكننا بحاجة إلى حل المشكلتين اللتين ذكرناهما أعلاه. الأولى هي أن الكتلة الحاصلة على أعلى الدرجات يجب أن تكون كتلة قانونية ، والثانية هي أنها تحتاج إلى انتظار تقديم إثبات الكتلة الكامل إلى L1 قبل إدخال عنصر جديد. ولاية. لذلك ، هناك حاجة إلى آلية حوافز أكثر فاعلية لمنع تعطل شبكة التراكم بالكامل (التوقف عن العمل) بسبب عدم وجود جزء معين من إثبات النص.
** مقاومة الرقابة: ** إذا استطعنا أن نضمن أن أي شخص يمكنه نشر اقتراح الحظر ، والتأكد من أنه ليس فقط مقدم العرض يمكنه تقديم إثبات الحظر ، فعندئذٍ ستتمتع الشبكة بمكافحة جيدة للرقابة.
** النهاية: ** ترتبط نهائية L2 ارتباطًا وثيقًا بفاعلية الشبكة ، لأن النهاية النهائية التي تم التحقق منها لا تزال بحاجة إلى انتظار إرسال Block Proof ، ولكن في الواقع يمكنك أيضًا الوثوق بمحتوى الكتلة المقابل لـ BP حاصل على أعلى الدرجات (طالما أنه لا يحتوي على معاملات ضارة).
سيتم الكشف عن هذا الحظر في بداية نافذة قبول الحظر ، مما يعني أنه كمستخدم ، ما عليك سوى انتظار نافذة اقتراح الحظر ، والحظر حيث يمكن قبول المعاملة التي قدمتها.
** توارث أمان L1: ** بصفتها L2 تقوم بتحديث حالتها من خلال تقديم إثبات الصلاحية ، يمكنها أن ترث أمان L1.
اقتراح Fernet: تقديم VDF لاختيار مقدم العرض القانوني
** مقدمة إلى مخطط Fernet: ** حدد درجة تقديرية للعقد المختلفة في اللجنة (أي مجموعة عقد Sequencer) من خلال VDF في كل جولة من دورة إنتاج الكتل ، والكتلة التي اقترحها Sequencer مع أعلى النتيجة النهائية سوف تصبح قطعة صالحة.
** اولا كيف تنضم الى اللجنة؟ في الواقع ، أنت بحاجة إلى تعهد 16 ETH في L1 ، ** وانتظر 4 كتل L1 بعد اكتمال عملية التعهد ، ثم انضم إلى لجنة Sequencer. بالنسبة للخروج من لجنة التسلسل ، فأنت بحاجة إلى استدعاء وظيفة Unstake في العقد L1 ، ومن ثم يمكنك استعادة المبلغ المتبقي من تعهدك بعد 3 أيام أخرى.
إذن ، ما هو VDF؟ وظيفة التأخير التي يمكن التحقق منها هي وظيفة تأخير يمكن التحقق منها ، وتفي هذه الوظيفة الرياضية بخصائص التنفيذ التسلسلي الصارمة ، وستقوم ببعض خطوات الحساب وتستهلك على الأقل فترة زمنية يمكن التنبؤ بها. نسجل القيمة المحسوبة بواسطة VDF على أنها نقاط ، والتي تحقق توزيعًا طبيعيًا موحدًا ، لذلك ، بعد أن يحسب Sequencer نقاط VDF ، يمكنه الحكم على احتمالية أن يتم اختياره كطالب قانوني. **
يتم حساب VDF لجهاز التسلسل على النحو التالي:
النتيجة = VDF (مفتاح خاص ، مدخلات عامة)
المدخلات العامة = {رقم الكتلة الحالي ، randao}
randao هو رقم عشوائي يستخدم لمنع Sequencer من حساب نقاط VDF الخاصة به في جميع ارتفاعات الكتل المستقبلية مسبقًا
** تنقسم عملية Fernet بأكملها بشكل أساسي إلى 3 مراحل: **
[تحليل اقتراح B52 الخاص بـ Aztec Labs: كيف تدرك ZK-Rollup لامركزية عقد التسلسل؟ ] (https://img-cdn.gateio.im/resized-social/moments-69a80767fe-71f4fc9e38-dd1a6f-7649e1)
** مرحلة الاقتراح: ** اقتراح \ _ PHASE \ _L1 \ _BLOCKS = كتلتان من Ethereum (ستستمر هذه المرحلة لكتلتين من L1)
في بداية هذه المرحلة ، سيستخدم كل مُسلسِل VDF لحساب نقاط VDF المقابلة في ارتفاع الكتلة الحالي. ** إذا اعتقد Sequencer أن نقاط VDF الخاصة به من المرجح أن تفوز بالحق في إنتاج كتلة هذه المرة (على افتراض أن النتيجة تفي بالتوزيع الطبيعي) ** ، فسيقوم بإرسال عقد إجمالي من الاقتراح إلى L1. يحتوي الاقتراح على: تجزئة تسلسل المعاملة ، للإشارة إلى كتلة L2 السابقة.
كتلة غير مثبتة: يتم إرسال محتويات الكتلة من عرض إلى عقد التجميع فقط. بعد ذلك ، ** يحتاج Sequencer إلى إرسال محتويات الكتلة المقابلة للكتلة غير المؤكدة وإثبات VDF إلى شبكة L2 p2p. **
مرحلة الإثبات: PROVING \ _PHASE \ _L1 \ _BLOCKS = 50 كتلة L1 (ستحتفظ هذه المرحلة بـ 50 كتلة L1 ، حوالي 10 دقائق)
يتلقى Prover جميع المعاملات المقابلة في Block Contents من شبكة L2 p2p ، وسيقوم بإنشاء إثبات للكتل ذات نقاط VDF أعلى. يعتمد إنشاء Proof أيضًا على طريقة تعاون Provers المتعددة بشكل متوازٍ (على غرار مخطط B52).
لذلك ، يحتاج Sequencer إلى تجميع الأدلة المقابلة للعديد من المعاملات المختلفة في Block Proof (بما في ذلك VDF Proof) في النهاية ، وإرساله إلى عقد التجميع L1. يمكن لأي شخص إرسال Block Contents الذي أرسل Block Proof إلى عقد Rollup.
** الإنهاء: ** من الضروري إرسال معاملة L1 لإنهاء الكتلة. يجب استيفاء الكتلة التي يمكن إتمامها: يتم إرسال محتويات الكتلة وإثبات الحظر ، ويجب إنهاء الكتلة السابقة المشار إليها. على أساس استيفاء الشروط المذكورة أعلاه ، يجب أن يكون لديك أيضًا أعلى درجة.
[تحليل اقتراح B52 الخاص بـ Aztec Labs: كيف تدرك ZK-Rollup لامركزية عقد التسلسل؟ ] (https://img-cdn.gateio.im/resized-social/moments-69a80767fe-985927a7a4-dd1a6f-7649e1)
آلية إنتاج بلوك خط الأنابيب: تجدر الإشارة إلى أن Fernet يتبنى آلية إنتاج بلوك خط الأنابيب.عند انتهاء مرحلة الاقتراح من الكتلة N ، يبدأ اقتراح المجموعة N + 1 (لدى Aptos والسلاسل العامة الأخرى أيضًا ممارسات مماثلة). ولكن بالنسبة للكتلة N + 1 ، فإنها تحتاج إلى الانتظار حتى يتم الانتهاء من الكتلة Nth قبل أن تتمكن من إرسال معاملة L1 Final Block واجتياز التحقق لتصبح الكتلة النهائية.
** أبعاد الهجوم المحتملة: ** إذا كان جهاز التسلسل الحاصل على أعلى نقاط VDF لا يبث بشكل متعمد محتويات الكتلة في L2 p2p ، فقد يؤدي ذلك إلى إعادة تنظيم الحظر.
حساب عدد كتل L2 في إعادة التسجيل: 1 + إثبات \ _ المرحلة \ _L1 \ _ BLOCKS / PROPOSAL \ _ PHASE \ _L1 \ _BLOCKS = 1 + 50/2 = 26 كتلة
الحل: قم بزيادة آلية كتلة العم لتجنب وجود كتلة مرشح كاملة واحدة فقط لكل فتحة L2s (فترة زمنية لتوليد الكتلة).
أهمية Fernet من حيث اللامركزية: ينضم Sequencer إلى لجنة Sequencer بتعهده بـ 16 ETH ، وعتبة الدخول ليست عالية (ولكن ليست منخفضة). لا يتطلب Prover أي تعهد ، ولكن لا توجد عقوبة إذا لم يقدم Prover إثباتًا. هذا هو عكس مخطط B52.
** النشاط النشط: ** يمكن ضمان فعالية الشبكة بشكل عام ، لأن آلية كتلة العم VDF + يمكن أن تضمن وجود أكثر من منتج كتلة واحد في كل جولة.
** MEV: ** اعتبارات MEV هي الأكثر خصوصية. تخطط الخطة لإدخال PBS ، بحيث بعد حساب درجة VDF عالية كمسلسل ، يمكنك العثور مباشرة على Block Builder لإنشاء كتلة أكثر قيمة.
** مقاومة الرقابة: ** سيتبنى Fernet أيضًا نفس آلية PBS مثل Ethereum ، لذلك في جوهرها ، فإن مشكلة Fernet المناهضة للرقابة تعادل تلك الخاصة بـ Ethereum's PBS.