+
+---
+
+## Web 1
+
+Introduction of always-on servers.
+
+Still mostly peer-to-peer.
+
+Cryptography more often, but still not ubiquitous.
+
+
+
+---
+
+## Web 2
+
+Introduction of **Digital Services** with **Rich State**.
+
+Administered by service providers: "Send _us_ your information."
+
+However, users must place faith in the service provider.
+
+Cryptographic guarantees are about interactions with the service provider, not peers.
+
+
+
+---v
+
+## Digital Services
+
+People rely on digital services every day.
+They are inescapable and valuable.
+
+- Twitter, Instagram, Facebook, etc.
+- Journalism and sources
+- Banks
+- Lawyers, notaries, regulators
+
+Notes:
+
+- Ask class for more examples
+- Digital services are not bad in and of themselves. They are very valuable. We use all of these every day. We are even using some to administer this course. But they are also hard to escape.
+
+---v
+
+## Trust Example
+
+Two users on Twitter:
+
+- Trust that we are seeing information from the same database\*
+- Trust that if a tweet is from X, then X wrote that tweet\*
+- Trust that others see our messages as from us\*
+- Trust that the messages we see are the messages the users wrote\*
+- Trust that we're interacting with the application as equals
+
+Notes:
+
+- Cryptography actually provides a lot of these guarantees, but not when an intermediary has stepped in between users.
+- This is one example, but class should discuss.
+
+---v
+
+## God Mode Enabled
+
+In web 2, service providers can perform abuses:
+
+- Censoring user interaction
+- Restricting users interaction
+- Failing to produce requested data
+- Mutating state opaquely
+
+---v
+
+## Thought experiment: Digital Currency
+
+Bitcoin's application was digital currency - a trivially simple application.
+
+Could this be built with Web2 technology?
+
+Notes:
+
+Yep it could. This is the kind of simple app you might build in a Freshman year course
+on modern web interfaces. It just needs to maintain a set of bank notes and their owners (or alternatively a set of accounts and their balances.) So why didn't this exist in web 2? Because the provider could print money. Or steal money. Or freeze funds.
+Side thought. How different is this from fiat currencies?
+
+---v
+
+## Distributed Applications in Web 2
+
+Providers run redundant data centers to prevents accidents.
+
+But it still assumes benevolent participants and some trusted leader.
+
+Notes:
+
+Even in web2 we start to see the idea of redundancy to prevent accidents from natural disasters, sabotage, hardware failure etc.
+But we do not yet see disintermediation. In web 2, the masses become beholden to the service providers who were free to extract value and manipulate the users.
+
+In fact redundant systems were widely studied even before web 2. Consider a flight computer that has sensors for things like air speed and altitude. If one sensor fails we want the plane to keep flying.
-Removing trust allows us to unpackage applications.
+---
+
+## Web3
-
+* A provision of digital services without the need to trust a service _provider_.
+* Providers do not need to be trusted; they are economically incentivized to behave honestly.
+* Allow users to interact with a common system without trusting any intermediaries.
Notes:
-The idea here is to discuss how applications are often seen as an entire bundle: e.g.
-Instagram is the database, the algorithms, the UX.
-But when we have credible expectations that we're interacting with the same system, rules, data, it's possible to build lots of ways to access and interact with the system.
-It also removes the need for a central authority to deal with all appeals/complaints from various users.
+We want to maintain the value, versatility, and richness of Web2, but remove the trust, and possibility of extractive behavior.
---
@@ -96,19 +204,21 @@ The system should behave as expected, even if system operators do not.
---v
-## _Unstoppability_
+## Unstoppability
No individual actor, company, state, or coalition should be able to degrade any of these properties.
---
+
+
## A Shared History
-
+
Notes:
-So now we understand the goals of web3. How do we achieve them? The key is allowing users to agree on a shared history. The simplest blockchains do nothing more than timestamp and attest to a stream of historical records. In Web 2 users have no visibility into the history of the app. They must trust the provider to accurately represent the current state. By giving the service provider the power to change the story, we give them the power to shape our understanding of reality and consequently our behavior.
+So now we understand the goals of web3. How do we achieve them? The key is allowing users to agree on a shared history. The simplest blockchains do nothing more than timestamp and attest to a stream of historical records. In Web 2, and indeed often in governmental bureaucracies, users have no visibility into the history of the app. They must trust the provider to accurately represent the current state. By giving the service provider the power to change the story, we give them the power to shape our understanding of reality and consequently our behavior.
---v
@@ -122,6 +232,95 @@ So now we understand the goals of web3. How do we achieve them? The key is allow
_-- Yuval Noah Harari, Sapiens --_
+---
+
+## State Machines
+
+We can formalize this notion of shared story with state machine model.
+
+
+
+Notes:
+
+Most systems that we care about can be modeled as state machines. A state machine is not a real machine that you can touch. It is a model comprised of a set of states and a set of rules about how to transition between the states.
+
+---v
+
+## Labelled Transition Systems
+
+Sometimes you can map the entire state space as an LTS.
+
+Other times it is too big.
+
+
+
+Notes:
+
+Consider if we tried to map all possible states of a social media app or a digital currency. Sometimes an LTS drawing like this is useful, other times it would be too large or even infinite. Even still, sometimes drawing part of it can help you think about what the states and transitions might be.
+
+Example: Audio Amplifier
+
+There are three buttons (louder, quieter, mute). The amplifier's volume output can be one of four levels: Silent, Quiet, Normal, Loud. Volume up and down should be pretty clear. When you mute the output immediately goes silent, and when you unmute it goes back to whatever it was before.
+
+Q: How should we model the states?
+A: We could make the states directly be the volume levels.
+
+---v
+
+## Example: Light Switch
+
+Simple Switch: 2 States, 1 Transition
+
+**Labelled Transition System**
+
+
+
+**History**
+
+
+
+---v
+
+## State Machine Example: Digital Cash
+
+Each state is a set of bank notes. Where a bank note has an amount and an owner.
+A transition involves a user consuming (spending) some bank notes and creating new ones.
+
+
+
+Notes:
+
+Not all conceivable transitions are valid. Imagine a user consuming a bank note worth 5 coins, and creating two new ones each worth 3 coins.
+
+---v
+
+## Sate Machine Example: Social Media
+
+Each state is a set of posts and their associated comments and emoji reaction counts.
+A transition involves, making a new post, or reacting to someone elses, or commenting
+
+
+
+Notes:
+
+There is not a single model here. Some state machines will allow deleting or editing posts, while others will not. Some will allow disliking posts while others only allow liking.
+
+---v
+
+## More State Machine Examples:
+
+
+
Uses an unspent transaction output (UTXO) model & Proof of Work (PoW) consensus.
@@ -234,7 +440,7 @@ Figure source: [Bitcoin white paper](https://bitcoin.org/en/bitcoin-paper)
## Litecoin, Monero, Dogecoin
-
+
Notes:
@@ -260,15 +466,8 @@ Let the market decide.
---v
-## Smart contracts - Two Definitions
+## Polkadot, Cosmos, Avalanche, Near, ...
-A machine program with rules that we could have defined in a contract, but instead a machine performs or verifies performance.- -#### Narrow Definition _"Web3 definition"_ +Notes: -
A program that specifies how users can interact with a state machine and is deployed permissionlessly to a blockchain network+Iterations on Ethereum's general computing platform. Strive for scalability interoperability etc. Experiment with different consensus models. \ No newline at end of file diff --git a/syllabus/3-Blockchain/3-Blockchain_Structure_slides.md b/syllabus/3-Blockchain/3-Blockchain_Structure_slides.md index aa459a022..ac2ac967c 100644 --- a/syllabus/3-Blockchain/3-Blockchain_Structure_slides.md +++ b/syllabus/3-Blockchain/3-Blockchain_Structure_slides.md @@ -23,7 +23,7 @@ And it allows them to know whether they have identical histories in O(1) by just ## Hash Linked List - +
Notes:
@@ -33,7 +33,7 @@ This is a simplified blockchain. Each block has a pointer to the parent block as
## Hash Linked List
-
+
Notes:
@@ -43,7 +43,7 @@ The pointer is a cryptographic hash of the parent block. This ensures data integ
## Hash Linked List
-
+
Notes:
@@ -202,10 +202,10 @@ The parent hash links blocks together (cryptographically linked list). The other
-- Version
- Previous Hash
-- Tx Merkle Root
- Time
+- Version
+- Tx Merkle Root
- N_Bits
- Nonce
@@ -214,18 +214,18 @@ The parent hash links blocks together (cryptographically linked list). The other