تعديل الإقراض على XRP Ledger ينتظر تصويت المدققين بنسبة 80% لإنقاذ المقترضين من الوحدة الإضافية

تفاصيل تعديل السداد في Pull Request 8698

تعديل برمجي جديد منشور مؤخرًا يستهدف بالدرجة الأولى مشغّلي الخزائن والمقترضين الذين يعتمدون على بروتوكول الإقراض الأصلي في شبكة XRP Ledger. يتناول التعديل طريقة تقريب مبالغ سداد القروض، وهو مطروح في طلب السحب رقم 8698 على برنامج rippled، أي الخادم المرجعي الذي يشغّل الشبكة من الطبقة الأولى التي تقف خلف عملة XRP. وبمجرد تفعيله، سيتطابق الرصيد بعد كل دفعة مع جدول القرض بدقة، بدلًا من الانحراف بفوارق صغيرة على مدى عمر الدين.

يحمل المقترح كله مفهومين محاسبيين: الحقل TotalValueOutstanding الذي يقيس المستحق على المقترض في أي لحظة، والحقل PeriodicPayment الذي يمثل المبلغ المقرر لكل قسط يُسدّد في موعده. فبموجب LendingProtocolV1_2، تنزل كل دفعة في موعدها عبر المعاملة LoanPay بقيمة TotalValueOutstanding إلى القيمة المجدولة، أي دفعة واحدة أقل في الإجمالي، دون تجاوز PeriodicPayment المقرّب. وإذا سدّد المقترض أكثر من المطلوب، يُعاد ضبط TotalValueOutstanding إلى الرقم المجدول للقسط المُعاد هيكلة. تبدو فروق التقريب الصغيرة أمرًا هامشيًا، لكن دفتر أستاذ يُسوّي القروض برمجيًا يحتاج إلى حساب حاسم، لأن كل عقدة على الشبكة يجب أن تصل إلى الرصيد نفسه بعد المعاملة ذاتها.

يمتد هذا التعديل إلى مسار الشبكة في الإقراض الأصلي، وهو سوق يُصنّف عادة ضمن قطاع DeFi، ويقع على السلسلة ذاتها التي تستضيف عملة RLUSD من Ripple، بعد أن أكدت الشركة إصدار نصف إصداراتها على شبكة XRP Ledger. وبما أن التعديل تصحيح على مستوى الشيفرة في محاسبة القروض، فهو لا يمس سعر XRP اليوم انعكاسًا مباشرًا؛ وأثره الحقيقي يقع على منظومة الإقراض في مجتمع XRP، حيث يحدد المصدرون شروط القروض ويتبع المقترضون الجدول.

كيف يتجمع انحراف التقريب على أقساط القرض

يقيّم التنفيذ الحالي مكوّن القيمة لكل دفعة بمعزل عن غيره. ومن هنا تتكدس أخطاء التقريب مع مرور عمر القرض: قد ينتهي القسط الأخير مطالبًا بوحدة واحدة زائدة عن PeriodicPayment المقرّب، وقد تتأرجح مكونات القيمة بين الأقساط المتتالية صعودًا وهبوطًا بدل أن تبقى ثابتة. أول التزام في طلب السحب ينقل حساب القيمة المجدولة من الدالة computeLoanProperties إلى دالة مستقلة باسم scheduledValue، دون أي تغيير في السلوك بحد ذاته. أما تمرير الطرفين عبر روتين مشترك واحد فيعني أن معاملة LoanSet التي تُنشئ القرض ومعاملة LoanPay التي تسجّل الدفعة تقرّبان الرقم بالطريقة نفسها.

وتحتاج القروض المكتوبة دون أي APY أيضًا إلى حدّ أدنى على الجزء الأساسي، لأن قيمتها تُقرّب إلى الأقرب بينما يُقرّب الأصل إلى الأعلى. وجوهر الإصلاح هو أسلوب يسميه المطورون «التلسكوبي»: يضبط مكوّن القيمة لكل دفعة في موعدها عند حدّ PeriodicPayment الأدنى أو الأعلى، ولن يقل عن وحدة واحدة أبدًا. وهكذا يستقر القسط الأخير تمامًا على PeriodicPayment المقرّب، فيُغلق الفجوة التي كانت تظهر في نهاية الجدول وتزول نمط التأرجح بين الأقساط. أما الخزائن فهي بنى الائتمان المجمّعة في الدفتر، وقد شملت الاختبارات خزائن Legacy وCashBasis وFixedPrecision، بتشغيلها مع التعديل النشط وبدونه حتى يعزل المراجعون أثره.

أين يقف تصويت المدققين بنسبة 80%

قراءتنا أن التعديل موجّه إلى المُصدرين وأدوات الخزائن أكثر بكثير مما هو موجّه إلى المقترضين العاديين. والمستخدمون والمستثمرون يشعرون اليوم بأثر ضئيل أو منعدم: الوحدة الزائدة على الدفعة الأخيرة تغيّر القليل عمليًا، والقروض القديمة التي حملت وحدة واحدة فوق جدولها تحتفظ بها، فيبقى القسط الأخير يتطلب PeriodicPayment زائد وحدة واحدة ما لم يسبق ذلك سداد زائد من المقترض. أما مبالغ السداد الزائدة الصغيرة فتُتجاهل غالبًا، وتن成败 المعاملة بنجاح دون خصم XRP إضافي. وبذلك تحصل منظومة الائتمان في الدفتر، التي تمتد أيضًا إلى تسويات PayFi، على حساب أنظف دون أي عبء ترحيل على القروض القائمة.

الطرف الذي لم يتحرك بعد هو مجموعة المدققين. فالتفعيل يتطلب موافقة 80% من المدققين مستمرة أسبوعين متتاليين، ولم يُعلَن بعد أي تصويت علني على LendingProtocolV1_2، ما يجعل تاريخ التفعيل غير محدد. والسؤال المفتوح يتعلق بالتوقيت لا بالجدارة: فالشيفرة واختباراتها موجودة، والمفقود هو التصويت نفسه.