Distributed Verifiers in PCP

05/21/2020 ∙ by Nagaganesh Jaladanki, et al. ∙ 0

Traditional proof systems involve a resource-bounded verifier communicating with a powerful (but untrusted) prover. Distributed verifier proof systems are a new family of proof models that involve a network of verifier nodes communicating with a single independent prover that has access to the complete network structure of the verifiers. The prover is tasked with convincing all verifiers of some global property of the network graph. In addition, each individual verifier may be given some input string they will be required to verify during the course of computation. Verifier nodes are allowed to exchange messaged with nodes a constant distance away, and accept / reject the input after some computation. Because individual nodes are limited to a local view, communication with the prover is potentially necessary to prove global properties about the network graph of nodes, which only the prover has access to. In this system of models, the entire model accepts the input if and only if every individual node has accepted. There are three models in the distributed verifier proof system family: 𝖫𝖢𝖯, 𝖽𝖨𝖯, and our proposed 𝖽𝖯𝖢𝖯, with the fundamental difference between these coming from the type of communication established between the verifiers and the prover. In this paper, we will first go over the past work in the 𝖫𝖢𝖯 and 𝖽𝖨𝖯 space before showing properties and proofs in our 𝖽𝖯𝖢𝖯 system.



There are no comments yet.


page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Preliminaries

For a graph , we denote by and the vertex and edge sets of the graph, respectively. For some vertex , we define the neighborhood of as those vertices in adjacent to , including itself. That is, .

In general, problem instances for each model will take the form of for in some family of graphs and a function from vertices to binary strings. Intuitively, is a “promise” that has some structure, e.g. that it is connected, while is an input string for each verifier node. For a vertex subset , we denote by the restriction of to .

For each proof system we discuss, the distributed verifier consists of for each vertex . Each verifier is local, in that it makes a decision based only on the structure, inputs, and proofs of its neighborhood. That is, each verifier is a function of the format where is, abstractly, an oracle with access to the proofs sent to . The format of these proofs will be specified in more detail for each model we discuss.

We will consider several natural graph properties and languages, which we now define.

Definition 1.1.

A graph is in Nonbiparite if it is not bipartite. That is, there exists no -coloring of .

Definition 1.2.

A graph is in Sym if some nontrivial automorphism exists on , i.e. some nonidentity permutation exists such that is compatible with the structure of , in that .

Definition 1.3.

Leader is the language of graphs with a unique distinguished “leader”. More explicitly, a graph with input strings , with a function , is in Leader if for exactly one vertex , and for all other vertices .

Definition 1.4.

A graph and input is in Span if defines a valid spanning tree on . That is, for each the string identifies either a neighbor of , supposedly its parent in the spanning tree, or with some unique string specifies that is the root of . If the directed graph defined by is indeed a spanning tree on , then .

2 Locally Checkable Proofs

In the Locally Checkable Proofs () model, the prover can only send a single different proof string to each verifier, after which there is no further communication with prover. Once this proof string is received, verifier nodes can communicate with their local neighborhood before accepting or rejecting the input.

Formally, the Prover is a function that associates every vertex to the proof string that that the Prover sends. The verifier is a computable function that has an oracle to the proofs and input strings of its local neighborhood. Note that the model does not allow verifiers to use randomness to accept or reject the Prover’s proof string. As a result, the following definition encapsulates the model.

Definition 2.1.

We say a given graph property admits locally checkable proofs if the two properties hold.

  • If , then there exists a proof such that all verifiers accept.

  • If then any proof will have at least one verifier reject.

Of particular interest in this model is the communication complexity between the prover and each verifier, which allows a complexity hierarchy to be defined within this model.

Definition 2.2.

We define the class to consist of graph properties that admit a locally checkable proof where the communication between each verifier and the prover is up to bits.

This following levels in the complexity hierarchy are of interest: , and , which were first described in a by a 2011 paper by Göös and Suomela [1]. We define as an alias for .

Intuitively, is an interesting complexity class as it allows the prover to send a concise yet non-negligible amount of information to each verifier to prove some global property about the graph.

2.1 lower bounds

An interesting property about the class is the existence of nontrivial lower bounds proved on proof size. Uniquely identifying every node in a graph of vertices takes a lower bound of bits, so one can potentially characterize the class as one that sends the identifiers of a constant number of nodes to each vertex in the proof string.

Several problems in the class, such as Span, Nonbiparite, or Leader, have bits of communication as a lower bound for proof strings.

The proof sketch for this is as follows. We can take several small cycles that form yes-instances of a particular graph property and “glue” them together to form a longer cycle that does not match the relevant graph property. The smaller yes-instances, which each require fewer bits to convey node identifiers and proof labels, still hold true locally when glued together, causing all nodes to accept based off of their local neighborhood. This will lead to an acceptance, even though the glued longer cycle is not part of the language.

