Hey there,

It’s been another week of the fellowship and I can’t wait to share the amazing stuff I’ve been up to. This week was all about digging deeper into Solidity basics and understanding the nitty-gritty of writing a secure smart contract. We had to complete the next two challenges in Speedrun Ethereum and I did some readings around Solidity Patterns and the Uniswap Whitepapers (which I did not understand much tbh).

In this challenge, we created our own ERC20 tokens and a ‘Vendor’ that acts as an always-available vending machine to buy and sell these tokens to anyone. This challenge strengthened my understanding of ownership and transfer of ether / ERC20 tokens between contract and user addresses.

When dealing with multiple contracts, such that one contract mints tokens (Token contract) and one contract deals with the buying and selling (Vendor contract) the newly minted tokens have to be transferred from the Token contract to the Vendor contract for the vendor to be able to buy from and sell to the users. Seems trivial to read but this needs to be specified while writing the application code else the Vendor would have zero, zilch, zip, nil, nada, nothing; and you would have a lot of angry unhappy users.

Another important pattern learned from this challenge is the approve() pattern in ERC20. When a user has to sell their tokens to the Vendor, they cannot just send these tokens and get back ether in exchange. They first need to approve the Vendor contract to take these tokens and only then can they sell these to the Vendor in exchange for ether.

Overall, this was a very empowering challenge because I got to create my own ECR20 token which can be used on the chain like any other token. The possibilities are limitless.

https://goerli.etherscan.io/address/0x11cCBc3f15899c119Cfc693387D81adDCaD2Ea87

https://wacky-body.surge.sh/

This was a fun one. There’s a Dice Game which rolls a random number. Calling a roll costs a player some ETH and if the dice rolls a number less than 2, the player gets a prize. And guess what? We got to write a rigged contract which chooses to call a roll from the Dice Game contract only when the player is sure to win.

This contract can be rigged because it derives its source of randomness from block hashes which, well… is not a very secure way of generating random numbers on the blockchain.

I also learned that adding a public visibility to a contract’s state variables automatically creates a getter function for that variable which can be sued to read the variable’s value from another contract. This however does not creates a setter function.

Before doing this challenge, I thought that require() is just like if-else block with perhaps some error handling, but I was so wrong! require() also reverts the transaction when the constraints are not met. This is so much important to make sure the states are unchanged if the required constraints are not met and the unused gas are refunded back.

Honestly, revelations like these keep us grounded, humble, and hungry.

https://goerli.etherscan.io/address/0x819A67D22eD1A6cbf3955e162444ac3DCaDaFA7c

https://probable-eggnog.surge.sh/

Apart from completing the challenges, I also had discussions with my mentor QEDK and went into some rabbit holes on Solidity. Linking the stuff I read below:

• Checks-Effects-Interactions Pattern

• Secure Ether Transfer

• Guard Check

• Reentrancy Guard

• external vs public functions

• send() vs transfer() vs call() for sending ETH (this and this)

• QEDK’s blog posts on Ethereum Part 1 and Part 2

It is so frustrating to learn something as a beginer. So many opened tabs, lingering doubts, broken tests, uncompileable code, and unanswered questions. Feels so far away from what we’re striving to do but these are really the things that inch us closer to them. All of this is worth the “Aha! Now it all makes sense to me” and the Accepted badge on the Speedrun profile.

Personally, reading documentations, Stackoverflow discussions and reading tutorials/articles online have helped me a lot. If I ever had a question, almost always Speedrun Challenge Telegram Channel had it already answered. So a big shoutout to everybody helping out there.

And btw, here’s a link to my Speedrun Profile:

https://speedrunethereum.com/builders/0x2Dc33edAC5F15e328dfFfF98021D365d1C4da620

Let’s see what the weeks ahead have for us.

PS: Whoa! I did not expect I could write all this in a few hours. I love the idea of writing but dread the practice, which makes me self-proclaim myself as a hypocrite. Glad to finally see myself working to remove this label from weighing me down into the eternal depths of ignorance.

Until next week,

Pushkar

