*Resources:*

*HW:*

## Recap

Synchrony | Asynchrony - ? | |

Permissioned | • PKI, any f<n ⇒ solution for BB
• no PKI, f≥n/3 ⇒ no BB protocol | ? |

## Relaxing the Synchronous Assumption

Recall 4 assumptions: - still in permissioned setting, later will move to permissionless consensus (big innovation in Bitcoin) - PKI will not be important for the next couple of lectures - will move to asynchronous model - the number of Byzantine nodes for us will be “at least 1”, i.e. f≥1

__Synchronous model:
__(i) shared global clock
(ii) every message sent at time t arrives at time t+1

However, (ii) is not OK for modeling internet, since there are *outages* and *denial-of-service* (DoS) attacks

If there is a known bound △ on the maximum message delays (even very large, like 1000 seconds), by the *inflating time* trick we are still in the synchronous model. Similarly if a prior bound △ on max difference between shared global clock.

These inflating time tricks to deal with failure of (i) and (ii) are very unsatisfying, because: (1) they don’t force us to deal with outages and DoS attacks; (2) they produce silly protocols in which nodes mostly idle.

## The Asynchronous model

__The basic idea:__
(i) no shared clock;
(ii) no bound on the max message delay
(iii) minimal assumption: every message arrives, eventually (otherwise things are uninteresting)

__Precise model:__

- pool M of outstanding not-yet-delivered messages
- while(TRUE):
- one message (r,m) is delivered (to recipient r) [useful to think of each message and their order as being chosen by an “adversary” whose sole goal is to foil the consensus protocol]
- r can add any number of messages to M

__Assume:__
- M is initialized to be $\{(i,\perp)\}_{i=1}^n$ (dummy messages to everyone to get started)
- every message is delivered, eventually
- each node, if receives a message, always injects a dummy message to itself into the pool M, in order to be able to speak later

Note that we now have two adversaries: - Byzantine nodes - Adversarial message delivery (which is probably not adversarial, but since we want to prove a theorem, we assume that it may go in any way, in particular worst possible adversary way)

Why we have made all these strange assumptions and models? It doesn’t reflect the internet, but it has much *weaker* assumptions then the internet, so if we would design a protocol under these assumptions, we would be in a great shape!

## Byzantine Agreement problem

Before:
- SMR (many outputs ⇒ *multi-shot* consensus problem)
- BB (one output ⇒ *single-shot* consensus problem)

Now:
- Byzantine Agreement, another *single-shot* consensus protocol.

__Protocol:__ specifies what messages a node sends upon receipt of a new message (as a function of what the node knows: its private input + messages it has seen thus far)

Setup: every node $i$ has its own private input $v_i^*\in V$ (for FLP we can take $V=\{0,1\}$) (as opposed to BB problem, where only sender has a private input) Goals: 1.The Byzantine Agreement problem.Termination:each node eventually halts with some output $v_i$; 2.Agreement:all honest nodes output same $v_i$ (safety property); 3.Validity:ifall honest nodes have the same private input $v^*$, their output $v_i$ is also equal to $v^*$(liveness property).

(again solving 1&2 or 1&3 is pretty easy)

Proposition 1: BB reduces to BA, i.e. BA solution ⇒ BB solution. Proof: […]

Proposition 2: as long as f ≤ n/2, BA reduces to BB, i.e. BB solution ⇒ BA solution. Proof: […]

## The FLP Impossibility result

Theorem.[Fischer-Lynch-Paterson 85’] For every n≥2, even for f=1 no deterministic protocol for Byzantine agreement satisfies Termination+Agreement+Validity in the asynchronous permissined model.

Note: this formally separates what’s possible in synchronous vs asynchronous settings.

**Remark 1:** the type of fault requred is just a crash fault (no need for Byzantine behavior!). But we will be proving this theorem using the Byzantine behavior, to make our lifes easier.

**Remark 2:** impossibility for BA implies impossibility for BB and SMR.

**Remark 3: **goal of all these impossibility result is to understand what fundamental trade-offs we need to make.

**Workarounds:**
- allow randomized protocols (nodes flip coins)
- strengthen assumptions: partially synchronous model (see Lecture 8)

*very long but beautiful proof:*

## Conclusions after the FLP impossibility result

- Impossibility results make clear the compromises + trade-offs required (i.e. Safety vs Liveness is a fundamental trade-off with unbounded msg delays)
- They also clarify which assumptions matter (PKI in synchronous model, synchronous vs asynchronous model)
- They also
*guide*you to the right model for consensus/blockchains porotocols (e.g., partially synchronous model) - The proofs are beautiful, especially the hexagon argument