20000 كلمة: النقاش الأمني حول التراكمات

هل ترث المجموعات الأمان؟

كتب في الأصل من قبل جون شاربونو

تم تجميعها في الأصل بواسطة فرانك ، فورسايت نيوز

مقدمة

شئنا أم أبينا ، ربما لن يتوقف Twitter أبدا عن الجدل حول ما إذا كان "L2" أو Rollup هو "وراثة الأمان".

في حين أن معظم المناقشات هي معارك دلالية لا يمكن تمييزها ، إذا تمكنت من تضييق نطاق الحجة ، فإن النقاط الأساسية تكون ذات قيمة لأنها تمس الأسئلة الأساسية حول متى وأين ولماذا يكون Rollup منطقيا.

هل يلغي L2 القابل للتطوير الحاجة إلى L1 في السوق؟ هل من الممكن تحويل L1 مثل Solana إلى L2؟

تتلخص هذه المناقشات بشكل أساسي في القضايا الأمنية. لسوء الحظ ، كان تعريف "الأمن" هنا دائما بعيد المنال. عادة ما نستخدم هذا المصطلح بشكل عرضي ، ومعظم الناس يعرفون تقريبا ما نتحدث عنه ، ولكن ليس تماما. سنقوم هنا بتفصيل الأمان بالتفصيل عبر البنى المختلفة.

تعريف الكلمة الطنانة

الالتفاف

لقد استخدمت سابقا التعريف التالي لمصطفى: "Rollup هو blockchain ينشر كتله إلى blockchain آخر ويرث الإجماع وتوافر البيانات (DA) لتلك blockchain".

فيما يلي تعريف أكثر عمومية قدمه جيمس بريستويتش: "Rollup هي طريقة للاشتراك في آلية إجماع أخرى من خلال تخصيص وظائف انتقال الحالة ، والحفاظ على حالة superset."

لا يتطلب أي منهما جسرا للتحقق ، كما أن القدرة على بناء جسور عبر السلسلة مع الحد الأدنى من افتراضات الثقة هي فائدة كبيرة ل Rollup ، ولكن تحليلها بشكل منفصل أمر بالغ الأهمية.

يمكننا النظر في معايير التجميع التالية:

• الإظهار هو نظام ذو حالة (مثل blockchain) مشتق من تشغيل وظيفة انتقال حالة مخصصة (STF) على إدخال البيانات على السلسلة الرئيسية (طبقة DA).
• يتم تأكيد جميع بيانات الإدخال (أي بيانات المعاملة الكاملة أو اختلافات الحالة) المستخدمة لاشتقاق حالة التأكيد النهائية للسلسلة البعيدة (أي Rollup) على السلسلة الرئيسية.
• نظرا لأن حالة الإظهار مشتقة من وظيفة انتقال الحالة (STF) التي تعمل على البيانات الموجودة على السلسلة الرئيسية ، فإن صلاحية الإظهار تعتمد على صلاحية السلسلة الرئيسية. يجب أن تتحقق عقدة Rollup بعد ذلك بشكل كامل من إجماع وصلاحية السلسلة الرئيسية (أو وضع افتراض أغلبية صادقة حول السلسلة الرئيسية) ؛

تحدد عقدة الإظهار حالة الإظهار على نتيجة إجماع السلسلة الرئيسية (مثل السلسلة الرئيسية التي تؤكد ترتيب كتل البيانات وتوفرها) من خلال تطبيق وظيفة انتقال الحالة الخاصة بها (STF).

جسر عبر السلسلة

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

بشكل أساسي ، يعمل الجسر عبر السلسلة ك "مراقب" لسلسلة blockchain أخرى (تماما مثل أي مستخدم بشري نموذجي آخر). ينفذ الجسر عبر السلسلة قاعدة تأكيد معينة يقتنع بها بحالة السلسلة المتصلة (على سبيل المثال ، عدد كتل Ethereum التي يجب أن تمر لقبول مدخلات النقل).

• عادة ما تقوم الجسور التقليدية عبر السلسلة بتشغيل العقد الضوئية للتحقق من صحة الإجماع على السلسلة لسلسلة المصدر (أي كل ما يثقون به في معظم علامات الإجماع) ؛
• يمكن أن توفر الجسور عبر السلسلة سمات أمان أقوى من خلال العمل كعقد ضوئية كاملة للتحقق (أي إضافة أخذ عينات توفر البيانات (DAS) + صلاحية / إثبات الفشل). على سبيل المثال ، قد يحتاج مدقق السلسلة إلى التشغيل على جميع عقد ضوء DAS التي تربط السلسلة ، وهو بديل خفيف الوزن أكثر من العقدة الكاملة التي تتطلب من المدقق تشغيل السلسلة المتصلة ؛
• يمكن أن يحتفظ جسر Rollup عبر السلسلة أيضا بنشاط ومقاومة السلسلة الرئيسية (لأن Rollup يجب أن يشارك إجماع السلسلة الرئيسية) ؛

التجسير من السلسلة الرئيسية → التراكمي

هذا الاتجاه بسيط للغاية ، حيث تتحقق عقدة Rollup بالكامل من السلسلة الرئيسية.

تعرف عقد Rollup كل ما يحدث على السلسلة الرئيسية ، لذا فهي تعرف متى تحدث معاملات عبر السلسلة ، ويجب أن تقوم عقدة Ethereum Rollup الكاملة الحالية أيضا بتشغيل العقدة الكاملة لطبقة Ethereum الأساسية نفسها.

لاحظ أن عقد Rollup يمكنها أيضا تشغيل عقدة ضوء مدقق كاملة لسلسلتها الرئيسية بدلا من ذلك ، إذا كانت مدعومة. دعنا نفكر في مثال افتراضي حيث نفذت Ethereum بالكامل الترقيات التالية:

• كتل تنفيذ Ethereum مع إثبات الصلاحية (بحث zkEVM في الطبقة الأساسية مستمر) ؛
• نفذت Ethereum DAS كاملة ، بحيث يمكن للعقد أخذ عينات من DA ؛
• تنشر طبقة تنفيذ Ethereum بياناتها كنقاط إلى طبقة البيانات ، تماما مثل أي مجموعة أخرى على Ethereum (على سبيل المثال ، سيتم نشر بيانات طبقة تنفيذ Celestia إلى طبقة DA الخاصة بها ، لذلك ستتحقق عقد DAS من توفر بيانات Rollup وطبقة التنفيذ الخاصة ب Celestia) ؛
• يوفر Ethereum دليلا كاملا على الإجماع بدلا من الاعتماد على لجان المزامنة (على سبيل المثال ، من خلال دمج المدققين ، وتجميع التوقيع بشكل أفضل ، وإثبات إجماع ZK المحتمل ، وما إلى ذلك) ؛

الآن ، بافتراض أنك تريد تشغيل عقدة كاملة لمجموعة تراكمية قائمة على Ethereum ، لمتابعة سلسلة تراكمية صالحة ، يجب أن تفهم سلسلة Ethereum الأساسية ، والتي تتطلب التحقق من إجماع وصلاحية Ethereum نفسها:

• إجماع Ethereum - يمكن لأي عميل عقدة خفيفة تتبع الإجماع الموقع على أنه blockchain ، رأس الكتلة ؛
• طبقة التنفيذ الخاصة ب Ethereum DA - عينة من العقد التراكمية لطبقة DA الخاصة ب Ethereum ، والتحقق من توفر بيانات Rollup وبيانات طبقة التنفيذ الخاصة ب Ethereum (لاحظ أن عقد DAS لا تزال تقدم بعض الافتراضات الإضافية حول العقد الكاملة ، كما سنرى لاحقا) ؛
• صلاحية حالة Ethereum الخاصة - مع zkEVM ، تأتي كل كتلة Ethereum مع دليل على الصلاحية ؛

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

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

جسر من السلسلة الرئيسية → Rollup

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

مرة أخرى ، هذا الجسر عبر السلسلة اختياري. تستخدم العقود الذكية على السلسلة الرئيسية لإقناع جميع عقد السلسلة الرئيسية بصحة Rollup ، مما يسمح بالاتصال ثنائي الاتجاه في ظل افتراضات ثقة جيدة.

التراكمات والمعالجات المشتركة والنوايا

كما تمت مناقشته ، توفر Rollups بعضا من حالتها الخاصة (حالة Rollup) بالإضافة إلى امتلاك حالة سلسلتها الرئيسية (مثل Ethereum). إذن ، هل لدى CoW Swap حالتها الخاصة التي ليست جزءا من حالة Ethereum؟ إذا كانت الإجابة بنعم ، فهذا يبدو وكأنه مجموعة تحديثات. إذا لم يكن كذلك ، فقد يكون "معالجا مشاركا".

ومع ذلك ، حتى هذا السؤال ليس بهذه البساطة كما يبدو:

بدلا من ذلك ، قد تعتقد أن العامل المميز هو استمرار الحالة:

إذا سمحت CoW Swap لمشاركين محددين بتزويد المستخدمين بتأكيدات مسبقة سريعة (أسرع من وقت حظر Ethereum) وتعد بأوامر تتضمن دفعات - نظرا لأن معالجة دفعات Ethereum تستغرق وقتا أطول مما يرغب معظم المستخدمين ، فهل هي الآن مجموعة تحديثات؟

تطرق كريس جويس إلى هذا الموضوع في حديثه في قمة النمطية ، بدءا من تعريف تقريبي للنوايا: "الالتزام بوظيفة تفضيل لمساحة حالة نظام معين".

لاحظ أوجه التشابه بين الدقة الجزئية (نية المطابقة) وفرز القيمة المحتصلة. يحصل المشغل على رسالة المستخدم الموقعة خارج السلسلة → ينشر البيانات الناتجة إلى السلسلة الرئيسية.

• التطبيقات القائمة على المقاصد - يتم حل تغييرات الحالة الناتجة على السلسلة (على سبيل المثال ، في مثال CoW Swap ، يكون التطبيق على السلسلة الأساسية ، لذلك يتم تبادل الرموز المميزة هناك) ؛
• تطبيق الإظهار - يستخدم البيانات المقدمة إلى السلسلة الرئيسية لحساب تغييرات الحالة الناتجة عن مجموعة التحديثات ؛

تحقق البنى المرتكزة على المقاصد والبنى المرتكزة على التجميع أهدافا مماثلة من اتجاهين متعاكسين. يعالج النهج المتمحور حول النية هذه المشكلة على نطاق واسع من منظور المستخدمين والتطبيقات ، ويعالج النهج المتمحور حول التراكمي هذه المشكلة على نطاق واسع من منظور سلاسل الكتل المختلفة.

