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

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

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

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

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

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

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

Rollup المناسب

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

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

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

صلاحية

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

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

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

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

معضلة

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

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

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

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

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