+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
+
+
+
+
+
+
+Notes:
-Platforms are OK as service providers, but peer-to-peer guarantees must be upheld without requiring trust in a service provider.
+Key point: your "perfect" system in is likely weak to things outside of the "rules"!
+especilly
---
## 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 (to date) is almost exclusively focused on _consensus system engineering_ - we reason about blockchains themselves, and "DApp"s use these as platforms to operate in.
+Smart contracts module _may_ include detains on unstoppable dapps design considerations.
+
+
+
---
## A Lot More Than Blockchain
-Blockchains only form one part of the stack. Web3 applications must prevent attacks at all layers. For discussion today:
+
+- Math โ **Provable Correct** (algo)
+- Consensus โ Proof of X (security)
+- Crypto โ \[ZK | VRF | Validity | ... \] Proofs
+
+
+
+
+
+
+
+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
+
+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_,
+
+
+Notes:
Source: [Buy Bitcoin Worldwide](https://www.buybitcoinworldwide.com/pages/mining/pools/img/pool-graph.png)
----
+---v
## Security Dilution
@@ -122,185 +499,208 @@ Security is always a finite resource:
+Systems with high security have the
+
----
+
+But validators are expensive, both economically and computationally.
-Any cryptographic guarantees are between central authority and users.
+Notes:
----
+Yet another N-lemma to consider.
-## Blockchain Node Queries
+---v
-In an ideal case, application users would run nodes themselves, so as to not trust a provider.
+## PoS Economic Security
-But nodes can consume large amounts of storage, network, and CPU resources.
+Proposition: The upper bound of economic security in PoS is relative valuation can secure, that is correlated with the market capitalization of the network.
----
+
+- This market capitalization could be company shares, or total ETH in existence, or total X token associated with a specific smart contract or parachain.
-These service providers wield large amounts of power to deceive, censor, and surveil.
+---v
----
+## โ PoS Economic Security Battles
-## Multi-Chain Applications
+
-If running _one_ node is burdensome, try multiple.
+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?
-## Light Clients
+---v
-Light clients only store block headers and consensus-critical information.
+## DApp PoS Economic Security
-- Allow users to query full nodes from RPC providers,
-- but take advantage of hash-based data structure to _verify_ the information coming from the provider.
-- Low storage and bandwidth requirements (use in a browser extension or mobile device).
+
----
+Notes:
-## Light Clients
+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.
-# Validator Power
+Nuke argue this is the same for the sum of all contracts valuations on something like Ethereum.
----
+---v
-## STF Upgrades
+## Authority Misbehavior
-Validators all execute the state transition function.
+
+
+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:
-# Dependencies
+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
+
+## 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
---
-## Separate Consensus Systems
+## Final Thoughts
+
+- Complexity generally increases the risks of failures, but we should not fear it.
+
---
-## Reversions
+
-
+## Questions
---
-## Blockchain Wars
+
-Systems with high security have the incentive to attack systems with low security whom they perceive as competitors.
+# Additional Slides
+
+Notes:
+
+For reference mostly, outside of formal class time ๐
---
-## Trustless Messaging
+## 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
-In order to handle messages _without trust_, systems must share common finality guarantees.
+> 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.