مطورو XRP Ledger مطالبون بحسم تعديلين لفحص الموافقة على الرموز قبل الشبكة الرئيسية

طلبان مفتوحان وآخران مغلقان

ما زال مطورو XRP Ledger مدينين للشبكة بقرار حاسم بشأن تعديلين مقترحين يشدّدان قواعد استلام الحسابات للرموز التي يشترط مصدّرها موافقة، ولا شأن من التعديلين بلغ بعد قواعد الشبكة الرئيسية حتى الآن. ثُبّت الطلبان باسم PR #8648 وPR #8650 في مستودع برمجيات الخادم التابع لمؤسسة XRP Ledger يوم 27 أكتوبر، وما زالا مفتوحين حتى صباح الاثنين 2 نوفمبر. وفي المقابل، أُغلق نقاشان مرافقان هما #8649 و#8651، وهو ما يجعل التعديلين الأضيق نطاقًا المسار الحيّ الوحيد أمام التغيير.

يتناول التعديل الأول، #8648، رموز مزودي السيولة في مجمعات صانع السوق الآلي. يقترح النص أنه كلما كان الحساب على وشك استلام أحد رموز السيولة هذه، لا بد من فحص متطلبات التفويض على الأصلين اللذين يشكّلان المجمع معًا، بحيث يمنع أصل واحد غير مفوّض عملية الاستلام بالكامل. يدبّ مقدمو السيولة أموالهم في هذه المجمعات حاليًا، حيث تسجّل TVL القيمة الإجمالية المقفلة، ويحتج النص المقترح على أن التحقق من الموافقة لحظة الإيداع وحدها قد لا يمنع تحويلات لاحقة للرمز. لذلك يمتد الفحص إلى ما هو أبعد من الإيداعات: يشمل المدفوعات، وعروض التداول، ومبيعات الرموز غير القابلة للفصل التي تُنفَّذ عبر dApp، ومزادات AMM، أي كل مسار يمكن للرمز أن يتحرك عبره.

أما التعديل الثاني، #8650، فيعالج خطوط الثقة التي تحمل رصيدًا قائمًا أصلًا. إن فحص الموافقة على مسارات الدفع الحالي لا يعمل إلا حين يكون الرصيد عند الصفر، ما يعني أن حسابًا لم يُفوَّض قط يستطيع مواصلة استلام الرموز ما دام يحتفظ بمبلغ متبقٍّ لديه. من شأن التعديل أن يمنع عمليات الاستلام الإضافية تلك مع الحفاظ على مسار الاسترداد سليمًا، وهو المسار الذي يعيد الرصيد القائم إلى المصدر. وهذا النطاق الأضيق هو ما يفرّقه عن النقاش المغلق #8649، وهو مقترح أوسع كان سيقيّد كل استخدامات الأرصدة غير المفوّضة.

إعداد Require Auth ومسار دعم 80% من المصادقين

يقوم المقترحان على إعداد Require Auth، وهو ضابط على جانب المصدر يشيرون الرمز إلى أنه لا تُمسكه إلا بموافقة. تذكر وثائق السجل الرسمية أن خط الثقة الخاص بالحساب يجب أن يُفوَّض قبل أن يتمكن من حيازة رمز من هذا النوع، وخط الثقة هو العلاقة المسجلة على دفتر توزيع الأستاذ بين الحساب ومصدر الرمز. خط الثقة غير المفوّض يعني ببساطة أن المصدر لم يمنح موافقته على ذلك الحامل، مهما كانت أدوات الفرز التي يطبقها. ويشمل النظام الرموز المُصدَرة فقط؛ فالأصل الأصلي الذي يقوم عليه سعر XRP لا يحتاج إلى بوابة مصدر، وهو تمييز يُبقي اقتصاديات الرموز للسجل منفصلة عن عملته الأساسية. والمصدرين الذين يفرزون حاملي الرموز، ومن بينهم منصات تستعد لإطلاق عملة مستقرة بعائد، يعتمدون على هذا الإعداد للتحكم في من يتلقى أصولهم، ولهذا تحمل مسارات الاستلام قيد المراجعة ثقلًا امتثاليًا واضحًا.

ويسير التفعيل وفق مسار محدد سلفًا. فالتعديلات تغيّر قواعد معالجة المعاملات، وتشترط الوثائق الرسمية أن يدخل التعديل ضمن إصدار برمجي ثم يحتفظ بدعم يتجاوز 80% من المصادقين الموثوقين لأسبوعين كاملين قبل أن ينشّط. ويرتبط المقترحان الجديدان كلاهما بتعديل fixCleanup3_5_0، ما يعني أن مصيرهما يمر عبر دورة الإصدار ذاتها. وقد يتحرك التوقيت في الأثناء: إذ انتقل تاريخ التفعيل المتوقع لـfixCleanup3_4_0 من الجمعة 23 أكتوبر إلى الأربعاء 4 نوفمبر مستوفًٍا شرط دعم المصادقين نفسه. والحالة المفتوحة تضع الطلبين الجديدان في مرحلة المراجعة، حيث يقرأ المشرفون الشيفرة ويطلبون تغييرات ويقررون ما إذا كان المنطق مؤهلًا لدخول نسخة مرشحة للإصدار. فالدمج، ثم الإدراج في إصدار، ثم تصويت المصادقين، هي المحطات الثلاث الفاصلة بين المقترحين وقواعد الشبكة الرئيسية.

الثغرة الامتثالية التي يسدّها #8650

الفجوة التي يرقّعها #8650 هي ثغرة امتثالية عملية لا نظرية: بموجب القواعد الحالية، يستطيع حساب غير مفوَّض يحمل رموزًا متبقية أن يواصل استلامها، وهو عين النتيجة التي يسعى المصدرُ المستخدمُ لـRequire Auth إلى منعها. واختيار الإصلاح الأضيق على حساب المقترح الأوسع المغلق يحفظ تدفقات الاسترداد بلا مساس مع إغلاق مسار الاستلام، على أن يُترك تنظيم بقية استخدامات الأرصدة غير المفوّضة لجولة قادمة. وتمرير الطلبين معًا عبر المراجعة يبقي الإصلاحين متوافقين، لأن فحوص #8648 على مستوى المجمعات وقاعدة #8650 على مستوى الرصيد يخدمان ذات غاية التحكم من جانب المصدر. ويستمر نشاط السجل على التوازي: فقد سجّلت بيانات السلسلة تحويل 1.8 مليار وحدة من XRP خلال 24 ساعة بما أبقى حجم التحويلات مرتفعًا، وأطلقت Ripple مليار XRP من الضمان يوم الأحد 1 نوفمبر، كما تُقيّد Ripple ذاتها استرداد RLUSD المباشر خلف عقود مفوَّضة، وهو ما ينسجم مع تشكّل السجل بضوابط جانب المصدر. أما ما تبقى ففي يد المطورين: دمج الطلبين، وإصدارهما ضمن إصدار، ثم الاحتفاظ بدعم يفوق 80% من المصادقين لأسبوعين. ولا ينشط أي تعديل قبل إغلاق دورة الإصدار المقبلة.