يُقدر إصدار GreatVoyage-v4.7.2 (Periander) في نهاية شهر يونيو ، ولا تزال المحتويات والميزات المضمنة قيد المناقشة ليتم تحديدها حيث نرحب بك لتقديم مساهمتك إلى الإصدار القادم في Periander Planning.
التغييرات المخطط إدراجها في Periander:
1. TIP-541: إضافة اقتراحًا للسماح بإلغاء unstaking في Stake 2.0
2. TIP-542: إضافة اقتراحًا لتحسين واجهة برمجة تطبيقات تفويض الموارد
3. TIP-543: إضافة اقتراحًا للسماح بالتكيف مع Ethereum Shanghai Upgrade
4. IP-544: تقدير الطاقة API يدعم عملية نشر العقد
5.ترقية وحدة شبكة P2P إلى Libp2p v2.0.0
◽️ إضافة وظيفة الكشف المسبق للعقدة لتحسين كفاءة اتصال P2P
◽️ دعم اكتشاف العقدة المستندة إلى DNS
◽️ دعم بروتوكول IPv6
◽️دعم إرسال الرسائل المضغوطة
TIP-541: أضف اقتراحًا للسماح بإلغاء unstaking في Stake 2.0
يقومTIP-541 على تحسين Stake 2.0 ، حاليًا بعد أن يبدأ المستخدمون معاملة Stake 2.0 غير ثابتة من خلال واجهة برمجة تطبيقات HTTP ، عليهم الانتظار 14 يومًا لسحب الأموال المقابلة حيث ستقدم Periander اقتراحًا جديدًا للحوكمة للسماح للمستخدمين بإلغاء عملية unstaking التي تم بدئها بالفعل ، مما يزيد من تحسين مرونة Stake 2.0.
وتجدر الإشارة إلى أنه لا يمكن إلغاء unstaking الذي طال انتظاره لأكثر من 14 يومًا وسيتم سحب الأموال تلقائيًا إلى الحساب وفي المستقبل يجب تأكيد هذه الوظيفة من خلال التصويت على الحوكمة لتحديد ما إذا كانت ستصبح سارية المفعول.
TIP-542: إضافة اقتراحًا لتحسين واجهة برمجة تطبيقات تفويض الموارد
عند تفويض الموارد يمكن للمستخدم اختيار تأمين عملية التفويض وإذا اخترت الإغلاق فلا يمكن إلغاء المورد المفوض إلى العنوان الهدف في غضون 3 أيام ، وهو أمر أكثر ملاءمة للمستخدمين المشاركين في سوق تأجير الموارد حيث يضيف TIP-542 اقتراحًا لتحسين تأمين الموارد المفوضة ، وتغيير وقت القفل من القيمة الثابتة الحالية البالغة 3 أيام إلى عدد محدد من الأيام وبهذا يمكن للمستخدمين تحديد عدد الأيام التي سيقفلها التفويض وفقًا لاحتياجاتهم ، مما سيوفر لهم المزيد من الخيارات ويحسن مرونة تفويض موارد Stake 2.0.
TIP-543: إضافة اقتراحًا للسماح بالتكيف مع ترقية Ethereum Shanghai
تم تضمين EIP-3855 في ترقية شنغهاي لـ Ethereum ، والتي تضيف تعليمات جديدة تسمى PUSH0 إلى Ethereum Virtual Machine (EVM) لتقليل تكلفة الغاز في معاملات العقود الذكية كما يضيف Periander اقتراحًا جديدًا للحوكمة ليكون متوافقًا مع EIP -3855.
من ناحية يمكن أن يضمن التوافق بين TRON و Ethereum على مستوى الجهاز الظاهري ومن ناحية أخرى فإنه يقلل أيضًا من تكلفة الطاقة لاستخدام العقود الذكية على TRON.
TIP-544: تقدير الطاقة API يدعم معاملة نشر العقد
يمكن للمطورين استدعاء wallet / triggerconstantcontract API لتقدير رسوم المعاملة للاتصال بعقد ذكي ولكن لا يمكن لواجهة برمجة التطبيقات هذه تقدير رسوم المعاملة لنشر عقد ذكي حيث يعمل TIP-544 على تحسين wallet / triggerconstantcontract API لدعم تقدير رسوم المعاملة لكل من استدعاء عقد ذكي ونشر عقد ذكي وبالتالي تحسين راحة مطوري العقود الأذكياء بشكل كبير.
ترقية وحدة شبكة p2p إلى Libp2p v2.0.0
Libp2p هو إطار عمل بروتوكول P2P مفتوح المصدر إصدار Java تم تطويره بواسطة مطوري Java-tron الأساسيين حيث يمكن لأي شخص تطوير التطبيقات الموزعة على أساس Libp2p ، ويتم تنفيذ شبكة P2P الأساسية لـ Java-tron على أساس Libp2p ومن أجل زيادة تحسين أداء الشبكة الأساسي لـ Java-tron ، سيحل Periander محل إصدار Libp2p v0.1.4 التابع بالإصدار v2.0.0.
يحتوي Libp2p v2.0.0 على الميزات الجديدة التالية:
وظيفة الكشف المسبق للعقدة
يختار Libp2p v0.1.4 ما إذا كان سيتم إنشاء اتصال ومزامنة البيانات مع العقدة البعيدة وفقًا لترتيب وقت تحديث العقدة البعيدة وفي السيناريوهات الفعلية قد يرفض الطرف الآخر الاتصال لسبب ما مما سيؤثر على مزامنة البيانات ، لحل هذه المشكلة حيث يدعم Libp2p v2.0.0 وظيفة الكشف المسبق للعقدة والتي يمكنها اكتشاف ما إذا كان يمكن توصيل العقدة مسبقًا وتجنب طلبات الاتصال غير الصالحة وتحسين كفاءة إنشاء الاتصال بشكل كبير.
اكتشاف العقدة المستندة إلى DNS
DNS هو بروتوكول يمكنه تعيين أسماء النطاقات وعناوين IP لبعضها البعض ، بحيث يمكن للأشخاص زيارة موقع الويب فقط من خلال تذكر اسم موقع ويب بسيط بدلاً من تذكر عناوين IP الخاصة بالعديد من مواقع الويب.
وبالمثل تحتاج التطبيقات الموزعة إلى معرفة العديد من العقد النشطة في الشبكة من أجل الانضمام إلى الشبكة وإنشاء اتصالات مع عقد أكثر نشاطًا حيث يقوم Java-tron بتكوين العديد من معلومات العقدة افتراضيًا في ملف التكوين وتبدأ معظم عُقد Java-tron بالانضمام إلى الشبكة من خلال هذه العقد الافتراضية مما يجعل هذه العقد تتحمل ضغط خدمة أكبر.
أفضل طريقة هي الاحتفاظ بقائمة كبيرة من العقد النشطة في مكان ما ونشر اسم المجال إلى العالم الخارجي ويمكن للعقد الأخرى الحصول على عقد في القائمة من خلال اسم المجال هذا للانضمام إلى الشبكة.
يدرك بروتوكول DNS هذه الوظيفة ويدعم بعض العقد الموثوقة في الشبكة لتصبح عُقد DNS لتلبية احتياجات العقد الأخرى في الشبكة للانضمام إلى الخدمات حيث سيؤدي اكتشاف العقدة على أساس بروتوكول DNS إلى تحسين قدرة الوصول إلى شبكة TRON بشكل كبير.
بروتوكول IPv6
بروتوكول IPV6 هو بروتوكول الإنترنت من الجيل التالي الذي يحل محل IPV4 وأثناء حل مشكلة استنفاد عنوان IP4 يتم أيضًا تحسين أداء الشبكة.
حاليًا تدعم أنظمة تشغيل الخادم السائدة كلاً من IPv4 و IPv6 لذلك لا يمكن لـ Libp2p v2.0.0 تحسين أداء شبكة TRON فحسب بل يوفر أيضًا مساحة لتوسيع بنية الشبكة المستقبلية لـ Java-tron.
ضغط الرسائل
يدعم Libp2p v2.0.0 نقل الرسائل المضغوطة والذي يمكن أن يقلل بشكل كبير من طلب Java-tron على النطاق الترددي للشبكة ، لذلك يمكنه تقليل تكلفة التشغيل والصيانة لعقد Java-tron.