February 27, 2023: Doom and Doomers ππ±
Could Verkle Trees, Upgradeable Contracts, and Goerli ETH threaten Ethereum?
Another week, another batch of purportedly existential threats to Ethereum. We cover the controversy in order of most to least dangerous.
Verkle Trees
Traversable Wormholes
Goerli ETH prices
Verkle Trees
Vitalik Buterin is one of the smartest human beings alive and the spiritual leader of Ethereum.
Vitalik likes Verkle Trees. He wrote a great blog post explaining why.
Without getting too technical, we can loosely explain the concept because so many Ethereans already have at least passing familiarity with βMerkle Trees.β They are commonly used for NFT preapprovals:
Devs construct a βMerkle treeβ containing all approved users
Users are given a βMerkle proofβ they can post to prove they are pre-approved
The proof can be easily validated because it deterministically hashes to a common βroot.β
This is useful because it would cost a lot of gas for a smart contract developer to store an arbitrarily long list of pre-approved addresses. Instead, the developer needs only to encode a simple hashing mechanism and a single root. Far cheaper and more elegant.
Enter Verkle trees. We presume they are a portmanteau of Merkle Trees and the Vector Commitments algorithmic improvement. However, we sleep cozier at night thinking the βVβ stands for βVitalik.β Either way, all you need to know is that the βVerkle Treeβ is a vastly improved algorithm, allowing much larger sets of data to be stored and processed efficiently.
Being able to utilize Verkle Trees could very well solve the Ethereum scaling problem. A challenge with scaling Ethereum is that it currently requires updating the entire βstateβ of the blockchain every time transactions occur, which has grown very complex because of all your degenerate ponzi activity.
If you airdrop $CRV to a thousand addresses, the state has to track a thousand new entries reflecting the new state of everybodyβs account, which is basically a thousand new pieces of data to track.
You can save a lot of effort ifβ¦ sayβ¦ you can compress everybodyβs $CRV balance and store it within a single Verkle Tree. Now you only need to store a root, and update just one root if the account balances get changed. This is a grossly simplified explanation of whatβs called a stateless client, expected to be a major breakthrough to allow ETH to scale with demand.
For this reason, Verkle Trees are prioritized in the ETH roadmap. We just completed βThe Merge,β and we will expect Verkle Trees to hit once we reach βthe Verge.β
Sounds great! Ethereum can scale! Vitalik supports it! Uncontroversial, right?


Well, Curve spoke up strongly in dissent.




Why would Curve be so opposed to instituting the seemingly great Verkle Trees?
Itβs not Verkle Trees specifically that is causing the objection. The issue is that accommodating Verkle Trees will reshuffle how gas is used when accessing smart contracts.
The gas changes would be quite good in some regards. Accessing adjacent storage locations cheaply could allow for some very good gas golfing moving forward.

At present though, current tooling is not prepared for such optimizations. In fact, it would have been completely impossible to plan for these changes when existing DeFi contracts were deployed.
Hence the trouble. Neither devs nor users could have predicted Ethereum would change the rules in such a manner. Previously deployed contracts were optimized for gas usage using one agreed upon set of rules. Teams trusted the rules would not change, and took the risk of deploying their contracts immutably.
The Verge would drastically change the rules. These changes could specifically harm existing contracts which cannot be altered. Curve and Uniswap are two of the most affected protocols, hence Curveβs warning this action is βabsolutely harmfulβ and threatens to βkill DeFi.β

Ethereum devs have played god before in such a manner. During the Istanbul upgrade, core devs imperiously changed the rules in a fashion that killed off functionality to Aragon. The early DAO hardfork also arguably amounted to devs changing the rules to reverse a hack perceived to be existentially dangerous.
In this case, technological solutions exist that wouldnβt retroactively change the rules. The most proper solution would be a double-versioned EVM, where apps deployed before the Verge were executed using the legacy EVM, with newer contracts properly versioned to the newest EVM.


The idea of embedding version info is the subject of stagnant ERC-1702.

The potential to hit a Verge iceberg is still quite distant. We hope the Ethereum core community works to honor the devs who trusted the Ethereum blockchain enough to build and launch major protocols and presume its infrastructure would be reliable.
Early deployers on Ethereum gambled on the stability of the EVM execution layer. At the time most of DeFi at the time had, at best, a one-week time horizon. Curve stunned the world by promising long time horizons⦠four year veCRV locks⦠300 year emissions window⦠and sealed this promise by deploying its contracts immutably. If Curve winds up uncompetitive because they chose to trust Ethereum, then Curve has been made the sucker.
An unfortunate reflection on the state of DeFi is that some people say, βjust upgrade!β If frequent changes to the EVM execution layer are to be expected, then upgradability will have a distinct advantage over immutability. However, we should optimize this the opposite direction. Upgradability turns out to be a pretty major bugβ¦
Traversable Wormholes
This next incident we rank as marginally less concerning. It involves a physics concept thought to be an impossibility⦠traversable wormholes.
Everybody agrees last yearβs Wormhole hack of 120K $ETH was rotten. This past week, the hack was somewhat reversed, by upgrading an upgradable contract. Dan Smith scooped it on-chain:

