Author: Marco González

Editor: Randall Roland

Node operators get together each week with Antelope core developers and community members. The overriding objective of the Node Operator Roundtable is:

Meetings occur on Wednesday at 14 UTC and last for an hour.

The February 1 roundtable explored current (Leap v3.2) and future configuration parameters. Midway through the discussion, it became clear that node configuration is a topic that needs further attention.

With the recent release of DUNE v1.1, Leap takes another step forward in its mission to make development and node operation more welcoming. Note that support for Ubuntu 18.04 will be removed before the March testing of Leap v4.0. Developers wishing to use Ubuntu will need to upgrade. Ubuntu versions 20.04 and 22.04 will be officially supported.

Also, note that the March testing won’t involve a consensus upgrade. Instead, September was mentioned (during the February 8 roundtable) as a potential consensus target date.

Configuring nodes for special purposes proves to be a complex issue. New documentation is needed. Leap 3.2 documentation expects to see improvement to address configurations in advance of upgrading.

HTTP response times took up a large chunk of the meeting. There’s agreement that a response time needs to be at least equal to max serialization time. Response times may be set higher to insure an inbound and outbound balance. For example, an HTTP request fails that timeout on large blocks. Atomic Hub was used as an illustration.

Additionally, excessive call data and overall efficiency need to be considered moving forward. Mentioned early in the discussion was to expect help with “boost libraries” and strategic changes.

Watch the recording on the EOS Network Foundation’s YT.

The notes for potential node configuration and applications took up much of this meeting. Next week’s discussion topic was entitled: “Special Purpose Nodes”.

How best to configure nodes for specific needs expects to extend beyond even next week’s discussion. Primary areas identified for improvement include:

Note that items (e.g. alleviating pressure and efficiency) are often interrelated. Special purpose nodes and their classification deal with abstract concepts. The discussion will also seek to add clarity.

The roundtable on February 8 began the process of classifying the different ways nodes are configured and used. An in-development Antelope node taxonomy document comes in advance of Leap v4.0 (target date is end-of-March on the Jungle testnet). Look out for a consensus Leap upgrade by as early as September.

In addition to the March and September target dates, expect an announcement regarding a code freeze for Leap 4.0.

Special purpose nodes are a conceptual model of all the potential use cases. Organizing node usage and configuration is a topic that’s resonated among EOS developers for some time. With version 4.0, node operators are about to experience a giant leap in streamlining day-to-day management.

Brian Hazzard compared the node brainstorming process to “Lego blocks”. As one might discern, the traits and subsequent roles of Antelope nodes are often abstract. Feedback from the community is welcomed. For the current list of node traits or loose classifications, visit the guiding document: draft taxonomy of the roles that different antelope nodes play.

Working classifications are listed on the draft document. Reviewed in this roundtable were:

What follows is an overview of the node types discussed during this meeting. More details can be found on GitHub (see issues for the week) and the taxonomy draft document.

Identified traits of consensus-requiring nodes that add blocks to a chain include:

Configuration best practices include:

See the taxonomy draft document for future considerations.

The most basic classification is the block relay node. The definition says it all. Relaying involves maintaining connections with peers and validating block headers. Credit Stephen Diesel for commenting:

“Good blocks go in, good blocks go out.”

The advantage of a relay node is that it can operate with more peers (10-15) than a BP node. Also, note that while a block relay node may be public, it shouldn’t be advertised (e.g. on bp.json).

Stephen’s comment illustrates the need for maintaining a peer group capable of consistently providing blocks ready to be relayed. Maintaining an open pipe involves not just synced transactions, but also a readiness to accept new blocks. Failing to maintain a readiness was identified as a contributor to empty blocks.

Like block relay nodes, a transaction relay node may act solely to relay blocks following the validation of a header. What distinguishes the transaction relay node is the ability to also accept:

Kevin Heifner shared a link to an in-the-works solution to improve block propagation following header validation. EOSUSA Michael shared a diagram of his node setup (see Feb. 8 roundtable).

Best practices will be explored and detailed moving forward. Node types seem to have three basic configurations:

Watch the recording on the EOS Network Foundation’s YT.

The next five node classifications on the draft document are:

The Special Purpose Node discussion series expects to continue next week with a focus on the above (API) classifications, best practices, and associated documentation.