Corhort 1 Syllabus Feedback

[shawntabrizi]

This is a meta issue where we can track all of the problems, "wish we had it", and feedback from this first cohort.

[shawntabrizi]

Section 1

• Gav changed the order, we should reflect that in the repo.
• More diagrams and visuals I think would be helpful.
  • For example, there are cool examples of hash collisions in the real world, we should show them.
• I think we could have added an exercise where we had them benchmark different hash functions with a data set that we prepared.

[shawntabrizi]

Section 2

• Loved all the demos, really outstanding.
• Gav has some feedback about Jonas's slides, we should get that incorporated.
• I thought the final NFT auction was a little dry at the end. I mean the demos were all AMAZING, but it felt like we were building up to some final big activity, and it went by real fast.
• I think we should have all the students actually give us $10 to start with to participate. Or we hand them $10 eur to start, and they have to hand it back. Changes the dynamic of "feeling loss"
• I think with each activity, we should have a slide with a graph of "what we expect" and then show the graph of the actual outcome of the users, or overlay the two. There were some irrational behaviors in the class, and it would be good to compare that to the expected behavior of rational actors.

[shawntabrizi]

Section 3

• I think currently it is too closely touching on Substrate, which really should be saved for 4. Need to find ways to make the content more blockchain / blockchain framework agnostic.
• I liked Joshy's demo building a live blockchain on the whiteboard and live consensus, but I didn't (personally) find them splitting into groups and doing it again on the paper added learning beyond the shared whiteboard. If we want to fit in other activities, I might suggest condensing this part.
• More about light clients at a theoretical level.

[shawntabrizi]

Section 4

Prereqs

• Need to really dive a bit into rust, basic commands, common patterns, etc...
• Rust features in general.

4.1 Substrate Intro

• Need to add a slide talking about the single threaded and sync execution of wasm.
• Need to add a slide which compares why you would build a substrate chain instead of a smart contract.
• Make the Pallet stuff more opaque
  • Don't dive into the FRAME / Pallet
• Show a transaction go through the client
  • Directionality of components used (what is the order)
• More clarity on the decision of division between client and runtime
• Add a quick detail on the size of Wasm (since it should be compact)
• More about std and no_std for wasm

SCALE

• More research on other encoding formats like Protobuf
• Add some kind of introduction into Metadata
• Show an array which is more than one byte length
• Show a struct using a compact encoding inside of it

Polkadot JS

• Create an in browser playground for users to follow along
• Review Subscan + Polkadot JS Apps before

Host Runtime Interface

• add dotted line around DB in example

[emresurmeli]

Section 3

• Overall, Joshy's coding activities were super well received.
• Manual blockchain and consensus exercises were well recieved, they can be refined to use different hashing algortihms and incorporate different ideas ie. mining pools, different election rounds, different attacks
• 3.4 We could have more content on light clients, either in section 3 or later in Substrate modules(depending on if we want students to learn about smoldot)
• 3.4 activity - Architecting unstoppable applications needs more time, we had to cut it short due to class starting late. We adjusted by letting each team choose a member to present their idea. The goal should be to have students write a whitepaper like document, and create a flow chart.
• 3.5 Kahoot got good feedback, and should be something we can do weekly. It's a good opportunity to keep a heartbeat on students. We do have to ask them to use their real names when signing in to play. That way we can see who is doing well/participating(ofc they should know about that).
• 3.5 Panel didn't work as intended, conversations were good, as students had good questions. But it diverted from the module topic a lot. Shawn reviewing previous materials was helpful, but felt that time could be better spent, either via having a lecture about other blockchain fundamental topics or coding exercise.

[kianenigma]

4.

We squeezed in a SCALE lecture spontaneously, and seeing how many questions students have, I think it should be well defined lecture + workshop with more dedicated time next time.

3.

I think currently it is too closely touching on Substrate, which really should be saved for 4. Need to find ways to make the content more blockchain / blockchain framework agnostic.

Expanding on this, For example a lecture in mod 3 spend ~20 minutes on weights, going into not even only substrate-specific details of how weights work, but also FRAME syntax, and from what I saw, students were more confused by this jump forward than educated by it.

