Check out the Issue Explorer
Looking to fund some work? You can submit a new Funded Issue here.
`ethstats` is an Ethereum-specific, opt-in node status reporting service.
The server component is called [`eth-netstats`](https://github.com/cubedro/eth-netstats); it can be seen on [ethstats.net](https://ethstats.net/) (ETH main-net), [ropsten-stats.parity.io](https://ropsten-stats.parity.io/) (Ropsten test-net), and others, including private/development chains [via `puppeth`](https://medium.com/@gilangbhagaskara/create-a-private-ethereum-network-using-puppeth-2833c06f66ea).
The stand-alone client component is called [`eth-net-intelligence-api`](https://github.com/cubedro/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`](https://github.com/ethereum/go-ethereum), - 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.
`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.
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;
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.
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.
* `geth`'s [`ethstats` package](https://github.com/ethereum/go-ethereum/blob/master/ethstats/ethstats.go), enabled with the `--ethstats` CLI arg, in Go;
* original [`eth-net-intelligence-api`](https://github.com/cubedro/eth-net-intelligence-api/blob/master/lib/node.js) stand-alone implementation, as a PM2 `node` application, in JS.
* @shazow's [`vipnode/ethstats`](https://github.com/vipnode/ethstats) re-implementation of the collection server, in Go;
* original [`eth-netstats`](https://github.com/cubedro/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