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