In module 3, we only want to inform them why metering execution time is important in blockchains, and what general approaches exist:

1. dynamic, runtime time approaches like ETH style gas metering.
2. static, pre-dispatch approaches like substrate weight system.

[sacha-l]

Module 3

• I found that we could do a better job on both content and delivery for not leaning into Substrate and Polkadot so much. We could be more blockchain agnostic and come up with a variety of example chains instead of picking Polkadot (just like how Module 2 got refactored).

Module 4: PJS workshop

Feedback:

The academy should have more hands on workshops like this. Going through a demo of a bunch of simple steps is great. But ideally (next time) imo should be followed with assigning the class with specific follow up exercises to do (just have steps 1, 2, 3 on the slide for example) like a mini workshop before moving on. This also applies to learning how SCALE works.

Module 4: Consensus

• Better to focus on implementations of consensus algorithms vs. evaluating them
• Outline the components of each consensus, objectively, always bringing and evaluating against the CAP theorum vs. going into potentially opinionated statements
  • Be more explicit on key takeways in the start: what are the necessary factors for the system to function, what to all systems have in common: --> economics, costs associated, miner or validator nodes (...?)
  • Silly questions: but "proof of work gives you significantly better security guarantees, I don't agree with your statements / arguments / analogies".
• In Polkadot and FRAME we can go ham, but Substrate should not be opinionated.

Corrections

• 2 Phases in a round (slide 38)

Activity idea:

• Aura is attackable because block production is known in advance: attack an Aura node.

Reordering thinkings

• FRAME should probably come after the Substrate module
• Polkadot after FRAME
• Within Polkadot, we should probably first dive into parachains and then Cumulus

[JoshOrndorff]

Module 4, Storage lesson: Two uses of the word "value".

1. The actual stored value that the runtime developer cares about (eg a balance)
2. The RockDB value (which is another trie node)

use this visualization tool to explain merklized storage: https://github.com/Lohann/substrate-state-visualizer

Module 3: Need to make it much more clear that the blocks represent transitions between states. The states themselves are NEVER part of the blocks. They are calculated by each node.

[kianenigma]

Module 3: Need to make it much more clear that the blocks represent transitions between states. The states themselves are NEVER part of the blocks. They are calculated by each node.

For this, we should use a figure such as page 6 here: https://github.com/kianenigma/SonicChain/blob/master/Presentation.pdf

[shawntabrizi]

Would be nice to touch on:

// This panics
#[test]
fn access_storage() {
    sp_io::storage::set(b"mykey", &vec![0,1,2]);
}

#[test]
fn access_storage() {
    let mut new_empty = sp_io::TestExternalities::new_empty();
    new_empty.execute_with(|| {
        sp_io::storage::set(b"mykey", &vec![0,1,2]);
    });
}

Also to do such a test in the frameless runtime.

#[test]
fn test_apply_extrinsic() {
    let block = BasicExtrinsic::new(5u8, None).unwrap();
    assert!(Runtime::apply_extrinsic(block).is_ok())
}

#[test]
fn show_me_scale() {
    println!("{:02x?}", 6u64.encode());
    //assert!(false)
}

#[test]
fn try_to_store() {
    let mut new_empty = sp_io::TestExternalities::new_empty();
    new_empty.execute_with(|| {
        sp_io::storage::set(b"mystorage", b"myvalue");
    });
}

[shawntabrizi]

Module 5

Intro to Polkadot

• Parathread diagram might be wrong.
• Note secondary validators in mechanics of parachain validation
• Bonding -> Parachain Leasing

Cumulus

• Def need to move it later into the curriculum
• Many diagrams and visuals needed to help cement ideas
• We should include a glossary at the beginning to ensure everyone knows the terms

[JoshOrndorff]

Module 5:

We should talk about the Polkadot parachain protocol before we talk about Cumulus. Most of the questions and confusion today were about the parachain protocol rather than cumulus itself. Presenting them together made it unclear what is cumulus specific, and what is imposed by Polkadot.

For the parachain protocol lesson we can borrow material from the implementors guide as well as https://medium.com/polkadot-network/the-path-of-a-parachain-block-47d05765d7a

