Content uploaded by Levi Rybalov

Author content

All content in this area was uploaded by Levi Rybalov on Jan 02, 2022

Content may be subject to copyright.

Incentivizing Energy Eﬃciency and Carbon Neutrality in

Distributed Computing Via Cryptocurrency Mechanism

Design

Levi Rybalov

January 1, 2022

Abstract

Cryptocurrencies and blockchain technologies have exploded in popularity in recent years.

However, a huge amount of energy is consumed by many of these cryptocurrencies, exacer-

bating climate change, and most of the energy is used for computations which have no value

other than securing the blockchain. In light of this fact, a number of cryptocurrencies were

created with the intent of being secured by, or rewarding, useful computations. In this paper,

we design a reward mechanism for the distributed computing platform BOINC (the Berkeley

Open Infrastructure for Network Computing), which is used by many universities and other

institutions around the world. The reward mechanism is separate from, but intended to be

implemented on top of, a cryptocurrency protocol. The mechanism achieves the three main

intended goals of the BOINC credit system via a multi-dimensional generalization of the pro-

portional allocation reward mechanism of Bitcoin, and an anti-cheating mechanism adapted

from an existing BOINC cheat-detecting mechanism. Since the generalization must be approx-

imated, we introduce several ways of doing so, and analyze the game theoretic aspects of the

approximation. One of these approximations requires a hardware proﬁling database, which has

many use cases well beyond BOINC or cryptocurrencies.

We also explore market mechanisms that balance the preferences of BOINC users with the

strengths of their machines using the well-known Top Trading Cycles algorithm and some of its

generalizations, with the eﬀect of increasing network output and energy eﬃciency. Additionally,

we explore avenues to make the cryptocurrency carbon-neutral. We conclude with an overview

of some existing cryptocurrencies that currently reward distributed computing.

1 Introduction

There are currently thousands of cryptocurrencies in existence, and the technology is under heavy

scrutiny by critics who call attention to the environmental impact of many Proof-of-Work (PoW)

based coins, most notably Bitcoin. A common criticism of PoW coins like Bitcoin is that the

SHA-256 hashing algorithm it uses has no useful output. A number of cryptocurrencies have been

designed to deal with this issue. In this paper, we design a reward mechanism for distributed

computing using the distributed computing platform BOINC, the Berkeley Open Infrastructure for

Network Computing.

BOINC is a middleware that connects projects with crunchers. Projects are often run by

institutions like universities, but can also be run by individuals, companies, or anyone with a server

1

and enough willpower. They send computational workloads to volunteers, called crunchers, who

use their hardware to crunch the computational workloads. All details regarding BOINC necessary

for this paper will be explained in Section 1.1. Despite the focus on BOINC, the methods laid out

in this paper can also be applied to other distributed computing platforms.

Before jumping into the details of how to design such a cryptocurrency, there are some perti-

nent questions that must be answered as to why such a cryptocurrency should be created at all.

The ﬁrst question is, what does this currency do that cannot be done with ﬁat? Indeed, with a

number of countries exploring government-approved digital currencies, what is even the purpose of

decentralized cryptocurrencies?

One of the primary beneﬁts of a cryptocurrency – and the one that will be most leveraged in this

paper – is that its stakeholders have the ability to determine the incentive mechanisms underlying

it; certain behaviors can be encouraged, and others discouraged. This is enabled by the numerous

checks and balances core to the philosophies underlying cryptocurrencies – the intertwined and

overlapping power centers, like core developers, miners (in PoW based coins) or stakers (in Proof-

of-Stake (PoS) based coins), merchants and individual users, and payment services – combined with

the implicit voting inherent to forking a blockchain in order to update or change the direction of

the coin [8], as well as exchanges, which wield signiﬁcant power in the cryptocurrency world.

Since BOINC is being used as a foundation for this reward mechanism, it is also worth asking

what the cryptocurrency that enables these rewards could do that already-existing BOINC credits

cannot. Primarily, a cryptocurrency that rewards BOINC computations would enable transferabil-

ity and fungibility, especially in light of the fact that BOINC projects each have their own credit

reward schemes. It is generally acknowledged that mechanism design – the study and design of

incentive structures – is much easier with money than without money, and that transferable utility

(via the ability to use the cryptocurrency as payment) changes (but mostly expands) the range of

possible incentive structures that can be designed.

If we wanted to translate the traditional PoW reward mechanism to a distributed computing

setting, the mechanism for the latter would reward crunchers proportionally to their computational

contributions – what a cruncher puts into the network, they get out of it in cryptocurrency. How-

ever, there is a major diﬀerence between traditional PoW mining and computations in distributed

computing. In the former, there is only a single function – in the case of Bitcoin, it is the SHA-

256 hashing algorithm. All hardware will have a ﬁxed hashrate on the algorithm, all else being

equal. However, in distributed computing, there is a wide variety of types of computations, and

the performance of diﬀerent types of hardware on these computations does not vary linearly with

the properties of the hardware.

1.1 BOINC Preliminaries

What follows is a brief overview of BOINC, particularly the elements of it that are necessary for

understanding this paper; see Anderson’s paper [3] for a comprehensive overview.

BOINC is an open-source middleware that connects two main groups: the ﬁrst group consists

of projects, which are individuals or institutions that need a large amount of computation that

can be divided into smaller, discrete workloads called jobs; the second consists of individuals called

crunchers who perform those computations with their hardware and return the results to the project

servers.

Projects often subdivide the types of computations they need completed into applications. Ap-

plications are usually a program, with each job of that application having diﬀerent inputs to that

2

program. A project could have some applications that only run on CPUs, and others that are

GPU-based and requires very little CPU time. This paper will base the reward mechanism on

applications, rather than projects, for reasons that will become clear in later sections.

Since crunchers can either intentionally or unintentionally return bad results, projects will often

send out multiple copies of the same job, which are called instances of that job; each instance is

also referred to as a Work Unit (WU). If a project determines that the results of a WU are valid,

which is often based on ﬁnding a quorum of results that agree with each other within some bounds

determined by the project, then that cruncher is awarded credits for completing that WU. The

bounds are necessary because the multitude of diﬀerent hardware vendors and operating systems

can produce diﬀerent results despite running the same programs with the same inputs, even when

the results should be deterministic. The credits are non-transferable and non-fungible, and are used

as an incentive to retain crunchers. The goals of the credit system are reproduced from [3] below:

•be device neutral: similar jobs (in particular the instances of a replicated job)

should get about the same credit regardless of the host and computing resource on

which they are processed;

•be project neutral: a given device should get about the same credit per time

regardless of which project it computes for;

•resist credit cheating: i.e. eﬀorts to get credit for jobs without actually processing

them.

In practice, project administrators choose their own credit-granting schemes, and reward diﬀer-

ent amounts of credits for the completion of diﬀerent WUs based on a variety of factors. Oftentimes,

the credit systems implemented by projects fail to achieve the ﬁrst goal of the credit system. Since

the actual number of credits awarded is also decided arbitrarily by the projects, the second goal

has not at all been met, with some projects awarding orders of magnitude more credits for approx-

imately the same amount of computation. Likewise, the third goal has not been achieved – the

most recent credit design [1] is known to have vulnerabilities that allow crunchers to receive much

more credit than they should.

Every cruncher has an identiﬁer called the cross-project identiﬁer (CPID), which is an identity

that represents a cruncher and their registered machines across all BOINC projects. Under the

current credit scheme, newly awarded credits for every project are factored into both the total

credit, and a number called the Recent Average Credit (RAC), which is a measure of the most

recent contribution of a CPID to a given project. The maximum RAC that a machine can achieve

is equal to the maximum number of credits that that machine can achieve in a day. The RAC

function has a half-life build-up/decay time of one week, meaning that after one week of consistent

crunching, the machine would achieve 50% of its maximum possible RAC, after two weeks, 75%,

etc. Likewise, if a machine stops crunching at any moment in time, then after one week, its RAC

would be 50% of what it was at the time that the machine stopped crunching, after two weeks,

25%, etc. See Appendix A for a code snippet simulating RAC build-up.

1.2 The Bitcoin Allocation Rule and Its Properties

In [6], Chen, Papadimitriou, and Roughgarden establish an axiomatic approach to block rewards in

the Bitcoin blockchain, demonstrating that the current proportional allocation rule used by Bitcoin

is the unique allocation rule that satisﬁes a number of properties: non-negativity, symmetry, (strong)

3

budget balance, sybil-proofness, and collusion-proofness. The deﬁnition of proportional allocation

is simple: for a miner i, the expected rewards pifrom a single block is their hash rate hidivided

by the hashrate of all miners:

pi=hi

Pj∈[n]hj

where [n]=0,1,...n, where nis the number of miners. We will re-use this latter notation in the

rest of this paper. Note that the expected rewards for a miner are linear in that miner’s hash rate.

The non-formal deﬁnitions of the aforementioned desired properties are reproduced below:

•Non-negativity. Expected rewards (the pi’s) should be nonnegative. That is, the

protocol cannot require payments from miners.

•Budget-balance. The protocol cannot be “in the red,” meaning the sum of expected

block rewards cannot exceed the unit of block reward available. Strong budget-

balance insists that the entire unit of block reward is allocated, while weak budget-

balance allows the protocol to withhold some of the block reward from miners.

•Symmetry. The allocation rule should not depend on the names of the miners (i.e.,

their public keys), only on their contributed hash rates.

