Proofs of Proofs of Work with Sublinear Complexity

Abstract

In the setting of blockchain based transaction ledgers we study the problem of “simplified payment verification” (SPV) which refers to the setting of a transaction verifier that wishes to examine the last k blocks of the blockchain (e.g., for the purpose of verification of a certain transaction) using as only advice the genesis block (or some “checkpoint” block that is known to it).

The straightforward solution to this task requires the delivery of the blockchain, the verification of the proof of work it contains, and subsequently the examination of the last k blocks. It follows that the communication required to complete this task is linear in the length of the chain.

At first thought the above seems the best one can hope: a sublinear in the length of the chain solution to the problem will be susceptible to an attacker that, using precomputation, can fool the verifier.

Contrary to this intuition, we show that with a suitable modification to the current Bitcoin blockchain protocol (that incurs a single hash expansion in each block and gives rise to the notion of an interconnected blockchain) we can produce proofs of proof of work with sublinear complexity in the length of the chain hence enabling SPV to be performed much more efficiently.

This research was supported by ERC project CODAMODA, # 259152.

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

Bitcoin, introduced by Nakamoto [10], and other numerous decentralized cryptocurrencies that were developed using the same codebase, have at their core a blockchain-based ledger of transactions. In these systems the ledger is a distributed data structure where transactions are organized into blocks. The blocks themselves form a hash chain so that each block is associated with a proof of work puzzle [1, 4, 7, 11] and it points to a single previous block. A valid blockchain is rooted at a genesis block that is hard-coded into the client software that supports the distributed ledger.

The blockchain is maintained by a dynamically changing set of players that are called miners. The main task of each miner is to solve a proof of work and thus produce the next block. A transaction is validated when it is added to the blockchain. The certainty placed upon a certain transaction is associated to the depth that is found in the blockchain. The deeper a transaction is placed in the blockchain the more certain it becomes that it will remain there. This was originally argued in [10] in a simplified model where the honest players are assumed to act in unison and the adversary follows a specific strategy. Security in the setting where the honest players are distributed and the adversary may exploit this was subsequently formally considered and proven in [6]. In this latter work two properties are introduced: common prefix and chain quality, and it is shown that with overwhelming probability in a parameter k, honest players will agree on the same prefix of the blockchain (after k blocks are pruned) and such chain will contain a certain percentage of blocks produced by honest players. These two properties were shown to imply that transactions in the ledger are “persistent” and that the ledger itself has “liveness” i.e., it is impossible for the adversary to stifle new transactions indefinitely.

In this work we study the problem of simplified payment verification or SPV. Introduced in [10], this problem considers a verifier that wishes to examine the ledger for a recent transaction. The verifier has as input a transaction identifier, say tx as well as the genesis block.¹ The verifier, with only this information, wishes to verify with high probability that the transaction has been included in the ledger and be sure that it will remain there with high probability. Based on the results stated above it is simple to implement such SPV verification as follows: the verifier will query the network and receive various blockchains (possibly some generated by an adversary that wishes to fool him) containing only the block headers for most blocks except the last k ones that are provided with all transactions (such communications have been referred as “SPV proofs”); the verifier will verify the integrity of the received chains and will select the one with the most proof of work. Finally, if the transaction with identifier tx is found at a depth say k it will conclude that the transaction is valid (with a probability of error as detailed by the persistence property of [6]). This SPV operation is more efficient than running a “full node” since not all transaction history needs to be received and verified.

An important observation regarding the above solution is that it is seemingly impossible to improve to below linear complexity in the length of the blockchain. Indeed, if a verifier is only allowed sublinear complexity it will not be able to verify that all the proofs of work in the received blockchains are valid. In this way it will only be able to verify fragments of given blockchains at best and this may open the door to potential attacks by an adversary that prepares ahead of time suitable blockchain fragments that are unrelated to the genesis block but are otherwise seemingly valid portions of the main blockchain.

Our Results. In this work, we present a method to construct proofs of proof of work that have sublinear complexity in the blockchain length. These proofs are capable of enabling “lite” SPV verification that is substantially more efficient compared to the full SPV verification described above. Our solution requires a modification in the current Bitcoin codebase that incurs a small overhead per each block that never exceeds a logarithmic function in the length of the blockchain and can be compressed to a single hash value; this gives rise to a special type of blockchain that we call an interconnected blockchain.

In our solution the lite verifier receives a pair ($\mathcal {X}$, $\pi$), where $\mathcal {X}$ is a blockchain fragment corresponding to the rightmost k blocks of the senders’ chain and $\pi$ is a proof of the proof of work that the pruned chain (denoted by $\mathcal {C}^{\lceil k}$) represents. Constructing the proof $\pi$ is achieved via the following mechanism.

Recall that each block in a blockchain is associated with a proof of work which corresponds to a suitably formed value w that satisfies the inequality $H(w) <T$ where H is a hash function (e.g., SHA-256 in the case of Bitcoin) and T is a target value which is determined via a target calculation function (this function takes into account the rate of growth of the blockchain and reflects the size of the set of miners that participate in the protocol).

