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:
October 18: Improved CPU Config, Discussion on Early Blocks Feature, Simplify Network-wide Config and more
October 25: Wishes & aspirations for Node Operator Call Format, Last Milestones to get to RC3
Please be sure to look for additional meeting notes and comments on GitHub. Videos reside on the ENF’s YT.
October 18 : Leap 5.0 on its way: Early Blocks, Performance Enhancements, and Community Input
Release of Leap 5.0 and Testing:
The meeting commenced with a comprehensive discussion on the release of Leap 5.0.
Community members were strongly encouraged to actively participate in testing the release candidate, RC2, with the primary aim of identifying and addressing any issues before the official stable release.
Changes to CPU Effort Percentage Option:
A significant change was introduced regarding the CPU effort percentage option.
The proposal involved shifting from using percentage values to configuring CPU effort in milliseconds.
Existing options, such as CPU effort percentage, last block CPU effort, last block offset, and last block versions, were to be replaced by a new option named “produce block offset ms.”
Details of the New “produce block offset ms” Option:
The newly introduced “produce block offset Ms” option grants node operators the ability to specify the number of milliseconds they wish to allocate for the entire round, which consists of 12 blocks.
This offset plays a crucial role in determining the time allocated for handling block production latency.
Importantly, it was clarified that this change would not impact the consensus mechanism and was specifically designed to enhance block production efficiency.
Early Block Production and Testing:
Subsequent discussions revolved around the introduction of early block production in Leap 5.0.
Michael, EOSUSA, presented the concept of altering system clock settings, which sparked concerns regarding potential issues and unintended consequences.
Concerns were expressed about how early block production might affect the network and whether it could lead to forks or other complications.
Performance in Lab Testing:
Kevin Heifner expressed his enthusiasm about the potential performance improvements brought about by early block production.
The discussion highlighted how early block production allows more time for transactions to be included in blocks, ultimately benefiting the network's efficiency.
The EOS VM OC (Optimized Compiler) was acknowledged as a significant performance enhancer, especially for EOSIO DApps and contracts.
Attention was drawn to the likelihood of increased load being shifted to history solutions to handle the performance boost.
“ There's a ton of performance improvements from the 1.8 days to where we are today like it's a much more tuned engine and so really it should be able to handle the load” Kevin Heifner, OCI
Configuring “produce block offset ms” and Defaults:
The conversation shifted towards configuring “produce block offset ms” and suggested default values.
A default value of 450 milliseconds was proposed for “produce block offset ms,” with discussions emphasizing the importance of default settings in influencing node behavior.
Flexibility was underscored as a key factor, allowing operators to adapt the setting to align with their specific network conditions.
Late Blocks and Clock Synchronization:
The issue of late blocks and their management in the context of early block production was addressed.
Considerations were given to the potential impact of clock synchronization and network latency on late blocks.
Kevin clarified that late blocks might lead to microforks, and the role of clock synchronization in this context was explored.
Setting “Max Transaction Time” and “Read Only Read Window Time”:
The discussion encompassed the “Max Transaction Time” setting and potential changes.
Kevin Heifner recommended a default setting of “somewhere around 500 milliseconds”
The importance of configuring settings for “Read Only Read Window Time” was highlighted, emphasizing network optimization for improved performance.
It was suggested that individual node operators should set these values based on their specific use cases.
Enforcement via On-Chain Consensus:
The concept of controlling settings via on-chain consensus was introduced as a means to simplify network-wide configuration changes.
“…now the BPs can can control it network wide by a consensus setting” Kevin Heifner
Discussion on PR for Labeling Peer-to-Peer Peers:
A pending Pull Request pertaining to the labeling of peer-to-peer peers was briefly mentioned.
Due to time constraints and the absence of the crucial team member Matthew Darwin, a detailed discussion on this topic was deferred for a future meeting.
The meeting concluded with a call for the community to actively test Leap 5.0 rc2 and provide feedback to ensure a seamless transition to the stable release.
October 25: Wishes & aspirations for Node Operator Call Format, Last Milestones to get to RC3
Main Topic: How to Continue the Node Operator Roundtable
Insights and Engagement:
Ross from EOS Sphere appreciated insights from the technical team.
Shaq stressed the need for Leap information and technical insights.
Michael from EOSUSA recognized the collaboration's impact on software maturation.
Kevin Heifner, OCI, emphasized the importance of feedback from node operators.
Future Meeting Wishes:
Discussion on including documentation in future calls.
Types of documentation highlighted, including protocol, node operator, and developer documents.
Consideration of evolving features and potential changes.
Calls for deeper exploration of upcoming features.
Meeting Formats:
The idea of different calls for specific topics was debated, with participants considering whether ad-hoc or short-lived calls would be valuable.
Concerns were raised that a shift to broader formats could inadvertently turn these calls into developer-focused meetings, causing node operators to disengage.
Attendee Selection:
Participants expressed a desire for heavyweight developers (e.g. Nathan James) to occasionally join these calls. The notion of a two-way exchange, bringing Kevin Heifner to developer meetings and leveraging Nathan's expertise for documentation and orientation, was proposed.
The dream team of participants, would include Kevin Heifner, Nathan James, and regular contributors (Michael EOSUSA, Ross (EOS Sphere), Matthew Darwin) was proposed. Infrastructure-heavy node operators, Aaron Cox (Greymass), and L2 specialists like Stan from EOS Amsterdam might also be included.
Meeting Frequency:
Lean towards maintaining a weekly schedule.
Meeting Duration:
Suggestion to keep meetings consistent at one hour.
Consideration of extending for in-depth discussions.
Alternate Meeting Times:
Challenge of disrupting routines and fragmenting participation.
Proposed additional calls at different times.
Agenda Improvements:
Suggested flexible agenda with status updates and main topics.
Meeting Notes Assessment:
Discussion on the adequacy of meeting notes.
Recommended seeking feedback from absent individuals.
Meeting Recordings:
No concerns about recording meetings.
AI-Generated Notes and Transcripts:
Welcomed AI-generated notes, contingent on active recording.
Boosting Attendance:
The final topic pertained to increasing attendance, with the suggestion to actively engage non-attendees in order to broaden participation in these valuable discussions.
Part revolving around Milestones regarding Leap Upgrade RC2 → RC3
A focus was placed on CPU availability for transaction signing, with a specific reference to a configuration parameter, the “produce block offset,” and strategies to optimize it for maximum performance.
Milestones were outlined, with a focus on fixing issues for the next release candidate.
Some critical issues, including BLS tests failing on ARM builds, were discussed, with work in progress to address them.
Configuration Parameters
The healthy setting for the “produce block offset” parameter was a significant topic, the question was brought up by Ross and Kevin stepped in with an in depth explanation of how this is improved in the upcoming release.
RC2 had a default of 90% or 600 milliseconds, which was considered too conservative.
In the new release, the new setting expressed the offset in milliseconds, allowing finer tuning. Participants discussed various settings and the potential benefits, like improved transaction processing and reduced latency.
“There is a potential increase in latency for transactions that happen to hit the 12th block but only the ones that would happen to hit that last block and so that's you know that a pretty small um negative for a rather large positive for everything else” Kevin Heifner
The most significant advantage is realized during periods of chain congestion. It also aids in handling failed transactions more effectively by providing additional time for their evaluation without negatively impacting overall throughput. In essence, it optimizes CPU utilization.
Sources & References