مقدمة:

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

لنتصور حلاً لتوسيع سلسلة الكتل العامة بالخصائص التالية:

• لديها سرعات قابلة للمقارنة مع تطبيقات الويب التقليدية Web2 أو التبادلات، متفوقة بكثير على أي سلسلة كتل عامة، طبقة 2 (L2)، ال rollups، السلاسل الجانبية، إلخ.

• لا توجد رسوم للغاز، وتكلفة الاستخدام تقترب من الصفر تقريبًا.

• أمان مالي عالي، يتجاوز المرافق المركزية مثل التبادلات، أقل من Rollups ولكن أكبر من أو يساوي sidechains.

• تجربة مستخدم مطابقة لـ Web2، دون الحاجة إلى أي معرفة بالمفاتيح العامة والخاصة للبلوكشين، المحافظ، البنية التحتية، الخ.

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

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

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

بشكل عام، SCP، مثل “البلوكشين المعماري” المذكور من قبل مجتمعات إيثيريوم وسيليستيا، لديها وحدات متنوعة مثل طبقة توفر البيانات، وحدة التنفيذ، وحدة الاتفاق، وحدة التسوية.

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

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

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

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

إطار ممارسة SCP

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

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

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

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

طبقة التنفيذ

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

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

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

1. التبادلات. باستخدام SCP، يمكن للشخص بناء تبادل عام وشفاف بمعدلات عالية للمعاملات في الثانية (TPS)، مجمعًا بين ميزات التبادل المركزي (CEX) السريعة والخالية من التكلفة وفوائد تمويل التبادل المركزي ولامركزي (DEX). هنا، يصبح الفارق بين CEX و DEX غامضًا.

2. شبكات الدفع. مشابهة للأليباي، باي بال، الخ.

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

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

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

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

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

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

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

دعونا نستعرض نظام تفاعل مستخدم بلوكشين Web3 النموذجي:

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

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

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

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

• إذا كان نظام تسجيل الدخول بالمعرف وكلمة المرور مرغوبًا فيه، يمكن استبعاد وحدة حفظ كلمة المرور من SCP، مما يجعلها غير مرئية للآخرين. داخليًا، يستخدم طبقة تنفيذ SCP لا زالت حسابات المفتاح العام الخاص بالبلوكشين والمنطق العملي، دون تسجيل أو تسجيل الدخول. ينبغي أن يتوافق معرف المستخدم في الواقع مع مفتاح خاص. ينبغي عدم تخزين هذا المفتاح الخاص من قبل جانب المشروع بالطبع. الحل القابل للتطبيق هو استخدام 2-3 MPC (الحساب المتعدد الأطراف) لحل مشكلة التخزين المركزي دون تحميل المستخدم بالاستخدام المفتاح الخاص.
• عند الاعتماد على تسجيل الدخول OAuth، يمكن استخدام JWT (رمز الويب الJSON) كوسيلة للمصادقة على الهوية. هذه الطريقة أكثر تمركزا قليلا من السابق، حيث تعتمد في الأساس على خدمات تسجيل الدخول من طرف ثالث المقدمة من قبل عمالقة الويب2 للتحقق من الهوية.
• في المرة الأولى التي يتم فيها استخدام تسجيل الدخول من جهة ثالثة، يتم تسجيل حقول JWT التي تمثل هويات المستخدم ومزود الخدمة في النظام. في العمليات اللاحقة للمستخدم، يُعامل أمر العملية كإدخال عام، بينما يُعتبر JWT ككل شاهدًا سريًا، باستخدام ZKP (إثبات الصفر المعرف) للتحقق من كل من معاملات المستخدم.
• كل JWT لديه حد انتهاء صلاحية، وسيطلب المستخدمون JWT جديدًا في المرة القادمة التي يقومون فيها بتسجيل الدخول، لذلك لا حاجة للتخزين الدائم. بالإضافة إلى ذلك، يعتمد هذا النظام على JWK (مفتاح الويب JSON)، والذي يمكن فهمه على أنه المفتاح العام الذي توفره العمالقة للتحقق من JWK. من الجدير أيضًا استكشاف كيف يتم إدخال JWK بشكل لامركزي إلى النظام وطرق تدوير المفتاح الخاص في المستقبل.

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

قضايا الخصوصية

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

رسوم

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

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

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

طبقة الاتفاق

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

طبقة التسوية

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

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

في الممارسة، قد لا يكون هذا الاختيار الأفضل:

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

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

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

تقارن الرسم التوضيحي بين SC بالأنماط الأخرى

إخلاء المسؤولية:

1. تم نقل هذه المقالة من [ جيك ويب3]. جميع حقوق الطبع والنشر تنتمي إلى الكاتب الأصلي [雾月، جيك ويب3إذا كانت هناك اعتراضات على هذه الإعادة، يرجى الاتصال بالبوابة تعلمفريق، وسيتولون بذلك بسرعة.
2. إخلاء المسؤولية عن المسؤولية: الآراء والآراء المعبر عنها في هذه المقالة هي فقط تلك التي تنتمي إلى الكاتب ولا تشكل أي نصيحة استثمارية.
3. يتم إجراء ترجمات المقالة إلى لغات أخرى من قبل فريق Gate Learn. ما لم يذكر غير ذلك، فإن نسخ أو توزيع أو سرقة المقالات المترجمة محظورة.