Finishing the P2P

[Isan-Rivkin]

This issue aims to describe at a somewhat high level the things need to be done before we can release.

note, since there are links to specific lines in the code I created mexico_branch because in develop the code might change a little bit when linking to some specific line but that branch is only for this documentation.

NOTE: for quickly testing and debuging your code use the CLI.

• have multiple shells simulate nodes and add/remove commands to the cli to test as you wish.
• adding a command+trigger to the cli.

1. Ethereum related stuff

@lenak25 I added TODO with your name in NodeController.js to show you where the EthereumApi should be created and stored.

Sync tests

Once flow done lookup #14 the test's requirements.

To run sync test manually in the cli:

1. spin up a node with --core <port_x> and type $announce in the CLI - this is the Provider node.
2. sping up a node with --core <port_y> and type $sync in the CLI - this is the Receiver node.

see related sync test:

AnnounceAction test

Ethereum Services

technichal spec : #19.
@lenak25
use case

1. on NewEpoch => do PTT (integration with @elichai on passing the torch (PTT))
2. on TaskSubmission => this means that some worker commited a new delta and should be synced into the local db of the worker.
3. on TaskRecordCreated => only relevant if the task is for the current worker because before this event the worker already has the input params and did the key exchange and all, now this is a confirmation to the worker that the requester did everything as expected.
4. SecretContractDeployment => same as TaskSubmission

Design
The integration of the EthereumServices class should be part of the worker i.e same as ConnectionManager.
The class should be initialized in the NodeController and every time that event occurs should trigger an Action.

for example: on NewEpoch => do PTT

so inside EthereumServices there will be emit of NewEpoch event and this will trigger PTTAction in the NodeController _actions map.

Ethereum MissingState

@lenak25
Integrate this in the code during the sync flow here.

Ethereum States Verification

@lenak25
specification here.

2. JsonRpcApi a.k.a client_api

Implement the different methods in the doc

getWorkerEncryptionKey is already implemented as an example on how to do this.
To run the example:

1. start a node with --proxy <port number> and let the user connect to it.
   node cli_app.js -i B1 -b B1 -p B1 --core 8978 --proxy 3346
2. start the worker node and let it connect to the proxy node.
   node cli_app.js -b B1 -n peer1 --core 7872
3. make the worker node subscribe to its own signKey topic
   $selfSubscribe
   You should see the following debug message:
   subscribed to [the_worker_sign_key] self signKey
4. Now test the proxy by openning another terminal and typing use the the_worker_sign_key from step 3:

curl -H "Content-Type: application/json" -d '{"jsonrpc": "2.0", "id":1, "method":"getWorkerEncryptionKey", "params":["the_worker_sign_key"]}' 127.0.0.1:3346

The response should be:

{"jsonrpc":"2.0","id":1,"result":{"targetWorkerKey":"the_worker_sign_key","workerEncryptionKey":"0061d93b5412c0c99c3c7867db13c4e13e51292bd52565d002ecf845bb0cfd8adfa5459173364ea8aff3fe24054cca88581f6c3c5e928097b9d4d47fce12ae47","workerSig":"worker-signature-with-signed-by-the-private-key-of-the-sender-key","msgId":"0OWU5HtodaPQ"}}

@lacabra and @apalepu23 the msgId field is super important because @elichai generates a different encryption key for differenct inputs in enigma-core and this is how he can link between different keys.
For example look at SendTaskInput rpc command how to uses msgId.

FYI,basic test command for the rpc getInfo that a user should type:

 curl -H "Content-Type: application/json" -d '{"jsonrpc": "2.0", "id":1, "method":"getInfo", "params":[]}' 127.0.0.1:<rpc port>

Couple of points:

• How the Worker subscribes to his signing key topic
• What the receiving worker does once he gets a request for EncryptionKey
• The Action that the JSONRPC server does to get the Key from the network
• The MOCK server response of the worker and the request/response message definitions for IPC.

3. Task Manager

I added a Dummy Task Manager, in this commit.

It should manage everything related to passing tasks to enigma-core, commiting tasks back to ethereum to collect fee's and store unfonfirmed tasks.

• The TaskManager API definition.
• Integration and Initiation of the TaskManager in NodeController.

4. Wrapping things up

Read high-level definition.
This should be finallized only when everything is set up.

To test this right now type $init in the cli.

-The implementation of $init cli commad is called InitWorkerAction.