Replication & Trust¶
How to achieve trust ?¶
The PoCo offers a consensus mechanism that can certify the likelihood of a result to be valid.
This consensus relies on the scoring of workers and the replication of a task’s execution to combine the score of the workers that come up with the same result.
Each worker’s contribution has an associated credibility. This credibility derives from the worker’s history score.
As described in [Trust2018], a worker score is a positive integer that is incremented for each valid and verified contribution.
In case of bad contribution, a worker loses one third of it’s score.
This credibility can be expressed as a likelihood percentage but also as a weight value that can be used to detect consensus without resorting to floating point arithmetics,
more details in [Trust2018].
Requiring a trust level¶
Based on [Sarmenta2002] describing the way to combine worker’s contribution and to evaluate a result’s likelihood, a requester can ask for the level of trust as a input for the PoCo processing, to impose a certain quality of service.
The trust level corresponds to a minimum correctness likelihood that a result must achieve to be valid. For example, a trust level of 0 means any contribution would be accepted, regardless of the score of the worker proposing it. On the other hand a trust level of 99.99% means a result will only be accepted if the contribution towards it result shows a correctness probability higher than 99.99%.
The trust level is expressed, on-chain, by a integer
trust such that
threshold = 1 - 1 / trust.
|Trust||PoCo enforced confidence threshold|
This consensus mechanism requires replicable applications.
Non deterministic applications, long running jobs such as webservers, do not meet this requirement out of the box.
When it is possible, the application developer must provide a deterministic result in the
Otherwise, the user can still run its application on the iExec platform but would have to disable the PoCo’s consensus layer.
Hardware security as TEE is an option to overpass this limitation.
|[Sarmenta2002]||(1, 2) Luis F.G.Sarmenta. Sabotage-tolerance mechanisms for volunteer computing systems. 2002. Future Generation Computer Systems, 18(4), 561–572 Sarmenta2002 PDF|
|[Trust2018]||(1, 2, 3) Trust management in the Proof of Contribution protocol. 2018. Technical report. Trust2018 PDF|