Joshy's reflections on the Blockchain and Smart Contracts hybrid module as delivered during week 2 of PBA3 in Berkeley 2023.
For the UCB cohort we largely re-wrote the smart contracts module, moving away from a narrow focus on ink! to a much broader perspective across the blockchain space and historically. We also integrated this content tightly with the existing blockchain module to create a week-long hybrid module. The motivation is that the idea of a smart contract predates blockchain and was a goal well before it was realized on blockchains.
I think this ordering makes a lot of sense and should be kept. However, I think the idea of one massive module can be improved upon. Thank you Nuke and Pauline for the opportunity to teach it as a monolith until the proper delineations became clear.
Monday - Historical look at smart contracts, distributed systems, technical content on state machines, p2p networking, web assembly Tuesday - Blockchain data structure in full detail, Leader election, Pow Wednesday - Blockchain Consensus, Unstoppable Applications Thursday - Learn Solidity, ink!, Vyper, practice writing smart contracts Friday - Start a blockchain network, Fork theory and practice, ink game, practice contracts and work on assignment
My favorite, Option 1 is to divide this content into three modules called Distributed Systems past present and future (Roughly MOnday's content), Blockchain Fundamentals (Roughly Tuesday's and Wednesday's content), and Smart Contracts in Web3 (Roughly Thursday and Friday's Content)
If this granularity is too extra, There is another option I like
Option 2 would be to split this into two module almost exactly as it appears on the current PBA website. But call them Blockchain and Distributed Systems and Smart Contracts in Web3. These slight shifts in title capture the fact that the historical stuff and general P2P stuff also fits with blockchains, and that the second module is about smart contracts as they came to be in web3, not the idea and history.
Cambridgey - adj - TODO copy definition from slides
I introduced this word in the first few minutes of class. This was to set expectations that the material would be both overall good, and also a little rough. And it was to invite students to learn in this environment. I'm glad we did this. I don't think it will be necessary next time.
So how Rough was it in the end? I think it was less Rough than {almost anything from actual Cambridge, Cryptography capture the flag in BA, Polkadot content in BA}. I think it was more Rough than {Blockchain content in BA, Substrate content in BA or UCB, Crypto content in UCB}. This is to say it fell about where I expected and was within PBA precident. I admit there were a few parts of Friday's content that we rougher than I would have liked to present. There are many ways in which this content can be iterated on and made really good, and I propose that the majority of it should be essentially kept. I will go into some bigger picture ways to improve the content in this reflection, and others will be relegated to issues in the relevant repos.
I think the content and delivery was good enough that students who wanted to learn it and were willing to put in effort and have a little grace with the instructors were indeed able to learn it. For me, this is the most important bar to clear.
This brings me to a personal reflection. I have the most to offerwhen it comes to creative energy, proofs of concept, pedogogy, first few deliveries of content, learning in public. These are my strengths. Some weaknesses include polishing up final products, making things "finished", delivering tried and true content. That is to say, I think I thrive when things are new and allowed to be a little Cambridgey, and I wither when I need to get things close to perfect.
Thank you all for the opportunity to work in this Cambridgey environment, and for working along side me. Our week of teaching was one of the most intense and also funnest of my career.
One area of new content we introduced at my suggestion was a historic look at the concept of smart contracts. I think it is important for students to see that people were hoping for smart contracts and trying to think of ways to implement them for a long time, and then see how the blockchain manifestation fits into those expectations.
We initially recieved a lot of constructive criticism about this during the dry run including that we should not obscure the actual web3 definition for this historical stuff, and we should make it clear why the historical stuff is useful. We iterated based on this feedback, and I think the delivered content, while certainly good enough, can still be improved upon.
Here is a quick braindump on how to iterate further, expanding on the better ideas for sequencing I outlined above.
- Frame a historical introduction to the next several modules first.
- Incorporate content from my shared storytelling sub0 talk.
- Look at history of smart contracts, szabo etc, and make it clear this is a historical look. Mention that the more precise web3 definition will be introduced in the smart contracts module.
- Introduce some OG Leslie Lamport stuff distributed consensus stuff.
- Keep the P2P networking lesson in this early section including napster examples etc.
- Maybe take a look at libp2p, ipfs, dat, git, irc, matrix, or some other interesting examples or non-examples of software that may feel decentralized.
We taught the concept of expressing a smart contract independently of any specific language, and then taught 2-3 specific languages and pointed out the commonalities and differences among them. Concretely we taught Solidity and ink! and also kind of taught Vyper, but it didn't get first class support.
I think this worked out as well overall. Pedagogically I really stand behind this approach and I think it was well-received. Some incremental improvements include:
- Better Vyper support
- More thorough test coverage during workshop
- Better testing on Academy PoW node
- Consider introducing new languages
Throughout the week, we offered many ungraded learning opportunities. In fact, the ungraded activities blockchain from scratch, grandpa boardgame, smart contract writing workshop, ink! game, and start a blockchain activity, occupied nearly half of the in-class time. This was done intentionally. I understood that students were here to learn as much as they could in the short time available and consequently I provided them with what I hoped to be many high-quality learning opportunities.
Some of these activities were new, others had run in the past. I"ll consider Blockchain from scratch as an example because it had run previously in both Cambridge and Buenos Aires. On both of those occasions, students engaged considerably asking me good questions, putting in work outside of class, and even catching little mistakes in the starter code. On those occasions the activity was also mentioned positively in many student review comments.
The response to blockchain from scratch and ungraded work generally felt quite different this time. Fewer students engaged or asked questions. I didn't get DMs outside of class asking about things students got stuck on. Overall I had the sense that the class didn't put as much effort into it. This is concerning primarly because it means students aren't encountering the concepts as closely and therefore not mastering them as thoroughly.
For many students, the lack of engagement with ungraded work first manifested as unpreparedness in the graded assignment which I will discuss below.
We gave a single graded assignment which was to build a trustless bridge following a btc-relay like approach. The students were asked to complete a smart contract that acts as an on-chain light client for a foreign chain. This assignment was to test their mastry of both blockchain and smart contract concepts. I think this is the perfect assignment topic to cover those two skillsets.
If we only wanted to assess blockchain, we could use part of blockchain from scratch. If we only wanted to assess smart contracts, we could use part of the contracts workshop. (I'm speaking pedagogically here, of course the licensing would still be a pain. The licensing is always a pain.) Because we wanted to assess both, we chose the bridge assignment. I recommend that if instructors want to assess both topics together in the future, they use this same assignment.
Of course it was Cabridgey like everything else, and there are issues opened in the repo already about how to make it better for next time.
In short this was a total shit show for many reasons.
One problem that I've identified above is that I didn't feel students properly engaged with the ungraded assignments. The ones where they were able to learn, play, and practice without the fear of a grader. Then when it came time to be graded, they didn't have all the required practice and experience. I don't entirely blame the students here. The question is why did they do that. Maybe because the days were already too long. Maybe because I didn't motivate them properly. This I genuinely don't know. I only know that if you don't show up to practice you aren't going to perform in the competition.
A bigger problem was the conflicting expectations that students were given about how grading would be performed. This was so fucking bad that I'm cringing even writing about it now, a month later. The student syllabus promised a clear breakdown of how everything would be graded and I literrely didn't even know that. I could and maybe should ahve read the syllabus again, but I also was relying on what I knew from previous PBAs. Anyway, I was trying to set expectations as I saw fit which was to not promise anything too precise in advance, and just encourage students to learn as much as they can and do the best work they can. They were not having this.
Then there was the whole nightmare about the semantics of the 0-4 scale. It seemed like everytime anyone tried to repeat it in their own words, they got it wrong according to Nuke. I gave a lot of 2s which I understood to be a good passing grade for students who met the requirements. But so many students were pissed that they only got 2. What a nightmare. I thought 3 and 4 was for exceeding the requirements. Students complained they didn't get a 3. I asked what they did beyond the requirements. They said I didn't tell them what to do beyone the requirements.
I still can't express how awful of an experience this grading was for me. It was worse than when I was a brand new teacher with no experience setting expectations or dealing with backlash. At minimum, if there is a requirement for grading scale or students have been given expectations those need to be explained clearly to the instructors and graders.
To the extent that this was my fault, I'm truly sorry and I'm open to feedback about how to improve. I also have feedback to offer in a more grading-specifc conversation, and I'm working on a draft of how we migh restructure certifications to be more skill and competency based.
This was so bad.
I'm so thankful for the team of contributors to this module.
Lauren, Aaron, Andrew, Filip, Stephen, Piotr, Maciej, Gabrielle, Nuke, and everyone else. Thank you for your positive attitudes, your tireless contributions, your debugging, and your endless support as we worked through the funnest and craziest week of teaching I can remember.
It would be my honor to work with any of you again.