Our new mechanism operates as follows: whenever a block with a lower than usual hash is created we mark this in the next block as a continuation of a “deeper” chain that we call the inner chain of depth i where i is the greatest integer for which it holds $H(w)<T/2^i$. Specifically, each block carries a vector of pointers (which can be thought of expanding the standard reverse pointing link in a blockchain across multiple levels). In this way, in our modified blockchain, a block will have a vector of pointers denoted as $\mathrm {interlink}= \langle s_0,\ldots , s_l \rangle$ such that $s_0$ points to the genesis block and for $i=1,\ldots ,l$, $s_i$ points to the previous block with hash value smaller than $T/2^{i}$. Note that l would be the largest integer for which a hash in the blockchain is less than $T/2^l$ (and $s_l$ is a pointer to the most recent such hash).

The construction of the proof $\pi$ is as follows: the sender will remove the k-suffix from its local chain $\mathcal {C}$ and denote it as $\mathcal {X}$. Then, in the remaining prefix denoted as $\mathcal {C}^{\lceil k}$, he will attempt to find the deepest inner chain $\pi$ that is of length at least m (the value m is a security parameter). The pair $(\mathcal {X}, \pi )$ will be the proof and will be transmitted to the lite verifier. In the optimistic scenario where the adversary does not actively interfere there is no further interaction between the lite verifier and the prover. In the general case, the adversary may invest hashing power in order to produce blocks with very low target, with the only purpose to increase the communication complexity between a lite verifier and a prover. In such case, the lite verifier engages in further interaction with the provers in order to be fully convinced.

Finally, we present a formal treatment of security for lite SPV proofs. Our argument is a simulation-based one. Security for a lite verifier is captured by the following statement: for any adversary that produces an SPV proof directed to a lite verifier there is an adversary producing an SPV proof directed to a regular SPV verifier that produces the same outcome. We establish the above security condition with overwhelming probability in m where m is a parameter of the lite verification protocol.

In our construction the complexity of the lite verifier will be shown to be $O(m\log n)$ in the optimistic case which can be improved in a straightforward manner to be $O(m\log \log n)$ where n is the blockchain length using Merkle trees.

Related Work. The first suggestion we are aware of² regarding the use of low hash values that appear naturally in the blockchain as an indicator of total proof of work was in a post in the Bitcoin forum [9]. A suggestion for a modification of the Bitcoin protocol was made in this post to include in each block a single “back-link” to the most recent block with a hash value less than half that of the previous block. Potential benefits of this modification were discussed including the possibility of using such pointers in SPV proofs.

In a short article posted in the Bitcoin-development list [5] this idea was taken further by suggesting to include a data structure containing various such back-links to previous blocks. An exact form of the data structure was not described and it was suggested that further research would be required to determine the most suitable data structure. A number of use-cases were discussed including the possibility of constructing compact SPV proofs as well as the design of “symmetrical two-way pegging schemes” between Bitcoin and side-chains. This latter concept, formulated in [2], enables the transfer of ledger assets from one main chain (say Bitcoin) to pegged side-chains. It is argued that such side-chains enable experimentation with new features in blockchain design and hence pegging them to, say, the Bitcoin blockchain enables the fluid transition of assets to these alternative blockchains (that potentially offer enhanced functionality or robustness features that are difficult to be assessed ahead of time). The pegging operation itself requires the main blockchain to enable transactions that move assets to special outputs that can only be “unlocked by an SPV proof of possession in the side-chain.” This effectively enables the transfer of assets from the main chain to the side-chain as well as their return to the main chain in case the owner of the assets wishes to do that. Building efficient SPV proofs is an important aspect of this mechanism and a suggestion along the lines of [5] is presented in [2]. The possibility of exploiting the SPV proof mechanism by an adversary is recognized and some countermeasures are briefly discussed however without any formal analysis or the conclusion to an explicit data structure and a proof construction algorithm.

Finally, we note that the Bitcoin modifications related to SPV node verification do not affect the operation of the full nodes of the blockchain protocol and thus are of a different nature to chain selection and reward mechanism modifications such as those suggested in the GHOST rule for blockchain selection [12] or the inclusive blockchain protocols of [8].

2 Preliminaries

We follow the same notation as the Bitcoin backbone protocol, [6]. Below we introduce some basic notation and terminology.

• G(.), H(.) are cryptographic hash functions with output in ${\lbrace 0,1\rbrace }^{\kappa }$.

• A block B has the following form: $B=\langle s,x,ctr\rangle$ where $s\in {\lbrace 0,1\rbrace }^{\kappa }, x\in {\lbrace 0,1\rbrace }^{*}, ctr\in \mathbb {N}$.

• A round is the period during which all the parties in the network are able to synchronize and obtain each other’s messages. The scheduling of messages is controlled by the adversary. Furthermore, in each round, the adversary is able to introduce arbitrary number of messages and deliver them selectively to the parties.

• The rightmost block of the chain $\mathcal {C}$ is the head ($\mathcal {C}$) and $\mathcal {C}^{\lceil k}$ is the chain $\mathcal {C}$ without the rightmost k blocks. If we suppose that head $(\mathcal {C})= \langle s,x,ctr\rangle$ and the previous block is $\langle s',x',ctr'\rangle$ then it holds $s= H(ctr',G(s',x'))$; in general every block has a reference to the previous block and thus all the blocks form a chain.

• The block header can be defined as $\langle ctr, G(s,x) \rangle$.

