Blockchain Developer Monthly Newsletter ⛓

The 7th Edition of Blockchain Developer Monthly!

Happy New Year everyone! Markus here. If you've been here before, you can skip this section. If it's your first time, keep reading.

What's this all about?!

Well there are lots of blockchain newsletters and youtube channels out there that will hype you up on the latest NFT project or predicting some new token that's going to the moon.

Less so in the last few months given most of the "tourists" looking to make a quick buck tend to disappear when prices go down. But the builders are still here and so are you and so is this newsletter.

It's still hard though to find newsletters that actually go deep into things that are relevant for developers working in the space.

That's why I created this - a newsletter dedicated to developers who want to stay up-to-date and excel in the world of web3.

In case you aren't already convinced... Being a solidity, blockchain, & ethereum developer is a fantastic career option.

Regardless of whether you love or hate crypto, there's no denying blockchain is an exciting technology with tons of job opportunities. You can work around the world, you get to work on solutions to big problems, and you're on the cutting edge of the tech sector.

But things move FAST.

So staying up-to-date with the constantly evolving ecosystem can be tough. If you're still reading this, maybe you want to be a top-performing developer within the web3 landscape, but probably don’t have time to find, read, and synthesize all the articles, videos and podcasts that come out each month.

So this monthly Blockchain Developer Newsletter was born.

I keep you up-to-date with what's happening within the web3 industry, without wasting your valuable time, by curating the most important articles, guides, news, resources, podcasts and videos from the past month.

This newsletter was inspired by Andrei's Web Developer Monthly + Python Monthly and Daniel's Machine Learning Monthly.

Ok, let's dive into this issue. I hope you enjoy!

Let's dive in. Here's what you missed in January 2023 as a Blockchain Developer…

New Solidity Developer Tools 🛠

With the New Year here it's time for you to add some more tools to your developer toolkit!

As a biohacker myself I'm always keeping an eye on new tools that help Solidity & Blockchain Developers work better, faster, and smarter.

So with that said, here's some new tools for you to give a try this month:

• ChugSplash is a declarative and deterministic framework for deploying and upgrading smart contracts that's available as a Foundry and Hardhat plugin.
• There's also a new Hardhat plugin that makes it easier to use Hardhat and Foundry in the same project. You can use it both for adding Foundry to an existing Hardhat project, and to add Hardhat to an existing Foundry project.
• Here's a guide on how to get a list of every smart contract created by an address, including smart contracts that create other smart contracts a.k.a. "factories".

Smart Contract Security Attacks in 2022 👨‍💻

There were a number of novel smart contract security issues that appeared in 2022, and I thought I'd be fun to give you a rundown of a couple that I found interesting.

In my opinion, one of the most interesting new attacks was: Phantom Functions.

    function depositWithPermit(...) {
        IERC20(token).permit(receiver, address(this), value, deadline, v, r, s);
        IERC20(token).safeTansferFrom(receiver, address(this), value);
    }

Can you spot the issue? It’s actually a tricky one to see.

I’ll give you a small hint: it’s the ‘permit’ line, but only sometimes…

Still stumped? Okay fine, I’ll just tell you.

The issue happens when an ERC20 has a fallback function that doesn’t revert. And actually quite a few ERC20s, including maybe the biggest ERC20 of all (WETH), actually have that.

Now if the permit function on the token doesn’t exist, it will go to the fallback function. And if that doesn’t exist, then the permit call here never reverts even with invalid signatures.

This code was in Multichain (previously known as AnySwap).

Their report can be found here.

The second most interesting new attack was: Read-Only Reentrancy.

Are you familiar with regular reentrancy attacks? If not, here's the gist:

The Reentrancy attack is one of the most destructive attacks in the Solidity smart contract.

A reentrancy attack occurs when a function makes an external call to another untrusted contract. Then the untrusted contract makes a recursive call back to the original function in an attempt to drain funds.

When the contract fails to update its state before sending funds, the attacker can continuously call the withdraw function to drain the contract’s funds.

