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 contained within this bi-monthly summary:

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

The meeting on June 21 continued the P2P discussion. A GitHub document answering some of the feedback in recent weeks guided the discussion.

The guiding document clearly defines the problem. Defining an acceptable solution aligns closely with previous feedback.

The guiding document page breaks down into several sections: the Problem, Solution, Issues, Resources, and Comments.

There are different needs for targeted user groups. Priorities are now better understood.

The identified audience is Antelope-based and:

To align the problem with core development, there needs to be a focus on “improving the user experience and infrastructure efficiency”. Successful implementation expects to yield “wider adoption and success of the Antelope protocol.”

Returning to the opportunities of target users, the top priorities are as such:

See the document and/or video for descriptions of other issues including a terminal-based UI, peer blacklists, and syncing.

The name given to the product opportunity described above is “P2P Improvements”. The four primary metrics for success, as listed on the GitHub document:

The process of identifying risks is guided by an article (The Four Big Risks) written by the Silicon Valley Project Group. The question asked centers on P2P Peer Discovery RFP regarding parallel timelines:

See the documentation page for more resources and issues.

Participant responses include:

The meeting concluded with clarifying questions. An inquiry was made about throttling (slowing down) as a bandwidth management strategy. From the feedback, throttling is considered an option as opposed to disconnecting peers.

The development team invites node operators to help steer the course of the next steps. Attention was called to the task breakdown (“Features/Epics”) section of the document page. Bandwidth and control mechanisms were mentioned here.

The June 28 meeting identified block trimming as an area to improve. Planning for Leap 5.0 includes preparation time, new standards, IF, OC, and more.

Node operators shared their experience with the current block-trimming process. Diagnostics, automation, and more solution types were discussed. The last third of the meeting discussed planning and preparations for Leap 5.0.

More about Leap 5.0 in a later section.

The floor was open to hear the concerns lingering on the community’s minds. The discussion began around trimming blocks and differing issues for the current 4.0.3 vs. 5.0 expectation. Block trimming garnered immediate interest. Using the leap-util to trim a solution for a bloks-log exception drew several comments. The need to extend trimming to several hundred blocks seems like it could be improved. Smaller trims that can identify the errors (exceptions) are an attractive feature to add.

Two topics seemed to resonate out of the opening discourse:

Below is a list of specifics mentioned. List items follow a general chronological and logical order as recorded in the meeting:

The community seems to want easier diagnostic and recovery tooling. For more details, visit the leap-util is unable to successfully run a detailed smoke test and trim the blocklog. #1348.

As previously mentioned, planning for a Leap 5.0 release candidate has begun. The development team works to mitigate the long, complicated process involved in a consensus upgrade. Leap 5.0 will establish a standard procedure. A couple of months are needed to prepare the community. Plans focus on a pre-holiday release, hence beginning a rollout in September.

Expectations are that Leap will undergo two major releases per year. One of which likely requires a consensus upgrade. Reducing node operating costs is among the chief concerns. This includes cost reductions for node operators when adding new chains. Comments were made about the benefits of experience and optimization (RAM, CPU, and disk space). The importance for more people to upgrade to 4.0 was stressed.

Two primary protocol upgrade features for 5.0 are:

IF seems to be the make-or-break point of the two. IF remains a key initiative of the ENF’s initial plan for the New EOS. OC features are performance benefits primarily meant to improve EVM. However, there are overall OC benefits that include producers. See Add eos-vm-oc-enable auto mode #1322 for more information.

Other items are developing in parallel, expected in future releases so as not to delay 5.0.

The meeting concludes with an examination of OC features for 5.0. Current development is concerned with fundamental improvements. OC should first run on eosio system contracts (e.g. for tokens and EOS EVM) before the other features mentioned. New features and preparing for Leap 5.0 likely remain the focus of future meetings.