هنا ، ليس من المهم وضع حدود مميزة محددة. علاوة على ذلك ، وجدنا أن Rollup لا يختلف كثيرا في الواقع عن التطبيقات التي اعتدنا عليها مع مطابقة النوايا خارج السلسلة!

أنت تعتمد على المشاركين خارج السلسلة (أجهزة التسلسل مقابل أدوات الحل / الحشو ، وما إلى ذلك) للحصول على بعض الضمانات الأضعف ، مثل توفير أفضل تنفيذ وتجربة مستخدم جيدة → تحديد النتيجة بناء على البيانات المنشورة في السلسلة الرئيسية. ومع ذلك ، فهم لا يحتفظون بأموالك في الحجز.

نظرا لأن الحساب خارج السلسلة الذي يمكن التحقق منه يصبح أكثر أهمية ، يمكن أن تصبح الخطوط الفاصلة بين الاثنين غير واضحة:

إذا كنت تريد أن يكون حل النية أو أمر الإظهار أقل ثقة ...

سلسلة كتل معيارية وبلوكشين متجانسة

غالبا ما يتم تعريف سلاسل الكتل المتجانسة (المعروفة أيضا باسم سلاسل الكتل المتكاملة) على أنها سلاسل تدمج عموديا جميع الوظائف الأساسية ، أي الإجماع و DA والتنفيذ. إنهم يتحملون المسؤولية الكاملة عن سلامتهم ، و Solana و Cosmos Hub هما مثالان رئيسيان.

غالبا ما يشار إلى طبقات DA (مثل Ethereum و Celestia) باسم سلاسل الكتل "المعيارية" لأنها تستعين بمصادر خارجية للتنفيذ إلى Rollup ، ولكن هذا ليس دقيقا تماما. كما أنهم مسؤولون بشكل مستقل عن إجماعهم وأجندة التنمية والإنفاذ.

حتى تنفيذ Celestia سيكون محدودا (على سبيل المثال ، التحويلات ، والتخزين ، والسلاسل المتقاطعة). وبالمثل ، إذا بدأ شخص ما في Rollup أعلى Solana ، فلن يصبح بطريقة سحرية blockchain "معيارية".

لذلك عندما تسمع الناس يشيرون إلى سلاسل مثل Ethereum أو Celestia على أنها سلاسل كتل "معيارية" ، أدرك أن هذا تمييز عملي أكثر من كونه تمييزا تقنيا بحتا. غالبا ما يقوم كلاهما بتحسين بنياتهما الخاصة لدعم مجموعة التحديثات. من المتوقع أن تتعامل هذه المجموعات مع معظم عمليات تنفيذ الصفقات ضمن نطاقها.

حتى Rollup ليس بالضرورة "معياريا" تماما - يمكن ل Rollup sequencer الاتفاق على تسلسل المعاملات ، وتوفير DA ، وتنفيذ المعاملات قبل أن تفعل السلسلة الرئيسية أي شيء. هذه هي الطريقة التي يتم بها تأكيد المستخدمين مسبقا. ثم توفر السلسلة الرئيسية التزاما "نهائيا" آخر ، تعلن مرة أخرى عن DA والإجماع على ترتيب معاملات Rollup.

الرول اب والسلاسل المتكاملة

لأغراضنا ، فإن التمييز الأكثر أهمية هو "التراكم" أو "عدم التراكم". هل تنشأ الحالة النهائية للسلسلة من البيانات المنشورة إلى سلسلة رئيسية منفصلة (أي طبقة DA)؟

بينما نربط اليوم DAS وصلاحية / إثبات الفشل مع عمليات التجميع التقليدية ، يجب أن نلاحظ أن هذه مفاهيم مختلفة منطقيا. من الناحية النظرية ، يمكن ترقية أي "سلسلة تكامل" (مثل سلسلة تطبيقات Cosmos النموذجية) لإضافة DAS وإثبات الصلاحية دون الحاجة إلى نشر بياناتها إلى سلاسل رئيسية خارجية أخرى مثل Ethereum. ستقوم العقدة بأخذ عينات من السلسلة والتحقق منها بشكل منفصل.

يتحدث فيتاليك عن هذا الاختلاف في نهاية اللعبة:

قد تلاحظ أن "blockchain الكبير التقليدي" (سلسلة التكامل) مع DAS + صلاحية / إثبات الفشل قد ينتهي به الأمر وكأنه "مجموعة تراكمية"! وبالمثل ، يمكن أن يصبح "التجميع القابل للتطوير والمهيمن" ناجحا لدرجة أنه يندمج ببساطة مع سلسلته الرئيسية لاستيعاب هذا التراكم.

تصبح حدود التمييز غير واضحة عند الحد الأقصى.

لذلك ، إذا كنت تعتقد أن فعالية DAS + / إثبات الفشل هي النتيجة النهائية ، فإن "التراكم" بمعنى ما أمر لا مفر منه. هناك فرق صحيح بين الطريقتين في الرسم البياني السابق:

• "Rollups" ويعرف أيضا باسم "النمطية" - بناء سلاسل مستقلة منطقيا ، ونشر البيانات إلى سلسلتها الرئيسية (طبقة DA) ، وإعادة استخدام إجماع السلسلة الرئيسية ؛
• "blockchain المتكاملة" ويعرف أيضا باسم "blockchain متجانسة" - دمج كل شيء في بروتوكول واحد بإجماع خاص به ، دون نشر البيانات في سلسلة رئيسية منفصلة (حتى لو كانت طبقة DA وطبقة التنفيذ أجزاء منفصلة منطقيا من البروتوكول المشترك بمعنى ما) ؛

عندما نتحدث عن "Rollup" في هذا التقرير ، فإننا نشير إلى الأول (أي ليس سلسلة تكامل مع DAS + صلاحية / إثبات الفشل ، والتي قد يشار إليها باسم Rollup المدمج).

في حين أن Rollup "التقليدية" لا تحتكر DAS أو البراهين (أي أن سلاسل الكتل الكبيرة المتكاملة يمكنها إضافتها) ، لاحظ أننا نتجاهل الكثير من التفاصيل الفنية هنا ، ولا يمكنك فقط اختيار Solana وتحديد "أوه ، أعتقد أننا سنضيف DAS اليوم".

يتطلب ذلك إعادة هيكلة أساسية للبروتوكول للبدء في الاقتراب مما نراه يفعله Ethereum و Celestia:

إن تغيير طريقة تشفير البيانات لدعم DAS سيعادل إبطاء تشفير الكتلة وانتشارها ، والبدء في الاقتراب من طبقة DA التقليدية:

لهذا السبب ، نرى الفريق يبني ما يلي:

