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 April 19 and 26 roundtables looked at Leap development. April 19 envisioned what might come of Leap version 5.0. By April 26, v4.0.0 had gone live. The final April roundtable fielded feedback and explored a new proposal.
April 19: Hopes and Dreams for Leap 5.0 and Beyond
The tone was a sort of dreamscape exploring the future potential of the EOS Network. Find meeting notes for April 16 on EOS Nation GitHub. View the recorded roundtable on the ENF’s YouTube.
OVERVIEW
Antelope version 5 is months away. Shaping development happens now. Community feedback is encouraged. View the comments of participants and share your own. But first, a few updates:
Leap v4.0.0 is imminent
Antler tooling
CDT demo expected in a week or two
Led by the Antelope team, the April 19 roundtable explored the hopes, aspirations, and dreams for version 5.0 and beyond.
The following summary adapts notes presented by Brian Hazzard. Antelope Leap version 5.0 has a loose target for release in Autumn 2023. Look out for updates and possibly a release as early as September.
Version 5.0 of the EOS mainnet represents the future and vision of the community. Participants were asked to express their wishlist (thoughts and dreams). Among the sub-topics for discussion were:
interests for today
small, yet impact, changes that are relatively easy to reach
pragmatic, useful, fun, and general pain reliever actions
remarkable, controversial, and wow factors
Moon shots and brilliant aspirations pertaining to both operators and users
The above sub-topics helped kick off wishes for 5.0 (and beyond) development. Below are brief summations from each of the nine participants:
Ross: dynamic peer discovery, automate best peers, and easily see the last block
Daniel: multichain friendly, useful ETH building blocks, and The Graph integration
Micheal: more detailed admin endpoint (“GetInfo2”) and a health query indicating safe/in sync node (“Is Ready”)
Marco (MachnBird Sparo): easy/accessible payment processing and hardware
Aaron: permissions with temporary authorizations and specified rules that match submissions
Kevin: parallelization of block validation, 100K TPS, and horizontal scaling
Denis: improve native resources via consolidation and cost efficiency
Tony: Loki integration for logging and a native monitoring solution
J.P.: improved peer management via an operational API and easily stay abreast of new features/fixes
Mathew: integrate WAX RNG, IPv6 everywhere, auto-start nodeos, and compressed snapshots format
OUTLOOK
Community feedback is central to current development. One might gather that providing feedback early during 5.0 development would be most valuable.
April 26: nodeos 5.0 Proposal for API/Serialization
With Leap v4.0.0 now live, the focus is on fixing a course(s) for the development of 5.0 in the months ahead. Meeting notes for April 26 are on EOS Nation GitHub. The proposal, (updated) API/serialization time constraints for nodeos 5.0, is found on an ENF hackmd.io link. Look for a recording on the ENF’s YouTube.
OVERVIEW
Again, the focus was on community feedback. Actually, the discussion took on more of a Q&A format. Updates include:
V4.0.0 was released this week and some node operators already adopting
CDT v4rc1 likely for next week
Below is a brief overview of the proposal. The two main takeaways for changes coming soon to 5.0 are:
ABI serialization limit
non-atomic API item constraints
Most ABI (Application Binary Interface) requests saw deserialization moved to the HTTP thread pool. The result is improved nodeos responsiveness on the main thread.
As a consequence, there are constraints on the number of items returned for non-atomic APIs. More specifically, requests for http_max_response_time must specify a range and maximum time. Note that valid requests always return at least one object, with a default maximum of 1,000 items.
A summation of guiding requirements is as follows:
API nodes should successfully serve any atomic request
non-atomic API calls should specify a max request time
must guard against user-provided “abi-bombs”
Discussion
The discussion was more unbound than usual. Listed topics were selected for what stood out and inspired the most back-and-forth conversation.
Why get_block changed
Speed, efficiency, and avoiding freezing the main thread seemed to inspire moving get_block onto the HTTP thread.
Time monitoring
Prometheus is recommended over a history solution. Prometheus should also aid a lot with monitoring. Among the wishlist is a lightweight, widely-available solution.
Use case for developers
The possibility of developers using a plugin was briefly discussed. So too was advancing the plugin, mention of the trace_api_plugin, and how some developers (finance in particular) distrust layer 2 solutions.
Other Topics
Among the other topics receiving substantial discussion time were:
reasons for failing (or freezing)
max response time
more about a history solution
snapshots
OUTLOOK
Leap 5.0 will surely bring heated discourse and more proposals. Getting this performance-oriented proposal right should go a long way in setting a smooth course for 5.0. Participants seem to harbor similar sentiments, with a focus on quality over quickly pushing out a solution.