قام مطورو دفتر أستاذ XRP بإيقاف العمل بخمسة تعديلات بروتوكولية نشطة منذ فترة طويلة في الإصدار 3.3.0 من xrpld، لكن هذه الخطوة لا تزيل ميزاتها ولا تتطلب من حاملي XRP اتخاذ أي إجراء.
أوضحت مهندسة برمجيات RippleX، مايوخا فاداري، على منصة X أن إيقاف العمل بالتعديل يزيل الكود القديم السابق للتعديل الذي يُترك بعد أن يعمل تغيير البروتوكول لسنوات. أما السلوك المعدّل نفسه فيبقى في مكانه. تؤكد وثائق XRPL الرسمية أن التعديلات التي يُوقف العمل بها تصبح أجزاءً غير مشروطة من البروتوكول الأساسي.
أصبح هذا التمييز مهمًا بعد إصدار xrpld 3.3.0 في 6 أغسطس، والذي أوقف العمل بتعديلات Clawback، و fixDisallowIncomingV1، و fixInnerObjTemplate، و fixNFTokenReserve، و fixUniversalNumber. بعبارة أخرى، "إيقاف العمل بـ Clawback" لا يعني أن جهات إصدار XRP Ledger تفقد وظيفة الاسترداد (clawback). بدلاً من ذلك، تتخلى الشبكة عن مسار الكود الأقدم الذي كان يصف كيفية تصرف المعاملات قبل أن يصبح التعديل نشطًا.
يتيح نظام تعديلات XRP Ledger إدخال تغييرات على البروتوكول دون فرض كل قاعدة جديدة فورًا على الشبكة الرئيسية. يصوت المدققون على التعديلات، ويجب أن يحافظ الاقتراح على دعم أكثر من 80% من المدققين الموثوق بهم لمدة أسبوعين متتاليين قبل أن يصبح نشطًا. بمجرد التمكين، ينطبق السلوك الجديد بشكل دائم ما لم يغيره تعديل آخر لاحقًا.
خلال الفترة التي تلي التفعيل، يحتفظ xrpld بكل من المنطق الحالي وبعض الكود السابق للتعديل. يمكن أن يساعد هذا الكود القديم المطورين على إعادة إنتاج سلوك دفتر الأستاذ القديم عند تصحيح الأخطاء أو التحقق من المعاملات التاريخية. ومع ذلك، فإن الاحتفاظ بسنوات من الفروع القديمة يضيف تعقيدًا إلى قاعدة الكود.
تنص وثائق التعديل الرسمية على أنه يمكن إيقاف العمل بتعديل على الشبكة الرئيسية بمجرد تمكينه لمدة عامين. يؤدي إيقاف العمل إلى إزالة مسار الكود القديم الخاص به، والتوقف عن معاملة التغيير كتعديل مشروط، ودمج السلوك الأحدث في البروتوكول بشكل غير مشروط.
وصفت فاداري العملية بأنها "مجرد تنظيف لقاعدة الكود" وقالت إنها "لن تؤثر على أي مستخدمين". وأضافت أن المطورين ينتظرون عادة عامين لأن التنفيذ السابق لا يزال مفيدًا عند تصحيح أخطاء المعاملات القديمة. تحذر وثائق اختبار XRPL الخاصة بها بالمثل من أن إعادة تشغيل المعاملات بدقة تاريخية قد تتطلب تشغيل إصدار xrpld الذي عالج المعاملة في الأصل بعد إيقاف العمل بالتعديلات القديمة.
Clawback هو الأكثر تميزًا من بين التعديلات الخمسة التي أُوقف العمل بها والأسهل في سوء الفهم. أصبحت الميزة نشطة على الشبكة الرئيسية في 8 فبراير 2024 وتسمح لجهات الإصدار المؤهلة باستعادة الرموز الصادرة من حامليها عندما يكون حساب جهة الإصدار قد مكّن إعداد Clawback المطلوب. لا تسمح لجهة الإصدار باسترداد XRP الأصلي.
لذلك، فإن إيقاف العمل بالتعديل يعني أن الشبكة لم تعد بحاجة إلى كود لإصدار من XRPL حيث لم تكن Clawback موجودة. سلوك Clawback الحالي يظل جزءًا من البروتوكول. تعرض صفحة تعديلات XRPL المعروفة الآن وظائفها السابقة للتعديل على أنها متقاعدة بشكل صريح.
تتبع التعديلات الأربعة الأخرى نفس المبدأ. صحح fixDisallowIncomingV1 مشكلة تفويض خط الثقة. عالج fixInnerObjTemplate الأخطاء المتعلقة بكائنات AMM الداخلية. أضاف fixNFTokenReserve فحوصات الاحتياطي عند قبول عروض NFT، بينما وحد fixUniversalNumber أجزاء من حسابات الفاصلة العائمة العشرية في XRPL. تبقى قواعدها بعد التعديل سارية المفعول على الرغم من إزالة المسارات القديمة.
هذه ليست آلية حوكمة جديدة. أوقف XRPL العمل بتعديلات سابقة بعد أن أصبحت قواعدها راسخة بما فيه الكفاية. على سبيل المثال، أوقف الإصدار 3.2.0 العمل بتغييرات أقدم تغطي الشيكات، وتفويض الإيداع، وحذف الحسابات، ووظائف بروتوكولية أخرى.
بينما تغادر خمسة تعديلات قديمة الحالة المشروطة، يضيف الإصدار 3.3.0 ستة مقترحات جديدة إلى xrpld. وهي BatchV1_1، و ConfidentialTransfer، و DynamicMPT، و PermissionDelegationV1_1، و Sponsor، و fixCleanup3_3_0. لا يعني إدراجها في البرنامج أن هذه القدرات نشطة بالفعل على الشبكة الرئيسية.
كما أفادت crypto.news، سيدعم ConfidentialTransfer عمليات نقل الرموز متعددة الأغراض التي تحافظ على الخصوصية، بينما سيسمح BatchV1_1 للحساب بتقديم ما يصل إلى ثماني معاملات داخلية معًا. سيسمح Sponsor لأطراف ثالثة بتغطية الرسوم ومتطلبات الاحتياطي، بينما سيوفر DynamicMPT المزيد من المرونة في خصائص الرموز المحددة.
يجب أن يجتاز كل اقتراح عملية المدققين في XRPL بشكل مستقل. يجب أن يستمر دعم أكثر من 80% لمدة أسبوعين قبل تنشيط التعديل، ويمكن أن ينخفض الدعم عن العتبة ويعيد ضبط المؤقت.
الفرق بين هذه التعديلات الجديدة والتعديلات الخمسة التي أُوقف العمل بها جوهري. المقترحات الجديدة تنتظر موافقة الشبكة. أما التعديلات التي أُوقف العمل بها فقد اجتازت تلك المرحلة منذ سنوات، وأصبحت سلوكًا راسخًا للشبكة، ووصلت الآن إلى النقطة التي لم يعد فيها الحفاظ على كودها القديم ضروريًا.
بالنسبة لحاملي XRP العاديين، لا يلزم أي ترحيل، أو تحديث للمحفظة، أو معاملة بشكل خاص بسبب إيقاف العمل بالتعديلات الخمسة. تستمر Clawback والسلوكيات البروتوكولية الأخرى المتأثرة في العمل وفقًا للقواعد المعمول بها.
لدى مشغلي الخوادم اعتبار مختلف. يطلب إشعار إصدار XRPL 3.3.0 من المشغلين الترقية إلى الإصدار 3.3.0 في أقرب وقت ممكن للحفاظ على استمرارية الخدمة. البقاء محدثًا مهم أيضًا لأن الخوادم تحتاج إلى برامج تحتوي على كود التعديلات التي قد تصبح نشطة لاحقًا. يمكن أن يصبح الخادم الذي يفتقر إلى تعديل نشط "محظورًا بسبب التعديل" ويتوقف عن المشاركة بشكل طبيعي في الشبكة.
في تغطية ذات صلة، تم إثبات هذه الآلية في يوليو عندما أدى تنشيط fixCleanup3_2_0 إلى حظر العقد التي تعمل بإصدارات قديمة غير متوافقة بسبب التعديل.
ينتقل الاهتمام الآن من التعديلات التي أُوقف العمل بها إلى قرارات المدققين حول الإضافات الست في الإصدار 3.3.0. كما ذكرنا سابقًا، يعد ConfidentialTransfer من بين المقترحات التي تهدف إلى توسيع أدوات XRPL للأصول الرمزية المؤسسية، لكن استخدامه لا يزال يعتمد على موافقة المدققين.
بالنسبة للتعديلات الخمسة التي أُوقف العمل بها، ومع ذلك، لا يوجد تصويت مماثل قادم. يمثل إيقاف العمل نهاية فترة الانتقال وليس نهاية وظائفها: القواعد المعدلة هي الآن ببساطة جزء من السلوك الأساسي الدائم لدفتر أستاذ XRP.
