Notes for consensus in blockchain era
Notes for consensus in blockchain era
Reference: Garay, Juan, and Aggelos Kiayias. "Sok: A consensus taxonomy in the blockchain era." Cryptographers’ track at the RSA conference. Springer, Cham, 2020.
1. Model for protocol executions:
Interactive Turing machine (ITM) as a formal model of computation. An instance of ITM is called an ITI. ITM is TM with identity tape and outgoing tape.
Protocol \Pi is modeled as an ITM, in arbitrary setting. To have "arbitrary", the setting is produced by an adversary so that one does not need to quantify over all possible details but treat everything as environments. Adversary is also specified as an ITM and only a single adv ITM is allowed.
(Z,C): environment and control program. Env Z can spawn new ITIs using \Pi or Adv, who writes to C in its outgoing tape. Communication is routed through C, sending messages to Adv.
Functionalities: specify resources available to instances. “Ideal functionalities” are also ITMs, and can be spawned by ITIs running \Pi. Eg., secure channel functionality, message-passing functionality.
VIEW is an execution, a string concatenating all messages and all ITI states at each step of the execution of the system.
Def. Given a predicate Q, \Pi satisfies property Q is \forall A and Z, Q(VIEW) holds.
Settings: asynchronous vs synchronous execution; static vs dynamic environments (assume the total number of ITIs is known); setup (CRS, PKI) as a separate functionality.
2. Consensus definition
Properties based: validity + agreement + termination
validity:
strong validity: the value agreed on is input by at least one honest party
Simulation-based: ideal functionality
Property-based proofs does not guarantee simulation-based security in case of a dynamic adversary.
Ledger consensus:
Problem: a set of servers continuously accepting transactions from a set T and incorporate them into a data structure called ledger, which is a unique view.
Property-based security definitions: consistency / persistence + liveness
consistency: a client queries an honest node and receives ledger view L1 and then queries an honest node in a later round and receives view L2, then L1 is the prefix of L2.
liveness: if a txn is valid and given as input to all honest parties in a round r, it is included in view of round r+u where u is the rounds in a complete consensus run [more in point 9]
serializability: if a txn t1 is valid and given as input to all honest parties in a round, and txn t2 is incompatible with t1, in later rounds, txn t2, t1 cannot be included in this order.
Simulation-based: [BMTZ17]
Related: called SMR in classical distributed systems literature
Reduction from Consensus to Ledger consensus:
no setup: Strong validity and termination ensure liveness and agreement ensures consistency. Strong validity is needed because honest parties may hold disjoint transaction sets. An alternative is to have interactive consistency and validity. One other related notion is predicate-based validity.
setup in all rounds in consensus (or emulate with one initial round, non-balack-box): sequential composition
3. Communication model
point-to-point / RMT: pairwise reliable and authenticated channels; also called RMT, reliable message transmission.
peer-to-peer diffusion: messages are passed along; cannot identify source; cannot preserve order
Given RMT, can Diffuse; given Diffuse, cannot simulate RMT.
4. Network model
Synchrony: protocol executions can be divided into rounds; parties are activated in sequence; message are delivered within a known bound \Delta
rushing adversary: adv can act last in a round to decide its behavior in this round and message delivery for honest parties in the next round
relax timing:
partial synchrony: unknown \Delta
asynchrony: eventual delivery; FLP impossibility result
fully asynchronous: messages can be dropped; impossible
5. Setup
Public-state setup: parameterized by a probability ensemble D, which given input size k, specifies a distribution that is used to sample a common string s of length poly(k).
Private-state setup: parameterized by a probability ensemble D, which given input size k, specifies a distribution that is used to sample a sequence of strings (s1,…,sn), each of length poly(k). Each party has private access to the corresponding string. The strings can be independent or correlated as in “correlated randomness”.
6. Computational assumptions
IT: unbounded adv; can be perfect or statistical (only meaningful in probablistic consensus protocols, e.g., a bad coin)
Computational: polynomial adv
One-way functions
PoW
Random oracle: (not in the ITM model) limit the quota of queries granted to each party in a round
7. Results
Point-to-point
Synchrony
i) IT security:
[LSP82] n>3t is necessary and sufficient condition; optimal round complexity is t+1
Deterministic:
[FL82] round complexity lower bound t+1
[DRS90] actual number of corruptions f<t, lower bound min{t+1, f+2} rounds for non-simultaneous stop termination; lower bound is still t+1 rounds if simultaneous stop is necessary
Randomized
[BO83]
[Rabin83] linearly resilient consensus in expected constant round is possible given a common source of randomness (“coin”)
[FM97] construct the common coin in [Rabin83], n>3t, expected constant round
[FG03] for “strong validity” definition, iff n> max(3, |V|) t where V is the domain of inputs and outputs
If pre-computation phase is allowed in IT setting with reliable broadcast, broadcast and consensus can be achieved with the same bounds as in computational setting, using “pseudo-signatures”.
ii) Computational security:
[LSP82] trusted setup; n>t, t+1 rounds but with exponential time complexity; [DS83] Dolev-Strong assumes PKI, polynomial time.
[Bor96] no PKI, parties distribute keys by themselves, broadcast and consensus are impossible if n<= 3t because keys are not tied to corresponding parties
[FG03] trusted setup; for “strong validity” definition, iff n> |V| t; polynomial time; t+1 rounds
[KK09] PKI, digital signatures, based on VSS => n>2t, expected constant round (extending [FM97])
[GKKO07] expected constant round for t = n/2 + k, expected O(k^2) running time
No simultaneous termination.
-> Probabilistic termination
sequential composition [LLR06]: property based security
parallel composition [BE03]: property based security
compositions with simulation-based security [CCGZ16]
Partial synchrony:
bounds remain the same with no setup and public setup; bounds degrade to n/3 with private setup
Asynchrony:
Feasibility
without setup,
can adapt [FM97] to achieve resilience n/4
termination except with negligible probability [CR93] / termination with probability 1 [ADH08], resilience n/3
private setup:
one-way function: always terminating, n/3 resiliency [Fel88]
Practicality
PBFT [CL02] n/3 resiliency
Peer-to-peer
The total number of participants is unknown but rather is a runtime parameter. The protocol needs to tolerate different participation levels.
Assuming peer-to-peer and private setup, one can simulate point-to-point, although inefficiently.
W/o authentication, deterministic consensus is impossible [Okun05]. Probabilistic consensus is possible.
Synchrony:
Computational security:
PoW: strings PoWs in a hash chain; optimal resiliency is n/2
One-way function
Partial synchrony:
Difficulty parameterization hardcoded →
network delay is low, then max resiliency;
otherwise, degrade until dissipating entirely.
Consistency collapses when delay is arbitrarily large.
8. Ledger consensus results
Point-to-point
Adapt standard BFTs.
Peer-to-peer
With private setup, can simulate point-to-point.
Maximum resiliency n/2. In other words, ledger consensus is impossible for t>=n.
The total number of participants is unknown.
PoW:
static & synchorny / partial synchrony: n>2t; each party has a fixed quota of queries that can be performed to a hash funciton
dynamic: assume PKI and honest majority [KRDO17]
PoS Dynamic setting
assume PKI and honest majority: snow white [BPS16] ouroboros praos [DGKR18]
dynamic availability in Ouroboros genesis: arbitrary number of parties may not be fully opeartional; “bootstrap from genesis” via a chain selection rule
Algorand: identities of participants need not be known in advance; but expected participation is hardcoded