Hey there,

It’s been another week of the fellowship and I can’t wait to share the amazing stuff I’ve been up to. This week was all about digging deeper into Solidity basics and understanding the nitty-gritty of writing a secure smart contract. We had to complete the next two challenges in Speedrun Ethereum and I did some readings around Solidity Patterns and the Uniswap Whitepapers (which I did not understand much tbh).

In this challenge, we created our own ERC20 tokens and a ‘Vendor’ that acts as an always-available vending machine to buy and sell these tokens to anyone. This challenge strengthened my understanding of ownership and transfer of ether / ERC20 tokens between contract and user addresses.

When dealing with multiple contracts, such that one contract mints tokens (Token contract) and one contract deals with the buying and selling (Vendor contract) the newly minted tokens have to be transferred from the Token contract to the Vendor contract for the vendor to be able to buy from and sell to the users. Seems trivial to read but this needs to be specified while writing the application code else the Vendor would have zero, zilch, zip, nil, nada, nothing; and you would have a lot of angry unhappy users.

Another important pattern learned from this challenge is the approve() pattern in ERC20. When a user has to sell their tokens to the Vendor, they cannot just send these tokens and get back ether in exchange. They first need to approve the Vendor contract to take these tokens and only then can they sell these to the Vendor in exchange for ether.

Overall, this was a very empowering challenge because I got to create my own ECR20 token which can be used on the chain like any other token. The possibilities are limitless.

https://goerli.etherscan.io/address/0x11cCBc3f15899c119Cfc693387D81adDCaD2Ea87

https://wacky-body.surge.sh/

This was a fun one. There’s a Dice Game which rolls a random number. Calling a roll costs a player some ETH and if the dice rolls a number less than 2, the player gets a prize. And guess what? We got to write a rigged contract which chooses to call a roll from the Dice Game contract only when the player is sure to win.

This contract can be rigged because it derives its source of randomness from block hashes which, well… is not a very secure way of generating random numbers on the blockchain.

I also learned that adding a public visibility to a contract’s state variables automatically creates a getter function for that variable which can be sued to read the variable’s value from another contract. This however does not creates a setter function.

Before doing this challenge, I thought that require() is just like if-else block with perhaps some error handling, but I was so wrong! require() also reverts the transaction when the constraints are not met. This is so much important to make sure the states are unchanged if the required constraints are not met and the unused gas are refunded back.

Honestly, revelations like these keep us grounded, humble, and hungry.

https://goerli.etherscan.io/address/0x819A67D22eD1A6cbf3955e162444ac3DCaDaFA7c

https://probable-eggnog.surge.sh/

Apart from completing the challenges, I also had discussions with my mentor QEDK and went into some rabbit holes on Solidity. Linking the stuff I read below:

• Checks-Effects-Interactions Pattern

• Secure Ether Transfer

• Guard Check

• Reentrancy Guard

• external vs public functions

• send() vs transfer() vs call() for sending ETH (this and this)

• QEDK’s blog posts on Ethereum Part 1 and Part 2

It is so frustrating to learn something as a beginer. So many opened tabs, lingering doubts, broken tests, uncompileable code, and unanswered questions. Feels so far away from what we’re striving to do but these are really the things that inch us closer to them. All of this is worth the “Aha! Now it all makes sense to me” and the Accepted badge on the Speedrun profile.

Personally, reading documentations, Stackoverflow discussions and reading tutorials/articles online have helped me a lot. If I ever had a question, almost always Speedrun Challenge Telegram Channel had it already answered. So a big shoutout to everybody helping out there.

And btw, here’s a link to my Speedrun Profile:

https://speedrunethereum.com/builders/0x2Dc33edAC5F15e328dfFfF98021D365d1C4da620

Let’s see what the weeks ahead have for us.

PS: Whoa! I did not expect I could write all this in a few hours. I love the idea of writing but dread the practice, which makes me self-proclaim myself as a hypocrite. Glad to finally see myself working to remove this label from weighing me down into the eternal depths of ignorance.

Until next week,

Pushkar