100 Days of Web3 (Days 11-20)

Not long ago I decided to take on the 100 days of Web3 challenge, in which I learn something daily about Web3 and blockchain development. I’m glad to say I’ve lasted longer than 10 days in this 100 day challenge. Check here if you’d like to know about what I did in the first 10 days.

Day 11

On day 11, I continued with building the final project for the Smart Contracts 201 course, which was to build a decentralized exchange. I built out some of the core functionality of the exchange such as allowing a user to deposit and withdraw ether into the exchange contract. Then I tested some of this functionality by writing some JavaScript in the Truffle console. In this first test, support for the LINK token was added to the exchange, I simulated a deposit of LINK by a user and then verified that their token balance on the exchange had changed appropriately. Since testing through the truffle console is tedious, I transferred the test to a JavaScript test file and added some more test cases for the core functionality.

Next up was implementing a limit order for the exchange. I created a new solidity contract called Dex and made it inherit from the core contract. The actual orderbook data was implemented using a double mapping structure within the Dex contract. I wrote a limit order function which would create an entry in the orderbook and rearrange the orderbook so that the highest price orders were at the top on the buy side and the lowest price orders were at the top on the sell side. I also implemented several unit tests for the limit order functionality. The functionality was sort of incomplete because while the order was created in the orderbook, the order didn’t get filled if there was a matching order on the opposite side.

Day 12

I finished up with the Smart Contracts 201 course and the decentralized exchange project by implementing the final feature: market orders. This was an interesting challenge because it involved actually filling orders in the orderbook. Depending on the quantity requested in the market order, existing orders in the orderbook could be completely filled or partially filled. Once again, I wrote several unit tests to verify the the market order was working correctly. I did run into an annoying issue with Solidity. Apparently you can only have a limited number of local variables in a Solidity function. I resolved the issue by writing helper functions to reduce the number of variables I needed in the market order function. After completing the code I also deployed the contract to the Ropsten test network.

Day 13

While taking the Smart Contracts 201 course, the instructor recommended taking the Smart Contracts Security course, I so I decided to do that next. While taking the course, I learned about a few famous hacks in crypto history including the DAO hack, the BeautyChain hack and the Parity library freeze. In many of these cases, following a few security best practices would have prevented the issue. Using the checks-effects-interactions pattern protects against the kind of reentrancy attacks which caused the DAO hack. The SafeMath library prevents underflow and overflow issues which caused the BeautyChain hack. Carefully auditing external libaries used in smart contracts could have greatly reduced the impact of the Parity library freeze.

The security course also included a section on smart contract upgradeability which was fascinating. Up until this point, I had thought that smart contracts were immutable and any bugs in them were final. However by using proxy contracts, it is actually possible to upgrade smart contracts by simply making the proxy contract point to a new implementation of the contract. As part of the course, we implemented a basic upgradeable proxy contract. In order to do this, we actually had to write some assembly code in the proxy smart contract. The assembly code used a delegate call to use functions on the implementation contract. Unlike normal calls to other smart contracts, with a delegate call, the implementation contract actually uses the storage of the proxy contract. I suspect it will be useful to learn more about lower level Solidity concepts like assembly as some things are not currently possible without it.

Day 14

Having hammered through the security course in a day, I decided to do a course on Chainlink next. This was my first exposure to the concept of oracles. Oracles allow for smart contracts to access data which was originally outside the blockchain. One of the most common use cases is for contracts to access price feeds, but there are many other possible uses such as generating random numbers. A smart contract can spend LINK (Chainlink) tokens to access oracles. Since Chainlink oracles aggregate data from many different sources, they are decentralized. This is essential because if an oracle simply accessed a single API, it would create single point of failure which would greatly reduce the resiliency of the smart contract depending on the oracle. It would also be a security risk in case a malicious actor took over that single API.

As part of the course, I created a lottery smart contract which accessed Ethereum price feeds and received randomly generated numbers using Chainlink oracles. I found the code fairly straightforward as it involved simply inheriting from a contract provided by Chainlink and calling the specific oracle contract from the lottery smart contract. Prior to taking this course, Chainlink was just another token I saw on the CoinMarketCap site, so it was great to get a better understanding of what it actually does.

