Add emitters to execution

[NicolasMahe]

The current implementation of the creation of executions only allows one orchestrator to create the execution. This is problematic as processes are replicated across the whole network and each node is running an orchestrator that will try to create the same execution. Currently, only the "fastest" orchestrator will actually create the execution, the other orchestrators will create transactions as well but they will be invalid as the execution they want to create already exists. Moreover, orchestrators should be incentivized to create executions to make the processes work. So they should receive a portion of the execution's coins (like runners and service developer).

So to fix this issue and reward orchestrators, we need to save the list of orchestrators that create or try to create the execution.

The second issue with the current system is any orchestrator can create executions on behalf of processes. This must be solved by implementing a consensus mechanism on the creation of executions. Only executions that passed consensus should be executed by the network.

Here is my vision to implement this feature:

1. if execution processHash is set, get the process's node that triggers this execution (this is not the process's node of the created execution, but the process's node of the event or result that triggers this execution). Verify that the signer is actually running the instance of the event or result that triggers this execution. Return error if the signer is not running the instance.
2. create the execution in the keeper if it doesn't already exist. set the execution's status to "proposed".
3. add the transaction's signer to the emitters list of the execution
4. mark the execution as "created" when enough the list of emitters reach >2/3 of the number of runners of the instance
5. the runner executes the execution if the transaction status is "created"
6. when the execution is completed, the emitters are rewarded from the execution's coins

Where to store the list of emitters

• If we want to respect the immutability of the data we put on the blockchain (https://forum.mesg.com/t/immutable-data-on-tendermint/407) we should create a new resource Emitter for every emitter.
• If we don't care about immutability, we could simply add a slice of AccAddress to the execution and exclude it from execution's hash calculation.

---

EDIT After discussion on Discord, forcing emitters to also run the instance solve the issue concerning the expected number of emitters. This modification has to be implemented in the orchestrator as well.

[krhubert]

Few questions:

Moreover, orchestrators should be incentivized to create executions to make the processes work.

Why? Creating execution is rather simple task so why we should reward it?

We can introduce an option to disable orchestrator if someone wishes too.

So to fix this issue and reward orchestrators,

From which address orchestrator would be rewarded? Process or some other resources?

we need to save the list of orchestrators that create or try to create the execution.

It's that will be a way more expensive operation for blockchain?

The second issue with the current system is any orchestrator can create executions on behalf of processes.

This is what we want and it will stay like that, no? The consensus on creation is the next step

This must be solved by implementing a consensus mechanism on the creation of executions. Only executions that passed consensus should be executed by the network.

So we want consensus on creations of execution, not the results? What about the execution results?

Also, what dose it mean consensus on execution creation? For me, this feature is rather checks + counter because there is no need for data agreement (the execution will always be the same) So in fact, we need just more confirmation from the network.

In case of execution results, there is consensus because we need an agreement on the data which might be different

When is the list of emitters is big enough?

We can leave setting this value for the service creator. He sets how many confirmation from the network he needs (1, 3, 5, or 66%, etc..)

[NicolasMahe]

Moreover, orchestrators should be incentivized to create executions to make the processes work.

Why? Creating execution is rather simple task so why we should reward it?

We can introduce an option to disable orchestrator if someone wishes too.

It's not as simple as creating an execution as orchestrators have the responsibility to check if any step of any process can be executed. The more process there is, the more resourceful it will become. Also, as orchestrators are running as client, we need to provide a mechanism to incentivize them to run.

So to fix this issue and reward orchestrators,

From which address orchestrator would be rewarded? Process or some other resources?

Orchestrators are currently using the address of the Engine.

we need to save the list of orchestrators that create or try to create the execution.

It's that will be a way more expensive operation for blockchain?

I'm not sure to understand the question. Registering an orchestrator will have a cost, yes.

The second issue with the current system is any orchestrator can create executions on behalf of processes.

This is what we want and it will stay like that, no? The consensus on creation is the next step

Yes, it will stay like this. But we need to prevent malicious activity. Checking if orchestrator can create an execution and apply consensus are solutions.

This must be solved by implementing a consensus mechanism on the creation of executions. Only executions that passed consensus should be executed by the network.

So we want consensus on creations of execution, not the results? What about the execution results?

We want both. But first, we want to implement the consensus on creation.

Also, what dose it mean consensus on execution creation? For me, this feature is rather checks + counter because there is no need for data agreement (the execution will always be the same) So in fact, we need just more confirmation from the network.

👍

In case of execution results, there is consensus because we need an agreement on the data which might be different

Exactly.

When is the list of emitters is big enough?

We can leave setting this value for the service creator. He sets how many confirmation from the network he needs (1, 3, 5, or 66%, etc..)

Yes that could be a option of the service. But I think we should build a simple and generic system for now. Like the fixed ratio in execution and the min price.

[NicolasMahe]

done in https://github.com/mesg-foundation/engine/pull/1705