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