دخل PermissionDelegationV1_1 على XRP Ledger فترة التفعيل الممتدة 14 يومًا بعد أن أيّد 29 من أصل 35 مدققًا موثوقًا في الشبكة ترقية صلاحيات الحساب.
وفقًا للوحة متابعة تعديلات XRP Ledger المباشرة، بدأ العد التنازلي في 21 سبتمبر، وقد يدخل PermissionDelegationV1_1 حيّز التنفيذ في 5 أكتوبر عند الساعة 11:18 بالتوقيت العالمي UTC إذا ظل دعم المدققين فوق العتبة المطلوبة طوال هذه الفترة.
يجب أن يواصل ما لا يقل عن 28 من أصل 35 مدققًا موثوقًا دعم التعديل. وإذا انخفض التأييد دون هذا المستوى قبل انتهاء العد التنازلي، فسيُعاد ضبط مؤقت التفعيل.
يغيّر PermissionDelegationV1_1 الطريقة التي يمكن بها لحساب على XRP Ledger أن يمنح حسابًا آخر صلاحية تنفيذ مهام محددة.
في ظل هيكل الحسابات الحالي، قد تواجه الشركات التي تحتاج إلى أنظمة مختلفة أو موظفين مختلفين لتنفيذ العمليات مشكلة منح حساب تشغيلي صلاحيات أكبر مما يحتاجه فعليًا. وقد صُمم Permission Delegation لفصل تلك المسؤوليات.
فعلى سبيل المثال، يمكن لحساب ما أن يخول حسابًا آخر لإجراء المدفوعات دون منحه صلاحية تغيير مفاتيح الحساب الأساسي. كما يمكن لجهة مُصدرة لعملة مستقرة أن تحتفظ بمفاتيحها الرئيسية دون اتصال بالإنترنت، مع منح نظام امتثال متصل بالإنترنت صلاحية الموافقة للعملاء على الاحتفاظ برمزها.
يمكن لكل حساب مُفوَّض أن يحصل على ما يصل إلى 10 صلاحيات، بينما يحتفظ الحساب المانح للصلاحية بالقدرة على تعديلها أو إلغائها.
يشبه هذا الترتيب فصل المسؤوليات المستخدم عادةً في المؤسسات المالية، حيث لا تشترك وظائف الدفع والامتثال والإدارة بالضرورة في المستوى نفسه من الوصول.
يشكل PermissionDelegationV1_1 جزءًا من مجموعة أكبر من التعديلات التي قُدمت عبر xrpld 3.3.0. وقد شمل الإصدار BatchV1_1 وConfidentialTransfer وDynamicMPT وSponsor إلى جانب Permission Delegation، مع توجيه عدد من هذه الميزات نحو المعاملات المؤسسية وإصدار الرموز.
وسيتيح Sponsor لكيان آخر تغطية رسوم المعاملات ومتطلبات الاحتياطي للمستخدمين دون التحكم في حساباتهم. ويمنح DynamicMPT المُصدرين مرونة أكبر بشأن خصائص مختارة في Multi Purpose Token، بينما صُمم ConfidentialTransfer لإخفاء أرصدة MPT ومبالغ المدفوعات عن العرض العام مع الإبقاء على آليات وصول للأطراف المصرح لها.
وكانت Crypto.news قد أفادت سابقًا بأن ConfidentialTransfer يستهدف حالات استخدام مؤسسية قد تحتاج فيها الشركات إلى خصوصية المعاملات مع الاستمرار في توفير المعلومات للمدققين والأطراف المخولة الأخرى.
يمثل PermissionDelegationV1_1 المحاولة الثانية لإدخال صلاحيات الحسابات المفوضة إلى XRP Ledger.
وقد تم إيقاف التعديل الأصلي قبل وصوله إلى الشبكة الرئيسية بعد أن أبلغ أحد مختبري المجتمع عن ثغرة في 15 سبتمبر 2025.
في التنفيذ المتأثر، كان البرنامج يتحقق مما إذا كان الحساب يملك صلاحية تنفيذ معاملة قبل التحقق بشكل صحيح من توقيعها. وكانت بعض المعاملات المرفوضة لا تزال قد تترتب عليها رسوم.
وبالتالي، كان بإمكان مهاجم إرسال معاملات غير مصرح بها برسوم مرتفعة عمدًا والتسبب في دفع حساب آخر لهذه الرسوم رغم أن المعاملات لم تكن موقعة بشكل صحيح. وكان تكرار هذه العملية قد يؤدي إلى استنزاف رصيد XRP المتاح لدى الضحية.
ونُصح المدققون بعدم دعم التعديل عقب اكتشاف الثغرة، ما حال دون تفعيل النسخة المتأثرة على الشبكة الرئيسية.
وقد أُدرج البديل في xrpld 3.3.0 مع تغييرات في كيفية التعامل مع المعاملات غير المصرح بها. ويجري الآن التحقق من التوقيع قبل نوع الإخفاق الذي قد يؤدي إلى تحميل الحساب المستهدف الرسوم.
وليست Permission Delegation الميزة الوحيدة من هذا الإصدار التي عادت بعد أعمال أمنية. فقد حل BatchV1_1 محل تنفيذ Batch سابق بعد أن اكتشف المطورون ثغرة توقيع حرجة ومنفصلة. وقد مضت ترقية Batch المنقحة عبر تصويت المدققين بعد الإصلاحات والمراجعة الإضافية.
لا يغيّر PermissionDelegationV1_1 بشكل مباشر معروض XRP أو جدول إصداره أو اقتصادياته الرمزية، ما يعني عدم وجود سبب آلي يجعل تفعيله وحده يولد طلبًا جديدًا كبيرًا على XRP.
يتعامل هذا التعديل مع صلاحيات الحساب بدلًا من رمز XRP نفسه. وستظل المؤسسات التي تستخدم الحسابات المفوضة تستخدم XRP لرسوم الدفتر العادية ومتطلبات الاحتياطي، لكن الميزة لا تتطلب منها شراء أو الاحتفاظ بكميات كبيرة من XRP لمجرد استخدام الصلاحيات المفوضة.
وتُظهر التطورات الأخيرة على الشبكة سبب أهمية التمييز بين تبني XRPL والطلب على XRP.
فقد وجد تحليل سابق لتعرض Ripple Prime لـ XRP أن حتى النشاط المؤسسي الكبير داخل منظومة Ripple لا يترجم تلقائيًا إلى طلب مكافئ على XRP. إذ يمكن للعملات المستقرة والأصول المُصدرة الأخرى أن تتولى جزءًا كبيرًا من نقل القيمة الأساسي، بينما يحتفظ XRP بأدوار تشمل رسوم المعاملات والاحتياطيات وبعض وظائف التوجيه.
وينطبق هيكل مشابه على Permission Delegation. إذ يمكن لمصدري العملات المستقرة، ومزودي الأصول المرمزة، وغيرها من الشركات استخدام هذه الميزة دون جعل XRP هو الأصل الذي يتم نقله.
وبدلًا من ذلك، يعتمد الارتباط السعري المحتمل على ما إذا كانت الترقية ستساعد في جلب مزيد من النشاط إلى XRP Ledger بمرور الوقت.
يمكن للمُصدرين المؤسسيين الذين يريدون إبقاء مفاتيح الصلاحيات العالية دون اتصال بالإنترنت استخدام الحسابات المفوضة للمدفوعات المتكررة أو مهام الامتثال. وإذا أسهمت هذه القدرات في تشجيع المزيد من الشركات على إصدار الأصول ومعالجة المعاملات على XRPL، فإن النشاط الناتج سيخلق استخدامًا أكبر للشبكة، حيث يظل XRP الأصل الأصلي المستخدم للرسوم والاحتياطيات.
وتشير الأدلة حتى الآن إلى أن نمو الشبكة وسعر XRP لا يتحركان دائمًا معًا. فقد توسعت RLUSD والأصول المرمزة على XRPL بينما مرّ XRP بفترات ضعف سعري، ما يُظهر أن ارتفاع نشاط الدفتر لا يولد بالضرورة ضغط شراء فوريًا على الرمز.
وقد قدم اختبار مؤسسي في يونيو شمل JPMorgan وMastercard وOndo Finance وRipple مثالًا آخر. فقد استخدم استرداد سندات الخزانة المرمزة XRP Ledger، لكن XRP لم يكن الأصل الجاري استرداده. وظل دوره المباشر مرتبطًا بالبنية التحتية الأساسية للشبكة.
لذلك، قد يوفر PermissionDelegationV1_1 قطعة إضافية من البنية التحتية للمستخدمين المؤسسيين دون أن يصبح محفزًا رئيسيًا ومستقلًا لسعر XRP.
ولا يزال رد فعل السوق حول التفعيل ممكنًا لأن المتداولين قد يستجيبون لترقيات الشبكة والتوقعات المرتبطة بالتبني. ومع ذلك، فإن أي أثر سعري مستدام سيعتمد على الاستخدام اللاحق للميزة وعوامل سوقية أخرى، بدلًا من مجرد تشغيل التعديل بحد ذاته.
يتجه Permission Delegation نحو التفعيل، بينما لا تزال عدة ميزات أخرى في XRP Ledger تمر بمراحل مختلفة من عملية التعديل.
صُمم BatchV1_1 لتجميع عمليات متعددة في معاملة منسقة، بما يسمح لكل إجراء مدرج بأن ينجح أو يفشل معًا. ويمكن لمثل هذا الهيكل دعم عمليات التسوية التي تحتاج فيها الأصول ومدفوعاتها إلى الانتقال في الوقت نفسه.
وسيمنح ConfidentialTransfer مُصدري Multi Purpose Token خيار إخفاء الأرصدة ومبالغ التحويل مع إبقاء الحسابات مرئية. وسيظل بإمكان الأطراف المصرح لها تلقي المعلومات اللازمة للامتثال وفق التصميم المقترح.
وواصل مطورو XRPL العمل بعد إصدار 3.3.0. فقد قدم الإصدار 3.4.0، الصادر في 16 سبتمبر، مراجعات على وظائف الإقراض المقترحة إلى جانب حزمة أخرى من إصلاحات البروتوكول.
ولا يزال إطار الإقراض خاضعًا لعملية تعديل الشبكة، مع اشتراط موافقة المدققين قبل أن تصبح الوظائف المقترحة نشطة على الشبكة الرئيسية.
XRP
