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

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

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

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

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

يجب أن يتضمن مشغل Rollup ZKP في المعاملات لتحديث جذر merkle لرصيد الحساب داخل السلسلة أثناء إكمال عمليات التداول خارج السلسلة، وإذا كان هذا ال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 الذي يستخدم BTC لتحقيق توافر البيانات، إذا لم يتم نشر البيانات التي يحتاجها المستخدم تلقائيًا على سلسلة الكتل، فإن حالة Rollup لن تتغير. باستخدام Validiums، يتوقف هذا الضمان تمامًا على قدرة النظام الخارجي المستخدم على مقاومة الغش وإخفاء البيانات.

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

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