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

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

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

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

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

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

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

اللف المناسب

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

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

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

صلاحية

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

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

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

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

معضلة

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

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

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

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

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