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. Videos reside on the ENF’s YT.

As Leap 5.0 approaches, roundtables take the form of open discussions. Aligning node operations with the release of 5.0 is challenging. Monitoring community sentiment, sharing development updates, and communication likely determines how smoothly the annual consensus upgrade goes this Autumn (2023).

Community interests on July 5 centered around block size and times.

Efficiency and stability characterize the discussion about high traffic (on Leap version 4.0), block size/time, 5.0, and SHiP issues. A feeling of harmony persists as Leap 5.0 approaches.

The discussion broadly focused on efficiency and stability. Details examined include network performance and traffic, SHiP, block size, processing time, and Leap 5.0 improvements. Also, note the included link about avoiding crashes when processing APIs.

While the EOS Network is the focus of node operator roundtables, meetings are open to discussions across all public AntelopeIO chains. Among the highest-trafficked is WAX.

The enormous traffic on WAX pushes node operators to their limits. Discussing WAX traffic issues aids in the development of new versions of the AntelopeIO software. Future iterations of EOS, WAX, and other AntelopeIO chains are certain to be better off because of the traffic investigations.

WAX struggles to implement Leap version 4.03 due to some existing issues. Testing continues as reports of bugs surface. Real-world load testing is also a consideration. Note that Leap version 5.0 prepares for far greater performance capabilities than is currently possible in 4.0 environments.

Block size remains a high-interest topic. When EOS initially launched, max CPU block times were set to 100 milliseconds. Times increased to 250 milliseconds, but in response to some early issues, the network settled on 200 milliseconds where it remains today. Leap 5.0 will conservatively revert back to 250 milliseconds with the capacity to handle much faster speeds.

Other topics and concerns raised include:

Leap 5.0 will change node operations via faster rounds and advantages derived from early block completion. Details for faster rounds break down as:

Early block completion involves allowing for earlier block starts even though the end time remains the same.

While 5.0 will realize faster block starts (over 4.0), the development team still wants to see the existing capabilities of 4.0.

The need to reach into a main thread and disrupt in-process transactions is solved in 5.0. The possibility for intercession remains. Following was the mention of scheduling and a desire to begin testing soon, ahead of the Autumn release.

A new patch release should solve recent issues with SHiP (State History Plugin). A report identified no feedback from SHiP devoid of peer connections. Snapshots can be useful in such instances. The fixes address syncing EOS from Genesis. Another identified issue involved not receiving ABI data. Data flow stopped when disconnecting from SHiP. All seem easy to fix.

Look out for incoming patch releases.

The meeting on July 12 explored dynamic applications for user authorizations. Security fixes addressed. Initial preparations for Leap 5.0 may begin in the coming weeks.

Dynamic applications need to consider users. Solutions were looked at from both the wallet side and code changes specific to node operators. Wallet solutions for multi-action authorization may prove most worthwhile for various reasons.

Releases address a security vulnerability. See the associated version links for more about each fix (including a stability solution).

Today’s roundtable analyzed a hot topic. Blockchain users need to maintain control over assets while experiencing familiar web2-like functionality. Dynamic authorizations that consider wallet solutions first likely prove the best course of action.

Some authorization combinations considered during this roundtable include:

Expiry options and whitelisting draw the most attention. While solutions may exist through core code changes, trusted wallet solutions seem to be a prudent first step.

For example, RFPs can work well with a wallet-first solution similar to past Scatter features. However, concerns arose around transaction scheduling and asynchronous wallet/applications (esp. games) closures.

A meeting participant mentioned in chat how “whitelisting and listing permission” differ. The participant outlined a solution where an operator can incorporate:

A general approach for any solution is to consider how user perspectives differ from the technical side. Comparisons were made to the streamlining of traditional web authorizations vs. user expectations. Users may wish to maintain a single blockchain account even if the reality is more complicated at the developer level. Suggested again were wallet features.

The moderator suggested Leap 5.0-related topics of instant finality (IF) and consensus-breaking issues. Key topics from the rest of the roundtable include:

A few ideas closed the meeting. Topics for consideration include understanding aspirations, staying current (e.g. packet managers), facilitating custom development tools, and stressing the importance of fundamental documentation.