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 (13 UTC to 14 UTC during daylight savings). For those wishing to learn the basics of EOS node operations, the EOS Network Foundation provides tutorials and documentation.

The discussion on special nodes was again postponed. Instead, Antelope core developers gave insight into Leap generations 4.0 and 5.0 during April 05 and 12 roundtables respectively. Core developers sought to inform the community and acquire feedback.
​

This week, the group welcomed ENF core developers to provide insight and demos of v4.0.0. Brian Hazzard provided notes that are also available on EOS Nation GitHub for April 05. View the recorded roundtable on the ENF’s YouTube.

Antelope v4.0.0 will further advance EOS’ dominance in performance, scalability, and reliability as compared to other blockchains. Identified features (from Brian’s notes) include:

Specific takeaways (from Brian’s notes):

Following Brian’s overview was a presentation by Lin Huang. Leading up to read-only transactions (and tasks) Lin discussed:

Lin went through a < /cleos push transaction > demonstration and read-only transactions. Key features of parallelized read-only transactions (and tasks) are:

Key items presented by Vlad for snapshot scheduling include:

He described recurring snapshots as “the most interesting” feature. Snapshots populate every 20 blocks and will continue until terminated. Unscheduled snapshots can be done with an ID.

Vlad also mentioned a new tool (leap-util) is currently adding new features and will have updated /cleos support.

Peter Oschwald detailed a performance harness walkthrough with a command line example and report. It was originally thought to establish a better way to run performance metrics against different operational nodes. Developers could then see how their improvements may be affecting performance throughout the ecosystem.

Peter walked through three different layers of the performance harness: simple, basic, and advanced. The more advanced the layer, the more parameters are allowed. More information about the testbed and typical configurations can be found in the Pefromance_tests README [see 31:12 of the video].

Peter goes on to describe the transaction generator, a replacement for the associated plugin, and handling large TPS. After going over more features, he indicates plans to continue to build out performance metrics. For example, measuring if nodeos performance is improving or degrading.

Quickly overviewing several topics before closing out the meeting was Kevin Heifner. Using Brian’s notes, Kevin overviewed four broad improvement areas and their subtopics:

Kevin went on to test how auto-peering is currently working. The example went into connectivity pertaining to BP scheduling.

Next, he provided a few notes on the Prometheus exporter plugin:

Concluding the meeting, was mention of nodeos having access to the (retain) directory but not the archives. State history follows the same behavior.

Kevin finished with micro-optimizations where blocks propagate after a header validation and need not occur on the main thread. Alongside a 4x improvement in get_block, propagating blocks expect to be much quicker in a 4.0 environment. He describes how “it’s faster period” and more than half of the process (time) has been moved off the main thread.

EOS is as fast a blockchain as there is. Antelope’s development of v4.0.0 will make EOS substantially faster, more efficient, and developer friendly.

Antelope core developers provided their vision of a 5.0 environment and asked for feedback. Comparisons were made to existing operations, a 4.0 environment, and envisioning 5.0. You’ll find the April 12 roundtable notes on EOS Nation GitHub and the video on the ENF’s YT.

New features coming with v4.0.0-rc3 are detailed in the link provided.

Bi-weekly developer office hours will provide further support for those attending roundtable meetings. Stephen Diesel will be leading meetings. The first will be on April 20 and every other Thursday after. Feel free to reach out to Stephen on Telegram to learn more about CDT and other developer-related stuff (e.g. DUNE, pain points, and the new Antler pods).

Given that a 5.0 consensus upgrade is months away (possibly early Autumn) the meeting was less structured than usual. Key topics of interest include:

4.0 will introduce the Prometheus plugin. In its brief time undergoing testing, community members have asked for making the plugin available to run on a separate, configurable port. That now appears to be a primary object for 5.0.

Prometheus on a separate endpoint inspired other endpoint configurations. Some endpoint categories proposed include:

Categories won’t be configurable with each endpoint. Rather, endpoints will be grouped in ways that make sense. There will also be uniformity across categories. The default will be that all endpoints are in one category so the system can run as it always had.

Shared was a proposal entitled “custom port/io configurations”.

Another priority for 5.0 is introducing IPv6.

The idea of efficient endpoint categories appeared to go over well. Some initial feed and responses included:

As it stands today, get_info is generally made public. However, there's a need in peer environments (e.g. producer nodes) for get_info to remain non-public.

Note that there are strong opinions about maintaining get_info on all endpoints.

The roundtable began to wrap up by discussing a sort of catchup mode and configurable threshold.

Brian closed the meeting by asking the community about a dream environment for 5.0. He provided suggestions of areas to focus proposals, but maintained that feedback should be virtually unrestricted:

The EOS Network is now connected to Ethereum via EOS EVM. 4.0 (no expected consensus upgrade) and 5.0 (planned consensus upgrade) are confidently making progress. Both versions improve speed and functionality. EOS already well-outperforms in the blockchains space. Now it’s time to realize dreams.