• A proof of work is finding a value ctr : $0\le ctr < 2^{32}$ so that $H(ctr,G(s,x)) < T$ where $T \in {\lbrace 0,1\rbrace }^{\kappa }$ is the target of the block.

• The value x is the information is stored in the a block. In the case of the Bitcoin protocol this information is a sequence of transactions (organized in the form of a Merkle tree).

3 Interconnected Blockchains

In order to produce a proof of proof of work, the prover with local chain $\mathcal {C}$ will produce the pair $(\mathcal {X}, \pi )$ by setting the $\mathcal {X}$ to be the k-suffix of its local chain $\mathcal {C}$ and computing the proof $\pi$. The proof $\pi$ constitutes a collection of blocks that are part of chain $\mathcal {C}^{\lceil k}$ and are collected in a specific way detailed below.

A proof $\pi$ is associated with an integer $i\in \mathbb {N}$ which is the depth of the proof. The blocks contained in the proof are determined by a special type of chain that we will call $\mathrm {innerchain}_i$.

Definition 1

An $\mathrm {innerchain}_i$ parameterized by an index $i >0$ is a valid chain derived from a chain $\mathcal {C}$ that has the feature that each block $B=\langle s,x,ctr\rangle$ satisfies $H(ctr,G(s,x)) < T/2^i$.

In an $\mathrm {innerchain}_i$ we observe that, intuitively, each block represents as much proof of work as $2^i$ blocks with target T of the parent chain $\mathcal {C}$. As a result, if the proof $\pi$ consists of m blocks, then the $\mathrm {innerchain}_i$ represents proof of work as much as $m\cdot 2^i$ blocks of target T.

In our system, in order to produce the proof, provers should extract $\mathrm {innerchain}_i$ for some $i>0$ from $\mathcal {C}^{\lceil k}$. This means that for every $i\in \mathbb {N}$ all blocks with hash value smaller than $T/2^i$ should form a chain. This leads to the notion of an interconnected blockchain.

Every block with hash value smaller than $T/2^i$ needs a pointer to the previous block with hash value smaller than $T/2^i$. This does not exist in regular blockchains of Bitcoin, so a suitable modification with a sequence of pointers in each block in $\mathcal {C}$ is needed. The addition of this data structure inside each block, that we will call $\mathrm {interlink}[]$ will give rise to an “interconnected blockchain.” A graphical description of an interconnected chain is shown in Fig. 1.

Fig. 1.

A graphical depiction of an interconnected blockchain of 11 blocks that contains an inner chain of depth 1 (comprised of blocks (1, 4, 7, 9)) and an inner chain of depth 2 (comprised of blocks (1, 7). The value of the $\mathrm {interlink}$ vector for each block is also shown.

The $\mathrm {interlink}$ data structure which should be included in each block B is dynamic and we formally define it below. Note that a block will be defined as $B=\langle s,x,ctr, \mathrm {interlink}\rangle$ and the blockheader as $\langle ctr,G(s,x,\mathrm {interlink})\rangle$.

Definition 2

$\mathrm {interlink}$ is a vector, which is included in each block B and for which it holds that, for all $i>0$, $\mathrm {interlink}[i]$ is the hash of the previous block of B in chain $\mathcal {C}$ with hash value smaller than $T/2^i$. $\mathrm {interlink}[0]$ is the hash of the genesis block.

Note that the length of the vector depends on the type of blocks that exist in chain $\mathcal {C}$. Suppose that $B=\langle s,x,ctr, \mathrm {interlink}\rangle$ is the head of the chain and $B'=\langle s',x',ctr', \mathrm {interlink}'\rangle$ is the previous block; then $\mathrm {interlink}$ is equal to $\mathrm {interlink}'$ after being updated with the algorithm we describe next.

3.1 Description of the Interlink-Update Algorithm

The purpose of this algorithm is to determine the operation that is needed in order to properly form an interconnected chain. When mining a new block, we must determine the appropriate set of pointers that will be used. Given the hash of the previous block denoted by s, the algorithm performs the following.

• Finds max i, so that $s= H(ctr',G(s',x',\mathrm {interlink}'))<T/2^i$.

• Extends the size of $\mathrm {interlink}'$ by adding $i-i'$ elements where the value $i'$ equals $sizeof(\mathrm {interlink}')$ (only if $i'<i$).

• Assign $H(ctr',G(s',x',\mathrm {interlink}'))=s$ to $\mathrm {interlink}[1],\ldots ,\mathrm {interlink}[i]$.

4 Proving Proof of Work with Sublinear Complexity

4.1 Description of the Prover

When a prover with a local chain $\mathcal {C}$ receives a request from a lite verifier that asks for the rightmost k blocks, then it constructs a proof $\pi$ of the proof of work in $\mathcal {C}^{\lceil k}$ using the algorithm $\mathsf {ConstructProof}$.

This algorithm’s input is $\mathcal {C}^{\lceil k-1}$ and its output is $\mathrm {innerchain}_i=\pi$, where i is the max i so that there are at least m (security parameter) blocks with hash value smaller than $T/2^i$ in $\mathcal {C}^{\lceil k}$. The algorithm $\mathsf {ConstructProof}$ (which we will describe below) calls the next algorithm, which is $\mathsf {ConstructInChain}$.

This algorithm uses a hash table, which is a data structure that stores (key, value) pairs. In our case, the hash table stores blocks with their hash values.

