diff --git a/syllabus/3-Blockchain/10-Designing_DAG_based_consensus-slides.md b/syllabus/3-Blockchain/10-Designing_DAG_based_consensus-slides.md deleted file mode 100644 index 016202a45..000000000 --- a/syllabus/3-Blockchain/10-Designing_DAG_based_consensus-slides.md +++ /dev/null @@ -1,709 +0,0 @@ ---- -title: Designing DAG-based consensus -description: A formal, yet friendly consensus framework ---- - -# Designing DAG-based consensus - ---- - -## Agenda - -
- -1. formalizing the consensus problem and related concepts -2. meeting a framework for designing DAG-based consensus protocols - ---- - -## How can this help? - -
- -It's not very likely that you will design a new consensus protocol from scratch or even implement one... - - - -but it's more likely that you will have to either choose or integrate one with your system. - - - ---- - -## The actual goals - -
- -- identify the key assumptions and limitations of the protocols -- understand the trade-offs between different approaches -- see what consequences the design choices have - ---- - -## What is consensus? - -
- -- a **process** of agreeing on the same result among a group of participants -- a fundamental **problem** in distributed computing -- a key **component** of blockchain technology stack - ---- - -## Consensus features - -
- -liveness, safety, integrity - ---- - -## We have already seen some - -
- -Nakamoto - -Babe - -Grandpa - -Sassafras - -Tendermint - -... - ---- - -## Who is running the protocol? - -
- -Participants, called **nodes** - ---- - -## Nodes - -
- -- nodes can be either honest or malicious -- honest nodes follow the protocol -- malicious nodes can deviate from the protocol in any way they want -- malicious nodes can collude with each other -- malicious nodes can be controlled by an adversary - ---- - -## Public key infrastructure - -
- -- every node has its own private and public key -- every node signs messages with its private key -- every node verifies messages with other nodes' public keys - ---- - -## Public key infrastructure - -
- -authenticated point-to-point communication - ---- - -## Adversary - -
- -Adversary **can** control the network delays, but is _computationally bounded_, i.e. it **cannot** break the cryptography (like forging the signatures). - ---- - -## Network - -
- -Communication via network... but what kind of network? - ---- - -## Network models - -
- -synchronous - -partially synchronous - -asynchronous - ---- - -## Network models: synchronous - -
- -> There exists a known upper bound \\(\Delta\\) on message delivery time. - -
-
- -_Intuition: there's a well-defined notion of a protocol round_ - ---- - -## Network models: asynchronous - -
- -> There is no upper bound on message delay, though delivery is guaranteed. - -
-
- -_Intuition: you can't tell whether a node has crashed or has a long delay_ - ---- - -## Network models: asynchronous - -
- -> There is no upper bound on message delay, though delivery is guaranteed. - -
-
- -- We assume that the adversary has full control over the message delays. -- The concept of a timeout is basically useless. - ---- - -## Network models: partially synchronous - -
- -> There exists a known bound \\(\Delta\\), and an unknown point in time **GST** after which the communication becomes synchronous with a delay \\(\Delta\\). - -
-
- -_Intuition: protocol will eventually work synchronously, but it needs to be safe before_ - ---- - -## Crucial theoretical results - -
- -> [FLP theorem] It is impossible to have a deterministic protocol that solves consensus in an asynchronous system in which at least one process may fail by crashing. - -
-
- -> [Castro-Liskov theorem] It is impossible to have a protocol that solves consensus in a partially synchronous system with \\(3f+1\\) nodes in which more than \\(f\\) processes are byzantine. - ---- - -## Crucial theoretical results - -
- -> [FLP theorem] It is impossible to have a deterministic protocol that solves consensus in an asynchronous system in which at least one process may fail by crashing. - -
-
- -> [Castro-Liskov theorem] It is impossible to have a protocol that solves consensus in a partially synchronous system with \\(3f+1\\) nodes in which more than \\(f\\) processes are byzantine. - ---- - -## Consequence - -
- -The best one can hope for in **asynchronous** scenario is **probabilistic** protocol tolerating **up to** \\(f\\) faults for \\(3f+1\\) participants. - -
- -> ✅ **Doable!** - - - ---- - -## Note on randomness - -
- -Real probability is actually needed in the extremely hostile environment. -In case where the adversary is not legendarily vicious, even a dumb (but non-trivial) randomness source will do. - ---- - -## Responsiveness - ---- - -## Responsiveness - -
- -Protocols that are **not responsive** have to **wait for** \\(\Delta\\) **time** to proceed to the next round. -
- ---- - -## Responsiveness - -
- -Protocols that are **not responsive** have to **wait for** \\(\Delta\\) **time** to proceed to the next round. -
-
- -- \\(\Delta\\) must be long enough to allow all honest nodes to send their messages. -- \\(\Delta\\) must be short enough to allow the protocol to make progress. -- In case of failure, they have to perform a pretty expensive recovery procedure (like the leader change). - ---- - -## Responsiveness - -
- -Protocols that are **responsive** **wait for** \\(2f+1\\) **messages** to proceed to the next round. - -
-
- -> Why \\(2f+1\\)? - - - ---- - -## Responsiveness - -
- -Protocols that are **responsive** **wait for** \\(2f+1\\) **messages** to proceed to the next round. - -
-
- -> Among \\(2f+1\\) nodes, there are at least \\(f+1\\) honest ones, i.e. honest majority. - ---- - -## Responsiveness - -
- -Protocols that are **responsive** **wait for** \\(2f+1\\) **messages** to proceed to the next round. -
-
- -- Asynchronous protocols must be responsive. -- In good network conditions, they significantly much faster. - ---- - -## Checkpoint - -
- -Up to this point, we covered: - -- consensus problem -- node types and adversary -- inter-node communication -- network models (synchronicity) -- protocol limitations in asynchronous network (honesty fraction and the need for randomness) -- responsiveness - ---- - -## Warmup exercise: broadcast - -
- -> (In an asynchronous network) **reliably** send a single message to all other nodes. - -
-
- -- (_validity_) If the sender is honest and broadcasts a message \\(m\\), then every honest node outputs \\(m\\). - - - -- (_integrity_) If an honest node outputs a message \\(m\\), then it must have been broadcast by the sender. - - - -- (_agreement_) If an honest node outputs a message \\(m\\), every other honest node outputs \\(m\\). - - - ---- - -## Reliable broadcast protocol (RBC) - -
- - - ---- - -## Reliable broadcast in practice - -
- -Due to the very high communication complexity we use heuristics or cryptography-based tricks. - ---- - -## Blockchain protocol vs Atomic broadcast - -
- -Atomic broadcast -
- - - ---- - -## Randomness formalized - -
- -Randomness beacon -
- - - ---- - -## Atomic broadcast: timeline - -
- - - ---- - -## Atomic broadcast: timeline - -
- - - ---- - -## Fun fact - -
- -Aleph paper, as the first, also achieved fully asynchronous randomness beacon: - -- with efficient setup (\\(O(1)\\) rounds, \\(O(N^2)\\) communication) -- with \\(O(1)\\) expected rounds to output a random value with \\(O(N)\\) communication per round - ---- - -## Consensus protocols (selection) - -
- - - - -### Classical protocols: - -- [DLS’88], [CR’92], -- PBFT [CL’99] -- Random Oracles … [CKS’05] -- Honey Badger BFT [MXCSS’16] -- Tendermint [BKM’18] -- VABA [AMS’19] -- Flexible BFT [MNR’19] -- HotStuff [YMRGA’19] -- Streamlet [CS’20] -- Grandpa [SKK'20] - - - - -### DAG-based protocols: - -- [L. Moser, P. Meliar-Smith ‘99] -- Hashgraph [B’16] -- Aleph [GLSS’18] -- DAG-Rider [KKNS’21] -- Highway [KFGS’21] -- Narwhal&Tusk [DKSS’22] -- Bullshark [SGSK’22] - - - - ---- - -## DAG-based protocols - ---- - -## DAG - -
- -Directed Acyclic Graph -
- - - ---- - -## How does it relate to consensus? - -
- -Intuition: graph represents the dependencies between messages (units). -
- - - ---- - -## Framework core - -
- -1. We maintain a local DAG representing our knowledge of the units. -2. We perform a local, offline consensus on our DAG. - ---- - -## Framework core - -
- -1. We maintain a local DAG representing our knowledge of the units. -2. We perform a local, **offline consensus** on our DAG. - ---- - -## Framework core (in other words) - -
- -1. (online): sending and receiving units that contribute to the local DAG -2. (offline): everybody performs a local consensus on the DAG, just by looking at it - ---- - -## Clue observations - -
- -- local DAGs might differ... -- but they are guaranteed to converge to the same DAG -- the offline consensus is guaranteed to produce the same result - ---- - -## Adversary control - -
- - - ---- - -## Randomness? Where is randomness? - -
- -It is put into the local consensus protocol. - ---- - -## Relation to the atomic consensus problem - -
- -- nodes receive transactions and put them into units -- nodes send each other their new units -- (locally) nodes come up with a linear ordering of the units and make blocks from chunks - ---- - -## Digression: block production, information dissemination and finalization - -
- -The common approach (e.g. in Substrate): - -- production and dissemination is done in the same layer -- afterwards, nodes perform consensus on finalizing disseminated blocks - -
- -Natural approach for DAG-based protocols: - -- information dissemination happens as 'the first phase' -- block building and (instant) finalization happens locally - ---- - -## Main consequences of the different separation - -
- -- block signatures -- speed - ---- - -## Local consensus: goal - -
- -Local copies might differ significantly, blocks might have not come to all nodes yet, etc... -but we have to make common decision about unit ordering! - ---- - -## Key concept: availability - -
- -Intuitively, a unit is **available** if: - -
- -- most of the nodes have it -- it was distributed pretty promptly (we won't call a unit available, if it finally arrived everywhere after a month) -- most of the nodes know that most of the nodes know that most of the nodes know... that it is available (mutual awareness) - ---- - -## Availability - -
- -If a unit is available, it is a good candidate for being chosen as an 'anchor' in extending current ordering. - ---- - -## Lightweight case study - -
- -Aleph Zero BFT protocol - ---- - -## Head - -
- - - ---- - -## Building blocks - -
- - - ---- - -## Choosing head - -
- - - ---- - -## Availability determination - -
- -Units vote for each other's availability. - ---- - -## (Part of) availability determination - -
- -VoteU(V) = - -- \[\[U is parent of V\]\] if V is from the round just after the round of U -- `0`/`1` if all children of U voted `0`/`1` -- `CommonVote(round(`U`), round(`V`))` otherwise -
-
- -_(U comes from the earlier round than V)_ - ---- - -## Bonus: generating randomness - -
- -Sig`sk`(nonce) - - -
- -
- -- randomness must be unpredictable -- delayed reveal -- must depend on \\(f+1\\) nodes -- cannot be disturbed by the adversary - -
- ---- - -## Standard way - -
- - - ---- - -## Standard way - -
- - - -Problem: need for trusted dealer! - ---- - -## One simple trick - -
- -Everybody is dealing secrets - ---- - -## Combining randomness - -
- - diff --git a/syllabus/3-Blockchain/14-Sassafras-slides.md b/syllabus/3-Blockchain/14-Sassafras-slides.md deleted file mode 100644 index 0881b2e3f..000000000 --- a/syllabus/3-Blockchain/14-Sassafras-slides.md +++ /dev/null @@ -1,198 +0,0 @@ ---- -title: Sassafras Authoring -description: Latest Module for Block Authoring on Polkadot -duration: 35min ---- - -## Sassafras and Semi-Anonymous Single Leader Election - -TODO: Andrew combine these with the authoring slides. You have creative liberty over the authoring ones. Hack them up! If we ever wanna go back there is the git history. - ---- - -# But.. - -- Wait dont we have BABE? - ---- - -# Why replace BABE? - -- Forks are legitimate. -- Why is forking an issue? -- Fun Fact Babe only uses random slot assignment 25% of the time -- Why is this an issue? - -Notes: -Is an issue because falling back on a known ahead of time schedule is vunerable to attacks - ---- - -# Can we do better? - - - - - - -Yes!! Sassafras!! - ---- - -# So what are our goals again? - -- Reduce to no forks(Almost) -- Make slots annonymous(Not known ahead of time) -- Go fast be secure etc.. - -Notes: - -- Does anyone know how we can still have forks no matter what? -- Why do we want that again? - ---- - -# Re-visit - -- Ring Signatures -- VRF -- RingVRF - -Notes: -VRF value is like a pubkey (Publicly known) and can provide -a signature or proof that you produced that random value - ---- - -# Ring Signatures - -- Recall from cryptography -- For a group of size n we can create an annoymous signature from within that group -- Meaning we have a valid signature but from that signature cannot identify which secret in the ring signed the message - -Notes: - -- Ring signatures trade some _non-repudation_ for _privacy_. -- So what do we - ---- - -# VRF - -- For some public input seed and some secret we can produce a random output -- We can then submit a VRF 'signature' or proof that we indeed possess the secret that generated that random output - -Notes: - -VRF value is like a pubkey (Publicly known) and can provide -a signature or proof that you produced that random value - ---- - -# RingVRF - -- We combine these ideas.. -- So we have a VRF output which we generated with 'Some secret'. -- i.e. We know that a Random output was generated by someone in the 'Ring' but we dont know who generated it. -- We can submit a proof saying yes this was indeed us from the ring (i.e. I produced this output) - ---- - -# Why is a RingVRF useful? - -- Answer: Allows us to know someone we know(sort of) has produced a VRFOutput but to not know who. - -Notes: -Sort of because we know that the person is in the Ring - ---- - -# Who will the participants be in the Ring? - - - - - - -Answer: Active consensus participants (Validators) - ---- - -# Tickets - - - - - - - -- A Ticket for the lottery -- Each participant creates a ticket (RingVRFOutput) -- When should we create a ticket? - -Notes: - -1. Lottery being participation in consensus! -2. Tickets should be created and submitted One epoch before the Party begins -3. Why do we want to be a person selected to participate in consensus again? - ---- - -# Submission of tickets - - - - - - - -- Each Participant computes and submits their ticket on-chain - ---- - -## Is there a problem? - -- Question: is there any issue with submitting your own ticket? -- Answer: Annonymity broken!! - ---- - -### Assigning Tickets to slots - -- We want to prevent someone from finding ways to manipulating randomness -- What can happen if a bad actor can get a majority of the slots for an epoch? - -Notes: - Consecutive slots can lead to more biasability in the randomness later down the line - Consecutive slots can cause problems for the network like outages or maliciious long forks - ---- - -# Outside in assignment - -1. `[tick0, tick1, tick2, tick3,.. tickN]` -1. `[tick1, tick3, .., tick2, tick0]` - -Notes: - -1. How does this help? -2. Answer: If you have found a way to get consecutive tickets then it breaks up the consecutive tickets - ---- - -## Claim a slot - -- Question: Now that slot x is up for grabs how do we prove that it is ours? -- Answer: Submit our unique VRF Signature/Proof -- Produce the block!! - ---- - -# Summary - -1. Produce RingVRFoutput(Ticket) one epoch before -1. Send to a friend -1. They post on chain -1. Outputs get assigned to slots randomly(psuedo) -1. When it is your turn submit VRF signature(proof) -1. Build your block and get rewards! - ---- diff --git a/syllabus/3-Blockchain/README.md b/syllabus/3-Blockchain/README.md index cadbc61b8..9979da198 100644 --- a/syllabus/3-Blockchain/README.md +++ b/syllabus/3-Blockchain/README.md @@ -34,10 +34,10 @@ The module is designed to 3 days of contact time lasting about 6-8 hours each da #### Morning -- 🗣️ [Decentralized Systems: Goals and History](./1-Overview_Goals_History-slides.md) -- 🎲 (Optional) [Manual Consensus Game](./Manual_Consenus_Activity.md) +- 🗣️ [Coordination and Centralization: Past, Present, Future](./1-Coordination_And_Centralization-slides.md) +- 🗣️ [P2P Networks](./2-P2P_Networks-slides.md) - ☕ Break -- 🗣️ [P2P Networks and State Machines](./2-P2P_Networks_State_Machines-slides.md) +- 🗣️ [State Machines](./2.5-State_Machines-slides.md) - ⌨️ Begin working on [Blockchain from Scratch](https://github.com/JoshOrndorff/blockchain-from-scratch/) #### Afternoon