Accounting and result validation

Participants are given credit for the computations performed by their hosts. These credits are used to generate web-site "leaderboards" showing individuals, teams, and categories (countries, CPU types, etc.) ranked by credit. It is expected that some users will attempt to get undeserved credit.

BOINC's unit of credit is CPU time times a weighted average of FP and integer speed and memory bandwidth. In principle it should reflect network transfer and disk storage as well. But it's hard to verify these activities, so for now they aren't included.

The core client reports the CPU time and the CPU metrics on which credit is based. These numbers can't be trusted in general.

Output files may be wrong. This can happen because of hardware failures, or because of tampering.

Both problems - credit-cheating and wrong results - can be addressed by redundant computing and result validation. 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, are project-specific.

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.

The validation program

BOINC supplies a utility program validate to perform validation and credit-granting. This program must be linked with two project-specific functions:

int check_set(vector results, int& canonicalid, double& credit);
int check_pair(RESULT& r1, RESULT& r2, bool& match);

check_set() 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.

check_pair() compares two results and returns match=true if they agree.

The file validate_test.C contains an example implementation of check_set() and check_pair().

Implementation

The following database fields are used:

WORKUNIT

bool need_validate

true iff this workunit has one or more results in state DONE and validate_state UNCHECKED

int canonical_resultid

nonzero if a conclusive check has been done for this WU; indicates the canonical result

RESULT

int state

INACTIVE, ..., DONE, ERROR

int validate_state

NEED_CHECK, VALID, INVALID