Author: Marco González

Editor: Randall Roland

Prometheus is an open-source toolkit, first active in 2012. That’s just a couple of years after the first Bitcoin block and two years before the first Bitcoin boom. Numerous companies now depend on the independently maintained project. Prometheus’ main features include:

Ethereum’s abundantly available statistics already benefit from Prometheus data exportation. So do investigations and analyses of Bitcoin nodes.

Prometheus provides long-standing benefits to high market cap chains by exporting crypto values. EOS expansion plans will invariably require the improvement of analytical tools. Prometheus also proves its worth in scraping endpoints and gathering data for presentation on Coin Market Cap.

Nodeos compares to a black box. The vast amount of information hidden deep within has yet to be tapped. Prometheus exporter can provide useful access.

Week #10 (Nov. 30) of the Node Operators Round Table kicked off the discussion about what kinds of statistics Prometheus Exporter should include for Leap 4.0.

The community prepared a list of preferred statistics. Among the first crucial data points (from the Nov. 30 meeting and comments [01, 02]) were:

Focus points for functionality included:

Broad early targets discussed during week #11 (Dec. 7) include:

In terms of deliverables, a nodeos monitoring dashboard is an example of what could be ready for the first version of Prometheus exporter on EOS.

Improving statistical analysis is only part of the equation. Insuring efficient performance is another.

The Blockchain Council described differences in smart contract platforms. EOS allows users to own assets whereas Ethereum employs a rental model. EOS keeps transaction costs low. However, the usage of RAM (likened to memory) needs to be curtailed to unleash the full potential of the in-development Leap 4.0.

The January 4 (week #13) EOS Node Operators Round Table advanced the weeks of Prometheus discussion. RAM usage was explored alongside a new resource model and scalability limits. User concerns need to stay ahead of network congestion. Other concerns are abuse and managing costs.

Earlier, during week #09, the excessive use of RAM in storing state history was identified as a key improvement area. Consumption continues to grow at a pace that’s getting hard to manage. Introducing new statistics via Prometheus would be incomplete without improving EOS efficiency. Statistics can become convoluted if core infrastructure lags behind other areas of development.

The week #09 meeting inquired about performance tradeoffs vs. RAM size. An answer that arose was to allocate a single:

“block production cycle for loading data into RAM”.

Further investigation was warranted by an RFP. Other short-term opportunities are listed in the meeting notes of week #09.

In terms of long-term solutions, two ideas resonated with the group:

AntelopeIO-related discussions about RAM are seen as early as in the EOS Core+ Blue Paper. Unsellable RAM was introduced for buyers supporting free accounts. This would prevent abuse in the form of selling excess RAM granted at the time of creation.

Leap 4.0 promises to build upon the resounding success already achieved by the AntelopeIO team. With many pre-existing issues inherited from EOSIO, the next version of the EOS mainnet expects to take an even greater Leap forward than 3.0 has. Keep in mind that Leap 3.0 introduces IBC and an EVM in ways that expand EOS’ presence.

The key to further expansion and scaling is improving statistical tools alongside efficiency. Early Prometheus integration gears toward fundamental analysis. Managing RAM for increased network traffic is also key to scaling. Prometheus and efficient RAM use will greatly aid independent projects of all sizes. Taken together, the future of EOS becomes a bit of a mystery with a multitude of avenues for innovation.