يقدم GreatVoyage-v4.7.0 (Aristotle) العديد من التحسينات والتحديثات المهمة حيث تعمل آلية الحصة الجديدة “Stake 2.0” على تحسين مرونة نموذج الموارد واستقرار نظام الحصة ؛ يساعد نموذج الطاقة الديناميكي على تعزيز التنمية المتوازنة بيئيًا ؛ وتعمل آلية التخزين المؤقت الثانوية على تحسين أداء قراءة قاعدة البيانات وتحسين أداء تنفيذ المعاملات وتوسيع إنتاجية الشبكة ؛ يستخدم مكتبة “libp2p” كوحدة شبكة Java-tron P2P لجعل بنية الكود أكثر وضوحًا وتقليل اقتران الكود ؛ يحسن إخراج السجل ، ويعيد توجيه سجلات LevelDB و RocksDB إلى ملفات سجل Java-tron ؛ دمج المزيد من الأدوات والوظائف في مربع الأدوات “Toolkit.jar” لتزويد المستخدمين بتجربة تطوير أكثر ملاءمة.
يرجى الاطلاع على التفاصيل أدناه
الجوهر Cores
1.نموذج تعهد (آلية الحصة) جديد – Stake 2.0
يقدم إصدار GreatVoyage-v4.7.0 (Aristotle) نموذج حصة جديدًا “Stake 2.0” حيث يهدف إلى إنشاء نظام حصة أكثر مرونة وكفاءة واستقرارًا ومقارنة بنموذج Stake 1.0 الحالي قد تم تحسين Stake 2.0 في الجوانب التالية:
◽️ يتم الفصل بين Staking والتفويض: في Stake 1.0 ، يتم دمج Staking وتفويض الموارد في عملية واحدة حيث يجب تحديد مستلم المورد في العملية.
بعد اكتمال التخزين المؤقت سيتم تفويض المورد إلى مستلم المورد المعين ويتم أيضًا الجمع بين فك الارتباط وعدم التفويض في عملية واحدة وإذا كنت ترغب في إلغاء التفويض فيجب عليك إلغاء تثبيت TRX المقابل أيضًا ويفصل Stake 2.0 عن Staking وتفويض الموارد إلى عمليتين مستقلتين حيث ينفذ المستخدم التخزين أولاً ويتم تخصيص المورد المحدد للمالك الآن ومن ثم ينفذ عملية المفوض لتعيين المورد إلى العنوان المحدد.
يتم فصل فك الارتباط وإلغاء التفويض أيضًا إلى عمليتين وإذا أراد المستخدم إلغاء التفويض فيمكنه إجراء عملية إلغاء التفويض مباشرةً دون إلغاء التثبيت ومن ثم يمكنه تفويض المورد للآخرين مرة أخرى حسب الحاجة والفصل بين Staking / unstaking والتفويض”delegating” / إلغاء التفويض “undelegating” يبسط عمليات المستخدم ويقلل من التعقيد التشغيلي.
◽️ إدارة تجزئة الموارد: في Stake 1.0 ستؤدي عملية unstake واحدة إلى unstake كل staked TRX ، ولا يمكن unstake الكمية المحددة من TRX حيث تم تحسين هذا في Stake 2.0 الآن ، وهنا يمكننا تحديد مبلغ TRX لـ unstake ، طالما أن المبلغ المحدد أقل من إجمالي المبلغ staked أو مساويًا له ، وفي Stake 1.0 لإلغاء مفوض مورد معين يمكنك فقط إلغاء جميع الموارد المفوضة مرة واحدة ولا يمكنك الإلغاء بتحديد مبلغ.
جلبت Stake 2.0 أيضًا عدم تفويض جزئيًا ، ويمكننا الآن إلغاء تفويض جزء من الموارد المفوضة حسب الحاجة مما يحسن مرونة إدارة الموارد.
◽️ فترة قفل Unstake والوصول المتأخر لـ TRX الغير المتعهد Unstaked: في stake1.0 بعد staking TRX ، نحتاج إلى الانتظار 3 أيام قبل إسترجاع TRX وبعد الإصدار ستصل TRX staked على الفور إلى حساب المالك ، في Stake 2.0 بعد اكتمال عملية Staking يمكن تحرير TRX staked في أي وقت ولكن يجب أن تنتظر بعض “N” أيام.
بعد تأخير “N” أيام ، يمكن سحب TRX الذي تم إصداره إلى حساب المالك ، “N” هي معيار شبكة TRON وعندما يتقلب سوق TRX بشكل عنيف بسبب تأخر وصول الأموال فإنه لن يؤدي بعد ذلك إلى إطلاق عدد كبير من عمليات stake أو Unstake ، مما يحسن من استقرار نموذج stake ، وفي نفس الوقت لن يتسبب في عدد كبير من الأموال التي تتدفق إلى السوق وتؤدي إلى تفاقم تقلبات السوق ويساعد على بناء مستقبل متوقع أكثر لتداول الشبكة بالكامل للمشاركين في الشبكة.
يدعم TVM Staking وإدارة الموارد: في Stake 2.0 ، تدمج آلة TRON الافتراضية التعليمات المتعلقة بإدارة الأسهم والموارد ويمكن للمستخدمين إجراء عمليات Stake /أو Unstake TRX في العقود الذكية ، وكذلك تنفيذ عمليات تفويض / إلغاء تفويض الموارد.
لمزيد من التفاصيل حول Stake 2.0 يرجى الرجوع إلى ما هو Stake 2.0؟
آلية الحصة الجديدة هي معيار ديناميكي في شبكة TRON ، بعد نشر GreatVoyage-v4.7.0 (Aristotle) ، يتم تعطيله افتراضيًا ويمكن تمكينه عن طريق بدء تصويت الاقتراح.
معلومات: https://github.com/tronprotocol/tips/issues/467
كود المصدر: https://github.com/tronprotocol/java-tron/pull/4838
2.تحسين أداء استعلام قاعدة البيانات
يستخدم Java-tron قواعد بيانات الذاكرة والقرص لتخزين البيانات وسيتم تخزين بيانات الكتلة الصلبة في قواعد بيانات متعددة على القرص وسيتم تخزين البيانات غير الموحدة في الذاكرة.
عندما يتم ترسيخ الكتلة تتم كتابة البيانات الموجودة في الذاكرة المقابلة في قواعد بيانات القرص وعند الاستعلام عن البيانات استفسر أولاً عن البيانات الموجودة في الذاكرة وإذا لم يتم العثور عليها ثم استعلم عن قاعدة بيانات القرص واستعلام قاعدة بيانات القرص يستغرق وقتًا طويلاً لذلك فإن إصدار GreatVoyage-v4.7.0 (Aristotle) يحسن أداء استعلام قاعدة البيانات ويضيف ذاكرة تخزين مؤقت ثانوية قبل تنفيذ عملية قاعدة بيانات القرص الأساسي.
عند كتابة البيانات على القرص تتم كتابة البيانات أيضًا في ذاكرة التخزين المؤقت من المستوى الثاني وعند الحاجة إلى الاستعلام عن قاعدة بيانات القرص إذا كانت البيانات المطلوب الاستعلام عنها موجودة في ذاكرة التخزين المؤقت من المستوى الثاني فسيتم إرجاعها مباشرة دون الاستعلام عن قاعدة بيانات القرص وتعمل ذاكرة التخزين المؤقت من المستوى الثاني على تقليل عدد الاستعلامات إلى قاعدة بيانات القرص وتحسين سرعة تنفيذ المعاملات وتحسين سرعة نقل الشبكة.
كود المصدر: https://github.com/tronprotocol/java-tron/pull/4740
3.تحسين عملية إنتاج الكتلة
عندما تنتج العقدة كتلة فإنها ستتحقق وتنفذ بالتسلسل جميع المعاملات التي يمكن تعبئتها في الكتلة ، وسيشمل التحقق من المعاملة وتنفيذها الحصول على بيانات الكتلة ، مثل رقم الكتلة ، وحجم الكتلة ، ومعلومات معاملة الكتلة إلخ. في الإصدارات السابقة لـ GreatVoyage-v4.7.0 (Aristotle) ، عندما تقوم بحزم المعاملات ، تتم إعادة حساب بيانات الكتلة أثناء عملية التحقق من كل معاملة وتنفيذها ، والتي تتضمن العديد من العمليات الحسابية المتكررة.
من أجل تحسين كفاءة معاملات التعبئة والتغليف تعمل GreatVoyage-v4.7.0 (Aristotle) على تحسين عملية إنتاج الكتل وتحسب فقط بيانات الكتلة مرة واحدة وتقوم بتحديث البيانات فقط عند الضرورة وبالتالي تقليل عدد حسابات بيانات الكتلة وتحسينها بشكل كبير كفاءة تغليف الكتلة.
كود المصدر: https://github.com/tronprotocol/java-tron/pull/4756
4.إضافة ذاكرة التخزين المؤقت للصفقة
عندما تعالج العقدة كتلة ، فإنها ستستخدم قيمة تجزئة المعاملة عدة مرات. في الإصدارات السابقة لـ GreatVoyage-v4.7.0 (Aristotle) ، يتم حساب قيمة تجزئة المعاملة كما يتم استخدامها ، ويستغرق حساب قيمة تجزئة المعاملة وقتًا طويلاً ، مما يؤدي إلى إبطاء معالجة الكتلة لذلك تضيف GreatVoyage-v4.7.0 (Aristotle) ذاكرة تخزين مؤقت لتجزئة المعاملة وسيتم الحصول على تجزئة المعاملة مباشرة من ذاكرة التخزين المؤقت عند استخدامها. فقط عندما تتغير بيانات المعاملة حيث تتم إعادة حساب تجزئة المعاملة. تعمل ذاكرة التخزين المؤقت المضافة حديثًا على تقليل عمليات حساب تجزئة المعاملات غير الضرورية وتحسين سرعة معالجة الكتلة.
كود المصدر: https://github.com/tronprotocol/java-tron/pull/4792
5.إضافة وحدة libp2p كتطبيق بروتوكول شبكة Java-tron p2p
بدءًا من GreatVoyage-v4.7.0 (Aristotle) ، سيتم استخدام مكتبة libp2p مباشرةً كوحدة شبكة P2P في Java-tron بدلاً من استخدام مكدس شبكة p2p الأصلي بحيث تكون بنية الشفرة أكثر وضوحًا ويكون اقتران الكود أقل ، ويسهل صيانته.
كود المصدر: https://github.com/tronprotocol/java-tron/pull/4791
TVM (آلة ترون الفتراضية/جهاز ترون الظاهري)
1. إضافة تعليمات جديدة لدعم Stake 2.0
تقدم GreatVoyage-v4.7.0 (Aristotle) نموذج Stake 2.0 ، وستدعم TVM تعليمات Stake 2.0 ذات الصلة بـ stake ومندوبي الموارد/التفويض في وقت واحد حيث يمكن للمستخدمين إجراء عمليات تفويض الأسهم والموارد من خلال العقود الذكية مما يزيد من إثراء سيناريوهات التطبيق للعقود الذكية على شبكة TRON وقد تمت إضافة ما مجموعه 6 إرشادات من 0xda إلى 0xdf وإجمالي 11 عقدًا مترجمًا مسبقًا من 0x100000b إلى 0x1000015 إلى TVM:
Stake 2.0 هي معيار ديناميكي في شبكة TRON ، بعد نشر GreatVoyage-v4.7.0 (Aristotle) يتم تعطيله افتراضيًا ويمكن تمكينه عن طريق بدء تصويت الاقتراح.
معلومات: https://github.com/tronprotocol/tips/issues/467
كود المصدر: https://github.com/tronprotocol/java-tron/pull/4872
2. نموذج الطاقة الديناميكي (Dynamic energy model)
نموذج الطاقة الديناميكي عبارة عن مخطط لتعديل استهلاك الطاقة المستقبلي للعقد ديناميكيًا بناءً على استخدام الطاقة المعروف في العقد وإذا كان العقد يستخدم الكثير من الموارد في دورة واحدة فإن الدورة التالية في هذا العقد حيث ستتم إضافة نسبة معينة من الاستهلاك العقابي وسيكلف المستخدمون الذين يرسلون نفس المعاملة إلى هذا العقد طاقة أكثر من ذي قبل وعندما يستخدم العقد الموارد بشكل معقول فإن استهلاك الطاقة الذي يولده المستخدم الذي يتصل بالعقد سيعود تدريجياً إلى طبيعته. من خلال هذه الآلية ، سيكون تخصيص موارد الطاقة على السلسلة أكثر منطقية وسيتم منع التركيز المفرط لموارد الشبكة على عدد قليل من العقود.
لمزيد من المعلومات حول نموذج الطاقة الديناميكي: مقدمة في نموذج الطاقة الديناميكي
نموذج الطاقة الديناميكي هو معيار ديناميكي في شبكة TRON ، بعد نشر GreatVoyage-v4.7.0 (Aristotle) ، يتم تعطيله افتراضيًا ويمكن تمكينه عن طريق بدء تصويت الاقتراح.
معلومات: https://github.com/tronprotocol/tips/issues/491
كود المصدر: https://github.com/tronprotocol/java-tron/pull/4873
3. تحسين قيمة الإرجاع لرمز التشغيل chainId
بدءًا من إصدار GreatVoyage-v4.7.0 (Aristotle) يتم تغيير القيمة المرتجعة لرمز التشغيل المتسلسل من تجزئة كتلة كتلة التكوين إلى آخر أربع بايتات من تجزئة الكتلة من كتلة التكوين ومع الحفاظ على القيمة المرجعة لـ chainid opcode المتوافقة مع القيمة المرجعة لواجهة برمجة التطبيقات eth_chainId Java-tron JSON-RPC.
يعد تحسين قيمة الإرجاع لرمز التشغيل chainId معيار ديناميكي لشبكة TRON حيث يتم تعطيله افتراضيًا بعد نشر GreatVoyage-v4.7.0 (Aristotle) ، ويمكن تمكينه عن طريق بدء اقتراح.
معلومات: https://github.com/tronprotocol/tips/issues/474
كود المصدر: https://github.com/tronprotocol/java-tron/pull/4863
API
1. إضافة واجهات برمجة التطبيقات لدعم Stake 2.0
تضيف GreatVoyage-v4.7.0 (Aristotle) ما مقدارة 10 من واجهات برمجة تطبيقات لدعم Stake 2.0:
للحصول على معلومات مفصلة عن واجهات برمجة التطبيقات الجديدة ، يرجى الرجوع إلى: ما هو Stake 2.0؟
https://coredevs.medium.com/what-is-stake-2-0-e04f59b948a6
معلومات: https://github.com/tronprotocol/tips/issues/467
كود المصدر: https://github.com/tronprotocol/java-tron/pull/4838
2. إضافة تقدير الطاقة API
في الإصدارات السابقة لـ GreatVoyage-v4.7.0 (Aristotle) يمكن للمستخدمين تقدير استهلاك الطاقة لتنفيذ معاملات العقد الذكية من خلال واجهة /wallet/triggerconstantcontract ، ثم تعيين معيار feelimit للمعاملة وفقًا للاستهلاك المقدر ومع ذلك نظرًا لأن بعض معاملات العقود الذكية قد تستدعي عقودًا ذكية أخرى فمن المحتمل أن يكون معيار feelimit المقدر غير دقيق.
لذلك فإن إصدار GreatVoyage-v4.7.0 (Aristotle) يضيف واجهة تقدير الطاقة / المحفظة / الطاقة التقديرية ، ومدى الإحساس المقدر بواسطة هذه الواجهة يمكن الاعتماد عليه في أي حال. يشير الحقل Energy_required في القيمة المرجعة لهذه الواجهة إلى المقدار المقدّر للطاقة المطلوبة للتنفيذ الناجح لمعاملة العقد الذكي هذه لذلك يمكن للمستخدم حساب معيار feelimit بناءً على هذا المجال: feelimit = الطاقة_المطلوبة energy_required * سعر وحدة الطاقة ، حاليًا سعر الوحدة للطاقة هو 420 sun.
إذا فشل تنفيذ استدعاء الواجهة المقدرة لسبب ما فستكون قيمة حقل الطاقة المطلوب 0 ، ولن يتم عرض هذا الحقل في القيمة المرجعة وفي هذا الوقت يمكنك التحقق من سبب فشل التنفيذ لاستدعاء الواجهة المقدرة من خلال حقل النتيجة.
بعد نشر إصدار GreatVoyage-v4.7.0 (Aristotle) بنجاح سيتم إغلاق واجهة برمجة التطبيقات هذه افتراضيًا ولفتح هذه الواجهة يجب تمكين عنصري التكوين vm.estimateEnergy و vm.supportConstant في ملف تكوين العقدة في نفس الوقت والقيم الافتراضية لكل من vm.estimateEnergy و vm.supportConstant كلاهما خاطئان.
كود المصدر: https://github.com/tronprotocol/java-tron/pull/4873
تغييرات أخرى
1. تحسين معايير تجميع Gradle
تعمل GreatVoyage-v4.7.0 (Aristotle) على تحسين معايير التجميع لـ Gradle ، وتكوين JVM الحد الأدنى لحجم الكومة إلى 1 جيجابايت ، مما يحسن سرعة تجميع Java-tron.
كود المصدر: https://github.com/tronprotocol/java-tron/pull/4837
2. تحسين وظيفة عقدة الإيقاف المشروط (node conditional stop function)
من أجل تسهيل النسخ الاحتياطي للبيانات أو إحصائيات البيانات لجهات نشر العقدة بدءًا من GreatVoyage-v4.5.1 (Tertullian) حيث تدعم العقد التوقف في ظل ظروف محددة ويمكن للمستخدمين تعيين شروط توقف العقدة من خلال ملف تكوين العقدة وسوف تتوقف العقدة عن العمل عند استيفاء الشروط ، ويدعم ثلاثة شروط توقف يتم تعيينها في نفس الوقت ويتم إيقاف العقدة عند استيفاء أي شرط حيث تتضمن هذه الشروط الثلاثة وقت الكتلة ، وارتفاع الكتلة ، وعدد الكتل التي يجب مزامنتها من بداية العقدة إلى نهايتها ومع ذلك نظرًا لأنه يُسمح بتعيين شروط الإيقاف المتعددة في نفس الوقت وعندما يحتاج المستخدم فقط إلى شرط واحد ويجب حذف عنصري التكوين الشرطي الآخرين في ملف التكوين لذلك إذا نسي المستخدم الحذف فقد توقف عند كتلة غير متوقعة ومع ذلك لا توجد في الواقع سيناريوهات تطبيق تتطلب تعيين شروط متعددة في نفس الوقت.
لذلك فإن إصدار GreatVoyage-v4.7.0 (Aristotle) يعمل على تحسين وظيفة الإيقاف الشرطي للعقدة وتظل معايير التكوين الاختيارية بدون تغيير ولكن يُسمح بتعيين معيار واحد صالح فقط في نفس الوقت وإذا قام ناشر العقدة بتعيين معايير متعددة فستقوم العقدة بالإبلاغ عن خطأ وتخرج من التشغيل ويبسط هذا التحسين تعقيد إعدادات المستخدمين.
كود المصدر: https://github.com/tronprotocol/java-tron/pull/4853 https://github.com/tronprotocol/java-tron/pull/4858
3. حذف التعليمات البرمجية المتعلقة بقاعدة البيانات v1
في الإصدارات السابقة لـ GreatVoyage-v4.7.0 (Aristotle) يوجد إصداران من قاعدة البيانات v1 و v2 حيث يمكن للمستخدمين الاختيار من بينها من خلال عنصر التكوين db.version ، ونظرًا لأن الإصدار v2 يعتمد وضع قاعدة بيانات الذاكرة + القرص ، فإنه يدعم توسيع قاعدة البيانات الأساسية ووظيفة استعادة البيانات الصحيحة في ظل ظروف غير طبيعية وما إلى ذلك ، وله مزايا واضحة مقارنة بـ v1. لذلك ومن أجل جعل بنية الكود أكثر وضوحًا بدءًا من GreatVoyage-v4.7.0 (Aristotle) يتم حذف الكود المتعلق بإصدار قاعدة البيانات v1 وعنصر تكوين إصدار قاعدة البيانات db.version ولم يعد المستخدمون بحاجة إلى تكوين إصدار قاعدة البيانات فقط الإصدار 2 متاح من الآن فصاعدًا ، مما يقلل من تعقيد تكوين العقد.
كود المصدر: https://github.com/tronprotocol/java-tron/pull/4836
4. تحسين إخراج سجل قاعدة البيانات
في الإصدارات السابقة لـ GreatVoyage-v4.7.0 (Aristotle) ، لا تتضمن سجلات العقدة مخرجات السجلات الأساسية بواسطة LevelDB أو RocksDB نفسها مما يجعل من الصعب استكشاف مشكلات قراءة وكتابة قاعدة البيانات لذلك يقوم GreatVoyage-v4.7.0 (Aristotle) بتحسين سجل قاعدة البيانات وإعادة توجيه إخراج السجل الأساسي لوحدة بيانات LevelDB أو RocksDB إلى ملف سجل العقدة ، مما يبسط صعوبة استكشاف أخطاء قاعدة البيانات وتحسين موثوقية تشغيل العقدة وكفاءة الصيانة.
كود المصدر: https://github.com/tronprotocol/java-tron/pull/4833
5. جعل سرعة تدفق لقطة شكلي
تحتاج العقد المضافة حديثًا إلى الشبكة إلى مزامنة بيانات الكتلة من العقد الأخرى وستقوم العقد أولاً بحفظ بيانات الكتلة المتزامنة في الذاكرة من ثم تخزينها على القرص. في الإصدارات السابقة لـ GreatVoyage-v4.7.0 (Aristotle) وعندما تزامن العقدة الكتل ، ستكتب عملية التدفق بيانات 500 كتلة من الذاكرة إلى القرص ، لذلك سيتم الاحتفاظ بأكثر من 500 كتلة من البيانات في الذاكرة وكل كتلة بيانات مرتبطة بقائمة مرتبطة وعند الاستعلام عن البيانات سيقوم أولاً بالبحث في أكثر من 500 كتلة متتالية من ثم الاستعلام عن قاعدة بيانات القرص عندما لا يتم العثور على البيانات المطلوب الاستعلام عنها ولكن اجتياز أكثر من 500 كتلة من البيانات يقلل من كفاءة استعلام البيانات.
لذلك بدءًا من إصدار GreatVoyage-v4.7.0 (Aristotle) يمكن تكوين عدد تدفق اللقطات ويمكن ضبط الحد الأقصى لعدد تدفق اللقطات في وقت واحد من خلال عنصر التكوين: storage.snapshot.maxFlushCount لتعظيم كفاءة استعلام قاعدة البيانات وتحسين سرعة معالجة الكتلة وإذا لم يتم تعيين عنصر التكوين فإن الحد الأقصى لعدد اللقطات المتدفقة في الطبق هو القيمة الافتراضية 1.
كود المصدر: https://github.com/tronprotocol/java-tron/pull/4834
6. تكامل Toolkit.jar
DBConvert.jar هي أداة تحويل قواعد البيانات والتي يمكنها تحويل LevelDB إلى RocksDB ؛ LiteFullNodeTool.jar هي أداة FullNode خفيفة ، يمكنها تحويل بيانات FullNode إلى بيانات LiteFullNode ، وبدءًا من GreatVoyage-v4.7.0 (Aristotle) ، تم دمج DBConvert.jar و LiteFullNodeTool.jar في مربع أدوات Toolkit.jar ، وتمت إضافة وظيفة نسخ قاعدة البيانات التي يمكنها تحقيق نسخ سريع لقاعدة بيانات العقدة وفي المستقبل سيتم دمج الأدوات حول Java-tron تدريجيًا في مربع الأدوات Toolkit.jar من أجل تسهيل صيانة الأداة واستخدام المطور والأوامر الخاصة باستخدام الوظائف الجديدة في Toolkit.jar toolbox هي كما يلي:
كود المصدر: https://github.com/tronprotocol/java-tron/pull/4813
الشجاعة هي أول صفات الإنسان لأنها الصفة التي تضمن للآخرين الجودة. – – أرسطو
المصدر: TRON Core Devs19