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

المؤلف: Wuyue ، المهوس Web3

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

الجسم: دعنا نتخيل مخطط تحجيم السلسلة العامة بالخصائص التالية:

• لديها سرعة مماثلة لتطبيقات أو تبادلات Web2 التقليدية ، تتجاوز بكثير أي سلسلة عامة ، L2 ، rollup ، sidechain ، إلخ.
• لا توجد رسوم غاز ، وتكلفة الاستخدام تكاد تكون صفرا.
• أمان عالي للأموال ، يتجاوز بكثير المرافق المركزية مثل البورصات ، أدنى من Rollup ولكنه أكبر من أو يساوي Sidechain.
• نفس تجربة المستخدم مثل Web2 ، دون أي معرفة بمفاتيح Blockchain العامة والخاصة ، والمحافظ ، والبنية التحتية ، وما إلى ذلك.

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

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

استخدمنا موضوع التحجيم المألوف جدا كمقدمة أعلاه ، في الواقع ، ** لا يقتصر SCP على التوسع ، ** يأتي إلهام تصميمه من Bitcoin و Ethereum وغيرها من حلول توسيع نطاق السلسلة العامة ومناقشات المجتمع. تتمثل رؤيتها وتطبيقها العملي في بناء جيل جديد من البنية التحتية غير الموثوقة وحتى منصة حوسبة بهيكل غير Blockchain. **

المكونات الأساسية SCP وكيفية عملها

بشكل عام ، يشبه SCP أيضا ما تسميه مجتمعات Ethereum و Celestia “Blockchain المعياري” ، مع طبقة توافر البيانات ، وطبقة التنفيذ ، وطبقة الإجماع ، وطبقة التسوية ووحدات أخرى.

طبقة توافر البيانات: تقوم بها سلسلة عامة معترف بها ومثبتة على نطاق واسع ، أو مرافق تخزين كطبقة توفر للبيانات ، مثل Ethereum و Arweave و Celestia وما إلى ذلك. طبقة التنفيذ: خادم يتلقى معاملات المستخدم وينفذها ، ويرسل بيانات المعاملة الموقعة من قبل المستخدمين إلى طبقة DA على دفعات ، على غرار تسلسل Rollup. ومع ذلك ، لا يجب أن تحتوي طبقة التنفيذ على بنية قائمة مرتبطة على غرار Blockchain ، بل يمكن أن تكون قاعدة بيانات Web2 + نظام حوسبة بالكامل ، ولكن يجب أن يكون نظام الحوسبة بأكمله مفتوح المصدر وشفافا. طبقة الإجماع: تتكون من مجموعة من العقد التي تسحب البيانات المقدمة إلى طبقة DA بواسطة طبقة التنفيذ وتستخدم نفس الخوارزمية مثل طبقة التنفيذ لحساب البيانات لتأكيد ما إذا كان الناتج الناتج لطبقة التنفيذ صحيحا ، ويمكن استخدامه كتكرار للوقاية من الكوارث لطبقة التنفيذ. يمكن للمستخدمين أيضا قراءة البيانات التي تم إرجاعها بواسطة كل عقدة في طبقة الإجماع لضمان عدم وجود احتيال في طبقة التنفيذ. طبقة التسوية: تتكون من مجموعة من العقد والعقود أو العناوين الأخرى على السلسلة ، والتي تستخدم لمعالجة سلوك المستخدمين الذين يودعون في SCP أو ينسحبون من SCP ، يشبه إلى حد ما وضع تشغيل جسور التفاعل عبر السلسلة. تتحكم عقدة طبقة التسوية في وظيفة السحب لعنوان الإيداع من خلال العقد متعدد التواقيع أو العنوان المستند إلى TSS. عند الإيداع ، يقوم المستخدم بإيداع الأصول في العنوان المحدد للسلسلة ، ويرسل طلبا عند السحب ، وتقوم عقدة طبقة التسوية بقراءة البيانات وتحرير الأصول من خلال multisig أو TSS. تعتمد درجة أمان طبقة التسوية على آلية التفاعل عبر السلسلة المعتمدة.

إطار ممارسة اللجنة الدائمة المعنية بقانون البراءات

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

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

