خلل في شبكة Liquid قد يفسّر فقدان نحو 320 مليون دولار من بيتكوين

توصل باحثون يحققون في حادثة شبكة Liquid التي تُقدَّر بنحو 320 مليون دولار إلى تفسير أكثر تحديداً لكيفية تمكّن مهاجم من استبدال رموز غير مدعومة ببيتكوين حقيقي، مرجّحين وجود خلل في "ذاكرة التخزين المؤقت" الخاصة بالتحقق من المعاملات داخل البرمجيات. وتشير روايات تقنية متداولة إلى أن المشكلة قد تكون مرتبطة بكيفية نشر نسخة من الكود. إذ قال Mononaut إن الثغرة المستغلة دخلت فرع التطوير الرئيسي لبرنامج Elements في الأسبوع السابق للحادثة، من دون أن تظهر في أي إصدار مُوسوم (tagged release). ووفقاً لحديثه، فإن مشغلي اتحاد Liquid (federation functionaries) شغّلوا ذلك الكود، بينما رفضت عقد أخرى المعاملات غير الصالحة. وحتى الآن، لم تؤكد Blockstream هذا السيناريو في التصريحات المتاحة. وفي حال ثبوت ذلك، سيصبح نشر البرمجيات محورياً لفهم حادثة جرى فيها تحرير بيتكوين عبر صلاحيات توقيع صحيحة، مقابل LBTC قيل إنه تم إنشاؤه بفعل خلل برمجي. تُعد Liquid سلسلة جانبية لبيتكوين، وتفترض آلية عملها أن تكون رموز LBTC مدعومة بنسبة 1:1 ببيتكوين تحتفظ به جهة الاتحاد. وبحسب ما أفادت به CryptoSlate سابقاً، قالت SideSwap إن عميلاً قدّم 4,000 LBTC عبر خدمة "pegout" بتاريخ 6 سبتمبر، ما أدى إلى تحرير نحو 3,996 BTC. وأكدت Liquid أن مفتاح تفويض "pegout" الخاص بـ SideSwap، وكذلك مفاتيح الاتحاد الأخرى، لم تتعرض للاختراق. وتركّز التفسيرات التقنية الناشئة على كيفية وصول الرموز إلى مسار السحب من الأساس. وشرح Calle ثغرة تتعلق بإثباتات النطاق (range proofs)، وهي آلية تتيح للعقد التحقق من أن مبالغ المعاملات المخفية تقع ضمن نطاق مسموح به من دون الكشف عن تلك المبالغ. وفي معاملات Liquid السرّية، لا يكفي التحقق من توازن المدخلات والمخرجات، لأن مخرجاً سلبياً مخفياً قد يعادل مخرجاً إيجابياً أكبر، فيبدو وكأن المعاملة متوازنة حسابياً رغم توليد رموز جديدة. الهدف من إثباتات النطاق هو منع هذا السيناريو. ونظراً لأن التحقق من هذه الإثباتات مكلف حسابياً، تحتفظ العقد بنتائج التحقق الناجح في ذاكرة مؤقتة لإعادة استخدامها. ووفقاً لرواية Calle، تمكن المهاجم من إنشاء مخرج وإثبات غير صالحين يتطابقان مع مفتاح ذاكرة التخزين المؤقت (cache key) المرتبط بتحقق صحيح سابق. وعند العثور على نتيجة مخزنة مطابقة، قد تتجاوز العقدة عملية التحقق التي كان ينبغي أن ترفض المخرج التضخمي. وأيد Charles Guillemet هذا التفسير، واصفاً الأمر بأنه تصادم مُصمَّم لمفتاح الذاكرة المؤقتة (cache-key collision) سمح لمعاملة سرّية غير صالحة بتجاوز فحص النطاق. في المقابل، نبه Calle إلى أن شرحه مُبسّط وقد يتضمن أخطاء. وفي إعادة بناء منفصلة للمعاملات، قال Stu إنه رصد معاملات تمهيدية تلتها معاملة يُعتقد أنها غير صالحة عند كتلة Liquid رقم 4,050,336. وذكر أن تلك المعاملة أنشأت نحو 3,996.0183 LBTC قبل تنفيذ السحب اللاحق عبر SideSwap. وتضيف رواية Mononaut تمييزاً بين العقد التي قبلت المعاملة وتلك التي رفضتها. إذ قال إن مشغلي الاتحاد قبلوا معاملات الاستغلال، ووافقوا على عمليات السحب، وواصلوا بناء الكتل. في المقابل، رفضت عقد أخرى، بما فيها العقد التي تشغّل مستكشف Liquid لدى mempool، الكتلة المتأثرة. وقد يفسر ذلك سبب غياب بعض المعاملات عن مستكشف يتبع عقداً رافضة، رغم ظهورها في أماكن أخرى. ويجعل هذا الانقسام من إصدار البرمجيات المستخدمة عاملاً حاسماً لفهم الإخفاق. وسيحتاج أي تقرير تشريحي (postmortem) إلى تحديد أي دوال برمجية كانت تعمل، ولماذا نُشرت تلك النسخة، وكيف اختلف سلوك التحقق فيها عن العقد التي رفضت الكتلة. وفي الوقت ذاته، وصف من يتحكمون بالبيتكوين المسحوب أنفسهم بأنهم "وايت هات"، وربطوا إعادة معظم الأموال بإصلاح الخلل عبر العقد المتأثرة. ولا تُظهر التغطيات المتاحة حتى الآن تأكيداً على اكتمال الإرجاع أو نشر التصحيح. وسيؤدي استرداد البيتكوين إلى معالجة عجز الاحتياطي، بينما سيساعد توضيح سبب قبول عقد الاتحاد للمعاملات، وإثبات أن البرمجيات المصححة ترفضها، على معالجة الخلل الذي سمح بخروج تلك الاحتياطيات.