أصبحت حلول Rollups محور الحديث في تحسين آلية توسيع نطاق البيتكوين مؤخراً، حيث تمكنت من سرقة الأضواء من شبكة Lightning فيما يتعلق بانتشار الفهم والتبني الأوسع. تهدف حلول Rollups إلى أن تكون طبقة ثانية خارج السلسلة ولا تعاني من قيود السيولة التي تعد مركزية في شبكة Lightning، أي أن المستخدمين النهائيين بحاجة إلى تخصيص (أو “إقراض”) أموال مسبقًا ليتمكنوا من استلام الأموال، أو أن قنوات التوجيه الوسيطة بحاجة إلى أرصدة قنوات لتسهيل حركة المبالغ المالية من المرسل إلى المستلم.
الأصل والتطور
تم تطوير هذه الأنظمة في الأصل للعمل على شبكة Ethereum وأنظمة أخرى كاملة تورينج، ولكن في الآونة الأخيرة تحولت الأنظار إلى نقلها إلى سلاسل الكتل المستندة إلى UTXO مثل البيتكوين. لن نتطرق في هذا المقال إلى حالة التنفيذ الحالية على البيتكوين، بل سنناقش كيفية عمل حلول Rollups المثالية التي يسعى الناس للوصول إليها على المدى الطويل بناءً على الميزات التي لا يدعمها البيتكوين حاليًا، وهي القدرة على التحقق من البراهين المعرفية الصفرية (ZKPs) على شبكته مباشرة.
هيكلية Rollups الأساسية
الهيكلية الأساسية لحل Rollup هي كالتالي: حساب واحد (أو في حالة البيتكوين UTXO) يحتوي على أرصدة جميع المستخدمين في رول آب. يحتوي هذا UTXO على التزام بشكل جذر ميركل لشجرة ميركل التي تلتزم بجميع أرصدة الحسابات الحالية في الرول آب. يتم تفويض جميع هذه الحسابات باستخدام أزواج من المفاتيح العامة/الخاصة، لذا لكي يقترح المستخدم عملية إنفاق خارج السلسلة، لا يزال بحاجة إلى توقيع شيء باستخدام مفتاح. يتيح هذا الجزء من الهيكلية للمستخدمين الخروج بحرية ودون إذن في أي وقت، ببساطة عن طريق إنشاء معاملة تثبت أن حسابهم جزء من شجرة ميركل، يمكنهم الخروج من الرول آب من دون إذن المشغل.
يتوجب على مشغل الرول آب تضمين ZKP في المعاملات التي تحدث جذر ميركل لأرصدة الحسابات على السلسلة في عملية إنهاء المعاملات خارج السلسلة، دون هذا ZKP ستكون المعاملة غير صحيحة وبالتالي لا يمكن تضمينها في سلسلة الكتل. يتيح هذا الإثبات للأشخاص التحقق من أن جميع التغييرات في الحسابات خارج السلسلة حصلت بتفويض من أصحاب الحسابات، وأن المشغل لم يقم بتحديث خبيث للأرصدة لسرقة الأموال من المستخدمين أو إعادة تخصيصها بشكل غير نزيه لمستخدمين آخرين.
المشكلة والتحديات
المشكلة هي، إذا تم نشر جذر شجرة ميركل فقط على السلسلة حيث يمكن للمستخدمين عرضه والوصول إليه، كيف يمكنهم الحصول على فرعهم في الشجرة ليتمكنوا من الخروج دون إذن عندما يريدون؟
حلول Rollups الكاملة
في حل رول آب كامل، يتم وضع المعلومات مباشرة في سلسلة الكتل كلما تأكدت معاملات جديدة خارج السلسلة وتغيرت حالة حسابات الرول آب. ليس الشجرة بأكملها، فذلك سيكون غير عملي، بل المعلومات الضرورية لإعادة بناء الشجرة. في تنفيذ بسيط، سيتم إضافة ملخص جميع الحسابات الموجودة في الرول آب بأرصدة وحسابات ببساطة في المعاملة التي تحدث الرول آب.
في تنفيذات أكثر تطورًا، يتم استخدام فرق الرصيد. هذا عبارة عن ملخص لما تم إضافة أموال أو خصمها من الحسابات خلال عملية التحديث. يمكن أن تتضمن كل تحديث للرول آب التغييرات فقط في أرصدة الحسابات التي حدثت. يمكن للمستخدمين عندئذٍ ببساطة مسح السلسلة و”إجراء الحسابات” من بداية الرول آب للوصول إلى الحالة الحالية لأرصدة الحسابات، مما يسمح لهم بإعادة بناء شجرة ميركل للأرصدة الحالية.
يوفر هذا كثيراً من النفقات والمساحة على الكتل (وبالتالي المال) مع السماح للمستخدمين بضمان الوصول إلى المعلومات اللازمة للخروج بإرادة منفردة. يتطلب إدراج هذه البيانات في رول آب رسمي يستخدم سلسلة الكتل لإتاحتها للمستخدمين وفقًا لقواعد الرول آب، أي أن المعاملة التي لا تتضمن ملخص الحساب أو فرق الحساب تعتبر معاملة غير صحيحة.
Validiums
الطريقة الأخرى للتعامل مع مشكلة توفر البيانات لانسحاب المستخدمين هي وضع البيانات في مكان آخر غير سلسلة الكتل. هذا يقدم قضايا معقدة، حيث لا يزال الرول آب بحاجة إلى فرض أن البيانات قد تم إتاحتها في مكان آخر. تقليديًا، تستخدم سلاسل الكتل الأخرى لهذا الغرض، خاصة المصممة لتعمل كطبقات توفر البيانات لأنظمة مثل الرول آب.
هذا يخلق معضلة بشأن ضمانات الأمان. عندما يتم نشر البيانات مباشرة على سلسلة الكتل البيتكوين، يمكن لقواعد الإجماع ضمان صحتها بشكل مطلق. ومع ذلك، عندما يتم نشرها على نظام خارجي، سيكون أقصى ما يمكن فعله هو التحقق من إثبات SPV بأن البيانات قد نشرت على نظام آخر.
هذا يتطلب التحقق من تأكيد أن البيانات موجودة على سلاسل أخرى، مما يعد في النهاية مشكلة أوراكل. سلسلة كتل البيتكوين لا يمكنها التحقق من أي شيء بشكل كامل إلا ما يحدث على سلسلتها الخاصة، وأقصى ما يمكنها هو التحقق من ZKP. لكن ZKP لا يمكنه التحقق من أن كتلة تحتوي على بيانات رول آب قد بُثت علنًا بعد إنشائها. لا يمكنه التحقق من أن المعلومات الخارجية متاحة للجميع بالفعل.
هذا يفتح الباب للهجمات التي تعتمد على حجب البيانات، حيث يتم إنشاء التزام بنشر البيانات ويستخدم لتقدم الرول آب، لكن البيانات لا تُتاح فعلاً. يؤدي هذا إلى منع المستخدمين من سحب أموالهم. الحل الحقيقي الوحيد لهذه المشكلة هو الاعتماد تمامًا على قيمة وهيكل الحوافز للأنظمة الخارجية ذاتيًا عن البيتكوين.
الصخرة والمكان الصعب
هذا يخلق معضلة فيما يتعلق بحلول الرول آب. عندما يتعلق الأمر بمسألة توفر البيانات، يوجد اختيار بديهي بين نشر البيانات على سلسلة كتل البيتكوين أو في مكان آخر. لهذا الخيار تداعيات ضخمة على أمان الرول آب وسيادته، وكذلك قابليته للتوسع.
من جهة، استخدام سلسلة كتل البيتكوين كطبقة توفر البيانات يفرض سقفًا صارمًا على مدى قابلية الرول آب للتوسع. هناك حد لمساحة الكتل، مما يضع حداً أعلى لعدد حلول الرول آب الممكن وجودها في وقت واحد وعدد المعاملات التي يمكن لجميع حلول الرول آب معالجتها خارج السلسلة بشكل مجمع. كل تحديث للرول آب يتطلب مساحة كتل تتناسب مع عدد الحسابات التي تغيرت أرصدتها منذ التحديث الأخير. تتيح نظرية المعلومات ضغط البيانات إلى حد معين فقط، وعند هذا النقطة لا يوجد المزيد من الإمكانيات لتحقيق مكاسب في التوسع.
من جهة أخرى، استخدام طبقة مختلفة لتوفر البيانات يزيل السقف الصارم لمكاسب التوسع، لكنه أيضًا يقدم قضايا جديدة تتعلق بالأمان والسيادة. في حل رول آب يستخدم البيتكوين لتوفير البيانات، من غير الممكن فعليًا تغيير حالة الرول آب دون إتاحة البيانات اللازمة للمستخدمين لسحب أموالهم بشكل تام على سلسلة الكتل. مع Validiums، يعتمد هذا الضمان بالكامل على قدرة النظام الخارجي المستخدم على مقاومة التلاعب وحجب البيانات.
أي منتج للكتل في نظام توفير البيانات الخارجي يمكنه الآن احتجاز أموال مستخدمي رول آب البيتكوين بإنتاج كتلة وعدم بثها فعليًا لإتاحة البيانات.
إذن، أي الخيارين سيكون الأفضل إذا وصلنا يومًا إلى تنفيذ رول آب مثالي على البيتكوين يمكن المستخدمين من السحب بحرية؟ الصخرة، أم المكان الصعب؟