Of course, counterattacking a hacker is obviously a good thing everybody supports. So how are doomers spinning this as a potential bad thing?

Essentially, any degens paying attention should take this as a major lesson. Today hackers got rugged via an upgradeable contract working as upgradeable contracts are designed to work. Tomorrow it could be anybody who gets upgraded out of their funds.
If you ape into an upgradable contract, your funds are always at risk of being rugged. Your money only exists at the whims of whomever has the keys to the backdoor. If you aped, you should unape.
βNaw, brah-ski, devs havenβt rugged yet! Theyβre trustworthyβ¦β
Upgradable contracts are at the mercy of not just the devs, but also to the increasingly quixotic demands of overtly hostile regulators. The most unprecedented part of the Wormhole reversal is that this counterattack was made at proverbial gunpoint, being compelled by court order.


In this case, weβd agree itβs a nice example of courts doing something good. In fact, if courts routinely demonstrated a track record of going after bad actors and standing up for the powerless, it would bolster their legitimacy within the crypto community. Crypto natives would gladly embrace regulation if authorities demonstrated a long track record of such upstanding behavior.
The problem is the unhinged actions of US regulators is torpedoing any potential whiff of credibility. Weβre instead facing the frightening prospect of a regime in where βGoldmanβ Gary Gensler can compel courts to rug every investor interacting with upgradable contract. It would be a potential bloodbath for retail investors, on a scale that would rival his crooked colleague SBF.
The risk is not even that far-fetched. At the moment, Goldman Gary is preposterously asserting $1T in market value be annexed to him by divine right. This maneuver amounts to an extralegal prohibition of cryptocurrency in the United States. Itβs a stunningly illegitimate overreach, and we hope the courts and Congress promptly subdue this impudent bureaucrat running amok.


Again, if you aped into any protocol with upgradeable contracts, you should unape immediately. Otherwise you face severe risk of being βprotected.β
Goerli ETH
Finally, the lowest level of existential crisis is absurd spectacle of Goerli ETH.
Goerli is one of many testnets. In theory you can use any testnet, but sometimes you might need one in particular due to specific integrations. OpenSea, for instance, has a website operating against the Goerli testnet, useful to preview how an NFT mint might look.
Over the past few months, developers have hated Goerli because its testnet ETH is becoming inexplicably scarce. Many of the faucets are frequently out of service, or trickle out so little Goerli ETH that accumulating enough to test is impractical.
Fortunately some resources still exist for devs with a provable track record:
Goerli ETH is intended to be valueless for all variety of practical reasons. Yet it is scarce, so the unbreakable law of supply and demand means that Goerli ETH is ironically valuable.
Entrepreneurial degens naturally set up a market to buy Goerli ETH.


More than just being scuzzy, the existence of a trading pair for Goerli ETH could theoretically trigger all sorts of legal ramifications for devs whose sole interest is simply shipping and testing on Goerli.


We hope it would be far-fetched to imagine theyβd persecute devs in this manner, but the western world has shown utter contempt towards cryptocurrency developers, to our severe detriment. Would βGoldmanβ Gary argue deploying an ERC-20 token to a testnet is a security? Unlikely, because thereβs not so much in the way of kickbacks from shaking down junior devs. But in US crypto policy, the cruelty is the point.
So the existence of Goerli testnet ETH markets is not at all existentially threatening for Ethereum itself. At most, itβs a marginal concern for developers and possibly a slightly greater concern for fools speculating on the market.
The solution is easy enough. Goerli should simply be put out to pasture after it completes its test run of the Shanghai upgrade. Testnets phase in and out of operation all the time. Wherever clowns get the idea to charge for testnet tokens, any testnet should simply be sunset immediately and replaced with a clean sandbox.
In the meantime, Goerli whales should dump their holdings and donate any profits to support public goods.


Devs looking to avoid testnet theatrics should learn to develop against a forked mainnet or a local Titanoboa environment. Curve famously has no testnet deployments, but instead conducts extensive testing against a local copy of the live mainnet state. Never any trouble securing testnet tokens!
Finally, quit being a knucklehead and ruining this for the rest of us. Donβt set up markets for testnet tokens! It helps nobody and causes heaps of trouble.