•Sybil-proofness. No miner can possibly beneﬁt by creating many accounts and

splitting its mining power among them.

•Collusion-proofness. Two or more miners cannot beneﬁt by pooling their mining

resources and somehow splitting the proceeds. This property has diﬀerent variants

depending on what types of payments between colluding miners are permitted; see

Section 2.2.

The authors made the above claims for the case of risk-neutral miners. They also examined the

cases for risk-averse (and risk-seeking) miners, and supplied corresponding possibility and impossi-

bility results.

1.3 Results

In this paper, we introduce an analogue of the proportional allocation rule used in Bitcoin for a new

BOINC credit system, addressing the ﬁrst two goals of the credit system described above, as well as

introduce anti-cheating mechanisms for risk-neutral crunchers (with results that can be extended

for risk-seeking crunchers), addressing the third goal of the credit system. We demonstrate how

this new proportional allocation rule and the anti-cheating mechanisms incentivize energy eﬃciency,

and describe a path towards carbon-neutrality.

In Section 2, a generalization of the proportional allocation rule used in Bitcoin to the multi-

dimensional case is constructed via an Equivalence Ratio between applications, which can be seen

as an exchange rate between the WUs of diﬀerent applications. This mechanism is also shown to

incentivize energy eﬃciency. However, calculating the parameters necessary for the generalization

is diﬃcult in practice, so approximations must be made. The necessity of an approximation makes

it so that sybil-proofness and collusion-proofness are no longer automatically guaranteed by the

construction of the rule, and so these properties must be recovered.

In Section 3, a linear regression approach is used to approximate the Equivalence Ratio, and

some issues and game-theoretic aspects of the approximation are examined.

4

In Section 4, another approach to approximating the Equivalence Ratio based on benchmarks

of every machine on the network is introduced. This approach oﬀers a wide variety of beneﬁts

extending far beyond cryptocurrencies and BOINC, but suﬀers from the inherent unreliability and

unveriﬁability of benchmarks returned by crunchers.

In Section 5, an anti-cheating mechanism is introduced, which addresses the third intended goal

of the BOINC credit system. However, a number of open problems remain, especially regarding

the possibility of projects cheating by recognizing fake results as legitimate.

In Section 6, the diverging incentives caused by the diﬀerence between applications that reward

crunchers the most and the applications that those crunchers most prefer is addressed by a reduction

to a market problem and invoking the Top Trading Cycle mechanism and its generalizations, with

the most general case remaining an open problem.

In Section 7, opportunities to oﬀset carbon emissions and imbue sustainability into the fabric

of the cryptocurrency are explored.

In Section 8, a brief overview of some existing cryptocurrencies which reward distributed com-

puting is provided.

2 Equivalence Ratio

In this section we develop an allocation rule, which is a function that maps the set of crunchers’

computational contributions to a reward vector. Since each cruncher can control more than one

machine, we frame the problem in terms of machines rather than crunchers. This can also be viewed

as each cruncher being broken up into multiple crunchers, each of whom owns one machine.

For any given machine under constant utilization, any given application with a stationary prob-

ability distribution over parameter inputs, the runtimes of WUs from that application and on that

machine follow some probability distribution. By the Law of Large Numbers and the Central Limit

Theorem, the sample average of the runtimes converges to the true average of the runtimes. Thus,

if rewards are based purely on the number of completed WUs of a particular application, then those

rewards would converge to what they would have been if the rewards had been based on the run-

times of the individual WUs. For that reason, the allocation rule rewards the same amount for each

WU from a given application, which in expectation accomplishes the ﬁrst goal of the BOINC credit

system. While the remainder of this paper could be easily modiﬁed to account for the credit schemes

that projects currently use, dealing with WUs removes many of the complications and potential

manipulations involved with calculating credit, without losing any necessary properties. However,

an allocation rule based on this principle is still susceptible to manipulations via cherry-picking

attacks, which is discussed in Section 5.

2.1 Setting

We can now formalize the setting: stripping down the environment of BOINC to the essential

components, the setting consists of a set of machines M={m1, m2, . . . , m|M|}, and a set of appli-

cations A={a1, a2, . . . , a|A|}. Every machine m∈Mis assumed to have the necessary components

required for crunching WUs (a CPU, RAM, main memory etc.), and may have co-processors like

GPUs.

In order to construct the allocation rule, we need to formally deﬁne the computational contri-

bution of a machine. Since each machine can crunch diﬀerent applications, the concept of a single

hash rate like in Bitcoin – or more generally, a single function – no longer applies. Rather, the

5

computational contribution of a machine mican be represented as a tuple wi= (wi1, wi2,...wi|A|),

where wij is the WU contribution of machine mito application ajmeasured in some arbitrary time

unit. For simplicity, we can assume that this time unit is equivalent to the length of the period

for which crunchers are rewarded (this is analogous to the time between blocks in Bitcoin, which

is designed to be about 10 minutes), which we will call the reward period. Then, the contribution

of every machine to every application can be summarized in an |M|×|A|matrix W, which is the

input data to the allocation rule.

The output of the allocation rule is a reward vector r= (r1, r2, . . . , r|M|), where riis the reward

allocated to machine mi. In the literature, the reward vector is usually called the payoﬀ vector.

Note that in contrast to the randomized reward allocation rule used in Bitcoin, rewards in this

setting will be deterministic. For now, the reward mechanism should be thought of as being an

independent layer on top of some underlying blockchain protocol, whether PoW, PoS, or some other

protocol – this topic will be explored more in Section 5.

Throughout the remainder of this paper, when machines are referred to as having agency, it

should be assumed that the machine’s owner is the one making the strategic decisions.

2.2 Allocation Rule

The approach to constructing the allocation rule and reward vector is straightforward: ﬁnd an

equivalence between the WUs of diﬀerent applications, and use the equivalence to determine a

universal computational contribution for each machine, analogous to the hash rate in Bitcoin.

In order to construct the equivalence, we need to deﬁne the WU completion rate, which is a

measure of how many WUs a machine can crunch on an application.

Deﬁnition 2.1. Let ρi

jbe the WU completion rate for machine mion application aj. The WU

completion rate ρi

jis the maximum number of WUs that machine mican accomplish on application

ajin a reward period.

In practice, BOINC crunchers can set limitations on how much their machines crunch. For

the purposes of this paper, machines that are not operating at full capacity can be viewed as less

powerful machines operating at full capacity, or virtual machines that have only subsets of their

hosts’ original computational power available (in fact, a number of BOINC applications run in

virtual machines, which negatively impacts performance).

The next step is to deﬁne the Equivalence Ratio (ER) of a machine. The ER for a machine is a

tuple consisting of the machine’s WU completion rates on each of the applications. Extending the

notation of ρi

j, denote by ρithe tuple representing the ER for mi. Then, for every i∈[|M|],

Deﬁnition 2.2.

ρi:= (ρi

1, ρi

2, . . . , ρi

|A|)

However, ρi0obtained by normalization on another mi06=miwould yield a diﬀerent ER (as-

suming that miand mi0are not identical machines). The next step is to extend the notion of ER

beyond a single machine.

Beginning with the base case, the ER for a set of machines M={m1}is calculated by consid-

ering how much this set can accomplish on each application – in this case, the ER is ρ1. Extending

this logic to two machines, the ER of a set of two machines M={m1, m2}is calculated by con-

sidering how much m1and m2can accomplish on each application together – this would be the

element-wise sum of ρ1and ρ2. Generalizing, the network-wide ER can be calculated by considering

6

how much the set of all machines in Mcan accomplish on each application together. Extending

notation again, we denote by ρjthe jth component of network-wide ER.

Deﬁnition 2.3. The jth component of the network-wide Equivalence Ratio is

ρj=X

i∈[|M|]

ρi

j

Extending notation one last time, we denote by ρthe network-wide ER.

Deﬁnition 2.4. The network-wide Equivalence Ratio ρcan be written as

ρ:= (ρ1, ρ2, . . . , ρ|A|)

The network-wide ER ρis the basis for the allocation rule. Let Rbe the total amount of rewards

allocated to machines during a reward period. The allocation rule is described in Algorithm 1. There

is a direct analogy to the proportional rule from Bitcoin: the total normalized WU contribution Ni

is analogous to hi, the hash rate, and the total normalized WU contribution T N W U is analogous

to Pj∈[n]hj. In contrast to the hash rate, notice that Niis a dimensionless number.

Note that most advanced hardware is located in the industrialized world, a large portion of which

experiences relatively cold winters. It is very common for BOINC crunchers to use their machines as

alternative heat sources during these winters, meaning that there will be more total computational

power on the network during winters than at other times of the year. If the rate of cryptocurrency

minting remains these same throughout the year, then it will be more proﬁtable to crunch during

summer in the northern hemisphere (where the vast majority of the industrialized world, the world’s

population, and hardware is located), which would lead to a lot of wasted potential.

However, if the rewards are scaled to reﬂect the amount of computational power on the network,

a cruncher could receive the same rewards with the same hardware whether or not they crunch in the

summer or the winter. Since crunching during the winter oﬀsets expenditures on heating, that would

make it more economical and energy eﬃcient to crunch in the winter. Making a further analogy

to the generalized proportional allocation rules discussed in [6], Rtakes the place of c(Pj∈[n]hj),

which is some function of the sum of all the hash rates on the network. In particular, if we

set R=T N W U , then each cruncher is rewarded the same ﬁxed amount for every WU of some

application that they complete. Unlike in Bitcoin, this would mean that the total rewards would

