مقدمة GreatVoyage-v4.6.0 (Socrates)
يقدم GreatVoyage-v4.6.0 (Socrates) العديد من التحسينات والتحديثات المهمة مثل آلية نقطة تفتيش قاعدة البيانات المحسنة والتي تعمل على تحسين استقرار تشغيل العقدة ؛ هيكل مؤشر علاقة مفوض الموارد المحسن ، وخوارزمية مكافأة التصويت المحدثة ، والتي تسرع سرعة تنفيذ المعاملات وتزيد من إنتاجية الشبكة ؛ اقتراح جديد لإضافة رسوم مذكرة المعاملات ، وزيادة تكلفة المعاملات مع المذكرات لتقليل عدد المعاملات منخفضة القيمة بحيث يحسن أمن وموثوقية شبكة TRON.
توفر مجموعة الأدوات المتكاملة ومقاييس Prometheus الجديدة المتعلقة بالشبكة وسطر أوامر التعليمات الجديد للمستخدمين تجربة تطوير أكثر ملاءمة.
يرجى التحقق أدناه للحصول على التفاصيل:
1.تحسين بنية فهرس علاقة المفوض
في شبكة TRON ، يمكن للحسابات تفويض الموارد إلى حسابات أخرى من خلال Staking ، ويمكنها أيضًا قبول الموارد التي تشاركها حسابات أخرى لأنفسهم.
لذلك يحتاج كل حساب إلى الاحتفاظ بسجل لعلاقة المفوض بما في ذلك كافة عناوين المستلمين التي قام الحساب بتفويض الموارد إليها وكافة العناوين التي فوضت الموارد للحساب.
في الإصدارات السابقة لـ GreatVoyage-v4.6.0 (Socrates) ، يتم تخزين علاقة المفوض في شكل قائمة عند إجراء تفويض المورد ، يجب أولاً التحقق مما إذا كان حساب المستلم موجودًا بالفعل في القائمة ثم يضيف الحساب إلى القائمة فقط إذا لم يكن موجودًا.
إذا قام حساب معين بتفويض موارد لحسابات متعددة أو قامت العديد من الحسابات بتفويض الموارد إلى الحساب المحدد فسيكون طول قائمة علاقة المفوض للحساب المعين كبيرًا. ستستغرق عملية البحث وقتًا طويلاً ، مما يؤدي إلى إطالة أوقات تنفيذ المعاملة.
لذلك تعمل GreatVoyage-v4.6.0 (Socrates) على تحسين بنية تخزين الفهرس لعلاقة مفوض المورد وتغييرها من قائمة إلى زوج ذي قيمة مفتاح وذلك لإكمال الاستعلام وتعديل بياناتها في وقت ثابت والذي يسرع بشكل كبير من سرعة تنفيذ المعاملات المتعلقة بالتفويض ويحسن معدل نقل الشبكة.
تحسين تخزين علاقة المفوض هو معلمة ديناميكية لشبكة TRON حيث يتم تعطيله افتراضيًا ويمكن تمكينه من خلال بدء اقتراح.
نصيحة: https://github.com/tronprotocol/tips/issues/476
كود المصدر: https://github.com/tronprotocol/java-tron/pull/4788
2.إضافة اقتراح رسوم مذكرة المعاملة
بدءًا من GreatVoyage-v4.6.0 (Socrates) يمكن فرض رسوم المذكرات على المعاملات المتعلقة بالمذكرة ومن خلال زيادة التكلفة ، ستؤدي الرسوم إلى تقليل عدد المعاملات منخفضة القيمة وذلك لتحسين أمان وموثوقية شبكة TRON.
رسوم المذكرة هي معلمة ديناميكية لشبكة TRON وبعد نشر GreatVoyage-v4.6.0 (Socrates) ، تكون القيمة الافتراضية “صفر” والوحدة هي “sun”.
يمكن تمكينه من خلال تحديد قيمة غير صفرية عن طريق بدء عرض ، على سبيل المثال ، “1000000” ، مشيرًا إلى أن المعاملة مع المذكرة ستتطلب رسومًا إضافية بقيمة 1 TRX.
نصيحة: https://github.com/tronprotocol/tips/issues/387
كود المصدر: https://github.com/tronprotocol/java-tron/pull/4758
3.إضافة اقتراح خوارزمية المكافأة الأمثل
سيجمع العديد من الناخبين في شبكة TRON المكافآت لفترة طويلة قبل سحبها وغالبًا ما تكون الفترة الفاصلة بين عمليتي سحب للمكافآت طويلة جدًا وفي الإصدارات السابقة لـ GreatVoyage-v4.6.0 (Socrates) ، لكي تسحب المعاملة المكافآت ، فإنها ستحسب وتجمع المكافآت لكل فترة صيانة منذ آخر سحب للمكافآت لذلك كلما طال الوقت منذ آخر سحب للمكافآت وسيستغرق حساب المكافأة وقتًا أطول.
لذلك يعمل GreatVoyage-v4.6.0 (Socrates) على تحسين خوارزمية حساب مكافآت التصويت. بدلاً من تجميع مكافآت كل فترة صيانة ، يمكن الحصول على مجموع المكافآت غير المسحوبة عن طريق طرح العدد الإجمالي للمكافآت المسجلة في فترة الصيانة لآخر سحب مكافأة من إجمالي المكافآت المسجلة في فترة الصيانة السابقة.
تدرك هذه الخوارزمية حساب العدد الإجمالي للمكافآت غير المطالب بها في وقت ثابت ، مما يحسن بشكل كبير من كفاءة الحساب ويسرع تنفيذ حساب المكافأة ، وبالتالي تحسين إنتاجية الشبكة.
خوارزمية المكافأة المحسّنة هي معلمة شبكة TRON ويتم تعطيلها افتراضيًا بمجرد نشر GreatVoyage-v4.6.0 (Socrates) ، ويمكن تمكينها من خلال التصويت من خلال اقتراح.
نصيحة: https://github.com/tronprotocol/tips/issues/465
كود المصدر: https://github.com/tronprotocol/java-tron/pull/4694
4.ترقية آلية نقطة التفتيش إلى الإصدار 2 في وحدة قاعدة البيانات
Checkpoint هي آلية استرداد تم إنشاؤها لمنع تلف قاعدة البيانات الناجم عن الإغلاق الاستثنائي حيث يستخدم Java-Tron ذاكرة وقواعد بيانات متعددة الأقراص لتخزين البيانات.
سيتم تخزين بيانات الكتلة الصلبة في قواعد بيانات أعمال متعددة ويتم تخزين البيانات غير الموحدة في الذاكرة وعندما يتم ترسيخ الكتلة ، ستتم كتابة بيانات الذاكرة المقابلة في قواعد البيانات ذات الصلة ومع ذلك نظرًا لأن الكتابة إلى قواعد بيانات أعمال متعددة ليست عملية ذرية ، إذا كان هناك توقف غير متوقع لسبب ما ، فقد لا تتمكن من كتابة جميع البيانات الموجودة في الكتلة على القرص ، ولن تكون العقدة كذلك قادرة على إعادة التشغيل بسبب تلف قاعدة البيانات.
لذلك قبل كتابة بيانات الذاكرة على القرص وسيتم إنشاء Checkpoint وتحتوي Checkpoint على جميع البيانات التي يجب كتابتها في كل قاعدة بيانات أعمال هذه المرة وبعد إنشاء Checkpoint ، يكتب أولاً بيانات Checkpoint إلى قاعدة بيانات Checkpoint مستقلة ، ثم يقوم بعملية كتابة قاعدة بيانات الأعمال وتحتفظ قاعدة بيانات Checkpoint دائمًا بأحدث بيانات الكتلة الصلبة وفي حالة تلف قاعدة بيانات الأعمال بسبب إيقاف تشغيل النظام بعد إعادة تشغيل العقدة وسيتم استرداد قاعدة بيانات الأعمال من خلال البيانات المحفوظة مسبقًا في قاعدة بيانات Checkpoints.
في الوقت الحالي يمكن لآلية Checkpoint التعامل مع الغالبية العظمى من حالات التوقف ولكن لا يزال هناك احتمال ضئيل بأن قاعدة بيانات الأعمال سوف تتضرر بسبب التعطل وفي الوقت الحاضر كتابة البيانات في LevelDB غير متزامنة ويستدعي البرنامج LevelDB لطلب كتابة البيانات على القرص.
في الواقع تتم كتابة البيانات فقط في ذاكرة التخزين المؤقت لنظام التشغيل ومن ثم سيقرر نظام التشغيل الوقت الفعلي للكتابة على القرص وفقًا لإستراتيجيته الخاصة وإذا حدث تعطل غير متوقع في الوقت الذي انتهت فيه العقدة للتو من الكتابة إلى قاعدة بيانات Checkpoint واستمرت في الكتابة إلى قاعدة بيانات الأعمال فمن المحتمل أن البيانات المكتوبة في قاعدة بيانات Checkpoint لم تتم كتابتها فعليًا على القرص بواسطة نظام التشغيل وفي هذه الحالة قد تفشل العقدة في إعادة التشغيل بشكل صحيح لأن قاعدة بيانات Checkpoint لا تحتوي على بيانات استرداد.
لحل هذه المشكلة قام GreatVoyage-v4.6.0 (Socrates) بترقية تطبيق Checkpoint إلى الإصدار V2 وستقوم آلية Checkpoint V2 بتخزين بيانات كتل صلبة متعددة.
لذلك حتى إذا لم تتم كتابة أحدث بيانات الكتلة الصلبة بنجاح إلى قاعدة بيانات Checkpoint بسبب الإغلاق غير الطبيعي حيث يمكن استخدام بيانات الكتلة التاريخية الصلبة لاستعادة قاعدة بيانات الأعمال عند إعادة تشغيل العقدة.
يتم تعطيل آلية Checkpoint V2 افتراضيًا في ملف التكوين ويمكن تمكين هذه الوظيفة عن طريق تعديل التكوين وتجدر الإشارة إلى أنه إذا قامت العقدة بتمكين نقطة التحقق V2 وتشغيلها لفترة زمنية معينة فلن تتمكن من التراجع إلى V1 بعد الآن.
نصيحة: https://github.com/tronprotocol/tips/issues/461
كود المصدر: https://github.com/tronprotocol/java-tron/pull/4614
5.تحسين أولوية إنتاج الكتلة بين العقد النشطة والعقد الاحتياطية
إذا قام الممثل الممتاز بنشر العقد النشطة والنسخ الاحتياطي فسيتم الحفاظ على الاتصال بين العقد ، وعندما يتم فصل العقد النشطة والنسخ الاحتياطي مؤقتًا بسبب مشاكل في الشبكة ستعتبر العقدة الاحتياطية أن العقدة النشطة غير صالحة وتتولى إنتاج الكتلة.
سيؤدي هذا إلى عملية إنتاج كتلة مكررة حيث ستنتج كل من العقد النشطة والعقد الاحتياطية كتل في نفس الوقت وفي الإصدارات السابقة لـ GreatVoyage-v4.6.0 (Socrates) ، عندما تتلقى العقدان النشطة والاحتياطية كتلًا من نفس كتلة الارتفاع تم إنشاؤها بواسطة بعضها البعض ، فسيتم تعليق كل منهما من 1 إلى 9 دورات إنتاج بلوك. أي أن الممثل الفائق سيفتقد من 1 إلى 9 كتل.
تعمل GreatVoyage-v4.6.0 (Socrates) على تحسين أولوية منطق إنتاج الكتل. عندما يحدث الموقف أعلاه وستقارن كلا العقدتين قيمة التجزئة للكتلة التي تنتجها العقدة الأخرى.
ستستمر العقدة ذات تجزئة الكتلة الأكبر في إنتاج الكتل وستقوم العقدة ذات تجزئة الكتلة الأصغر بتعليق دورة إنتاج الكتلة ثم تستمر في إنتاج الكتل ، ومقارنة تجزئة الكتلة مرة أخرى.
سيقوم ما مجموعه 27 من الممثلين المتميزين بإنشاء الكتل بالتتابع لذلك يستغرق الأمر 81 ثانية لتخطي دورة إنتاج الكتله ، خلال هذه الفترة إذا كانت مشكلة الاتصال بينهما هي فشل قصير المدى في الشبكة فسيكون هناك وقت كافٍ لاستعادتها.
بالإضافة إلى ذلك بعد تلقي هاتين الكتلتين ستختار العقد الأخرى أيضًا الكتلة ذات التجزئة الأكبر وتتجاهل الكتلة التي تحتوي على تجزئة أصغر وسيؤدي هذا التنفيذ إلى تحسين كفاءة إنتاج الكتلة بشكل كبير أثناء اتصالات الشبكة المعوقة بين العقد النشطة والنسخ الاحتياطي واستقرار الشبكة.
كود المصدر: https://github.com/tronprotocol/java-tron/pull/4630
6.تحسين خوارزمية Kademlia لوحدة الشبكة
معرف عقدة Java-Tron هو رقم عشوائي ، سيتم تجديده في كل مرة يتم فيها بدء العقدة. في تنفيذ خوارزمية Kademlia لـ Java-Tron وسيتم حساب مسافة العقدة وفقًا لمعرف العقدة ، ثم سيتم وضع معلومات العقدة في K bucket المقابل وفقًا للمسافة.
إذا تمت إعادة تشغيل العقدة في K bucket لسبب ما ، فسيتغير معرف العقدة وعندما يتم اكتشاف أن العقدة غير متصلة بالإنترنت مرة أخرى فإن المسافة المحسوبة وفقًا لمعرف العقدة الأخير لم تتمكن من تحديد موقع K bucket الأصلي ، وبالتالي لا يمكنها حذف العقدة node من bucket وسيؤدي إعادة تشغيل عدد كبير جدًا من هذه العقد إلى تخزين الكثير من البيانات غير الصالحة في K bucket الخاصة بالعقدة.
لذلك تعمل GreatVoyage-v4.6.0(Socrates) على تحسين خوارزمية Kademlia ، وتستخدم جدول تجزئة لتسجيل العقد المكتشفة ويتم حساب مسافة العقدة مرة واحدة فقط عندما يتم كتابتها في K bucket لأول مرة ويتم تخصيصها لحقل “المسافة” للعقدة ، ثم تتم إضافة العقدة إلى جدول التجزئة.
في المستقبل سيتم الحصول على مسافة العقدة مباشرة من خلال هذا المجال وحتى إذا تغير معرف العقدة بعد إعادة تشغيل العقدة ، فلن يتم تحديث مسافة العقدة في جدول التجزئة.
عندما يتم اكتشاف أن العقدة غير متصلة ، يمكن العثور على العقدة المقابلة من جدول التجزئة وفقًا لعقد IP ومن ثم يمكن الحصول على المسافة إلى العقدة من خلال حقل مسافة العقدة ، وأخيراً يمكن حذف معلومات العقدة من K bucket.
كود المصدر:
https://github.com/tronprotocol/java-tron/pull/4620
https://github.com/tronprotocol/java-tron/pull/4622
تغييرات أخرى
1.دمج ArchiveManifest.jar في Toolkit.jar
ArchiveManifest.jar هو أداة تحسين بدء تشغيل LevelDB مستقلة والتي يمكنها تحسين حجم ملف بيان LevelDB وبالتالي تقليل استخدام الذاكرة وتحسين سرعة بدء العقدة بشكل كبير.
بدءًا من GreatVoyage-v4.6.0 (Socrates) ، تم دمج أداة ArchiveManifest.jar في Toolkit.jar وفي المستقبل سيتم دمج جميع الأدوات حول Java-Tron تدريجيًا في مربع الأدوات Toolkit.jar لتسهيل صيانة الأداة واستخدام المطور.
كود المصدر: https://github.com/tronprotocol/java-tron/pull/4603
2.إضافة مقاييس بروميثيوس prometheus لوحدة الشبكة
تضيف GreatVoyage-v4.6.0 (Socrates) ثلاثة مقاييس بروميثيوس جديدة تتعلق بوحدة الشبكة: تأخير جلب الكتلة ، وتأخير تلقي الكتلة ، وتأخير معالجة الرسائل حيث تساعد المقاييس الجديدة في مراقبة صحة الشبكة للعقدة.
كود المصدر: https://github.com/tronprotocol/java-tron/pull/4626
3.إضافة خيار الأمر – تعليمات
تضيف GreatVoyage-v4.6.0 (Socrates) خيارات سطر الأوامر “مساعدة” للتحقق من جميع المعايير والتعليمات ، يرجى التحقق من المثال أدناه:
$ java -jar FullNode.jar –help
Name:
FullNode – the java-tron command line interface
Usage: java -jar FullNode.jar [options] [seedNode <seedNode> …]
VERSION:
4.5.2-d05f766
TRON OPTIONS:
-v, –version Output code version
-h, –help Show help message
-c, –config Config file (default:config.conf)
–log-config Logback config file
–es Start event subscribe server
DB OPTIONS:
-d, –output-directory Data directory for the databases (default:output-directory)
WITNESS OPTIONS:
-w, –witness Is witness node
-p, –private-key Witness private key
VIRTUAL MACHINE OPTIONS:
–debug Switch for TVM debug mode. In debug model, TVM will not check for timeout. (default: false)
كود المصدر: https://github.com/tronprotocol/java-tron/pull/4606
4.تحسين LiteFullNodeTool.jar
LiteFullNodeTool.jar هي أداة عقدة خفيفة لجافا ترون وتتمثل مهمتها الرئيسية في تحويل قاعدة بيانات fullnode إلى قاعدة بيانات عقدة خفيفة. تعمل GreatVoyage-v4.6.0 (Socrates) على تحسين الأداة وتحسين راحة وثبات الأداة.
كود المصدر: https://github.com/tronprotocol/java-tron/pull/4607
5.تحسين القيمة المرجعة لواجهات برمجة تطبيقات eth_getBlockByHash و eth_getBlockByNumber
من أجل أن تكون متوافقة بشكل أفضل مع واجهة بروتوكول Ethereum’s JsonRPC 2.0 ، تقوم GreatVoyage-v4.6.0 (Socrates) بتغيير وحدة حقل “الطابع الزمني” في القيمة المرجعة لواجهات برمجة تطبيقات eth_getBlockByHash و eth_getBlockByNumber من مللي ثانية إلى ثوانٍ ، مما يجعل قيم الإرجاع لـ هاتان واجهتا برمجة التطبيقات متوافقان تمامًا مع Ethereum Geth.
كود المصدر: https://github.com/tronprotocol/java-tron/pull/4642
لتحريك العالم يجب علينا تحريك أنفسنا. – – سقراط
المصدر: TRON Core Devs