Verification

To be able to participate in the protocol, the participants must verify that the inputs they are receiving are valid in regards to the ledger chain they are

maintaining. They must also be able to validate whether the proof-of-work function was computed correctly as well as the validity of signatures.

Proofs of Work We have already presented a way to verify whether a proof of work was computed correctly in the previous chapter. We present the functionverifyPoWagain, which takes a triple (x, y, s) as input and verifies whethery =PoWs(x). If we want to see whether the proofs of work in a PoW blockP Cj_{[i] are properly computed, we would evaluate verifyPoW}

over (P Cj_{[i].link, P C}j_{[i].proof) (which is a slight abuse of notation, as} P Cj_{[i].proof is a pair). It is important to note that each participant can}

make unlimited queries to verifyPoW and that the query takes only one time step and is not dependent on the rateγj of the participant.

PoW blocks For a participantajto characterise whether a PoW block is valid, he must take into account the structure of the block and whether it is consistent with his ledger chain as well as the PoW chain where it belongs. Checking the structure of the block implies not only checking whether it follows the definition, but also whether P Ck[i].linkLedger is equal to

H(BC[i−1]). This means that the block points to the appropriate ledger block. Ledger blocks also point to PoW blocks, although not necessarily. If it is the case, then there exists a triple (x, y, z) in BC[i].P such that

z= Σ.signkxand the following properties must be verified 1. P Ck_{[i].linkis equal toy}

2. P Ck_{[i].proof is equal tox}

If this is not the case,aj must query forP Ck_{[i−1], verify it and then use} H(P Ck_{[i−1]) in place ofy(it is not necessary to check the second property}

as long as the block is well constructed). Note that this procedure works if and only if the preceding chains are consistent and valid. We will call this procedureverifyPCand any participant may query the environment for it a polynomial amount of time per time step. If the block is successfully verified,verifyPCoutputs 1, in any other case it outputs 0. While in certain cases it is necessary to have the rest of the PoW blockchain to verify a block, for simplicity in the presentation we will only includeP Ck[i] and

BC as the inputs toverifyPC. Note thatverifyPCmakes use ofverifyPoW

to check whether the proofs of work are computed correctly.

Ledger Block and Transactions Participants are also interested in verifying blocks from the ledger chain. To verifyBC[i], they should check whether it points to the right block in the chain and whether it contains enough correct proofs of work by the participants. Besides the structural prop- erties of the block, we must also ensure that the transactions contained within it are valid. To simplify this, we will define two functions to do this verification. One which only takes into account the consistency of the transactions, verifyTxs and one which solely checks the structure of the block itself, verifyBC. The former takes a blockchain and a (possibly

empty) set of transactions and checks if the transactions in the blockchain are consistent and whether the set can be added to it without breaking consistency. It also checks that all transactions are valid, as only the envi- ronment may create valid transactions but the adversary may input fake transactions. The latter takes a blockchain BC[0, i) and a block BC[i], withi≥2, and checks whether the following properties hold:

• BC[i].st=i

• BC[i−1].NA⊆BC[i].NA∪ind(BC[i].G)

• BC[i−1].NA\BC[i].NA6=_∅iff there exist records inBC[i].Gsuch thatind(BC[i].G) =BC[i−1].NA\BC[i].NA

• BC[i].linkis equal toH(BC[i−1])

• Let|BC[i].NA| =m, |BC[i].P| > Qm where every element of P is of the form (x, y, z) withz= Σ.signj(x, y).

• BC[i].Gcontains records of the form (M, B, B∗), whereM ⊆BC[i− 1].NAandM∩BC[i].NA=∅

• Let |BC[i].NA| =m, |BC[i].Sig| > Qmwhere every s ∈ Sig is of the forms= Σ.signj(id, N A, link, T, G, P).

• The order of the elements of P and Sig corresponds to the order induced by the indices

• If there exist (x, y, z)∈BC[i].P and (x∗, y∗, z∗)∈BC[i−1].P such thatz= Σ.signj(x, y) andz∗= Σ.signj(x∗, y∗) thenverifyPoW(y∗, x) = 1

Note that whileverifyTxschecks if the transactions in the chain itself are consistent, verifyBC checks only whether the new block would fit at the tail of the chain, but does not check if the chain itself is constructed cor- rectly. However, this would be easy to do by defining a function that uses

verifyBCrecursively.

Cheating An important part of our protocol is the ability to recognise and expel cheaters from participating. We are interested in preventing people from forking the chain and, because the blocks are signed, it is possible to infallibly recognise when this happens. If two different blocks with the same round identifier are signed by the same participant, it can only be because of an attempt to fork the chain. Because our signature scheme is assumed to be unforgeable, this can only happen if a party purposefully tried to maintain two different chains2_{. An attempt at forking can be}

recognised both in ledger and in PoW blocks. We will take advantage of the similarity in their construction to create a function that can work on both types of blocks, which we will callcheckCheat.

2_{We will see that it is impossible for an honest party to accidentally sign the incorrect} ledger block.

If we have two PoW blocks that belong to the same participant, we have proof that the creator of that block is attempting to fork a chain. However, if we have two ledger blocks that belong to the same round, we only have definite proof of cheating by the people who signed both blocks. Because honest parties will have one of the two blocks in their chains already, it would be tempting to define everyone who signed the blocks from the fork as an antagonistic party and remove them from the protocol. However, we are interested in punishing only overt attempts at cheating: when someone signed two distinct blocks in the same round.

Given two blocks, we want to know if they imply that a certain set of participants were cheating. Although the two block structures that we work with are different, they have the same overall structure. In particular, the last element of the tuple contains signatures of the rest of the block, which is what we care about. This means that given a block B, which might be either a ledger or PoW block, the seventh element, B.Sig, is a set of signatures. In the same way, the first element, B.st, is a round identifier. Therefore, we definecheckCheatthe following way:

checkCheat(B, B∗) =     

∅ ifB andB∗ are of different type

ind(B.Sig)∩ind(B∗.Sig) ifB.st=B∗.st

∅ otherwise

Having a cheating detection mechanism inside of the protocol allows the protocol to regulate itself. While we will work in a permissioned setting where consequences can be executed outside the model, having a mechanism inside of it allows us to regulate behaviour from the inside in order to not rely on outside compliance to keep the protocol functional.