The algorithm $\mathsf {ConstructInChain}$ has as input a chain $\mathcal {C}$ and an i. Its output is a chain with all the blocks with hash value smaller than $T/2^i$ in $\mathcal {C}^{\lceil 1}$.

4.2 Description of the Lite Verifier

We consider the case when a lite verifier has received $(\mathcal {X}_A,\pi _A)$ and $(\mathcal {X}_B,\pi _B)$ from provers A, B respectively that supposedly hold chains $\mathcal {C}_A$ and $\mathcal {C}_B$. Its purpose is to find which proof represents the chain with the most proof of work.

• Without loss of generality, let $\pi _A = \mathrm {innerchain}_{\mu }$, so its blocks have hash value smaller than $T'=T/2^\mu$ and $\pi _B =\mathrm {innerchain}_{i+\mu }$, so its blocks have hash value smaller than $T/2^{i+\mu }= T'/2^i$ with $i\ge 0$.

Firstly the lite verifier examines whether the length of $\pi _A$ and $\pi _B$ is more than m without the genesis and whether the length of the suffixes is k respectively. If a proof does not satisfy the above properties, it is rejected.

Next, the lite verifier examines whether there is a common block x in $\mathcal {X}_A$ and $\mathcal {X}_B$, because in this case the lite verifier can find which chain represents more proof of work easily. Specifically this means that there is a fork between $\mathcal {C}_A$ and $\mathcal {C}_B$ in the last k blocks. So the lite verifier chooses the suffix that represents the most proof of work (more blocks after x since we assume the same T).

If there is no common block in the suffixes then the lite verifier will execute the algorithm $\mathsf {MaxChain}[\pi _A,\pi _B]$ which will decide which proof represents the chain with the most proof of work. This algorithm may require additional interaction with A, B and operates as follows.

$\mathsf {MaxChain}$ uses two sub-procedures called $\mathsf {RemoveCPhigh}$ and $\mathsf {RemoveCPlow}$. The $\mathsf {RemoveCPlow}$ algorithm with input $(\pi _A,\pi _B)$ just prunes the common blocks, sets $\pi _A', \pi _B'$ to be the proofs without these common blocks and sets b to be the most recent common block in $\pi _A, \pi _B$.

The $\mathsf {RemoveCPhigh}$ on input $(\pi _A,\pi _B)$ will actively query B for the chain with blocks with hash value smaller than $T/2^\mu$ that is omitted in $\pi _B$. Formally, it will return $( \pi '_{A},\pi '_{B},b )$, where $\pi '_{A},\pi '_{B}$ are the proofs without the common prefix and b is the most recent common block with hash value smaller than $T/2^\mu$ in $\mathcal {C}_A$ and $\mathcal {C}_B$. In more detail, it operates as follows:

