Author: Markus Hinrichs
Editor: Randall Roland
Node operators, Antelope core developers, and community members meet each week to talk about the network and its development. The primary objective of each Node Operator Roundtable is:
“…to improve the Antelope protocol (specifically) for node operators.”
Roundtables occur every Wednesday. Visit the Telegram channel for information about joining. The EOS Network Foundation provides tutorials and documentation for those who want to learn the basics of operating an EOS node.
Below is a list of the roundtables contained within this bi-monthly summary:
November 9: Leap 5.0 Status, Migration Plan, OC Auto Mode Discussion, Potential Risk for Non-Upgraded Nodes and more
November 15: EOS VM OC Fixes Completed, Anticipated RC3 Release in Early–Mid-December, Issues Discussion.
Please be sure to look for additional meeting notes and comments on GitHub. Videos reside on the ENF’s YT.
November 9: Leap 5.0 Status, Migration Plan, OC Auto Mode Discussion, Potential Risk for Non-Upgraded Nodes and more
Leap 5.0 Status Update:
Work for Leap 5.0 has been mostly complete for a few weeks.
One outstanding issue related to BLS libraries is being addressed for Release Candidate 3 (RC3).
No significant new changes are expected in RC3, compared to previous discussions.
Migration Plan for Upgrading to 5.0:
The default setting is now “ES VM OC enable equals AUTO,” enabling OC mode selectively based on context.
Discussion on handling heterogeneous networks where some nodes upgrade to 5.0 while others do not.
"There are a few conditions where a potential concern could arise; it does depend on heavy network load (CPU)” Brian Hazzard
Recommendation for nodes running earlier versions to set “ES VM OC enable ON” to keep up with faster throughput of Leap 5.0 Nodes (more memory efficient, more CPU efficient etc.).
Clear communication and community involvement will be crucial to handle any issues that arise and eventually help community members upgrade their nodes.
Discussion on OC Auto Mode:
Clarification on OC Auto mode being dependent on the machine type (producer or non-producer) and system contracts.
Producers using OC for EOSIO system contracts; non-producers using OC for all contracts unless configured otherwise.
Potential Risks for Non-Upgraded Nodes:
If a producer does not upgrade to 5.0, under OC-enabled mode, blocks may not be verified by other producers during heavy non-system contract loads.
Back pressure dynamics may encourage non-upgraded nodes to upgrade.
“... And they should upgrade… If there’s a load, then upgrade” Matthew Darwin
Timeline for Leap 5.0 Release:
Stable release expected to be a few weeks away, with rc3 approximately a week away.
Encouragement for node operators to test release candidates on non-production nodes, starting with test nets.
Timely upgrade recommendations for non-production and production nodes on main nets.
Issue Reports and Contributions:
Acknowledgment of issue reports, especially from active contributors like Matthew.
Most critical issues have been addressed, and rc3 incorporates fixes from rc2+.
Brian Hazzard is expressing gratitude for valuable feedback, the active participation in the Antelope node operators Round Table and Community Channel is very appreciated. The call concludes with an invitation to join the next week's session.
November 15: EOS VM OC Fixes Completed, Anticipated RC3 Release in Early–Mid-December, Issues Discussion.
5.0 Status Update
EOS VM OC host function fixes are complete.
Bake-off between two host function versions with performance differences.
Targeting 5.0 RC3 release between 6-14th December.
Request for testing RC3 on test networks or non-BP nodes in production.
Feedback and Discussion on Submitted Issues
Support for Arbitrary Labels on P2P Peers (Kevin Heifner)
Discussion on the need for arbitrary labels, since it adds complexity and reduces readability.
According to Matthew Darwin, it would probably be best to add a JSON structure for additional peer information.
Consideration of restructuring peering config before implementation.
“It won’t be included in Leap 5 anyway, so it makes sense to wait for that refactoring work”
Suggestion from Mathew Darwin: Don't Force Flush State Files on Nodeos Exit
Discussion revolved around the suggestion and its impact on overall system performance.
Kevin Heifner regards flushing as crucial but recognizes associated issues, such as a considerable time delay during restarts. This challenge stems from the need to flush not only the small nodeos file but also numerous files from other chains.
In this context, Ross shared a Medium article discussing potential improvements with ZFS.
Kevin recommended closing the discussed issue and advocated for testing flushing with Leap 5.0. He highlighted the numerous performance improvements in Leap 5.0, including the mapped private node feature, which has the potential to significantly expedite the flushing process.
Log Non-Default Options, One Per Line
When nodeos starts, it logs all the non-default options on a long line.
This is a style choice according to Brian Hazzard
Reasoning for Using Line Delimitation:
Implemented to improve grepability, making it easier to search within log files.
Reasoning for Consolidating into a Single Line:
Considered valuable for debugging, increasing the probability of being included in a log line paste.
Enhances practicality and simplifies utilization in troubleshooting situations.
Add New Feature: Is State Compatible
Proposal for a service script designed to facilitate compatibility checks, thereby reducing time delays.
Deliberation on the utilization of snapshots and Nodeos exit codes ensued.