be proportional to the computational power on the network.

A natural question to ask about this mechanism is what kind of behavior it incentivizes. It

turns out that using the ER to derive a universal BOINC credit incentivizes crunchers to direct

their hardware towards applications on which they are strongest relative to the network-wide ER,

if they can only crunch one application at a time. A generalization of this idea also applies to the

case where a machine can crunch more than one application at a time. This is an energy-eﬃcient

mechanism in the sense that if the incentives are followed, WUs are going to be crunched by machines

which will accomplish them with lower energy consumption relative to the other machines on the

network. Note that crunchers may have pro ject or application preferences of their own, which would

lead them to not pursue this ﬁnancial incentive. This contradiction, and attempts to resolve it, is

explored more deeply in Section 6.

Theorem 1.The Reward Assignment Algorithm incentivizes directing machines towards applica-

tions on which they are strongest relative to the network-wide ER, if the machines can only crunch

one application at a time.

7

Algorithm 1 Reward Assignment Algorithm

Input:

Network-Wide ER ρ

WU completion matrix W

Total network-wide rewards R

Output:

|M|×|A|normalized WU matrix N

T N W U , the Total Normalized Work Units (network-wide)

ri, the rewards that mireceives in the time interval

——————————————————————————————————————————

Calculate Nand T N W U

Initialize T N W U = 0

for i = 1 . . . |M|do

for j = 1 . . . |A|do

Nij =Wij /ρj

T N W U =T N W U +Nij

end for

end for

Calculate reward vector

for i = 1 . . . |M|do

Ni=Pj∈[|A|]Nij

ri=Ni

T NW U ·R

end for

8

Proof. By deﬁnition, maximizing rewards for miis maximizing ri. From the deﬁnition of ri,

Pj∈[|A|]Nij , and by extension T N W U, are the factors that can be directly aﬀected by a cruncher.

As in the algorithm, let Ni=Pj∈[|A|]Nij , and let T N W U−i=T N W U −Nibe the T N W U

without the contribution of mi. Then, T N W U =T N W U−i+Ni, and

ri=Ni

T N W U−i+Ni

riis an increasing function in Ni, meaning that maximizing Nialso maximizes ri. Since Nij =

Wij /ρj, and the ER is given, this in turn means that Wij is the only factor that can be modiﬁed

by the owner of miin order to maximize their reward.

The maximum possible Wij for machine miand all applications a∈Ais in fact ρiby deﬁnition.

So maximizing Nibecomes ﬁnding the application a0that maximizes ρi

a0/ρa0, i.e.

argmax

a0∈A

ρi

a0/ρa0

Thus, given some ER, the maximum possible reward for any machine that can only crunch

one application at a time is realized by dedicating all of that machine’s computational power to

the application for which the machine’s ER has the largest relative diﬀerence compared to the

network-wide ER.

Corollary 1.If a machine cannot maximize its rewards by crunching only a single application, then

it can maximize its reward by crunching two or more applications which together yield a higher

normalized WU contribution than the application on which it is strongest relative to the ER.

Remark. For a single machine that has both a CPU and GPU, the ER equally values CPU and GPU

calculations. Since GPUs with strong FP64 capabilities tend to be more expensive, and increases

in FP64 performance do not always scale at the same rate as increases in FP32 performance, FP64

can in a sense be considered a diﬀerent type of computation. Then, a single machine actually also

equally values CPU, GPU FP32, and GPU FP64 calculations. There is a similar phenomenon on a

network-wide level, but with the added twist that all machines will have CPUs, but not all machines

will have GPUs.

The “value” of CPU calculations relative to the “value” of GPU calculations depends on a

number of factors and is ultimately subjective. For that reason, it may be preferable to consider

ERs for CPU and GPU applications separately, and then manually choose an equivalence between

the two classes – for example, by considering the average power consumption of recent CPUs and

recent GPUs. This would have the eﬀect of roughly valuing the computational output per unit of

energy equally between CPUs and GPUs, thus directing focus on the most energy-eﬃcient way of

programming an application.

Remark. The ER can change based on the machines that are on the network and the applications

available to be crunched. An interesting implication of this fact is that there is no intrinsic measure

of computational power like FLOPs or runtime that describes the equivalence of computational

requirements between applications; rather, the equivalence is relative to the machines that are on

the network at any given moment in time. This novel approach diverges substantially from prior

attempts to solve this problem, such as in the current credit systems used by many projects, the

most recent iteration of the recommended BOINC credit system [1], or in [4], where Awan and

Jarvis proposed a new type of ﬁxed credit based on a diverse set of benchmarks.

9

However, determining ρis impractical for a number of technical reasons, the most obvious and

disqualifying of which is the diﬃculty or even impossibility of getting trustworthy benchmarks of

every machine crunching every application. Even if getting trustworthy benchmarks was possible,

another major issue is the diﬃculty of running enough WUs of each application in order to get

an accurate WU completion rate. For some machines, a single WU from some applications can

take days or even weeks. For that reason, the rest of this paper will deal with acquiring approxi-

mations of these values. We propose two main methods for achieving this. The ﬁrst method can

be implemented using only minor modiﬁcations to the data currently openly provided by BOINC

projects; in particular, the data needed would be a breakdown of a CPID’s RAC to more granular

data. The second method requires the construction of a hardware proﬁling database, which could

be implemented using lightweight benchmarks of each machine on the network.

Due to the fact the ER must be approximated, there must be assurances on how the actions of one

machine or a group of machines can be used to alter the ER for the beneﬁt of the machine(s). Two

of the main desirable properties discussed in Section 1.2, sybil-proofness and collusion-proofness,

can now be framed in the following way:

Sybil-proofness : no machine can beneﬁt by creating more than one CPID and splitting its

computational resources among those CPIDs.

Collusion-proofness: two or more machines cannot beneﬁt by pooling their resources and split-

ting the rewards in some manner.

The other desirable properties – non-negativity, symmetry, and budget balance – are satisﬁed

by construction.

3 The Linear Regression Approach

In order to build an intuition for the linear regression approach to approximating the ER, we will

use an example involving a sample universe of two applications: A={a1, a2}. After introducing

some assumptions, we will go through the process of approximating the ER, and afterwards address

each of the assumptions and their consequences in a real-world implementation of this approach.

In this universe, machine mican crunch either one application exclusively, the other applica-

tion exclusively, or a combination of both applications. All three of these settings can be chosen

by assigning diﬀerent priorities (called “Resource share” in the BOINC Manager) to each of the

applications.

Consider a priority vector (ui,1−ui), ui∈[0,1] for mi, which denotes the fraction of resources

that goes to each application. One of the simplifying assumptions we will make is that a linear

decrease in the WU output for one application implies a linear increase in the output of another

application; that is,

wi= (ρi

1·ui, ρi

2·(1 −ui))

An example of a line deﬁned by wiranging between 0 and 1 is shown in Figure 1.

Using this model, we begin with a set of machines crunching these two applications, each with

its own computational contribution w, which is visualized as a point in two-dimensional space.

Next, we run a linear regression on the points. Finally, we take the resulting best-ﬁt line, place a

line of equal slope through each of the points, and use these lines to make an approximation b

ρiof

ρifor every mi. See Figure 2 for a visualization of this process.

Calculating the points of intersection with the axes is straightforward. Suppose that for each

mi, the standard-form equations describing ρiare c1a1+c2a2+ei= 0, with c1, c2determined by

10

Figure 1: Example of a line deﬁned by an ER of (100,50) for machine mi, with uiabove, and wi

below, their corresponding points.

Figure 2: The Linear Regression approach for approximating the ER. On the left is a set of points

wifor each machine mi, i = 1,..., 20, which plot the computational contributions of each machine.

In the center is the regression line. On the right are lines with the same slopes as the regression line,

passing through each of the points. The intersection of each line with the axes is an approximation

b

ρiof ρi, from which an approximation bρof ρcan be calculated.

the linear regression, and an intercept eifor each machine mi. Then, the network-wide ER would

become

(−1

c1X

i∈[|M|]

ei,−1

c2X

i∈[|M|]

ei)→(1

c1

,1

c2

)

In three dimensions, the logic generalizes: the regression will deﬁne a plane, and the three points

where the plane intersects the axes are the corresponding values in the ER. Generalizing further

to |A|>3 applications, every wican be mapped to its own (|A| − 1)-dimensional hyperplane,

11

with the intersection of that hyperplane with the |A|axes constituting the b

ρi. By Deﬁnitions 2.3

and 2.4, adding up these points of intersection application-wise would yield an approximation of

the network-wide ER. Since the b

ρiare all constant multiples of the points of intersection of the

(|A| − 1)-dimensional hyperplane with the |A|axes, the sum would also be a constant multiple of

the points of intersection, and therefore, only the output of the linear regression need be considered,

just as in the preceding 2-dimensional example.

When running linear regression in practice, one application is written as a linear function of the

others:

a1=c1+c2a2+c3a3+. . . c|A|a|A|

Then bρ1=c1, and

bρi=−c1

ci

∀i6= 1

Factoring out c1,

bρ= (1,−1

c1

,−1

c2

,...,−1

c|A|

)

In Figure 3 are the results of the linear regression approach applied to data obtained from the

Gridcoin network (a cryptocurrency that rewards crunchers for their BOINC contributions) for a

subset of BOINC projects. However, the available data was limited to a list of CPIDs by their

RACs on every project, and had to be whittled down. In order to implement the linear regression