Day 15

As most of the courses I’ve taken so far were at the Moralis Academy, I frequently heard references to the Moralis platform, and I decided to look into it more. I went through about half of this introductory course on YouTube here:

During the the first half of the course, I learned about many useful features of Moralis. They abstract away a lot of common features implemented by dapps (decentralized applications) into their library and framework. The particularly impressive and useful features were:

• Implementing crypto login for users on web apps for example with Metamask
• Keeping track of users and their wallet/address information through the Moralis back-end
• Easily interacting with smart contracts and transferring ether through simple JavaScript functions
• Useful Web APIs which provide information about ERC-20 tokens, NFTs, transactions and more.

There is some completed code provided on GitHub from a link in the video description, however since the code is already complete, I couldn’t really code along with what the instructor was doing. I just sort of looked at the code and made sure I understood it.

Since I wanted to do something hands-on for the day as well I followed along with the following YouTube tutorial to build a decentralized exchange with Moralis. It was really just building the front-end part because the back-end had already been built by 1-inch and integrated into Moralis with a plugin.

Day 16

On day 16, I completed the second half of the beginner Moralis course which I had started on the previous day. I learned about more features of Moralis including:

• The Moralis DB (which is basically a managed MongoDb at this time)
• Moralis cloud functions
• Triggers which allow for code to be executed before or after certain actions happen

At the end of the Moralis course, Ivan recommended learning a front-end framework like React as this is what most dapps will use on the front-end. Since my knowledge of front-end frameworks was a bit rusty, I decided I could benefit from a basic React course. It’s not really Web3, but I know that I’m probably going to be using it to build dapps. So I started with the React 101 course from Moralis Academy.

Day 17

I continued with the React course and although it wasn’t really a lesson on Web3, having solid React basics will make it easier for me to build dapps on the front-end. I learned about or reviewed many React concepts including functional components, lifting up state, property drilling, hooks, conditional rendering and retrieving data from web APIs. As part of the course we built an exchange which called the Coin Paprika API. I liked that I could use the Coin Paprika API without signing up or getting an API key. It seems like a good tool to use when building prototypes on the front-end which require information such as coin prices.

Day 18

Having finished the React course, I was on the hunt for another! I decided to take the Ethereum Game Programming course at Moralis Academy next. The first part of this course was building a game using the Phaser game framework. I was really impressed at how this framework lets you create games with just JavaScript on the browser. I followed along with the course, as we built a side-scrolling game where a knight tries to collect as many bitcoins as he can before the time runs out. It was a great experience, because I learned that even with very little game development experience it is possible to build a fun, simple game pretty quickly.

Day 19

On day 19, I started the Ethereum part of the Ethereum game programming course. First, I created an ERC-20 token called Fake Bitcoin (Hahaha). I used the OpenZeppelin library for the ERC-20 token, so I barely had to write any custom code for it. Next I used web3.js in the game to transfer to the user the same number of Fake Bitcoin tokens which they collected during the game. I implemented Metamask integration in the game so that the experience of receiving tokens after game finished was seamless. I also deployed the token to the Ropsten test network.

Day 20

The next section of the course was to implement some power-ups in the game which would be represented by ERC-1155 tokens. Prior to this, I had created both ERC-20 (fungible) and ERC-721(non-fungible tokens), but I had not used ERC-1155 before. ERC-1155 tokens can be thought of as semi-fungible. Basically, rather than a single unique token per token type, several tokens of a certain type can exist. The ERC1155 standard was proposed by Enjin and was really targeted toward the crypto gaming industry. Once again, I implemented the ERC1155 token using the OpenZeppelin library, so I didn’t have to write any custom code to create this token.

Next I created a marketplace smart contract which users would use to buy these power-ups. This was a relatively straight-forward contract where users send ether to the contract using a function which also takes the token type id that they want to buy. The marketplace contract also had to implement the onERC1155Received function so that the power-up token contract allows the power-up tokens to be transferred to the marketplace.

Summary

As with the first 10 days, I learned so much on days 11-20. I really started to get into some interesting stuff like using Chainlink oracles, smart contract security, new token standards and even some game programming. I’m looking forward to learning more as always.