مجلة بيتكوين: ما هي التحديات التي تواجه Rollup؟

المصدر: مجلة بيتكوين ؛ الترجمة: Wu Zhu و Jinse Finance

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

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

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

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

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

Rollup المناسب

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

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

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

صلاحية

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

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

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

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

معضلة

هذا يواجه rollup مأزقًا. عندما يتعلق الأمر بمشكلة توافر البيانات، توجد في الأساس اختيار ثنائي بين نشر البيانات على سلسلة كتل بيتكوين أو في مكان آخر. هذا الاختيار له تأثير كبير على أمان rollup وسيادته وقابليته للتوسع.

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

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

الآن يمكن لأي منتج للكتلة على نظام توفر البيانات الخارجية أن يختطف أموال مستخدمي BTCRollup من خلال إنتاج كتلة بدلاً من بث كتلة فعلية، مما يجعل البيانات متاحة.

لذا، إذا نجحنا حقًا في تحقيق تنفيذ Rollup المثالي على BTC، وتحقيق سحب المستخدمين من جهة واحدة فعليًا، فماذا سيحدث؟