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

المصدر: مجلة بيتكوين. تجميع: خمسة باهت ، التمويل الذهبي

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

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

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

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

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

Rollup المناسب

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

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

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

الصلاحية

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

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

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

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

تقاعس وتعقيد

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

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

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

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

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