approach properly, this data would need to be even more ﬁne-grained by machine (rather than by

CPID), by application (rather than by project), and by number of WUs completed (rather than

by RAC); these data can only be acquired via changes to the BOINC source code. Since that data

is not currently available, only a subset of the data that likely corresponds to individual machines

crunching one application was used. See Appendix B and the corresponding Jupyter notebook for

a detailed description of how the data was handled and why the granular data is needed.

Figure 3: Actual ER Calculation

12

3.1 Shortcomings of the Linear Regression Approximation

3.1.1 Inaccuracies in Estimation

The assumption that under constant hardware utilization a linear decrease in output for one ap-

plication implies a linear increase in output for another application is not necessarily correct. For

example, by varying u, it is possible that some threshold of cache, RAM, or other resource is

reached which results in a non-linear change or discontinuity in the amounts of each application

that a machine could crunch. Furthermore, the underlying relationship could even be a (piecewise)

curve. Another assumption made in the linear regression approach was that, in addition to the

relationships being linear, the hyperplanes deﬁning the ER for each machine had the same coeﬃ-

cients, which also is not necessarily correct. The following theorem bounds the error between ρand

bρas determined by the linear regression.

Theorem 2.The application-wise absolute diﬀerence between the true ER and the estimated ER

deﬁned by the linear regression is bounded above by the number of machines times the maximum

application-wise absolute diﬀerence for any machine mibetween ρiand ρ:

|ρa−cρa|≤|M| · max

i∈[|M|]|ρi

a−c

ρi

a|

∀a∈A.

Proof. By Deﬁnition 2.3,

ρa=X

i∈[|M|]

ρi

a

We also have that

cρa=X

i∈[|M|]c

ρi

a

Then

ρa−cρa=X

i∈[|M|]

ρi

a−X

i∈[|M|]c

ρi

a

=⇒ |ρa−cρa|=|X

i∈[|M|]

ρi

a−X

i∈[|M|]c

ρi

a|

=|X

i∈[|M|]

ρi

a−c

ρi

a|

≤X

i∈[|M|]

|ρi

a−c

ρi

a|

≤ |M| · max

i∈[|M|]|ρi

a−c

ρi

a|

(1)

In practice, the estimated ER will be much more accurate, because it will not be the case that

the diﬀerence between c

ρi

aand ρi

awill have the same (maximum) magnitude and direction for all

i∈[|M|].

13

Another key issue is the fact that if one application uses only a CPU, while the other uses a bit

of the CPU and mostly the GPU, then the linear relationship described earlier will not hold even

approximately. For example, in the two-application universe, while it will be true that the b

ρifor a

particular machine on those applications will intersect the axes, the relationship will not be linear

– it will look more like a rectangle with a rounded upper right corner. If there are enough such

machines, then the linear regression over all the machines on the network will not even intersect

the two axes on their positive rays.

As was discussed in Section 2, this problem can be addressed by separating the CPU applications

and GPU applications, determining the ERs within these classes, and then choosing an equivalence

between the two classes of computations. This process can also be done at an even more granular

level – for example, by splitting the GPU class into FP32 and FP64 applications.

A further potential shortcoming of the linear regression approach is that converging on an

accurate estimate of the ER in the limit of a large number of machines requires that the distribution

of the computational powers of the machines crunching each of the applications is identical – i.e.

that for each application, each machine crunching it is i.i.d. from the same distribution as all the

other applications. However, there is no way to know whether this is in fact the case, or to create

such a situation.

Setting aside things like driver versions, if we assume that there are no WUs that are too simple

to run on any hardware, then we can conclude that WUs can only not run on some hardware

if those WUs are too demanding. For example, consider again a two-application universe, and

suppose that WUs from one application require more RAM or GPU VRAM than many machines

have, and the other application supports all machines. A linear regression would roughly lead to

an approximated ER that equates the averages of the outputs on the two applications. However,

since only more powerful machines can crunch the more restrictive application, then the more

powerful machines that crunch the more restrictive application will be undervalued. This would

incentivize application developers to develop applications that can be run on as many diﬀerent

types of machines as possible.

Overall, while this may not aﬀect strategic aspects regarding sybil-proofness and collusion-

proofness, it does add another error to the way that the ER is being calculated.

3.1.2 Game-theoretic Analysis

It is possible that sybil-attacks or collusion-attacks could also be used to alter the ER. These types

of attacks can be partially mitigated by using weighted linear regression, where the weights could

be, for example, the computational contribution of the points. An initial ER could be calculated

by standard linear regression, which is the same as every point having the same weight. Then,

each machine could be weighted by its Ni, and the weighted linear regression could be iterated

until convergence. It is not clear whether this method of calculating the ER is sybil-proof and/or

collusion-proof.

In recent game-theoretic literature, there has been a focus on determining the computational

tractability of computing moves that would beneﬁt agents. It is possible that the weighted linear

regression approach, or even the linear regression approach without weights, would have so many

agents and so many unpredictable factors that computing moves that maximized rewards even in

expectation could be in some complexity class that in practice renders attempts at manipulation

unfeasible. Furthermore, by Theorem 1 and by construction of the weighted linear regression, any

such manipulations intended to award the manipulator(s) higher rewards would still ultimately

14

incentivize the manipulator(s) to be energy eﬃcient. Whether or not the linear regression approach

is sybil-proof or collusion-proof either by the deﬁnitions given earlier, or because ﬁnding beneﬁcial

strategies is computationally intractable, remains an open problem.

The remainder of this section is a game-theoretic analysis of what would happen if every cruncher

chose to crunch applications which maximized their rewards based on the most recent ER. The case

where crunchers do not act solely in their ﬁnancial interests is addressed in Section 6. While it is not

necessary for understanding the rest of the paper (since the underlying assumption that crunchers

will only act in their ﬁnancial interest almost certainly will not hold), some readers may ﬁnd it

interesting.

Recall that we begin with the input W, from which the ER is calculated. Suppose then that

every machine tries to maximize its reward for the next reward period based on the ER from the

current reward period. Recall that the true slopes of the ERs, ρi, may not all be constant multiples

of bρor ρitself – see Figure 4 for an example of the general case of the example ERs from Figure

2. Thus, depending on W, it may be possible that bρis changed during its next calculation such

that machines have an incentive to switch to a diﬀerent application (note that if in fact the slopes

were all constant multiples of bρ, then switching from one application to another would not change

bρ, since wiwould remain the same distance away from bρfor any ui).

Figure 4: General ERs

A two-dimensional implementation of this game can be found in Appendix C. We were able to

ﬁnd instances which converged to a stable ER, diverged, and cycled. The latter ﬁnding indicates

that even in this simple scenario, a pure-strategy Nash equilibrium does not exist. For much larger

numbers of machines, which would be the case in practice, we did not ﬁnd an instance that did not

converge.

In theory, a mixed-strategy Nash equilibrium should exist. There are a ﬁnite number of crunch-

ers, and each each cruncher has a ﬁnite (although quite large) set of strategies, which are the

various combinations of WUs from diﬀerent applications that they can crunch in a reward period.

The simulations just described were repeated games in which crunchers were choosing the best

possible strategies based on the results of the previous game.

15

In practice, a number of the assumptions necessary for a Nash equilibrium to be reached would

not be fulﬁlled. As already mentioned, not all crunchers will try to maximize their rewards. Even

if we kept ﬁxed the contributions of crunchers who chose not to maximize their rewards, and only

considered crunchers who did, there are a number of reasons that the game would still not converge

to a Nash equilibrium. First, there is no guarantee that each remaining cruncher would execute

their strategy ﬂawlessly. Furthermore, it is not the case that a deviation of a cruncher would not

cause deviations by other crunchers. Additionally, due to the dynamic nature of the network, with

hardware coming online and oﬄine, along with crunchers switching which applications they crunch

for other reasons, computing the best possible strategy (or even a proﬁtable one) might be in a

complexity class that is not possible to compute.

4 Hardware Proﬁling Database

Like the linear regression approach introduced in Section 3, the basis of the Hardware Proﬁling

Database (HPD) approach to estimating ρrelies on obtaining predicted ERs for each machine. At

the core of the HPD method is a set of benchmarks B={b1, b2, . . . , b|B|}, which are a variety

of tasks that measure processor speeds, RAM size and bandwidth, bandwidth between CPU and

GPU, available disk space, etc.; another attempt to construct a new BOINC credit by Awan and

Jarvis also included a larger number of benchmarks than the current BOINC system uses [4]. As

before, machines running at a fraction of their capacity can be viewed as either weaker machines or

virtual machines. Machines without GPUs would have their GPU benchmarks equal to 0. Then,

the HPD is an |M| × |B|matrix H, where Hij is the output of machine mion benchmark bj∈B.

With Hin hand, it is possible to map a machine’s benchmarks to its expected output on each

application. Deﬁne a family of functions F={f1, f2,...f|A|}. Each function f∈Fmaps the

benchmarks bof a machine mto an expected output on an application a. Let the benchmarks for

machine mibe bi. Then,

fa:bi7→ c

ρi

a,∀a∈A, m ∈M

With c

ρi

ain hand for all machines and all applications, and using Deﬁnitions 2.3 and 2.4, bρcan

be easily constructed.

The family of functions Fcan be any of a variety of traditional statistical methods or machine

learning algorithms. Below we list some costs and beneﬁts of linear regression, non-linear regressors,

and neural networks, but these methods are non-exhaustive and should be considered merely as

