Bitcoin Magazine: ما هي التحديات التي تواجه Rollup؟

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

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

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

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

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

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

Rollup المناسب

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

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

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

صلاحية

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

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

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

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

معضلة

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

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

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

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

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