Other technical choices
Some requester might want an onchain callback with the result of the execution. The callback mechanism is based on [EIP1154]. The result is a
bytes value that is set during the
IexecHub implements both side of the [EIP1154].
Results are identified by their
taskidand can be pulled through the
In order to use the push approach, the requester can use the
callbackfield to specify the address of a smart contract that implement the
receiveResultmethod specified in [EIP1154]. This method will be called during the finalization with at minimum of 100000 gas to proceed [*].
In order to protect the scheduler and the workers, any error raised during this callback will be disregarded and will not prevent the finalization from happening. The same goes for the callback running out of gas.
Consensus & Reveal duration
When orders are matched, a deal is recorded by the IexecClerk which details the parameters of the task. If a consensus on a result is achieved within a given timeframe then the task is considered successfull. On the other hand, if no consensus is reached the the execution if considered a failure. The duration of the consensus timer is a balance between the quality of service offered to the requester (short timer) and the margin available for the scheduler and the worker to achieve consensus (and go through the reveal process).
The maximum duration of a task is governed by its category. While the consensus duration can obviously not be shorter than the task runtime a significant margin is required for the scheduler to do its job correctly. Multiple workers are likely to contribute and extra time must be planed for the revealing and finalization steps.
The consensus timer starts when the deal is recorded by the IexecClerk. Once this timer is over, and if no consensus was finalized, the task is considered a failure and the requester can claim a failed consensus to get a refund. In the v3-alpha version, this timer lasts for 10 times wathever the category runtime is.
In addition to the consensus timer, a contribution timer is started. This timer limits the timeframe for worker to contribute to ensure the enough time is left for the reveal and finalize phases. In the v3-alpha version, this timer lasts for 7 times wathever the category runtime is.
The reveal timer starts whenever a consensus is reached and determines the timeframe the workers have to reveal their contributions. This should be long enough for worker to have time to reveal while not being to long so that the requesters waits to long for its result or the consensus fails because the scheduler cannot finalize in time. In the v3-alpha version, this timer lasts for 2 times wathever the category runtime is. This leaves a gap of at least 1 time the category runtime for the scheduler to finalize the task before the end of the consensus timer.
When a consensus fails, the requester gets a refund and the scheduler loses its stake. In order to remove an attack vector, the requester does not get any of the seized stake. If this was a feature, anyone could build a flawed application that would not reach consensus to drain money from the scheduler. This would force the scheduler to whitelist all applications thus reducing the usability of the platform.
Seized stake from the scheduler goes into a specific account called the reward kitty. No one controls this account, nor can withdraw from it. However, the tokens are not burned. Whenever a task is finalized, the scheduler that organized the execution of this task is rewarded by the requester but it also gets a small part of the reward kitty.
As described in the protocole parameters section, this reward is
reward = kitty.percentage(KITTY_RATIO).max(KITTY_MIN).min(kitty).
|[EIP1154]||(1, 2, 3) EIP 1154: Oracle Interface|
|[*]||value susceptible to change.|