examples.

Linear regression would provide weights (coeﬃcients) for each benchmark, which helps explain

which aspects of a machine are important in determining its b

ρi. However, it is limited by its

linearity, which can be somewhat compensated for by feature engineering. Additionally, linear

regression naturally supports multiple outputs. Further improvements can be made on top of linear

regression, such as generalized linear models, or in the case that cruncher-supplied data is being

used to make the mappings, using linear regression ﬁrst on the machines that only crunch single

applications, and once an equivalence ratio is found, adjusting it based on the machines that crunch

multiple applications.

Non-linear regressors, such as random forests or gradient boosting, would also provide the

relative importances of benchmarks in predicting outputs. Unlike linear regression however, they

can ﬁnd how non-linear relationships between the benchmarks determine a machine’s performance

16

on a given application. One downside of this approach is that these algorithms (at least, the ones

mentioned) are not inherently multi-output. Multi-output wrappers do not take into account how

the predictions for each component of the output depend on each other, and so only data involving

single outputs (applications) could be used.

Neural networks are both multi-output and non-linear; however, they do not provide an easy

way of determining relative importances of particular inputs.

4.1 Implementation Challenges

There are two main implementation issues in the HPD approach. The ﬁrst issue is the diﬃculty of

getting reliable benchmarks from each machine, or a statistically large enough sample of machines.

The second issue is determining F.

Suppose that these benchmarks were obtained by sending WUs from a BOINC project. With the

assumption that the benchmarks would either be posted to the blockchain or veriﬁed in some other

way by the network, the veriﬁcation that the benchmarks are in fact what crunchers submitted them

as is trivial. The issue is that WUs are sent as binaries, and should be treated as being completely

reverse-engineerable, in the sense that one could recover the original code that constructed the WU.

From this point, the WU could be manipulated – a cruncher could run any code, and submit any

result, that they wanted to. Unlike deterministic BOINC WUs, there is currently no way to verify

whether the results from a benchmarking WU are honest, barring obvious and extreme cases. The

most obvious method of ensuring that such benchmarks would be trustworthy – trusted computing

– is unpopular because of privacy concerns.

From a computational standpoint, determining Fis trivial. The troubles arise when determining

which benchmarks and application outputs are used. In a more centralized setting, there could be a

set of trusted machines, and their outputs could be used to determine F. These machines and their

trustworthiness could be a combined eﬀort of crunchers and projects, or some cryptographically

secure approach. An alternative approach is to operate under the assumption that some subset of

the benchmarks is unreliable, and try to deal with that problem as best as possible. Additionally,

the benchmarks in Hcould also be combined with Win order to approximate the ER, in a similar

way to what was done with linear regression, but with the addition of this new and useful dataset.

4.2 Beneﬁts of the HPD

This database would have a wide variety of uses beyond trying to approximate the ER, and even

beyond cryptocurrencies and BOINC.

First, projects would be able to use benchmarks and outputs to design their applications in

ways that take advantage of potential optimizations, and plan the structure of future applications

based on existing hardware or anticipated new hardware on the market.

Non-BOINC researchers could use the benchmarks for similar purposes as the project admin-

istrators – data-mine the database to ﬁnd interesting patterns that could yield new insights into

hardware evolution over time, which has the added advantage of attracting new researchers to the

BOINC community. For example, in [9] and [10], Al-Qawasmeh et al. take a database with the same

form as Hand deﬁne three measures on the set of machines: Machine Performance Homogeneity

(MPH), Task-Machine Aﬃnity (TMA), and Task Type Diﬃculty Homogeneity (TDH). These mea-

sures are used to characterize heterogeneous computing environments to provide insights on how

to optimize the use of the machines.

17

Crunchers could use the database to inform themselves about future hardware purchases, as

well as use the information to fully predict the ERs of their machines, which is useful in addressing

the tradeoﬀ between crunching their favorite applications and the most proﬁtable applications, as

addressed in Section 6.

Companies or other institutions could use the database for their own hardware-purchasing de-

cisions, and even use the network and benchmarking projects to send out their own benchmarking

WUs while paying crunchers for their services with the cryptocurrency, creating a source of demand.

5 Anti-Cheating Mechanism

Many projects have multiple instances of a job sent to diﬀerent machines in order to detect cheating

or bad results due to numerical instabilities across diﬀerent platforms and types of hardware. Some

projects use adaptive replication [2] of jobs, in which trust is established between an application

and a machine, resulting in that machine being sent jobs with fewer and fewer replicated instances

from that application, as long as the WUs are consistently returned with reliable results by that

particular machine. If results are found to be invalid, then the host has to start again from zero

trust.

Both the adaptive replication policy and the reward mechanism introduced in Section 2 can

be modiﬁed to reward a machine more for being trusted and consequently crunching jobs with

fewer replicated instances. The modiﬁed reward mechanism would discourage cheating by making

it as least as proﬁtable (more proﬁtable) to be honest as it is to cheat, making honesty a weakly

(strongly) dominant strategy, and consequently lead to gains in energy eﬃciency.

This anti-cheating mechanism can be implemented on the project-level and/or the network-

level. In the former case, the incentive for crunchers would be to minimize the number of replicated

instances that they crunch, but otherwise there would be no inter-project eﬀects. In the latter case,

the energy eﬃciency of the network can be improved even further. Machines have an incentive to

crunch jobs that have the fewest number of replications, and projects have an incentive to have

their workloads computed quickly, want to attract the aforementioned machines, and so likewise

have an incentive to reduce the number of replications. This would create a system where projects

attempt to attract crunchers and compete with each other by reducing replication. Whether or

not this is a good dynamic to introduce to the network is beyond the scope of this paper, but the

possibility should be seen as one of a number of parameters that can be changed to incentivize

diﬀerent types of behavior.

Such a mechanism could also instigate new research into cross-hardware, cross-platform, cross-

operating system numerical stability. Interestingly, it may also whittle down the machines that

crunch particular applications to only those that consistently return reliable results (which are

the machines that are numerically stable on those application/platform pairs), in a sense sorting

the machines by their ability to return correct results, if the cause of incorrect results is because

of some numerical instability. Note that this latter eﬀect might undermine one of the underlying

assumptions of the linear regression approximation of the ER by making the distribution of machines

across applications diﬀerent.

5.1 Past

Assume that a project can temporarily rescind credit for, and verify through additional replication,

the results of previously approved WUs. The case where only future WUs can be additionally

18

replicated is addressed in the subsequent section.

Consider a machine mithat has a stream of incoming WUs from some application a. Let wj

be the jth WU sent to miafter some initial starting time. Let tjbe the number of instances of the

job corresponding to wjthat were sent to diﬀerent crunchers. Let rj=rbe the constant reward

given to the cruncher for completing a WU from application a.

In order to disincentivize cheating, the expected reward from being honest must be greater than

or equal to the expected reward from cheating. One natural mechanism to try would be to scale

the rewards for the completion of a given WU by the inverse of the number of instances of that job,

so that rj=r/tjrather than rj=r. This can be interpreted as granting a total reward rfor every

job, with every machine that crunched one of the instances of that job getting its equal share of

the reward. If tj= 1, then miis the only one that crunched wj, and so rj=r, and migets all of

the reward; if tj= 2, then migets half of the reward, etc.

Consider the simple case where either there is one copy or there are two copies of wj, i.e.

tj= 1 or tj= 2 – the following results generalize easily. Towards the aim of discouraging cheating,

project administrators replicate wjwith some probability p. We assume that the event that a job

is replicated is independent of the event that micheats, and that michooses to cheat using some

strategy of when to cheat and when to return legitimate results.

Since every job has probability pof being replicated independently of other jobs being replicated,

it is only necessary to consider a subset of the WUs that micrunches – in particular, those for

which micheats. Since these WUs had probability pof being veriﬁed when considering all the

WUs, they still have probability pwhen considering only the subset. Thus, the strategy by which

micheats is not relevant. Since the probability of a WU being replicated is Ber(p), the number of

instances sent until one is replicated is Geom(p), and so in expectation miwill be caught after 1

p

WUs, implying that there will be 1

p−1 occurrences of micheating and not getting caught.

The goal is to have the loss in rewards be greater than or equal to the expected rewards from

cheating. Let nbe the number of veriﬁed WUs. Now, the loss

L= (rewards if past nWUs were not veriﬁed) - (rewards if past nWUs are veriﬁed)

and the rewards from cheating

C= rewards if past WUs were not veriﬁed while machine was cheating and was not caught

and we want L≥E[C]. When considering the results of WUs which are being retroactively

replicated, it will be assumed that they are all veriﬁed as being legitimate results – otherwise, this

entire process of replicating already accepted WUs can be applied recursively.

19

Now,

L

=

n

X

i=1

ri−

n

X

i=1

r0

i

=

n

X

i=1

r

1−

n

X

i=1

r

2

=

n

X

i=1

(r−1

2r)

=n

2r

(2)

Invoking the memorylessness property of the geometric distribution, a sequence of cheat results

– the aforementioned subset – will be caught in expectation 1

pWUs into the sequence. Thus,

E[C]=(1

p−1) r

1

Finally,

L≥E[C] =⇒n

2r≥(1

p−1)r=⇒n≥2(1

p−1)

It is important to note that this mechanism will not catch all illegitimate results submitted by

a cruncher; rather, it will ﬁnancially disincentivize cheating in expectation, since crunchers might

still be able to proﬁt by cheating in some cases, but not on average. Increasing nbeyond the lower

