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:

Meetings occur every Wednesday from 14 UTC to 15 UTC (13 UTC to 14 UTC during daylight savings). The EOS Network Foundation provides tutorials and documentation for those wishing to learn the basics of operating an EOS node (and more).

Below is a list of the two roundtables encompassing this bi-monthly summary:

Look for additional meeting notes and comments on GitHub. Video recordings reside on the ENF’s YT.

The June 7 meeting was mostly an open discussion. As September approaches, there’s an increased focus on preparing for Leap 5.0.

Improving node operations management is a recurring community interest. P2P improvement comprises much of the feedback.

P2P improvements continue to capture node operators' attention. Primary issues relate to transaction stability, reliability, and overall ‘quality of life’ for node operators. Target areas identified that help realize the best solutions include:

Previous weeks offered some insight into the above topics. The following section seeks to add clarity and save the reader time. Expect a comprehensive report (from the team) about P2P improvements after further discussion and feedback.

Improved visibility and management are needed to increase efficiency. The main focus is the visible status of nodes on a peer network that enables operators to identify their preferred connections at a given time.

Likened to a black box, peer information can leave an operator guessing as to where to find blocks currently in need. Data types important here include:

Outbound data flow should be more than inbound. The current designation for synchronization is a timeout before moving on to the next node. P2P synchronization improvements are also the topic of a recent GitHub conversation.

Node flow can increase efficiency by eliminating the need to battle for the same information. However, there may be a security issue when changes lack reasoning and peer numbers remain eerily stable. Solutions mentioned include:

Ethereum labeling again drew a comparison. Continuously reevaluating peers was followed by peer willingness to produce blocks. However, increasing general availability brought on a security concern and bandwidth vs. block limit issues.

Community feedback generally accompanies experiences. Below are highlights of detailed descriptions:

A follow-up question revisited was:

The community continues to work toward a healthier network over time. Everyone is encouraged to try 4.0.1 and provide feedback on related issues.

Moving on from the peer management discussion were topics mostly related to the Leap 5.0 consensus upgrade tentatively scheduled for September.

The June 14 meeting again saw participants brainstorming about persistent, on-the-mind improvement areas.

History solutions with independent libraries have come up from time to time. Antelope firewall garners increased attention. With Leap 5.0 on the horizon, meeting participants took time to explore long-term innovation.

A GitHub conversation on Decoupled Instrument Feasibility remains on the mind of several operators. Though, this topic retains the status of postponed.

An on-topic video about data management was provided in the chat to complement today’s discussion.

Opening the exchange of ideas and feedback was a deep mind substream (history) solution. There are many reasons for node operators to harbor an interest in a history solution. Following are some discussed areas.

Beginning the history discussion were mentions of dfuse, Graph, and (later) firehose. The focus was on keeping separate libraries and instrumentation out of the nodeos codebase. A non-nodeos solution for abstracting history remains in the minds of developers. However, short-term solutions (e.g. partial need fulfillment via traces) still outweigh the high-effort-to-reward ratio for the moment.

Independent efforts toward a deep mind history solution offered more insight and commentary. Below are the highlights that consumed about a quarter of the meeting:

A meeting participant described a prototype (for the library function) that replaced the logger with a pass-pointer to nodeos with the intention of nodeos sending the appropriate information back. The solution yields speed and flexibility, especially for gaming-type applications. Limitations of the prototype involve security and language limitations (e.g. works well with Python but not Javascript). Looking long-term, a chain-based interface for experimentation with different data structures is seen as a desirable pursuit.

Briefly touched upon was Antelope Firewall. An ENF grant is funding the building of the new firewall. A few items were quickly mentioned:

The value of the firewall is for things like rate limiting, account interactions, and more (e.g. independent JSON files).

The meeting concluded with some ‘crazy’ ideas about the future of the Antelope environment. The following ideas are outside of the development team’s roadmap:

While the conversation was short-lived, it did spur up a conversation about ‘crazy’ EOSIO builds. The community is encouraged to share such builds in honor of EOS’ 5th anniversary.