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

مصدر: مجلة بيتكوين؛ ترجمة: وو زو، مجلة الذهب المالية

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

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

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

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

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

Rollup المناسب

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

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

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

صلاحية

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

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

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

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

الدخول والخروج من المأزق

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

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

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

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

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