Rareskills https://www.rareskills.io
These are my solutions to the assignments at Rareskills. This bootcamp has the value proposition "Get personal coaching for four months from blockchain industry experts, then get recruited to top web3 companies". I applied, because it is one of the few bootcamps out there. I passed the coding test and Jeffrey Scholz and his team convinced me with their knowldege and industry expertise - so I joined the October cohort 2022. I am happy to be part of the bootcamp.
--- Week 1: ERC 20 ---
I created ERC 20 Token contracts with OpenZeppelin, worked on user management, and finally on a linear bonding curve for setting a price for buying and selling a token. I got to know the Remix Dev Environemnt, all browser based. At the end of the week I added test case to debug. A very cool feature is Solidity debugging, which helped me a lot. worked with Remix and Solidity testing.
--- Week 2: ERC 721 ---
This week I had to create first a some images, that I placed to the ipfs. From there I created my first NFT ERC721 contract and deployed my nfts, now visible on polygon (https://mumbai.polygonscan.com/address/0x7093CFC26ea2C1a41165e1C9D88173603375027F). I named them Prime Cats ;-). Of course I know the NFT boom is already over, but still a cool thing! Important to verify the contract on polygon. The second task was the most challenging one, a staking contract for NFTs and rewarding the user with 10 tokens every 24h. Not sure how I did this, we will see. A contract gets fast complex and with remix alone it is hard to debug and ensure quality. I assume that's why the next week we go into testing and other tools than remix. Great ;-).
--- Week 3: All about hardhat testing ---
Hardhat is a cool tool to learn. It is created by a foundation that wants to make the tool the best ones and it seems to be so good, that developer start to prefer it over truffle. I don't know truffle, so I cannot tell. I was doing my first 2 weeks only in Remix and was starting to miss the browser environment with included debugging feature. But hey, that's how you feel when you like something and do not want to learn something new - hardhat revealed itself to me as a stable tool that does its job. It integrates in VS Code and its command line is extensible. In one week of course I did not grasp everything, but I was able to migrate from remix and write several tests and found quite some bugs I still had in the assignments of week 1 and 2. Smart Contract development is hard and impossible without tests. And writing tests in hardhat is much more flexible than in remix, and more stable. We worked with solhint and prettier to find bugs and format the code to a pro level, finally used static code analysis with slither. Used mutation testing (wow, kill the mutants) and finally played ethernaut. A quite busy week. I feel gain streched ;-).
--- Week 4: Integrate smart contracts with a web frontend ---
Week 4 was the toughest for me. We got the task to create a webapp for a smart contract - a game where you can mint and burn tokens, this time an ERC1155 Multitoken standard, that can store multiple tokens of ERC20 or ERC721 - The idea behind this contract is to reduce transaction costs when you need to create/burn/transfer multiple tokens. The work on the contract was not that hard, openzeppelin quite fast read. The big challenge, and this was mentioned, was creating a working webapp. I have a database, PHP, Wordpress background - here we agreed to work on Next.js. It was open to us what to use, but hey, why not learn more? We were encouraged to learn something new, but not overinvest with tutorials. That was a tough one, because I love to learn with videos. Still one thing is clear, after watching 20h of video you have not created anything and still have to create your first app, so why not create it immediately???
Well, I managed after working through 4h tutorials on react and starting with a sample that I copied together from many places. I learned react piece by piece myself. Finally the difficult parts of integrating with metamask was necessary, connecting with hardhat development server. I prefered this over Ganage, that I read does not give stack traces back. It was a good choice. So I was able to create a working solution locally, debug issues, understand metamask and I think this was a fair approach on reading docs, listening to tutorials and working on code myself in try and error - combined with grabbing code samples and understanding these.
It was a long week, I hope the next ones are a bit less intense. Here you see my solution - that was the best, with Vercel you are able to deploy very easy from your git repository to a website. Open Source Pure.
--- Week 5 to 8: Advance concepts of Solidity ---
I write this being finishing the 3rd security week. The callange for me was to understand solidity in its details and use Solidity in Remix, Hardhat and working with the Görli Test chain. We worked through a selected list of the Ethernaut problems, Capture the Ether challenges, Damn Voulnerable Defi and Solidity Riddles. It was hard for me to understand at the beginning of the exercise what exaclty was expected - at the end of this week it was clear to me to write markdown files - hey, this is the file I write, but nobody told me, but logical md file. So today I used a plugin for VS Code to write these files and I start to upload each file. I focussed - against the recommondation - one week of security watching and reading, then spent a few days understanding Ethernaut and when use web3 in the browser, remix or hardhat. Week three I finished Ethernaut and Capture the ether. Not sure if this is the best learning path ;-). But the one I chose.
I think this took long because of other work I had to do, so not sure if I am able to finish in time. So I will finish document one more day the done tasks and finally finsih Defi tasks next week. So it takes me nearly 5 weeks to complete. Still the learnings are huge and every day I learn a detail. What is clear to me now this course works only if you are willing to work a lot alone, ask many questions, listen very good and then do again resarch and problem solving. Like this I create for me a virtous loop. Maybe it is the endless repetition of the same topic from different perspectives that makes this course work so good. Lets see if I can be up to my time plan and I do not condamn my optimism :-)
What motivates me I can continue to specialize with the same learning techniques in additional courses of Rareskills. So finally I will be at a point of specialization I would not have expected - a real web3 expert.
--- Week 9 and 10: Gas optimization and assembly programming ---
Rareskills.io agenda for this course states: "Learn from the bestselling author of the Udemy courses on gas optimization and assembly programming. It’s not just enough to master Solidity. You must master the environment that it runs in: the Ethereum Virtual Machine. You will learn how the EVM actually conducts the transactions, stores information,and the protocols it uses to receive instructions."
After the winterbreak with almost 3 weeks doing something different I am back with Gas optimization and assembly programming. The first two days was hard to focus, especially because of the low level of the work - assembly coding with Opcodes. I solved 20 evm puzzles, ethernaut tasks and rareskill gas puzzles. With this I read quite some text and watched several videos. What have I achieved? I start to feel secure and confident in my work. It is clear I get more productive. The long term achivement I believe is that I write more efficient code and if a problem arises, I am able to solve it better/faster due to the sum of different perspectives.
I look forward for the next week with more gas optimization and programming tasks.
-- Week 11-12: YUL and Assembly Contracts ---
This two weeks where the most difficult assignment in the course. I created a 1155 ERC token purely in YUL. This was a hell of a journey, starting with about a week learning and research about the ERC1155 standard, intros into development with Foundry, learning about how values of different types are stored by solidity and how you handle memory and storage yourself in YUL. It was a huge learning experience, I was not sure I was capable of. I made my first experience with GitHub Co-Pilot, that was very valuable and showed the pros and cons of chatbots, helping with repeating code and discovering new code patterns, but as well hallucinating wrong code that introduces bugs that are very hard to track down. All in all such helpful 2 weeks, that I am proud of!!!
-- Week 13: Week 13: Smart Contract Upgrades ---
Smart Contract Upgrads seemed to be done in 1 week, but it was way too much work for me. There was less to watch but more open questions regarding cloning and delegate calls. 2 ethernaut challenges and 2 DAmn Vulneral Defi Challenges took quite some time as well, as well using the Open Zeppelin Upgrade plugins for the first time. These two weeks clarified my questions how to upgrade contracts. It is very obvious that in software develpment you need to fix bugs. On the other hand it is understandable that your code should work as good as it is possible, because a lot of money can be involved and things can go terribly wrong if you dont know what you are doing. It was a great week for me! Many learnings and working with production ready code like the TimeLock, AccessControl or the GnosisSafe. I felt like working on a real project. Feeling the pain of small errors I did not know about! I was expecting after the YUL weeks, which I finsihed earlier because of using Foundry, this week was a piece of cake, until I realized it was not! But the bigger is the learning. Cool lets see what happens next week!
-- Week 14: Week 14: Exotic Smart Contract Upgrade Patterns ---
I was learning about create2 in this week, how you can (re)deploy the smart contract at a certain address. This is important for metamorhic contracts in combination with selfdestruct. It is important to understand that in selfdestruct not only the implementation is destroyed, as well the storage. For probably security reason, destructing contracts is not supported anymore. It was fun to see the metamorph contracts work. Finally in this week there was the diamond pattern from Nick Mudge. He created a contract with one Proxy and several implementations (Facets). The calls go always to the diamond and the calls are forwared to the implementaion - but the storage and context is kept in the diamond (Proxy pattern). I worked through all the tests from Nick Mudge, added a NFTFacet and ERC20Facet to it. Important to mention that the diamond allows only a function name once so it is wise to use a prefix for every proxy. Finally I added the tests and I was done. What a learning on larger projects. This is really great and I am happy and proud to be that far. THANKS to RARESKILLS to make this fast learning possible!!!
-- Week 15: Advanced NFT ---
Wow what a week. As always in software development I think I know most of it and then I get overwhelmed by details - that I finally solve. Here it was not different. The begining was reading, quite a lot, it was about multidelegate call, msg.sender and tx.origin, and a lot about merkle trees, how we can use these for allowlists. And this opened a whole universe of how gas efficient you can do nft presales/airdrops, which are quite common. Merkle trees are not difficult finally, but you need to understand how they are created and how the libraries from openzeppelin work. I am trying to work with foundry and this created an issue because creating merkle proofs and the merkle root is only possible from javascript with hardhat (oh no!). I cannot call javascript from a smart contract so I passed the necessary values, as text to foundry. Together with merkle trees I learned about bitmaps that contain a hash of the address and the index of the nft. This is a very gas efficient way to store the allowlist. That was really cool! Two guys from our course used calldata and metamorphic contract to be even better with gas efficiency for allowlist, but because selfdestruct is depreciated and I lack of time I stopped reading (maybe if I have a really large airdrop I will use this again).
After reading I created a Advanced ERC721, and I checked it is not possible for a smart contract to mint (but foundry is a smart contract so I excluded the owner from this rule). I added the need of the cost of an nft and added the state of the nft (presale, public, out of run). I implemented the merkle tree and check the proof in a bitmap to safe gas. Added a multidelegatecall by leting the nft inherit from a multidelegatecall. Added the possilbility to add nicknames for NFTs through erc721metadata extension. What really took a long time was a commit reveal scheme, understanding what it is. I used the Bored Apes Yacht Club as a template that uses a provenence string over all nfts and calculates a startposition after all nfts are minted. All NFTs can be seen through the metadata, but you dont know the startposition, therefore you cannot speculate to get a better nft with rare traits. I needed to take care about leading zeros in addresses which safe gas and created some with 3 leading zeros. I deployed the smart contract to Poligon and gave the ownership to a gnosis multisig. Finally I created a ERC1155 that wraps a ERC721 token and gives you for this a ERC1155 token back. WHAT A WEEK! COOL! DONE!
-- Week 16: Applied ECDSA: EIP 4337, 712, ERC20Permit, and others
Yeah! every time when you think it cannot get more difficult, you realize that it can. Ha. But the fun fact is you can work yourself through with a lot of reading, research, selection and patience. That was necessary in this week, which took me longer as expected. I started with the ERC20Permit, which is a great way for a owner to sign a transaction with a private key. The receiver can permit the approval on the smart contract and do the tranfer. This is a great way to save gas, because the owner does not need to approve. Then I was checking how to use signatures in genaral. This was essential and only after I realized how to handle signatures, I understood how gasless transaction can work. With ERC20Permit I learned how to use the EIP712 standard, which is a standard for signing typed messages. Like this a user is able to read a human readable message when signing a transaction. I further read about uni- and bidirectional payment channels. They allow a user to autorize one person to receive eth from a smart contract at a given time, that another person placed to the smart contract, but just if he has the signature. Bidirectional payment channel allow a group to sign who receives what from the smart contracts eth. Really interesting was the OpenZeppelin Workshop 01 and 25 about Meta Transaction with the OpenZeppelin Defender. It basically allows you to call by http OZ Defender and it will call a smart contract implementing ERC2771. Msg.sender will be replaced by the address of the caller. This is a great way to save gas, because you dont need to sign a transaction. I implemented a gasless exchange on this basis, which is really cool. I did that with ChatGPT-4, where I specified the smart contract and I iterated over problems and fixed the smart contract until it was finished - this gasless exchange has an orderbook on-chain, which is not advisable and for educational purposes only. I would need to work more on it, but that would be too much for this task and I stopped here. Finnaly I did a lot of reading about ERD 4337 Account Abstraction - which seems in spring 2023 a huge topic. It allows quite some new functionality like subscription, multisig, password recovery and gasless transactions. I am really looking forward to this. Well this was it. Really a lot of learning!!!!
-- Week 17: Elliptic Curves Math: secp256k1 and r, s, v
* Follows *