a series of builtsystems that implement the aforementioned
refinements, with the following features:

GPU acceleration

a compiler that allows the developer to
express a computation in a restricted subset of
C; the compiler produces executables that
implement the protocol entities

Verifiable ASICs, a new approach to building trustworthy hardware using untrusted components

Though these systems are not yet at true
practicality, they are arguably practical in some
regimes. More importantly, these systems highlight
the potential applicability of the theory, and indeed, there
is now a thriving research area based on this
promise. Thus, we are hopeful that over the next few
years, the underlying theoretical tools will find
their way into real systems.

Built systems under the Pepper project

In the descriptions below, the prover is the
entity that performs a computation. The
verifier checks a proof (produced by the
prover) that the computation was performed
correctly.

Pepper

Pepper is the first system to challenge the folklore that
PCP-derived machinery is impractical. Pepper implements an efficient argument system based on a
protocol of Ishai et al., CCC 2007, and incorporates new
theoretical work to improve performance by 20 orders of magnitude.
Pepper is implemented and experimentally evaluated, and is arguably
practical for some computations and in some regimes.

Ginger is based on Pepper. It slashes query costs via
further refinements. In addition, Ginger broadens the
computational model to include (primitive) floating-point
fractions, inequality comparisons, logical operations, and
conditional control flow. Ginger also includes a parallel
GPU-based implementation, and a compiler that transforms
computations expressed in a high-level language to
executables that implement the protocol entities.

Zaatar addresses a limitation in Ginger, namely that
avoiding immense work for the prover requires
computation-specific tailoring of the protocols. Zaatar is
built on our observation that the QAPs of Gennaro et al., EUROCRYPT 2013
yield a linear PCP that works with the
Ginger/Pepper/IKO framework and is (relatively) efficient for the prover.
The consequence is a prover whose total work is not much
more than linear in the running time of the computation (and
does not require special-purpose tailoring).

Allspice addresses a key
limitation of prior work for verifying computations: either it
relies on cryptography, which carries an expense (as with Zaatar,
Ginger, Pepper, and IKO), or else it applies to a restricted class
of computations (as with work by Cormode et al., ITCS 2012, which
builds on an interactive proof system of Goldwasser et al., STOC
2008). Allspice optimizes the non-cryptographic
protocols and extends them to a much larger class of computations.
Allspice also uses static analysis to compile an input program to
the best verification machinery for that program.

Pantry extends
verifiable computation to handle stateful computations: those
that work over RAM, or computations for which the verifier does not
have the full input. Pantry composes techniques from untrusted
storage with existing verifiable computation machinery: the
verifier’s explicit input includes a digest of the full input
or state, and the prover is obliged to compute over state that
matches the digest. The result is to extend verifiability to real
applications of cloud computing (MapReduce jobs, queries against
remote databases, applications for which the prover’s state is
hidden, etc.). Besides the gain in expressiveness, Pantry improves
performance: by not handling inputs, the verifier saves CPU and
network costs.

Buffet eliminates what was
a problematic cost-programmability tradeoff in this research area. Prior
to Buffet, there were two approaches to program representation. One
approach, due to Ben-Sasson et al., Usenix
Security 2014, offered excellent programmability (the full C
programming language) but substantial overhead. Another approach
(embodied by Pantry, Pinocchio,
and Zaatar) offered much lower overhead but could not handle
data-dependent control flow. Buffet takes Pantry as a base and applies
static program analysis (including loop flattening) together with an
adaptation of BCTV's elegant
representation of RAM. Buffet can handle essentially any example in
the verifiable computation literature (it supports an expansive subset
of C, disallowing only goto and function pointers) and achieves the
best performance in the area by multiple orders of magnitude.

Zebra instantiates a new model
for building trustworthy chips, called Verifiable ASICs.
This model uses a high-performance chip from an untrusted (and possibly malicious)
hardware vendor to accelerate the computation of a low-performance
chip supplied by a trusted vendor, while retaining the latter's trustworthiness.
To instantiate the model, Zebra builds on the interactive proofs of
GKR,
CMT,
and Allspice.
Zebra demonstrates that, for a class of real computations, the Verifiable ASICs approach
reduces costs and improves performance compared to chips built solely by a trusted
manufacturer.

Giraffe builds on the
Verifiable ASICs model introduced by Zebra.
Giraffe removes Zebra's requirement that a trusted entity supply the verifier with
an endless stream of precomputations.
In doing so, it charges for all protocol costs and makes outsourcing with
probabilistic proofs worthwhile for the first time.

Giraffe includes a new probabilistic proof for data-parallel computations that
refines the protocol of Thaler13
to give asymptotically optimal prover cost; this is of independent interest.
Giraffe also develops a design template that automatically produces optimized
hardware designs for a wide range of computations and circuit technologies.
It combines this template with program analysis and compiler techniques that extend
the Verifiable ASICs model to a wider range of computations.
Compared to Zebra, Giraffe handles computations that are 500× larger, and it can
automatically outsource parts of programs that are not worthwhile to
outsource in full.

Overview: what is Pepper?

Pepper is an academic research project whose goal is to make
verified computation
practical. By verified computation (which is sometimes also called
“verifiable computation”), we mean a system that implements
the following picture:

