Generic worker

[ryscheng]

All workers should register with the registry and be assigned work from the scheduler. We should no longer have a dedicated notion of a compute node running a specific contract.

[kostko]

This will also require some protocol changes as our current RPC calls assume that there is only one contract that can be called. We will need to update the messages to include a contract id.

And after the compute node stops being part of a compute committee for a specific contract it should stop the contract worker and stop accepting any RPC requests for that contract.

[kostko]

Currently the compute node has a hack where it doesn't register the key manager compute node. The reason for that is that nodes are already treated as generic in committee elections so if we registered the key manager compute node as well it could be elected into the actual contract committee.

When a generic worker is implemented, this hack can be removed.

[kostko]

When we introduce the generic worker, we will also need the following utilities:

• Register an entity.
• Register a contract.

These could be part of ekiden-tools so you can build and register a contract.

[willscott]

It sounds like there are potentially 3 separate client binaries:

• ekiden-tools - for contract developer / development help
• dummy-node-controller - for admin operations on the running system
• ekiden-cli? - for client interactions with the running system

[kostko]

So the dummy node controller is for admin operations on the dummy system while ekiden-cli(?) will probably also be used in production (e.g., to register entities/contracts).

[willscott]

right, which makes it seem like it could be worth a separate binary.

On Fri, May 18, 2018 at 9:29 AM, Jernej Kos notifications@github.com wrote:

So the dummy node controller is for admin operations on the dummy system while ekiden-cli(?) will probably also be used in production (e.g., to register entities/contracts).

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/oasislabs/ekiden/issues/48#issuecomment-390261351, or mute the thread https://github.com/notifications/unsubscribe-auth/AAaIp3tWTi9V3VL38JilUEBvPN6v5b4Lks5tzvbrgaJpZM4TC9Cp .

[kostko]

Yes I agree about that, I am not sure if we should combine ekiden-cli with ekiden-tools or not?

[ryscheng]

Deprioritizing. Currently there is only 1 committee and 1 contract. We'll need to revisit this later

[willscott]

Additional task here: refactor node/dummy to node/.

[kostko]

And probably integrate compute/ into node/ as well?

[ryscheng-mobile]

Outdated. Now we only have 1 runtime-ethereum

[kostko]

We should still support multiple runtimes in the future or not? Are we removing the contract registry and the notion of Oasis contracts to replace them with runtimes? Current architecture is confusing from a naming standpoint and this needs to be taken care of.