#xrpledgerpatchesxrpcreationbug
قلّما توجد أمور أهمّ من المعروض نفسه بالنسبة إلى أصل ذي معروض ثابت. لذلك لفتت ثغرة كُشف عنها حديثًا في XRP Ledger الأنظار هذا الأسبوع، إذ كان من الممكن أن تسمح بإنشاء XRP من دون تصريح، رغم أن الإصلاح متاح منذ أسابيع.
إليك التسلسل الزمني، بحسب ما ورد:
• التقرير: في 22 سبتمبر، أبلغ الباحثان كايدن لياو وVeria AI عن المشكلة عبر برنامج مكافآت اكتشاف الثغرات في XRPL. وتمكّنت RippleX من إعادة إنتاجها على خادم اختبار مستقل، وأكدت إمكانية إنفاق XRP المُنشأ. • الخلل: تجاوز سعة عدد صحيح في محرك المدفوعات. فإذا استهلكت دفعة واحدة عددًا كافيًا من عروض دفتر الأوامر، فقد تلتف نتيجة إحدى العمليات الحسابية لتصبح رقمًا أصغر بكثير، ما يؤدي إلى حصول البائعين على كامل المبلغ المستحق لهم، في حين يدفع المشتري مبلغًا أقل بكثير. وقد يتحول الفرق إلى XRP جديد. ويبدو أن الخلل يعود إلى عام 2015. • الإصلاح: صدر الإصدار xrpld 3.4.1 في 25 سبتمبر، مضيفًا عمليات تحقق من تجاوز السعة وعدادًا أوسع نطاقًا لتعزيز الأمان. وطُرح كتحديث طارئ من دون تصويت مدققي المعاملات على التعديل، وهو التصويت المعتاد، تجنبًا لترك الخلل مكشوفًا خلال فترة تصويت علنية. وتقول RippleX إن أكثر من 80% من مدققي UNL الافتراضيين كانوا يستخدمون الإصدار المُحدّث أو إصدارًا أحدث بحلول ذلك اليوم. • الكشف: نُشرت التفاصيل في 9 أكتوبر. وتفيد RippleX بعدم وجود أدلة على استغلال الثغرة. كما أُصلح خلل آخر أقل خطورة يؤثر في ميزة Batch، ولم يكن نشطًا على الشبكة الرئيسية عند اكتشافه.
لماذا يكتسب الأمر أهمية: يختلف خلل إصدار العملات عن خلل السرقة، لأنه يمس سلامة المعروض مباشرةً. وكان استغلاله سيتطلب إعدادًا محكمًا يضم مئات العروض وبضع مئات من XRP كاحتياطيات، وهو ما قد يساعد في تفسير عدم ملاحظته. وتُظهر هذه الواقعة أيضًا جانبين من العملية: برنامج مكافآت اكتشاف الثغرات يعمل كما ينبغي، والمفاضلة بين سرعة تطبيق التصحيح والطريقة اللامركزية القائمة على التصويت التي تُجري الشبكة تغييراتها بها عادةً.
عندما يتعين إصدار إصلاح حاسم قبل أن يتمكن المجتمع من التصويت عليه، كيف ينبغي للشبكات الموازنة بين السرعة والشفافية والإجماع؟
