A place for talking about the Ethereum Virtual Machine on Farcaster.

Q: How can I write more secure Smart Contracts?

A: By understanding this key principle: Smart Contracts are NOT SOFTWARE.

Smart Contracts are HARDWARE.

“Alex, WTF are you talking about?”… hear me out…

Cofounder, CTO of Cyfrin, Building CodeHawks, Solodit and Updraft.

Previously: Chainlink Labs

Thoughts are my own.

Software Engineers and Product teams approach software this way because it works. When the impact of issues is low, and the cost to fix them is low, the rapid feedback loop of agile development is extremely effective. The benefits outweigh the drawbacks.

It's a no brainer

Consider Hardware.

Developing Hardware is a very different experience. There’s no rapid feedback loop or moving fast and breaking things. When something goes wrong, the impact is NOT low. Phones combust in pockets. Planes go down. Rockets blow up.

How do these issues get fixed? Total recall, or sometimes, they just don’t.

Impact: High,
Cost to fix: High.

The process of idea to execution of a new piece of hardware looks nothing like the process of moving fast and breaking things.

Every minute detail is mapped out and thought about way ahead of time. The testing/QA process is rigorous and grueling. There is no fallback. It needs to be right the first time.

When you think about Smart Contracts, which of these two buckets do they naturally fall into?

In Web3, when a Smart Contract has an issue, the impact is not just a disgruntled user, it’s often millions and, in some cases, billions of dollars.

Fixing it is not a 10-minute hotfix, it’s a locked protocol, emergency upgrade (lol hello governance/more_bugs/centralization/etc), or no fix at all.

Smart Contracts are hardware.

Don’t take my word for it, the evidence is already here.

Look at any of the major Blue-Chip Defi protocols that have lasted more than a couple of years. It’s clear that the development approach is similar to Hardware manufacturers.

@uniswap was a research paper well before any Solidity was written.

Chainlink Labs releases research papers for every primitive they create, well before writing the software. AAVE is formally verified!

If you approach Smart Contract development with a “Move Fast and Break Things” mindset, you’re already doomed.

This is the first mistake engineers make when they come into Web3 IMO.

Approach developing Smart Contracts like Intel approaches chip manufacturing.

Smart Contracts are Hardware.

For the past 20 years, writing software has meant iterating quickly: Getting an MVP out there ASAP, moving fast, and breaking things.

So, what happens when something goes wrong? UI misalignment? No worries: 10-minute hotfix. 404 error? Release a patch.

Impact: Low,
Cost to fix: Low