مجلة بيتكوين: ما هي المصاعب التي تواجه تقنية الRollup؟

مصدر: مجلة بيتكوين. ترجمة: وو زو, مجلة الذهب المالية

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

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

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

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

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

Rollup المناسب

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

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

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

صلاحية

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

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

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

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

التراجع والتقدم المحير

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

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

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

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

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