Integrate Master process with Deployer contract

[DmiSergeev]

Motivation

Currently, Fluence clusters might be launched only locally (via bash scripts) or using some centralized solution
which combines solvers' keys and delivers the combined information (namely, genesis and p2p configuration) to solvers.

Also, there already exist Deployer eth contract and Master node process prototype implementations.

In order to unlock launching decentralizing Fluence network functionality, we need to integrate Deployer contract,
Master process, and solver Docker container.
We also need a scalable solution that allows launching several solvers on a single node from a single Master process.

Proposed change

Deployer contract changes

• Contract provides the following state-modifying methods:
  • addCode(codeName, numberOfSolvers) to request a formation of one cluster served by the requested number of solvers running the specified code.
    • The code is not reused for different clusters.
    • It's possible to invoke it for the same code several times.
  • addNode(masterKey, address, startPort, endPort) to claim that the specified master is ready to launch solvers on ports from the specified range.
    • This claim cannot be updated (like by extending port range later).
    • Once specified via addNode, a master key cannot be reused anymore for subsequent addNode invocations.
• Cluster is formed once there is an added code and there is enough amount of registered nodes whose port ranges are not exhausted yet.
• Contract provides information about formed clusters:
  • Via ClusterFormed event emitted as soon as the cluster is formed.
  • Via getClustersForNode(masterKey) contract view to retrieve previously formed clusters.
  • Via getCluster(clusterID) contract view to get all information about a particular formed cluster.
• Ports are not reused; the contract is unaware of actual solver statuses: whether they are running, not running yet, or terminated.

Master process changes

• Fluence Master process (FluenceNode.scala) becomes a non-CLI process.
• It takes launching parameters:
  • Master key information (location of the file with public/private key pairs for Tendermint consensus and p2p).
  • Eth node URL.
  • Deployer contract address.
  • (possibly) Eth account to authorize contract method invocations.
• It actualizes the list of solvers to run:
  • By retrieving clusters that had formed before Master started (via GetClustersForNode contract view).
  • By listening to ClusterFormed contract events after Master started.
• It launches actual solvers (if they not launched previously).
• In order to be launched properly, solvers configured by:
  • Master key information.
  • Genesis/transport information from view/event.
  • Reference to WASM code to run on solvers:
    • For now, this code is manually placed to node locally and referenced by location.
    • In future this code would be downloaded via Swarm and referenced by Swarm hash.

Additional utilities

A dedicated utility/script to invoke addCode and addNode methods is required.