---
# System prepended metadata

title: Parity University

---

# 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: 
    
    ![](https://i.imgur.com/khoxilu.png)

    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. 
    
    ![](https://i.imgur.com/G4Xk4Bk.png)
    
    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. 

    ![](https://i.imgur.com/TmyYgbx.png)
    
    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