# Parity University

[TOC]

# Week 1: Rust

- Basic, lame syntax: `let`, `fn`, `loop`, etc. Everything that's in common with other languages.
- Uniqeue, new syntax: `enum`, `match`, patterns
- Ownership, Memory and model safety in Rust
- Demonstrate an example of how you CANNOT buffer overflow in (safe) rust and how darn easy it is to do in C.
- Generics
- generic types
- generic constants
- `trait`s, `struct`s, and `impl`s
- Associated types and constant
- Macros, procedural and declarative
- Look into the old `decl_module`, and the trailing tt pattern

# Week 2: Background Knowledge, Blockchain 101
- History of blockchain
- distributed, decentralized, and centralized systems. See figure in https://www.rand.org/content/dam/rand/pubs/papers/2005/P2626.pdf
- PoW history, spam resistence in emails.
- History of using a "Ledger": https://link.springer.com/article/10.1007/BF00196791
- First sign of PoW for email spam protection: https://link.springer.com/chapter/10.1007/3-540-48071-4_10
- Digital Money: https://link.springer.com/chapter/10.1007/0-387-34799-2_25
- Satoshi, BTC (UTXO)
- ETH (account-based, smart contracts)

- Misc. Background knowledge:
- Hashing
- ECC
- public and private keys.
- diffie-helman key exchange (great idea for rust exercise)
- digital signatures.
- Binary encoding
- Look at alternatives, e.g. `protobuf`, `bincode`
- P2P networks
- Key value data-base
- Webassembly as a portable, deterministic execution env.

- blockchain 101:

I've presented roughly this order to multiple parties so far, and find this to be good sequence of definitions to explain how a blockchain works:

- State: The end goal, the OG of data, what the whole blockchain tries to maintain with a sensus.
- Transaction: what might alter the state
- Runtime: what processes the transactions
- Blocks: a group of transactions
- Blocks can be chained via their parent hash: tamper-proof.
- Block header
- Block database:
- mandatory to keep in order to verify history.
- State Database:
- Attached to each block.
- It is optional: State(block_n) = Function(block_0, block_1, ... block_n-1)
- Just briefly mention that the whole state can be *hashed*, e.g digested into a single value, like a fingerprint, called state root.

Now we know enough to talk about block authoring. Ignore the fact of "how we decide who authors a block" for a second, and just assume Alice wants to author a block.
- Transaction Pool: where a bulk of totally unimportant transactions live, and we, as block author, can get a transaction out of the queue, based on some arbitrary criteria.
- Depict how appliying each transaction alters the state and produces a new one.
- Depict how the new final state root, along side the parent hash, is placed into the block header. Example:


Now let's talk about block validation. Again, assume somehow everyone else receives the block Alice has authored and wants to verify it.

- Depic how we deterministically arrive at the same state root.


Finally, we can wrap it up by stating how in a blockchain, *most often*, we are constantly:

- One entity claims to be an author
- Every N-1 other entity tries to validate and make sure that the author was honest.
- Use this quote from Pierre:
> Blockchain is a democracy in which we are looking for a temporary dictator.


Finally, we pack all of this into the main component of the consensus system:
- Block authoring: Who gets to author the block (babe, aura, PoW)
- conflict resolution: What if multiple parties are authoring at the same time (longest chain)
- Finality: (not exaplined yet, kinda too advance for now) (grandpa)
- economic security: What incentivizes the author to author the right thing (hash power, stake).

Knowing this, we can dive a bit into the leftover things that we ignored so far:
- We don't actually Hash the whole state: Merkle Tree and how state root is actually computed.
- This can also be a part of the "Misc. Background knowledge" section
- TLDR: sell blockchain as a decentralized state machine
- One author proposes a state transition
- Everyone else agreese upon it
- Collectively mark certain state transitions as "final".

- More in-depth lectures:
- Crypto-economics and game-theory.
- Cryptography.

# Week 3: Substrate and Frame

Unpopular opinion: I would start teaching FRAME from the bottom up, not the other way around. So, I would

1. Explain the high level difference and diagram of substrate client, and runtime
2. Explain VERY CLEARLY how the communicate:
3. Externalities + sp_io for runtime -> world communication
4. RuntimeAPI for world -> runtime
3. Recap on some of the previous components that we talked about in the previous week:
- peek into tx-pool
- peek into basic-authorship
- ...
4. Go over the main runtime APIs and explain why a client needs to ask these things from the runtime:
- `sp_core::BlockBuilder` api
- `TaggedTransactionPool` api
- ...
6. And then build the most simple, FRAME-LESS blockchain possible, where each transaction will will just bump a counter or something.

ONLY when all of this is exaplined: FRAME is basically an opinionated way to implement these runtime APIs.

# Week 4: Polkadot, Parachains, XCM

TODO