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

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

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

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

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

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

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

Rollup المناسب

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

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

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

صلاحية

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

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

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

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

معضلة

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

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

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

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

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