تخزين نموذج الإجماع: الجيل القادم من بلوكتشين لا يجب أن يكون بلوكتشين

المصدر: Wuyue, Geek Web3

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

• < p>إنه يتمتع بسرعة مماثلة لتطبيقات أو تبادلات Web2 التقليدية، وهو ما يتجاوز بكثير أي سلسلة عامة، أو L2، أو سلسلة جانبية، أو سلسلة جانبية، وما إلى ذلك.

• لا توجد رسوم على الغاز وتكلفة الاستخدام 0.

• يعتبر مستوى أمان الأموال مرتفعًا، ويتجاوز بكثير مستوى أمان المرافق المركزية مثل البورصات، وهو أدنى من مستوى Rollup ولكنه يساوي السلاسل الجانبية.

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

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

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

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

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

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

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

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

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

everPay

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

الآن يمكننا أن نفهم نموذج إجماع التخزين بشكل كامل من خلال سير عمل EverPay.

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

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

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

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

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

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

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

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

طبقة التنفيذ

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

بيئات التنفيذ الممكنة بلا حدود

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

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

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

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

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

يمكنك أن ترى أن العملية المذكورة أعلاه تتضمن بالفعل مفاهيم مماثلة مثل المبادلة عبر السلسلة وتجريد الحساب. بالطبع، فهي متشابهة تمامًا. ونحن نفهمها فقط في سياق SCP. على وجه الخصوص، فإن مفاهيم مثل تجريد الحساب غير ضرورية بشكل طبيعي لـ SCP، وينبغي أن يقال أن هذا هو الأمتعة التي تركتها Ethereum. بعد عدة جولات من الجهود، أطلق مجتمع Ethereum أخيرًا معيار EIP-4337 لحل إحدى مشكلات اعتماد Web3 على نطاق واسع - مشكلة الحساب. علاوة على ذلك، يعد EIP-4337 مجرد معيار، ولم يتم بعد اختبار ممارسات تطبيقه. في إطار بنية SCP، لا يوجد مفهوم لتجريد الحساب - يمكنك استخدام حسابات Web2 القياسية وحسابات blockchain حسب الرغبة. من هذا المنظور، يمكن استخدام العديد من حالات استخدام Web2 الناضجة مباشرة على 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.

طبقة تأكيد الإجماع

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

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

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

طبقة التسوية

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

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

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

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

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

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

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

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

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

الملخص

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

SCP عبارة عن Web3 جديد تمامًا نموذج منصة الحوسبة مشابه لسرعة تطبيق معاملات Web2 التقليدية، وتكلفة المعاملة لا تذكر، ويمكن بناء تطبيقات محتملة لا حصر لها عليها، ويتوافق الأمان مع الحلول السائدة. في الوقت الحاضر، ظهر عدد من التطبيقات في إطار نموذج SCP، مثلeverPay وPermaSwap وMind Network وما إلى ذلك. واستنادًا إلى مفاهيم التصميم الممتازة الخاصة بها، فهي واعدة جدًا بالدخول في نمو هائل في هذا السوق الصاعد والسوق الصاعدة التالية.