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

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

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

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

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

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

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

Rollup المناسب

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

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

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

صلاحية

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

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

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

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

تقدم وتراجع

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

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

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

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

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