bound found above can be used to make cheating an arbitrarily bad strategy.

5.2 Future

When only future WUs can be additionally replicated, the goal is still similar to the one in the

past case: to have the expected rewards under an honest strategy be greater than (or equal to) the

expected rewards under a cheating strategy.

Since a machine could get to the point where it is sent the fewest number of replicated instances,

cheat for as long as it can, and then stop crunching the application once it is caught, it could proﬁt

from cheating as long as it is not possible to retroactively verify WUs. For the future setting, we

introduce a deposit d, which can either be in the form of non-replicated WUs which are treated

as replicated WUs (meaning that the cruncher receives a lower reward than they should have for

crunching those WUs), or some amount of the cryptocurrency itself. If the deposit is withdrawn or

withheld, it must be rebuilt if the machine/cruncher wants to continue running that application.

The idea is that a machine can gain at least as much by taking its deposit and discontinuing

crunching that application as it can by cheating.

Let nand rbe as they were in the prior case, and as before, consider only the WUs for which

the machine is cheating. Consider some starting WU w1, during which miis already under the

WU veriﬁcation scheme with minimum replication, and assume that miis cheating starting when

they received w1. Let wjbe the WU for which miwas caught returning bad results. Since by

20

construction we are only considering WUs for which miis cheating, w1. . . wj−1have no other

instances – that is, miis the only one crunching them.

Up until wj,mihas gained (j−1)rfrom cheating, so the loss for mimust be greater than (or

equal to) (j−1)r; setting d≥(j−1)raddresses this problem. Since we do not know jahead of

time, we can set d≥E[(j−1)r] = ( 1

p−1)r. Once miis caught, the deposit is lost, and it must be

rebuilt in the same manner it was constructed.

5.3 Cherry-picking Attacks

Under the most recent iteration of the BOINC credit system [1], there is an attack vector by which

a cruncher only crunches shorter WUs and abandons longer WUs, called a cherry-picking attack.

This would still be an attack vector in the reward mechanism described in this paper. There are two

main sources of information that a potential attacker might have: 1) the estimated WU runtime

as given by projects, and 2) empirical estimates of the mean, percentiles, variance, and potentially

other statistics of the runtimes on the attacker’s machine.

The problem caused by the ﬁrst source of information can be solved by simply not providing

crunchers with such detailed information; perhaps an average runtime and variance would suﬃce.

The second problem is trickier. For a given machine, job runtimes from a particular application

will come from some probability distribution X. In order to eliminate the cherry-picking attack, X

would have to come from some family of distributions where, given the elapsed time t,Xis such

that E[X−t|t]≤E[X] for all t.

For example, if the runtime distribution is bimodal, then the time diﬀerence between the argu-

ments of the modes would need to be larger than the time diﬀerence between zero and the minimum

of the arguments of the modes. If the latter condition does not hold, then several WUs could be

wrapped together into a single WU such that the distribution of runtimes becomes unimodal, al-

though this would still not necessarily satisfy E[X−t|t]≤E[X] for all t. For example, a unimodal

distribution skewed strongly to the left might still not meet the necessary criterion.

Alternatively, some form of punishment could be used to dissuade crunchers from using this

attack. For example, the number of WUs sent to a machine could be reduced if too many WUs

are returned as abandoned. Another form of punishment could be higher levels of replication for

hosts that have returned many abandoned tasks. Additionally, it is worth noting that use of the

cherry-picking attack could actually damage the cruncher because of its eﬀect on the ER (in the

linear regression approach), but it is likely not to matter on the scale of a single machine.

5.4 Project Collusion

While the crunchers can be incentivized to not cheat, the projects must also be disincentivized from

cheating. Consider a project that wants to conﬁrm that some particular machine(s) completed

more WUs than they actually did. Split the machines on the network into two groups: machines

knowingly colluding with the project, and all other machines. If the WU distribution is randomized

in a trustworthy manner, then it would be impossible to favor any machines in the second group. For

example, the WUs could be randomly distributed by relying on randomized data from the blockchain

to determine which WUs go to which machines, with that process carried out and veriﬁed on the

blockchain. To know whether or not a job should be replicated, projects could be told to which

machine the WU was sent after it was already sent, after determining whether the result should be

accepted at all, or at some other point. The randomization process just described might interfere

21

with the methods that BOINC projects use to schedule jobs (in particular, projects need to know

which platform a machine uses, since there are diﬀerent application versions for diﬀerent platforms);

see [3]. However, the fact that machines are incentivized to crunch the applications on which they

are most eﬃcient somewhat counterbalances this interference. It may also be possible to reconcile

these problems with further research – the purpose here is merely to demonstrate feasibility.

However, it would still be possible to favor colluding machines by simply having them return

a result from a set of results that the project automatically recognizes as legitimate, but knows is

actually being returned from a colluding machine. It may be the case that the only way to deal

with this problem is by having some sort of trustworthy oversight over which types of WUs are

considered legitimate results – however, this problem is beyond the scope of this paper. (Note that

there is nothing wrong with a (non-proﬁt) project using its own machines to crunch WUs.)

5.5 Open Problems

There remain a number of open questions about this anti-cheating mechanism. Does the expected

payoﬀ from cheating increase with the number of machines under the control of the attacker? What

fraction of the machines on the network (or crunching a particular application) would an attacker

have to control in order to have a higher expected payoﬀ from cheating than from being honest?

What would happen if some fraction of WUs were sent on to triple veriﬁcation – could this mitigate

large scale attacks?

In another vein, the anti-cheating mechanism as described only works properly for WUs that

have deterministic results. It is an open problem on how to disincentivize cheating for WUs with

non-deterministic results.

Note another interesting open problem: the project collusion issue is one of the main obstacles

in constructing a true Proof-of-Research coin, which is why both Curecoin and Gridcoin have their

reward mechanisms built on top of PoS protocols. One possible solution, theoretically but not

practically, is to have every project for which a cruncher can receive rewards publish data on the

blockchain – in particular, how jobs are created, to which machines they are distributed, the results,

and by what rules the results are accepted or rejected. Beyond obvious privacy concerns, this would

also be an enormous amount of data to be stored, in addition to the fact that it could potentially

make exploits much easier.

6 Top Trading Cycles

Despite ﬁnancial incentives, crunchers might still choose to crunch less proﬁtable applications. In

order to balance the eﬃciency of a machine and the desires of its owner, we oﬀer two restricted

formulations of this problem and describe how they can be solved using the Top Trading Cycles al-

gorithm and its generalizations, and conclude with a general formulation describing a more realistic

version of the resource allocation problem.

6.1 Intuition

Suppose that two crunchers each have a machine of their own, with the following ERs:

Application 1 Application 2

Machine 1 ρ1

1= 100 ρ1

2= 50

Machine 2 ρ2

1= 50 ρ2

2= 100

22

A preference proﬁle is a set of binary relations between each application where aibmeans

that iprefers ato b. We will assume that preference proﬁles are not complete – that is, it is not

necessary that all applications are in the relation. However, they are transitive: if aband bc,

then ac.denotes a weak preference, while denotes a strong preference.

Now suppose that the two preference proﬁles for the two crunchers are 1=a21a1and 2=

a12a2. Cruncher 1 can oﬀer to crunch their less preferred application in exchange for cruncher

2 crunching cruncher 1’s more preferred application, while keeping the rewards for crunching the

less preferred application, and vice versa. This way, both crunchers can have their more preferred

applications crunched while still utilizing the full potential of their machines, and realizing an overall

better outcome.

Consider another example with three crunchers, each with their own machine:

Application 1 Application 2 Application 3

Machine 1 ρ1

1= 100 ρ1

2= 50 ρ1

3= 25

Machine 2 ρ2

1= 50 ρ2

2= 25 ρ2

3= 100

Machine 3 ρ2

1= 25 ρ2

2= 100 ρ3

3= 50

with preference proﬁles 1=a31a21a1,2=a22a12a3, and 3=a13a33a2. It

is easy to see that having each cruncher crunch their machine’s most proﬁtable application results

in amounts of WUs of each application being crunched that is more preferred by each cruncher

than if they each crunch their favorite application.

What follows is an informal explanation of desired properties of mechanisms in the ﬁeld of

resource allocation problems.

In both examples, it is clear that every cruncher, in terms of their application preferences,

prefers the outcome where they each crunch their most proﬁtable applications than if they each

crunched their favorite applications. We can say that the former assignment Pareto dominates the

latter assignment, meaning that every cruncher at least weakly prefers the former assignment to

the latter, and at least one cruncher strictly prefers it. An assignment is Pareto eﬃcient if it is not

Pareto dominated by any other assignment.

We also introduce the notion of the core. The core is the set of assignments in which no subset

of the agents can deviate and arrive at a better assignment for that subset. As explained in [7],

an assignment in the core also implies individual rationality – that is, no cruncher can possibly

do worse by participating in the mechanism than they could on their own – and Pareto eﬃciency,

since if an assignment is in the core, and it is Pareto dominated by some other assignment, then all

the agents would have an incentive to deviate to the other assignment, meaning that the original

assignment was not in the core.

The ﬁnal concept is strategyproofness, which is a property that means no cruncher can beneﬁt

by misreporting their preferences.

We can now deﬁne the ﬁrst part of the problem: each machine mihas an endowment, which

in this case is ρi. The second part of the problem is traditionally the set of preferences proﬁles

= (1,2,...,|M|). However, the preference proﬁles over applications need to be modiﬁed to

