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

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

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

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

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

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

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

Rollup المناسب

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

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

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

صلاحية

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

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

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

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

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

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

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

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

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

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