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

مصدر: مجلة بيتكوين؛ ترجمة: وو تشو، مجلة جينسن

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

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

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

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

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

تراكم مناسب

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

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

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

صلاحية

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

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

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

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

إرباك و حيرة

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

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

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

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

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