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

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

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

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

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

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

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

Rollup المناسب

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

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

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

صالح حتى

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

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

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

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

دخول وخروج من الوادي

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

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

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

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

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