Author: Marco González

Editor: Randall Roland

Node operators, Antelope core developers, and community members get together each week to discuss the captivating questions of the day. The primary objective of each Node Operator Roundtable is:

“...to improve the Antelope protocol (specifically) for node operators”.

Meetings take place every Wednesday from 14 UTC to 15 UTC.

The first two March roundtables continued the discussion on Special Nodes, particularly regarding best practices. The March 1 roundtable explored BP Nodes goals vs. best practices. March 8 finished up with Block-only Relay Nodes. If you’re here about the impending “code freeze”, expect an announcement within days following the March 8 roundtable. As for a Leap 4.0.0 testnet release, the development team remains on schedule for the end-of-March/early April target.

The ‘draft taxonomy of the roles that different antelope nodes play’ contains comprehensive notes. To explore the beginning of the Special Nodes discussion, visit the section entitled ‘Post Upgrade meetings’ on GitHub.

Watch the March 1 roundtable discussion on the ENF’s YouTube. Read the notes on EOS Nation (Leap) GitHub.

The March 1 roundtable is the 4th in an ongoing discussion about special purpose nodes. Among the issues is more efficient resource models across the ecosystem. That includes a three-strikes rule vs. subjective billing needs.

The group picked up notations about History providers. Primary Node types that specifically mention history on the draft document include:

Layer-2 solutions that mention history include:

Regarding “state history”, among the issue are:

Also, see follow-up suggestions for history.

The list of node types concludes with the Resource Provider Node, the third layer-2 solution on the list. Its objective is as a user experience enhancer. While the Resource Provider Node currently runs nodejs, it may eventually become decentralized like an API plugin. The draft taxonomy document defines the Resource Provider Node as:

The meeting continued with best practices and the effort and requirements for optimal configuration. A key objective for best practices includes identifying minimums across Antelope networks (e.g. WAX, Telos…).

There will likely be debates on best practices, especially considering the varying needs across networks. For example, all of the following vary based on blockchain network utilization:

Device requirements took over the best practices discussion. Operators should check the overall nodeos configuration when changing a node type. For example, running with starts-and-stops vs. uninterrupted should re-tune a CPU to AtticLabs recommendations. See the draft taxonomy document for the AtticLabs link and other device requirements like ECC RAM, x86 processors, and more.

Closing out the roundtable were notes about security best practices and not reusing hardware keys.

Chain API Node received some final words concerning nodeos configuration best practices for Block Producer Nodes. Recommendations include:

The Chain API Node discussion concluded on what should become available (e.g. simplifying with just Getinfo, though Prometheus may otherwise provide a solution).

Keep in mind that certain node types will require variable configurations. The meeting closes with additional follow-up items (under the Next Steps section of the draft taxonomy doc).

Watch the March 8 roundtable discussion on the ENF’s YouTube. Read the notes on EOS Nation (Leap) GitHub.

The Antelope team reports being on track for an end-of-month/early-April release candidate. Future-focused development of Antelope Leap 4.0.0 has concluded for the time being. An announcement on a ‘code freeze’ is imminent. A 4.0.0 release candidate expects to follow within a couple of weeks.

The initial discussion revisited nodeos config best practices for Block Producer Nodes. Peering is almost always internal. Protecting an internal node network with a WireGuard key (for example) is effective. WireGuard is but one option. Such keys prevent unexpected, nuisance connections.

Special use case scenarios (e.g. resyncing) joined the follow-up items under the Next Steps section. Also advised was to consider increasing efficiency.

The remainder of the roundtable focused on Block-only Relay Nodes and their configuration best practices. The group went into detail about the number of connections. In a previous meeting, 10 to 15 connections were deemed appropriate for the config file. This small connection range is merely a starting point.

Regarding Leap 3.2, maxing out Block-only Relay Node connections between 25-50 is safe. Several notes added were:

The first consideration mentioned for Block-only Relay Node device requirements was that more than one is needed to avoid a single point of failure.

Much of the rest of the discussion focused on connectivity and speed. A reliable internet connection is stressed. So was a fast disk with heavy write focus. See other best practices in the draft taxonomy document for comments about full vs. partial block logs. Note that Leap 4.0 expects to have an auto-node connection feature.

An important distinction is made here regarding a popular misconception. On Antelope chains, a snapshot is just the current state. That’s different from Ethereum’s definition. Thus, for Antelope chains, a peer network needs only ‘enough’ of a full block-log. A full history isn’t necessary for internal relays on Antelope chains.

Mentioned throughout the draft taxonomy discussion is the impact of adjusting variables outside of best practices. For example, a pure Block-only Relay Node accepts nothing more than blocks. Also, note that Leap 4.0 may not require Block-only Relay Nodes.

Expect next week's roundtable to continue the discussion on best practices for nodeos configuration specific to API nodes.