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 nanoRLC 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 mechanism goes for the callback running out of gas.
Consensus & Reveal duration¶
- When orders match, IexecClerk records the deal which details the parameters of the task. If a consensus on a result is achieved before the countdown, the task is successful.
- After the countdown, as no consensus is reached, the execution is failed. 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 the category the task fits in. 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.
In case of failure, the requester can claim the refund.
In the v3-alpha version, this timer lasts for 10 category runtime, for all category.
As described in the protocol parameters section, this reward is
reward = kitty.percentage(KITTY_RATIO).max(KITTY_MIN).min(kitty).