تفسير SCP: نموذج بنية تحتية غير موثوق به يخرج عن الصورة النمطية المجمعة

مكونات SCP الأساسية ومبادئ العمل

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

• طبقة توفر البيانات: تتكون من يمكن استخدام السلاسل العامة المعترف بها على نطاق واسع والتي تم اختبارها عبر الزمن كمسؤولية، أو يمكن استخدام مرافق التخزين كطبقة توفر البيانات، مثل Ethereum وArweave وCelestia وما إلى ذلك.

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

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

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

الإطار العملي لـ SCP

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

• استخدام طبقة DA لهذا المشروع تم تركيب منشأة التخزين الدائم Arweave وهي الدائرة الكبيرة في الصورة.

• المنسق، طبقة التنفيذ. يرسل المستخدم المعاملة إلى المنسق، ويقوم المنسق بتنفيذ العملية ويعرض نتائج العملية، ثم يرسل بيانات الإدخال الأصلية للمستخدم إلى طبقة DA على دفعات.

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

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

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

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

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

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

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

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

طبقة التنفيذ

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

بيئات التنفيذ الممكنة بشكل لا نهائي

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

< li>< p style = "text-align: left;">Exchange. استنادًا إلى SCP، يمكن بناء بورصة مفتوحة وشفافة وعالية TPS. ولا يمكن أن تتمتع هذه البورصة بخصائص سرعة CEX والتكلفة الصفرية فحسب، بل يمكنها أيضًا الحفاظ على لامركزية DEX. يصبح التمييز بين CEX وDEX غير واضح هنا.

• شبكة الدفع. على غرار Alipay وPayPal وما إلى ذلك.

• يدعم الآلة الافتراضية/سلسلة الكتل لتحميل البرامج/العقود. يمكن لأي مطور نشر أي تطبيق عليه ومشاركة جميع بيانات المستخدم مع البرامج الأخرى والعمل وفقًا لتعليمات المستخدم.

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

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

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

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

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

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

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

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

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

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

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

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

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

على الرغم من أن طبقة تنفيذ 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، إلا أن هذا غير مقبول في بعض التطبيقات، لذلك يمكن للمطورين أيضًا إنشاء أنظمة معاملات خاصة.

الشحن

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

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

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

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

لا يوجد حاليًا حل واضح لحل مشكلة مقاومة الرقابة، وهي مشكلة نموذج SCP.

طبقة الإجماع

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

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

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

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

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

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

طبقة التسوية

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

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

قد يتساءل شخص ما لماذا لا يستخدم SCP سلسلة ذات عقود ذكية كطبقة DA؟ يسمح هذا بطبقة تسوية قائمة على العقود وغير موثوقة تمامًا.

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

ولكن من الناحية العملية قد لا يكون هذا هو الخيار الأفضل:

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

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

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

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

صورة تقارن SCP مع النماذج الأخرى