be preference proﬁles over the machines.

Note that the mechanics of the exchange in the context of BOINC or blockchains/cryptocurrencies

are not discussed here; the purpose of this section is to explore the feasibility of the underlying

mechanism.

23

6.2 Reduction to Top Trading Cycles

We begin with the simplest possible reduction: suppose that each cruncher only owns one machine,

and each machine can only crunch one application at a time.

In order to transform preferences over applications to preferences over machines, the application

preferences just introduced need to be reﬁned. Let the new preference proﬁle over applications

ifor machine mibe an ordering over amounts of WUs from applications in decreasing order of

preference. For example, consider the second machine from the second example above. One possible

new preference proﬁle for m2is 2=a25

2a50

1a100

3. This new preference proﬁle over applications

indicates that m2would prefer to trade for more than 25 WUs of a2, which is logical, since it is

m2’s most preferred application, and they can only achieve 25 WUs alone. If there are no machines

available for trade that can achieve that many WUs, either because no other cruncher is oﬀering

that, or because all the machines that could achieve that number of WUs were already traded for,

then m2’s subsequent preference is more than 50 WUs of a1– which again, m2cannot achieve on

its own. Finally, m2would prefer more than 100 WUs of a3– which again, m2cannot achieve on

its own.

Another possible sequence is 2=a75

1a25

2a50

1a100

3. This is the same as the previous

sequence, except with an additional preference at the beginning, indicating that m2prefers more

than 75 WUs of a1to more than 25 WUs of a2. Note that the assumption so far has been that

these minimums are exclusive. If the minimums are not exclusive, then a machine might end up

preferring itself to any other machine – this is easily taken care of by TCC and its generalizations.

Now these new preferences over amounts of WUs need be transformed into preferences over

machines. Consider the following transformation: for the ﬁrst element in a preference proﬁle, the

subset of machines satisfying the corresponding minimum can be sorted in decreasing order of

their performances on that application, appended to the ﬁnal list of preferences over machines, and

removed from the pool of machines; this is the ﬁrst subset of preferences for the machine. This

process would be repeated for every element in the preference proﬁle. Note that a cruncher can

have two or more separate values for a single application, as long as those ranges are separated by

at least one other application (otherwise they could be reduced to the minimum among them), as

just illustrated with the second possible sequence. This would create an ordering over all machines

with no repeats, and is formalized in Algorithm 2.

This transformation makes the problem setting the same as the traditional setting for TTC

(a housing market), and so the original TTC algorithm can be invoked. TTC is known to be

core-selecting and strategyproof.

6.3 Multiple Endowments

A natural extension of this formulation is to the case where crunchers can own more than one

machine, which of course is the case in reality. This is a well-researched area with a plethora of

useful results, some of which we describe below.

First, S¨onmez showed in [11] (Corollary 2) that in indivisible goods economies, if there is at least

one agent that owns more than one good, then there is no allocation rule that is both core-selecting

and strategyproof (the author originally used Pareto-eﬃcient and individually rational in place of

core-selecting, but the statement follows simply when taking into account that the core is both

Pareto-eﬃcient and individually rational, as already described).

In [7], Fujita et al. present a generalized version of the housing market problem with condition-

ally lexicographic preferences over bundles of objects, and introduce an algorithm called Augmented

24

Algorithm 2 Preference Assignment Algorithm for mi

Input:

M,ρj∀j∈[|M|], and preference proﬁle over amounts of WUs i

Output:

Preference proﬁle over machines 0

i

——————————————————————————————————————————

0

i= [ ]

for k= 1 . . . len(i)do

amount, application = i[k]

satisfying = {i∈[|M|]|ρi

application >amount}

0

i.append(satisfying machines sorted in decreasing order of performance on application)

remove satisfying machines from M

end for

Top Trading Cycles (ATTC), which they showed is also core-selecting, and prove that ﬁnding ma-

nipulations is NP-complete. These manipulations include lying about preferences, splitting endow-

ments, and hiding endowments.

In [5], Aziz presents the Fractional Top Trading Cycle (FTTC) algorithm. The setting is one

in which agents can own more than one house or fractions of houses, and the author proceeds

by breaking each agent into subagents for each of the houses, where each subagent owns what its

superagent owned. We reproduce a theorem from that paper below:

Theorem 6 [Aziz]. For the housing markets with strict preferences, discrete but multi-unit

endowments, FTTC is equivalent to the ATTC mechanism.

A corollary is that FTTC is also as hard to manipulate as ATTC.

6.4 General Setting/Open Problem

A further extension of the problem is to the case where crunchers can oﬀer to crunch more than

one application. Beyond this, there are also generalizations where crunchers can have non-strict

preferences, or even preference classes, over some ranges of WUs of diﬀerent applications; however,

the latter generalizations are beyond the scope of this paper.

We will re-use the assumption from Section 3 that given a constant level of use for a given

machine, a linear decrease in the output of one application implies a linear increase in the output

of another application (keeping in mind the separation between CPU and GPU applications).

Formalizing this, let the non-negative weights for each application be g= (g1, g2,...g|A|), and

Pi∈[|A|]gi= 1. Then the endowment of a machine miis g⊗ρi, where ⊗denotes element-wise

multiplication. The preference proﬁles remain as they were previously. This setting diﬀers from the

aforementioned multi-endowment and fractional settings in that the endowment here is not only

multi-dimensional, but the endowments and the allocations can be any arbitrary fraction of every

application, as long as the fractions sum to 1. Note the critical fact that the linear increase/decrease

property does not hold in general, and especially does not hold when taking into account CPU and

GPU applications. The purpose here is to present the most basic extension of this problem.

In [12], Yu and Zhang drop entirely the idea of trading cycles, and instead propose describing

the trades in terms of parameterized linear equations. This approach may be much better suited

for the general setting we have here, since it simpliﬁes the complex problem of deciding who trades

25

what with whom, and the linearity of the equations might make it much easier to handle the linearly

balanced endowments.

There may also be entirely diﬀerent approaches that are better suited to solving this prob-

lem. For example, genetic algorithms and other techniques intended to optimize use of distributed

computing resources could ﬁnd allocations that satisfy certain social welfare functions better than

generalizations of TTC or other market mechanisms. However, the other approaches may not have

properties such as core-selection.

7 Carbon Neutrality

There remains a fundamental issue: what about the carbon emissions caused by running the hard-

ware? Also, who would buy this cryptocurrency, and thus pay for these computations?

There are a number of ways that this cryptocurrency could be made carbon-neutral. First,

renewable energy sources create excess energy on the grid during peak sunlight and wind hours,

which do not coincide with peak energy usage hours, meaning that the excess energy must be stored

for later use – this is the most critical issue facing renewable energy integration today. Distributed

computing can convert excess electricity into heat, which can be stored in water heaters or household

thermal energy storage systems for later use.

Second, for-proﬁt companies which need distributed computing can buy this cryptocurrency in

order to mediate transactions by paying crunchers for use of their hardware, which would boost the

price and liquidity of the currency (price is aﬀected by mediation [8]). Since some machines may

be used to heat air and/or water for immediate use (not energy storage), if there are no tasks from

companies that are willing to pay, but the heat is still needed, then the machines can fall back on

the volunteer projects.

Relatedly, vast.ai is a platform connecting hosts owning hardware suitable for deep learning

with willing buyers. Until recently, many vast.ai hosts had their machines defaulting to Ethereum

mining when their hardware was not in use for deep learning – this mining can easily be replaced

with BOINC tasks. There are also companies which construct machines speciﬁcally for the recovery

of waste heat from computing, like Qarnot, which oﬀers opportunities for future cooperation.

Additionally, there are a number of BOINC projects dedicated to matters of environmental

concern – the most notable is climateprediction.net, but there have also been projects in the past

that attempted to improve solar panels, and there are many more opportunities in this area.

Finally, crunchers could donate some of their currency – potentially proﬁts, after paying for elec-

tricity – to foundations that protect land from deforestation, or responsible reforestation projects.

Then, those who are looking to oﬀset their carbon emissions can buy the currency from the foun-

dations/projects, granting the latter the ﬁat currency necessary to buy and protect the land. Al-

ternatively, crunchers can invest their proﬁts in other forms of carbon reduction, green energy, or

sustainable and recyclable hardware, which is a relatively new but growing ﬁeld.

8 Current State of Distributed Computing Cryptocurren-

cies

There are a number of cryptocurrencies that reward distributed computing. Curecoin rewards

computations for Folding@home, a distributed computing platform for protein folding. Primecoin

26

is a PoW coin where the PoW computations are searches for prime numbers. Obyte rewards

computations for World Community Grid, a BOINC project, but does not reward other projects.

Gridcoin rewards a subset of BOINC projects suited to its distribution mechanism. Since Gridcoin

is the only cryptocurrency currently rewarding more than one BOINC project, we will use it as an

example of how blockchains and their economics develop.

Gridcoin was started in 2013 as a fork of Blackcoin, which itself was a fork of Peercoin, which

itself was a fork of Bitcoin. It was started as a PoW coin using the scrypt hashing algorithm, with a

layer on top of the PoW protocol that rewarded BOINC contributions. Beginning in 2014-2015, the

coin was forked, the protocol was eventually shifted to PoS, and the GRC in existence at the time

was inﬂated to ∼340 million GRC. The PoS protocol awarded every UTXO that staked a block

with a percent yield based on the age of the UTXO, as well as rewards for that person’s BOINC

