ملاحظة: لغرض تسهيل فهم وتحليل نموذج التراكمي، قام باحث Celestia NashQ بتقسيم مُسلسِل التراكمي إلى كيانين منطقيين - المُجمِّع ومنتج الرأس. وفي الوقت نفسه، قام بتقسيم عملية طلب المعاملات إلى ثلاث خطوات منطقية: التضمين والطلب والتنفيذ.
وبالاسترشاد بهذا التفكير التحليلي، أصبحت المتغيرات الستة الرئيسية لمجموعة السيادة أكثر وضوحًا وأسهل للفهم. ناقشت NashQ بالتفصيل مقاومة الرقابة وحيوية متغيرات مجموعة التحديثات المختلفة، بالإضافة إلى الحد الأدنى من التكوين لكل عقدة متغيرة لمجموعة التحديثات في حالة تقليل الثقة (على سبيل المثال، لتحقيق حالة عدم الثقة، على الأقل ما هي أنواع العقد التي يحتاج مستخدمو مجموعة التحديثات إلى يجري).
على الرغم من أن هذا المقال يحلل Rollup من منظور Celestia، والذي يختلف عن الطريقة التي يحلل بها مجتمع Ethereum نموذج Rollup، مع الأخذ في الاعتبار الترابطات العديدة بين Ethereum Rollup وCelestia Sovereign Rollup، فضلاً عن التأثير المتزايد للأخير، فإن هذه المقالة أيضًا متطرفة للغاية يستحق القراءة لعشاق الايثيريوم.
المجموعات المجمعة هي مجموعات بلوكتشين تقوم بنشر بيانات المعاملات الخاصة بها إلى بلوكتشين أخرى وترث إجماعها وتوافر البيانات.
لماذا أقوم بتغيير "الحظر" إلى "بيانات المعاملة" هنا؟ اسمح لي أن أخبرك بالفرق بين كتلة القيمة المحتسبة وبيانات القيمة المحتسبة وأوضح لك أن الحد الأدنى من القيمة المحتسبة يحتاج فقط إلى بيانات القيمة المحتسبة مع متغيرنا الأول.
الكتلة المجمعة هي بنية بيانات تمثل blockchain على ارتفاع معين. وهو يتألف من البيانات المجمعة ورأس التراكمي. وتكون البيانات المجمعة إما مجموعة من المعاملات أو فرق الحالة بين دفعات المعاملات.
إن أبسط طريقة لإنشاء مجموعة بيانات تبدأ من خلال قيام المستخدم بنشر المعاملات على blockchain آخر. سوف نطلق على blockchain طبقة الإجماع وتوافر البيانات، لكنني سأختصرها إلى DA-Layer في جميع الرسوم البيانية التالية. (ملاحظة: يشبه Layer1 الذي يُشار إليه غالبًا في مجتمع Ethereum).
في المتغير الأول الخاص بنا، يجب على كل عقدة تراكمية إعادة تشغيل جميع المعاملات على blockchain للتحقق من أحدث حالة. لقد أنشأنا للتو مجموعة متشائمة!
مجموعة التحديثات المتشائمة هي مجموعة تراكمية تدعم فقط العقد الكاملة التي تعيد تشغيل جميع المعاملات في المجموعة المجمعة للتحقق من صحتها.
لكن في هذه الحالة من هو المُسلسل في هذه الحالة؟ لا يقوم أي كيان فعليًا بتنفيذ المعاملات باستثناء العقد الكاملة المجمعة نفسها. عادة، يقوم جهاز التسلسل بتجميع المعاملات وإنتاج رأس تراكمي، ولكن لا يوجد رأس في هذه الحالة!
لتسهيل المناقشة، قمنا بتقسيم جهاز التسلسل إلى كيانين منطقيين: المُجمِّع ومنتج الرأس الذي يميزه. يجب أن يكون أحد الكيانات على علم بالحالة (على سبيل المثال، يجب تنفيذ الحالة لحساب الرأس)، ولكن لا يحتاج المجمع إلى فهم الحالة حتى يتمكن من تجميعها.
التسلسل هو عملية التجميع وإنتاج الرأس.
التجميع هو عملية تجميع المعاملات في دفعة واحدة. تتكون مجموعة المعاملات من معاملة واحدة أو أكثر. (ملاحظة: الدُفعة هي جزء من البيانات الموجودة في الكتلة المجمعة باستثناء الرأس).
إنتاج الرأس هو عملية إنشاء رأس القيمة المحتسبة.
الرأس المجمع عبارة عن بيانات وصفية حول الكتلة، والتي تتضمن على الأقل التزامًا بالمعاملات في تلك الكتلة. (ملاحظة: الالتزام هنا يشير إلى الالتزام بصحة نتائج معالجة المعاملة).
من خلال المنظور أعلاه، يمكننا أن نرى من يلعب دور كل مكون من مكونات مجموعة التحديثات. دعونا نلقي نظرة أولا على الجزء المجمع. لا تحتوي المجموعة المتشائمة المذكورة سابقًا على عملية إنتاج رأس، ويقوم المستخدمون بنشر المعاملات مباشرة إلى طبقة DA، مما يعني أن شبكة طبقة DA تعمل بشكل أساسي كمجمع.
التراكمي المتشائم هو أحد أشكال التراكمي الذي يقوم بتفويض خطوة التجميع إلى طبقة DA. ليس لديها جهاز تسلسل. يُطلق على هذا النوع من التجميع أحيانًا اسم "التراكمي المستند إلى".
يتمتع التراكمي المستند إلى نفس مقاومة الرقابة والحيوية التي تتمتع بها طبقة DA (يقيس النشاط سرعة استجابة النظام لطلبات المستخدم). إذا أراد مستخدمو هذا النوع من مجموعة التحديثات تحقيق حالة من الحد الأدنى من الثقة (الأقرب إلى عدم الثقة)، فيجب عليهم تشغيل عقدة خفيفة لطبقة DA وعقدة تراكمية كاملة على الأقل.
دعونا نناقش التجميع المتشائم باستخدام المجمعات المشتركة. تم اقتراح هذه الفكرة من قبل إيفان فوربس في منشوره في المنتدى حول تصميم جهاز التسلسل المشترك. هذاالافتراض الأساسي هو أن جهاز التسلسل المشترك هو الطريقة الرسمية الوحيدة لتسلسل المعاملات. يشرح إيفان فوائد أجهزة التسلسل المشتركة مثل هذا:
"لفتح تجربة مستخدم مكافئة لـ web2، يمكن لأجهزة التسلسل المشتركة [...] توفير التزامات ناعمة سريعة (ملاحظة: ليس ضمانًا موثوقًا للغاية). توفر هذه الالتزامات الناعمة بعض الوعد التعسفي بالترتيب النهائي للمعاملات (أي أنها تعد بعدم تغيير أمر المعاملة)، ويمكن استخدامها لإنشاء إصدارات محدثة قبل الأوان من الحالة (ولكن لم يتم الانتهاء من الانتهاء بعد في هذا الوقت).
بمجرد تأكيد نشر بيانات الكتلة على الطبقة الأساسية (يشير s/b إلى DAlayer)، يمكن اعتبار الحالة نهائية."
نظرًا لأننا لا نزال مجموعة تراكمية متشائمة، فلدينا فقط عقد تراكمية كاملة ولا توجد عقد خفيفة. يجب على كل عقدة تنفيذ جميع المعاملات لضمان الصلاحية. لا توجد عقد ضوئية في هذا النظام، لذا ليست هناك حاجة لرأس تراكمي، المعروف أيضًا باسم منتج الرأس. (ملاحظة: بشكل عام، لا تحتاج العقدة الخفيفة في blockchain إلى مزامنة الكتل الكاملة، ولكنها تتلقى فقط رؤوس الكتلة)
نظرًا لعدم وجود خطوة إنتاج رأس تراكمي، لا يحتاج جهاز التسلسل المشترك التراكمي المذكور أعلاه إلى تنفيذ معاملات لتحديثات الحالة (شرط أساسي لإنتاج الرأس)، ولكنه يتضمن فقط عملية تجميع بيانات المعاملة. لذلك أفضّل أن أسميه مجمعًا مشتركًا.
في هذا المتغير، يحتاج مستخدمو مجموعة التحديثات إلى تشغيل ما يلي على الأقل في حالة تقليل الثقة:
العقدة الضوئية لطبقة DA + العقدة الخفيفة لشبكة التجميع المشتركة + العقدة الكاملة المجمعة.
في هذا الوقت، من الضروري التحقق من رأس المجمع المنشور (لا يشير إلى رأس التجميع) من خلال العقدة الضوئية لشبكة المجمع المشتركة. كما ذكر أعلاه، يتولى المجمع المشترك مهمة فرز المعاملات. في رأس المجمع المنشور، يحتوي على التزام تشفير، يتوافق مع الدفعة التي نشرها على طبقة DA.
بهذه الطريقة، يمكن لمشغل عقدة التراكمي التأكد من أن الدفعة المستلمة من طبقة DA تم إنشاؤها بواسطة المجمع المشترك، وليس بواسطة الآخرين.
(نظرًا لأن المحتوى الوارد أعلاه غامض نسبيًا، يمكنك قراءة الرسم التخطيطي مرة أخرى)
التضمين هو العملية التي يتم من خلالها قبول المعاملة في blockchain.
الطلب هو عملية ترتيب المعاملات في تسلسل محدد في blockchain.
التنفيذ هو العملية التي تتم من خلالها معالجة المعاملات في blockchain، ويتم تطبيق آثارها على حالة blockchain.
ولأن المجمع المشترك يتحكم في التضمين والنظام، فإننا نرث مقاومته للرقابة.
إذا افترضنا أن L_ss هي حيوية المجمع المشترك، وL_da هي حيوية طبقة DA، فإن حيوية هذا المخطط هي L = L_da && L_ss. بمعنى آخر، إذا كان أي من النظامين يعاني من فشل في الحيوية، فإن التجميع أيضًا يعاني من فشل في الحيوية.
من أجل البساطة، سأستخدم الحيوية باعتبارها منطقية. إذا فشل المجمع المشترك، فلن نتمكن من متابعة عملية التجميع. إذا فشلت طبقة DA، فيمكننا الاستمرار في الالتزامات الناعمة للمجمع المشترك. ومع ذلك، سنعتمد على إجماع المُجمِّع المشترك وتوافر البيانات، وهو ما سيكون أسوأ من طبقة DA الأصلية.
دعنا نستمر في استكشاف مقاومة الرقابة لحل التجميع أعلاه:
في هذا المخطط، لا تستطيع طبقة DA فرض رقابة على معاملات محددة. (ملاحظة: قد ترفض مراجعة المعاملات في كثير من الأحيان السماح بتحميل معاملات معينة إلى السلسلة). يمكنه فقط مراقبة دفعات التجميع الكاملة التي قام المجمع المشترك بتجميعها بالفعل. (رفض دفعة ليتم تضمينها في طبقة DA).
ومع ذلك، وفقًا لسير عمل التراكمي، عندما يرسل مجمع المشاركة دفعة المعاملة إلى طبقة DA، فقد أكمل بالفعل تسلسل المعاملة، كما تم تحديد الترتيب بين الدُفعات المختلفة. ولذلك، فإن هذا النوع من مراجعة المعاملات بواسطة طبقة DA ليس له أي تأثير آخر باستثناء تأخير نهائية دفتر الأستاذ التراكمي.
خلاصة القول، أعتقد أن تركيز مقاومة الرقابة هو ضمان عدم قدرة أي كيان على التحكم أو التلاعب بتدفق المعلومات داخل النظام، في حين تتضمن الحيوية الحفاظ على وظائف النظام وتوافره، حتى في حالة وجود انقطاعات في الشبكة. والتصرفات المعاكسة. وعلى الرغم من أن هذا يتعارض مع التعريف الأكاديمي السائد الحالي، إلا أنني سأظل أستخدم تعريف المفهوم الذي ذكرته.
على الرغم من أن المجتمع يتمتع بفوائد المجمع المشترك، إلا أننا نريد تجنب الاعتماد عليه ونريد الرجوع إلى طبقة DA. سنقوم بدمج الطلب والسماح للمستخدمين بإرسال المعاملات مباشرة إلى طبقة DA. فهو يجمع بين التجميع القائم والمشترك.
نحن نفترض أنه سيتم تفسير الترتيب النهائي على أنه جميع المعاملات المطلوبة بواسطة المجمع المشترك ثم جميع المعاملات القائمة بعد ذلك لكل كتلة طبقة DA. نحن نسمي هذه القاعدة بقاعدة اختيار الشوكة المجمعة.
التجميع هو عملية من خطوتين هنا. أولاً، يتولى المجمع المشترك زمام المبادرة، حيث يقوم بتجميع بعض المعاملات. بعد ذلك، تقوم طبقة DA بتجميع الدُفعات والمعاملات المطلوبة بالفعل والتي أرسلها المستخدم مباشرة.
أصبح تحليل مقاومة الرقابة الآن أكثر تعقيدًا. قد تقوم عقدة شبكة DA-Layer بمراجعة الدفعة المرسلة بواسطة المجمع المشترك قبل إنتاج كتلة DA-Layer التالية. بعد معرفة بيانات المعاملة في الدفعة، يمكن لعقدة DA-Layer استخراج قيمة MEV، وبدء معاملة تشغيل أمامية بحسابها على شبكة التراكمي، وإدراجها في كتلة DA-Layer قبل تضمين الدُفعة المقدمة بواسطة التراكمي المجمع المشترك.
من الواضح أن نهائية أمر المعاملة التي يضمنها الالتزام الميسر للنوع الثالث من متغير القيمة المحتسبة أكثر هشاشة من النوع الثاني من متغير القيمة المحتسبة المذكور أعلاه. في هذه الحالة، يقوم المجمّع المشترك بتسليم قيمة MEV إلى عقدة DA-Layer. وفي هذا الصدد، أقترح على القراء مشاهدة المحاضرة حول الرقابة المربحة على MEV.
في الوقت الحاضر، ظهرت بعض حلول التصميم لتقليل قدرة عقد شبكة DA-Layer على تنفيذ مثل هذه المعاملات MEV، مثل وظيفة "فترة نافذة إعادة التنظيم"، والتي ستؤخر المعاملات المقدمة مباشرة من قبل مستخدمي شبكة Rollup إلى DA-Layer . قامت Sovereign Labs بتفصيل ذلك في مقترح التصميم الخاص بها المسمى Based Sequencing with Soft Confirmations، حيث تم اقتراح مفهوم "التسلسل المفضل".
نظرًا لأن MEV يعتمد على نظام التجميع الذي تختاره وقاعدة اختيار الشوكة الخاصة بالتجميع، فإن بعضها لن يتسرب شيئًا، والبعض الآخر سوف يسرب بعض أو كل MEV إلى طبقة DA، ولكن هذا موضوع ليوم آخر.
أما بالنسبة للحيوية، فإن هذا التصميم المتراكم له ميزة على مجرد وجود مجمع مشترك. إذا كان المجمع المشترك يعاني من فشل في النشاط، فلا يزال بإمكان المستخدم إرسال المعاملات إلى طبقة DA.
أخيرًا، دعنا نتحدث عن أصغر إعداد مخفض للثقة: العقدة الضوئية لطبقة DA + العقدة الضوئية المجمعة المشتركة + العقدة الكاملة المجمعة.
في هذا الوقت، ما زلنا بحاجة إلى التحقق من صحة رؤوس المجمع المشترك للعقدة الكاملة المجمعة لدينا حتى نتمكن من التمييز بين دفعات المعاملات لقاعدة اختيار التفرع الخاصة بها.
لنبدأ في طهي بعض العقد الخفيفة باستخدام متغير يسمى مجموعة التراكمية المتفائلة القائمة على منتج رأس مركزي. يستخدم هذا التصميم طبقة DA لتجميع المعاملات، لكننا نقدم منتج رأس مركزيًا لتمكين العقد الضوئية المجمعة.
يمكن للعقد الخفيفة التراكمية التحقق بشكل غير مباشر من صحة معاملات التراكمية من خلال جولة واحدة من إثبات الاحتيال. ستتخذ العقدة الخفيفة موقفًا متفائلاً تجاه منشئ رأس المجموعة، وستجري تأكيدًا نهائيًا بعد انتهاء فترة إثبات الاحتيال. الاحتمال الآخر هو أنه يتلقى دليل احتيال من عقدة كاملة صادقة، مع العلم أن منشئ الرأس قد أرسل بيانات غير صحيحة.
لن أخوض في التفاصيل حول كيفية عمل إثباتات الاحتيال ذات الجولة الواحدة، لأن هذا من شأنه أن يكسر نطاق هذه المقالة. الفائدة هنا هي أنه يمكنك تقليل فترة إثبات الاحتيال من 7 أيام إلى مبلغ معين، وهو مبلغ لم يتم تحديده بعد ولكن بمقادير أصغر. تستطيع العقد الخفيفة تلقي أدلة الاحتيال من خلال طبقة p2p دون الحاجة إلى انتظار النزاع، حيث يتم التقاط كل شيء في دليل واحد.
نحن نستخدم طبقة DA كمجمع يرث مقاومة الرقابة. يفعل التضمين والنظام. سيقرأ منتج الرأس المركزي الترتيب الأساسي من طبقة DA ويكون قادرًا على إنشاء رأس صالح من ذلك. سيقوم منتج الرأس المركزي بنشر الرأس وجذور الحالة إلى طبقة DA. تعتبر جذور الدولة هذه ضرورية لإنشاء دليل احتيال ضد هذا الالتزام. يقوم المجمع بالتضمين والطلب، بينما يقوم منتج الرأس بالتنفيذ.
من المفترض أن طبقة DA (التي تعمل أيضًا كمجمع تراكمي في هذا الوقت) لا مركزية بدرجة كافية وتتمتع بمقاومة جيدة للرقابة. بالإضافة إلى ذلك، لا يمكن لمنتج الرأس تغيير تسلسل المعاملات المجمعة المنشور بواسطة المجمع. الآن، إذا كان منتج الرأس لا مركزيًا، فإن الفائدة الوحيدة هي حيوية أفضل، لكن الخصائص الأخرى لمجموعة Rollup هي نفس المتغير الأول، Based Rollup.
إذا كان منتج الرأس يعاني من فشل في الحيوية، فإن المجموعة المجمعة تعاني أيضًا من فشل في الحيوية. لن تتمكن العقدة الخفيفة من متابعة السلسلة، بينما لا يزال بإمكان العقد الكاملة اتباع السلسلة إذا كان ذلك مرغوبًا، وتعود إلى مجموعة تراكمية متشائمة كما هو موضح في البديل 1. من الواضح،الحد الأدنى من التكوين لتقليل الثقة الموصوف في البديل 4 هو:
العقدة الضوئية لطبقة DA + العقدة الضوئية المجمعة.
لقد ناقشنا مجموعة القيمة المتشائمة (مجموعة القيمة المبنية على أساس) ومجموعة القيمة المتفائل، والآن حان الوقت للنظر في مجموعة ZK-Rollup. قدم طغرل مؤخرًا عرضًا تقديميًا حول الفصل بين المُجمِّع (Sequencer) ومنتج الرأس (Prover) (Sequencer-Prover Separation in Zero-Knowledge Rollups). في هذا النموذج، من الأسهل التعامل مع نشر المعاملات كبيانات مجمعة بدلاً من State Diff، لذلك سأركز على الأول. البديل 5 عبارة عن مجموعة ZK قائمة على سوق إثبات لا مركزي.
الآن، يجب أن تكون على دراية بما تفعله القيمة المحتسبة. يقوم البديل 5 بتفويض دور التجميع إلى عقد DA-Layer، التي تؤدي عمل التضمين والترتيب. وسوف أقتبس من مستند Sovereign-Labs الذي يقوم بعمل رائع في شرح دورة حياة تصميمها. سأقوم بتعديله قليلاً حتى يناسب الإصدار 5.
يقوم المستخدمون بنشر كتلة جديدة من البيانات على سلسلة L1. بمجرد الانتهاء من النقطة على L1، فهي نهائية منطقيًا. مباشرة بعد الانتهاء من كتلة L1، يتم فحص العقد الكاملة من مجموعة البيانات المجمعة من خلالها ومعالجة جميع نقاط البيانات ذات الصلة بالترتيب الذي تظهر به، مما يؤدي إلى إنشاء جذر حالة تجميعية جديد. عند هذه النقطة، يتم الانتهاء من الكتلة بشكل شخصي من منظور جميع العقد الكاملة.
منتجنا الرئيسي في هذا التصميم هو سوق المثل اللامركزي.
تؤدي عقد الإثبات (العقد الكاملة التي تعمل داخل ZKVM) نفس العملية تقريبًا مثل العقد الكاملة - المسح عبر كتلة DA ومعالجة جميع الدُفعات بالترتيب - إنتاج الأدلة ونشرها على السلسلة. (يجب نشر البراهين على السلسلة إذا كانت المجموعة المجمعة ترغب في تحفيز المُثبتين - وإلا فمن المستحيل معرفة المُثبِّت الذي كان أول من قام بمعالجة دفعة معينة). بمجرد نشر إثبات لدفعة معينة على السلسلة، تصبح الدُفعة نهائية بشكل شخصي لجميع العقد، بما في ذلك العقد الخفيفة.
(نظرًا لوجود العديد من المفاهيم المتضمنة، يمكنك إلقاء نظرة على الرسم التخطيطي مرة أخرى)
يتمتع الإصدار 5 بنفس مقاومة الرقابة التي تتمتع بها طبقة DA. لا يمكن لسوق الإثبات اللامركزي فرض رقابة على المعاملات لأن طبقة DA تحدد الترتيب القانوني. لقد قمنا بإضفاء اللامركزية على المنتج الرئيسي فقط من أجل تحسين الحيوية وإنشاء سوق للحوافز. الحيوية هنا هي L = L_da && L_pm (سوق المثل). إذا كانت حوافز سوق الإثبات غير متوازنة، أو كانت تعاني من فشل في الحيوية، فلن تتمكن العقد الخفيفة من متابعة السلسلة، ولكن لا يزال من الممكن أن تتبع العقد الكاملة المجمعة السلسلة إذا كان ذلك مرغوبًا، وتعود إلى تراكم متشائم قائم. يوجد هنا أصغر إعداد مخفض للثقة، تمامًا كما في الحالة المتفائلة التي تحتوي على عقدة ضوئية لطبقة DA + عقدة ضوئية تراكمية.
ما زلنا نسمح لعقد DA-Layer بالعمل كمجمعات للقيمة المجمعة، ونفوضها للتعامل مع تضمين المعاملات وفرزها.
كما ترون من الشكل أدناه، يستخدم كل من ZK Rollup وOptimistic Rollup نفس دفعات المعاملات المطلوبة على طبقة DA كمصدر لدفتر الأستاذ التراكمي. ولهذا السبب يمكننا استخدام نظامي إثبات في نفس الوقت: لا تتأثر دفعات المعاملات المطلوبة على طبقة DA بنظام الإثبات نفسه.
دعونا نتحدث عن النهاية. من منظور العقدة الكاملة المجمعة، يكون التجميع نهائيًا عندما تكون طبقة DA نهائية، حيث تحتاج فقط إلى تنفيذ المعاملات لهذا المتغير. لكننا نهتم أكثر بنهائية العقدة الضوئية. لنفترض أن منتج الرأس المركزي يضع بعض الحصص، ويوقع فوق الرأس، وينشر جذور الحالة المحسوبة إلى طبقة DA.
كما هو الحال مع الإصدار 4 السابق، ستثق العقد الخفيفة بشكل متفائل في التنفيذ وتنتظر دليل احتيال من عقدة كاملة صادقة تُظهر أن منتج الرأس ارتكب عملية احتيال. بعد انتهاء نافذة إثبات الاحتيال، تصبح كتلة القيمة المحتسبة نهائية من منظور عقدة ضوء القيمة المحتسبة.
النقطة الأساسية هي أنه إذا تمكنا من الحصول على دليل ZK، فلن نضطر بعد الآن إلى الانتظار حتى تنتهي نافذة إثبات الاحتيال. بالإضافة إلى إثباتات الاحتيال ذات الجولة الواحدة، يمكننا استبدال إثباتات الاحتيال بإثباتات ZK ورفض أي رأس ضار تم إنشاؤه من منتج الرأس المتفائل!
عندما تتلقى العقدة الخفيفة شهادة ZK المقابلة لمجموعة معاملات تراكمية معينة، سيتم الانتهاء من الدفعة.
الآن لدينا التزام ناعم سريع ونهائي سريع.
لا يزال الإصدار 6 يتمتع بنفس مقاومة الرقابة التي تتمتع بها طبقة DA كما هو قائم عليها. بالنسبة للحياة، سيكون لدينا L = L_da && (L_op || L_pm )، مما يعني أننا قمنا بزيادة ضمان الحياة لدينا. إذا كان المنتج الرئيسي المركزي أو السوق المثبت يعاني من فشل في الحيوية، فيمكننا الرجوع إلى المخطط الآخر.
أصغر إعداد مخفض للثقة هو العقدة الضوئية لطبقة DA + العقدة الضوئية المجمعة.
ملخص:
قمنا بتقسيم جهاز التسلسل إلى كيانين منطقيين: المُجمِّع ومنتج الرأس
قمنا بتقسيم جهاز التسلسل إلى ثلاث عمليات منطقية: التضمين والترتيب والتنفيذ.
تعد المجموعات المتشائمة والمجموعات المستندة إلى شيء ما
اعتمادًا على احتياجاتك، يمكنك توصيل وتشغيل أدوات التجميع ومنتجي الرؤوس.
يتبع كل متغير مجموعة محتسبة في هذه المقالة نمط التصميم هذا:
وأخيرا، لدي بعض الأفكار. يرجى التفكير في:
ملاحظة: لغرض تسهيل فهم وتحليل نموذج التراكمي، قام باحث Celestia NashQ بتقسيم مُسلسِل التراكمي إلى كيانين منطقيين - المُجمِّع ومنتج الرأس. وفي الوقت نفسه، قام بتقسيم عملية طلب المعاملات إلى ثلاث خطوات منطقية: التضمين والطلب والتنفيذ.
وبالاسترشاد بهذا التفكير التحليلي، أصبحت المتغيرات الستة الرئيسية لمجموعة السيادة أكثر وضوحًا وأسهل للفهم. ناقشت NashQ بالتفصيل مقاومة الرقابة وحيوية متغيرات مجموعة التحديثات المختلفة، بالإضافة إلى الحد الأدنى من التكوين لكل عقدة متغيرة لمجموعة التحديثات في حالة تقليل الثقة (على سبيل المثال، لتحقيق حالة عدم الثقة، على الأقل ما هي أنواع العقد التي يحتاج مستخدمو مجموعة التحديثات إلى يجري).
على الرغم من أن هذا المقال يحلل Rollup من منظور Celestia، والذي يختلف عن الطريقة التي يحلل بها مجتمع Ethereum نموذج Rollup، مع الأخذ في الاعتبار الترابطات العديدة بين Ethereum Rollup وCelestia Sovereign Rollup، فضلاً عن التأثير المتزايد للأخير، فإن هذه المقالة أيضًا متطرفة للغاية يستحق القراءة لعشاق الايثيريوم.
المجموعات المجمعة هي مجموعات بلوكتشين تقوم بنشر بيانات المعاملات الخاصة بها إلى بلوكتشين أخرى وترث إجماعها وتوافر البيانات.
لماذا أقوم بتغيير "الحظر" إلى "بيانات المعاملة" هنا؟ اسمح لي أن أخبرك بالفرق بين كتلة القيمة المحتسبة وبيانات القيمة المحتسبة وأوضح لك أن الحد الأدنى من القيمة المحتسبة يحتاج فقط إلى بيانات القيمة المحتسبة مع متغيرنا الأول.
الكتلة المجمعة هي بنية بيانات تمثل blockchain على ارتفاع معين. وهو يتألف من البيانات المجمعة ورأس التراكمي. وتكون البيانات المجمعة إما مجموعة من المعاملات أو فرق الحالة بين دفعات المعاملات.
إن أبسط طريقة لإنشاء مجموعة بيانات تبدأ من خلال قيام المستخدم بنشر المعاملات على blockchain آخر. سوف نطلق على blockchain طبقة الإجماع وتوافر البيانات، لكنني سأختصرها إلى DA-Layer في جميع الرسوم البيانية التالية. (ملاحظة: يشبه Layer1 الذي يُشار إليه غالبًا في مجتمع Ethereum).
في المتغير الأول الخاص بنا، يجب على كل عقدة تراكمية إعادة تشغيل جميع المعاملات على blockchain للتحقق من أحدث حالة. لقد أنشأنا للتو مجموعة متشائمة!
مجموعة التحديثات المتشائمة هي مجموعة تراكمية تدعم فقط العقد الكاملة التي تعيد تشغيل جميع المعاملات في المجموعة المجمعة للتحقق من صحتها.
لكن في هذه الحالة من هو المُسلسل في هذه الحالة؟ لا يقوم أي كيان فعليًا بتنفيذ المعاملات باستثناء العقد الكاملة المجمعة نفسها. عادة، يقوم جهاز التسلسل بتجميع المعاملات وإنتاج رأس تراكمي، ولكن لا يوجد رأس في هذه الحالة!
لتسهيل المناقشة، قمنا بتقسيم جهاز التسلسل إلى كيانين منطقيين: المُجمِّع ومنتج الرأس الذي يميزه. يجب أن يكون أحد الكيانات على علم بالحالة (على سبيل المثال، يجب تنفيذ الحالة لحساب الرأس)، ولكن لا يحتاج المجمع إلى فهم الحالة حتى يتمكن من تجميعها.
التسلسل هو عملية التجميع وإنتاج الرأس.
التجميع هو عملية تجميع المعاملات في دفعة واحدة. تتكون مجموعة المعاملات من معاملة واحدة أو أكثر. (ملاحظة: الدُفعة هي جزء من البيانات الموجودة في الكتلة المجمعة باستثناء الرأس).
إنتاج الرأس هو عملية إنشاء رأس القيمة المحتسبة.
الرأس المجمع عبارة عن بيانات وصفية حول الكتلة، والتي تتضمن على الأقل التزامًا بالمعاملات في تلك الكتلة. (ملاحظة: الالتزام هنا يشير إلى الالتزام بصحة نتائج معالجة المعاملة).
من خلال المنظور أعلاه، يمكننا أن نرى من يلعب دور كل مكون من مكونات مجموعة التحديثات. دعونا نلقي نظرة أولا على الجزء المجمع. لا تحتوي المجموعة المتشائمة المذكورة سابقًا على عملية إنتاج رأس، ويقوم المستخدمون بنشر المعاملات مباشرة إلى طبقة DA، مما يعني أن شبكة طبقة DA تعمل بشكل أساسي كمجمع.
التراكمي المتشائم هو أحد أشكال التراكمي الذي يقوم بتفويض خطوة التجميع إلى طبقة DA. ليس لديها جهاز تسلسل. يُطلق على هذا النوع من التجميع أحيانًا اسم "التراكمي المستند إلى".
يتمتع التراكمي المستند إلى نفس مقاومة الرقابة والحيوية التي تتمتع بها طبقة DA (يقيس النشاط سرعة استجابة النظام لطلبات المستخدم). إذا أراد مستخدمو هذا النوع من مجموعة التحديثات تحقيق حالة من الحد الأدنى من الثقة (الأقرب إلى عدم الثقة)، فيجب عليهم تشغيل عقدة خفيفة لطبقة DA وعقدة تراكمية كاملة على الأقل.
دعونا نناقش التجميع المتشائم باستخدام المجمعات المشتركة. تم اقتراح هذه الفكرة من قبل إيفان فوربس في منشوره في المنتدى حول تصميم جهاز التسلسل المشترك. هذاالافتراض الأساسي هو أن جهاز التسلسل المشترك هو الطريقة الرسمية الوحيدة لتسلسل المعاملات. يشرح إيفان فوائد أجهزة التسلسل المشتركة مثل هذا:
"لفتح تجربة مستخدم مكافئة لـ web2، يمكن لأجهزة التسلسل المشتركة [...] توفير التزامات ناعمة سريعة (ملاحظة: ليس ضمانًا موثوقًا للغاية). توفر هذه الالتزامات الناعمة بعض الوعد التعسفي بالترتيب النهائي للمعاملات (أي أنها تعد بعدم تغيير أمر المعاملة)، ويمكن استخدامها لإنشاء إصدارات محدثة قبل الأوان من الحالة (ولكن لم يتم الانتهاء من الانتهاء بعد في هذا الوقت).
بمجرد تأكيد نشر بيانات الكتلة على الطبقة الأساسية (يشير s/b إلى DAlayer)، يمكن اعتبار الحالة نهائية."
نظرًا لأننا لا نزال مجموعة تراكمية متشائمة، فلدينا فقط عقد تراكمية كاملة ولا توجد عقد خفيفة. يجب على كل عقدة تنفيذ جميع المعاملات لضمان الصلاحية. لا توجد عقد ضوئية في هذا النظام، لذا ليست هناك حاجة لرأس تراكمي، المعروف أيضًا باسم منتج الرأس. (ملاحظة: بشكل عام، لا تحتاج العقدة الخفيفة في blockchain إلى مزامنة الكتل الكاملة، ولكنها تتلقى فقط رؤوس الكتلة)
نظرًا لعدم وجود خطوة إنتاج رأس تراكمي، لا يحتاج جهاز التسلسل المشترك التراكمي المذكور أعلاه إلى تنفيذ معاملات لتحديثات الحالة (شرط أساسي لإنتاج الرأس)، ولكنه يتضمن فقط عملية تجميع بيانات المعاملة. لذلك أفضّل أن أسميه مجمعًا مشتركًا.
في هذا المتغير، يحتاج مستخدمو مجموعة التحديثات إلى تشغيل ما يلي على الأقل في حالة تقليل الثقة:
العقدة الضوئية لطبقة DA + العقدة الخفيفة لشبكة التجميع المشتركة + العقدة الكاملة المجمعة.
في هذا الوقت، من الضروري التحقق من رأس المجمع المنشور (لا يشير إلى رأس التجميع) من خلال العقدة الضوئية لشبكة المجمع المشتركة. كما ذكر أعلاه، يتولى المجمع المشترك مهمة فرز المعاملات. في رأس المجمع المنشور، يحتوي على التزام تشفير، يتوافق مع الدفعة التي نشرها على طبقة DA.
بهذه الطريقة، يمكن لمشغل عقدة التراكمي التأكد من أن الدفعة المستلمة من طبقة DA تم إنشاؤها بواسطة المجمع المشترك، وليس بواسطة الآخرين.
(نظرًا لأن المحتوى الوارد أعلاه غامض نسبيًا، يمكنك قراءة الرسم التخطيطي مرة أخرى)
التضمين هو العملية التي يتم من خلالها قبول المعاملة في blockchain.
الطلب هو عملية ترتيب المعاملات في تسلسل محدد في blockchain.
التنفيذ هو العملية التي تتم من خلالها معالجة المعاملات في blockchain، ويتم تطبيق آثارها على حالة blockchain.
ولأن المجمع المشترك يتحكم في التضمين والنظام، فإننا نرث مقاومته للرقابة.
إذا افترضنا أن L_ss هي حيوية المجمع المشترك، وL_da هي حيوية طبقة DA، فإن حيوية هذا المخطط هي L = L_da && L_ss. بمعنى آخر، إذا كان أي من النظامين يعاني من فشل في الحيوية، فإن التجميع أيضًا يعاني من فشل في الحيوية.
من أجل البساطة، سأستخدم الحيوية باعتبارها منطقية. إذا فشل المجمع المشترك، فلن نتمكن من متابعة عملية التجميع. إذا فشلت طبقة DA، فيمكننا الاستمرار في الالتزامات الناعمة للمجمع المشترك. ومع ذلك، سنعتمد على إجماع المُجمِّع المشترك وتوافر البيانات، وهو ما سيكون أسوأ من طبقة DA الأصلية.
دعنا نستمر في استكشاف مقاومة الرقابة لحل التجميع أعلاه:
في هذا المخطط، لا تستطيع طبقة DA فرض رقابة على معاملات محددة. (ملاحظة: قد ترفض مراجعة المعاملات في كثير من الأحيان السماح بتحميل معاملات معينة إلى السلسلة). يمكنه فقط مراقبة دفعات التجميع الكاملة التي قام المجمع المشترك بتجميعها بالفعل. (رفض دفعة ليتم تضمينها في طبقة DA).
ومع ذلك، وفقًا لسير عمل التراكمي، عندما يرسل مجمع المشاركة دفعة المعاملة إلى طبقة DA، فقد أكمل بالفعل تسلسل المعاملة، كما تم تحديد الترتيب بين الدُفعات المختلفة. ولذلك، فإن هذا النوع من مراجعة المعاملات بواسطة طبقة DA ليس له أي تأثير آخر باستثناء تأخير نهائية دفتر الأستاذ التراكمي.
خلاصة القول، أعتقد أن تركيز مقاومة الرقابة هو ضمان عدم قدرة أي كيان على التحكم أو التلاعب بتدفق المعلومات داخل النظام، في حين تتضمن الحيوية الحفاظ على وظائف النظام وتوافره، حتى في حالة وجود انقطاعات في الشبكة. والتصرفات المعاكسة. وعلى الرغم من أن هذا يتعارض مع التعريف الأكاديمي السائد الحالي، إلا أنني سأظل أستخدم تعريف المفهوم الذي ذكرته.
على الرغم من أن المجتمع يتمتع بفوائد المجمع المشترك، إلا أننا نريد تجنب الاعتماد عليه ونريد الرجوع إلى طبقة DA. سنقوم بدمج الطلب والسماح للمستخدمين بإرسال المعاملات مباشرة إلى طبقة DA. فهو يجمع بين التجميع القائم والمشترك.
نحن نفترض أنه سيتم تفسير الترتيب النهائي على أنه جميع المعاملات المطلوبة بواسطة المجمع المشترك ثم جميع المعاملات القائمة بعد ذلك لكل كتلة طبقة DA. نحن نسمي هذه القاعدة بقاعدة اختيار الشوكة المجمعة.
التجميع هو عملية من خطوتين هنا. أولاً، يتولى المجمع المشترك زمام المبادرة، حيث يقوم بتجميع بعض المعاملات. بعد ذلك، تقوم طبقة DA بتجميع الدُفعات والمعاملات المطلوبة بالفعل والتي أرسلها المستخدم مباشرة.
أصبح تحليل مقاومة الرقابة الآن أكثر تعقيدًا. قد تقوم عقدة شبكة DA-Layer بمراجعة الدفعة المرسلة بواسطة المجمع المشترك قبل إنتاج كتلة DA-Layer التالية. بعد معرفة بيانات المعاملة في الدفعة، يمكن لعقدة DA-Layer استخراج قيمة MEV، وبدء معاملة تشغيل أمامية بحسابها على شبكة التراكمي، وإدراجها في كتلة DA-Layer قبل تضمين الدُفعة المقدمة بواسطة التراكمي المجمع المشترك.
من الواضح أن نهائية أمر المعاملة التي يضمنها الالتزام الميسر للنوع الثالث من متغير القيمة المحتسبة أكثر هشاشة من النوع الثاني من متغير القيمة المحتسبة المذكور أعلاه. في هذه الحالة، يقوم المجمّع المشترك بتسليم قيمة MEV إلى عقدة DA-Layer. وفي هذا الصدد، أقترح على القراء مشاهدة المحاضرة حول الرقابة المربحة على MEV.
في الوقت الحاضر، ظهرت بعض حلول التصميم لتقليل قدرة عقد شبكة DA-Layer على تنفيذ مثل هذه المعاملات MEV، مثل وظيفة "فترة نافذة إعادة التنظيم"، والتي ستؤخر المعاملات المقدمة مباشرة من قبل مستخدمي شبكة Rollup إلى DA-Layer . قامت Sovereign Labs بتفصيل ذلك في مقترح التصميم الخاص بها المسمى Based Sequencing with Soft Confirmations، حيث تم اقتراح مفهوم "التسلسل المفضل".
نظرًا لأن MEV يعتمد على نظام التجميع الذي تختاره وقاعدة اختيار الشوكة الخاصة بالتجميع، فإن بعضها لن يتسرب شيئًا، والبعض الآخر سوف يسرب بعض أو كل MEV إلى طبقة DA، ولكن هذا موضوع ليوم آخر.
أما بالنسبة للحيوية، فإن هذا التصميم المتراكم له ميزة على مجرد وجود مجمع مشترك. إذا كان المجمع المشترك يعاني من فشل في النشاط، فلا يزال بإمكان المستخدم إرسال المعاملات إلى طبقة DA.
أخيرًا، دعنا نتحدث عن أصغر إعداد مخفض للثقة: العقدة الضوئية لطبقة DA + العقدة الضوئية المجمعة المشتركة + العقدة الكاملة المجمعة.
في هذا الوقت، ما زلنا بحاجة إلى التحقق من صحة رؤوس المجمع المشترك للعقدة الكاملة المجمعة لدينا حتى نتمكن من التمييز بين دفعات المعاملات لقاعدة اختيار التفرع الخاصة بها.
لنبدأ في طهي بعض العقد الخفيفة باستخدام متغير يسمى مجموعة التراكمية المتفائلة القائمة على منتج رأس مركزي. يستخدم هذا التصميم طبقة DA لتجميع المعاملات، لكننا نقدم منتج رأس مركزيًا لتمكين العقد الضوئية المجمعة.
يمكن للعقد الخفيفة التراكمية التحقق بشكل غير مباشر من صحة معاملات التراكمية من خلال جولة واحدة من إثبات الاحتيال. ستتخذ العقدة الخفيفة موقفًا متفائلاً تجاه منشئ رأس المجموعة، وستجري تأكيدًا نهائيًا بعد انتهاء فترة إثبات الاحتيال. الاحتمال الآخر هو أنه يتلقى دليل احتيال من عقدة كاملة صادقة، مع العلم أن منشئ الرأس قد أرسل بيانات غير صحيحة.
لن أخوض في التفاصيل حول كيفية عمل إثباتات الاحتيال ذات الجولة الواحدة، لأن هذا من شأنه أن يكسر نطاق هذه المقالة. الفائدة هنا هي أنه يمكنك تقليل فترة إثبات الاحتيال من 7 أيام إلى مبلغ معين، وهو مبلغ لم يتم تحديده بعد ولكن بمقادير أصغر. تستطيع العقد الخفيفة تلقي أدلة الاحتيال من خلال طبقة p2p دون الحاجة إلى انتظار النزاع، حيث يتم التقاط كل شيء في دليل واحد.
نحن نستخدم طبقة DA كمجمع يرث مقاومة الرقابة. يفعل التضمين والنظام. سيقرأ منتج الرأس المركزي الترتيب الأساسي من طبقة DA ويكون قادرًا على إنشاء رأس صالح من ذلك. سيقوم منتج الرأس المركزي بنشر الرأس وجذور الحالة إلى طبقة DA. تعتبر جذور الدولة هذه ضرورية لإنشاء دليل احتيال ضد هذا الالتزام. يقوم المجمع بالتضمين والطلب، بينما يقوم منتج الرأس بالتنفيذ.
من المفترض أن طبقة DA (التي تعمل أيضًا كمجمع تراكمي في هذا الوقت) لا مركزية بدرجة كافية وتتمتع بمقاومة جيدة للرقابة. بالإضافة إلى ذلك، لا يمكن لمنتج الرأس تغيير تسلسل المعاملات المجمعة المنشور بواسطة المجمع. الآن، إذا كان منتج الرأس لا مركزيًا، فإن الفائدة الوحيدة هي حيوية أفضل، لكن الخصائص الأخرى لمجموعة Rollup هي نفس المتغير الأول، Based Rollup.
إذا كان منتج الرأس يعاني من فشل في الحيوية، فإن المجموعة المجمعة تعاني أيضًا من فشل في الحيوية. لن تتمكن العقدة الخفيفة من متابعة السلسلة، بينما لا يزال بإمكان العقد الكاملة اتباع السلسلة إذا كان ذلك مرغوبًا، وتعود إلى مجموعة تراكمية متشائمة كما هو موضح في البديل 1. من الواضح،الحد الأدنى من التكوين لتقليل الثقة الموصوف في البديل 4 هو:
العقدة الضوئية لطبقة DA + العقدة الضوئية المجمعة.
لقد ناقشنا مجموعة القيمة المتشائمة (مجموعة القيمة المبنية على أساس) ومجموعة القيمة المتفائل، والآن حان الوقت للنظر في مجموعة ZK-Rollup. قدم طغرل مؤخرًا عرضًا تقديميًا حول الفصل بين المُجمِّع (Sequencer) ومنتج الرأس (Prover) (Sequencer-Prover Separation in Zero-Knowledge Rollups). في هذا النموذج، من الأسهل التعامل مع نشر المعاملات كبيانات مجمعة بدلاً من State Diff، لذلك سأركز على الأول. البديل 5 عبارة عن مجموعة ZK قائمة على سوق إثبات لا مركزي.
الآن، يجب أن تكون على دراية بما تفعله القيمة المحتسبة. يقوم البديل 5 بتفويض دور التجميع إلى عقد DA-Layer، التي تؤدي عمل التضمين والترتيب. وسوف أقتبس من مستند Sovereign-Labs الذي يقوم بعمل رائع في شرح دورة حياة تصميمها. سأقوم بتعديله قليلاً حتى يناسب الإصدار 5.
يقوم المستخدمون بنشر كتلة جديدة من البيانات على سلسلة L1. بمجرد الانتهاء من النقطة على L1، فهي نهائية منطقيًا. مباشرة بعد الانتهاء من كتلة L1، يتم فحص العقد الكاملة من مجموعة البيانات المجمعة من خلالها ومعالجة جميع نقاط البيانات ذات الصلة بالترتيب الذي تظهر به، مما يؤدي إلى إنشاء جذر حالة تجميعية جديد. عند هذه النقطة، يتم الانتهاء من الكتلة بشكل شخصي من منظور جميع العقد الكاملة.
منتجنا الرئيسي في هذا التصميم هو سوق المثل اللامركزي.
تؤدي عقد الإثبات (العقد الكاملة التي تعمل داخل ZKVM) نفس العملية تقريبًا مثل العقد الكاملة - المسح عبر كتلة DA ومعالجة جميع الدُفعات بالترتيب - إنتاج الأدلة ونشرها على السلسلة. (يجب نشر البراهين على السلسلة إذا كانت المجموعة المجمعة ترغب في تحفيز المُثبتين - وإلا فمن المستحيل معرفة المُثبِّت الذي كان أول من قام بمعالجة دفعة معينة). بمجرد نشر إثبات لدفعة معينة على السلسلة، تصبح الدُفعة نهائية بشكل شخصي لجميع العقد، بما في ذلك العقد الخفيفة.
(نظرًا لوجود العديد من المفاهيم المتضمنة، يمكنك إلقاء نظرة على الرسم التخطيطي مرة أخرى)
يتمتع الإصدار 5 بنفس مقاومة الرقابة التي تتمتع بها طبقة DA. لا يمكن لسوق الإثبات اللامركزي فرض رقابة على المعاملات لأن طبقة DA تحدد الترتيب القانوني. لقد قمنا بإضفاء اللامركزية على المنتج الرئيسي فقط من أجل تحسين الحيوية وإنشاء سوق للحوافز. الحيوية هنا هي L = L_da && L_pm (سوق المثل). إذا كانت حوافز سوق الإثبات غير متوازنة، أو كانت تعاني من فشل في الحيوية، فلن تتمكن العقد الخفيفة من متابعة السلسلة، ولكن لا يزال من الممكن أن تتبع العقد الكاملة المجمعة السلسلة إذا كان ذلك مرغوبًا، وتعود إلى تراكم متشائم قائم. يوجد هنا أصغر إعداد مخفض للثقة، تمامًا كما في الحالة المتفائلة التي تحتوي على عقدة ضوئية لطبقة DA + عقدة ضوئية تراكمية.
ما زلنا نسمح لعقد DA-Layer بالعمل كمجمعات للقيمة المجمعة، ونفوضها للتعامل مع تضمين المعاملات وفرزها.
كما ترون من الشكل أدناه، يستخدم كل من ZK Rollup وOptimistic Rollup نفس دفعات المعاملات المطلوبة على طبقة DA كمصدر لدفتر الأستاذ التراكمي. ولهذا السبب يمكننا استخدام نظامي إثبات في نفس الوقت: لا تتأثر دفعات المعاملات المطلوبة على طبقة DA بنظام الإثبات نفسه.
دعونا نتحدث عن النهاية. من منظور العقدة الكاملة المجمعة، يكون التجميع نهائيًا عندما تكون طبقة DA نهائية، حيث تحتاج فقط إلى تنفيذ المعاملات لهذا المتغير. لكننا نهتم أكثر بنهائية العقدة الضوئية. لنفترض أن منتج الرأس المركزي يضع بعض الحصص، ويوقع فوق الرأس، وينشر جذور الحالة المحسوبة إلى طبقة DA.
كما هو الحال مع الإصدار 4 السابق، ستثق العقد الخفيفة بشكل متفائل في التنفيذ وتنتظر دليل احتيال من عقدة كاملة صادقة تُظهر أن منتج الرأس ارتكب عملية احتيال. بعد انتهاء نافذة إثبات الاحتيال، تصبح كتلة القيمة المحتسبة نهائية من منظور عقدة ضوء القيمة المحتسبة.
النقطة الأساسية هي أنه إذا تمكنا من الحصول على دليل ZK، فلن نضطر بعد الآن إلى الانتظار حتى تنتهي نافذة إثبات الاحتيال. بالإضافة إلى إثباتات الاحتيال ذات الجولة الواحدة، يمكننا استبدال إثباتات الاحتيال بإثباتات ZK ورفض أي رأس ضار تم إنشاؤه من منتج الرأس المتفائل!
عندما تتلقى العقدة الخفيفة شهادة ZK المقابلة لمجموعة معاملات تراكمية معينة، سيتم الانتهاء من الدفعة.
الآن لدينا التزام ناعم سريع ونهائي سريع.
لا يزال الإصدار 6 يتمتع بنفس مقاومة الرقابة التي تتمتع بها طبقة DA كما هو قائم عليها. بالنسبة للحياة، سيكون لدينا L = L_da && (L_op || L_pm )، مما يعني أننا قمنا بزيادة ضمان الحياة لدينا. إذا كان المنتج الرئيسي المركزي أو السوق المثبت يعاني من فشل في الحيوية، فيمكننا الرجوع إلى المخطط الآخر.
أصغر إعداد مخفض للثقة هو العقدة الضوئية لطبقة DA + العقدة الضوئية المجمعة.
ملخص:
قمنا بتقسيم جهاز التسلسل إلى كيانين منطقيين: المُجمِّع ومنتج الرأس
قمنا بتقسيم جهاز التسلسل إلى ثلاث عمليات منطقية: التضمين والترتيب والتنفيذ.
تعد المجموعات المتشائمة والمجموعات المستندة إلى شيء ما
اعتمادًا على احتياجاتك، يمكنك توصيل وتشغيل أدوات التجميع ومنتجي الرؤوس.
يتبع كل متغير مجموعة محتسبة في هذه المقالة نمط التصميم هذا:
وأخيرا، لدي بعض الأفكار. يرجى التفكير في: