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

مصدر: مجلة بيتكوين. ترجمة: وو زو، Jinse Finance

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

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

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

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

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

Rollup المناسب

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

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

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

صلاحية

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

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

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

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

تقدم وانسحاب

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

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

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

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

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