Author: Marco González

Editor: Randall Roland

Ever since the first launch of AntelopeIO (Leap 3.1) in September, the focus shifted from chronicling the launch of next-gen tech to identifying important features for advancement. Among the most notable discussions of 2022 were:

This edition of the bi-monthly summary of the EOS Node Operator Roundtable covers January 04, as well as 11 and 18 (combined). The first two meetings of 2023 took on a different format; for security reasons, no videos were published.

A primary concern for the January 4 roundtable was to gather feedback for potential changes to the AntelopeIO resource model. In previous weeks, congestion issues on WAX were identified as areas that could be improved for across-the-board operating performance. The meeting began by identifying the pain points experienced by node operators.

Following the discussion of RAM usage, low-grade and high-grade hardware were considered. Potential sticking points include a limitations cap (low-grade) and economic viability (high grade). In regards to a new resource model, an opportunity exists to:

The idea is that a new resource model should focus on a cost-effective increase in available network storage.

A ‘gas’ (or fueled) resource model was weighed against current options like raw resources, REX, and powering up services. However, fueling each transaction has historically proven to have its own issues. Micro-transactions, an area where EOS excels, are typically a heavy load for gas models. Additionally, there’s a psychological factor in moving away from EOS’ built-in operations.

Gas-free operations characterize EOS as an easy-to-use chain. One of the early concepts guiding the advancement of EOS was that dApps themselves model their services to be resource providers for their users. Certainly a user-plus. However, the economic viability and potential for abuse need further deliberation.

One potential outcome arising from the fueling discussion was to codify native solutions. Evaluating resource draws (e.g. users, developers, wallets, and node operators) can identify limitations. The resource model would then be ready to improve the operating environment.

The goal for developing a new resource model is:

An area appearing to offer high rewards with relatively little effort is the often ambiguous PowerUp service. Not worth investigating was improving upon NET resourcing.

Topics on the agenda include continuing the discussion on the AntelopeIO resource model, particularly for node services. Areas of concern already identified include history and API.

Published meeting notes were recorded differently for January 11 and 18. The latter began with a summary of the last two calls. From there, the focus was on continuing the resource model discussion.

The few software progress updates mentioned included:

The meeting opened with developer feedback. Mac development began to be addressed with more to come in a later roundtable. While Mac isn’t officially supported, developers can compile for themselves. Some topics of interest included CDT (contract developer toolkit) compiling as an option to DUNE (Docker Utilities for Node Execution). GitHub actions (and Ubuntu) were also mentioned as an option for compiling and thus circumventing CDT.

At this point in the discussion, a new roundtable specific for developers found support.

The discussion continued about how the AntelopeIO resource model impacts node operators. Status updates were:

An open discussion of how node operator feedback can help the ENF deliver solutions. What follows are identified topics thought to ease (or smooth) operations.

EOS Nation tooling was mentioned as a helpful starting point for getting a node up and running. Animus was also shared for tracking endpoints.

Replacing 3rd party reliance with more native solutions (e.g. Wharf kit, better wallets, improve powerup) is thought to improve the usability of the chain. This solution was identified as being low-effort/high-reward. Other efficient solutions included:

More complex solutions seem to be peering and guaranteeing connectivity. WAX was mentioned as a high need in this area. If a public node gets full, options could exist for private nodes and/or preferred peers. Public nodes would still be maintained.

Last on the list for the January 18 meeting was read-only nodeos instances and block propagation. Merging blocks after headers should prove a considerable improvement. Aiding block propagation comes in the form of the earlier mentioned 3.1 patch and potentially through relay-only nodes.

Relieving pressure from nodes that write and sync can be achieved by read-only flags (from state files). Scaling improves when node pressure is reduced. By identifying nodes for a specific purpose, more peers can be included while also reducing RAM.

Specific purpose nodes brought up the discussion of more elaborate and interactive functions. For example, should nodeos be an inclusive solution or do microservices offer advantages? DFUSE and GRAPH were mentioned here.

Also, note that a read-only capable design document expects to be out soon.

Scheduling issues may prevent the next meeting.