contributions. Another fork in 2018 resulted in constant block rewards, rather than a percent return

based on age, with ∼14 million GRC being minted per year – 25% going to the PoS block rewards,

and the remaining 75% going to rewards for BOINC computations. There is strong evidence to

suggest that most of the GRC at the time of the 2014-2015 fork remains in the hands of those who

were present before the fork.

As of this writing, there is a total of ∼455 million GRC in existence; of that, there is ∼30 million

GRC in the Foundation wallet. The Foundation wallet is a multi-signature wallet entrusted to

long-standing members of the community and is intended to be used for enhancement or promotion

of Gridcoin. It is still almost entirely derived from the initial fork, since developers have been

reluctant to accept payment for their contributions. Many Gridcoin crunchers still send donations

to the Foundation, despite the current rate of minting being small relative to the initial ∼340 million

GRC after the initial fork.

While Gridcoin experienced a rapid rate of growth during the 2017 cryptocurrency boom, it

plummeted in activity and price during the subsequent decline. It has experienced a not-nearly-as-

large amount of growth in price and users since the 2020 cryptocurrency boom, despite the absolute

size of the 2020 boom far eclipsing the size of the 2017 boom. Correspondingly, Gridcoin also has

mostly empty blocks and a very low velocity of money. However, it has one of the highest rates

of development in the entire cryptocurrency industry, and many non-core developers regularly add

new uses or external features to the blockchain, indicating the viability of such cryptocurrency

communities.

9 Conclusion

Unfortunately, BOINC has stalled in growth. As Anderson noted in [3],

The original BOINC participation model was intended to produce a dynamic and grow-

ing ecosystem of projects and volunteers. This has not happened: the set of projects has

been mostly static, and the volunteer population has gradually declined. The reasons

are likely inherent in the model. Creating a BOINC project is risky: it’s a signiﬁcant

investment, with no guarantee of any volunteers, and hence of any computing power.

Publicizing VC [Volunteer Computing] in general is diﬃcult because each project is a

separate brand, presenting a diluted and confusing image to the public. Volunteers tend

to stick with the same projects, so it’s diﬃcult for new projects to get volunteers.

At the same time that BOINC has stalled, cryptocurrencies have exploded in popularity, with

the computational power and resources devoted to the latter far outstripping the former. The stall

27

in growth has come despite a massive increase in the amount and availability of computing power

among consumers. There is a good opportunity to direct this ever-increasing amount of computa-

tional power towards more useful work; cryptocurrencies and BOINC can play a big role in this. As

for the problems just quoted, a minor modiﬁcation to the reward mechanism could create a ﬂoor of

computational power for each application/project, guaranteeing that if it receives below a certain

amount of normalized WU contributions, then crunchers of that application/project are rewarded

more, thus incentivizing crunchers to crunch them. Ideally, this would create a situation where no

application/project falls below that minimum. Likewise, it is possible to create a cap on the amount

of total rewards for all crunchers that can be awarded for crunching a particular application/project;

this upper bound would incentivize crunchers to crunch less popular applications/projects in case

a particular application/project became extremely popular.

10 Acknoledgements

The author would like to thank James C. Owens, Cy Rossignol, Itai Feigenbaum, and Vitalii

Koshura for useful comments and discussions.

References

[1] A new system for runtime estimation and credit.url:https://boinc.berkeley.edu/trac/

wiki/CreditNew.

[2] Adaptive replication.url:https://boinc.berkeley.edu/trac/wiki/AdaptiveReplication.

[3] D. P. Anderson. “BOINC: A Platform for Volunteer Computing”. In: J Grid Computing

(2020), pp. 99–122.

[4] M. S. K. Awan and S. A. Jarvis. “MalikCredit - A New Credit Unit for P2P Computing”. In:

2012 IEEE 14th International Conference on High Performance Computing and Communica-

tion & 2012 IEEE 9th International Conference on Embedded Software and Systems (2012),

pp. 1060–1065.

[5] H. Aziz. “Generalizing Top Trading Cycles for Housing Markets with Fractional Endow-

ments”. In: arXiv preprint arXiv:1509.03915 (2015).

[6] X. Chen, C. Papadimitriou, and T. Roughgarden. “An Axiomatic Approach to Block Re-

wards”. In: Proceedings of the 1st ACM Conference on Advances in Financial Technologies.

2019, pp. 124–131.

[7] E. Fujita et al. “A Complexity Approach for Core-Selecting Exchange under Conditionally

Lexicographic Preferences”. In: Journal of Artiﬁcial Intelligence Research (2018).

[8] A. Narayanan et al. Bitcoin and Cryptocurrency Technologies. 2016.

[9] A. M. Al-Qawasmeh, A. A. Maciejewski, and H. J. Siegel. “Characterizing Heterogeneous

Computing Environments using Singular Value Decomposition”. In: 2010 IEEE International

Symposium on Parallel & Distributed Processing, Workshops and Phd Forum (IPDPSW).

IEEE. 2010, pp. 1–9.

[10] A. M. Al-Qawasmeh et al. “Characterizing Task-Machine Aﬃnity in Heterogeneous Com-

puting Environments”. In: 2011 IEEE International Symposium on Parallel and Distributed

Processing Workshops and Phd Forum. IEEE. 2011, pp. 34–44.

28

[11] T. S¨onmez. “Strategy-Proofness and Essentially Single-Valued Cores”. In: Econometrica 67.3

(1999), pp. 677–689.

[12] J. Yu and J. Zhang. “Eﬃcient and fair trading algorithms in market design environments”.

In: arXiv preprint arXiv:2005.06878v3 (2021).

29

A RAC Code

This code, which can also be found here, has been slightly modiﬁed from the original code, which

can be found here.

#include <iostream>

#include <math.h>

#define SECONDS_PER_DAY 86400

using namespace std;

void update_average (

double work_start_time, // when new work was started // (or zero if no new work)

double work, // amount of new work

double half_life,

double& avg, // average work per day (in and out)

double& avg_time, // when average was last computed

double& fakeTime // new, for simulations

) {

//double now = dtime();

double now = fakeTime;

if (avg_time) {

double diff, diff_days, weight;

diff = now - avg_time;

if (diff<0) diff=0;

diff_days = diff/SECONDS_PER_DAY;

weight = exp(-diff*M_LN2/half_life);

avg *= weight;

if ((1.0-weight) > 1.e-6) {

avg += (1-weight)*(work/diff_days);

}

else {

avg += M_LN2*work*SECONDS_PER_DAY/half_life;

}

}

else if (work) {

// If first time, average is just work/duration

//

cout << "avg_time = " << avg_time << "\n";

cout << "now = " << now << "\n";

double dd = (now - work_start_time)/SECONDS_PER_DAY;

30

avg = work/dd;

}

avg_time = now;

}

int main() {

double RAC = 0;

double timeOne = 1;

double timeTwo = 1;

double totalCredit = 0;

double timeInterval = 3600; // new; time in seconds between each RAC update

double work_start_time = 0; // when new work was started // (or zero if no new work)

double work = 200; // amount of new work

double half_life = 604800;

double& avg = RAC; // average work per day (in and out)

double& avg_time = timeOne; // when average was last computed

double& fakeTime = timeTwo; // new; for simulation

for (int i=0; i<1500; i++) {

if (1) {

if (i % 24 == 0) {

cout<<"week " << i/168 + 1 << ", day " << (i/24)%7 + 1 << ";

current hour = " << i << "; ";

cout<<"totalCredit = " << totalCredit << "; ";

cout<<"RAC = "<< RAC << "\n";

}

}

fakeTime += timeInterval;

update_average(work_start_time, work, half_life, avg, avg_time, fakeTime);

totalCredit += work;

}

cout<<"Final totalCredit = " << totalCredit << "\n";

cout<<"Final fakeTime = " << fakeTime << "\n";

cout<<"Final RAC = "<< RAC;

return 0;

}

B ER Approximation

The code for the ER approximation can be found here.

As described in Section 1.1, the computational contribution of all of the machines under a

31

cruncher’s CPID to a project is grouped into a single measurement called RAC, which is the

only statistic currently provided to the public by projects. Increasingly granular disaggregation

of the RAC yields an increasingly accurate estimate of the ER. There are three main levels of

disaggregation:

1) Machine-level disaggregation. A single CPID can contain many machines, and those that do

can be massive outliers in the data and completely distort the regression, to the extent that bρmight

not even intersect the axes on their positive rays.

2) Application-level disaggregation. Most projects have multiple applications, each of which has

diﬀerent computational requirements. Projects can normalize their credits across their respective

applications – however, even a single project not normalizing their credits across their applications

would prevent an accurate estimate of ρ. Furthermore, even if every single project normalized their

credits across their applications, the current credit computations are still ﬂawed, which is one of the

motivations for basing the ER on WUs completed, rather than credits. Additionally, normalizing

based on all of the machines on the network provides a much larger sample size than normalization

based on a small subset of hardware to which projects have access.

3) WU-level disaggregation. A number of revisions to BOINC’s credit-granting mechanism have

been explored, see [1] for an example. However, the diﬃculty involved in taking into account all

the factors about the machines means that there have been no comprehensive solutions for this

problem yet. As explained in Section 1.1 and the preceding paragraph, this is why WU-level data

is preferred.

C Game-Theoretic Simulations

The code for the game simulations can be found here.

Figure 5: Game that converges

32

Figure 6: Game that diverges

Figure 7: Game that cycles

33