Light Node Initialization

[ebuchman]

The light node already support config file and flags through Abscissa.

Configuration file for a light node should include:

• chain id
• list of full node urls (prod versions should require them to be https)
• trust period duration (eg. 1week)
• trust threshold (numerator and denominator, eg. 1/3)

When starting the light node for the first time, we need to provide subjective initialization in the form of a block height and hash, eg. --height 962118 --hash 28B97BE9F6DE51AC69F70E0B7BFD7E5C9CD1A595B7DC31AFF27C50D4948020CD. See the tendermint lite command.

If we restart the process, we shouldn't need to provide this info, as we should have a trusted state in our db by then.

Of course if the trusted state has expired, the node should fail, and we should be required to re-initialize with a new hash and height.

Another possible situation for initialization is starting from a new blockchain, in which case we can potentially pass in a --genesis flag with a path to a tendermint genesis file to initialize the trusted state from. But we also need to add support for initializing from genesis (see #201).

We might want to separate initialization and normal operation into two distinct commands.

[ebuchman]

This isn't just for the Light Node - any use of the Light Client will require some way to subjectively initialize it, so it should expose some initialization method that takes a height and hash and be able to start from there.

Note for off chain uses (eg. light node, relayer), we specify a height and hash and the LC fetches the header and validator set, checks everything matches, and trusts it and starts from there. For on chain uses (eg. IBC on chain), the header and validator set would be provided directly and just trusted (ie. as part of client creation on chain), since on chain logic can't "fetch" things

[romac]

The light client (supervisor) will also need to be provided with a mapping between peer ids and net addresses.

[liamsi]

We might want to separate initialization and normal operation into two distinct commands.

My current thinking is ideally there would be two commands:

• light-node initialize --height <trusted height> -- hash <trusted hash> [-f] <- inits the light node subjectively (optionally force overwrite existing initialized store) via verify_to_target and returns (or goes over to main loop?)
• light-node start [-c] starts main loop (light client handle for verify_to_highest and the rpc server); all options for the light client instances are controllable via a config file (-c)

[brapse]

This landed with #430