[shawntabrizi]

Module 6

Intro:

• Add "externalities" to FRAME prerequisites.
• Show off before and after number of lines with macro expand
• Go deeper and have slides which explain why we use types rather than functions in a config
  • And potential tradeoffs

More high level, the FRAME intro should be much more big picture. I think we got too deep too quickly and lost people.

Let them experience the magic, and then explain to them how it works, rather than bottom up.

Storage:

• Talk about reading the storage item of other pallets.
• difference between NMaP and Map with tuple key.
• Talk about getter.

---

pub use pallet::* needs to be in the empty skeleton of a pallet, otherwise construct_runtime! won't work.

[shawntabrizi]

Proof of Existence Workshop

• Need to make sure the workshop has no bugs or errors
• More time spent on reviewing and discussing the "empty shell"
  • Ideally show that it compiles with basically nothing in it
  • Compare it to solidity contracts
  • Explain that this is the basis for FRAME
• Users complete the pallet part
• Users should run the node
• Front-end already built and hosted somewhere they can easily use it and try it out, no JS dev

IMO we should avoid open ended building on top of this, as they have not learned anything from FRAME yet. This is just a taster for the minimal working pallet, and to expose them to the things they will expect to learn about. I felt introducing the currency trait was opening a big door too early.

The best thing is for them to be "how does this work?" And we tell them that it is covered in our lectures.

[shawntabrizi]

Hooks + Dispatchable

• Mention a use case for on_finalize, like deleting temporary storage.
• why on_finalize is deadly in a parachain.
• mention #[transactional]
• elaborate more on weight vs metering: privacy, trust of SC, efficiency.
• talk about example: how you make a transaction fee-lees, or paid by someone else.

[shawntabrizi]

Walkthrough of the traits we use

Too many people failed to know which traits to use, which pallets implement which traits, and all that.

Too many people failed when simply adding an existing pallet to their project.

We need to improve all of that.

[sacha-l]

FRAME comments

• The pattern of theory + workshops was good for first three modules but got lost towards the end of the Substrate module. Although we did do some workshops during Substrate and FRAME, there wasn't much of a pattern of: "Here's what you'd expect to see, e.g. Events and Errors + here's an activity that will give you hands on experience working with them". I spoke to multiple students who felt lost during the FRAME lectures: "what's the context of knowing this? why does this matter to me as a developer?". We could probably state the answers to these questions more explicitly as a prelude to the more conceptual lectures.
• For next time we should give students time for more hands on activities to apply what they learnt from the lecture slides. And we should prepare the exercises for them, giving them steps to follow, specific expectations.
• The goals for module 4 and 6 should be to teach them depth about Substrate and FRAME but also prepare them for their final projects. Many students were completely lost for the first few days working on their assignments.
• We should have more workshops that will help students for their final project and do them before the deadline. Shawn's live coding was arguably the most valuable time spent to set students up for success in making progress on their finals.

---

• With workshops during Substrate (like the state transition activities and the frame-less runtime), we should provide tests for students to check their solutions against. We can even make some count towards their final grades. Either way, they can also see what the solution is even if they haven't finished.
• Short graded activities would be good for us to get an idea of where everyone's at, and also to build confidence in the students' abilities in preparation for their final project.

[shawntabrizi]

For the final project, we should have scaffolded templates so that students are not getting stuck with the basics of importing things and "setting it up".

Instead, they can work from files which are already set up and instead work on the todos in those files

[shawntabrizi]

Suggestion to use: https://classroom.github.com/

[shawntabrizi]

Also some instructions for students with any computer to use cargo remote with some special server we have, to avoid problems compiling and working with substrate.

[kianenigma]

Module 4: The whole runtime api versioning system is about to be changed: https://github.com/paritytech/substrate/pull/11779

[bkchr]

Module 4: The whole runtime api versioning system is about to be changed: paritytech/substrate#11779

Not really :P We just extend it, but it doesn't change that fundamentally.

[nuke-web3]

This was a great set of notes that AFAIK have been implemented since. If not, please reference what was missed in a new issue!