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

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

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

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

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

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

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

Rollup المناسب

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

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

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

صلاحية

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

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

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

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

الدخول والخروج من الوضع الصعب

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

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

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

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

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