يفعّل XRP Ledger تصحيحًا يسد ثغرة تتيح سكّ الرموز — XRP بأمان فعّل XRP Ledger تعديلًا برمجيًا يغلق ثغرة كان من الممكن، في ظل ظروف معينة، أن تسمح للحسابات التي تملك صلاحية الحرق فقط بإنشاء رموز مُصدرة. دخل الإصلاح، المسمى fixCleanup3_4_0، حيز التنفيذ في 4 نوفمبر عند الساعة 14:52 بالتوقيت العالمي، على السجل 108,112,129، وفقًا لمتتبع التعديلات XRPLWin. ما طبيعة الخلل؟ - تعلّق الخلل بنظام تفويض الصلاحيات في السجل، وبصلاحية مفوضة تسمى PaymentBurn. تتيح PaymentBurn لحساب معتمد إتلاف رموز أصدرها حساب آخر (وهو نمط شائع لدى خدمات الدفع التي تسترد العملات المستقرة). - بموجب القواعد السابقة، كان من الممكن لحساب يملك صلاحية PaymentBurn فقط، في بعض الحالات النادرة التي تتجاوز فيها عملية الدفع حدّ الرصيد الصفري، أن ينتهي به الأمر إلى إنشاء رموز مُصدرة بدلًا من حرقها فحسب. - كان من الممكن أن يؤثر هذا السلوك في الأصول المُصدرة على السجل — كالعملات المستقرة ورموز خطوط الثقة والرموز متعددة الأغراض — لكنه لا يؤثر في XRP الأصلية، التي تقع خارج نطاق نموذج الصلاحيات هذا. هل استُغلت الثغرة؟ - لم تؤكد أي تقارير علنية وقوع استغلال، كما أن الإفصاحات حتى الآن لم تحدد أي جهة إصدار تعرضت لإنشاء رموز غير مصرح به. كيف يعمل الإصلاح؟ - يرفض التعديل «مدفوعات PaymentBurn التي تتجاوز رصيدًا صفريًا»، ما يفصل فعليًا بين إتلاف الرموز وإصدارها، ويمنع حالة تجاوز الحد التي أتاحت السك غير المقصود. - أُدرج التغيير ضمن إصدار خادم XRP Ledger v3.4.0 في سبتمبر، لكن تعديلات البروتوكول تتطلب تصويتًا من المدققين قبل تغييرها لقواعد الشبكة. جدول التصويت والتنفيذ لدى المدققين - تحتاج تعديلات البروتوكول إلى دعم أكثر من 80% من المدققين الموثوقين لمدة 14 يومًا متتاليًا لتفعيلها. وبوجود 35 مدققًا في القائمة الافتراضية المتتبعة، فهذا يعني أن 29 مدققًا على الأقل يجب أن يعلنوا دعمهم باستمرار. - بدأت نافذة الموافقة الأولى في 9 أكتوبر، لكنها انقطعت عندما انخفض الدعم عن الحد المطلوب في 21 أكتوبر (استمرت المحاولة الأولى 12 يومًا و3 ساعات). تشكلت أغلبية جديدة في وقت لاحق من ذلك اليوم، فبدأ عدّ تنازلي ثانٍ مدته 14 يومًا، واستمر 14 يومًا و5 دقائق، ما أتاح التفعيل في 4 نوفمبر. - يتطلب التصويت في XRPL دعمًا متواصلًا، لذا حتى التراجع المؤقت قد يؤخر الترقية. تصحيحات أخرى مضمنة في fixCleanup3_4_0 إلى جانب إصلاح PaymentBurn، يجمع التعديل عدة إصلاحات للصيانة والسلامة تؤثر في سلوك المعاملات والمحاسبة: - الاستردادات القسرية لصانع السوق الآلي (AMM): تمنع المعاملة من إتلاف رموز مزود السيولة عندما يؤدي التقريب لولا ذلك إلى بقاء المُصدر من دون أصول أساسية. - قواعد التداول الخاضع للصلاحيات: تمنع الحسابات من تلقي رموز معينة عبر العروض عندما ينبغي لقيود المُصدر أن تمنع عمليات النقل هذه. - احتياطيات الضمان، وتفويض الرموز متعددة الأغراض، ومعالجة توقيعات المعاملات: تقدم بادئات توقيع منفصلة لمنع إعادة استخدام توقيعات خاصة بدور معاملة معين لدور آخر. - تصحيحات محاسبية لخزائن الأصول المفردة وبروتوكول الإقراض المقترح: تعدّل طريقة احتساب الإيداعات والسحوبات والأصول القابلة للاسترداد والمدفوعات المتأخرة والقروض المتعثرة. تمهّد هذه التصحيحات السجل لميزات الإقراض المستقبلية، لكنها لا تفعّلها — إذ لا يزال كل تعديل خاص بالإقراض بحاجة إلى موافقة منفصلة من المدققين. السياق والخطوات التالية - حث المطورون مشغلي الخوادم على الترقية إلى الشيفرة البرمجية v3.4.0 قبل دخول التعديل حيز التنفيذ. ويأتي التفعيل بعد إفصاحات سابقة عن خلل سكّ الرموز؛ إذ تناول crypto.news المسألة في 2 نوفمبر، حين كان التعديل لا يزال بانتظار التفعيل. - تظل ميزات الإقراض المقترحة (خزائن الأصول المفردة وLendingProtocolV1_1) خاضعة لتصويت مستقل، ولن تصبح نشطة على الشبكة الرئيسية إلا إذا حصل كل منها على دعم المدققين المطلوب. لماذا يهم ذلك؟ - يزيل التصحيح خطرًا محتملًا ذا مصداقية في حالات نادرة يهدد الرموز المُصدرة على XRP Ledger، ويعزز ضبط سلوكيات متعددة للمعاملات والمحاسبة — وهي خطوة مهمة لتعزيز ثقة جهات الإصدار، وسلامة العملات المستقرة، وميزات البروتوكول المستقبلية. اقرأ المزيد من الأخبار المُنشأة بالذكاء الاصطناعي على: https://app.chaingpt.org/news