2002-10-20 22:12:53 +00:00
|
|
|
<title>Validation of results and credit</title>
|
2002-08-20 23:54:17 +00:00
|
|
|
<body bgcolor=ffffff>
|
2002-10-20 22:12:53 +00:00
|
|
|
<h2>Validation of results and credit</h2>
|
2002-04-30 22:22:54 +00:00
|
|
|
<p>
|
2002-10-20 22:12:53 +00:00
|
|
|
Communication from the core client can easily be altered or forged.
|
|
|
|
|
Some users will attempt to get undeserved credit
|
|
|
|
|
by falsifying their CPU metrics or CPU times.
|
2002-08-19 18:43:10 +00:00
|
|
|
Output files may be wrong.
|
2002-10-20 22:12:53 +00:00
|
|
|
This can result from tampering or hardware failures.
|
2002-04-30 22:22:54 +00:00
|
|
|
<p>
|
2002-09-26 05:57:10 +00:00
|
|
|
Both problems - credit-cheating and wrong results - can be addressed
|
2002-08-19 18:43:10 +00:00
|
|
|
by <b>redundant computing</b> and <b>result validation</b>.
|
2002-09-26 05:57:10 +00:00
|
|
|
In this approach, each workunit is processed at least twice.
|
|
|
|
|
The project back end waits until a minimum number of results have been returned,
|
|
|
|
|
then compares the results and decides which are considered correct.
|
|
|
|
|
The notion of equality of results,
|
|
|
|
|
and the policy for deciding which are correct,
|
2002-09-02 17:25:55 +00:00
|
|
|
are project-specific.
|
2002-04-30 22:22:54 +00:00
|
|
|
<p>
|
2002-09-26 05:57:10 +00:00
|
|
|
The back end then marks correct results as "validated",
|
|
|
|
|
finds the minimum reported credit for the correct results of a given workunit,
|
|
|
|
|
and assigns this amount of credit to all the correct results.
|
|
|
|
|
This ensures that as long as a reasonable majority of participants
|
|
|
|
|
don't falsify credit, almost all credit accounting will be correct.
|
|
|
|
|
|
|
|
|
|
<h3>The validation program</h3>
|
|
|
|
|
|
|
|
|
|
BOINC supplies a utility program <b>validate</b>
|
|
|
|
|
to perform validation and credit-granting.
|
|
|
|
|
This program must be linked with two project-specific functions:
|
|
|
|
|
<pre>
|
|
|
|
|
int check_set(vector<RESULT> results, int& canonicalid, double& credit);
|
|
|
|
|
int check_pair(RESULT& r1, RESULT& r2, bool& match);
|
|
|
|
|
</pre>
|
|
|
|
|
<b>check_set()</b> takes a set of results.
|
|
|
|
|
If there is sufficient agreement,
|
|
|
|
|
it selects one of them as the "canonical" result
|
|
|
|
|
(returning its ID) and also decides what credit should
|
|
|
|
|
be granted for correct results for this workunit.
|
|
|
|
|
<p>
|
|
|
|
|
<b>check_pair()</b> compares two results and returns match=true
|
|
|
|
|
if they agree.
|
|
|
|
|
|
2002-04-30 22:22:54 +00:00
|
|
|
<p>
|
2002-09-26 05:57:10 +00:00
|
|
|
The file <b>validate_test.C</b> contains an example
|
|
|
|
|
implementation of check_set() and check_pair().
|
|
|
|
|
|
2002-09-02 17:25:55 +00:00
|
|
|
|
|
|
|
|
<hr>
|
|
|
|
|
<h3>Implementation</h3>
|
|
|
|
|
|
2002-09-26 05:57:10 +00:00
|
|
|
The following database fields are used:
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
<b>WORKUNIT</b>
|
|
|
|
|
<dt> bool need_validate
|
|
|
|
|
<dd>
|
2002-09-02 17:25:55 +00:00
|
|
|
true iff this workunit has one or more results in state DONE
|
|
|
|
|
and validate_state UNCHECKED
|
2002-09-26 05:57:10 +00:00
|
|
|
<dt>
|
2002-09-02 17:25:55 +00:00
|
|
|
int canonical_resultid
|
2002-09-26 05:57:10 +00:00
|
|
|
<dd>
|
2002-09-02 17:25:55 +00:00
|
|
|
nonzero if a conclusive check has been done for this WU;
|
|
|
|
|
indicates the canonical result
|
|
|
|
|
|
2002-09-26 05:57:10 +00:00
|
|
|
<p>
|
|
|
|
|
<b>RESULT</b>
|
|
|
|
|
<dt>
|
2002-09-02 17:25:55 +00:00
|
|
|
int state
|
2002-09-26 05:57:10 +00:00
|
|
|
<dd> INACTIVE, ..., DONE, ERROR
|
|
|
|
|
<dt>
|
2002-09-02 17:25:55 +00:00
|
|
|
int validate_state
|
2002-09-26 05:57:10 +00:00
|
|
|
<dd>
|
|
|
|
|
NEED_CHECK,
|
|
|
|
|
VALID,
|
2002-09-02 17:25:55 +00:00
|
|
|
INVALID
|
|
|
|
|
|