يمكننا أن نرى النظام بأكمله ، والإجماع الذي يحققونه هو كل شيء خارج السلسلة ، وهو جوهر نموذج إجماع التخزين - فهو يتخلى عن نظام NodeConsensus على غرار Blockchain ، ويسمح لطبقة التنفيذ بالتخلص من عملية اتصال وتأكيد الإجماع الثقيلة ، وتحتاج فقط إلى القيام بعمل الخادم ، وذلك لتحقيق TPS والاقتصاد غير المحدود تقريبا. هذا مشابه جدا ل Rollup ، لكن SCP اتخذ مسارا مختلفا من Rollup ، في محاولة للانتقال من حالة استخدام خاصة بالمقياس إلى نموذج انتقال جديد من Web2 إلى Web3. **

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

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

يمكننا أن نصرخ بمثل هذا الشعار - “** لا يتعين على الجيل القادم من البنية التحتية غير الموثوقة الاعتماد على بروتوكولات الإجماع ، ولكن يجب أن يكون أنظمة مفتوحة المصدر وشبكات عقدة P2P **”.

النية الأصلية للأشخاص لاختراع واستخدام Blockchain هي Trustless ، ودفتر الأستاذ متسق وغير قابل للتزوير ويمكن تتبعه وغيرها من الأساسيات المبتذلة ، والتي تم ذكرها بوضوح في BitcoinWhite Paper. ولكن بعد Ethereum ، سواء كان مخطط التوسع للسلسلة العامة القديمة ، أو Rollup أو Blockchain المعياري ، فقد شكل الجميع عقلية: ما نقوم به يجب أن يكون Blockchain (يتكون من بروتوكول إجماع العقدة) ، أو Rollup ، والذي يبدو أنه حل سلسلة (فقط هناك بنية بيانات Blockchain ، لكن العقدة ليس لديها تبادل مباشر لرسائل الإجماع).

ولكن الآن ، استنادا إلى إطار عمل SCP ، حتى لو لم يكن Blockchain ، يمكن تحقيق سلسلة من المتطلبات مثل دفتر الأستاذ غير الموثوق به ، والمتسق ، وعدم التزوير ، والتتبع ، وما إلى ذلك ، بالطبع ، الفرضية هي أن هناك تفاصيل تنفيذ أكثر وضوحا.

طبقة التنفيذ

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

بيئة تنفيذ ممكنة لا حصر لها

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

*تبادل. استنادا إلى SCP ، يمكن بناء تبادل مفتوح وشفاف وعالي TPS ، والذي يمكن أن يكون له خصائص سرعة CEX والتكلفة الصفرية ، مع الحفاظ على لامركزية DEX. يصبح التمييز بين CEXs و DEXs غير واضح هنا.

• شبكة الدفع. على غرار Alipay و PayPal وما إلى ذلك.
• دعم الأجهزة الافتراضية / لوادر Blockchain / العقود. يمكن لأي مطور نشر أي تطبيق عليه ، ومشاركة جميع بيانات المستخدم مع البرامج الأخرى ، والعمل وفقا لتعليمات المستخدم.

SCP ، وهو نمط تصميم يدعم بيئات التنفيذ التعسفي ، له فوائده الفريدة: لم يعد عليه الاعتماد على مكونات معينة ذات أمتعة تاريخية ، وخاصة مفهوم “تجريد الحساب” الذي أنشأه مجتمع Ethereum ، وهو أمر غير مرغوب فيه بطبيعته ل SCP.

في إطار بنية SCP ، لا يوجد مفهوم لتجريد الحساب - يمكنك اعتماد حسابات Web2 القياسية وحسابات Blockchain بحرية. من هذا المنظور ، لا تحتاج العديد من حالات استخدام Web2 الناضجة إلى إعادة التفكير والبناء للعمل مباشرة على SCP. قد يكون هذا هو فائدة SCPs على التراكمات. **

الشفافية وعدم التماثل

يجب أن يلاحظ نظام الحساب المذكور أعلاه ، والقراء الحساسون أنه على الرغم من أن SCP يمكنه الاستفادة من نظام حساب Web2 ، إلا أنه يبدو أنه من الصعب استخدامه كما هو.

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

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

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

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

** دعنا نراجع نظام تفاعل مستخدم Web3 Blockchain النموذجي: **

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