3 Distributed Interactive Proofs

The model extends upon the model by introducing the notion of interaction and randomness between each verifier and the prover. Every verifier and the prover are allowed to communicate by exchanging communication in a series of rounds. These rounds of communication may be interspersed by communication with other nodes in the local neighborhood of the verifier. Because of the introduction of randomness, the prover-verifier system is not guaranteed to always produce the right answer such as in the model.

Definition 3.1.

We say a given graph property admits a distributed interactive proof if the two properties hold.

  • If , then there exists a prover

    such that all nodes accept with probability greater than


  • If then for any prover, the probability that all nodes accept is less than .

Ideas from traditional models can be extended to the model as well. In particular, the paper proposing the model worked extensively in the public-coin variant of the model, in which the verifiers share all generated randomness with the prover.[3] A prominent system used was the model. Communication complexity is denoted in this model as , where the number of bits transferred between the prover and verifier is upper bounded by .

Intuitively, randomness and interaction seem to give this model more power, which may allow the net communication complexity to go down. Indeed, this is true, with results showing that . This is direct improvement from the model, which showed that .

3.1 RAM Compiler

The RAM compiler, introduced by Naor, Parter, and Yogev, is a general way of transforming traditional graph protocols with a centralized verifier into those that can be accepted by the network graph of verifiers [2].

At a high level, this reduction involves using the network graph as a RAM machine, with each individual verifier responsible for a small portion of the computation. The computation is checked to be globally correct with a specific reduction to Set Equality, for which a protocol is given in the paper.

4 Distributed PCP

In the distributed model we propose, the prover provides one global proof string which can be queried by each verifier in the graph. Intuitively, this model gains some power from the fact that the prover is forced to commit to a single, shared proof for all verifiers – each verifier can both check that the proof is locally consistent with its neighborhood, and that it honestly encodes some global structure of the graph and vertex inputs. This sort of verifier strategy does not appear in or , as in these classes the prover is free to send inconsistent proofs to different verifiers.

Formally, we define distributed as follows:

Definition 4.1.

Given a family of graphs and graph language , we have if

  • Completeness: For any , there exists a proof with such that

  • Soundness: For any , for any proof , we have .

for some with each verifier using at most random bits and making at most queries to .

4.1 Constant-query

We will demonstrate constant-query protocols for the problems Nonbiparite, Leader, and Span. As seen above, there exist no locally checkable proofs of size for these problems, suggesting that probabilistic checking is more powerful than the fixed proofs of . However, the protocols below require that , where is the family of connected graphs with vertices. This is required only for the verifier to know how to query a Hadamard encoding of an

-dimensional vector, and it is not clear that this is central to the protocol itself.

4.1.1 Nonbipartite

Recall that a graph

is bipartite if and only if it has no cycles with an odd number of vertices. Thus, it suffices to provide a proof that some odd cycle exists in

. Given some odd cycle , consider the vector with , where if and only if . Since we want to verify that is in fact an odd cycle in a constant number of queries, we let the proof be the Hadamard encoding of . Let be the basis vector with value at coordinate and everywhere else, and let be the all ones vector. Each verifier then runs the following protocol:

  1. Run linearity check on .

  2. Query .

  3. If , communicate with neighbors to ensure there exist exactly two distinct such that .

  4. Query and check .

Note that each query is error-corrected — that is, instead of querying e.g. , we instead query for a randomly sampled . For any graph , the prover can find some loop with odd vertices, so completeness holds. Soundness follows from the converse of this, and the fact that the linearity check and each query introduce only a constant probability of error. Therefore, .

4.1.2 Unique Leader

In the constant-query protocol for Leader, the honest proof is simply the Hadamard encoding of the input: , where for . The protocol for each is as follows:

  1. Run linearity check on .

  2. Query and check .

  3. If :

    • Sample which is zero on entry and uniform in elsewhere.

    • Query and check .


    • Query and check .

If the prover attempts to lie about , it will be caught in the second step of the protocol. Otherwise, the third step verifies that there exists a unique such that and . Completeness and soundness follow.

4.1.3 Spanning Tree

Here, an honest prover sends where


where is the directed graph defined on by , where if . The verifier runs the Leader protocol on , then, if is not root, checks using queries

  1. Check .

  2. Check for on element and uniform from elsewhere.

It follows that

5 Conclusions & Future Work

We have introduced the model, which we believe to be an interesting and meaningful notion of distributed proof. Future directions include the relationship between and the or classes — although we presented some protocols for graph languages in and , we have yet to devise any general reductions. It could also be interesting to explore the creation of succinct arguments from using cryptographic methods, which may be useful in practical settings.