• We suppose that the proofs are stored in two arrays respectively. The algorithm looks for block $\pi _B$[1] in $\pi _A$ and it continues until it finds a $\pi _B$[$i'$] that it is not in $\pi _A$. As $\pi _B[i'-1]$ is included in $\pi _A$, there is a j, so that $\pi _A[j]= \pi _B[i'-1]$.

• It asks B for an array V with blocks with hash value smaller than $T/2^\mu$ between $\pi _B$[$i'-1$] and $\pi _B$[$i'$]. $\mathsf {RemoveCPhigh}$ will fail in case the array V is not returned by B.

• It finds min $j'\ge j+1$ so that $\pi _A$[$j'$] differs from V[$j'-j$].

• $\pi _{B'}$ is $\pi _B$ without the first $i'-1$ blocks and $\pi _{A'}$ is $\pi _A$ without the first $j'-1$ blocks.

• $b=\pi _A[j'-1]$.

• Return $(b, \pi _A', \pi _B')$.

Next we describe the algorithm $\mathsf {MaxChain}$. Given diverging $\pi _A,\pi _B$, the algorithm will select the proof with the most proof of work as long as the diverging suffix is long enough (as determined by a parameter m). In case the algorithm cannot make a decision it will recurse, requesting proofs with lower depths from A, B as needed, until it reaches level 0 where a decision will be made independently of the parameter m. During these recursion steps if one of the communicating nodes, A, B, fails to support its proof (by providing the extra blocks that the lite node requests) the $\mathsf {MaxChain}$ algorithm will conclude that the opposing chain is the correct one (or it will inevitably fail in case no node is responding to its requests). In more detail the algorithm operates as follows:

• Firstly, the algorithm calls $\mathsf {RemoveCPlow}$ to obtain the pruned suffixes (this does not require interaction). Then, it checks whether $i>0$. In this case, the proofs have different depths and the algorithm checks whether $\pi '_{B}.pow \ge \pi '_{A}.pow$ and simultaneously $\pi '_{B}.length \ge m$. If these two conditions hold, the lite verifier will choose $\pi _B$. Otherwise the algorithm uses $\mathsf {RemoveCPhigh}$ in order to discover the common prefix from the proofs $\pi _A, \pi _B$ (this will require interacting with B).

• Secondly the algorithm checks which of the proofs represents the most proof of work. The proof with the most proof of work is returned if it has length at least m for $\pi '_{B}$ and $2^{i} m$ for $\pi '_A$. Note that in this case a decision is made whose security hinges on the parameter m.

• If the proof with the most proof of work is not long enough the algorithm asks B or both A, B for a proof with a lower depth of the part of the chain ($\mathcal {C}_A^{\lceil k}$ or $\mathcal {C}_B^{\lceil k}$) without the common prefix and continues recursively. We use $\mathsf {Request_B}$[b, y] to denote a request from B for a proof with hash value smaller than $T/2^y$ of the chain $\mathcal {C}_B^{\lceil k}$ that is rooted at block b. Similarly, $\mathsf {Request_A}$[b, y] functions in the same way for player A.³

Eventually, the algorithm will either obtain diverging suffixes that are long enough or will reach the depth 0 (where the actual target T is used) where a decision will be made based solely on the amount of proof of work. This will determine the winning proof and the lite verifier may proceed to execute another comparison or conclude the process.

5 Efficiency Analysis

In this section we present the efficiency analysis of the proof system: first we discuss space complexity, i.e., the expansion that is required in the local storage of the full nodes due to the data structure of the interconnected blockchain. Then, we analyze the communication that is required to send the proof and the verification complexity of the lite verifier.

5.1 Space Complexity

We first show a suitable upper bound on the vector $\mathrm {interlink}$ that is the only addition in each block of the interconnected blockchain.

Theorem 1

Let n be the length of a chain $\mathcal {C}$ that is consisted of blocks with hash value smaller than $T=2^f$. Then the expected size of the dynamic vector $\mathrm {interlink}$, is $f- \sum _{i=1}^{f}(1-\dfrac{1}{2^i})^n$.

Proof

We define a discrete random variable $X_j \in \lbrace 0,\ldots ,f\rbrace$ associated with each block $\mathcal {C}[ j ]$ so that

$$X_j=i \Longleftrightarrow \dfrac{T}{2^{i+1}}\le H_B < \dfrac{T}{2^{i}}, i\in \lbrace 0,\ldots ,f-1\rbrace $$

$$X_j=f \Longleftrightarrow 0\le H_B < \dfrac{T}{2^{f}}$$

($H_B$ is the hash value of $\mathcal {C}[ j ]$).

The hash value of each chain’s block $H_B$ follows the uniform discrete distribution on $\lbrace 0,\ldots ,T-1\rbrace$. So

$$\mathrm {Pr}(X_j=i)=\mathrm {Pr}(\dfrac{T}{2^{i+1}}\le H_B < \dfrac{T}{2^{i}}) = \dfrac{1}{2^{i+1}} ,i\in \lbrace 0,\ldots ,f-1\rbrace $$

$$\mathsf {Pr}(X_j=f)=\mathrm {Pr}(0\le H_B < \dfrac{T}{2^{f}}) = \dfrac{1}{2^{f}}$$

It holds:

$$\sum _{i=0}^{f}\mathsf {Pr}(X_j=i)=1$$

Then the size of the $\mathrm {interlink}$ follows $Y= max \lbrace X_1,\ldots , X_n \rbrace$ distribution.

If $0\le y<f$ then:

$$\begin{aligned} \mathsf {Pr}(Y\le y)=&(\mathsf {Pr}(X_j\le y)) ^n=(\sum _{i=0}^{y} \dfrac{1}{2^{i+1}})^n=(1-\dfrac{1}{2^{y+1}})^n \\ \mathsf {Pr}(Y=y)=&\mathsf {Pr}(Y\le y)-\mathsf {Pr}(Y\le y-1)=(1-\dfrac{1}{2^{y+1}})^n - (1-\dfrac{1}{2^{y}})^n \end{aligned}$$

It also holds: $\mathsf {Pr}(Y\le f)=1$ and $\mathsf {Pr}(Y= f) =1-(1-\dfrac{1}{2^{f}})^n$

We have:

$$\begin{aligned} E(Y) =&\sum _{y=0}^{f-1}y\cdot [(1-\dfrac{1}{2^{y+1}})^n - (1-\dfrac{1}{2^{y}})^n] +f \cdot [1-(1-\dfrac{1}{2^{f}})^n] \\ =&(f-1)\cdot (1-\dfrac{1}{2^f})^n -\sum _{i=1}^{f-1}(1-\dfrac{1}{2^i})^n +f \cdot [1-(1-\dfrac{1}{2^{f}})^n] \\ =&f- \sum _{i=1}^{f}(1-\dfrac{1}{2^i})^n \end{aligned}$$

   $\square$

In Fig. 2 we demonstrate a graph that shows that the size of $\mathrm {interlink}$ is logarithmic in n when n ranges in the current Bitcoin blockchain length and the target is kept stable at $2^{200}$.

Fig. 2.

Size of $\mathrm {interlink}$ as a function of blockchain length when target is $T=2^{200}$.

Compressing the Interlink Vector Using Merkle Trees. To reduce the storage per block it is possible to compress the $\mathrm {interlink}$ vector using a Merkle tree. In more detail, instead of storing the whole $\mathrm {interlink}$ in each block we can organize the vector in a Merkle tree and store only the root hash in each blockheader. This demands the addition of only a hash value in each block instead of the sequence of hash values in $\mathrm {interlink}$. The modifications needed in the $\mathsf {ConstructProof}$ algorithm are straightforward and we omit them.

5.2 Communication and Time Complexity

We will analyze now the size of the proof $\pi$. We will focus in the optimistic scenario, where the adversary does not create deep forks that cut into the proofs of the honest parties, i.e., when the k-suffix that the adversary sends has a common block with the suffix of the proofs sent by the honest provers. Note that the honest parties will not fork in the part of the chain before the k-suffix with overwhelming probability in k [6]. In such case the lite verifier chooses the chain with the most proof of work without having to perform any extra interaction with the provers (performing the $\mathsf {Request}$ steps in the $\mathsf {MaxChain}$ algorithm). Therefore the size of the proof will be the output of the $\mathsf {ConstructProof}$ algorithm.

Let $\mathcal {C}^{\lceil k}$ be the pruned local chain without the k-suffix of a prover that a lite verifier has asked, n the length of the chain and m the security parameter. Firstly we will prove that the probability with which a block of $\mathcal {C}^{\lceil k}$ has hash value smaller than $\dfrac{T}{2^i}$ is $\dfrac{1}{2^i}$.

If $H_B$ is the hash value of a block B and $j\in \mathbb {N}$, $j< T$ then $\mathrm {Pr}(H_B=j\mid H_B<T)=1/T$. It follows,

$$ \mathrm {Pr}(H_B< T/2^i \mid H_B< T)=\sum _{j=0}^{T/2^i-1}\mathrm {Pr}(H_B=j\mid H_B< T)=\dfrac{T/2^i}{T}=\dfrac{1}{2^i} $$

The number of blocks in $\mathcal {C}^{\lceil k}$ with hash value smaller than $T/2^i$ is a discrete random variable $D_i$ that follows the Binomial distribution with parameters (n, $p_i=1/2^i$) and its expected value is $E(D_i)=n\cdot p_i$.

Recall that the $\mathsf {ConstructProof}$ algorithm has output the $\mathrm {innerchain}_{i_0}=\pi$, where $i_0$ is the maximum i so that there are at least m blocks with hash value smaller than $T/2^i$ in $\mathcal {C}^{\lceil k}$. As a result we must examine what is the depth $i_0$ of the proof that the algorithm returns and how many blocks (denoted by $D_{i_0}$) the proof $\pi$ will contain.

In the next lemma we establish that the depth of the inner chain that the $\mathsf {ConstructProof}$ algorithm returns is quite close to the optimal value (which is roughly $\log (n/m)$).

Lemma 1

Let n be the size of the local pruned chain $\mathcal {C}^{\lceil k}$ of the prover. Assume that $n<Tm$ and define i so that $2^im \le n <2^{i+1}m$. Then it holds $\mathrm {Pr}(D_{i-1}\le m-1) \le \exp (-\varOmega (m))$.

Proof

Observe that $n\cdot p_{i-1} =n/2^{i-1}\ge 2^i m / 2^{i-1}= 2 m > m-1$. So according to the Chernoff bound⁴ for the Binomial distribution it holds that:

$$\begin{aligned} \mathrm {Pr}(D_{i-1}\le m-1)&\le \exp (- (np_{i-1}-(m-1))^2 / 2n p_{i-1} ) \\ \le&\exp (- 1/(2/(2^{i-1}))\cdot (n (1/(2^{i-1}))-(m-1))^2/{n})) \\ \le&\exp (-(2 m-m+1)^2/2^{3}m) \le \exp (-\varOmega (m)) \end{aligned}$$

This completes the proof.    $\square$

Armed with this lemma we next observe that the length of the inner chain for the suitable index is not going to be substantially larger than m.

Lemma 2

Let $n<Tm$ and define i so that $2^{i}m \le n <2^{i+1} m$. It holds that $\mathsf {Pr}(D_{i-1}\ge 5m)\le \mathrm {exp}(-\varOmega (m))$.

Proof

Observe first that $2m/n \le p_{i-1}=1/2^{i-1} < 4m/n$. Consider the Chernoff bound on the upper tail that states $\mathsf {Pr}[ X \ge (1+\delta )\mu ]\le \mathrm {exp}(-\delta ^2 \mu /3)$ when X is a Binomial distribution with mean $\mu$ and $\delta \in (0,1]$. It follows that $\mathsf {Pr}[ D_{i-1} \ge 5m ] \le \mathsf {Pr}[ D_{i-1} \ge (1+1/4) p_{i-1} n ] \le \mathrm {exp}(- p_{i-1}n / 48 ) \le \mathrm {exp}(- m/24 )$.    $\square$

We are now ready to state the theorem that establishes the efficiency of the proof that is constructed and communicated to the lite verifier.

Theorem 2

The size of the proof $\pi$ that the prover sends in response to a lite verifier in the optimistic case is O(m) with overwhelming probability in m.

Proof

In the optimistic case the proof $\pi$ that the prover sends to the lite verifier is the output of the $\mathsf {ConstructProof}$ algorithm. If n is the length of the local chain from which the prover constructs the proof and we have $2^i m \le n <2^{i+1}m$ for an $i\ge 1$ then it holds that: The $\mathsf {ConstructProof}$ algorithm will return a proof of depth $i-1$ with overwhelming probability in m, as we proved in Lemma 1. Furthermore, the size $D_{i-1}$ of the proof $\pi$ will be bounded by 5m with overwhelming probability in m, as we proved in Lemma 2. This completes the proof.    $\square$

The above completes the argument for the optimistic case, where the adversary does not explicitly interfere and attempts to increase the complexity of the lite verifier. We note that in the case that the adversary interferes and makes the lite node to engage in extra communication by issuing the $\mathsf {Request}$ commands, he can only succeed in this with significant effort (by mining very low target blocks) and with bounded, albeit non-negligible, probability. It seems unlikely that an adversary will engage in this effort for the sole purpose of delaying a lite verifier and for this reason, we consider the optimistic efficiency analysis performed above to be quite indicative of the actual performance of the protocol.

Finally with respect to time complexity observe that in the optimistic case, the verifier will have to perform a number of verification steps that are proportional to the size of the proof that is received. It follows that the complexity of the verifier is also $O(m \log n)$.

Complexity When Using a Compressed Interlink Vector. The communication and time complexity in this case can be improved since in each block from the $\mathrm {interlink}$ vector committed in the Merkle root hash only a path in the tree needs to be transmitted. It follows easily that the complexity of the lite verifier in the optimistic case will be $O(m \log \log n)$.

6 Security Analysis

A successful attack against our lite verification mechanism suggests that a lite verifier reaches a different conclusion about a certain transaction compared to a full verifier. The proof argument for security is as follows: given an adversary $\mathcal {A}$ that responds to a lite verifier we construct an adversary $\mathcal {A}^*$ that responds to a full verifier. We will argue that with high probability the full verifier operating with $\mathcal {A}^*$ reaches the same conclusion as the lite verifier operating with $\mathcal {A}$.

Intuitively the above means that for any proof that a lite verifier accepts and processes there exists a full chain that can be recovered and produces the same output behavior for a regular SPV verifier.

The description of $\mathcal {A}^*$ is as follows:

• 1. $\mathcal {A}^*$ simulates the operation of $\mathcal {A}$ while additionally in each round acts as a full verifier and requests the chains from all the honest nodes denoted by $\mathcal {C}_1,\ldots ,\mathcal {C}_e$ for some integer e. It maintains a “block tree” BT containing all blockchains and adds there any blocks that are produced by the adversary. Note that it is possible to $\mathcal {A}^*$ to perform this since in the random oracle model (that we adopt from [6]) it is possible for $\mathcal {A}^*$ to monitor all queries of $\mathcal {A}$ to the hash function $H(\cdot )$. Any queries made by $\mathcal {A}$ that do not correspond to valid blocks are ignored.

• 2. When $\mathcal {A}$ responds to a lite verifier with a pair $(\mathcal {X}, \pi )$, $\mathcal {A}^*$ searches in BT for a chain $\mathcal {C}$ that is consistent with $(\mathcal {X}, \pi )$, i.e., $\mathcal {X}$ is the suffix of $\mathcal {C}$ and $\pi$ is a sub-chain of $\mathcal {C}$. If such a chain is found, then $\mathcal {A}^*$ response to a full verifier with $\mathcal {C}$. If no chain is found then $\mathcal {A}^*$ returns no response to the full verifier.

We perform our analysis in the model of [6]. Recall that in their model, there are n parties maintaining the blockchain, each allowed q queries to the hash function (thought of as a random oracle) and t of the parties are controlled by the adversary. The probability of finding a proof of work with a single hash query is $T/2^{\kappa }$ (recall that the target is T and is stable). We use the same notation as [6] and we denote $\alpha = (n-t)pq$, $\beta = pqt$ and $\gamma = \alpha - \alpha ^2$. Intuitively, the parameter $\alpha$ represents the hashing power of the honest parties; it is also an upper bound on the expected number of solutions that the honest parties will obtain in one round; on the other hand $\beta$ is the expected number of solutions that the adversary may produce in one round. Finally, $\gamma$ is a lower bound on the expectation of a uniquely successful round, i.e., a round where a single honest party finds a proof of work solution.

We are now ready to formulate the theorem that establishes the security of lite verification. The theorem is conditioned on $\gamma >(1+\delta ) \beta$ which roughly⁵ corresponds to the setting where the honest parties command the majority of the hashing power.

Theorem 3

(Security of lite verification) Let $\gamma > (1+\delta ) \beta$ for some $\delta >0$. A full verifier interacting with $\mathcal {A}^*$ reaches the same conclusion as the lite verifier operating with $\mathcal {A}$ with probability $1 - \mathrm {exp}(-\varOmega (\delta ^2 m))$.

Proof

(Sketch). We compare any execution with $\mathcal {A}$ where a lite verifier requests a proof to an execution where a full verifier requests a proof from $\mathcal {A}^*$. We define an event $\mathsf {BAD}$ to be the event that the two verifiers report a different conclusion. An event $\mathsf {BAD}$ would necessarily correspond to the case 2 above in the definition of $\mathcal {A}^*$ when the latter fails to reconstruct a chain $\mathcal {C}$ from BT that corresponds to the proof $(\mathcal {X},\pi )$ that the adversary $\mathcal {A}$ produces. Let $\mathsf {NOWIT}$ be this latter event and observe $\mathsf {BAD} \subseteq \mathsf {NOWIT}$. We will argue that whenever $\mathsf {NOWIT}$ happens then with overwhelming probability in m it holds that a proof originating from an honest party will win the comparison performed by the $\mathsf {MaxChain}$. Let this event be $\mathsf {HWIN}$. In more detail we will prove that $\mathrm {Pr}(\lnot \mathsf {HWIN} \wedge \mathsf {NOWIT})$ drops exponentially in m. Observe that this is sufficient since $\mathsf {BAD}\subseteq \lnot \mathsf {HWIN}$ and hence it will follow that $\mathrm {Pr} (\mathsf {BAD})$ drops exponentially in m.

The event $\lnot \mathsf {HWIN}$ suggests that the adversary $\mathcal {A}$ has managed to produce a proof for which no honest party could outperform in the view of the $\mathsf {MaxChain}$ procedure. Furthermore, if $\mathsf {NOWIT}$ happens also, it follows that it is impossible for $\mathcal {A}^*$ to reconstruct a chain that corresponds to the proof that wins the $\mathsf {MaxChain}$ algorithm. This suggests that the winning proof $(\mathcal {X},\pi )$ contains blocks that were impossible to attach to the blockchain tree BT by $\mathcal {A}^*$, due to the fact of not being valid extensions of a (level-0) chain. It follows that in the response $(\mathcal {X},\pi )$, the proof $\pi$ should diverge from all chains that belong to an honest party (otherwise all the blocks in $\mathcal {X}$ would have been attached to BT and a witness for $(\mathcal {X},\pi )$ would be reconstructed by $\mathcal {A}^*$). Let b be the most recent common honestly generated block of $\pi$ with the longest chain $\mathcal {C}$ from BT that belongs to an honest party. Given that $\mathsf {MaxChain}$ elected $(\mathcal {X},\pi )$ over the proof provided by the owner of $\mathcal {C}$ it holds that $\pi$ contains a sequence of at least m blocks starting from b (or later) that are of target $T/2^{i}$ where $i>0$ is the depth of $\pi$. Let r be the round that block b was created. We will next show that the probability that $\mathcal {A}$ obtains m blocks with hashes less than $T/2^{i}$ faster than the honest parties’ chains advance by $2^{i} m$ blocks is negligible in m. It follows that it will be with negligible in m probability that $\mathcal {A}$ can produce a proof that will be selected by $\mathsf {MaxChain}$.

Let $X_r$ be the random variable that is equal to 1 if r is a successul round (following the terminology of [6]). In [6] it is shown that in any s rounds following round r it holds that the length of the honest parties’ chains will be at least $\ell + \sum ^s_{l=r} X_l$ where $\ell$ is the length of an honest parties’ chain at round r.

The number of rounds that will be required for the adversary to compute m blocks with hash less than $T/2^{i}$ follows a negative binomial distribution. The expectation for the number of rounds is $2^{i}\beta ^{-1}m$ where $p = T/2^{\kappa }$ and $\beta = pqt$. By applying a tail bound for the negative binomial distribution we obtain that the probability the number of rounds is less than $(1-\delta /4)2^{i}\beta ^{-1}m$ is $\mathrm {exp}(- \varOmega ( \delta ^2 m ) )$.

On the other hand, in $(1-\delta /4)2^{i}\beta ^{-1}m$ rounds, by applying a Chernoff bound, the probability that the honest parties will produce less than $(1-\delta /4)^2 \gamma 2^{i}\beta ^{-1}m$ blocks is bounded by $\mathrm {exp}(-\varOmega (\delta ^2 m) )$.

Observe now that $\gamma > (1+\delta ) \beta$ implies $\gamma (1-\delta /4)^2 \beta ^{-1} >1$ and thus the probability that the proof of work of the chains owned by the honest parties will exceed that of the adversary is $1- \mathrm {exp}(-\varOmega (\delta ^2m ))$.    $\square$

On the Feasibility and Infeasibility of Non-interactive and/or Constant Size Proofs. Observe that our security parameter for the proof is m and the size of the proof in the optimistic case is O(m). In our construction, the lite verifier may require further interaction with the provers if it discovers forks in the inner chains that it receives. This leaves open the question whether shorter proofs can be achieved (e.g., constant size) or whether it is possible to obtain non-interactive proofs, i.e., proofs that require always a single message from the full nodes to the lite verifier. With respect to constant size proofs it is unlikely that the techniques like the ones we consider here would provide such an improvement: for instance, if a single block of exceptionally low hash value is transmitted as a proof of many proofs of work of proportional length, concentration bounds will not be able to provide a sufficiently low probability of attack. In other words, such short proofs might be exploitable by an attacker in very much the same way that the difficulty raising attack of [3] operates and hence they will not be secure. Similarly, given any non-interactive proof that goes arbitrarily low in terms of the inner chain it selects, one can always imagine an attacker that attempts to fork in the very last block of the inner chain and thus gain an unfair advantage compared to the honest parties even in the honest majority setting. However this may be countered by requiring sufficient number of blocks following such low hash blocks; we leave for future work the feasibility of investigatng the design of short and secure non-interactive SPV proofs.

The Dynamic Setting. To account for a dynamically changing population of miners, in Bitcoin and related blockchain protocols, the target is recalculated at regular intervals. It is possible to build our interconnected blockchains in the dynamic setting as well; some care needs to be applied during verification of proofs however since target recalculation will need to be performed over the inner chains. We leave the analysis in the dynamic setting for future work.