Document and publish the future roadmap

[adrianbrink]

This issue will collect all the missing and needed features before ethermint can be considered production ready. Please add your wishes and concerns as comments to allow us to better prioritise.

There are generally two fronts that ethermint needs improvement on.

High Level Roadmap

1. User experience

• How do you get started?
• How do you initialise a new instance with consensus relevant parameters (initial accounts, ...)?
• How do you provide configuration option to the instance (even those that can be changed between different runs)?
• How is the logging output structured?

2. Core logic

• How is the underlying go-ethereum instance provisioned?
  • should we just use the most high level objects from go-ethereum or piece it together ourselves and set everything up separately
• How much of the configuration should not be up to the user but is specific to running an ethermint instance (some options might have to be set in a certain way in order for ethermint to work)?
• How are transactions processed?

3. IBC and Validator Set changes

4. How can we use the light-client capabilities of Tendermint to our advantage in Ethermint?

Features

1. User experience

A user should not have to worry about initialisation. A user installs the ethermint binary and is immediately ready to connect to the testnet or to setup a private network. The binary should ship with the initialisation files for both tendermint and ethermint to connect to our testnet.

In order to connect to the testnet a user should specify ethermint --testnet and any number of other flags to configure the ethereum node. Issuing this simple command initialises the tendermint instance and the ethermint instance and starts both. There should be no error output and a user should immediately be able to use any tool over RPC.

In order to start a private local network, a user should specify ethermint --development and any number of other flags to configure the ethereum node. As above this initialises and starts everything needed.

In order to connect to the live network, a user simply needs to issue ethermint and he will immediately fast-sync to the public network.

One solution to getting the binaries installed could be to specify it as a dependency in brew and otherwise to have an install script that automatically also pulls the tendermint binaries.

#282 #284 #244

2. Core Logic

TODO

3. IBC

TODO

4. Light Client

TODO

Concrete Features and Improvements

• Enable coin movements over IBC

• Remove all command line flags from go-ethereum and instead use a config.toml file to configure the ethereum stack

  • expect a config.toml file in the directory set via --home
  • expect a genesis.json file in the directory set via --home

• Simplify the command line flags

  • --home - defines the base directory for ethermint
  • --help
  • --tendermint_addr - address to connect to tendermint core
  • --abci_laddr - address that the ABCI server will listen on
  • --verbosity - log level, that get translated to the ethereum stack (config.toml file will override)

• Simplify the available commands

  • start - initialises and starts the ethermint instance
  • version
  • remove commands such as unsafe_reset_all

• tests are run against a live network on CircleCi

• benchmarking suite is run against ethermint on every build

• RPC compliance suite with go-ethereum and `parity is added during tests

• CI should run across multiple different architectures.

• Decide which RPC endpoint from go-ethereum we need to override to make them sensible

• Implement a bettre framework then ethereum/api.go to override those endpoints

• Transition to viper cli

I am looking forward to all suggestions.

Once we have decided we need to make this easily sharable with #184.

[ratranqu]

Feature:

• health/readiness status (i.e. ready to transact): for instance to set up behind HAProxy and know when completed to recover from a core dump/panic.

[adrianbrink]

@ratranqu Have you considered the Status() endpoint on Tendermint?

[ratranqu]

@adrianbrink: thx for your suggestion. I haven't looked at the Status() endpoint in the latest version of tendermint. However, on 9.x (used as the backend for hyperledger/burrow), it looks like it doesn't tell me that a node which for instance had to be restarted from scratch (i.e. from latest_block_height=0) is still catching up with the rest of the chain? i.e. that I am not yet able to send transactions to the chain through that node (they remain in unconfirmed tx until the node has caught up). That's what I'm after. Does it make sense?

[kidinamoto01]

Hey Andrian,
Can we make deploying ethermint on a multi-node physical cluster easier?

[ratranqu]

@adrianbrink: actually, with the fix from #194, eth_syncing() could do the trick?

[adrianbrink]

@ratranqu Yes #194 fixes this.

[odeke-em]

@adrianbrink I think another thing we should think about is perhaps finding different machine types and run Ethermint on them and that can help us determine what works and what doesn't e.g #221. IMHO it'd make Ethermint look attractive to enterprise if we can provide guarantees of it being stable across different machine environments. Perhaps this is low priority, but it might help us dodge curveballs such as not suddenly working on a new developer's machine.

[adrianbrink]

#241 covers this

[odeke-em]

Could we make this issue a superset of #184?

[adrianbrink]

@odeke-em Yes absolutely