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 nonnegligible 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 yesinstances of a particular graph property and βglueβ them together to form a longer cycle that does not match the relevant graph property. The smaller yesinstances, 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 proververifier 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 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 publiccoin 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 Constantquery
We will demonstrate constantquery 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:
Run linearity check on .

Query .

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

Query and check .
Note that each query is errorcorrected β 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 constantquery protocol for Leader, the honest proof is simply the Hadamard encoding of the input: , where for . The protocol for each is as follows:

Run linearity check on .

Query and check .

If :

Sample which is zero on entry and uniform in elsewhere.

Query and check .
Else:

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
and
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

Check .

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.
References
 [1] GΓΆΓΆs, Mika, and Jukka Suomela. βLocally checkable proofs in distributed computing.β Theory of Computing 12.1 (2016): 133.
 [2] Naor, Moni, Merav Parter, and Eylon Yogev. βThe Power of Distributed Verifiers in Interactive Proofs.β arXiv preprint arXiv:1812.10917 (2018).
 [3] Kol, Gillat, Rotem Oshman, and Raghuvansh R. Saxena. βInteractive distributed proofs.β Proceedings of the 2018 ACM Symposium on Principles of Distributed Computing. ACM, 2018.
Comments
There are no comments yet.