A famous real-world Reentrancy attack is the DAO attack which caused a loss of 60 million US dollars.

Uhhh sounds pretty bad, right? You can read more about regular reentrancy attacks here.

Luckily you can protect against attacks like this in state modifying functions via reentrancy guards.

But the problem is that view functions typically don’t have reentrancy guards.

When you're building smart contracts you might read data using a getPrice() view function. But the price cannot be trusted in this case due to reentrancy, and there’s no guard since it’s a view function.

So what should we do?

A method to solve this could be allowing other smart contracts to read the state of a reentrancy lock. Generally speaking this is, unfortunately, not yet possible. Alternatively you could add reentrancy guards to all your view functions.

Solidity Deep Dive: Randomness in Ethereum + New Opcode 'Prevrandao' 🥽

'The Merge' upgrade finally brought a new consensus mechanism to Ethereum. Instead of the old Proof of Work, blocks are now produced via Proof of Stake.

Proof of Work finds consensus via block hashes and a process called mining. Prior to The Merge, miners typically would look for specific block-hashes using GPUs. This process was unpredictable and only solvable using brute-force. Hence if you find a fitting hash, you 'proved' some work.

Now you 'prove' some stake instead of work. A miner now is called a 'validator' and each one has to put up 32 ETH as stake. New blocks are proposed by a validator that has the ‘correct’ 32 ETH stake.

And with this Proof of Stake protocol Ethereum has built in some randomness. But why does Ethereum even require randomness? Theoretically you could have each validator be chosen one after another in a pre-defined order, right?

Well no, because such a predictable protocol opens up a range of potential attacks:

• Denial of Service (DOS): If you know in advance who will be the next block proposers, you can more easily launch DOS attacks one by one for the chosen validators. If the order is random, you have less time to plan your attack.

• Selfish Validator Registrations: One could try to register especially advantageous validators that are chosen sooner and game the mechanism to earn more rewards.

• Bribing: You could also try to bribe validators in advance for blocks that might interest you to e.g. censor some specific transactions or not propose a block at all.

• Double-spending: Maybe one of the most critical attacks could be a double-spending attack. If you can predict the order in advance, it makes it easier to plan such an attack through a combination of bribing and simply owning a sequence of validators yourself. And you’ll know exactly which block you’ll be able to try your double-spend attack.

Okay so randomness is important for security. But how is the randomness in Ethereum created?

Good question! The short answer is that you have every validator in a given epoch pre-commit to a random number only computed locally.

The final random number is: every validator’s local random number combined via XOR (explicit or).

The combination with XOR ensures that even just one single honestly computed random number of one of the validators in an epoch will lead to a new unmanipulated random number.

Once an epoch is finished, the newly computed randomness will be used to determine the validators in the next epoch.

Kind of cool eh? Okay maybe I'm using the word "cool" too loosely, but I think it's cool!

Now if you did find this cool and want to learn about how to use the new opcode Prevrandao, you can keep reading in this guide.

My Goodiebag of Random Tidbits 🍬

Here's a few extra pieces of news and tips that I thought was interesting this month!

• Custom errors (compared to revert reason strings) can help significantly reduce the size of your contracts, making it easier to stay under the max size of smart contracts (i.e. the EIP-170 limit of ~24kB).
• Maple Finance v2 has open-sourced their smart contract repositories and published their documentation, and they've provided some interesting commentary on it (honestly I tried summarizing some of these but it's just better to read the linked Twitter thread!).
• The Graph Network is now supporting four new chains: Arbitrum, Avalanche, Celo and Optimism. This means there is added support for Blockchain Developers across these chains, providing access to secure, reliable & decentralized data.

See you next month!

I hope you enjoyed this edition of Blockchain Developer Monthly.

Something missing? Have an idea of what to include in a future post? Let me know.

See you next month,
Markus

By the way, I teach people how to code in Solidity and get hired as a Blockchain Developer in the most efficient way possible. Come check out a few of our Blockchain & Web3 Courses below and try out some of the free preview lessons.