كيف يمكن الخروج من عقلية التراكم ودمج منصة Web2 مع Web3 بإطار عمل أوسع وأكثر انفتاحًا؟
** بقلم Wuyue، Geek Web3 **
**مقدمة: **ستقدم هذه المقالة بشكل مستقبلي نموذج تصميم البنية التحتية لـ Web3 الذي يبدو فريدًا بعض الشيء - نموذج التوافق القائم على التخزين (SCP). على الرغم من أن نموذج تصميم المنتج هذا من الناحية النظرية، فهو مختلف تمامًا عن النموذج المعياري السائد حلول blockchain مثل Ethereum Rollup، ولكنها مجدية جدًا من حيث سهولة التنفيذ وسهولة الاتصال بمنصة Web2، لأنها منذ البداية لم أكن أنوي أن أقتصر على مسار تنفيذ ضيق مثل Rollup. أراد استخدام إطار عمل أوسع وأكثر انفتاحًا ** لدمج منصة Web2 ومرافق Web3 **، والذي يمكن القول إنه عقل وهو نهج خيالي مفتوح على مصراعيه.
النص: دعونا نتخيل حلاً لتوسيع السلسلة العامة بالخصائص التالية:
- يتمتع بسرعة مماثلة لتطبيقات أو تبادلات Web2 التقليدية، وهو ما يتجاوز بكثير أي سلسلة عامة، أو L2، أو سلسلة جانبية، أو سلسلة جانبية، وما إلى ذلك.
- لا توجد رسوم على الغاز، وتكلفة الاستخدام تقارب 0.
- أمان الأموال مرتفع، ويتجاوز بكثير أمان المرافق المركزية مثل البورصات، وهو أدنى من Rollup ولكنه أكبر من أو يساوي السلاسل الجانبية.
- نفس تجربة المستخدم مثل Web2، دون أي معرفة بالمفاتيح العامة والخاصة، والمحافظ، والبنية التحتية، وما إلى ذلك الخاصة بـ blockchain.
إن مثل هذا الحل مثير للغاية بالفعل: فمن ناحية، حقق بشكل أساسي الحد الأقصى في توسيع السعة؛ ومن ناحية أخرى، فقد أرسى أيضًا أساسًا متينًا للغاية للتبني الشامل لـ Web3، مما أدى بشكل أساسي إلى إزالة الفجوة بين Web2 وWeb3 تجربة الاستخدام.
ومع ذلك، يبدو أننا لا نستطيع أن نتخيل عدد الحلول التي يمكن أن تكون كاملة إلى هذا الحد، لأن هناك بالفعل القليل جدًا من المناقشات والممارسات السائدة.
لقد استخدمنا التوسع، وهو موضوع مألوف جدًا، كمقدمة أعلاه. في الواقع، لا يقتصر SCP على التوسع. يأتي إلهام تصميمه من خطط التوسع والمناقشات المجتمعية للسلاسل العامة مثل Bitcoin و Ethereum. وتتمثل رؤيتها وتطبيقها العملي في بناء جيل جديد من البنية التحتية غير الموثوقة، حتى منصة حوسبة غير معتمدة على تقنية البلوكشين. **
المكونات الأساسية ومبادئ العمل لـSCP
بشكل عام، **SCP يشبه أيضًا ما تسميه مجتمعات Ethereum وCelestia “البلوكشين المعياري”. ** يحتوي على أقسام نمطية مثل طبقة توفر البيانات، وطبقة التنفيذ، وطبقة الإجماع، وطبقة التسوية.
- طبقة توفر البيانات: تفترضها سلسلة عامة أو مرافق تخزين معروفة ومثبتة على نطاق واسع كطبقة توفر البيانات، مثل Ethereum وArweave وCelestia وما إلى ذلك.
- طبقة التنفيذ: خادم يُستخدم لتلقي معاملات المستخدم وتنفيذها، وفي الوقت نفسه يرسل بيانات المعاملات الموقعة من قبل المستخدم إلى طبقة DA على دفعات، على غرار مُسلسل مجموعة Rollup. لكن طبقة التنفيذ لا تحتوي بالضرورة على بنية قائمة مرتبطة على غرار blockchain، يمكن أن تكون قاعدة بيانات Web2 بالكامل + نظام حوسبة، ولكن يجب أن يكون نظام الحوسبة بأكمله مفتوح المصدر وشفافًا.
- طبقة الإجماع: وتتكون من مجموعة من العقد، تقوم بسحب البيانات المرسلة من طبقة التنفيذ إلى طبقة DA، وتستخدم نفس الخوارزمية مثل طبقة التنفيذ للعمل على هذه البيانات لتأكيد ما إذا كانت النتيجة أم لا إخراج طبقة التنفيذ صحيح، ويمكن استخدامه كتكرار للوقاية من الكوارث لطبقة التنفيذ. يمكن للمستخدمين أيضًا قراءة البيانات التي يتم إرجاعها بواسطة كل عقدة في طبقة الإجماع للتأكد من عدم وجود احتيال في طبقة التنفيذ.
- طبقة التسوية: وتتكون من مجموعة من العقد والعقود أو العناوين على سلاسل أخرى، وتستخدم للتعامل مع سلوك المستخدمين الذين يقومون بإعادة الشحن إلى SCP أو سحب الأموال من SCP، وهو يشبه إلى حد ما وضع التشغيل من جسر عبر السلسلة. تتحكم عقدة طبقة التسوية في وظيفة السحب لعنوان إعادة الشحن من خلال عقود التوقيع المتعدد أو العناوين المستندة إلى TSS. عند إعادة الشحن، يقوم المستخدم بإيداع الأصول في العنوان المحدد على السلسلة، وعند السحب، يتم إرسال طلب، وبعد أن تقرأ عقدة طبقة التسوية البيانات، تقوم بتحرير الأصول من خلال التوقيع المتعدد أو TSS. يعتمد مستوى الأمان لطبقة التسوية على الآلية عبر السلسلة المعتمدة.
إطار ممارسة SCP
يمكننا أن نفهم نموذج SCP من خلال الإطار التالي. يمكن أن يكون للمنتج الذي يلبي إطار عمل SCP وظائف رئيسية مثل إعادة الشحن والتحويل والسحب والمبادلة وما إلى ذلك، ويمكن توسيعه بشكل أكبر على هذا الأساس. الصورة أدناه عبارة عن رسم تخطيطي لهذا المنتج:
- تستخدم طبقة DA للمشروع منشأة التخزين الدائمة Arweave، الدائرة الكبيرة في الصورة.
- **منسق طبقة التنفيذ. ** يرسل المستخدم المعاملة إلى المنسق، ويقوم المنسق بتنفيذ العملية ويعرض نتائج العملية، ثم يرسل بيانات الإدخال الأصلية للمستخدم إلى طبقة DA على دفعات.
- الكاشف يسحب بيانات المعاملة الأصلية المقدمة من المنسق من Arweave، ويستخدم الخوارزمية المتوافقة مع المنسق للتحقق من البيانات والنتائج. كما أن عميل الكاشف مفتوح المصدر ويمكن لأي شخص تشغيله.
- ** الحراس، مجموعة من المختبرين المسؤولين عن التوقيع المتعدد لنظام السحب. **سيتم التحقق من طلبات السحب وإصدارها بناءً على بيانات المعاملة. وبالإضافة إلى ذلك، فإن الحارس مسؤول أيضًا عن التوقيع على الاقتراح.
"يمكننا أن نرى النظام بأكمله، والإجماع الذي توصلوا إليه يقع خارج السلسلة. هذا هو جوهر نموذج إجماع التخزين - فهو يتخلى عن نظام إجماع العقد على غرار blockchain ويحرر طبقة التنفيذ من الإجماع الثقيل. تتطلب عملية التأكيد عمل خادم واحد فقط، وبالتالي تحقيق عدد غير محدود تقريبًا من عدد TPS والاقتصاد. وهذا مشابه جدًا لـ Rollup، لكن SCP اتخذ مسارًا مختلفًا عن Rollup، حيث حوله من حالة استخدام مخصصة لتوسيع السعة إلى نموذج انتقال جديد من Web2 إلى Web3. **
المنسق المذكور أعلاه هو خادم، ولكن هذا لا يعني أن المنسق يستطيع أن يفعل ما يريد. على غرار فارز Rollup، بعد إرسال البيانات الأصلية المقدمة من قبل المستخدمين على دفعات على Arweave، يمكن لأي شخص تشغيل برنامج الكاشف للتحقق منها ومقارنتها بالحالة التي أرجعها المنسق. **إلى حد ما، هذه هي نفس فكرة تطبيقات النقش تمامًا. **
في ظل هذه البنية، لا يشكل الخادم المركزي وقاعدة البيانات تحديًا أساسيًا. هذه أيضًا نقطة أخرى في نموذج SCP، الذي يربط ويفصل بين مفهومي “المركزية” و"الكيان الفردي" - ** في نظام غير موثوق به، يمكن أن تكون هناك مكونات مركزية، ** يمكن أن تكون حتى مكونات أساسية، ولكن هذا لا يؤثر على انعدام الثقة بشكل عام.
يمكننا أن نصرخ بمثل هذا الشعار - “الجيل القادم من البنية التحتية غير الموثوقة لا يحتاج إلى الاعتماد على بروتوكولات الإجماع، ولكن يجب أن تكون أنظمة مفتوحة المصدر وشبكات عقد P2P”.
إن الهدف الأصلي للأشخاص الذين يخترعون ويستخدمون تقنية blockchain هو عدم الثقة في دفاتر الأستاذ المتسقة والأساسيات غير القابلة للتزوير والتتبع وغيرها من الأساسيات الشائعة، والتي تم ذكرها بوضوح في الورقة البيضاء الخاصة بالبيتكوين. ** ولكن بعد Ethereum، ** سواء كانت خطة التوسع للسلسلة العامة القديمة، أو Rollup أو blockchain المعيارية، ** لقد شكل الجميع عقلية: ما نصنعه يجب أن يكون blockchain ** ( وهو يتكون من بروتوكول الإجماع العقد)، أو حل مثل Rollup الذي يشبه السلسلة (يحتوي فقط على بنية بيانات blockchain، لكن العقد لا تتبادل رسائل الإجماع مباشرة).
ولكن الآن، في ظل الإطار القائم على SCP، حتى لو لم يكن blockchain، يمكن تحقيق سلسلة من المتطلبات مثل انعدام الثقة، واتساق دفتر الأستاذ، وعدم التزوير، وإمكانية التتبع، وما إلى ذلك. وبطبيعة الحال، الفرضية هي أنه يجب أن يكون هناك أن تكون تفاصيل التنفيذ أكثر وضوحا.
طبقة التنفيذ
تعد طبقة التنفيذ أمرًا بالغ الأهمية في النظام بأكمله، فهي تتولى عملية الحوسبة للنظام بأكمله وتحدد التطبيقات التي يمكن تشغيلها على النظام.
** بيئات التنفيذ الممكنة التي لا نهاية لها **
من الناحية النظرية، يمكن تحويل بيئة التنفيذ في طبقة التنفيذ إلى أي شكل، والاحتمالات لا حصر لها، اعتمادًا على كيفية وضع طرف المشروع لمشروعه:
*تبادل. استنادًا إلى SCP، يمكن بناء بورصة مفتوحة وشفافة وعالية TPS. ولا يمكن أن تتمتع هذه البورصة بخصائص سرعة CEX والتكلفة الصفرية فحسب، بل يمكنها أيضًا الحفاظ على لامركزية DEX. يصبح التمييز بين CEX وDEX غير واضح هنا.
- شبكة الدفع. على غرار Alipay وPayPal وما إلى ذلك.
- دعم الآلة الافتراضية/سلسلة الكتل لتحميل البرامج/العقود. يمكن لأي مطور نشر أي تطبيق عليه ومشاركة جميع بيانات المستخدم مع البرامج الأخرى والعمل وفقًا لتعليمات المستخدم.
**SCP، وهو نموذج تصميم يدعم بيئات التنفيذ العشوائية، له فوائده الفريدة: **لم تعد بحاجة إلى الاعتماد على مكونات معينة ذات أمتعة تاريخية، وخاصة مفهوم “تجريد الحساب” الفريد لمجتمع Ethereum، وهو أمر مهم للغاية إلى SCP ويقال أنه ليس ضروريا بطبيعته.
في إطار بنية SCP، لا يوجد مفهوم لتجريد الحساب - يمكنك استخدام حسابات Web2 القياسية وحسابات blockchain حسب الرغبة. من هذا المنظور، يمكن استخدام العديد من حالات استخدام Web2 الناضجة مباشرة على SCP دون إعادة التفكير والبناء. قد يكون هذا هو فائدة SCP مقارنة بـ Rollup. **
** الشفافية وعدم التماثل **
لقد تم ذكر نظام الحساب أعلاه، وكان ينبغي للقراء الحساسين أن يكتشفوا أنه على الرغم من قدرة 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. لا حاجة لاستخدام توقيعات متعددة.
ولكن من الناحية العملية قد لا يكون هذا هو الخيار الأفضل:
- لا يتم استخدام الإيثريوم خصيصًا لتخزين البيانات، كما أن سعره مرتفع جدًا مقارنة بسلسلة عامة لتخزين البيانات فقط. **بالنسبة لنموذج SCP، تعد تكاليف التخزين المنخفضة أو الثابتة بدرجة كافية أمرًا بالغ الأهمية. **بهذه الطريقة فقط يمكن دعم الإنتاجية على مستوى Web2.
2.** يثبت أن تطوير النظام صعب للغاية، لأن SCP لا يمكنه محاكاة EVM فحسب، بل يمكنه أيضًا تنفيذ أي منطق. ** وعندما ننظر إلى فرق مثل Optimism، التي لا يزال دليل احتيالها غير متصل بالإنترنت، ومدى صعوبة تطوير zkEVM، يمكننا أن نتخيل أنه من الصعب للغاية تنفيذ إثبات الأنظمة المختلفة على Ethereum.thing.
لذلك، **يعد Rollup حلاً له جدوى عملية أفضل فقط في ظل ظروف محددة. **إذا كنت تخطط لتنفيذ حل أوسع وأكثر انفتاحًا، فتخلص من نظام EVM ودمج المزيد من ميزات Web2، ثم Ethernet فكرة فانغ التراكمي غير مناسب.
**SCP ليست خطة معينة لتوسيع سلسلة عامة، ولكنها بنية أكبر لمنصة حوسبة Web3، لذلك من الواضح أنه ليس من الضروري اتباع فكرة الطبقة الثانية من Ethereum. **
صورة تقارن SCP والنماذج الأخرى