• طبقات DA المتخصصة (مثل Ethereum's Danksharding ، Celestia ، إلخ) - كتل بطيئة + DAS ؛
• أجهزة التسلسل المشتركة (مثل Espresso أو Astria أو حتى Solana) - حقا مجرد طبقات DA سريعة ، لا تتطلب DAS ؛

ومع ذلك ، إذا قمت بفصل وقت القطع السريعة و DAS ، فإنهما ليسا متوافقين بالضرورة. على سبيل المثال ، يمكنك تخيل سلسلة مثل Solana تقدم مسارين مختلفين:

• مسار سريع - الاستمرار في تنفيذ المعاملات ونشر البيانات في أسرع وقت ممكن (كما هو اليوم) ؛
• مسار بطيء - تشفير البيانات بعد وقوعها بطريقة يمكن من خلالها أخذ العينات غير المتزامنة ، مما يوفر التأكيد على أن عقد DAS متأخرة قليلا عن توافق الآراء ؛

يناقش أناتولي في البودكاست كيف يجمع Eclipse Ethereum و Celestia و Solana معا ، ومن الطرف الآخر من الطيف ، يمكنك تخيل طبقة DA تضيف مسارا أسرع قبل إتاحة البيانات لأخذ العينات:

يؤدي توفير مسارين في نفس بروتوكول الطبقة الأساسية إلى استيعاب الفرز المشترك السريع بشكل فعال ، مما يوفر تصميما مثيرا للاهتمام يعتمد على Rollup. لاحظ أنه في الوقت الحالي لا تزال هذه فكرة استكشافية للغاية.

تأكيد القاعدة

مع هذه الخلفية ، يمكننا الآن البدء في تحليل سمات الأمان لهذه البنى المختلفة.

أولا ، تتفاعل العقد مع أي blockchain عن طريق تشغيل "قواعد التأكيد":

"تشير قواعد التأكيد إلى الخوارزمية التي يتم تشغيلها بواسطة عقدة لإخراج ما إذا تم تأكيد الكتلة أم لا. في هذه الحالة ، في ظل افتراضات معينة ، تنطوي بشكل أساسي على تزامن الشبكة والنسبة المئوية للأسهم الصادقة ، عند استيفاء هذه الشروط ، سيتم ضمان الكتلة أن إعادة التنظيم لن تحدث أبدا ".

يمكن أن يكون هناك أي عدد من قواعد التأكيد لسلسلة معينة:

• كم عدد الكتل التي تحتاج إلى انتظارها قبل تأكيد معاملة Bitcoin؟ 1 ？ 6 ？ 10 ？
• هل تستخدم LMD GHOST لتأكيد الكتل بناء على دفتر الأستاذ القابل للاستخدام في Ethereum ، أم تنتظر الأداة النهائية (Casper FFG) للتأكيد؟
• هل تقوم بتشغيل العقد الكاملة التي تتحقق مباشرة من كل كتلة ، أو العقد الخفيفة فقط التي تتحقق من توقيع الإجماع؟
• هل سألت للتو إنفورا؟

نظرا لأن كل قاعدة إقرار يمكن أن تضع افتراضات مختلفة تماما ، يمكن أن يكون لها خصائص أمان مختلفة جدا حتى عند التفاعل مع نفس السلسلة:

هذا التمييز دقيق ولكنه مهم:

الأمن = الأمن + النشاط

الآن دعنا نتعمق في ما إذا كانت مجموعة التحديثات "ترث الأمان" من سلسلتها الرئيسية.

الميراث ، وربما بشكل أكثر وضوحا ، Rollup دائما "يؤجر" بدلا من "يرث" أي شيء في سلسلته الرئيسية ، ويدفع تكلفة مستمرة للموارد المستهلكة (DA) ، ويمكن لأي من الطرفين اختيار إنهاء العلاقة. لكن هذا ليس الجزء المثير للاهتمام من المشكلة.

الأمن ، من الآن فصاعدا سنركز على الأمن. يتكون أمان الخوارزمية من السلامة والحيوية:

• الأمن (لن يحدث شيء سيء) ، فإن الحالة النهائية التي تحددها عقدتان صحيتان لن تتعارض أبدا ؛
• الحيوية (الأشياء الجيدة ستحدث في نهاية المطاف) ، ستكمل جميع العقد السليمة حالة جديدة تعكس المعاملات المضمنة في غضون فترة زمنية محدودة ؛

باستخدام إطار عمل Sreeram الممتاز ، يمكننا تقسيمها إلى خمس سمات تعمل معا لتأمين قواعد التأكيد:

دعنا نفكر في مثال لسلسلة تكامل افتراضية مع DAS + صلاحية / إثبات الفشل. لا يتم نشر بياناتها في أي سلسلة رئيسية خارجية أخرى. من أجل البساطة ، نفترض الانتهاء الفوري (مثل Tendermint) ، لذلك لا يوجد تمييز قابل للاستخدام بين دفتر الأستاذ المتاح ودفتر الأستاذ النهائي (مثل Ethereum's Gasper).

سننظر في ثلاث قواعد تأكيد يمكن استخدامها لتتبع السلسلة باستخدام أنواع مختلفة من العقد:

• عقدة ضوء مدقق الإجماع - يتحقق من إثبات الإجماع (أي يثق في إجماع الأغلبية الصادقة).
• عقدة ضوء المدقق الكامل - التحقق من الإجماع + التحقق من DA (باستخدام DAS) + التحقق من صلاحية الحالة (باستخدام الصلاحية / إثبات الفشل) ؛
• عقدة كاملة - إجماع التحقق + التحقق المباشر من DA (تنزيل جميع البيانات) والصلاحية (تنفيذ جميع المعاملات وحساب الحالة) ؛

تأكد من أن القاعدة لها سمات أمان ، السلسلة لا

مرة أخرى ، "نتحدث بالعامية أن السلسلة آمنة ، ولكنها في الواقع قاعدة تأكيد مرتبطة بسمة الأمان".

لنلق نظرة على بعض الأمثلة.

نظرية CAP

كخلفية ، تخبرنا نظرية CAP أنه لا يمكن لأي دفتر أستاذ تلبية هذين الشرطين في نفس الوقت:

التكيف (المعروف أيضا باسم التوافر الديناميكي) - البقاء نشطا مع المشاركة الديناميكية (أي إذا كانت معظم العقد غير متصلة بالإنترنت) ؛ النهاية (ويعرف أيضا باسم الاتساق) - الحفاظ على الأمان تحت أقسام الشبكة ؛

تميل بروتوكولات الإجماع إلى تقسيمها إلى قسمين ، كل منها يفي بأحد الشروط المذكورة أعلاه:

• أطول بروتوكولات السلسلة - تضمن هذه البروتوكولات (مثل إجماع ساتوشي في Bitcoin) النشاط حتى عندما يكون عدد العقد المشاركة النشطة متغيرا (أي أنها قابلة للتكيف) ، ومع ذلك فهي ليست آمنة (أي ليست نهائية) تحت تقسيم الشبكة ؛ بروتوكولات من نوع BFT - تحقق بروتوكولات توافق الآراء الكلاسيكية (مثل PBFT) النهائية ولكنها لا تحقق القدرة على التكيف ؛

قواعد تأكيد البيتكوين

إجماع البيتكوين لا يوفر أي نهاية اقتصادية صعبة.

تراقب العقد أطول سلسلة في طريقة العرض المحلية الخاصة بها ، ولكل مستخدم الحرية في تطبيق أي قاعدة تأكيد يريدها (على سبيل المثال ، قبول الكتل مع تأكيدات >k). المعيار هو الانتظار حتى يتم تأكيد 6 كتل ، لكن الأمر متروك لك.

بالنسبة للمعاملات ذات القيمة الأعلى ، من المعقول الانتظار لفترة أطول. وهناك مفاضلة بين وقت الانتظار والأمن، أي إمكانية إعادة التنظيم.

قواعد تأكيد الإيثريوم

يبدو للوهلة الأولى أن إجماع PoS الخاص ب Ethereum (Gasper) يتجنب نظرية CAP. ومع ذلك، فإنه ينفذ هاتين الخاصيتين لأنه يحتوي على اثنين من دفاتر الأستاذ المتداخلة:

• دفتر الأستاذ المتاح ديناميكيا - إذا لم يتم تقسيم الشبكة ، فهي آمنة ونشطة مع مشاركة ديناميكية ؛
• دفتر الأستاذ البادئة النهائي - دائما آمنة ومأمونة. إذا لم يتم تقسيم الشبكة وشاركت عقد كافية ، فإنها تظل نشطة ؛

ينتمي Gasper إلى عائلة بروتوكول "المد والجزر" (المعروف أيضا باسم دفتر الأستاذ المزدوج أو قاعدة التأكيد المزدوج). يقع تصميم دفتر الأستاذ المزدوج خارج نطاق نظرية CAP (أي أنه يفترض قاعدة تأكيد واحدة). عندما يتم تقسيم الشبكة ، يتخلف دفتر الأستاذ النهائي عن دفتر الأستاذ التكيفي ، لكنه يلحق بالركب عند إصلاح الشبكة.

ويتيح ذلك معالجة المفاضلة بين القدرة على التكيف والنهائية على مستوى المستعملين بدلا من المستوى على نطاق المنظومة. هذه سمة من سمات بروتوكول "أطول سلسلة من نقاط التفتيش" التي اقترحتها نظرية blockchain CAP من حيث القدرة على التكيف والنهائية التي يمكن للمستخدمين الاعتماد عليها. توفر هذه البروتوكولات للمستخدمين الفرديين خيارا بين النهاية والقدرة على التكيف ، بدلا من فرضها على مستوى النظام العام.

يكشف جاسبر صراحة عن قاعدتي تأكيد مختلفتين ، تم تعيينهما إلى دفتري الأستاذ المذكورين أعلاه:

• القواعد المتاحة ديناميكيا - القدرة على التكيف مضمونة. احترم رأس الكتلة لأطول سلسلة. LMD GHOST هي قاعدة اختيار شوكة تستخدم لتحديد أثقل شجرة فرعية.
• قواعد اللمسات الأخيرة - يضمن اليقين النهائي. احترم الكتل التي أكدتها الأدوات النهائية. Casper FFGs هي أدوات نهائية تنطبق على قواعد اختيار الشوكة ؛

وكما نوقش في الورقة:

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

هذا يسمح لجميع العقد (صادقة) في النظام:

• اتباع آلية اقتراح كتلة مشتركة ؛
• ومع ذلك ، يمكن للعقد المختلفة اختيار قواعد تأكيد مختلفة ؛

يستمر المدققون في إطالة أطول سلسلة (تعدين كتل جديدة على ارتفاعات متزايدة باستمرار) ، بغض النظر عن مستوى المشاركة ، ولكن فقط عندما تكون هناك مشاركة كافية ، ستظهر نقاط تفتيش جديدة.

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

يعتمد أمان المستخدمين على قواعد التأكيد التي يتبعونها. هناك مفاضلة بين الاعتراف السريع بالكتلة والضمانات الأمنية الأقوى. قد يفضل المستخدمون الذين يبيعون القهوة النشاط على الأمان ، لكن المستخدمين الذين يبيعون اليخوت قد يفضلون الأمان على النشاط.

يمكن لعقد Ethereum أيضا تطبيق بعض الاستدلال على قواعد التأكيد الوسيطة الأخرى لأغراض عملية. بدلا من استخدام كتل k الساذجة كقاعدة تأكيد تكيفية ، كما تفعل Bitcoin ، يمكننا إضافة استدلال آخر يتضمن افتراضات حول مزامنة الشبكة وصدق المدقق.

هذا هو بالضبط ما هو مقترح في قواعد تأكيد بروتوكول إجماع Ethereum ، والتي تقترح قواعد تأكيد بالخصائص التالية:

• في ظل الظروف المثالية - ستؤكد القاعدة كتلة جديدة فور فتحتها ؛
• في ظل ظروف الشبكة الرئيسية النموذجية - يجب أن تكون القاعدة قادرة على تأكيد معظم الكتل الجديدة في غضون دقيقة ؛

قاعدة التأكيد هذه ليست بديلا عن النهاية الاقتصادية. بدلا من ذلك ، فإنه يوفر استدلالا مفيدا للمستخدمين الذين يعتقدون أن مزامنة الشبكة ستبقى في المستقبل القريب. دعونا نقارن بين الاثنين:

دعنا نفكر في بعض الأمثلة ، مثل إذا كنت تبيع يختا مقابل 2.5 مليون دولار في ETH ، فإليك بعض قواعد التأكيد المحتملة:

• عقدة كاملة + في انتظار النتيجة النهائية - حتى الغالبية الخبيثة من المدققين لا يمكنهم خداعك لقبول كتل غير صالحة (مثل إنتاج ETH مزيف). إذا دفعوا لك 2.5 مليون دولار في ETH ثم حاولوا إعادة هيكلة الكتلة النهائية لاحقا ، فسوف يتحملون تكلفة ضخمة (يتم تخفيض ثلث حقوق الملكية على الأقل) ؛
• عقدة كاملة + انتظر كتلة - لا يزال معظم المدققين الضارين غير قادرين على خداعك لقبول كتلة غير صالحة ، ومع ذلك يمكنهم إرسال 2.5 مليون دولار في ETH في كتلة صالحة ، والمغادرة على متن يخت ، ثم يتم إعادة تنظيم الكتلة على الفور ، وهو أمر ممكن إذا كان هناك وزن حصة كاف أو ظروف شبكة سيئة ، لا يتم قطعها عقابيا ؛
• عميل العقدة الخفيفة - يمكن أن تكذب عليك لوحات المزامنة الضارة دون عقوبة ويمكن للمشترين المغادرة على متن يخت (لاحظ أن لجنة المزامنة هذه حصرية ل Ethereum كمجموعة فرعية من الإجماع ، ويمكن لسلاسل PoS الأخرى ذات دعم عميل العقدة الخفيفة الأكثر كفاءة التحقق من جميع أصوات الإجماع مع عدد صغير من المدققين) ؛
• MetaMask - أنت تثق فقط في Infura ، الشخص الذي اشترى اليخت منك وعد موظف Infura بأنه يمكنهم أخذ اليخت في عطلة نهاية الأسبوع ، لذلك كذبوا عليك ، واعتقدت أنك حصلت على 2.5 مليون دولار في ETH ، ثم سلمت المفاتيح ؛

التراكمي يؤكد القواعد

كما هو الحال مع أي سلسلة، تتفاعل العقد مع مجموعة التحديثات باستخدام قواعد إقرار مختلفة. سيتم الانتهاء من أقوى قواعد تأكيد Rollup جنبا إلى جنب مع إجماع سلسلتها الرئيسية. يمكن أن يكشف جهاز التسلسل التراكمي عن قواعد تأكيد أضعف للحصول على تجربة مستخدم أفضل (أي توفير تأكيد مسبق سريع للمستخدمين غير الصبورين) ، ولكن يمكن للمستخدمين أيضا انتظار الأمان الكامل لقواعد تأكيد السلسلة الرئيسية.

يبدو تدفق المعاملات التراكمية النموذجي كما يلي:

• يقدم المستخدم معاملة إلى جهاز التسلسل ؛
• يقوم جهاز التسلسل بفرز المعاملات ويعطي تأكيدا مسبقا ؛
• يجب تطبيق STF الحتمي على المعاملات المطلوبة لحساب حالة التجميع الجديدة ؛
• يتم أخيرا إصدار التزام حالة التجميع المحدث وبيانات المعاملات ذات الصلة إلى السلسلة الرئيسية ؛

بعد نشر بيانات المعاملة في السلسلة الرئيسية:

• العقدة الكاملة التراكمية - يتحقق مباشرة من صحة حالة السلسلة المقترحة ؛
• عقد ضوء التراكمي (بما في ذلك جسور التحقق) - لا يمكن التحقق منها مباشرة ؛
• يستخدم المراقبون المختلفون لنفس مجموعة التحديثات قواعد تأكيد مختلفة ، لذلك يضعون اللمسات الأخيرة على وجهة نظرهم في أوقات مختلفة:
• افترض الإفراج عن بيانات المعاملات الكاملة (وليس فقط اختلافات الدولة) ؛
• كما ذكرنا سابقا ، يجب أن تقوم عقد Rollup أيضا بتشغيل العقد الكاملة للسلسلة الرئيسية أو العقد الخفيفة الكاملة للمدقق (أو استخدام العقد الخفيفة لمدقق الإجماع لوضع افتراضات أغلبية صادقة). يمكن تشغيل عقد ضوء الإظهار كبرنامج إضافي أو ضمنيا داخل عقدة السلسلة الرئيسية (أي مجموعة التحقق من عقد الجسر عبر السلسلة على السلسلة الرئيسية) ؛

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

لذلك ، حتى الطلبات المركزية لا تقلل حقا من أمان "مجموعة التحديثات". تحصل دائما على الأمان الذي يتوافق مع قواعد التأكيد التي تحتاجها. سواء كان Rollup يحتوي على تصميم قائم على جهاز التسلسل أو تصميم آخر ، يمكنك استخدام نفس قواعد التأكيد (على سبيل المثال ، انتظر حتى يتم الانتهاء من السلسلة الرئيسية وتحقق من صلاحية Rollup). بافتراض التنفيذ السليم (على سبيل المثال ، فرض تضمين المعاملات عبر السلسلة الرئيسية) ، يمكنك الحصول على نفس سمات الأمان في نفس الإطار الزمني مع الحفاظ على الشروط الأخرى كما هي.

وبالمثل ، يمكنك أن تتخيل أن منتجي كتلة Ethereum L1 يقدمون تأكيدا مسبقا بسبب أوقات الحظر البطيئة ، مما لا يجعل "Ethereum" أقل أمانا. تحتاج فقط إلى تحديد ما إذا كنت تريد استخدام قاعدة تأكيد أخرى (أقل أمانا) حتى يقوم مدقق Ethereum بوضع اللمسات الأخيرة على الأمان الأعلى.

تتناسب فكرة التأكيد المسبق بشكل جيد مع منطق جاسبر الذي وصفه فيتاليك:

المبدأ العام هو أنك تريد توفير "أكبر قدر ممكن من الإجماع" للمستخدم: إذا كان هناك > 2/3 ، فإننا نتوصل إلى توافق في الآراء على أساس منتظم ، ولكن إذا كان هناك < 2/3 ، فلا يوجد سبب للتأخير دون تقديم أي شيء ، لأنه من الواضح أن السلسلة ستستمر في النمو على الرغم من انخفاض مستوى الأمان مؤقتا للكتلة الجديدة. إذا كان تطبيق واحد غير راض عن مستوى أمان أقل ، فلا تتردد في تجاهل هذه الأجزاء حتى يتم الانتهاء منها.

بوضع كل هذا معا ، عندما تتفق جميع قواعد التأكيد على نفس حالة دفتر الأستاذ في نفس الوقت ، يكون لدينا "منطقة اتساق":

تأكيد القاعدة والأمان وإمكانية الوصول

إذا كانت قاعدة التأكيد الخاصة بك هي الوثوق بجهاز تسلسل واحد يديره SBF ، بدلا من جهاز تسلسل لامركزي يتكون من أكثر المدققين شهرة في العالم ، فقد يكون أمانك أسوأ ، والفشل النشط وإعادة التنظيم هما إخفاقات أمنية.

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

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

مرة أخرى ، هذا يلامس النقد الحقيقي لسلاسل الكتل عالية الإنتاجية مثل Solana. ما هي قواعد التأكيد التي يمكن للأشخاص استخدامها بالفعل؟ قد يكون لديك ظروف أمان جيدة لتشغيل عقد Solana الكاملة ، ولكن قد لا يتمكن معظم الأشخاص من الوصول إلى قاعدة التأكيد هذه (أي اعتمادا على متطلبات الموارد و / أو التكلفة).

التحقق المباشر (أي عدم الثقة فقط في الأغلبية النزيهة) هو سمة أساسية لهذه الأنظمة. لذلك ، بالنسبة لقاعدة تأكيد معينة ، نحن نهتم حقا بجانبين - الأمان وإمكانية الوصول:

باختصار :

• يتفاعل المستخدمون مع أي سلسلة من خلال قواعد التأكيد ؛
• يمكن أن تحتوي السلسلة على أي عدد من قواعد التأكيد ؛
• الأمن هو سمة من سمات قاعدة التأكيد ، وليس السلسلة نفسها ؛
• نحن نهتم بأمن وإمكانية الوصول إلى قواعد التأكيد لسلسلة معينة ؛

في الواقع ، عندما نقول أن سلسلة معينة آمنة ، فإننا نحاول التعبير عن فكرة أن قواعد التأكيد المرتبطة بها آمنة ويمكن الوصول إليها.

التراكمات مع أمان سلسلة التكامل

1 ، سلسلة التكامل مع إثبات صحة DAS +

نحن نرى الآن أنه يمكن التحقق من الأمان فيما يتعلق ب DA وصلاحية الحالة مباشرة عن طريق التشفير (DAS + الصلاحية / إثبات الفشل) دون وضع افتراضات قوية حول مشغلي السلسلة. يمكن لأي بروتوكول تنفيذ هذه تقنيا. يمكن للعقد الكاملة أيضا التحقق من DA وصلاحية الحالة دون افتراضات خارجية.

الآن دعونا نركز على خصائص أخرى - النشاط ومقاومة إعادة التركيب. كما رأينا سابقا ، يمكن أن تفشل هذه بغض النظر عن نوع قاعدة التأكيد التي تقوم بتشغيلها. لنلق نظرة على سلسلة تكامل أخرى تثبت نهائية فعالية DAS + لمقبس + PoS الأحادي:

يعد اختيار قواعد إقرار قوية فعالا بشكل خاص لمجموعة فرعية من حالات فشل الأمان ، حيث لا يمكن حتى لمعظم المدققين الضارين خداع العقد الكاملة أو العقد الضوئية للمدقق الكامل للاعتقاد بما يلي:

• البيانات غير المتاحة متاحة بالفعل؛
• أو انتقالات الحالة غير الصالحة صالحة ؛

سواء كان لدى Ethereum مدقق 1 أو عدد لا يحصى من المدققين ، فإن جميع العقد تؤمن بشكل أو بآخر ب DA أو صلاحية الكتلة ، والتي يتم ضمانها عن طريق التحقق. يمكن التحقق من العقد الضوئية الكاملة للمدقق بطريقة أبسط (ولكن لاحظ أن DAS تضع بعض الافتراضات الأخرى ، والتي سنناقشها لاحقا).

ومع ذلك ، قد تمنع الغالبية الضارة من المدققين دفتر الأستاذ من النمو أو فرض رقابة عليك أو إعادة تنظيم السلسلة (تعتمد حالات الفشل التي تحدث على قواعد التأكيد). DAS + ZK لن ينقذك. وتتوقف مقاومة إعادة التنظيم والنشاط دائما إلى حد ما على مختلف السمات الأساسية لسلسلة معينة (مثل المشغلين الموثوق بهم، والحوافز الاقتصادية، وتوافق الآراء الاجتماعي، وما إلى ذلك).

ومن غير الواضح أن النشاط ومقاومة إعادة التنظيم لا يزالان من سمات قاعدة معينة من قواعد الاعتراف، لأن كل عقدة تخضع لنفس الهجوم الوارد في الجدول أعلاه. بغض النظر عن قواعد التأكيد هنا ، لديهم نفس الضمان.

ومع ذلك، يصبح هذا واضحا مرة أخرى عند إزالة افتراض نهائية الفتحة الواحدة. في Ethereum's Gasper ، اعتمادا على دفتر الأستاذ الذي تتبعه (أي أطول دفتر أستاذ سلسلة أو نقطة تفتيش متاحة) ، سيكون لديك مرة أخرى نشاط مختلف وخصائص مقاومة لإعادة التنظيم. تتسبب معظم أدوات التحقق الضارة في حدوث أعطال أمنية مختلفة اعتمادا على قواعد التأكيد التي تقوم بتشغيلها.

على أي حال ، فإن النقطة المهمة هي أن البناء الأساسي للسلسلة مهم جدا هنا. أنت بحاجة إلى مشغلين أقوياء وحوافز اقتصادية وإجماع اجتماعي للحفاظ على السلسلة نشطة ومقاومة لإعادة الهيكلة. بالإضافة إلى ذلك ، توفر بروتوكولات إجماع دفتر الأستاذ المزدوج مثل Ethereum للمستخدمين مرونة قيمة لحساب التوافر والنهائية وفقا لاحتياجاتهم.

2 ، إثبات الإظهار باستخدام صلاحية DAS +

الآن دعنا نعدل هذا المثال قليلا:

• المثال السابق - سلسلة تكامل مع إثبات صحة DAS + ، تخيل أخذ Solana اليوم ، ولكن إضافة دليل على DAS + ؛
• مثال جديد - يتم نشر Rollup على سلسلة رئيسية خارجية (مثل Ethereum) مع إثبات الصلاحية + DAS (لاحظ أن Ethereum DAS لم يتم تشغيله بعد) ، يحتوي Rollup على مجموعة تسلسل لامركزية يمكنها الوصول إلى توافق في الآراء مع تأكيد مسبق سريع ؛

ستلاحظ أن Rollup يحتوي على نوعين منفصلين تماما من قواعد التأكيد لأطر زمنية مختلفة (على سبيل المثال ، ما إذا كنت تعمل بناء على الإجماع المسبق لجهاز التسلسل أو تنتظر الإجماع النهائي للسلسلة الرئيسية) ، دعنا الآن نلقي نظرة على كل مسار.

المسار السريع - قبل إجماع السلسلة الرئيسية

يمكن أن تعتمد عقد الإظهار على تأكيد من جهاز التسلسل (قبل النشر إلى السلسلة الرئيسية) ، ونفترض أنه يمكنهم تشغيل عقد Rollup التالية:

• عقدة ضوء مدقق إجماع التراكمي - ثق بالأغلبية الصادقة في إجماع تسلسل التراكمي ؛
• التراكمي كامل المدقق ضوء عقدة - تشغيل DAS + على تغذية التسلسل للتحقق من إثبات الصلاحية قبل نشر أي شيء إلى Ethereum ؛
• العقدة الكاملة التراكمية - قم بتنزيل جميع البيانات من موجز التسلسل وتنفيذ جميع المعاملات للتحقق مباشرة من DA وصلاحيتها ؛

من الناحية الفنية ، يمكن لجهاز تسلسل Rollup تسهيل DAS وتقديم دليل على الصلاحية قبل النشر على السلسلة الرئيسية ، لكن هذا لا يحدث بالفعل. عادة ما يتم تصميم العقد الضوئية الكاملة للتحقق من ذلك من خلال السلسلة الرئيسية ، لكنني أفترض أنه يمكن مقارنة براهين DAS + "الحية" بشكل أكثر وضوحا بنفس السلسلة المتكاملة.

يوضح الجدول التالي التغييرات مقارنة بمثال سلسلة التكامل:

• الاعتماد على جهاز التسلسل التراكمي للنشاط ومكافحة إعادة التركيب ، بدلا من مجموعة المدقق للسلسلة المتكاملة ؛
• تمت إزالة سمة النشاط النهائي فقط ، لأنه يتم عرض النطاق الزمني فقط قبل إجماع السلسلة الرئيسية هنا (ستكون سمات النشاط "النهائية" هذه مملوكة ذاتيا لاحقا في المستقبل) ؛

تظهر عمليات الحذف يتوسطها خط أحمر وتظهر الإضافات باللون الأزرق:

مسار بطيء - انتظر إجماع السلسلة الرئيسية

لمزيد من الأمان ، يمكن للعقد انتظار إجماع من السلسلة الرئيسية (مثل Ethereum) ، حيث يتم تشغيلها بشكل أكثر وضوحا ، أي يجب أن تقوم عقد Rollup أيضا بتشغيل عقدة السلسلة الرئيسية:

• عقدة ضوء مدقق إجماع السلسلة الرئيسية - ثق في إجماع الأغلبية الصادقة للسلسلة الرئيسية ؛
• عقدة ضوء المدقق الكامل للسلسلة الرئيسية - تحقق من إثبات صحة السلسلة الرئيسية + تشغيل DAS على السلسلة الرئيسية (بما في ذلك بيانات Rollup + بيانات السلسلة الرئيسية) ؛
• عقدة السلسلة الرئيسية الكاملة - قم بتنزيل جميع بيانات السلسلة الرئيسية (بما في ذلك التحقق من البيانات الإجمالية) + تنفيذ جميع معاملات السلسلة الرئيسية للتحقق مباشرة من الصلاحية ؛
• لاحظ أنه يمكن التحقق من صلاحية حالة مجموعة التحديثات من خلال مسارين مختلفين:
• خارج السلسلة الرئيسية (تشغيل برنامج عقدة Rollup إضافي) - لا يتطلب Rollup سلسلته الرئيسية للتحقق من حالته أو STF ، ولا يحتاج إلى نشر جسر تحقق ، وبدلا من ذلك يمكنه التحقق من إثبات Rollup بطريقة أخرى (على سبيل المثال ، تلقي إثبات Rollup عبر p2p) ، الأمر الذي يتطلب تشغيل برنامج عقدة Rollup إضافي للتحقق من الدليل (أي عقد ضوء Rollup) ؛
• داخل السلسلة الرئيسية (تنفيذ عقدة Rollup داخل السلسلة الرئيسية) - هذا هو المعيار اليوم ، يتم نشر منطق مدقق عقدة ضوء Rollup في السلسلة الرئيسية نفسها (أي عقد الجسر المدمج في Rollup) ، نظرا لأن عقدة مدقق Rollup هذه تعمل داخل STF للسلسلة الرئيسية ، فإن التحقق من صحة STF للسلسلة الرئيسية يعني أيضا التحقق من STF للمجموعة ؛

إذا حصلنا على سلسلة رئيسية خالية من المعرفة (مثل Ethereum L1 zkEVM) + تثبت جميع عمليات التجميع حالتها داخل السلسلة الرئيسية → فسنحصل على رؤية Vitalik لإثبات التفرد. إن إثبات المعرفة الصفرية للتحقق من صحة Ethereum يعني التحقق من صحة جميع السلاسل الأخرى والتحقق من صحة العقد لتطبيقاتها الداخلية:

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

التغييرات من جدول "المسار السريع التراكمي" السابقة كما يلي:

يتم تحقيق ذلك من خلال إجبار السلسلة الرئيسية للمعاملات على تضمين أو فرض استبدال التسلسل / المشغل ، والذي نسميه النشاط "النهائي" هنا ، لأنه من وجهة نظر Rollup ، إنه مسار بطيء ، ولكن من منظور السلسلة الرئيسية ، يمكن اعتبار هذا نشاطا "في الوقت الفعلي".

التراكمي مع سلسلة الكتل المتكاملة

الآن يمكننا أن نرى التغييرات في سمات الأمان المتعلقة ب blockchain المتكاملة و Rollup:

• DA وصلاحية الحالة - إذا تم تنفيذه ، يمكن أن يوفر إثبات صلاحية DAS + ضمانات أمان قابلة للتطبيق ، بغض النظر عما إذا كانت السلسلة متكاملة أو تقليدية Rollup. في الواقع ، تهيمن مجموعة التحديثات على هذه التقنيات اليوم. مقاومة الحياة وإعادة التنظيم - سلاسل الكتل المتكاملة مسؤولة عن ذلك بشكل مستقل عبر جميع السيناريوهات. بدلا من ذلك ، تقدم مجموعة التحديثات مجموعة من قواعد التأكيد ضمن أطر زمنية مختلفة. يمكنك استخدام قواعد تأكيد أقل أمانا (إجماع تسلسل الثقة) للحصول على ضمانات سريعة ، أو انتظار قواعد تأكيد أكثر أمانا (انتظر إجماع السلسلة الرئيسية) ؛

النشاط ومقاومة إعادة التركيب

لا يمكن ضمان هذه السمات بكلمة مرور، وحتى عبر قواعد الإقرار (على سبيل المثال، سواء كنت تشغل عقدة كاملة أو خفيفة)، فقد تكون عرضة لفشل الأمان.

إذا كان المشغل خارج نطاق السيطرة تماما ، فلا يمكن لأي عقدة كاملة أو دليل ZK أن يحميك من فشل النشاط أو إعادة التنظيم.

يتم تحقيق هذه السمات من خلال مشغلين أقوياء ولامركزيين ، وآليات مقاومة للرقابة ، وتوافق في الآراء يفضي إلى النشاط ، و "تكلفة" عالية لإعادة الهيكلة ، وإجماع اجتماعي قوي ، وما إلى ذلك. غالبا ما تكون المقارنة الموضوعية بين هذه الأمور صعبة.

كيف تقيس لامركزية المشغل والإجماع الاجتماعي؟ لا توجد إجابة واحدة صحيحة. يمكن القول إن هذه هي أصعب الجوانب في التصميم ، وهي في الواقع فريدة جدا لسلسلة معينة.

الأهم من ذلك، نرى أن مجموعة التحديثات يمكنها تفويض مكافحة إعادة التنظيم والنشاط إلى السلسلة الرئيسية، وأن قواعد التأكيد المستخدمة في مجموعة التحديثات يمكن أن يكون لها نفس سمات الأمان كما لو كانت تعمل على السلسلة الرئيسية في نفس الإطار الزمني.

يمكن للسلاسل حتى اختيار السمات التي سيتم تفويضها إلى أي سلسلة، ويمكن لأنواع مختلفة من البنى "L2" (مثل الصلاحيات والتفاؤل والسلاسل الجانبية) استيعاب مجموعات فرعية مختلفة من سمات الأمان. على سبيل المثال:

• مكافحة إعادة الهيكلة - قد تفوض مجموعة التحديثات مكافحة إعادة الهيكلة إلى Ethereum ، وتستند قواعد اختيار الشوكة الخاصة بها إلى ما يؤكده إجماع Ethereum لتحديد "السلسلة الأساسية". إذا تمت إعادة تنظيم Ethereum ، إعادة تنظيم Rollup أيضا.
• حيوية - ومع ذلك ، إذا كان Rollup يفتقر إلى التضمين القسري وآلية استبدال المشغل القسري ، فلا يزال مستخدمو Rollup لا يتلقون سمة حيوية Ethereum ؛

يمكن أن يوفر Rollup أيضا للمستخدمين مسار هروب للخروج من Rollup ، ولكن مع الاحتفاظ بالقدرة على فحص المستخدمين ومنع الودائع من دخول Rollup (هذه هي الطريقة التي يعمل بها Loopring ، على سبيل المثال). إذا ظل الإيداع غير معالج بعد فترة زمنية معينة ، فيمكن للمستخدم سحب الأموال المقفلة من عقد L1.

وهذا يسلط الضوء على أهمية هذه الآليات.

توفر البيانات وصلاحية الحالة

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

ومع ذلك ، تتأثر العقد الخفيفة لمدقق الإجماع بالطبع بصحة حالة الأغلبية النزيهة وفشل DA. إنهم يؤمنون فقط بكل ما يقوله الإجماع. هذا هو السبب في أن DA وصلاحية الحالة هي التي تجعل قواعد تأكيد الأمان متاحة وتعمل حقا. غالبا ما يكون هذا هو الاختلاف الأيديولوجي الكبير بين Rollups التقليدية و blockchains الكبيرة التي لا تركز كثيرا على التحقق من المستخدم.

بالترتيب ، غالبا ما تكون هذه هي الطرق المفضلة لتحقيق التوازن بين الأمان وإمكانية الوصول:

• جعل DAS وإثبات الفعالية متاحة على نطاق واسع ؛
• إذا لم يكن لديك DAS و / أو إثبات الصلاحية ، فاجعل العقد الكاملة متاحة على نطاق واسع (أي متطلبات الموارد المنخفضة ، وسهولة التشغيل ، وما إلى ذلك) ؛
• إذا لم يكن لديك DAS و / أو إثبات الصلاحية ، وكان يتعذر الوصول إلى العقدة الكاملة إلى حد كبير ، فيرجى جعل عقدة ضوء مدقق الإجماع متاحة على نطاق واسع والحصول على إجماع أغلبية صادقة جدير بالثقة ؛
• زيارة إنفورا.

لاحظ أن 2 (عقدة كاملة) هي في الواقع الأكثر أمانا. يعد التحقق من ZK أمرا بسيطا ، لكن عقد DAS تضع بعض الافتراضات الإضافية التي لا تقوم بها العقد الكاملة. ومع ذلك ، فإنها توفر نفس الأمان تقريبا مثل العقد الكاملة ، ومع متطلبات الموارد في جزء صغير من ذلك ، فهي قابلة للتطوير.

تحتاج العقد الكاملة فقط إلى تنزيل جميع البيانات ، لذا فهي متأكدة بنسبة 100٪. يوقعون على الكتلة فقط عندما يكون كل شيء هناك. لم يتم وضع أي افتراضات حول الأطراف الخارجية.

الهدف من DAS هو تحقيق أمان جيد تقريبا مثل العقد الكاملة ، مع متطلبات موارد أقل بكثير (أي على نطاق أعلى). تغطي هذه المقالة حول مستويات أمان توفر بيانات العقدة الخفيفة هذا جيدا.

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

هذه الافتراضات "N-in-2" (على سبيل المثال ، يمكن لأقلية صادقة من العقد تأمين DAS) مفيدة للغاية فيما يتعلق بالافتراض التقريبي النموذجي "N / 2" (على سبيل المثال ، يمكن أن يؤدي 51٪ من منتجي الكتل إلى إعادة التنظيم). فيتاليك لديه مقدمة جيدة لهذا في منصبه على نموذج الثقة.

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

راجع مثالا للتحقق السابق من إثبات القيمة الإجمالية:

• نشر دليل Rollup على ZK إلى عقد Ethereum الذكي ، حيث تقوم بتشغيل عقدة Ethereum الكاملة والتحقق ضمنيا من الدليل ؛
• أرسل دليل ZK من Rollup إلى عقدة ضوء Rollup للتحقق من الدليل مباشرة ؛

في كلتا الحالتين ، يمكنك ضمان الفعالية. بغض النظر عن مكان التحقق منه ، لا يمكنك تحديد فعاليته. لا تتمتع Ethereum بنفس الفعالية "القسرية" حقا مثل عقد Ethereum "القوة" المضادة لإعادة الهيكلة أو الخصائص النشطة. تعتمد مناهضة إعادة الهيكلة والحيوية إلى حد كبير على من تحصل عليها.

ضع في اعتبارك مجموعة التحديثات المستندة إلى سلسلة الاحتيال:

• تتبع قواعد اختيار شوكة Rollup طرف السلسلة→ إذا تمت إعادة تنظيم السلسلة ، إعادة تنظيم Rollup أيضا ؛
• يتم فرض آلية التضمين الإلزامية ل Rollup وحذف التسلسل من خلال عقود التجسير عبر السلسلة على سلسلة الاحتيال→ إذا توقف دفتر الأستاذ لسلسلة الاحتيال ، فسيتوقف دفتر الأستاذ الخاص بمجموعة التحديثات أيضا. إذا أرادت سلسلة الاحتيال فرض رقابة على مجموعة التحديثات الخاصة بك ، مراقبتك ؛

Rollup قادر على كشف قواعد التأكيد بنفس سمات الأمان مثل سلسلتهم الرئيسية ، والتي يمكنهم تلقيها على الأكثر بمعدل إجماع سلسلة المضيف (في الواقع ، سيكون عادة أبطأ ، اعتمادا على عدد المرات التي يتم فيها نشر Rollup إلى السلسلة الرئيسية).

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

يمكن أن يكون لاختيار السلسلة الرئيسية ل Rollup بحكمة تأثير ملموس على سمات الأمان. من المهم بشكل خاص الاستفادة من سلسلة خلفية ذات نشاط قوي (نمو دفتر الأستاذ + CR) ومقاومة إعادة التنظيم.

افتراضات أمنية مختلفة لفترات زمنية مختلفة

لنلق نظرة على مثال بسيط. تقرر Chain X ما إذا كان سيتم نشرها كمجموعة تراكمية على سلسلة رئيسية موجودة أو كسلسلة بلوكشين متكاملة خاصة بها.

يحتوي الإظهار على الخصائص التالية:

• 10 ثوان كتلة الوقت.
• يتم دعم العقد الخفيفة DAS
• يمكن توفير قواعد تأكيد "عالية الأمان" للنشاط ومكافحة إعادة التنظيم (مثل المدققين اللامركزيين الموثوق بهم ، وما إلى ذلك) ؛

تتميز سلسلة الكتل المتكاملة بالخصائص التالية:

• كتلة وقت الإخراج هو 1 ثانية ؛
• يمكن تنفيذ عقدة ضوء DAS وإثبات الصلاحية ، سواء تم إطلاقها كسلسلة كتل متكاملة أو كمجموعة تراكمية ؛
• إذا تم تنفيذ جهاز تسلسل مركزي - فإنه سيوفر قواعد تأكيد "أمان منخفضة" حول النشاط ومقاومة إعادة التركيب ؛
• إذا نفذت إجماعا لامركزيا خاصا بها (إما كمجموعة تسلسل تراكمية مؤكدة مسبقا أو كمجموعة مدقق سلسلة متكاملة) ، فستوفر قواعد تأكيد "أمان متوسط" للنشاط ومكافحة إعادة التنظيم ؛

يقدم الجدول التالي تمثيلا مرئيا مبسطا لأفضل ضمانات الأمان التي قد يتمتع بها المستخدمون في ظل عمليات التنفيذ المختلفة (أي أنهم يستخدمون أقوى قواعد الإقرار المتاحة). على وجه الخصوص ، نركز هنا على النشاط ومقاومة إعادة التركيب (لأننا نفترض أن السلسلة ستحقق فقط إثبات فعالية DAS + في هاتين الحالتين):

يعد "الأمان المطلق" ل Rollup أعلى من "الأمان في الوقت الفعلي" لأن السلسلة الرئيسية لا يمكن أن تضمن لنا أسرع من وقت الكتلة الخاص بها. على الرغم من أنه يمكنك التحقق من أن الإقرارات المسبقة لجهاز التسلسل هي انتقالات حالة صالحة ، لا يمكنك ضمان نهايتها بالكامل حتى تصل أخيرا إلى طبقة DA.

ولكن كما رأينا ، فإن النشر في سلسلة رئيسية قوية بطريقة تراكمية يعزز الأمان. يمكنهم استئجار الأمن بسرعة سلسلتهم الرئيسية. بشكل أساسي ، لا توجد طريقة للحصول على جميع سمات الأمان للسلسلة الرئيسية بشكل أسرع من إجماع السلسلة الرئيسية نفسها.

ومع ذلك ، يميل المستخدمون إلى نفاد الصبر. نتيجة لذلك ، ستوفر مجموعة التحديثات عادة تأكيدا مسبقا أسرع ، لكن الضمان سيكون أقل خلال هذه الفترة. يمكن للمجموعة اختيار تصميم تسلسل متوازن:

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

ومن المثير للاهتمام ، يمكنك القول بأن مجموعات طلب L1 أقل نشاطا من أجهزة التسلسل المركزية ، اعتمادا على النطاق الزمني الخاص بك. حتى الآن ، تحدثنا عن النشاط ، بما في ذلك في نوع من مفهوم "الوقت المحدود". ومع ذلك ، هذا نسبي تماما وذاتية. نسبة إلى ماذا؟ كم من الوقت يستغرق؟

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

• إذا كان الأساس = العملية داخل مجموعة التحديثات ، فقد توفر مجموعة التحديثات المتسلسلة L1 نشاطا أفضل. لا ينبغي وعد أي شخص آخر في السلسلة حتى يتم تأكيد السلسلة الرئيسية ، لذلك أنتم جميعا على قدم المساواة ؛
• إذا كان خط الأساس = العملية خارج مجموعة التحديثات - يمكن أن توفر مجموعة التحديثات ذات التأهيل المسبق الناعم نشاطا أفضل. يعد التأكيد المسبق مجرد خيار مجاني ، وما زلت تعود إلى ضمان السلسلة الرئيسية بسرعة السلسلة الرئيسية ، ولكن يمكنك الحصول على ضمان أضعف في هذه الأثناء. إذا كنت لا تثق بهم ، فما عليك سوى انتظار تأكيد السلسلة الرئيسية. لا يتجمد العالم بين كتل Ethereum ، وبالنسبة للعديد من التطبيقات ، قد تكون الأسعار القديمة بين أوقات الحظر الطويلة غير مقبولة ؛

إذا حاولت تنفيذ مجموعة تحديثات "حقيقية" دون تأكيد مسبق ، فمن الممكن أن يحدث تأكيد مسبق على أي حال. بالنسبة للمشاركين ، مثل بناة ومدققي Ethereum ، هناك حافز مالي لهم لتقديم هذا الالتزام بأنفسهم. هذا هو بالضبط سبب وجود نقاش حول كيفية محاولة منشئي Ethereum وأصحاب المصلحة توفير تأكيد مسبق سريع في الطبقة الأساسية.

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

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

بغض النظر عن الجدول الزمني الدقيق ، فإن النشاط النهائي لامتصاص السلسلة الرئيسية قوي للغاية ، واستخدام سلسلة رئيسية قوية كآلية تنسيق يوفر تهديدات موثوقة وحقوق خروج. إن مجرد الكشف عن هذا التهديد الموثوق وحده يجعل من غير المرجح أن تكون هناك حاجة إليه لمنع السلوك الضار في المقام الأول.

على سبيل المثال ، إذا كان لدى المستخدم آلية موثوقة للخروج بالقوة أو حتى إزالة المشغل بالقوة ، فلن يتمكن جهاز التسلسل التراكمي المركزي من استخراج الإيجار بشكل تعسفي من المستخدم وقفله. هذا مجال عام تمت مناقشته في كريس جويس في حديثه عن حافة تكلفة تحويل MEV والألعاب البطيئة.

بالطبع ، يمكن أن يحدث نشاط غير متوقع أيضا ، وفي هذه الحالة يمكن أن يكون مسار النسخ الاحتياطي هذا ذا قيمة كبيرة مرة أخرى.

الإثبات لا يحمي السلسلة بل يحمي المستخدم

بعد كل هذا ، يمكننا أن نرى أنه بالنسبة لقاعدة تأكيد معينة ، اتضح أنه من الأكثر دقة حماية "المراقبين" (المستخدمين) المختلفين لمجموعة التحديثات بدلا من حماية "مجموعة التحديثات" نفسها. لا يوجد أمان "مجموعة التحديثات" كإجراء واحد محدد.

ضمان سلامة المراقب هو بالطبع أهم شيء ، لأننا جميعا مراقبون للسلسلة! هذه السلسلة هي ما يقوله مراقبوها. إذا لم تتمكن من مراقبتها بطريقة آمنة ، فعليك أن تثق بشخص آخر (مثل المدقق) ليخبرك ب "الحقيقة" عنها. لكننا لا نريد أن نثق ، نريد التحقق → نريد دليلا.

لفهم سبب أهمية التمييز بين "إثبات السلسلة" و "مراقب سلسلة الإثبات" ، ضع في اعتبارك ما يلي:

• العقد الخفيفة - تكون العقد الخفيفة Rollup أكثر أمانا إذا كان هناك دليل ، فلا يتعين عليهم الوثوق بصحة كلمات أي شخص ؛
• عقدة كاملة - إذا كان هناك دليل ، فلن يزيد أو ينقص أمان العقدة الكاملة من Rollup ، يمكنك بدء Rollup ("مجموعة التحديثات المتشائمة") بدون جسر مدمج أو حتى أي دليل ، إذا بدأت في إرسال دليل على الصلاحية ، فلن يزيد أمان العقدة الكاملة أو ينقص ؛

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

التصديق يؤمن جسر الالتفاف

يعد جسر التحقق الخاص ب Rollup مراقبا مهما للغاية! الأدلة تضمن سلامة الجسر!

كما هو الحال مع أي عقدة ضوء نموذجية ، لا يمكن للجسر التحقق مباشرة من صلاحية Rollup. نحن لا نؤمن بالأغلبية النزيهة ، لكننا نحمي الجسور بالأدلة. يقوم بروتوكول الإجماع لقاعدة البيانات A (طبقة DA) بفرز الكائنات الثنائية كبيرة الحجم للبيانات ثم يتحقق من أن الجسر يتحقق بشكل مستقل من صحة التحديث المقابل لقاعدة البيانات B (مجموعة التحديثات):

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

إذا قمت بتشغيل عقد كاملة للسلسلة، فلن تتمكن الأطراف الضارة من خداعك لقبول انتقالات الحالة غير الصالحة. ومع ذلك ، إذا كان لدى الطرف الضار قواعد تأكيد مختلفة ، فلا يزال بإمكانه انتحال الجسر. إذا كنت تحتفظ بأصول مدعومة بضمانات في الجسر ، فقد تصبح أموالك غير مدعومة. بهذا المعنى ، فإن الفشل الأمني لجسر الانتحال "معدي".

دعنا نفكر في سيناريو افتراضي قديم حول Terra:

• لدى Terra مجموعتها الخاصة من المدققين ، ورمزها الأصلي هو LUNA ، ويمكن إصدار UST الأصلي ؛
• يحتوي Osmosis على مجموعة خاصة به من المدققين ، ورمزه الأصلي هو OSMO.
• لدينا جسر Terra ←→ Osmosis IBC قياسي حيث يقوم كل جانب بتشغيل عقدة ضوء مدقق الإجماع للسلسلة الأخرى (أي أن كل جانب من الجسر يعتمد على أغلبية صادقة من مجموعة المدققين في السلسلة الأخرى) ؛
• يمكنك تشغيل العقدة الكاملة الخاصة بك لكل سلسلة كمستخدم ؛
• نشير إلى UST على التناضح الذي تم تجسيره عبر IBC باسم osmoUST ؛
• نشير إلى OSMO على Terra التي تم تجسيرها عبر IBC باسم terraOSMO ؛
• أنت تملك تيرا أوسمو على تيرا.
• أنت تقوم بعمل LPs في تجمع osmoUST / OSMO على التناضح ؛

مع انهيار Terra ، ينخفض سعر LUNA ، وفي النهاية ، سيتجاوز ربح مجموعة المدققين التي تصبح ضارة نظريا قيمة LUNA المخزنة ، ويمكن لمدقق Terra توقيع كتل غير صالحة والقيام بما يلي:

• النعناع المزيف UST → عبر السلسلة إلى التناضح إلى النعناع osmoUST ، استخدمه لاستنفاد جميع أزواج تداول osmoUST (على سبيل المثال ، أخرج جميع OSMO من تجمع osmoUST / OSMO ؛
• سك terraOSMO المزيف → عبر السلسلة إلى التناضح لسحب جميع ضمانات OSMO الأصلية المقفلة على التناضح الذي يدعم terraOSMO ، ولن يتم الآن دعم جميع terraOSMO المتبقية على Terra ؛
• حسنا ، فشل الأمان هنا:
• العقدة الكاملة (أنا) - تتعرف العقدة الكاملة الخاصة بي على كتل Terra على أنها غير صالحة وترفضها ، ولا يمكن لمدققي Terra سرقة مواقع terraOSMO أو osmoUST / OSMO LP ؛
• عقدة خفيفة (جسر) - يتحقق الجسر فقط من توقيع إجماع Terra على الكتلة (عدم التحقق من انتقالات الحالة الصالحة) حتى لا يرفضها ، يمكن لمدققي Terra سرقة ضمانات OSMO التي تدعم terraOSMO الخاص بي واستنزاف جميع OSMO من تجمع osmoUST / OSMO (ترك مجموعة من osmoUST لا قيمة لها) ؛

يستخدم الجسر قواعد الإقرار مع افتراضات ثقة أقوى.

لا يمكن لمدققي Terra سرقة كميات كبيرة من أصول Terra الخاصة من العقد الكاملة (لن يتم خداعهم) ، وسوف يرفضون هذه الكتل. ومع ذلك ، يمكن للمدققين خداع مدققي الإجماع في عملاء خفيفين (بما في ذلك الجسور) ، وهذا هو السبب في أن أخطاء الإجماع تؤثر على الأصول عبر السلسلة.

لاحظ أنه من المهم ألا "تصيب" هذه الأخطاء بقية السلسلة ، أي أن الخطأ "يصيب" أصول التناضح المعرضة لمسار جسر تيرا ، ولكن لا يوجد خطأ أمني في سلسلة التناضح نفسها.

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

كتجربة فكرية ، فإن أبسط حل هو جعل كل مستخدم يقوم بتشغيل العقد الكاملة لكل سلسلة ، والتي تتضمن الجسر عبر السلسلة نفسه. ضع في اعتبارك أننا رأينا بعض جسور العقدة الكاملة المضمنة أحادية الاتجاه:

• تتطلب مجموعات Ethereum حاليا عقد خاصة بها لتشغيل عقد Ethereum الكاملة ، وتشترك هذه المجموعات في إجماع Ethereum ؛ ستتطلب Namada (سلسلة Tendermint منفصلة ، وليست سلسلة Rollup) من عقدها تشغيل عقد Ethereum الكاملة ، ومع ذلك لا توافق Namada على إجماع Ethereum (أي أنها لا تنشر البيانات إلى Ethereum أو تستمد حالتها بناء على ذلك) ؛

يعمل هذا مع عقد Ethereum الكاملة ، ولكن من الواضح أن هذا لا يتوسع. لا يمكنك البدء في جعل كل سلسلة Cosmos تحتاج فقط إلى تشغيل عقد كاملة لكل سلسلة Cosmos أخرى. لا تتوسع جسور العقدة الكاملة ثنائية الاتجاه هذه ، بل تزيد فقط من متطلبات الأجهزة.

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

صلاحية الحالة - بينما يتم استخدام IBC حاليا مع إثبات الإجماع التقليدي ، يمكن تعديله لإضافة دليل على الصلاحية لربط السلاسل ، والآن لا يتم خداع الجسور من خلال انتقالات الحالة غير الصالحة. كان من شأن هذا أن يمنع بالضبط ما وصفه الهجوم سابقا ، وإذا كان الجسر قادرا على التحقق من صحة انتقال الحالة ، لكان قد رفض كتلة مدقق Terra باعتبارها غير صالحة.

يبدو هذا مشابها جدا لكيفية قيام جسر Rollup على Ethereum بالتحقق من البراهين التراكمية ، باستثناء أنه يمكن أن يكون ثنائي الاتجاه أيضا.

DA - بالإضافة إلى ذلك ، قد تتطلب السلسلة عقدها لتشغيل عقد ضوء DAS التي تربط السلسلة. على سبيل المثال، يمكن أن يكون لديك سلسلتان Cosmos تتطلبان المدققين الخاصين بهما لتشغيل عقد ضوء DAS الخاصة بالسلسلة الأخرى (إذا كانت كل سلسلة تنفذ عملاء ضوء DAS، غير المدعومين حاليا). بمجرد الانتهاء من ذلك ، يمكن لكل سلسلة الآن معرفة صلاحية بعضها البعض و DA دون الحاجة إلى تشغيل العقد الكاملة.

بالنسبة إلى Rollup ، بحكم التعريف ، فأنت تمتلك جميع البيانات الموجودة على السلسلة الرئيسية ، بحيث يمكن للجسر هناك الوصول إليها. من ناحية أخرى ، تقوم عقد التجميع بتشغيل عقد السلسلة الرئيسية.

سلاسل مستقلة ومستقلة

لنلق نظرة على سمات الأمان الخمس الخاصة بنا مرة أخرى ، الآن في سياق مراقبة جسر التحقق من Rollup على Ethereum:

• نمو دفتر الأستاذ - يمكن لمدققي Ethereum إجبار دفتر الأستاذ الخاص ب Rollup على الاستمرار في النمو (مثل معاملات تضمين القوة) ؛
• مقاومة الرقابة - يمكن لمدققي Ethereum إجبار مشغلي Rollup على عدم فرض رقابة إلى أجل غير مسمى (على سبيل المثال ، فرض تضمين المعاملات أو استبدال جهاز التسلسل) ؛
• مكافحة إعادة الهيكلة - ترتبط مكافحة إعادة هيكلة Rollup ب Ethereum. إذا تمت إعادة تنظيم Ethereum ، إعادة تجميع جميع عمليات التجميع على Ethereum ؛
• توافر البيانات - DA الخاص ب Rollup مضمون لأن Rollup مشتق بحكم التعريف من البيانات التي يؤكدها إجماع السلسلة الرئيسية (حيث يوجد عقد Rollup) ، وتشترك Rollup والسلسلة الرئيسية في إجماع الدمج ، DA هو شرط صلاحية Ethereum نفسها ، لذلك إذا لم تكن البيانات متوفرة ، فإن كتلة Ethereum نفسها غير صالحة. يمكن للجسر الوصول إلى البيانات على السلسلة الرئيسية دون إضافة افتراضات الثقة ؛
• صلاحية الحالة - سيتحقق العقد من إثبات صحة انتقال حالة التجميع (أو انتظر مرور نافذة التحدي) ، مما يثبت أن تحديث الحالة المعلن هو نتيجة صالحة لتطبيق STF الخاص ب Rollup على البيانات المقابلة المؤكدة على السلسلة الرئيسية ؛

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

يقدم فيتاليك مثالا توضيحيا مفيدا:

"تقوم بنقل 100 ETH إلى جسر فوق Solana وتحصل على 100 Solana-WETH ، وتتعرض Ethereum للهجوم بنسبة 51٪. يقوم المهاجم بإيداع مجموعة من ETH في Solana-WETH ثم يستأنف المعاملة على جانب Ethereum بمجرد أن يؤكد جانب Solana ذلك. لم يعد عقد Solana-WETH مدعوما بالكامل ، وربما تبلغ قيمة 100 Solana-WETH الآن 60 ETH فقط. حتى مع وجود جسر مثالي قائم على ZK-SNARK للتحقق من صحة الإجماع بالكامل ، فإنه لا يزال عرضة لهجوم بنسبة 51٪ مثل هذا.

لذلك ، من الآمن دائما الاحتفاظ بأصول Ethereum الأصلية على أصول Ethereum أو Solana الأصلية على Solana بدلا من الاحتفاظ بأصول Ethereum الأصلية على Solana أو أصول Solana الأصلية على Ethereum. في هذا السياق ، لا يشير "Ethereum" إلى السلسلة الأساسية فحسب ، بل يشير أيضا إلى أي L2 مناسب مبني عليها.

إذا تعرضت Ethereum للهجوم بنسبة 51٪ وتعافت ، فسوف يتعافى Arbitrum و Optimism أيضا ، لذلك حتى إذا تعرضت Ethereum للهجوم بنسبة 51٪ ، فإن تطبيقات "التجميع المتقاطع" التي تحفظ الحالة على Arbitrum و Optimism مضمونة للبقاء ثابتة. إذا لم تتعرض Ethereum لهجوم بنسبة 51٪ ، فلن تكون هناك طريقة للقيام بهجوم بنسبة 51٪ على Arbitrum و Optimism ، على التوالي. لذلك ، لا يزال من الآمن تماما الاحتفاظ بالأصول الصادرة عن Optimism القائم على التحكيم .

يمكنك استبدال Solana بأي سلسلة تريدها - حتى سلسلة افتراضية حيث تتفوق على مدقق Ethereum من حيث الثقة ، وبشكل أساسي ، تكون أي افتراضات أمنية مضافة عندما تتحدث عن الأصول عبر السلاسل مع دفتر الأستاذ الخاص بها (على سبيل المثال ، ETH من Ethereum) ، وهناك دائما إمكانية إعادة تنظيم سلسلة متصلة أو فشل النشاط.

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

ما هي الافتراضات الأمنية المعقولة متروك لك. في الواقع ، لم يكن هناك فشل إجماع مماثل بين السلاسل الرئيسية. سيكون هذا واضحا ومكلفا ، لكنه قد يكون افتراضا أقوى حول ربط السلاسل الأضعف.

هناك أيضا بعض العيوب لربط سلسلة Rollup بالسلسلة الرئيسية. دعنا نقارن سيناريوهين عبر السلسلة ، في كلتا الحالتين لدينا سلسلتان تستخدمان جسرا عبر سلسلة المدقق الكامل ثنائي الاتجاه:

• التبعية - تشترك السلسلة البعيدة (أي Rollup) في إجماع السلسلة الرئيسية (أي طبقة DA) وتستمد حالتها الخاصة من البيانات الموجودة على السلسلة الرئيسية ، ويجب أن تتفرع السلسلة البعيدة مع السلسلة الرئيسية وتحدد نهايتها بناء على السلسلة الرئيسية ؛
• مستقلة - هذه السلاسل لها إجماع مستقل خاص بها ، فهي لا تستمد حالتها الخاصة بناء على بيانات عن سلاسل أخرى. لا يشتركون في علاقة سلسلة بعيدة (أي مجموعة تحديثات) ←→ السلسلة الرئيسية (أي طبقة DA). إنهم لا يعيدون تجميع صفوفهم معا ولا يعتمدون على نشاط بعضهم البعض ؛
• ومن المثير للاهتمام ، أن هذه الأشياء جيدة وسيئة:
• سيء - قد تبدو إعادة تنظيم سلسلتك مع سلاسل أخرى أو فشل النشاط عيبا للوهلة الأولى ، فلماذا تواجه سلسلتي مشاكل لأن سلسلتك مكسورة؟
• جيد - إذا تسبب هذا الاختلاف في مشاكل خطيرة في سلسلتك ، فهذه في الواقع فائدة مهمة (على سبيل المثال ، إذا كان لديك عدد كبير من الأصول عبر السلسلة من سلسلة المصدر ، إعادة تنظيمها من منظور جسرك عبر السلسلة ، مع ترك ضمانات غير مدعومة) ، يجب أن تكون السلسلة وجسرها عبر السلسلة متسقين مع بعضهما البعض ؛

وبالمثل، فإن القيود والسعي المفرط إلى الريع لهما آثار إيجابية وسلبية محتملة، مما يسلط الضوء على سبب أهمية وجود طبقة أساسية محايدة ومقاومة للرقابة:

• جيد - تحمي السلسلة الرئيسية الجيدة مستخدمي Rollup من مشغلي Rollup الذين يضغطون على الكثير من القيمة منهم ، مما يفرض امتيازات الخروج ؛
• سيئة - قد تؤدي السلاسل الخلفية السيئة إلى تضخيم السعر بشكل تعسفي واستخراج تلك القيمة من Rollup ومستخدميها أنفسهم ؛
• إثبات التقديم + تشغيل DAS في كلا الاتجاهين بدلا من مشاركة سلسلة رئيسية مشتركة لديه أيضا بعض أوجه القصور:
• لا تريد أن تطلب من العقدة الخاصة بك تشغيل مجموعة من العقد الخفيفة DAS للسلاسل الأخرى ، ويجب عليك إضافة سلاسل جديدة يدويا ، وتشغيل DAS على طبقة DA مشتركة ضخمة أكثر كفاءة ؛
• من غير الفعال لكل سلسلة التحقق من صحة العديد من السلاسل المختلفة ، ومع ذلك ، فمن الممكن نظريا تجميع البراهين بين سلاسل متعددة بحيث تحتاج مجموعة السلسلة بأكملها فقط إلى نشر دليل واحد على السلسلة ؛

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

خاتمة

يعد "أمان الميراث Rollups" اختصارا جيدا ، ولكن تذكر أن هذه هي النقاط الرئيسية التي نعنيها حقا:

• تدفع Rollup إيجارا لسلسلتها الرئيسية ، مثل Ethereum ، مقابل الموارد التي تستهلكها (DA) ؛
• يمكن أن تعرض مجموعة التحديثات قواعد التأكيد مع خصائص الأمان حتى السلسلة الرئيسية (أي يمكن للمستخدمين الحصول على نفس الضمانات الأمنية كما هو الحال عند التشغيل على السلسلة الرئيسية نفسها) ؛
• يحصل المستخدمون على سمات أمان السلسلة الرئيسية هذه بسرعة إجماع السلسلة الرئيسية ؛
• إذا أراد مستخدمو Rollup أن يكونوا أسرع من التأكيد الذي توفره السلسلة الرئيسية ، فيمكنهم استخدام قواعد التأكيد ، والتي تضع افتراضات أمنية مؤقتة إضافية ؛
• يتفاعل المراقب (أي المستخدم) مع مجموعة التحديثات من خلال قواعد التأكيد ، وجسر التحقق بأقل افتراض ثقة هو مراقب (اختياري ولكنه ذو قيمة كبيرة) ؛

الآن ، ضع في اعتبارك فوائد نشر مجموعة التحديثات على سلسلة التكامل:

سلامة المستخدم - سواء كنت ترغب في تنفيذ أي جسور عبر السلسلة أم لا ، يمكن ل Rollups استئجار DA من سلسلتها الرئيسية واستعادة إجماعها ، مما يسمح ل Rollup بكشف قواعد التأكيد التي تطابق السلسلة الرئيسية مع مستخدميها دون الحاجة إلى الوصول إلى إجماعها الخاص ؛

الأمان عبر السلسلة - يمكن ل Rollup بناء سلسلة مشتركة داخل مجال الأمان المشترك للسلسلة الرئيسية (أي السلسلة الرئيسية نفسها و Rollup الخاصة بها) ، ويمكن مقارنة خصائص الأمان الخاصة بها بالعمل على السلسلة الرئيسية نفسها ؛

يجب أن نرى أن هذا في الواقع وجهان لعملة واحدة ، وأن Rollup يسمح فقط للسلسلة بتوفير قواعد التأكيد ، ويمكن أن يصل أمانها إلى أمان السلسلة الرئيسية. كل من الجسور عبر السلاسل والمستخدمين العاديين هم مراقبون للسلاسل مع قواعد إقرار معينة. ربما تكون الجسور أهم "مراقبين" في هذه السلاسل لأن أمنها له آثار واسعة النطاق.

عندما نحاول إنشاء نظام آمن ، نحتاج إلى الاهتمام بأمان قواعد التأكيد المحددة بالإضافة إلى إمكانية الوصول إليها. إذا كان معظم المراقبين (المستخدمين) الذين يتفاعلون مع هذه السلاسل بعيد المنال ، فإن قواعد تأكيد الأمان لا تساعد كثيرا.

بينما نربط اليوم DAS وإثبات الصلاحية مع Rollup ، فهي مفاهيم منفصلة منطقيا. يمكن لأي سلسلة دمج هذه التقنيات ، ويبدأ التمييز بين ما هو تراكمي أو ليس مجموعة تراكمية في الانهيار في نهاية اللعبة (أي بالنسبة لمجموعة واحدة متكاملة ، قد يكون لها طبقات DA وتنفيذ منفصلة منطقيا تحت بروتوكول واحد).

ومع ذلك ، فإن طبقات "التجميع التقليدية" و DA تهيمن بوضوح على تقنيات التحقق والتوسع هذه اليوم.