أصدر مطورو XRP Ledger الإصدار 3.3.0 من xrpld في 6 أغسطس، مما يقرب العديد من التغييرات البروتوكولية من التفعيل المحتمل على الشبكة الرئيسية.
- يقدم XRPL 3.3.0 كود البروتوكول، لكن موافقة المدققين تظل ضرورية قبل أي تفعيل على الشبكة الرئيسية.
- من شأن ConfidentialTransfer حماية أرصدة MPT ومبالغ التحويل مع الحفاظ على وصول الامتثال للأطراف المصرح لها.
- يستعيد BatchV1_1 وظيفة المعاملات الذرية بعد إيقاف نسخة سابقة بسبب خلل أمني.
- من شأن Sponsor السماح لأطراف ثالثة بتغطية الرسوم والاحتياطيات بينما يحتفظ المستخدمون بالسيطرة الكاملة على الحساب.
- من شأن DynamicMPT السماح للمصدرين بتعديل خصائص مختارة من الرمز لاحقًا، لدعم احتياجات الأعمال والامتثال المتطورة.
يؤكد الإصدار الرسمي على GitHub العمل على ConfidentialTransfer وBatchV1_1 وSponsor وDynamicMPT، إلى جانب الإصلاحات والتغييرات البروتوكولية الأخرى. إصدار البرنامج نفسه لا يفعل هذه الميزات على الشبكة.
التمييز مهم لأن بعض التقارير تصف ستة ترقيات بأنها نشطة بالفعل. بموجب عملية تعديل XRP Ledger، تتطلب ميزات البروتوكول الجديدة دعم المدققين قبل التفعيل. يجب أن يحافظ التعديل على دعم أكثر من 80% من المدققين الموثوقين لمدة أسبوعين متواصلين قبل أن يسري.
XRP Ledger 3.3.0 يضيف أدوات الخصوصية والمعاملات الذرية
تم تصميم ConfidentialTransfer لإضافة الخصوصية للرموز متعددة الأغراض، أو MPTs. تقول وثائق XRPL إن التعديل يستخدم التشفير لحماية الأرصدة الفردية ومبالغ التحويل مع الحفاظ على الآليات التي تسمح للأطراف المصرح لها، بما في ذلك المصدرين أو المدققين، بالتحقق من المعلومات اللازمة للامتثال.
تظل الميزة خاضعة لتفعيل التعديل، لذا لا ينبغي وصف تحويلات MPT الخاصة بأنها نشطة على الشبكة الرئيسية لـ XRPL بعد.
BatchV1_1 هو مكون رئيسي آخر. يسمح معيار XLS-56 بتجميع معاملات متعددة ومعالجتها معًا، بما في ذلك المعاملات التي تشمل حسابات مختلفة. يمكن أن يساعد التنفيذ الذري في سير عمل التسوية حيث يجب أن تنجح عدة إجراءات معًا بدلاً من ترك جزء مكتمل بينما يفشل آخر.
الميزات المنقحة تتبع النتائج الأمنية السابقة
لدى Batch تاريخ مهم. تم تعطيل نسخة سابقة قبل تفعيل الشبكة الرئيسية بعد اكتشاف مشكلة أمنية في منطق توقيع المعاملات. انتقلت مؤسسة XRPL لاحقًا نحو BatchV1_1 كبديل مصحح. كما ورد سابقًا في تغطية أمان XRPL، زاد المطورون من المراجعة الرسمية حول الترقيات الأخيرة.
اتبع تفويض الإذن مسارًا مشابهًا. كشفت XRPL في سبتمبر 2025 أن خطأ في التعديل السابق كان يمكن أن يسمح لمعاملة غير مصرح بها بفرض رسوم على حساب آخر في ظل ظروف محددة. نُصح المدققون بالتصويت بـ"لا"، ولم يتم تفعيل الميزة الضعيفة أبدًا. تم تطوير PermissionDelegationV1_1 كبديل لها.
يسمح المفهوم المنقح للحساب بمنح أذونات معاملات محددة دون تسليم مفتاحه الرئيسي، مما يدعم المحافظ التشغيلية بسلطة محدودة.
Sponsor وDynamicMPT يستهدفان الإعداد المؤسسي
تم تصميم Sponsor، استنادًا إلى XLS-68، للسماح لحساب آخر بتغطية رسوم المعاملات أو متطلبات الاحتياطي بينما يحتفظ المستخدم بالسيطرة على الحساب والمفاتيح. يمكن أن تسمح الميزة للتطبيقات بإعداد المستخدمين دون مطالبتهم باقتناء XRP فقط لتلبية تكاليف الشبكة. يدعم اقتراح XLS-68 صراحة رعاية الرسوم والاحتياطيات مع الحفاظ على سيطرة المستخدم على المفاتيح.
يستهدف DynamicMPT مصدري الرموز. يسمح اقتراح XLS-94 للمصدرين بتعيين خصائص MPT مختارة كقابلة للتغيير عند إنشاء رمز، ثم تحديث تلك الحقول المسموح بها لاحقًا. يهدف المعيار إلى استيعاب متطلبات الأعمال أو الامتثال المتغيرة دون جعل كل خاصية رمز قابلة للتحرير بحرية.
معًا، تتناسب هذه الميزات مع تركيز XRPL المتزايد على التمويل المرمّز. في تغطية الترميز ذات الصلة، ذكرت crypto.news أن JPMorgan وMastercard وOndo Finance وRipple اختبروا استرداد خزانة مرمّز باستخدام XRPL.
ليس كل ترقية مذكورة تنتمي إلى الإصدار 3.3.0
يعد تصحيح واحد ضروريًا حول صياغة "الترقيات الست" المنتشرة على نطاق واسع. ينتمي fixCleanup3_2_0 إلى دورة xrpld 3.2.0 السابقة، وليس حزمة ميزات 3.3.0 الصادرة حديثًا. يُظهر سجل التغييرات على GitHub للإصدار 3.3.0 بدلاً من ذلك العمل حول LendingProtocolV1_1 ومسار fixCleanup3_3_0 منفصل إلى جانب الميزات الرئيسية.
لذلك لا ينبغي قراءة الإصدار على أنه ست قدرات مكتملة تصبح متاحة في وقت واحد. إنه معلم برمجيات الخادم الذي يمنح المدققين والمشغلين الكود اللازم لقرارات التعديل. يمكن أن يكون للتعديلات الفردية جداول زمنية مختلفة للتصويت وقد تفشل في التفعيل إذا انخفض الدعم دون الحد المطلوب.
هذه العملية الحوكمية كانت مهمة من قبل. تم إيقاف تعديلات Batch وPermission Delegation الأصلية بعد تحديد الأخطاء قبل تفعيل الشبكة الرئيسية، مما يظهر أن الإدراج في البرنامج أو تصويت المدققين ليس هو نفسه النشر في الإنتاج.
ماذا يحدث بعد ذلك لمدققي XRPL
يحتاج مشغلو العقد الآن إلى تقييم الإصدار 3.3.0 وتحديد ما إذا كانوا سيقومون بالترقية ودعم التعديلات الفردية. تعتمد تواريخ التفعيل الدقيقة على تصويت المدققين، وليس على إصدار البرنامج في 6 أغسطس. تتطلب قواعد تعديل XRPL استمرار الأغلبية العظمى بشكل مستمر لمدة أسبوعين.
بالنسبة لحاملي XRP، فإن التغيير الفوري تقني وليس نقديًا. يوسع الإصدار 3.3.0 مجموعة الأدوات المحتملة للشبكة للخصوصية والتسوية متعددة الخطوات والسلطة المفوضة والإعداد المدعوم وإصدار الرموز القابل للتكوين، لكن لا شيء يضمن ارتفاع الطلب على XRP أو ارتفاع السعر.
ستكون المعالم التالية القابلة للتحقق هي اعتماد المدققين للإصدار 3.3.0، ومستويات دعم التعديل، وتواريخ التفعيل المجدولة. حتى يتم الوصول إلى هذه العتبات، يجب وصف القدرات الجديدة بأنها صادرة في برنامج العقد وتتحرك عبر الحوكمة، وليس كميزات نشطة بالكامل على الشبكة الرئيسية لـ XRP Ledger.
قرارات المدققين، وليس تسويق الإصدار، ستحدد متى تصبح كل ميزة قابلة للاستخدام على الشبكة الرئيسية.