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

المصدر: مجلة Bitcoin؛ تم إعداده بواسطة: Five Baht, Golden Finance

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

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

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

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

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

التراكمي المناسب

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

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

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

الصلاحية

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

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

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

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

معضلة

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

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

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

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

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