2. تسجيل دخول المستخدم: لا يتطلب استخدام Blockchain تسجيل الدخول ، ولا تحتوي معظم dApps على عملية تسجيل الدخول ، ولكنها تتصل بالمحفظة. ستطلب بعض dApps من المستخدمين التوقيع والتحقق بعد الاتصال بالمحفظة للتأكد من أن المستخدم يحمل المفتاح الخاص حقا ، بدلا من مجرد تمرير WalletAddress إلى الواجهة الأمامية.

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

الفرق بين الوضعين ناتج عن التماثل وعدم التماثل. في بنية مستخدم الخادم ، يحمل كلا الطرفين نفس الأسرار. في بنية Blockchain-User ، يحتفظ المستخدم فقط بالأسرار.

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

نظرا للطبيعة غير المتماثلة للتشفير غير المتماثل وأزواج إثبات المعرفة الصفرية ، أتصور سيناريوهين محتملين:

• إذا كنت ترغب في استخدام نظام معرف كلمة المرور ، فيمكنك ترك وحدة تخزين كلمة المرور هذه خارج SCP ، بحيث لا يمكن لأي شخص آخر رؤيتها. لا تزال طبقة تنفيذ SCP تستخدم حسابات المفتاح العام والخاص ل Blockchain ومنطق التشغيل ، دون تسجيل أو تسجيل دخول ، إلخ. يتوافق معرف المستخدم فعليا مع مفتاح خاص. ** بالطبع ، لا يمكن الاحتفاظ بهذا المفتاح الخاص على جانب المشروع ، والحل الأكثر جدوى هو استخدام 2-3 MPC لحل مشكلة التخزين المركزي ، مع عدم السماح للمستخدمين باستخدام المفتاح الخاص. عند الاعتماد على تسجيل الدخول إلى OAuth ، يمكن استخدام JWT (Json Web Token) كوسيلة للمصادقة. ** ستكون هذه الطريقة أكثر مركزية قليلا مما سبق ، لأنها تحتاج بشكل أساسي إلى الاعتماد على خدمة تسجيل الدخول التابعة لجهة خارجية التي تقدمها الشركات المصنعة ل Web2 كمصادقة للهوية.

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

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

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

الخصوصية

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

الشحن

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

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

مقاومة الرقابة

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

** لا يوجد حاليا حل واضح لمشكلة مقاومة الرقابة، وهي مشكلة في نموذج الحزب الشيوعي المستدام. **

طبقة الإجماع

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

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

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

تمنح طبقة التنفيذ المستخدم نتيجة التأكيد المسبق والنهائي الناعم ، لأنه لم يتم تقديمه بعد إلى طبقة DA ؛

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

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

طبقة التسوية

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

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

** قد يتساءل المرء لماذا لا يستخدم SCP السلاسل ذات العقود الذكية كطبقة DA؟** هذا يمكن أن يجعل طبقة التسوية التي تعطي العقود وغير موثوق بها تماما.

على المدى الطويل ، طالما تم التغلب على بعض الصعوبات الفنية ، إذا تم وضع طبقة DA على طبقة DA بعقود مثل Ethereum ، ويمكن بناء العقد المقابل للتحقق ، يمكن أن تحصل SCP أيضا على نفس أمان التسوية مثل Rollup ، دون الحاجة إلى استخدام التوقيع المتعدد.

لكن من الناحية العملية ، هذا ليس بالضرورة هو الأمثل: **

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

2. إثبات أنه من الصعب جدا تطوير النظام ، لأن SCP لا يمكنها محاكاة EVM فحسب ، بل يمكنها أيضا تنفيذ أي منطق. ** بالنظر إلى حقيقة أن فرقا مثل Optimism لا تزال غير متصلة بالإنترنت للحصول على أدلة الاحتيال ، وصعوبة تطوير zkEVM ، يمكننا أن نتخيل أنه من الصعب للغاية تنفيذ إثباتات الأنظمة المختلفة على Ethereum.

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

** SCP ليس مخططا عاما لتوسيع نطاق السلسلة ، ولكنه بنية منصة حوسبة Web3 أكبر ، لذلك من الواضح أنه ليست هناك حاجة لاتباع فكرة Ethereum Layer 2. **

** رسم تخطيطي يقارن SCP بالنماذج الأخرى **