Introduces the remarkable QAP/QSP encoding, which is borrowed by many of the projects in the area.
Pinocchio and Zaatar
have similar performance
except that Pinocchio has much better amortization behavior.

Introduces an innovative
program representation and combines it with an optimized
implementation of Pinocchio's verification engine.
This approach brings excellent programmability (enabling
support of the full C programming language) and
the best amortization behavior in the literature but
overhead is very high.
Compared to Buffet, for
example,
programmability is slightly better
but performance is orders of magnitude worse.

For a quick performance comparison, based on re-implementations
of many of the systems, see this
presentation (accompanies the Microsoft Faculty Summit video
above). Also, the Buffet
paper contains a careful, apples-to-apples performance comparison
of BCTV and
Pantry
(and by extension, Pinocchio and
Zaatar).

Source code for all of our built systems is available online, under a BSD-style license.
In addition, we provide full re-implementations of
most of the related systems;
this facilitates performance comparisons.

Implemented systems

We maintain a github repository
with our latest released code. For experimenting or building on our work, we suggest
using this release.

We also provide snapshots of our systems at the time of publication, useful
for reproducing our results:

(1) Costs to the verifier. To check that a
remote computation was performed correctly, the
verifier must incur a per-computation setup
cost: this cost (which consists of CPU
and network costs) amortizes over multiple
instances of the same computation (potentially
over all future
instances), on different inputs.
However, the cross-over point, in terms of when
the setup cost is paid for, is quite high:
tens or hundreds of thousands of
instances of the same computation.

This setup cost can be slashed
(as in
Allspice)
or eliminated (as
in CMT).
Unfortunately, these solutions apply
only to restricted classes of
computations.

Using the techniques of BCTV, the setup cost can be reused over all
computations of the same size.
However, the cost of these techniques is very high,
and in practice, one would need to incur the setup
cost thousands of times anyway (as explained in Buffet).

Using other
techniques of BCTV,
the setup cost can be made independent of the computation.
However, these techniques are primarily theory at this
point; for example, the prover's computational costs are many orders of
magnitude higher than the other works in the
area.

(2) Costs to the prover. The CPU costs to the
prover are currently immense: orders of
magnitude (factors between a thousand and a
million) more than simply executing the
computation. An additional bottleneck is memory:
the prover must materialize a transcript
of a computation's execution.

As a consequence of the above costs, all
projects in this area are currently limited to
small-scale computations: programs that take several million
steps, but not more.

Verifying computations without reexecuting them: from theoretical possibility to near practicality
[link]
Michael Walfish and Andrew J. Blumberg
(This survey is written for a
general CS audience and is probably a good first paper to
read for those curious about the area.)
Communications of the ACM (CACM),
Volume 58, Number 2, pages 74–84, February 2015.
Prior versions: November 2013, July 2014.
(ECCCTR13-165).

(Implementations of) verifiable computation and succinct arguments: survey and wishlist
(This talk surveys
the last few years of progress on (implementations of) protocols for verifiable
computation and closely related
problems, such as succinct non-interactive (zero knowledge)
arguments. Watching the talk is likely to be an efficient way to
begin a literature search and to get pointers to research
questions for the area.)
Simons Institute: Securing Computation, June 2015 [pptx (1.1 MB),
video]

Summary of Pepper’s results so far

Our line of work on
Pepper, Ginger, and Zaatar has instantiated an
argument system (an interactive protocol that assumes a
computationally bounded prover) due to Ishai, Kushilevitz, and Ostrovsky (CCC 2007),
in this
paper (also available here).
Through theoretical and practical refinements, we have reduced the
cost of this argument system by a factor of roughly 1020 (seriously).

In another line of work, Allspice, we have built on an interactive proof
system due to Goldwasser, Kalai, and Rothblum (STOC 2008), and
refined and implemented by Cormode, Mitzenmacher, and
Thaler (ITCS 2012). One of the chief advantages of this
line of work is that it avoids expensive cryptographic operations.

One might wonder: which protocol is “best”? Our experience has
been that it depends on the computation. Accordingly, Allspice
includes a compiler that takes as input a high-level programming language and
performs static analysis to compile to the best available
protocol for that computation.

In the above works, the computational model does not support
stateful computations, namely those that work over RAM, or
computations for which the verifier does not have the full input.
In Pantry, we overcome this
limitation, and apply the verification machinery to MapReduce jobs,
queries against remote databases, and applications for which the
prover’s state is private.

Our approach: PCPs, argument systems, and interactive proofs

Our approach is to apply the fascinating theory of
Probabilistically Checkable Proofs (PCPs) and two closely related
constructs: argument systems and interactive proofs.

The theory
surrounding PCPs demonstrates, astonishingly, that it is possible
(in principle) to check a mathematical proof by investigating only a
few bits of that proof. In our context, this implies that the
picture we wanted
has a solution, one that is unconditional and
general-purpose.

The research: make the theory practical

Unfortunately, PCPs, as described in the
theoretical literature, are not remotely practical: in
the most asymptotically “efficient” schemes, the server would take
trillions of years to produce a proof.

Can we incorporate PCPs into a built system? So far, we have been able to come close. Here is a top-level summary of
Pepper’s results to date.