A Scalable Verification Solution For Blockchains
A Scalable Verification Solution For Blockchains
A Scalable Verification Solution For Blockchains
Abstract
Bitcoin and Ethereum, whose miners arguably collectively comprise
the most powerful computational resource in the history of mankind,
offer no more power for processing and verifying transactions than a
typical smart phone. The system described herein bypasses this bottle-
neck and brings scalable computation to Ethereum. Our new system
consists of a financial incentive layer atop a dispute resolution layer
where the latter takes form of a versatile “verification game.” In addi-
tion to secure outsourced computation, immediate applications include
decentralized mining pools whose operator is an Ethereum smart con-
tract, a cryptocurrency with scalable transaction throughput, and a
trustless means for transferring currency between disjoint cryptocur-
rency systems.
Contents
1 Securing computations with economics 2
1.1 Outsourced computation . . . . . . . . . . . . . . . . . . . . . 3
1.2 Practical impact . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Smart contracts . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1
3.2 Solution: The verification game . . . . . . . . . . . . . . . . . 12
3.3 Detailed protocol . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4 Runtime and security analysis . . . . . . . . . . . . . . . . . . 16
4 Incentive layer 17
4.1 Jackpots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2 Taxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3 Deposits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.4 Generating forced errors . . . . . . . . . . . . . . . . . . . . . 21
4.5 Solver and Verifier election . . . . . . . . . . . . . . . . . . . 22
4.6 Protocol overview . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.7 Sanity check . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5 Defenses 26
5.1 Pairwise Sybil attacks . . . . . . . . . . . . . . . . . . . . . . 28
5.2 The trifecta . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.3 Collusion pools . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.4 On low-hanging fruit . . . . . . . . . . . . . . . . . . . . . . . 34
5.5 A cash equivalence problem . . . . . . . . . . . . . . . . . . . 35
6 Implementation 36
7 Applications 37
7.1 Practical decentralized pooled mining . . . . . . . . . . . . . 37
7.2 Dogecoin–Ethereum bridge . . . . . . . . . . . . . . . . . . . 38
7.3 Scalable transaction throughput . . . . . . . . . . . . . . . . . 38
7.4 Towards a big data system . . . . . . . . . . . . . . . . . . . . 39
A Addendum 40
A.1 Security patches . . . . . . . . . . . . . . . . . . . . . . . . . 40
A.2 The TrueBit Virtual Machine . . . . . . . . . . . . . . . . . . 43
A.3 Additional applications . . . . . . . . . . . . . . . . . . . . . 44
2
another, while Ethereum transactions perform financial and database oper-
ations contingent on the evaluation of more complex computational scripts.
Anonymous miners, who freely join and leave cryptocurrency networks, de-
termine the validity of these transactions and thereby establish who owns
which coins. Remarkably, this verification scheme requires no central au-
thority to operate securely.
In practice, miners can successfully maintain blockchain integrity so long
as the computational burden of verification remains minimal. Indeed, Bit-
coin and Ethereum, whose miners arguably collectively comprise the most
powerful computational resource in the history of mankind, offer no more
power for processing and verifying transactions than a typical smart phone.
One cannot simply increase the volume or complexity of transactions flow-
ing into the blockchain without risking inclusion of invalid transactions due
to the so-called Verifier’s Dilemma [50] (see Section 3.1). In 2015, the Ver-
ifier’s Dilemma manifested itself in the form of the July 4 Bitcoin fork [35]
which temporarily derailed the entire network. The Ethereum community
also witnessed a related exploit in its 2016 denial-of-service attacks [16].
A consensus computer [50] permits users to outsource computations to
the Ethereum network and receive correct answers in exchange for payment
so long as the effort required to verify solutions does not exceed the threshold
induced by the Verifier’s Dilemma. Thus the trustless consensus computer
offers a small but reliable kernel of semantic truth.
3
contracts. Proper economic incentives, the cornerstone of any cryptocur-
rency, can deter many types of errors from occurring in ways that simple
task repetition cannot. Furthermore, in contrast to a cloud whose configu-
ration details may not be visible to users, any systemic network errors that
might occur on a blockchain-based system like TrueBit would appear in plain
sight to the entire community. Cryptocurrencies indeed provide an excellent
starting point as they already achieve several desirable properties.
4
• Trustless cryptocurrency exchange. Currently users must find trusted
exchange partners to transfer currency (or messages) between block-
chains. TrueBit can facilitates secure transfer, for example, of doge-
coins to the Ethereum blockchain and back (modulo some new opcodes
for dogecoin) [8].
5
rely on the only trusted resource, the limited network of miners, to resolve
it. Dispute resolution occurs as a “verification game” subroutine in TrueBit,
and we will discuss its details in Section 3.
Who initiates a dispute in the case of an incorrect computation, and
how can we ensure that such a dispute will actually occur? One option
is to assume that each party with some stake in the contract brings their
own trusted (although not necessarily mutually trusted) verifier, and flags
for a challenge if needed. This trusted verifier approach suffices for some
applications, but in general parties may need to rely on the results of a
previously executed TrueBit contract ex post facto even if they themselves
did not exist at the time of its creation. Like Ethereum smart contracts,
TrueBit contracts must have universal validity.
Since there exist no trusted parties on Ethereum’s network, by symmetry
we must allow any party to be hired to solve any computational task, and
similarly anyone should be able to challenge a Solver’s outcome of a com-
putational task. The latter requirement ensures that TrueBit operates by
unanimous consensus. Assuming that an honest and motivated Challenger
exists who will challenge any wrong answer given by the Solver, the system’s
incentives for the Solver are straightforward: reward correct solutions. But
how can we make sure that such a motivated Challenger exists?
Idea 3. Offer a bug bounty and provide expectation that bugs will exist.
6
system incentives: the Solver gets paid for submitting an incorrect solu-
tion and penalized for submitting a correct one. We discuss the details of
TrueBit’s forced error protocol in Section 4.
Let us return to our dispute resolution subroutine. At the heart of
TrueBit’s protocol lies an interactive “verification game” which decides whe-
ther or not a contested computational task was performed correctly (see
Section 3). The verification game proceeds through a series of rounds, where
each round recursively checks a smaller and smaller subset of the compu-
tation. A trusted network, in our case the Ethereum platform [11], merely
enforces the rules of the game and therefore does not bear the bulk of the
verification burden. Anyone on the network can generate tasks, compute, or
verify in exchange for rewards. TrueBit does not require “honest” or “altru-
istic” nodes for correct operation but rather runs under the assumption that
each node wishes to maximize its own profit. We shall discuss the details of
TrueBit’s incentives for participation in Section 4.
7
puzzle [65]. The new cryptocurrency Zcash [34] successfully makes use of
verifiable computing machinery, albeit only for a very restricted class of
computation tasks. Below we contrast TrueBit with verifiable computing
and traditional cloud computing.
1. Incentives. Unlike traditional cloud computing, where the user simply
trusts the cloud to provide correct answers, TrueBit provides financial
incentives to ensure correctness.
2. Transparency. The entire inner workings of TrueBit’s interpreter sit on
the blockchain and are open for inspection (see Section 6). Further-
more, the user community can democratically update the interpreter
as needed.
3. Efficiency. Solvers in TrueBit have low computational overhead and
minimal initial setup costs. The verification game (Section 3) does
introduce some extra work, but in practice, due to high penalties for
wrong answers and bogus challenges, we expect participants to appeal
to the verification game only rarely, if at all.
4. Simplicity. TrueBit’s operation is relatively straightforward. Unlike
traditional verifiable computing, TrueBit avoids deep probabilistically
checkable proofs (PCPs), succinct non-interactive arguments of knowl-
edge (SNARKs) [37], and exotic cryptographic assumptions (e.g. those
used in zkSNARKs [38]). The standard cryptography used in TrueBit,
namely hash functions and digital signatures, sits in the underlying
blockchain network and does not surface in the TrueBit protocol itself.
5. Adaptability. TrueBit runs on top of Ethereum’s current protocol with-
out impacting functionality.
6. Keyless entry. Participants do not need to manage cryptographic keys
beyond those used in Ethereum. TrueBit establishes identities through
financial deposits alone, and therefore the system avoids risks from
cryptographic trapdoors.
2.2 Assumptions
Traditional distributed systems models focus on tolerance against arbitrary,
Byzantine errors. In Ethereum and other Nakamoto consensus-based cryp-
tocurrencies, however, we have no reason to expect arbitrary errors—nodes
generally deviate from protocol due to financial incentives. Our system
model makes two basic assumptions about the underlying network.
8
(i) There exists a trusted network (i.e. Ethereum) that correctly performs
very small computation tasks.
(ii) Participants are rational in the sense that they act to maximize their
individual profits. In particular, we expect that CPUs will show up to
do computational tasks if and only if they expect fair compensation
for their work.
The consensus computer [50] shows how one can use the incentives in Ether-
eum to establish assumption (i) above both in theory and in practice. The
task of our new system will be to amplify this small amount of correct com-
putation in order to handle larger tasks using assumption (ii). Even though
solo Ethereum miners rarely earn mining rewards, expected long-term re-
turns suffice to merit their participation in the system (via mining pools).
As we shall discuss in Section 3.1, anonymous parties may not necessarily
perform correct computations when economic incentives, including conser-
vation of CPU cycles, pressure them to do otherwise. This observation
justifies assumption (ii). We emphasize that we do not find the assumption
that there exists a single honest (and non-lazy) participant [46] to be real-
istic. A person who loyally contributes CPU cycles without incentive to do
so most likely does not exist in a large, general purpose, public system.
This paper takes a somewhat simplified view of Nakamoto consensus. In
some cryptocurrencies, such as Bitcoin, miners can selectively censor a class
of transactions by deciding not to include its members in their blocks. In
the case of TrueBit, censorship of challenges (see Section 4) or transactions
in the verification game (Section 3.2) could result in catastrophic, bogus
solutions being accepted on the blockchain. In Ethereum, however, censor-
ing individual transactions is difficult as miners cannot easily see where an
Ethereum transaction might call without executing it. Indeed Ethereum
users can obfuscate the function of their transactions, making it computa-
tionally costly for miners to hand-pick transactions for their blocks. Hence
we shall assume that censorship of individual transactions does not happen.
In Section 5.1, we analyze an attack on TrueBit in which miners withhold
entire blocks and show that it is not profitable.
9
Judges in the verification game (Section 3) always adjudicate correctly,
as do the Referees in the incentive layer (Section 4).
(ii) Attackers are rational. We assume that attackers have limited financial
resources and will not deviate from protocol unless it is profitable for
them to do so.
10
who adjudicate all disputes, and we show how such Judges can correctly
resolve disputes over complex computations.
11
whose verifications require non-trivial computational efforts will fail to ex-
ecute correctly as rational miners, who may choose to deviate from the
suggested protocol, stop donating their limited resources to thankless ver-
ification tasks. In short, Ethereum lacks a scalable verification mechanism
and remains vulnerable to serious attacks [50] when miners have to verify
more than a tiny amount.
TrueBit contracts securely execute computationally-intensive tasks for
use in Ethereum smart contracts. The system’s core consists of a smart
contract interface where a user can request a solution to a computational
task or puzzle, and anyone can solve it in exchange for a reward. Our inter-
active verification game, described below, empowers users to both outsource
arbitrary computations in a decentralized manner and receive back correct
solutions. To achieve this goal, we will not only reduce the redundancy of
verification work but also refine the incentive structure responsible for the
Verifier’s Dilemma.
12
Example (matrix multiplication [46]). We give an illustrative example of
a verification game. Suppose that the given task is to compute the product
of two matrices A and B. The Solver claims that A × B = C. In the first
round, the Challenger must claim an error in one of the entries in C, and
outputs coordinates i, j such that
n
X
ci,j 6= ai,k · bk,j
k=1
The Judges only verify that i, j are coordinates and that dn 6= ci,j and that
d0 = 0. The Challenger loses if this fails to hold. In the second round, the
Solver tries to defend himself by providing a k such that dk 6= dk−1 +ai,k ·bk,j .
If the Judges can verify this claim then the Solver wins the game, and
otherwise the Challenger wins.
13
which acts as a certificate commitment for the leaf values in the following
sense. If one knows only the root of a Merkle tree and wants to confirm
that some data x sits at one of the leaves, the holder of the original data
can provide a path from the root to the leaf containing x together with the
children of each node traversed in the Merkle tree. Such a path is difficult
to fake because one needs to know the child preimages for each hash in the
path, so with high likelihood the data holder will supply a correct path if
and only if x actually sits at the designated leaf.
For clarity, we will present the verification game in the familiar and stan-
dard language of Turing machines, but in actuality TrueBit uses the Google
Lanai architecture to simulate steps in the computation (see Section 6). The
verification game consists of three parties:
• a Solver who has allegedly performed some computational task and
claims some solution,
14
1. The Solver selects c configurations equally spaced apart in time
across the current range of the dispute. In the initial iteration,
for example, the Solver selects configurations across the entire
tableau at the following time steps:
t 2t 3t ct
, , ,..., .
c c c c
He then produces c Merkle trees, each with s leaves, where the
leaves constitute the complete machine state at each of these
times, and broadcasts each of the roots of these Merkle trees to
the blockchain.
2. The Challenger responds with a number i ≤ c, indicating the first
time step in this list that differs from her own, and broadcasts
this number i to the blockchain.
3. The Judges check that the Solver indeed posted c Merkle roots
to the blockchain and that the Challenger’s value i satisfies 1 ≤
i ≤ c. If either of these checks fails, the Solver, or respectively
the Challenger, loses immediately.
4. The next iteration of the game continues similarly, but restricted
to configurations between the i − 1-st and i-th indexed configu-
rations. Here we interpret a 0 as the computation’s initial con-
figuration.
Final stage. After log t/ log c rounds, the loop above converges to the first,
disputed computational step, and the Judges explicitly check this step
of the computation as follows. Suppose that the first disagreement
occurs at time e. The Solver provides paths from the Merkle root for
time e to its leaves containing:
The Solver also provides the analogous paths for time e−1. The Solver
loses the dispute if the Judges find that any of these paths fail to be
valid. Finally, using this information and the original task code (which
existed on the blockchain prior to the verification game), the Judges
check the computational step at time e and rule whether the challenge
was justified.
15
3.4 Runtime and security analysis
We now show that the work done by the Judges is small compared to the
work required to perform the task, and that the number of interaction rounds
is modest. Note that the majority of effort from the Judges simply involves
recording data onto the blockchain. The Judges’ work is split over many
transactions and therefore avoids any chance of a Verifier’s Dilemma.
We fix σ as the size of each hash in the Merkle trees, and p as the
space required to store a single machine state for the computation. For
computational tasks that run in time t and space s with c configuration roots
posted per round, the protocol requires log t/ log c rounds of interaction on
the main loop, writes cσ + log c bits to the blockchain during each iteration
of the main loop, and writes 2 · ((2σ + 1) log s + 5 + p) bits in the final round
(assuming that tape squares can contain either 0, 1, or be blank, so we need
3 · log 3/ log 2 ≈ 5 bits to describe 3 of them). Summing these parts, the
total time required for community-wide verification from the Judges is then
log t
O · (cσ + log c) + 2 · ((2σ + 1) log s + 5 + p)
log c
16
σ, the chance that such collisions occurs by accident even becomes likely for
sufficiently enormous tasks.
One could entirely eliminate the security risk discussed in the previous
paragraph by posting complete machine states on the blockchain rather than
just Merkle roots, but this makes the protocol more expensive. Alternatively,
one could either increase the parameter σ or the number of states checked
by the Judges in the final step. In this sense, the choice of σ bounds the
maximum complexity of secure computations in TrueBit. We will also see in
Section 4.1 that the capital held by the TrueBit contract as a “jackpot” for
finding a forced error poses an additional constraint on computational ca-
pacity, but this value can scale as well. Finally, the effectiveness of TrueBit’s
verification game may degrade for extremely complex tasks due to the com-
putational limitations of the Challenger. If the expected execution time
of a verification game exceeds a human life expectancy, for example, then
potential Challengers may lack motivation to participate despite financial
incentives. Note that even when a task itself is feasible, its correspond-
ing verification game may not be as the verification game carries significant
overhead. We anticipate that future versions of TrueBit may optimize the
verification game for certain kinds of tasks so as to reduce this discrepancy
(see Section 7.4).
Remark. The verification game provides a significant privacy-protecting ef-
fect in that only disputed parts of a given computation must touch the public
eye [44].
4 Incentive layer
We now discuss the financial incentives which encourage anonymous par-
ties to both contribute CPU cycles and perform requested computational
tasks correctly. We use the dispute resolution layer from Section 3 as a
subroutine and connect its role to the present construction. A Verifier is a
potential Challenger, that is, someone who checks submitted solutions and
calls for a challenge (see Section 3) if and when she detects an error. By
assumption (ii) in Section 2.2, Verifiers must receive adequate payment for
verification tasks. As argued in the beginning of Section 2, however, Veri-
fiers can only receive rewards when they actually find bugs. It follows that
the reward for discovering errors must encompass amortized payment for all
verification tasks checked, including those in which no bugs were found.
Any Ethereum user who offers a reward through TrueBit for performing
a computational task is called a Task Giver. A party which offers a solu-
17
tion for performing these tasks in exchange for a reward is called a Solver,
and, as indicated in the previous paragraph, Verifiers check that Solvers’
solutions are correct. Solvers and Verifiers will play the roles of “Solvers”
and “Challengers” respectively from the dispute resolution layer (Section 3)
whenever a Verifier initiates a verification game. Referees enforce the rules of
the TrueBit protocol in the incentive layer. While Ethereum miners enforce
protocol rules both through the roles of “Judges” in Section 3 and the role
of “Referees” in the present section, we use distinct labels for them because
the layers and functions differ for these roles. The primary role of Judges
is to interactively resolve a dispute, whereas Referees primarily enforce that
Solvers and Verifiers timely submit appropriate data in the incentive layer.
1. A Task Giver announces a task and offers a reward for its solution.
3. Verifiers check the Solver’s solution. They win a large “jackpot” pay-
out if both:
In the rest of this section, we discuss the security measures in TrueBit which
ensure that participants comply with the skeletal procedure outlined above.
A more complete description of the protocol appears in Section 4.6.
4.1 Jackpots
TrueBit periodically imposes forced errors in which a Solver must offer a
wrong solution to a task (see Section 2). This ensures that Verifiers who
diligently search for errors will eventually find them. Accordingly, Verifiers
18
who correctly report forced errors receive substantial jackpot payouts. By
design, Verifiers cannot predict when forced errors will occur and therefore
have incentive to check all tasks carefully. Forced errors occur only rarely,
and we expect Solvers to make only few, if any, other errors. Rewards for
identifying unforced errors may be modest compared to jackpot payouts,
and we consider any such payments of these type incidental, rather than
fundamental, to TrueBit’s secure incentive structure.
The jackpot payout effectively bounds the complexity of computation
tasks that TrueBit can perform securely. The Verifier must, on average, re-
ceive a payment which fairly compensates her for the task at hand, which
means that the jackpot payout should at least consist of fair compensation
for the current task times the forced error rate. In this way, the jackpot cap
bounds the Verifier’s expected per task compensation which, by assump-
tion (ii) in Section 2.2, restricts Verifiers’ available CPU cycles per task.
We fix a rate for forced errors among tasks. This fraction should not be so
low so as to discourage Verifier participation through excessively infrequent
rewards, but neither should it be so high so as to run the risk of Referees
bias (see Section 5.1). We set forced errors to occur, on average, once every
thousand tasks.
4.2 Taxes
Given that a jackpot repository must exist, we now describe the mechanism
for funding it. We assume that a generous philanthropist deposits some
initial funds into the repository, but thereafter TrueBit will be self-sustaining
through taxes. Any Task Giver that calls a TrueBit contract must pay not
only the cost of computational work done by the Solver but also for the work
done by the Verifier(s) (excluding unforced errors and bogus challenges), as
well as the work done by Referees and Judges. We refer to the latter two
costs as the verification tax. We ensure that the jackpot repository never
disappears entirely by placing a cap on the jackpot size. To this end, we set
the maximum jackpot payout for a forced error to be one third of the total
repository size.
While a single, attentive Verifier suffices to ensure correctness and ach-
ieves ideal tax efficiency, in practice the verification tax requires a substantial
cushion. We estimate the necessary verification tax to be 500% – 5000% of
the cost of performing the given task. As we shall see in Section 5.2, there is
a quantitative tradeoff between tax efficiency, Solver deposits, and security
of computations, so Solvers could potentially absorb some of this tax burden
by contributing higher deposits. Our tax rate estimate incorporates Veri-
19
fiers’ incentives for participation and the fact that both the Task Giver and
the Solver for a given task each have incentive to perform verification. Par-
ticipation from these parties may necessitate higher taxes because the total
jackpot payoff decreases exponentially as the number of challenges increases
(see Section 5.3). Expected jackpot payoffs must be sufficiently high to con-
sistently attract at least one Verifier per task. The required tax amounts
may also depend on peculiarities of human behavior. Indeed, we may have
to pay Verifiers more than Solvers per CPU cycle because Verifier rewards
have the human-undesirable property of being sporadic whereas Solvers al-
ways receive immediate rewards. Thus the optimal tax rate must, at least
in part, be determined experimentally.
4.3 Deposits
TrueBit requires deposits from Solvers and Verifiers in order to thwart Sybil
attacks (see Section 5.1) and incentivize correct computations. We set these
deposits to be more than the expected jackpot payout for a given task plus
the cost of playing a verification game. In particular, the deposits must be
large enough to:
1. pay for the (expensive) cost of a verification game, including all re-
wards and penalties for Solver and Challengers and work done by
Judges,
3. discourage Task Givers who collude with Solvers in effort to get bogus
solutions onto the blockchain (see Section 5.2),
4. refund taxes to the Task Giver in case the Solver causes an unforced
error,
20
As an example of the second type, consider a situation where the Solver
deposit is small (say 10 ETH) but the expected jackpot payout per task
is high (say 1000 ETH). An individual playing both the role of the Solver
and Verifier could offer a bogus solution and then challenge his own answer,
hypothetically netting, on average, 1000 − 10 = 990 ETH without providing
any useful service. Such an action would degrade other Verifiers’ incentive
to participate.
As an example of the last case, if the outcome of a time-sensitive TrueBit
contract controlled a 1000 ETH payout but only required a 10 ETH Solver
deposit, then the party who stands to lose 1000 ETH from the TrueBit
contract could attempt to cause a delay by posing as a Solver to the TrueBit
contract and giving a bogus answer. We leave it to the Task Giver to
determine appropriate minimum deposit values for such specific situations,
as such contextual determinations lie outside of the scope of TrueBit itself.
1. The Task Giver does not know the random bits at the time that she
announces a task.
2. The Solver does not know the random bits until after he has committed
his solution.
3. Verifiers do not know the random bits until after they decide whether
to challenge.
The first property makes it difficult for a Task Giver to create a task designed
to swindle the jackpot repository, and the second discourages Solvers from
being lazy and only volunteering to solve tasks which have forced errors. In
order to satisfy these three properties, TrueBit combines random bits from
the following two sources:
(b) the hash of the block mined immediately after the block containing
the Solver’s solution.
21
By hash of the block, or block hash, we more precisely mean the hash of the
block’s header, a roughly 200-byte piece of data that contains the times-
tamp, nonce, previous block hash, and Merkle root hash of the transactions
occurring in the block [32]. Source (b) achieves properties 1. and 2. above,
and source (a) achieves property 3.
TrueBit generates Solvers’ “private” random bits using a method reminis-
cent of RANDAO’s random generator mechanism [25]. Before participating
in a TrueBit contract, a Solver must privately generate a string of random
bits r and publish its hash on the blockchain. This action commits the
Solver to using r in the protocol without revealing the value r to others.
The Solver establishes property 2. above by committing both a hash
of a “correct” solution and a hash of an “incorrect” solution prior to the
broadcast of the block hash from item (b). At the time that this block hash
is revealed, only the Solver, who has access to the value r, knows whether or
not a forced error is in effect. He publicly designates one of his two hashed
solutions for evaluation, however potential Verifiers do not know a prioiri
whether the Solver intended his solution to be “correct” or “incorrect.”
Only after the timeout for challenges has elapsed do the Verifiers witness
the Solver’s private random bits in the clear and learn whether a forced
error was in effect. In case the Solver’s solution is challenged, the Solver
must reveal r as well as his second “correct” solution in order to prove that
the error was forced and avoid a penalty (see Section 5.4). Thus, in the case
of a forced error, the Task Giver still obtains a correct solution. In case of
an unforced error, i.e. when the Solver evidently fails to provide a correct
solution, the Task Giver receives a full refund of her task reward and taxes
(see Section 4.3 and Section 4.6).
Although in theory one could securely run this part of the protocol with-
out hashing the Solver’s solutions, hashing makes it easier for the Solver to
provide a convincing “incorrect” solution which appears, upon casual in-
spection, indistinguishable from a “correct” one. The Solver can effectively
use any randomly selected “incorrect” solution during a forced error because
he never has to reveal its preimage.
22
current block happens to also hold a lottery ticket, he may bias his chances
of winning the lottery. This bias does not affect the security of TrueBit,
however, since the Solver must still provide a correct solution.
In contrast to the Solver selection, TrueBit does not impose a limit on the
number of Verifiers, and we describe in Section 5.3 how multiple Verifiers
who participate in a task must split their rewards after a successful challenge.
Due to the computational work involved in verification, rational Verifiers will
only verify tasks in case they expect to receive adequate compensation for
their work (assumption (ii), Section 2.2). Thus the number of Verifiers
verifying each task will remain low due to the balance between computation
costs and incentives (see Section 5.2 and Section 5.3).
23
(b) the timeOut for accepting bids, performing the computation,
and waiting for a challenge. In the protocol below, we do not
distinguish between these various timeouts with distinct no-
tation, and we colloquially use “timeOut” to refer to both
events and lengths of time. In all cases, timeOut must be
long enough to avoid microforks during which Referees tem-
porarily disagree on current parameters.
(c) a reward for a correct output, which must be at least the
cash equivalent of the task difficulty d based on timeOut
(see Section 5.5), plus a total tax of T · d. The reward is
held in escrow by the TrueBit contract while the taxes are
immediately deposited into the jackpot repository.
(d) the minimum deposit, minDeposit, needed to participate as
a Solver or Verifier (see Section 4.3, Section 5.1, Section 5.2,
and Section 5.3).
2. Solvers who have the requisite minDeposit and random bits can
bid to take on the task until the bidding timeOut. At most one
Solver is selected (Section 4.5), and if no Solver takes on the task
in the allotted time, the task request is canceled and the Task
Giver receives a full refund.
3. The Solver privately computes task. In case of a timeOut, Solver
forfeits his deposit to the jackpot repository and the protocol
terminates.
(a) Solver commits two distinct hashes to the blockchain, thereby
committing both a “correct” and an “incorrect” solution.
(b) The hash of the next mined block is revealed, and then Solver
knows whether or not there is a forced error (see Section 4.4).
(c) Solver designates one of the two hashes as the hash of his
solution.
4. Verifiers who have posted minDeposit can challenge (the hash
of) solution until timeOut. Prior to timeOut, the Verifier must
broadcast the hash of an even integer to the blockchain in order
to commit to a challenge. Hashing an odd number in case of no
challenge is optional and may be used to camouflage real chal-
lenges from other Verifiers (see Section 5.3). After timeOut, the
Verifier broadcasts to the blockchain this hashed number in the
clear to reveal her action.
(a) If no Verifier challenges solution, then
24
i. Solver reveals r to prove that there was no forced error
(i.e. the criteria in Step 4(b)i below fails),
ii. Solver reveals solution in the clear on the blockchain,
iii. Solver receives the task reward, and then
iv. the protocol terminates.
(b) Otherwise, some Verifier challenges solution.
i. Solver reveals his private random string r on the block-
chain, and Referees check it against his commitment from
preprocessing step 3. If the hash of the concatenation of
r and the block hash following the solution announce-
ment from 3(b) is small (as determined by the forced er-
ror rate, see Section 4.1), then a forced error is in effect
(see Section 4.4).
ii. If the value r reveals that Solver’s error was forced, then
Solver must reveal his secondary solution in the clear (see
Section 5.4).
A. If no Verifer challenges Solver’s secondary solution so-
lution before timeOut, then Verifier wins a fraction
the maximum jackpot amount J, scaled for task dif-
ficulty. In case of challenges from multiple Verifiers,
the jackpot is split among them. In more detail, if
there are k distinct challenges, then each participating
Verifier receives J/2k−1 times the ratio of the task’s
difficulty to the system’s maximum task difficulty (See
Sections 4.1, 5.3, and 5.4 for further discussion).
B. Otherwise the Solver must play the verification game
with the challenging Verifier(s). Verifier penalties, Ver-
ifier rewards, Solver penalties, and refunds to the Task
Giver here are the same as described in the next step.
In case the Solver successfully defends himself against
all challenges, however, then the jackpot payouts pro-
ceed as in Step 4(b)i above.
iii. Otherwise the error was not forced. Solver reveals
solution in the clear, and then Solver and Verifier must
play a verification game (Section 3.2). In case of chal-
lenges from multiple Verifiers, the steps below are re-
peated until either some Verifier wins a challenge or Solver
defeats all Verifier challenges. The Solver collects reward
only once he wins all of the challenges, and if this does
25
not happen, then the Task Giver receives a refund on
his reward, and tax payments are reimbursed through
Solver’s deposit as described below.
A. If Solver wins, then Verifier forfeits half of her deposit to
the jackpot repository and the other half to the Solver,
where the latter suffices to compensate the Solver for
playing the verification game (see Section 4.3).
B. Otherwise Verifier wins. Solver pays at most half of his
deposit to the Verifier(s), according to the distribution
scheme in Step 4(b)ii above, pays back the Task Giver’s
taxes out of this amount, and forfeits the remaining
funds to the jackpot repository (see Section 5.1 and
Section 5.2).
End of protocol.
Note that Solver does not receive reward when a forced error occurs in
Step 4(b)ii. In such situations, we expect the Solver to challenge his own
“mistake” and receive a jackpot payout much greater than reward. TrueBit
makes this payout automatic since the Solver would lose the verification
game anyway if he and Verifier were to play it out.
5 Defenses
We now analyze the security of the incentive layer from Section 4. TrueBit’s
security relies on the presence of at least one Verifier to check each task
performed. In this section we show that available incentives suffice to guar-
antee the existence of such Verifier(s) according to the network assumptions
in Section 2.2 and the attacker model from Section 2.3. TrueBit defends
against shortcuts which could divert verification incentives to non-verifying
parties. In particular, we show that TrueBit resists Sybil attacks, collusion
26
parameter dependency
dispute layer parameters - fixed constants.
p, c, and σ (Section 3)
tax rate - fixed constant (500% – 5000%).
(Section 4.2, Section 5.2)
forced error rate - fixed constant (1/1000).
(Section 4.1)
maximum jackpot payout - 1/3 of current jackpot repository.
(Section 4.2)
cash equivalent of CPU cycles - based on external markets.
(Section 5.5)
maximum task difficulty - maximum jackpot payout divided by
(Section 4.1) cash equivalent of a CPU cycle.
task Parameters in this box are chosen by
the Task Giver with minimums as de-
scribed below:
timeouts (Section 4.6) - long enough to avoid microforks.
task difficulty - determined by timeouts.
Solver reward (Section 5.5) - no less than the cash equivalent of the
task difficulty.
expected jackpot payout - cash equivalent of task difficulty, and
(Section 4.1, Section 5.2, number of active Verifier deposits.
Section 5.4)
Solver & Verifier deposits - more than the cost of verification
(Section 4.3, Section 5.1, game plus the expected jackpot pay-
Section 5.2, Section 5.3) out. Also depends on tax rate.
actual number of Verifiers - as many join (incentives limit over-
(Section 4.5) participation).
jackpot payout for challenging - based on maximum jackpot payout,
a forced error (Section 5.3) actual number of verifiers, and ratio of
task difficulty to maximum task diffi-
culty.
Payout for detecting an - at most half of Solver deposit is split
unforced error among all Verifiers (rest goes to jackpot
(Section 5.1, Section 5.2) repository).
27
pools, opportunistic attacks related to jackpot payoffs, and certain external
threats.
Judges and Referees. Recall that Ethereum miners play the roles of
Judges and Referees in TrueBit. Our analyses in Section 3.4 and Section 4.6
show that the work done by these parties is small, and hence they are not
vulnerable to a Verifier’s Dilemma (Section 3.1). Nakamoto consensus [56]
therefore ensures that miners will not post bogus transactions, i.e. enforce
rules incorrectly, lest other miners reject their block and cost them a block
reward. Therefore the only threat from miners is block withholding, specif-
ically with regard to random number generator bias (see Section 4.4).
While in theory miners could discard blocks, along with their mining
reward and associated random bits for TrueBit, in practice this may never
happen. A miner who drops a block must expect in exchange some income
greater than the usual mining reward in order to make this action worth-
while. If such income were to come as a bribe from a TrueBit participant,
it would have to come from a Solver since only the Solver, who has unique
access to his own private random bits, knows how to bias miners’ random
bits towards or away from a forced error. In short, miners cannot disturb
randomness in TrueBit without a tip-off from a Solver. The Solver, however,
has no reason to bias against a forced error because this would prevent him
from challenging his own answer and winning the jackpot, or at the very
least would invite others to share it with him, thereby decreasing the total
jackpot payout (see Section 5.3). Moreover, the Solver is unlikely to suc-
ceed in biasing towards a forced error since miners have little control over
their own block hashes. This “one-sided” effect of block withholding, which
can lock away jackpot funds but (almost) never release them, makes block
28
hashes a safe source of randomness in TrueBit. Hence the Solver’s potential
reward for challenging his own solution under a forced error is not merely an
artifact of TrueBit’s incentive structure — it guarantees unbiased Referees.
Task Giver and Solver. A Task Giver who also acts as a Solver does
not benefit from solving her own task. One idea for an attack vector would
be to create a task such that the Solver’s private random bits force an error
for the given task. Since the Task Giver cannot predict the random bits
from the block hash at the time the task is created (Section 4.4, part (b)),
the Task Giver cannot create such a task. Moreover, the Task Giver cannot
afford to flood TrueBit with useless tasks and solve them herself in the hopes
of eventually, by chance, encountering a forced error. The Task Giver would
pay more taxes to the jackpot repository than she would expect to win from
the jackpot payout (Section 4.2), even taking into consideration any rewards
she might win by correctly solving her own tasks. Her losses are amplified
through payments to other Solvers, Verifiers, and Judges who choose to
participate in the protocol.
Solver and Verifier. The Solver’s burned deposit always exceeds the Ver-
ifier’s income for successfully challenging an unforced error (see Section 4.3).
Hence the Solver has no incentive to challenge himself as a Verifier in such
cases. Similarly, a Verifier can only lose her deposit by posing bogus chal-
lenges. In certain situations it is conceivable that a Solver–Verifier pair
could benefit from submitting a false solution and then challenging it due to
temporal constraints external to TrueBit itself (as mentioned in Section 4.3),
and in such cases the Task Giver must determine the necessary deposits to
deter such actions.
In the case of an forced error, we expect the Solver will challenge himself
in order to win the jackpot. Nevertheless, TrueBit’s tax rate (Section 4.2),
and hence its jackpot payout (Section 4.1), suffices to incentivize an inde-
pendent Verifier to also check the solution. As we shall see in Section 5.3,
the Solver lacks incentive to claim the same jackpot more than once, hence
the Solver’s self-verification does not spoil other Verifiers’ motivation to par-
ticipate.
Task Giver and Verifier. A Task giver can certainly verify the solution
she receives. This checking can only improve the reliability of the system!
We cannot, however, assume that the Task Giver will always perform such
checks due to the Task Giver’s possible computational and financial resource
29
constraints or lack of motivation to involve herself in the details of a TrueBit
contract.
30
better algorithms can gain a market advantage in TrueBit. Such a Verifier
can check more solutions per unit time and therefore increase her expected
jackpot rewards per unit time. Verifiers are free to leave the network at
any time, for any reason. If the current number of active Verifiers exceeds
the number supported by the tax rate and task flow, then the probabilis-
tic default strategy tells each Verifier to exit the system with the minimal
probability that one would expect to restore equilibrium if all Verifiers were
following the default strategy.
Verifiers who choose tasks to verify at random according to the default
strategy, as opposed to changing their behavior based on guesses as to who-
solved-what before, can reasonably estimate their compensation for partici-
pation. When a significant number of Verifiers (not necessarily a majority)
follow the default strategy, the adversary wishing to establish a bogus so-
lution can neither predict which tasks will be verified, nor can he influence
which tasks default strategy Verifiers will verify. According to assump-
tion (ii) in Section 2.2, there exists some bound on the adversary’s financial
means. If not, he could simply flood the Verifier pool with deposits and be-
gin verifying, which in turn would incentivize legitimate Verifiers to leave the
system. Therefore the adversary can only post a bogus solution and hope
that, by chance, it gets ignored. In this way, the default Verifier strategy
spoils the scare-off strategy above.
Let us now estimate the chances that the adversary succeeds to post
a bogus solution which all legitimate Verifiers fail to notice. We make the
worst-case assumption that the adversary Solver always gets elected to solve
his own task. Suppose that the tax rate (see Section 4.2) supports at least
6 Verifiers per task, and that the adversary holds at most 1/6 of all Verifier
deposits. Then effectively there are an average of 5 verifiers per task. Sup-
pose n is the average number of simultaneous tasks on the network. Then
the number of Verifiers is approximately 5n, and so the chance that none
of them check a particular solution is the chance that each of them inde-
pendently and randomly choose other tasks, or [(n − 1)/n]5n . Therefore the
probability that the adversary gets caught, regardless of n, is
1 5n
1− 1− > 1 − e−5 > 99%.
n
The leftmost inequality follows from the standard limit definition for the
Calculus constant e. We conclude that the adversary will most likely lose
his Solver deposit by attempting such an attack.
By raising taxes further, we can make such an attack even more costly.
In this sense the tax rate, together with the minimums for Solver deposits,
31
bounds the mandatory “honesty” of the network. If bogus solutions never
occur, then there would be no need for taxes. On the other hand, higher
taxes make it more expensive to cheat. There is a tradeoff between overhead
tax expenses for Task Givers, minimum deposits for Solvers, and security of
computations.
Rich but powerless. First, consider a Cartel of Solvers with limited CPU
bandwidth but deep pockets which volunteers to solve each and every task
that comes along. The Cartel makes no attempt to provide correct solutions
to any of these tasks, but instead intends to absorb lost Solver deposits un-
til a forced error comes along, at which point it splits the jackpot among
its members. By construction (see Section 4.3), Solver deposits exceed the
expected jackpot payout per task. Therefore, in the long run, such a Cartel
strategy loses money. If members of the Cartel instead decide to start pro-
ducing correct solutions, this does not harm security because that’s what
they are supposed to do anyway. We remark that, also by construction
(Section 4.4), a Solver cannot simply decide to accept only tasks which have
32
forced errors because the Solver does not know whether or not a forced error
is in effect until after he has committed his solution to the blockchain.
Similarly, a Cartel which challenges every single task in the hopes of
eventually obtaining a jackpot sustains losses in the long run due to lost
Verifier deposits.
33
reward paid out when there are exactly i challenges. Then we want
k k+1
· Jn+k > · Jn+k+1 ,
n n+1
or
n+1 k
Jn+k+1 < Jn+k · · .
n }
| {z | {z 1}
k +
>1 for all n≥0 ≥1/2 for all k≥1
Easy winners. If the jackpot for all tasks were equal, rational Verifiers
might choose to verify only simple tasks and ignore complex ones. For
this reason, the jackpot for each task scales proportionally with the task’s
complexity (Step 5. in Section 4.6). Scaling ensures that a Verifier’s expected
jackpot payout per CPU cycle remains constant across all tasks, and it
equally incentivizes Verifiers to inspect simple and complex tasks. Solvers
always appear to perform tasks since the minimum task reward suffices to
compensate them for their work (see Section 4.6 and assumption (ii) in
Section 2.2, ).
Multiple solvers. For security reasons, TrueBit explicitly does not allow
Task Givers to hire redundant Solvers for a single task (Main Algorithm,
Step 2., Section 4.6). Suppose that two Solvers provided solutions to a single
task and exactly one of them receives a forced error. Any Observer who
notices a difference in the two solutions on the blockchain could, without
34
verifying anything, challenge both solutions. By playing two verifications
and sacrificing one deposit, such an Observer could potentially win a jackpot
at negligible cost, thereby degrading the overall incentives for verification.
35
In the first iteration of TrueBit, we will manually update the internal cash
equivalent of a CPU cycle based on a live feed (e.g. [4, 23, 26]). Ultimately,
however, we would like to input these prices in a decentralized way without
relying on a third-party. Later versions of the protocol may make use of
Augur [2], a decentralized prediction market which ports outside information
sources onto the Ethereum blockchain. As of this writing, Augur is currently
in beta testing. Alternatively, we may build an independent blockchain for
reporting prices whose “transactions” consist of exchange rate updates.
6 Implementation
Formally, TrueBit is a smart contract in Ethereum which uses Ethereum’s ex-
isting smart contract framework to bootstrap the creation of computationally-
intensive TrueBit contracts. Tasks in TrueBit take the form of C, C++, or
Rust code, but the user must pass this code as input to the Google Lanai
architecture [15] (discussed below) prior to submission to TrueBit. This lat-
ter step guarantees consistency of simulated architecture and allows Judges
to adjudicate fairly.
36
7 Applications
TrueBit is more than just an outsourced computation system. It is designed
for use in trustless smart contracts. We present some examples of possible
use cases.
37
which aims to bring smart contract functionality to Zcash in the spirit of the
Dogecoin–Ethereum bridge below, may also benefit from TrueBit’s ability to
check Zcash’s proof-of-work.
38
7.4 Towards a big data system
In order to perform as a truly scalable cloud computer, TrueBit must have
access to a scalable data storage system. Ethereum’s blockchain alone does
not suffice as storing even moderate amounts of data directly on Ethereum’s
blockchain is prohibitively expensive. TrueBit can securely access and use
portions of massive data sets so long as the data is stored somewhere pub-
licly and permanently, for example in Swarm [28] or on another blockchain.
Parties who wish to rely on such data in a TrueBit contract must be sure
that Verifiers have access to the full data set.
To use TrueBit on external data, one need only store a Merkle root of the
massive data set on the blockchain and add non-deterministic steps in the
verification game in which the Solver can “guess” the original data set rep-
resented by the Merkle root. While Solvers and Verifiers must have access
to the full data, Judges and Referees do not. Indeed, if we modify the ver-
ification game so as to permit tasks for nondeterministic Turing machines,
then the Solver can nondeterministically guess the certificate data as a step
in the TrueBit contract. Only in cases of disputes would the Solver have to
reveal external certificate data to the Judges via the blockchain. In some
applications, the Solver might even even be able to reveal to the Judges a
privacy-preserving zkSNARK rather than the data itself. zkSNARKs have
the potential to enable privacy for many different kinds of systems on Ether-
eum [59].
While in theory TrueBit’s scalable protocol can process arbitrarily com-
plex tasks, in practice the verification game is inefficient and therefore secu-
rity of TrueBit computations degrades as tasks reach the level of big data.
For big data applications, TrueBit may not be able to rely on a one-size-fits-
all verification game. Therefore we anticipate optimizing the verification
game for certain classes of tasks. For example, Section 3.2 gives an example
of an efficient, specialized verification game for matrix multiplication. In
future versions of TrueBit, Task Givers might broadcast not only tasks but
also an indication of the corresponding verification game to be played in
case of disputes.
Remark. We conclude with a caveat: TrueBit may expose latent security
vulnerabilities in the underlying Ethereum network as a result of new kinds
of interactions between smart contracts and miners. By allowing smart
contracts to check proof-of-works, for example, TrueBit may facilitate 38.2%
attacks [62].
39
Acknowledgments. We thank Vitalik Buterin and Vlad Zamfir for sug-
gesting the use of forced errors in the TrueBit protocol and Eli Bendersky
for introducing us to Google Lanai. We also thank Loi Luu and Julia Koch
for useful discussions.
A Addendum
In the months following the initial release of this whitepaper, new work and
feedback informed TrueBit’s development roadmap and helped refine the
protocol itself. We discuss a few recent developments.
We investigate three attacks of the first type followed by two of the second.
1. The Solver’s solutions are discarded, and a new Solver lottery takes
place. This re-incentivizes Verifiers to participate in the task while
voiding the Solver’s incentive to reveal private information.
2. Half of the Solver’s deposit gets burned. This makes the above attack
expensive for the Solver.
3. The other half of the Solver’s deposit goes to the party who reported
the Solver’s random bits. This incentivizes Observers to report the
Solver’s prematurely revealed random bits.
40
Incorrect secondary solution (Sina Habibian and Harley Swick [22]).
Suppose that a forced error is in effect and that the Solver submits two
incorrect solutions. When the Solver reveals his “correct” secondary solution
in Step 4(b)ii of the protocol (Section 4.6), Verifiers ignore it because there’s
no chance of a jackpot payout. Indeed, the only “reward” for correctly
challenging this secondary solution is to play a verification game. Hence one
of the Solver’s bogus solutions ends up on the blockchain.
We eliminate the incorrect secondary solution vulnerability as follows.
Denote the Solver’s two solutions by A and B. In the beginning of Step 4,
rather than signaling for a challenge with the hash of an even integer, the
Verifier hashes an integer whose value mod 3 the protocol interprets as
follows:
0 mod 3: challenge solution A,
1 mod 3: challenge solution B,
2 mod 3: challenge both A and B.
The Verifiers indicate their choice without knowing which of the two solu-
tions the Solver puts forth as an answer. The protocol hides this information
from Verifiers via the following process. The Solver commits to either solu-
tion A or solution B by hashing either A or B paired with his private random
bits, where the Solver’s private random bits serve as “noise” which prevent
Verifiers from guessing which option the Solver chose. The Solver has incen-
tive not to share his private random bits due to the “Premature disclosure of
random bits” patch above as well as the fact that the Solver risks reducing
his jackpot share by exposing this private information. Finally, once the
timeout for challenges has passed, the Solver reveals his random bits in the
clear, thereby indicating his commitment to either solution A or solution
B. Challenges and forced errors then proceed as usual. In case the protocol
forces the Solver to reveal his second “correct” solution, Verifiers who earlier
committed to a challenge against this second solution are obligated to play
a verification game. In this way, Verifiers catch errant secondary solutions
just as they catch errant primary ones.
In case a forced error is not in effect, broadcasting a pair of incorrect
solutions poses a cost to the Solver in the form of a lost deposit. Indeed
Verifiers have proper incentives to check the Solver’s primary answer. Since
forced errors occur rarely and unpredictably, the Solver expects to sacrifice
several deposits in order to mount an “incorrect secondary solution” attack.
This loss offsets the Solver’s eventual jackpot gain from challenging his own
forced error solution. We implicitly assume that the chance to win a jackpot
sufficiently motivates a Verifier to challenge whenever a Solver submits a pair
41
of incorrect solutions; any Verifier who challenges both submitted solutions
must play a verification game.
The fix above has a potentially useful side effect of publicly indicating
how many Verifiers are monitoring a given task. Indeed, a Verifier broad-
casts one of the three commitment forms above if and only if she is paying
attention. The option to signal “no challenge” is no longer needed for cam-
ouflage because broadcasting challenges no longer indicates presence of a
forced error. Moreover, if the Solver were to submit two correct solutions,
the smart contract could immediately recognize them as identical and pe-
nalize the Solver accordingly.
An adversary could potentially exploit the monitoring feature in the pre-
vious paragraph by broadcasting multiple challenge commitments from Sybil
identities, thereby reducing the total payout in case of a forced error and
discouraging other rational Verifiers from participating. For this reason, the
protocol must prevent Verifiers from revealing which task they are challeng-
ing until the final phase of the protocol. Since each Verifier performs the
given computational task without distraction from others’ commitments, an
adversary cannot deter Verifier participation via Sybil attack.
42
available for payout after a protocol upgrade. Note that the maximum
jackpot amount does not necessarily pay out at each forced error; the actual
payout depends on the difficulty of the task.
43
become increasingly ready-to-use due to contributions and testing by Apple,
Google, Microsoft, and Mozilla [45]. Several cryptocurrency projects have
begun to develop on WebAssembly, including Dfinity, eWASM, and Parity,
due to the platform’s machine independence and relative simplicity.
The TVM consists of two parts:
2. an on-chain stepper which, given a state, can compute the next state.
44
Data marketplace. Hedge fund Numerai [19] crowdsources modeling
problems to data scientists and then executes trades based upon their work.
Numerai rewards successful models, however contributing data scientists
must trust Numerai to both test their work and compensate them fairly.
TrueBit enables autonomous data markets. Open Mined [21], paired with
TrueBit, opens the possibility of trustless renumeration based on stream-
ing flows of models and data. The Ocean Protocol [20], which facilitates
contribution and sharing of data, also requires a verification mechanism.
Staking and random numbers. 1protocol [1] allows users who have ei-
ther computing resources or capital, but not necessarily both, to participate
as TrueBit Solvers and Verifiers by decoupling security deposits from work
done. In addition, 1protocol’s Arbit protocol uses interactive verification to
generate random numbers in a decentralized way.
Other applications. Please check the TrueBit website for other current
ideas in progress! https://truebit.io.
References
[1] 1protocol. http://1protocol.com.
45
[9] Dwarfpool is now 50.5%. http://forum.ethereum.org/discussion/
5244/dwarfpool-is-now-50-5.
46
[28] Swarm. http://swarm-gateways.net/.
[29] The DAO. http://daohub.org/.
[30] Warning: Ghash.io is nearing 51% – leave
the pool. http://www.cryptocoinsnews.com/
warning-ghash-io-nearing-51-leave-pool/.
[31] WebAssembly. http://webassembly.org/.
[32] White paper. https://github.com/ethereum/wiki/wiki/
White-Paper.
[33] Why Equihash? https://z.cash/blog/why-equihash.html.
[34] Zcash. https://z.cash/.
[35] Some miners generating invalid blocks. https://bitcoin.org/en/
alert/2015-07-04-spv-mining, July 2015.
[36] Ittai Abraham, Dahlia Malkhi, Kartik Nayak, Ling Ren, and Alexander
Spiegelman. Solidus: An incentive-compatible cryptocurrency based on
permissionless Byzantine consensus. https://arxiv.org/abs/1612.
02916, 2016.
[37] Eli Ben-Sasson, Alessandro Chiesa, Daniel Genkin, Eran Tromer, and
Madars Virza. SNARKs for C: Verifying program executions succinctly
and in zero knowledge. In Ran Canetti and Juan A. Garay, editors,
Advances in Cryptology – CRYPTO 2013: 33rd Annual Cryptology
Conference, Santa Barbara, CA, USA, August 18-22, 2013. Proceed-
ings, Part II, pages 90–108, Berlin, Heidelberg, 2013. Springer Berlin
Heidelberg.
[38] Nir Bitansky, Ran Canetti, Omer Paneth, and Alon Rosen. Indistin-
guishability obfuscation vs. auxiliary-input extractable functions: One
must fall. https://eprint.iacr.org/2013/468.pdf.
[39] Ran Canetti, Ben Riva, and Guy N. Rothblum. Practical delegation of
computation using multiple servers. In Proceedings of the 18th ACM
Conference on Computer and Communications Security, CCS ’11, pages
445–454, New York, NY, USA, 2011. ACM.
[40] Ran Canetti, Ben Riva, and Guy N. Rothblum. Refereed delegation of
computation. Information and Computation, 226:16 – 36, 2013. Special
Issue: Information Security as a Resource.
47
[41] Kyle Croman, Christian Decker, Ittay Eyal, Adem Efe Gencer, Ari
Juels, Ahmed Kosba, Andrew Miller, Prateek Saxena, Elaine Shi, Emin
Gün Sirer, Dawn Song, and Roger Wattenhofer. On scaling decen-
tralized blockchains (a position paper). In Financial Cryptography
and Data Security 2016 BITCOIN Workshop, volume 9604 of Lecture
Notes in Computer Science, pages 106–125. Springer Berlin Heidelberg,
February 2016.
[42] Christian Decker, Jochen Seidel, and Roger Wattenhofer. Bitcoin meets
strong consistency. In Proceedings of the 17th International Conference
on Distributed Computing and Networking, ICDCN ’16, pages 13:1–
13:10, New York, NY, USA, 2016. ACM.
[43] Ittay Eyal, Adem Efe Gencer, Emin Gun Sirer, and Robbert Van Re-
nesse. Bitcoin-NG: A scalable blockchain protocol. In 13th USENIX
Symposium on Networked Systems Design and Implementation (NSDI
16), pages 45–59, Santa Clara, CA, March 2016. USENIX Association.
[44] Tim Goddard. AdversariallyVerifiableMachine. https:
//www.reddit.com/r/ethereum/comments/51qjz6/interactive_
verification_of_c_programs/d7ey41n/.
[45] Andreas Haas, Andreas Rossberg, Derek L. Schuff, Ben L. Titzer,
Michael Holman, Dan Gohman, Luke Wagner, Alon Zakai, and
JF Bastien. Bringing the web up to speed with WebAssembly. In
Proceedings of the 38th ACM SIGPLAN Conference on Programming
Language Design and Implementation, PLDI 2017, pages 185–200, New
York, NY, USA, 2017. ACM.
[46] Sanjay Jain, Prateek Saxena, Frank Stephan, and Jason Teutsch. How
to verify computation with a rational network. https://arxiv.org/
abs/1606.05917, June 2016.
[47] Eleftherios Kokoris Kogias, Philipp Jovanovic, Nicolas Gailly, Ismail
Khoffi, Linus Gasser, and Bryan Ford. Enhancing Bitcoin security and
performance with strong consistency via collective signing. In 25th
USENIX Security Symposium (USENIX Security 16), pages 279–296,
Austin, TX, 2016. USENIX Association.
[48] Joshua A. Kroll, Ian C. Davey, and Edward W. Felten. The
economics of Bitcoin mining, or Bitcoin in the presence of adver-
saries. http://www.econinfosec.org/archive/weis2013/papers/
KrollDaveyFeltenWEIS2013.pdf, June 2013.
48
[49] Loi Luu, Viswesh Narayanan, Chaodong Zheng, Kunal Baweja, Seth
Gilbert, and Prateek Saxena. A secure sharding protocol for open
blockchains. In Proceedings of the 2016 ACM SIGSAC Conference on
Computer and Communications Security, CCS ’16, pages 17–30, New
York, NY, USA, 2016. ACM.
[50] Loi Luu, Jason Teutsch, Raghav Kulkarni, and Prateek Saxena. Demys-
tifying incentives in the consensus computer. In Proceedings of the 22nd
ACM SIGSAC Conference on Computer and Communications Security
(CCS 2015), pages 706–719, New York, NY, USA, 2015. ACM.
[51] Loi Luu, Yaron Welner, Jason Teutsch, and Prateek Saxena. Smart-
Pool: Practical decentralized pooled mining. http://smartpool.io/
docs/smartpool.pdf.
[53] Silvio Micali. ALGORAND: the efficient and democratic ledger. http:
//arxiv.org/abs/1607.01341, 2016.
[54] Andrew Miller, Ahmed Kosba, Jonathan Katz, and Elaine Shi. Nonout-
sourceable scratch-off puzzles to discourage Bitcoin mining coalitions.
In Proceedings of the 22Nd ACM SIGSAC Conference on Computer
and Communications Security, CCS ’15, pages 680–691, New York,
NY, USA, 2015. ACM.
[55] Andrew Miller, Yu Xia, Kyle Croman, Elaine Shi, and Dawn Song.
The honey badger of BFT protocols. In Proceedings of the 2016 ACM
SIGSAC Conference on Computer and Communications Security, CCS
’16, pages 31–42, New York, NY, USA, 2016. ACM.
[57] Rafael Pass and Elaine Shi. Hybrid consensus: Efficient consensus in
the permissionless model. https://eprint.iacr.org/2016/917.pdf,
2016.
49
[59] Christian Reitwiessner. zkSNARKs in a nutshell. https://blog.
ethereum.org/2016/12/05/zksnarks-in-a-nutshell/, Dececmber
2016.
[62] Jason Teutsch, Sanjay Jain, and Prateek Saxena. When cryptocur-
rencies mine their own business. In Financial Cryptography and Data
Security: 20th International Conference (FC 2016) Christ Church, Bar-
bados, pages 499–514. Springer Berlin / Heidelberg, 2017.
[63] Jelle van den Hooff, M. Frans Kaashoek, and Nickolai Zeldovich. Ver-
sum: Verifiable computations over large public logs. In Proceedings of
the 2014 ACM SIGSAC Conference on Computer and Communications
Security, CCS ’14, pages 1304–1316, New York, NY, USA, 2014. ACM.
[64] Yaron Velner, Jason Teutsch, and Loi Luu. Smart contracts make Bit-
coin mining pools vulnerable. To appear in 4th Workshop on Bitcoin
and Blockchain Research (BITCOIN 2017).
50