Scribd
Upload
4 views

Blockchain Consensus properties _ part 2

The document discusses the Consensus Layer and the challenges of achieving agreement on transaction history among participants with potentially divergent interests. It outlines the Consensus Problem, Byzantine behavior, and the necessity of an honest majority for protocol properties like termination, agreement, and strong validity. The document also introduces Bitcoin's unique approach to consensus, emphasizing its blockchain structure, proof of work, and the implications of a public setup for communication and security.

Uploaded by

mscs24009
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
4 views

Blockchain Consensus properties _ part 2

The document discusses the Consensus Layer and the challenges of achieving agreement on transaction history among participants with potentially divergent interests. It outlines the Consensus Problem, Byzantine behavior, and the necessity of an honest majority for protocol properties like termination, agreement, and strong validity. The document also introduces Bitcoin's unique approach to consensus, emphasizing its blockchain structure, proof of work, and the implications of a public setup for communication and security.

Uploaded by

mscs24009
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 29

Motivation for the

Consensus Layer, I

• A transaction history needs to be agreed by all


participants.

• Participants may have diverging interests in terms


of the history of transactions.
The Consensus Problem
v1 v2 v3 vn
P1 P2 P3 Pn

High level
requirement Consensus Protocol
agree on
the output

P1 P2 P3 Pn

u1 u2 u3 un
Study initiated by Lamport, Pease, Shostak 1982
Problem Statement
• A number (say, t) of the participating entities can
diverge from the protocol.

• This has been called Byzantine behaviour in the


literature.

• The properties of the protocol are defined in the


presence of this “malicious” coalition of parties that
attempts to disrupt the process for the “honest”
parties. H, |H| = n t
Consensus Properties

• Termination 8i 2 H(ui is defined)

• Agreement 8i, j 2 H (ui = uj )

Strong Validity : 8i 2 H 9j 2 H (ui = vj )


Honest Majority is
Necessary, I
Consider an adversary that performs
one of the following with probability 1/3

n n
2 2

; 0 1

8i 2 A0 : (vi = 0) 8i 2 A1 : (vi = 1)
Honest Majority is
Necessary, II
• If the adversary corrupts A0, then output of honest
parties (that belong to A1) should be 1.

• If the adversary corrupts A1, then output of honest


parties (that belong to A0) should be 0.

• If the adversary corrupts no-one, then the output of


all parties should be equal.
Is Honest Majority Sufficient?

• Two important scenarios have been considered in


the consensus literature.
n
• Point to point channels. No setup. t<
3
• Point to point channels. With setup. n
t<
2

The setup enables provides a correlated private initialization string to


each participant. It is assumed to be honestly produced.
Setup in Consensus

• A "public-key infrastructure" (PKI).

• parties have signing and verification keys for a


digital signature scheme.

• Each party knows every other party’s verification


key.
Enter Bitcoin
• (2008-2009)

• Important concepts used

• blockchain data structure.

• proof of work (POW).

• both known and studied earlier, but put in


combination for a novel application.
Blocks
B = hs, x, ctri

pointer content counter


to previous (proof of work witness)

(H(ctr, G(s, x)) < T ) ^ (ctr  q)

hash functions target upper bound


Blockchain
B0 = h?, x0 , ctr0 i genesis block

B1 = hs1 , x1 , ctr1 i
.. si = H(ctri 1 , G(si 1 , xi 1 ))
.

Bn = hsn , xn , ctrn i

C = hB0 , . . . , Bn i xC = hx0 , x1 , . . . , xn i
dk
C = hB0 , . . . , Bn ki
head
The bitcoin “backbone”
• The core of the bitcoin protocol

• The chain validation predicate.

• The chain selection rule (max-valid)

• The proof of work function.

• The main protocol loop

• Protocol is executed by “miners.”


Adversary Model
• Assume there are n parties running of the protocol

• synchronously.

• each one has a quota of q queries to the function


H(.) in each round.

• A number of t parties are controlled by an


adversary (a malicious coalition).
Basic Properties
• Common Prefix

• Chain Quality

• Chain Growth
Common Prefix, I
Common Prefix, II
(strong common prefix / consistency)

dk
8r1 , r2 , (r1  r2 ), P1 , P2 , with C1 , C2 : C1 C2

The property holds true in a probabilistic sense


with an error that decays exponentially in k
If we take different chains of parties at different rounds, if we
remove k blocks from one, we will be inside other chain. The more
blocks remove, the higher is the likelihood you will be in the
prefix of other chain that will be adopted by honest party in
future round. is close to one, but never always 1.
The probab
(1-epsilon). The honest parties maintain a main chain with
small diverging forks. There will be no deep forks. Fork
means divergence from the main chain.
Common Prefix, III
(strong common prefix / consistency)

dk
8r1 , r2 , (r1  r2 ), P1 , P2 , with C1 , C2 : C1 C2

• The property goes in future. Am I looking at the right chain? You


remove k blocks ,and with high probability you are sure that future
chains will adopt prefix.
Chain Growth, I
Chain Growth, II
Parameters ⌧ 2 (0, 1), s 2 N
8r1 , r2 honest player P with chains C1 , C2
r2 r1 s =) |C2 | |C1 | ⌧ s
The property holds true in a probabilistic sense
with an error probability that exponentially decays
in s. The chain will grow at honest node after period of
time s. Tau is close to zero, but bounded away.

⌧ ⇡ probability at least one honest


party finds a POW in a round
Chain Quality, I
Chain Quality, II

Parameters µ 2 {0, 1}, ` 2 N


The ratio of blocks of an `-long segment of an honest chain
produced by the adversary is bounded by (1 µ)`/l

The probability holds true probabilistically with an


error that exponentially decays in ` where the blocks in
chain coming from? consider when t=n/2

n 2t
µ⇡
n t
Robust Transaction Ledger

• The three properties can provide a ledger with the


following characteristics.

• persistence: Transactions are organized in a


“log” and honest nodes agree on it.

• liveness: New transactions are included in the


log nodes, after a suitable period of time.
Establishing the ledger
• Persistence follows from strong Common Prefix.

• (need to exclude k most recent blocks)

• Liveness from Chain Growth and Chain Quality.

• (leave sufficient time for chain to grow and then


apply chain quality to ensure that at least one
honest block is included).
The Bitcoin Setting for
Consensus
• The bitcoin setting is a different compared to what has been
considered classically for the consensus problem.

• Communication is by diffusion. (no point-to-point channels).

• Message delivery is assumed but message origins and


recipient list are not specified.

• The protocol setup is not a private correlated setup (digital


signatures are not used to authenticate miners)

• A public setup is assumed (in the form of the genesis


block)
Natoshi Email.

https://www.mail-archive.com/[email protected]/msg09997.html

You might also like