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

مصدر: مجلة بيتكوين؛ ترجمة: ووزو، كينغ كينغ فاينانشيال

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

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

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

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

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

Rollup المناسب

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

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

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

صلاحية

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

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

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

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

ضيق الخيارات

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

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

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

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

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