Hi developers,
In this video, I’d like to talk about the differences between web2 and web3 development.
At the end of the day, it’s the same job. I mean, you still write code.
But not the same way.
If you’re new here, I’m bios42, and on eat the blocks we help web2 developers get into web3.
Let’s jump straight into it.
I still remember the first contract I deployed on the testnet.
Once deployed, I was wondering: Ok, now that it’s live, how can I update the contract?
I wanted to add features to the contract and could not understand why p I had to redeploy the contract on every single update.
So I searched on google: “How to update a smart contract”.
And what I found literally blew my mind.
The blockchain is actually immutable.
You can’t update a contract.
I mean, by default. Because you can actually update a contract, but it’s not the default paradigm.
So back to this moment, it’s like someone had lit a firecracker in my head.
I immediately thought about all the implications/consequences of this new paradigm: the code had to be extensively tested, security would become an issue and it would require deep expertise.
And I was right. It was actually even bigger than that.
So I’d like to summarize some of the major changes I have noticed since I started in blockchain development.
Every point I’ll mention deserves a full video by itself.
So, if you’re interested in going deeper into one of these topics, let us know in the comments below.
First point, as I already mentioned, you cannot update a contract once deployed.
And even if you can find some workarounds to make your contract upgradable, it’s not easy to do. It can open the door to critical issues.
Unless you have a very good reason to make your contract upgradable, you shouldn’t do so.
Immutability is exactly what makes ethereum, and all ethereum like blockchains, interesting for many use cases.
Second point, related to the first one: you’d better extensively test your code.
I mean, reaaaalllly, extensively test your code.
In the web2 space, I was already writing a lot of tests since I’m working with TDD (Test Driven Development).
But when I write a contract, I usually write more and bigger tests on top of my unit test, trying to imagine many different edge cases.
This already saved my life a bunch of times.
Ok, not really my life.
But the project’s life I was working on: An error can cost a lot of money.
Contracts often handle assets worth millions of dollars.
You really don’t want to make any mistakes.
This drives me to the third point: plan for the unexpected.
Once you have tried removing any bug, start thinking about how to recover from a bad situation.
Your contract is super safe.
Ok, great!
But what if…
What could be the worst-case scenario?
What bad could happen?
Once you listed all that, think about the countermeasures you could put in place.
For example, in my last staking contract, I had some circuit breakers that could prevent transfers and get all the funds back in an emergency.
And that was a good idea.
The contract was a bit complex, and a sneaky bug appeared in some complex scenarios.
Thanks to that, we could rescue the funds and airdrop every holder.
Yes, it gives a lot of power to the ownership of the contract and I don’t like that.
But, I feel like it’s a good compromise.
If we see that the contract works fine for a while, we can abandon ownership.
I could also talk about gas optimization, security, and work rhythm.
But we are reaching the end of the timebox.
Once again, if you want more details about these topics, tell us in the comments which are the most interesting for you.
If you want to continue your blockchain journey, check out these videos on the channel.
You’ll find tons of great resources to keep learning.
That’s all for this quick video, thanks for watching and I’ll speak to you soon.
Bye
