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.

Interest in exploring current development and gauging feedback continued through the first half of the month.

Look for meeting notes on GitHub and recorded videos on ENF YT.

The May 03 meeting may aid active developers wishing to get up to speed. While the list provided is a work in progress, initiatives were detailed for their perceived value now and their role in launching Antelope 5.0.

Before digging into the action around 5.0, here are a few updates:

Following the brief comments on updates were topics chosen by attendees. A first option was to return to the taxonomy of node types. Another was to review and comment on active agendas for Leap 5.0.

The discussion would ultimately settle on two topics:

The ENF grant initiatives for Leap v5.0.0 discussed on May 3 include:

Of the items listed above, two (IF and Peer Node Discovery Improvements) are recognized as RFP (request for proposal) projects.

The IF RFP may prove to be the most important 5.0 initiative. Reaching finality faster (than a couple of seconds it currently takes) impacts how developers think about their dApps. IF means a quicker relay between transactions and a reliably affected network state. Imagine what developers can do when more completed actions are assured. IF raises the complexity of dApp development. Users (and the network as a whole) benefit from more robust and creative dApps.

Feedback about IF always seems positive. Mentioned were use cases and how developers might change the way they build. In its most basic form, faster finality streamlines transactions known to be needed. For more about IF, read Coalition Report – Faster Finality with IBC, SDKs + New P2P Improvement RFP.

Maybe not as essential, but well-understood across the developer community, is the issue of RAM limitations. The brief discussion overviewed general plans and promised to report back on the concerns of larger operations.

Contract interactions target developers’ scaling concerns. Maintaining a flexible solution(s) shined among the brief feedback.

Immediate(ish) broadcasting seems to be a hot topic. That is, introducing operational advantages that ‘start early’, before the next block slot. It avoids encountering a pending transaction with a partially-filled next block. One potential issue is that diagnosing BP latency may become harder. Solutions to BP latency could be to wrap the block, monitor between nodes, an envelope block, and additional header information.

Peer node discovery is another RFP. Beyond the mention of private IP addresses, limits/overload, and a possible subnet mask, the topic wasn’t discussed much. A participant mentioned how the Ethereum community has substantial experience in this area. An action item was created that may be revisited at a future roundtable.

Prometheus was mentioned alongside Generalized IP (port configs for nodeos HTTP endpoints). The idea is to avoid redundancy, tech debt, and functionality.

At the moment, Reproducible Pinned Builds require a manual step. The goal is to increase automation as the developer community matures. Further information was requested. Snapshots were mentioned here. Snapshots expect to become more reasonable with new patch releases and prioritized over restarts. Note that major releases may need more than a snapshot.

Other topics on the ENF grant initiatives for Leap v5.0.0 list at the time of this writing were:

The Leap v5.0.0 initiatives list is a work in progress. It will likely change many times before the Leap 5.0 target for September/October 2023. The overriding idea is that AntelopeIO stands apart within the blockchain space through its performance and reliability. Development should support these concepts. Also, a key consideration is easing processes for developers and fostering user adoption.

Note that the list does not include bug fixes.

Leap v4.0.0 generally seems to be doing the job for which it was intended. Flexible account signatures are of particular interest. The new feature is considered a substantial addition.

More challenging items relate to multisigs and time-delays. Making multisigs easier for GameFi seems prudent. Time-delay features were revisited with the idea of scoped temporary authority (permissions).

Improving documentation resurfaced again. An initial challenge is balancing patches and updates alongside core development documentation. The expectation is that improvements will come as the Fall release of 5.0 approaches.

Antelope on EOS (Leap) 4.0 is an exciting display of what’s to come. Some developers already recognize the advantages and choose to make the non-mandatory upgrade. Team ENF continues to show off its talent by letting developing information flow. A new EOS culture has emerged, one of creativity and working for prosperity.

Updates to look out for include:

The discussion began by asking for input from those who’ve run a public EVM. Insight into the current environment of public EVM node operation derives from the rest of the discussion.

Incentives were among the early topics. Interacting with the community and ensuring value and growth followed.

“Good (operational) health checks” is an in-the-works solution. Most participants seem to support focusing on Antelope’s known performance and reliability over that of load balance.

Wallet issues were discussed for both MetaMask and Anchor. Easy ads for MetaMask seem to be a logical next step. Probably requiring more effort, but focusing on Anchor to improve the EVM environment seems wise.

As EOS enters the EVM environment, it’s important to remember that EOS brings more to the table than other EVM technology. While EOS EVM seeks to match the operational capacity of existing EVM dApps, development must be careful to avoid pitfalls. Suggested was improving upon how similar goals are uniquely achieved by EOS. More specifically, begin with (CPU/NET) resource wrapping paid by “miners”. Furthermore, look to increase the number of miners to ease the fee distribution.

Among the other items that caught the group’s attention were

Note that a shared community vision began to touch upon ideas that lend to centralization vs. decentralization. EOS’ target audience might also be included in this discussion.

Overall, the May 10 roundtable was an energetic discussion that touched upon both general and specific matters. EOS EVM may be live, but it has yet to show its true form. Development continues as new dApps launch. Developing on EOS EVM today takes true talent, foresight, and adaptability. Yet, it’s now when the most fruitful seeds are planted.