diff --git a/syllabus/3-Blockchain/0-Hybrid_Schedule_for_week_two_slides.md b/syllabus/3-Blockchain/0-Hybrid_Schedule_for_week_two_slides.md deleted file mode 100644 index 1986c3675..000000000 --- a/syllabus/3-Blockchain/0-Hybrid_Schedule_for_week_two_slides.md +++ /dev/null @@ -1,139 +0,0 @@ ---- -title: Week 2 - Smart Contracts and Blockchain -description: How the smart contract and blockchain content will be ordered and who is teaching it. -duration: 15 minutes ---- - -# Week Two - -## Blockchain Smart Contracts - ---- - -## Official Schedule - - - -Mon - - - - - - -Tue - - - - - - - -Wed - - - - - - - - -Thu - - - - - - - -Fri - - - - - - ---- - -## Hybrid Schedule - - - -Mon - - - - - - -Tue - - - - - - - -Wed - - - - - - - -Thu - - - - - - - -Fri - - - - - - - ---- - -## Smart Contracts Team - -Notes: - -Teaching today you'll have Lauren, Aaron, Joshy, and Andrew. -Stephen from Moonbeam, Piotr and Filip from Aleph0, will all be here later this week to do some smart contract lectures and activities as well. -The format for this morning will be lecture, activity, break, lecture, activity -After lunch it will be the same: lecture, activity, break, lecture, and activity! - ---- - -## Blockchain Team - -Notes: - -Then tomorrow Josh, Andrew, and Maciej will go from Smart Contracts to Blockchain things. Remember we're bouncing back and forth during the week, continuously building on the content and our definitions. -But we'll continue to follow that same format of lecture then activity, lecture and activity and so on. -I should caveat and share that Joshy and I both prior teachers, so we're big fans of hands on activities. We feel it's the opportunity to put your learning into practice. We don't want to be up here the entire time talking at you. We want you to be able to get your hands dirty and get into the code. - ---- - -## New Content Warning - -> Cambridge-y (adj) - Overall good quality, but with rough edges or imperfections. Especially when related to PBA content. - -Notes: - -This is the third edition of the PBA. -That means a lot of our content is pretty polished and honed. -Whereas a year ago when we did this for the first time in Cambridge, a lot of stuff was, well, kinda Cambridge-y. - -But this smart contract content is actually brand new. -In the past we had a very short module at the end of the course specifically about writing ink! smart contracts. -This time we have moved it much earlier to emphasize the impact smart contracts can have on society, and why blockchains are so important for their success. -We also take a broader view, looking not only at ink!, but also at the EVM, Solidity, and Vyper. - -We have put a lot of love into this content, and we hope you'll enjoy it and give us constructive criticism to make it less Cambridge-y next time. diff --git a/syllabus/3-Blockchain/1-Overview_of_Blockchains_slides.md b/syllabus/3-Blockchain/1-Overview_of_Blockchains_slides.md index f0e88988d..7f44c7f54 100644 --- a/syllabus/3-Blockchain/1-Overview_of_Blockchains_slides.md +++ b/syllabus/3-Blockchain/1-Overview_of_Blockchains_slides.md @@ -6,6 +6,15 @@ duration: 30 - 45 minutes # Overview of Blockchains +TODO Joshy + +Braindump for the structure of this lesson for HK: + +- Shared Story Telling +- Digital Services +- Broad def of smart contract +- State Machines + --- ## Upholding Expectations 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 7df05598e..000000000 --- a/syllabus/3-Blockchain/10-Designing_DAG_based_consensus_slides.md +++ /dev/null @@ -1,685 +0,0 @@ ---- -title: Designing DAG-based consensus -description: A formal, yet friendly consensus framework ---- - -# Designing DAG-based consensus - ---- - -## Goals of this lecture - -
- -1. formalize the consensus problem and related concepts -2. provide a framework for designing DAG-based consensus protocols - ---- - -## 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/11-Unstoppable_Applications_slides.md b/syllabus/3-Blockchain/11-Unstoppable_Applications_slides.md deleted file mode 100644 index e012b6057..000000000 --- a/syllabus/3-Blockchain/11-Unstoppable_Applications_slides.md +++ /dev/null @@ -1,988 +0,0 @@ ---- -title: Unstoppable Applications -description: Unstoppable Applications in Web3 -duration: 1 hour ---- - -# Unstoppable Applications - -Notes: - -Much like tokenomic design, that is a large component in unstoppable apps that incorporate cryptocurrency or other motivating factors, this lesson is far far too short to give you all the tools and techniques to make a robust DApp design. - -Instead we strive to highlight the problem space we face and some classes of solutions to them. - ---- - -## Motivation - -So far, we have discussed state machines and consensus... in _isolation_. - -Does the _contexts in which they operate within_ matter? - -Notes: - -- So far _mostly_ on simplified, idealized systems. - - "Black boxes" of cryptography - - Rational actors and assumed complete models of behavior in economics - - Blockchains as an "[isolated system](https://en.wikipedia.org/wiki/Isolated_system)" of sorts - external systems _cannot_ be reasoned about in the same way... - We will talk about the Oracle Problem. -- In _practice_ there are far more ["unknown unknowns"](#🙈-unknown-unknowns) and "black swan" behavior. - More to come on that in this lesson. - ---- - - - -## Discussion - -> What properties of a system make it "stoppable"? - -Notes: - -- Web2 context: central providers & authorities, ... -- Web3 context: decentralized, ... -- What properties of a system make it "stoppable"? - ---- - -### Unstoppable Apps Properties - - - -- Anitfragile -- Trustless\* -- Censorship-less\* -- Accessible\* -- ...perhaps more? - - - -Notes: - -The "\*" indicates the Web3 context for defining properties, not generally. -Not all of these can apply, nor is is possible all simultaneously apply. -We need to craft the system properties based on what we must achieve. -In reality we strive for Absolute Unstoppability, but likely cannot grantee it in _every possible scenario_. - ---- - -## Anitfragile - - - -
- -> Some things benefit from shocks; they thrive and grow when exposed to volatility, randomness, disorder, and stressors and love adventure, risk, and uncertainty. -> Yet, in spite of the ubiquity of the phenomenon, there is no word for the exact opposite of fragile. -> Let us call it antifragile. -> Antifragility is beyond resilience or robustness. -> The resilient resists shocks and stays the same; the antifragile gets better. -> -> -- [Antifragile]() -- - -
- - - - - - - -Notes: - -- Read Antifragile quote, recommend book recommended, see the links throughout slides for more after class. -- Hydra fable & lore: https://en.wikipedia.org/wiki/Lernaean_Hydra - even though can be almost completely destroyed, it is _resilient_ and recovers. - Absolutely Unstoppable doesn't mean it cannot be damaged or even paused temporarily, it means it cannot cease to exist and will eventually recover, and ideally come back stronger in doing so. - ---- - -## An N-lemma - -Hypothesis: a _absolutely_ Unstoppable App cannot exist. - -We must make trade-offs out of all N properties
that a _absolutely_ Unstoppable App would possess. - - - - - - - - - - -Notes: - -As with crypto, we can have astronomically good odds... -But they are not perfect. -We want the most robust system possible, given the _environment and context_ the consensus system lives in. - -More relevant trilemma: - -- [Scalability](https://cointelegraph.com/news/sharding-could-resolve-ethereum-scalability-trilemma-says-researcher) -- [Zooko's Triangle](https://en.wikipedia.org/wiki/Zooko's_triangle) (Network IDs) -- More likely! - ---- - -## Web3 Tech Stack - - - -Notes: - -This diagram is a bit dated with advancements in the field, but a good approx. -representation. - -Observation and clarification: DApps canonically refer to smart contract applications. -These exist _within the context_ of consensus systems that themselves inherit properties of unstoppability from. -The academy is more focused on _consensus system engineering_ - we reason about blockchains themselves - rather than "DApp"s that _use_ those as platforms to operate in or on. -The Smart contracts lessons _may_ include detains on unstoppable dapps design considerations. - - - - ---- - -## Much More Than Blockchain Architecture... - - - - -Blockchains only form one part of the stack. - -Web3 applications must prevent attacks at all layers. - - - - - - -- Networking -- Consensus -- Node access -- Validator power -- Inter-consensus trust -- _Human factors_ -- _Extrinsic factors_ - - - - - -Notes: - -These are for discussion today, but there are _many more_ thank those listed here! - ---- - - - -# Human Level - ---- - -## Attacking Web3 - - - -Notes: - -Key point: your "perfect" system in is likely weak to things outside of the "rules"! -especially - -Image Source: https://xkcd.com/538/ - ----v - -## Web3 Criticisms - - - - -There are [valid criticisms](https://moxie.org/2022/01/07/web3-first-impressions.html) of how many Web3 apps operate today. - - - - - - -- Humans are cheap & lazy...
- No individuals run servers. -- RPC node providers -- A _protocol_ improves
slowly vs. a platform. -- False marketing,
frauds, & scams! - - - - - -Notes: - -https://moxie.org/2022/01/07/web3-first-impressions.html great critique on the state of the space, but founder of [Signal messenger](https://signal.org). - -Not all hope is lost! -This is valid mostly in the present, we will discuss these and what we're building to realize a better stack. - - - ---- - - - -# Systems Level - ----v - -## Prove it! - -We use the word "proof" a lot...
it means many things in [different contexts](https://en.wikipedia.org/wiki/Provable): - - - -- Math → **Provable Correct** (algo) -- Consensus → Proof of X (security) -- Crypto → \[ZK | VRF | Validity | ... \] Proofs - - - -Notes: - -The one so far not covered is Provable Correctness - where we can use maths to _prove_ that our logic cannot do unexpected behavior. -An interesting example is [Cardano's design value proposition](https://docs.cardano.org/explore-cardano/cardano-design-rationale) using haskell and provably correct most parts of their platform. - -> We have a lesson and exercise on formal verification methods latter on - this is how we can approach Provable Correctness in the context of Rust and thus Substrate. - -BUT this property assumes a complete system model! -Nuke proposes that when considering factors outside the consensus system, there cannot be a rigorous proof of correctness as we cannot model the universe. - ----v - -## 🔮 Oracle Problem - -An [oracle](https://en.wikipedia.org/wiki/Category:Computation_oracles) provides eternal data to a consensus system.
(i.e. a partial state of an external chain) - -The [oracle problem](https://blog.chain.link/what-is-the-blockchain-oracle-problem/) relates to the _trust_ in the oracle. - -Notes: - -- Example: Random Oracle, NOT like VRF we saw in the crypto module that can be in the consensus system. -- Oracle needed for _input_ from anything that lives outside of the boundary of the consensus system. - - Everything in a chain is self-referential. - Applications in a consensus system may want to _try_ and reason about something outside itself. -- Inclusive of bridges -- https://blog.chain.link/what-is-the-blockchain-oracle-problem/ - ----v - -## 🦢 Black Swans - - - -- known bounds of operation
_assumed_ impossible -- death spirals - - - -Notes: - -Explain example of luna or other system collapse. - -- 📔[The Black Swan: The Impact of the Highly Improbable](https://en.wikipedia.org/wiki/The_Black_Swan:_The_Impact_of_the_Highly_Improbable) -- [Wiki Black Swan Theory](https://en.wikipedia.org/wiki/Black_swan_theory) - ----v - -## 🤯 Complexity - - - - - - - - - -- Illustrating how to map the intricacies of _coupled, complicated, interactions of systems_. -- \* You are not expected to understand this plot 😅 - - - - -Notes: - -- Great talk by the author: https://www.youtube.com/watch?v=S3REdLZ8Xis reference talk by book author. - -Example: irrational actors can be represented in a very simple model as a completely random act, or opposite act of what a rational actor would do. If you "fuzz" you system you may discover fragility to irrational actions that could undermine your system. Perhaps it's far easier and more likely than it at first appears to experience a black swan event. - -- Image [source](https://en.wikipedia.org/wiki/Nassim_Nicholas_Taleb#/media/File:Genealogy_map_of_topics_treated_by_Nassim_Taleb.jpg) - Describes the various categories of uncertainty, epistemology limits and statistical subjects touching on Taleb's Black swan / antifragility etc. ideas - ----v - -## 👪 Dependency - - - - - - - - - -- [Confusion](https://secureteam.co.uk/news/what-is-a-dependency-confusion-attack/) -- [Hijacking](https://blog.sonatype.com/bladabindi-njrat-rat-in-jdb.js-npm-malware) -- [Hardware side-channel attacks](https://hackaday.com/2019/09/13/side-channel-attack-shows-vulnerabilities-of-cryptocurrency-wallets/) - - - - -Notes: - -- yes in software and hardware, you are at risk of attack from poisoned deps through non-maintenance, up to targeted exploitation. - One mitigation is vendoring these, need systems inn place to monitor. - Dependabot is not sufficient. -- Also in dependance on specific operational contexts. - For example that it is legal to operate the software for nodes. - -Image source: https://xkcd.com/2347/ - ----v - -## 🦸 Dependency in Polkadot - - - - - - - - - -> _Foundational_ to Polkadot ecosystem! - - - - -Notes: - -- [Jaco](https://github.com/jacogr) is effectively the only maintainer of how _just about everything_ communicates with Substrate nodes! -- [Capi](https://github.com/paritytech/capi) is on the way, but just getting started. - ----v - -## 🙈 Unknown unknowns - - - -Notes: - -Outside of the system itself, we cannot guarantee/prove that every possible condition is accounted for in our models & system design. -We must expect forces outside our system & it's model may interact in unexpected ways. -Assumptions about context must be rigorously evaluated (i.e. - what does finality mean in the chain this pallet or contract lives in?) -(Formal mathematical proofs reason only about the things we can and do account for.) - ---- - - - -# Network Level - ----v - -## 🕸️ Peer-to-Peer Networks - - - ----v - -## Network Attacks - - - -- Entry/Boot nodes and peer discovery -- Data center faults -- Traffic analysis and targeted takedowns -- Eclipse attacks - - - -Notes: - -The network lesson covers these, just a reminder that the network is not in the direct command of the consensus system, so it's a threat! - -- security & stability -- privacy! - On chain might be ZK, but how about the gossip and RPCs? - -Boot nodes typically _hard coded_ to "bootstrap" and start peer discovery. -Boot nodes can decide what peers to advertize, or can be inaccessible. -Common data centers (AWS, GCP, ...) could fail or censor, potentially large number of peers go dark. -Hard to hide! Most p2p traffic is easy to identify vs. web2 traffic. - ----v - -## Node Queries - -Running a node is hard, most people outsource. - - - -These service have power to deceive, censor, and surveil. - ----v - -## Multi-Chain Applications - -If running _one_ node is burdensome, try multiple. - - - ----v - -## Trustless Messaging - -In order to handle messages _without trust_,
systems must share common finality guarantees. - -`A` should never process a message from `B`,
where `B` is reverted and `A` is not. - ----v - -## A Note on Synchronicity - -Smart contracts on a single chain (e.g. Ethereum)
can interact trustlessly because of their shared view of finality. - -Asynchronous systems can also share finality.
-i.e., be members of the same consensus system. - ----v - - - -# Discussion - -**Minimum viable decentralization.** - -> What key aspects should be considered? - -Notes: - -- Quantitative: nodes needed (for what), incentives, ... FIXME TODO -- Qualitative: social norms, ... FIXME TODO - ---- - - - -# Consensus - ----v - -## Mining Pools - -Proof of Work authority sets have no finite bound.
-But people like to organize. - -\[Collaborating | Colluding\] authority sets creates risk. - -Notes: - -Call out that Nomination pools exist and are discussed in the NPoS lesson latter. -Similar issues, but in a more bounded set. - ----v - -## Mining Pools - - - -Notes: - -Source: [Buy Bitcoin Worldwide](https://www.buybitcoinworldwide.com/pages/mining/pools/img/pool-graph.png) - ----v - -## Security Dilution - -Security is always a finite resource: - - - -- Centralized: Cost of corruption/influence -- Proof of Work: Number of CPUs in the world -- Proof of Stake: Value (by definition, finite) - - - ----v - -## Security Dilution - -Consensus systems compete for security,
and they have reason to attack each other. - -Emergence of obscure/niche "Proof of X" algorithms
to shelter from attack only goes so far. - ----v - -## ⚔ Blockchain Wars - -Systems with high security have the
incentive to attack systems with low security
whom they perceive as competitors. - -> For fun and profit. - -Notes: - -"In ~~a galaxy~~ the universal consensus ~~far far away~~ not so far away..." - ----v - -## ⚔ Proof of Work Battles - - - -> What might it cost to successfully attack? - -Notes: - -- For PoW, hashing power for the same algo can be attacked! - Buying hash power is possible: -- Most GPU miners switch tasks to the mine the highest paying (relative to some base currency) chain using software like https://www.nicehash.com/. -- ASICs are less flexible, but also can to the highest paying coin. -- Example: [ETH classic deep re-ogs](https://coingeek.com/ethereum-classic-experiences-51-attack-and-3000-block-reorg/) - ----v - -## Proof of...
Nothing at Stake - -Forks are "free" to vote in favor of...
-vote on them all! - -(If you are not eventually slashed!) - -> What might it cost to successfully attack? - -Notes: - -- Unlike PoW where voting on a chain costs something _extrinsic_ to the system, PoS has only _intrinsic_ measures to do accounting of consensus rules. -- **Critical:** This was a problem with early naive implementations of PoS. - Modern PoS schemes avoid this specific problem by having the security deposit and slashing for equivocation (in a few slides) -- Good explainer, source of image: https://golden.com/wiki/Nothing-at-stake_problem-639PVZA - ----v - -## Proof of...
_Relatively_ Nothing at Stake - -Risk-to-reward ratio of attacks is
_relative to the valuation of the staked assets_. - -Rational actors take into account
_extrinsic motivators_ in calculating the highest reward. - -> What might it cost to successfully attack? - -Notes: - -- Again PoS ha only _intrinsic_ measures to do accounting of consensus rules, but the system doesn't exist in a vacuum: the relative valuation of what is at stake needs to be accounted for. - ----v - -## Validator Consolidation - -How many validators does a system need? - -Higher numbers should lead to a decrease in the ability for entities to collude. - -But validators are expensive, both economically and computationally. - -Notes: - -Yet another N-lemma to consider. - ----v - -## PoS Economic Security - -Proposition: The upper bound of economic security in PoS is relative valuation can secure, that is correlated with the market capitalization of the network. - -> Market capitalization refers to the total market value of all assets inherent to a single company/chain/token. - -Notes: - -- This market capitalization could be company shares, or total ETH in existence, or total X token associated with a specific smart contract or parachain. - ----v - -## ⚔ PoS Economic Security Battles - - - -Notes: - -Here like in PoW we have relative safety in networks, but there is no way to "hop" from one chain to another, so the war is still in the relative security, but one stake cannot _directly_ attach another stake in a separate consensus system... - -What about an system of value _within_ consensus? - ----v - -## DApp PoS Economic Security - - - -Notes: - -Consideration: these notes are an oversimplification! We may talk more about this kind of problem in NPoS lesson (Nuke thinks at least). -The details of a formal analysis are out of scope for this Academy. - -Proposition: Total applications valuation of their assets (tokens on smart contracts, or parachains) is limited and that limit is correlated with the total economic security of the consensus system they reside in. - -In Polkadot's relay chain model, Nuke would argue it's feasible that an attack to extract value from a very highly valued asset could outweighs the cost of obtaining a _byzantine level of stake_ to execute. -Therefore the sum of all parachains market cap is also limited as that same level of stake control would enable take over of all chains on it. - -Nuke argue this is the same for the sum of all contracts valuations on something like Ethereum. - ----v - -## Authority Misbehavior - - - -- Equivocation - - Authorship: Proposing mutually
exclusive chains - - Finality: Voting for mutually
exclusive chains to be final -- Invalidity -- Lack of availability -- **Intentional protocol abuse** ([selfish mining](https://golden.com/wiki/Selfish_mining_attack-39PMNNA)) - - - -Notes: - -We already talked consensus faults, but abuse is newer. -Nuke argues "abuse" as a term here isn't the intended mechanism design, and is adverse to the health of the system. -Selfish mining where it's impossible to _prove_ an author is withholding valid blocks to "cheat" by mining ahead of the rest of th network is a good example in the class of attacks that consensus authorities and others may have. - -...Could other actors abuse the protocols? - ----v - -## Accountability of Authority - -Authority should imply accountability. - -No matter how you design an authority selection mechanism, some people will have a privileged position within it. - -Those who _choose_ to become authorities should be liable for their actions. - ----v - -## Provability and Equivocation - -Some types of misbehavior are harder to prove than others. - -**Equivocation** is simple:
Someone can just produce two signed messages as cryptographic proof. - -Others rely on challenge-response games and dispute resolution. - -Notes: - -Nothing at stake solution, with the possible caveat of long range attacks. [Weak subjectivity](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity) can still potentially cause the same behavior in a much harder to orchestra way, with bad actors having already have their stake released to produce a valid, finalized fork. - ----v - -## Design Considerations
in Polkadot - -- More validators increases the state transition throughput of the network: parachains. -- Individual shards have full economic freedom by being members of a larger consensus system. -- _Superlinear_ slashing puts colluding validators at existential risk,
while well-meaning ones should have little to worry about). - -Notes: - -A few interesting design decisions in Polkadot's architecture. - -We will cover polkadot much more in depth latter! - ----v - -## Transaction Censorship and Ordering - -Block authors choose the transactions they include and in what order. - - - -- Censorship attacks -- "Maximal extractable value" (MEV) - - - ----v - -## Web3 Goal: Non-Censorship - -There are a lot more system users than system authorities. - -However, every transaction must be included by an authority. - -If no authority will include a user's transaction, they do not have _permissionless_ access. - -_If any authority (author) decides not to censor, it **may** be included._ - -Notes: - -Most present systems have no mechanism to penalize censorship, and a much harder problem can be the ability to discover this is happening on the network at all, depending on the actors involved. - ----v - -## Maximal Extractable Value (MEV) - -A measure of the value that block authors can extract based on their knowledge of pending transactions and ability to order them. - - - -- Frontrunning -- Backrunning -- Sandwiching - - - -> https://www.mev.wiki/ - -Notes: - -Emergent behavior. -Not realized as possible by many until it quietly became the norm. - ----v - -## Maximal Extractable Value - -> An environment in which detection means certain death...
-> ...identifying someone’s location is as good as directly destroying them.

-> -- [Ethereum is a Dark Forest](https://www.paradigm.xyz/2020/08/ethereum-is-a-dark-forest) -- - -Notes: - -Tell the story of this article, basically a white hat engineered obfuscation to try and remove funds in a bugged contract -> someone decoded, realized extractable valued, and front-ran them. - -This is now the norm on Ethereum at least, and further _it's becoming institutionalized_. - - - ----v - -## 👼 Flashbots - -> Flashbots is a research and development organization formed to mitigate the negative externalities posed by Maximal Extractable Value (MEV) to stateful blockchains, starting with Ethereum.

-> -- [Flashbots](https://www.flashbots.net/) -- - -Notes: - -This might be misleading, in that they are profiting in making MeV more effective and institutionalized! - ----v - -## Flashbots 😈 - -- **Flashbots Auction**: a marketplace for transaction ordering including the Flashbots Relay and MEV-Geth. -- **MEV-Boost**: an out-of-protocol implementation of proposer-builder separation (PBS) for proof-of-stake Ethereum. -- **Flashbots Protect**: an rpc endpoint that anyone can use for protection from frontrunning and failed transactions. -- **Flashbots Data**: tools and dashboards to improve the transparency of MEV activity on Ethereum and the Flashbots Auction. - -Notes: - -Centralizing force, as information asymmetry generally drives towards a monopoly on MeV. -Competitive landscape for this exists, and to Flashbots' credit, they seem genuine in trying to help the health of Ethereum by decentralizing... - -(BUT FIRST a discussion!) -Especially in light of recent OFAC pressures revealing fragility in the system... - ----v - - - -# Discussion - -Front-running as a Service (FaaS) & MEV Auctions (MEVA) - -_A solution or crutch?_ - -Notes: - -- Flashbots & Friends - ----v - -## Compliance - - - -Notes: - -https://cryptoslate.com/op-ed-is-ethereum-now-under-u-s-control-99-of-latest-relay-blocks-are-censoring-the-network/ - -- code is unstoppable, but platform _can_ sensor. ability -> responsibility (we may talk more on that latter) - ----v - -## Social Context - -Social systems and norms can help _cover up_ weaknesses in protocols. - -> Public monitor to shame OFAC censors:
> https://www.mevwatch.info/ - -Notes: - -- Pressure from peers through breaking norms, perhaps even losing of authority in consensus due to this. - Peer reputation in computer networks, and here also in human ones. -- Sometimes social pressures are healthy for the system, sometimes toxic depending on point of view and who benefits! -- In monero "run your own node" culture helps keep it decentralized.
- Bitcoin big block wars show social pressures help decide the canonical forks. -- Normalizing MEV for the profit of middlemen, providing extraction services in the worst case. - ----v - -## Unbundling - - - -Notes: - -From before, but here point out how this is getting more fine grained as well, and where a single actor would do it all (early bitcoin for example) we are moving more and more to appear. - -- Especially if more things like MeV can be enhanced by doing so. -- This introduces more complexity and interfaces that can provide weakness (especially when a network is required!) - ----v - -## Unbundling - -### _The vision of "blockspace" leads
more and more to this end_ - ----v - -## Diversity - - - -Notes: - -- Parity saved ETH (alt clients, and diversity) - - same runtime on chain, it's impossible to have an alt runtime. -- all on GCP -- All run same hardware (CPU, etc.) -- ... - -- Image source, and good reference on this: https://mirror.xyz/jmcook.eth/S7ONEka_0RgtKTZ3-dakPmAHQNPvuj15nh0YGKPFriA - ---- - -## Final Thoughts - -- Complexity generally increases the risks of failures, but we should not fear it.
- $~~~$_Hypothesis: this \_usually_ makes systems more brittle.\_ -- Observable behavior trumps models and theory.
- $~~~$_Complex systems are not intuitive and may show your assumptions and models are wrong!_ -- This lesson was a _start_ down holes... - $~~~$_We encourage you to keep diving deeper!_ - -Notes: - -- Risks and unknown unknowns increase exponentially so in many cases. -- Examples of observables in things like MEV OFAC dominance and Babe fallback dominance etc. -- Looking forward to explore the great unknown horizons in Web3 together! - ---- - -## 🤝 Together, into the Deep - - - ---- - - - -# Questions - ---- - - - -# Additional Slides - -Notes: - -For reference mostly, outside of formal class time 😀 - ---- - -## Governance... Unstoppable? - - - -[Unstoppable Code: The Difference Between Can't and Won't](https://www.youtube-nocookie.com/embed/Q6euy5W1js4) - -Notes: - -Watch _after class_! -Perhaps assigned informally to everyone to watch in the next few days. - ----v - -## Unstoppable Code - -> It seizes power from dominate forms of power: governments, corporations, states, associations, cultures, religions. -> It seizes power, from these big things and gives it to little people. -> And sooner or later, the people who are losing their undeserved, abusively applied power will start to fight back. -> And at that point, we will start to find out how unstoppable our code is.

-> -- Andreas Antonopoulos -- - ----v - -## Can't vs. Won't - -> The moment you go over the the line from "can't to won't, what started as an ability becomes a responsibility. -> And then if you claim that you don't have the ability anymore, that responsibility just became negligence, criminal negligence.

-> -- Andreas Antonopoulos -- - -Notes: - -- The difference? -- Silk road founder getting 2 life sentences + 40 years. -- moral relativism -> "who's law?" -- Don't make your "oops clause" -> not too narrow. - ---- - -## DAOs - -Decentralized Autonomous Organizations ([DAOs](https://www.investopedia.com/tech/what-dao/)). - -> A **coordination** mechanism. - ----v - -## Democratic Systems - -Democratic Mediums is a directory of patterns
for decision, deliberation, and noise. - - - -- https://medlabboulder.gitlab.io/democraticmediums/ -- https://metagov.org/ -- weekly seminar -- https://www.smartcontractresearch.org/ - - - -Notes: - -Very much encouraged to explore after class! -Many novel and niece definitions in this wiki. - ---- - -## Modeling Behavior - -> [Token Engineering](https://tokenengineeringcommunity.github.io/website/)
-> {especially the Academy & cadCAD Edu} - -Notes: - -Mostly free education and tools to dive deeper on tokenomics. -Remember, these are _models_ of idealized systems in general, real world conditions will differ! diff --git a/syllabus/3-Blockchain/12-UTXO-privacy-slides.md b/syllabus/3-Blockchain/12-UTXO-privacy-slides.md deleted file mode 100644 index 4238781d1..000000000 --- a/syllabus/3-Blockchain/12-UTXO-privacy-slides.md +++ /dev/null @@ -1,115 +0,0 @@ ---- -title: Adding Privacy to the UTXO model -description: Explore some techniques for adding privacy to the UTXO model -duration: 30min ---- - -# Adding Privacy - ---- - -## Input/Output-based Cryptocurrencies - -- Transactions have a list of unspent transaction outputs (UTXOs) as its inputs -- Each input is signed -- The transaction is allowed to spend as much funds as the sum of its inputs -- The transaction spends funds by creating outputs and by paying a fee - ---- - -## Input/Output-based Cryptocurrencies - -- Inputs must only refer to actually existing outputs (membership) -- The output spent must not be prior spent (linkability) -- The output's owner must consent to this transaction (ownership) -- The transaction's inputs and outputs must be balanced (sum check) - ---- - -## Bitcoin - -- Bitcoin specifies the spent output. This satisfies membership and linkability -- Each Bitcoin output has a small, non-Turing complete program (Script) specifying how it can be spent -- Each input has a `scriptSig` which proves the script is satisfied and this is an authorized spend (ownership) -- The outputs cannot exceed the inputs, and the remainder becomes the fee (sum check) - ---- - -## ZK Proofs - -- ZK-SNARKs - A small proof that's fast to verify (<= $O(\sqrt{n})$) -- ZK-sNARKs - A small proof that's not fast to verify (>= $O(n)$, frequently $O(n log n)$) -- ZK-STARKs - A small proof that's fast to verify, based on hash functions -- All of these can prove the execution of an arbitrary program (via an arithmetic circuit) -- None of these reveal anything about the arguments to the program - ---- - -## Merkle Proofs - -- Merkle proofs support logarithmically proving an item exists in a tree -- For 2\*\*20 items, the proof only requires 20 steps -- Even if a ZK proof is superlinear, it's a superlinear encoding of a logarithmic solution - ---- - -## Private Membership - -- When an output is created on-chain, add it to the Merkle tree -- When an input specifies an output, it directly includes the output it's spending -- It also includes a Merkle proof the output exists _somewhere_ on chain, embedded in a ZK proof - ---- - -## Pedersen Commitments - -- A Pedersen commitment has a value (some number) and a mask (also some number) -- There's as many masks as there private keys, hiding the contained value -- Pedersen commitments can be extended to support multiple values - ---- - -## A New Output Definition - - - -- ID -- Amount -- Owner -- Mask -- All in a single
- Pedersen commitment - - - ---- - -## Private Membership - -- We don't prove the included output exists on chain -- We prove an output with identical fields exists on chain _yet with a different mask_ -- This allows spending a specific output without revealing which it is - ---- - -## Ownership and linkability - -- A ZK proof can take the output ID and apply some transformation -- For every output ID, the transformation should output a single, unique ID -- Not just anyone should be able to perform this transformation -- This provides linkability, and if only the owner can perform the transformation, ownership - ---- - -## Sum check - -- One final ZK proof can demonstrate the sum of inputs - the sum of outputs = fee -- There are much more efficient ways to prove this - ---- - -# Summary - -- This hides the output being spent and the amounts transacted -- Combined with a stealth address protocol, which replaces addresses with one time keys, it hides who you're sending to as well -- This builds a currency which is private w.r.t. its on-chain transactions diff --git a/syllabus/3-Blockchain/7-P2P_Networking_slides.md b/syllabus/3-Blockchain/2-P2P_Networking_slides.md similarity index 100% rename from syllabus/3-Blockchain/7-P2P_Networking_slides.md rename to syllabus/3-Blockchain/2-P2P_Networking_slides.md diff --git a/syllabus/3-Blockchain/2-Blockchain_Structure_slides.md b/syllabus/3-Blockchain/3-Blockchain_Structure_slides.md similarity index 100% rename from syllabus/3-Blockchain/2-Blockchain_Structure_slides.md rename to syllabus/3-Blockchain/3-Blockchain_Structure_slides.md diff --git a/syllabus/3-Blockchain/3-Consensus-Authoring-slides.md b/syllabus/3-Blockchain/4-Consensus-Authoring-slides.md similarity index 100% rename from syllabus/3-Blockchain/3-Consensus-Authoring-slides.md rename to syllabus/3-Blockchain/4-Consensus-Authoring-slides.md diff --git a/syllabus/3-Blockchain/9-Econ_and_Game_Theory_in_Blockchain_slides.md b/syllabus/3-Blockchain/5-Econ_and_Game_Theory_in_Blockchain_slides.md similarity index 100% rename from syllabus/3-Blockchain/9-Econ_and_Game_Theory_in_Blockchain_slides.md rename to syllabus/3-Blockchain/5-Econ_and_Game_Theory_in_Blockchain_slides.md diff --git a/syllabus/3-Blockchain/4-Accounts_and_UTXOs_slides.md b/syllabus/3-Blockchain/6-Accounts_and_UTXOs_slides.md similarity index 54% rename from syllabus/3-Blockchain/4-Accounts_and_UTXOs_slides.md rename to syllabus/3-Blockchain/6-Accounts_and_UTXOs_slides.md index 33479b864..8d4f33efd 100644 --- a/syllabus/3-Blockchain/4-Accounts_and_UTXOs_slides.md +++ b/syllabus/3-Blockchain/6-Accounts_and_UTXOs_slides.md @@ -232,6 +232,118 @@ Parallelization? Storage space, privacy solutions? --- +# Adding Privacy + +--- + +## Input/Output-based Cryptocurrencies + +- Transactions have a list of unspent transaction outputs (UTXOs) as its inputs +- Each input is signed +- The transaction is allowed to spend as much funds as the sum of its inputs +- The transaction spends funds by creating outputs and by paying a fee + +--- + +## Input/Output-based Cryptocurrencies + +- Inputs must only refer to actually existing outputs (membership) +- The output spent must not be prior spent (linkability) +- The output's owner must consent to this transaction (ownership) +- The transaction's inputs and outputs must be balanced (sum check) + +--- + +## Bitcoin + +- Bitcoin specifies the spent output. This satisfies membership and linkability +- Each Bitcoin output has a small, non-Turing complete program (Script) specifying how it can be spent +- Each input has a `scriptSig` which proves the script is satisfied and this is an authorized spend (ownership) +- The outputs cannot exceed the inputs, and the remainder becomes the fee (sum check) + +--- + +## ZK Proofs + +- ZK-SNARKs - A small proof that's fast to verify (<= $O(\sqrt{n})$) +- ZK-sNARKs - A small proof that's not fast to verify (>= $O(n)$, frequently $O(n log n)$) +- ZK-STARKs - A small proof that's fast to verify, based on hash functions +- All of these can prove the execution of an arbitrary program (via an arithmetic circuit) +- None of these reveal anything about the arguments to the program + +--- + +## Merkle Proofs + +- Merkle proofs support logarithmically proving an item exists in a tree +- For 2\*\*20 items, the proof only requires 20 steps +- Even if a ZK proof is superlinear, it's a superlinear encoding of a logarithmic solution + +--- + +## Private Membership + +- When an output is created on-chain, add it to the Merkle tree +- When an input specifies an output, it directly includes the output it's spending +- It also includes a Merkle proof the output exists _somewhere_ on chain, embedded in a ZK proof + +--- + +## Pedersen Commitments + +- A Pedersen commitment has a value (some number) and a mask (also some number) +- There's as many masks as there private keys, hiding the contained value +- Pedersen commitments can be extended to support multiple values + +--- + +## A New Output Definition + + + +- ID +- Amount +- Owner +- Mask +- All in a single
+ Pedersen commitment + + + +--- + +## Private Membership + +- We don't prove the included output exists on chain +- We prove an output with identical fields exists on chain _yet with a different mask_ +- This allows spending a specific output without revealing which it is + +--- + +## Ownership and linkability + +- A ZK proof can take the output ID and apply some transformation +- For every output ID, the transformation should output a single, unique ID +- Not just anyone should be able to perform this transformation +- This provides linkability, and if only the owner can perform the transformation, ownership + +--- + +## Sum check + +- One final ZK proof can demonstrate the sum of inputs - the sum of outputs = fee +- There are much more efficient ways to prove this + +--- + +# Summary + +- This hides the output being spent and the amounts transacted +- Combined with a stealth address protocol, which replaces addresses with one time keys, it hides who you're sending to as well +- This builds a currency which is private w.r.t. its on-chain transactions + +--- + ## Small shill... Tuxedo 👔 > diff --git a/syllabus/3-Blockchain/13-Forks_slides.md b/syllabus/3-Blockchain/7-Forks_slides.md similarity index 100% rename from syllabus/3-Blockchain/13-Forks_slides.md rename to syllabus/3-Blockchain/7-Forks_slides.md diff --git a/syllabus/3-Blockchain/5-Consensus_Finality_slides.md b/syllabus/3-Blockchain/9-Consensus_Finality_slides.md similarity index 100% rename from syllabus/3-Blockchain/5-Consensus_Finality_slides.md rename to syllabus/3-Blockchain/9-Consensus_Finality_slides.md diff --git a/syllabus/3-Blockchain/Outline_Hybrid.md b/syllabus/3-Blockchain/Outline_Hybrid.md deleted file mode 100644 index 7cf0292fa..000000000 --- a/syllabus/3-Blockchain/Outline_Hybrid.md +++ /dev/null @@ -1,109 +0,0 @@ -# Hybrid Module Outline - -Content might be arranged this way when the Blockchain module is being offered as a full-week collaboration with the Smart Contracts module. - -## Monday - -We introduce the notion of contracts and how smart contracts fit in to history. -Students learn about expressing agreements as code and are left wondering where we could run such programs. - -### Morning - -- 📛 Introduce instructor, TAs - This module is coding heavy, we will spend a lot of time coding in class. - Lauren, Joshy - Founders Required -- 🗣️ Overview of Smart Contracts Lecture - Lauren - Founders Required -- ⌨️ [Rocket Cash Activity](https://github.com/Polkadot-Blockchain-Academy/rocket-cash-master/): Express contracts as code using rocket.rs - Aaron - Founders Required -- ☕ Break -- 🗣️ Digital Services and State Machines - I like to think of "state" as a double entendre - Lauren - Founders Required -- ⌨️ Begin BFS coding activity - specifically state machine part - Joshy, Lauren, Aaron, Andrew - Founders NOT Required - -### Afternoon - -- 🗣️ P2P Networking - Andrew - Founders NOT Required -- ⌨️ More BFS. -- ☕ Break -- 🗣️ Platform Agnostic Bytecodes - Joshy - Founders Required -- ⌨️ Web Assembly exercise - Joshy, Andrew, Lauren, Aaron - Founders Required -- 🗣️ Closing Discussion - Where would we actually run these contracts? - Joshy - Founders Required - -## Tuesday - -We put together the pieces presented individually yesterday to form a P2P network where nodes reach consensus on a blockchain-tracked history of a state machine. -We begin discussing consensus, and show how economics and game theory underlie the security assumptions of our P2P network. - -### Morning - -- 🗣️ Blockchain Structure - Joshy - Founders Required -- ⌨️ More BFS -- ☕ Break -- 🗣️ Consensus Part 1 - Authoring - Agreeing on Possibilities - Joshy - Founders Required -- 🎲 Manual Consensus Activity (aka BitStory) - Founders Required - -### Afternoon - -- 🗣️ Econ & Game Theory in Blockchain - Maciej - Founders Required -- ⌨️ More BFS -- ☕ Break -- - 🗣️ Unstoppable Applications Lecture - Nuke - Founders Required -- ⌨️ More BFS, or some other activity associated with fees and ordering. Maybe some kind of auction thing. - -## Wednesday - -We introduce the concept of deterministic finality, explore its history, and deep dive on a few PBFT mechanisms. -We also explore light clients and bridges, both of which benefit from deterministic finality. - -### Morning - -- 🗣️ Consensus Part 2 - Finality - Agreeing on Ordering - Joshy - Founders Required -- ☕ Break -- 🎲 [Grandpa Board Game Activity](https://github.com/Polkadot-Blockchain-Academy/pba-grandpa-board-game) - Joshy, Andrew, Lauren, Aaron - Founders NOT Required - - _Note that this repo is private, intended to be shared with the student cohort's github team for read access._ - _This also allows for people to pull up on mobile if logged in to view easier_ -- ⌨🗣️ DAG Based Consensus - Piotr Mikolajczyk - Founders NOT Required - -### Afternoon - -- 🗣️ Account and UTXO models - Andrew - Founders Required -- 🗣️ Privacy in the UTXO model - Guest Content - Founders Not Required -- ⌨️ Continue Coding on BFS -- ☕ Break -- 🗣️ Light Clients and Bridges - Joshy - Founders Required -- ⌨️ BFS - -## Thursday - -Big Contract Writing Extravaganza! -Students spend the day getting hands on experience writing smart contracts for PABs used in real-world blockchain contracting platforms. - -### Morning - -- 🗣️ EVM Concepts - Stephen Shelton - Founders Required -- ⌨️ Solidity Code Along - Stephen Shelton - Founders Required -- ⌨️ Vyper Code Along - Stephen Shelton - Founders Required -- ☕ Break -- 🗣️ Wasm Concepts - Filip Bielejec and Piotr Mikolajczyk - Founders Required -- ⌨️ ink! Code Along - Filip Bielejec and Piotr Mikolajczyk - Founders Required -- 🗣️ Introduce Contract Writing Workshop - Joshy - Founders Required - -### Afternoon - -- ⌨️ [Contract Writing Workshop](https://github.com/Polkadot-Blockchain-Academy/Contract-Writing-Workshop) - Joshy, Lauren, Aaron, Stephen Shelton, Filip Bielejec, and Piotr Mikolajczyk - Founders NOT Required - -## Friday - -This day combines the two culminating activities from the two modules into a day-long hands-on learning and comradery activity. - -### Morning - -Students will launch a blockchain a la the blockchain module. -Also get a few last short talks -Then they will use that chain to launch their smart contracts a la the contracts module. - -- ⌨️ Start a Blockchain Activity - Joshy - Founders NOT Required -- ☕ Break -- 🗣️ Types of Forks - Maciej - Founders NOT Required -- ⌨️ Forking Exercises - Joshy - Founders NOT Required - -### Afternoon - -🎲⌨️☕ Ink! Game - Lauren -🎲⌨️☕ Use the chain that we launched in the morning to execute the smart contracts competition. - Joshy, Lauren, Aaron, Stephen Shelton, Filip Bielejec - Founders NOT Required diff --git a/syllabus/3-Blockchain/Outline_Standalone.md b/syllabus/3-Blockchain/Outline_Standalone.md deleted file mode 100644 index a115d9aa4..000000000 --- a/syllabus/3-Blockchain/Outline_Standalone.md +++ /dev/null @@ -1,47 +0,0 @@ -# Standalone Module Outline - -This is an example of how the content might be arranged when the module is being offered independently. -When possible, it is preferable to run this module as a collaboration with the smart contracts module. -For details, see the [Hybrid Lesson Outline](Outline_Hybrid.md) - -## Day 1 - Morning Session - -- 📛 Introduce instructor, TAs - This module is coding heavy, we will spend a lot of time coding in class. -- 🗣️ Overview of Blockchain Lecture -- ⌨️ Begin BFS coding activity - specifically state machine part -- ☕ Break -- 🗣️ Blockchain Structure Lecture -- ⌨️ Continue BFS coding activity. Students should start the blockchain portion and finish the first lesson in that part even if they are not done with the state machine stuff yet (which is very likely). Then they can continue whichever part moves them - -## Day 1 - Afternoon Session - -- 🗣️ Consensus Part 1 Lecture - Authoring - Agreeing on Possibilities -- 🎲 Manual Consensus Activity (aka BitStory) -- ☕ Break -- 🗣️ Accounts vs UTXOs Lecture -- ⌨️ Continue coding on BFS - -## Day 2 - Morning Session - -- 🗣️ P2P Networking Lecture -- ⌨️ BFS -- ☕ Break -- 🗣️ Consensus Part 2 Lecture - Finality - Agreeing on Ordering -- 🎲 [Grandpa Board Game Activity](https://github.com/Polkadot-Blockchain-Academy/pba-grandpa-board-game) - - _Note that this repo is private, intended to be shared with the student cohort's gihub team for read access._ - _This also allows for people to pull up on mobile if logged in to view easier_ - -## Day 2 - Afternoon Session - -- 🗣️ Light Clients Bridges -- ⌨️ Continue Coding on BFS -- ☕ Break -- 🗣️ Unstoppable Applications Lecture -- ⌨️ BFS - -## Day 3 (Half Day) - -The activity and lecture can bleed together. I imagine launching a chain and getting some basic tokens - -- 🗣️ Resource Allocation lecture -- ⌨️ Start a Blockchain Activity diff --git a/syllabus/3-Blockchain/README.md b/syllabus/3-Blockchain/README.md index 5512e1fa5..4e16758d3 100644 --- a/syllabus/3-Blockchain/README.md +++ b/syllabus/3-Blockchain/README.md @@ -1,24 +1,54 @@ # Blockchain Fundamentals Module -This module introduces students to the problem space that blockchain is trying to solve (resilient, equitable, trustless infrastructure) as well as the technical aspects of how it solves those problems and to what extent it falls short. +This module introduces students to the shortcomings of centralized infrastructure including censorship, equity, reliability, and trustworthiness. It then demonstrates through lectures, coding activities, and games, how a peer to peer network can achieve consensus on a shared history that is recorded in the blockchain data structure. -The primary coding activity, which will run throughout the module is [Blockchain From Scratch](https://github.com/JoshOrndorff/blockchain-from-scratch/). +The module is designed to fit a schedule of 5 session of contact time lasting about 3-4 hours each. Some out-of-class study is expected, and a graded assignment is recommended. -## Collaboration with Smart Contracts Module +## Hands on Activities -In some PBA offerings, this module is slated to be taught immediately before the module on Smart Contracts. -When this is the case, these two modules can be intertwined to achieve a more compelling learning experience. +* The primary coding activity is [Blockchain From Scratch](https://github.com/JoshOrndorff/blockchain-from-scratch/). Each student should close this repository to work through it in and after class. This will occupy 8-10 hours of class time. -This intertwined approach begins with the Smart Contracts instructor defining and motivating the concept of a Smart contract, and leaving students wondering where such a contract could execute. -It continues with the Blockchain instructor showing that a blockchain is a perfect place to run a smart contract, and introduces the technical aspects according to this module. -Next, the Smart Contracts instructor gives students hands on experience building smart contracts in common blockchain-oriented programming environments. -Finally, the super-module concludes with an activity in which students launch a blockchain and participate as node operators, then launch their own smart contracts on top of the just-launched blockchain. +* Grandpa Board Game - TODO find the repo, it may have gotten deleted. For now the content was copied into https://polkadot-blockchain-academy.github.io/pba-book/blockchain-contracts/_materials/grandpa-board-game.html -When taught as a collaboration, the super-module requires roughly 5 days. -For more details, see the [Hybrid Lesson Outline](Outline_Hybrid.md) +* Start a Block and Fork Off - This activity is written up [in this repo](./Start_A_Blockchain_Activity.md) and also in [its own repo](https://github.com/Polkadot-Blockchain-Academy/Academy-PoW). TODO Unify these in the separate repo so the activity can be re-used externally. -## Independent Module +## Approximate Schedule -When the aforementioned collaboration with the smart contracts module is not practical, this module may still be taught standalone. -When taught as a standalone entity, the module requires roughly 2.5 - 3 days. -For more details, see the [Standalone Lesson Outline](Outline_Standalone.md). +### Block 1 + +- 🗣️ [Overview of Blockchains](./1-Overview_of_Blockchains_slides.md) +- 🎲 (Optional) [Manual Consensus Game](./Manual_Consenus_Activity.md) +- ☕ Break +- 🗣️ [P2P Networks](./2-P2P_Networking_slides.md) +- ⌨️ Begin working on [Blockchain from Scratch](https://github.com/JoshOrndorff/blockchain-from-scratch/) + +### Block 2 + +- 🗣️ [Blockchain Datastructure](./3-Blockchain_Structure_slides.md) +- ⌨️ Continue BFS +- ☕ Break +- 🗣️ [Consensus Part 1 - Author Selection](./4-Consensus-Authoring-slides.md) +- ⌨️ Continue BFS + +### Block 3 + +- 🗣️ [Econ and Game Theory in Blockchain](./5-Econ_and_Game_Theory_in_Blockchain_slides.md) +- ⌨️ Continue BFS +- ☕ Break +- 🗣️ [Accounts vs UTXOs](./6-Accounts_and_UTXOs_slides.md) +- ⌨️ Continue BFS + +### Block 4 + +- ⌨️ Start A Blockchain and Perform Forks ([Writeup](./Start_A_Blockchain_Activity.md), [Repo](https://github.com/Polkadot-Blockchain-Academy/Academy-PoW)) +- 🗣️ [Types of Forks](./7-Forks_slides.md) +- ☕ Break +- 🗣️ [Light Clients Bridges](./8-Light_Clients_and_Bridges_slides.md) +- ⌨️ Continue BFS + +### Block 5 + +- 🗣️ [Consensus Part 2 - Finality](./9-Consensus_Finality_slides.md) +- 🎲 [Grandpa Board Game](https://polkadot-blockchain-academy.github.io/pba-book/blockchain-contracts/_materials/grandpa-board-game.html) TODO Find proper repo +- ☕ Break +- 🗣️ Guest Speaker \ No newline at end of file diff --git a/syllabus/3-Blockchain/Start_A_Blockchain_Activity.md b/syllabus/3-Blockchain/Start_A_Blockchain_Activity.md index 8410bdf0d..244e9f9b6 100644 --- a/syllabus/3-Blockchain/Start_A_Blockchain_Activity.md +++ b/syllabus/3-Blockchain/Start_A_Blockchain_Activity.md @@ -57,16 +57,6 @@ Finally, there is a contentious fork. Some of the community are keccak maxis, ot There could be three chains after step seven. But we want a relatively stable chain for the contracts work in the afternoon, so we try to guide the class toward agreeing on a single chain if it is not happening naturally. -### Light Clients - -Would be nice to have a light client, but unlike the early days of Substrate, it is no longer included. -Last I heard from Nikos, Substrate connect / smoldot / etrc does not support PoW chains, so this will have to come later or be removed. - -### Other Infrastructure - -Like block explorer or indexer? - ### Smart Contracts -The Smart Contracts module has an activity about launching smart contracts on a running chain. -When these modules are run back-to-back, it makes an excellent learning experience to use this same chain we just launched to also launch the smart contracts. +The Smart Contracts module is run immediately after, it makes an excellent learning experience to use this same chain they just launched to also launch the smart contracts. diff --git a/syllabus/3-Blockchain/6-Resource_Allocation_Fees_Ordering_slides.md b/syllabus/3-Blockchain/X-Resource_Allocation_Fees_Ordering_slides.md similarity index 98% rename from syllabus/3-Blockchain/6-Resource_Allocation_Fees_Ordering_slides.md rename to syllabus/3-Blockchain/X-Resource_Allocation_Fees_Ordering_slides.md index 373ccebeb..af7943b55 100644 --- a/syllabus/3-Blockchain/6-Resource_Allocation_Fees_Ordering_slides.md +++ b/syllabus/3-Blockchain/X-Resource_Allocation_Fees_Ordering_slides.md @@ -6,6 +6,9 @@ duration: 1 hour # Fees, Ordering +TODO Determine if any of this can / should be re-used. +If so, find it a home, probably in the econ and game theory lecture. + --- ## Overview diff --git a/syllabus/3-Blockchain/img/schedule/blockchain_full.drawio.svg b/syllabus/3-Blockchain/img/schedule/blockchain_full.drawio.svg deleted file mode 100644 index 0356f2385..000000000 --- a/syllabus/3-Blockchain/img/schedule/blockchain_full.drawio.svg +++ /dev/null @@ -1,4 +0,0 @@ - - - -
Block
Chain
Block...Text is not SVG - cannot display \ No newline at end of file diff --git a/syllabus/3-Blockchain/img/schedule/blockchain_half.drawio.svg b/syllabus/3-Blockchain/img/schedule/blockchain_half.drawio.svg deleted file mode 100644 index 097cee351..000000000 --- a/syllabus/3-Blockchain/img/schedule/blockchain_half.drawio.svg +++ /dev/null @@ -1,4 +0,0 @@ - - - -
Block
Chain
Block...Text is not SVG - cannot display \ No newline at end of file diff --git a/syllabus/3-Blockchain/img/schedule/smart_contracts_full.svg b/syllabus/3-Blockchain/img/schedule/smart_contracts_full.svg deleted file mode 100644 index 05c045c43..000000000 --- a/syllabus/3-Blockchain/img/schedule/smart_contracts_full.svg +++ /dev/null @@ -1,4 +0,0 @@ - - - -
Smart
Contracts
Smart...Text is not SVG - cannot display \ No newline at end of file diff --git a/syllabus/3-Blockchain/img/schedule/smart_contracts_half.svg b/syllabus/3-Blockchain/img/schedule/smart_contracts_half.svg deleted file mode 100644 index f67c9fdfa..000000000 --- a/syllabus/3-Blockchain/img/schedule/smart_contracts_half.svg +++ /dev/null @@ -1,4 +0,0 @@ - - - -
Smart
Contracts
Smart...Text is not SVG - cannot display \ No newline at end of file