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.
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
always returning a transaction trace
separate transactions for tracking and trace 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
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:
Parallelized read-only transaction and task execution
Multi-threading and thread safety
Optimizations to http_plugin
Subjective CPU improvements
Auto-peering with scheduled proximal BP nodes
Lighter validation for relays
Data control & visibility
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.
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)
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:
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.
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:
meaningful new capabilities
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