All Collections
EOS Support Media
Bi-Monthly Node Operator Roundtable Summary [April 2023 #1]
Bi-Monthly Node Operator Roundtable Summary [April 2023 #1]

Published April 17, 2023

Markus Hinrichs avatar
Written by Markus Hinrichs
Updated over a week ago

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:

“ 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.

April 05: Antelope v4.0.0 Update and 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:

  • provide even higher performance with multi-threading

  • reduce latency and enable faster block propagation

  • provide more data control and visibility

  • quality of life improvements for node operators

Specific takeaways (from Brian’s notes):

  • get_block is 4x faster and no longer on the main thread

  • JSON parsing throughout nodeos is approximately twice as fast

  • multi-threaded, read-only windows enable API providers to use as many threads as available

Lin Huang: Read-only Transactions

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

  • new RPC endpoints

  • non-modified state actions to prevent accidental changes

  • disallowing authorizations/signatures

  • always returning a transaction trace

  • separate transactions for tracking and trace logging

  • deep-mind logging

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

  • read-only: can run parallel

  • read-write: cannot run in parallel

  • read window: can only run read-only

  • write window: can run both read-only and read-write; and sequentially on the main thread

  • configurations

Vlad: Snapshot Scheduling and Enhancements

Key items presented by Vlad for snapshot scheduling include:

  • snapshots for scheduling (one-time future and recurring)

  • 3 API calls (snapshot_requests) to accomplish the above

  • stored as a JSON file

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: Performance Harness

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.

Kevin Heifner: Performance, Latency, Data, and Quality of Life

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:

  • Higher Performance

    • Parallelized read-only transaction and task execution

    • Multi-threading and thread safety

    • Optimizations to http_plugin

    • Subjective CPU improvements

  • Reduced Latency

    • Auto-peering with scheduled proximal BP nodes

    • Lighter validation for relays

  • Data control & visibility

    • Prometheus exporter

    • Log splitting for blocks and SHiP

  • Quality of life

    • Resource monitor absolute value setting

    • Better logging throughout nodeos plugins

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:

  • IPv4 for 4.0 makes it possible to listen on a separate port when the plugin is enabled

  • IPv6 for 5.0

  • Log splitting (specify a different state directory)

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.

April 12: Looking Ahead to a 5.0 Environment and Endpoint Categories

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.


  • v4.0.0-r3 released

  • CDT-rc1 is due out soon (possibly by next week)

  • developer office hours

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:

  • a desire for early feedback (and dreams for 5.0)

  • proposal reviews

  • Prometheus plugin

  • endpoint categories


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:

  • get_info

  • chain_ro

  • chain_rw

  • net_ro

  • net_rw

  • producer_ro

  • producer_rw

  • snapshot

  • trace_api

  • Prometheus

  • node

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.

Meeting Feedback

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

  • comments about a new configuration (category) for get_supported_apis

  • the process of filtering through connections

  • discussion about get_server_info and get_info that’s separate for the public and node operators

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.

Closing Out

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:

  • pain points

  • special items

  • improving performance

  • meaningful new capabilities

  • driving adoption

  • carving out a niche


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.

Sources & References

Did this answer your question?