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

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

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

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

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

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

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

Rollup المناسب

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

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

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

صلاحية

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

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

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

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

الوضع الحرج

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

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

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

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

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