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

مصدر: مجلة بيتكوين. ترجمة: وو زو، كينسي فاينانشال

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

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

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

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

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

Rollup المناسب

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

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

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

صلاحية

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

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

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

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

معضلة

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

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

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

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

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