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

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

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

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

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

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

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

Rollup المناسب

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

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

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

الصلاحية

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

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

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

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

الذهاب والعودة

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

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

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

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

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