`ethstats` plugin for node status reporting

Background

ethstats is an Ethereum-specific, opt-in node status reporting service.

The original JavaScript implementation was developed by Marian Oancea (@cubedro).

The server component is called eth-netstats; it can be seen on ethstats.net (ETH main-net), ropsten-stats.parity.io (Ropsten test-net), and others, including private/development chains via puppeth.

The stand-alone client component is called eth-net-intelligence-api; this can be used with any node implementing a certain sub-set of Ethereum’s JSON-RPC queries required by e-n-i-a.

(An alternative approach - taken, for example, by geth, - is implementing a client as a sub-service in the node itself.)

Client-server communication happens over WebSockets.

This issue is about implementing the functionality in trinity, preferably as a plug-in.

Details

e-n-i-a is by now mostly unmaintained; it also expects features that trinity does not currently have, like a JSON-RPC-over-HTTP interface, as well as certain JSON-RPC queries (e.g. subscriptions to “new block” events).

Instead of trying to “fix” that, it “would be nice” to have this as a plug-in. This eliminates the need for JSON-RPC-over-HTTP (which is itself well-suited to be a plug-in), and allows using internal APIs (event subscriptions, timers, etc.).

The plug-in APIs in trinity are unstable; this work will help produce a “demo” of what it takes to write a trinity plug-in, as well as shape the APIs themselves.

Inputs

These are listed “for information purposes”; refer to the existing implementations for actual ones.

Note that some are or will be implemented as part of a different plug-in!

(Likely obtained using internal APIs; falling back to JSON-RPC request over IPC socket could be possible, but that would probably show an inconsistency in internal APIs…)

• Operator-specified (yet human-readable 😉) node name;
• operator-specified “contact details”;
• node software id/version;
• OS id/version;
• Python impl-n id/version;
• whether active/syncing/mining;
• PoW hash rate (actually mostly useless due to prevalence of grinder proxies);
• chain head:
  • block number/hash/difficulty;
  • transaction count;
  • ommer (uncle) count;
• recommended gas price;
• peer count;
• transaction count in pending transaction pool;
• uptime.

Output

JSON messages over a WebSocket, to an operator-specified remote server.

Since ethstats is a “push” scheme, a “shared secret” (essentially a passphrase, also operator-specified) must be used.

Notes

I highly recommend reading @shazow’s notes on the ethstats protocol (linked below, in section References -> Server) to get in touch with its quirks.

Personally, I found geth’s client code slightly more readable than e-n-i-a, but I’m very biased.

Also, to clarify: I’m not exactly thrilled by the ethstats protocol, but it’s already got infrastructure around it to be immediately usable.

References

Client

• geth’s ethstats package, enabled with the --ethstats CLI arg, in Go;
• original eth-net-intelligence-api stand-alone implementation, as a PM2 node application, in JS.

Server

• @shazow’s vipnode/ethstats re-implementation of the collection server, in Go;
• original eth-netstats server implementation, in JS.

Possibly related issues/PRs

These are for further exploration of the topic. Status in parenthesis, at time of posting.

• PR #1182 (merged) - Convert “fix-unclean-shutdown” to plugin
• Issue #979 (open) - Plugin architecture
• Issue #1090 (open) - Convert plugin API to be purely event based
• Issue #1103 (open) - Create guide on how to write plugins

[veox]

@cubedro You’ve misspelled @evgeniuz again. 😉 Fixed.

[evgenius]

@owocki no way, don’t bring me into this 😄