GRIDNET Core 1.4.4 Release Notes
Greetings Operators and users alike! The team at GRIDNET is excited to present the latest iteration of our Core system, version 1.4.4. This version boasts a slew of enhancements, fixes, and new features that will greatly enhance the overall experience and security of our platform. Without further ado, let’s dive deep into the changes:
Chain-Proof Proposals Optimization: We’ve achieved a significant boost in the performance of checkpoint proposals when nodes request chain-proofs from their remote counterparts. This particularly benefits nodes that need to synchronize with peers, especially if they are considerably lagging behind in terms of recent events.
Memory Utilization: The latest optimizations have notably improved memory usage. We’ve introduced a method that capitalizes on extremely fast look-up tables maintained for both Key-Blocks and Data-Blocks. This eradicates the need to retrieve blocks entirely, allowing us to just consult their images (IDs) from the tables. Moreover, the checkpoints a local node requests are recomputed only every few minutes, thus significantly reducing unnecessary computational overhead.
Checkpoint Strategy : During synchronization, GRIDNET Core will now propose checkpoints only up to the depth of cached blocks, thereby minimizing cold storage usage. This change has been introduced to ensure more efficient use of resources and optimize synchronization times.
Bug Fixes & Improvements:
Logging and Vitals:
- Fixed the logging of warnings originating from the Vitals monitoring sub-system.
- Addressed false-negative warnings related to the embedded HTTP sub-system concerning Liveness assessment.
- Improved logging for block processing. Now, if a block has the potential to become a leader — which is determined when scheduled for processing locally — the Operator is kept informed.
- Enhanced logging especially for debug-level events, ensuring irrelevant network-related logs are kept out of the Operator’s terminal view.
- Improved support for the scenario where a node unilaterally begins producing its own history of events despite a globally accepted heftier history. The reported difficulty will now be contextually appropriate.
- Added clear indicators in logs to distinguish whether a block is in the Validation or Prevalidation phase.
UDT Protocol Adjustments:
- Fixed the interval for required UDT connectivity reports, ensuring proper synchronization.
- Added measures to prevent bombarding the same remote peers with excessive UDT connections; now there’s a minimum interval of 60 seconds between such attempts.
- Resolved an issue where UDT conversations were initiated even if they weren’t added to a corresponding container.
- Integrated a safety mechanism to call a destructor on an already active UDT conversation.
Mining Indicators: We’ve implemented a straightforward indicator that flags when mining occurs on a FORK that is beneath the Heaviest Leader. This serves as a warning to the Operator when the node mines based on a history that is outpaced by the leading block acknowledged by the broader network.
- Introduced the ‘warnings’ utility to GridScript. This quickly displays all recently generated warnings, providing immediate insights for Operators.
- Added the ‘diff’ command in GridScript, allowing users to view the current difficulty.
- We’ve refined the ‘chain’ utility to accurately showcase the heaviest leader. The syntax for this is “chain -show -heaviest -block recent”. Corresponding MAN pages have been updated.
Connection Reporting: Upon establishing a connection, the associated transport layer and the IP address of the connecting end will briefly be relayed to the Operator.
Enhanced Anti-DOS Measures: In response to numerous Denial of Service attacks aimed at our nodes, we’ve fortified the GRIDNET-Core’s internal firewall. We’ve zeroed in on the UDT protocol, which is notably resource-intensive. Operators are continually informed about detected attack vectors without being overwhelmed with excessive notifications.
Timestamp Security: We’ve significantly enhanced our measures against timestamp manipulations. Nodes will now permit a maximum time-drift of 15 seconds into the future, as indicated by the native operating system. Moreover, any drift into the past, from the standpoint of the parent block, is strictly prohibited.
This release embodies our commitment to ensuring GRIDNET Core remains a secure, efficient, and dependable platform. We deeply appreciate the continuous feedback and support from our community, which has been instrumental in shaping this update.
Download the new version from the usual location. As always, should you have any queries or feedback, do not hesitate to reach out. Implementation has taken place on YouTube LIVE as always, with detailed explanations and commentary on Twitter and in even more details over at our Discord server.
Stay decentralized, stay empowered!