ROADMAP: Make eth Great Again

[chfast]

Remove Whisper

Owner: @chfast.
Approved-by: @chfast, @gumb0.

cpp-ethereum contains support for whisper protocol v3 that is totally out-dated. @gluk256 is working on whisper v5+ in go-ethereum and v5 is massively different than v3. There is not interest in having whisper v5 in cpp-ethereum at this moment, the current code is usually commented out, we don't run any tests.

Remove whisper protocol support.

JSON RPC

1. Drop JSON RPC via HTTP.
   Let's drop the HTTP server from eth client in favor of (future) modular solution: Proxy for JSON RPC.

2. Remove legacy RPC methods.

Dependencies

1. If HTTP removed, we don't need microhttpd system library.
2. LevelDB is working on CMake support, but this work seems to be blocked by Google internal issues. There is also Bitcoin fork of leveldb with Windows support. Combining these two works, we can final pack leveldb for Hunter.
3. Having 1 and 2 we can build static version of eth without dependencies.

[gumb0]

(Whisper we have is v3, but I agree with removing it)

[gumb0]

One thing I don't like about removing HTTP before we have an alternative is that we won't be able to participate in things like https://ethstats.net/ and http://status.ethereum.org/

(Also you won't be able to connect Remix to eth, but no one does that anyway I think)

[gumb0]

Some my ideas below.

JSON RPC

3. Work towards unified interface with go-ethereum. Go through all the methods in both clients, see what is different and what we need to implement.
   Some discovered issues are labeled with rpc

Synchronizaton

1. Snapshot sync - make downloading the snapshot usable Download snapshot through Parity's warp protocol #4622 WIP - Download snapshot through Parity's warp protocol #4227
2. Snapshot sync - make snapshot sync user experience more smooth by combining download and import steps (that is, start importing automatically after downloading)
3. Snapshot sync - download the rest of the chain from genesis to snapshot block in the background after importing snapshot.
4. Snapshot sync - support creating snapshots and giving them out through warp protocol (only leeching from Parity nodes is not cool)
5. Full sync - better strategy to deal with chain reorgs - instead of backward linear search to find the fork block we'd like to do binary search similar to what go-ethereum does.

Network

Support devp2p v5 #4559

Sealing

Support Rinkeby PoA.

Tests

No specific proposals, but I'd like to see some discussion about how to improve testing strategy & organization in general, maybe switching to other testing framework, maybe using mocking.
@winsvega @pirapira

RPC tests seem to me to be very useful idea, but they are in the very primitive stage and not really working and no one improves them.

Documentation

I could create some documents/diagrams describing current architecture, but it would take some time (and then we'd need to maintain it)

Releases

No specific proposals, but maybe we should come up with some release strategy/schedule.

[gumb0]

Logging

Improve logging subsystem, allow filtering by module, maybe similar to geth --vmodule

[chfast]

Ad. logging - I'd like to replace the logging code with an external library with modules / labels there. Boost.Log might be the first candidate as we depend on Boost heavily anyway.

Ad. releases - I propose to make an release every time you finish any of features above.

[chfast]

About sealing engine, can we make regular OOP interface for it, instead of this template mess we have right now? I don't see any benefits of having that templated...

[chfast]

Logging: I finally found it in Boost.Log. They call it "channels": http://www.boost.org/doc/libs/1_65_1/libs/log/doc/html/log/detailed/sources.html#log.detailed.sources.channel_logger.
I hope you can filter by this.

[gumb0]

I'm not sure which template mess exactly you refer to, seal engine classes themselves are not templates, they are derived from SealEngineFace interface in a usual way...

There's SealEngineRegistrar class which has a template method to register a seal engine in a global collection of seal engines, and I don't see much point in this class, we could just get rid of it, I think.

[chfast]

Sorry. I think I was thinking about GenericMiner<EthashProofOfWork>... nevermind.