When I first heard about Ethereum in 2016 I naively saw it as the future of the internet. I was fresh out of a coding bootcamp and felt like I had some basic understanding as to how the technology worked at a very (very) high level. I proceeded to “invest” and try to sell just about anyone who would listen on what I thought to be the Next Big Thing.

At the time, decentralization felt like the obvious next step in the evolution of technology. Why do we need middlemen? It should be our data and we should be able to move it around as we please! Beyond that, why do we need banks? A trust-less system that allowed for collateralized debt would be a game changer!

As a software manager it is part of my job to find inefficiencies and fix them. However, as I’ve grown I’ve come to learn that some efficiencies are there for a reason — to prevent future inefficiencies. Why do we need PR reviews? Why not just push directly to master?

As systems like MakerDAO, Compound, UniSwap, and many other trust-less decentralized finance platforms emerge, they remove “inefficiencies” in the financial system and allow for seamless exchange and lending. While these systems have worked well at a very small scale, they haven’t been without terrifying software bugs.

Compound Self Liquidation Maker Collateral Liquidation Big Scary ETH Bug That Was Patched Buncha Projects Getting Rekt

These resulted, or could have resulted, in hundreds of millions of USD worth of value being stolen with ZERO recourse. The beauty of a trust-less system is that you don’t need to ask for permission to do things. The code is the law. The absolutely terrifying thing about a trust-less system is that you don’t need to ask for permission to do things. The code is the law.

Writing complex software without bugs is impossible. There are so many unexpected edge cases you will never think of them all no matter how large or small the team is.

Relying on a decentralized, immutable data structure as a ledger for your finances is incredibly terrifying to me. Immutability is an awesome architectural decision. ACID databases are very cool. However, decentralized immutability means that nothing can be done should an unintended action occur with your account.

You lost $4,000,000 because someone hacked an oracle and liquidated your entire ETH position in an autonomous collateral lender? Thoughts and prayers! Aweee you lost $230,000 because someone decided to do something way over your, my, and the developers heads on BurgerSwap (https://www.rekt.news/burgerswap-rekt/)? Thoughts and prayers and why the fuck are you holding $230,000 on a website called BurgerSwap!

BuT yOu cAN rEaD ThE sOuRce cODe!! Yea no shit. But like I said before, no one can think of all the edge cases and map out all of the dependencies within these contracts to determine with certainty whether something is safe or not. Hell, most of these contracts are audited by security firms that verify the “safety” of them before deploying. And they still get pwned!

All of the ways that I’ve thought to combat this remove the decentralization and/or trust-less-ness (?) of the contract. Could you allow token holders to vote on a revocation of the hackers tokens? Maybe if the hacker doesn’t hold the majority at this point. But even if they don’t, what happened to “code is law”. Wasn’t the “hacker” just executing the contract as it allowed?

I still hold crypto, and will continue to do so. But as the days go on and I grow as a developer and person, I can’t help but become bearish about crypto, in its current form, becoming The Next Big Thing.