Ethereum today is incredibly congested—it’s even more congested now than it was during the height of the ICO bubble. This is impressive, but also worrying! Ethereum 2.0 is still a ways away, but the tiny island of Ethereum 1.0 is already populated to the point of saturation. Artist’s rendition of Ethereum 1.0 (source) You’ve probably heard that Ethereum 2.0 is going to be sharded. Beyond base scalability improvements, sharding is how Ethereum 2.0 is going to scale to meet demand.  But many people have asked—will sharding really work for DeFi? After all, sharding breaks composability, and isn’t composability the main thing about DeFi? (Money Legos™ and so on.) Let’s draw out this line of thinking.  Ethereum 2.0 is going to create a bunch of shards, which will work like loosely connected blockchains. But all the DeFi stuff will end up living on a single shard, since it all wants to coagulate together. So we’ll end up in the exact same place we started: one huge DeFi shard, massive congestion.  The same crowded island, but a little bigger now. (source) In a sense, this vision is almost certainly correct. But it’s wrong in being alarmed about this: in fact, this is perfectly fine and to be expected! Let me paint a thought experiment for you. Cities, Suburbs, and Farmland Imagine the day that Ethereum 2.0 launches with full smart contracts. On day one, it’s empty, like a fresh and untouched landscape. Eager Ethereum 1.0 settlers disperse across the shards. Ethereum 2.0 on day one. (Source) Will they spread uniformly across this landscape? Of course not! The first settlers will want to band together and form cities.  In cities, individuals live and work together because they benefit from coordination and proximity. In exchange for the increased productivity of living in a city, those settlers are willing to pay more in higher rents and more congestion (in Ethereum, gas prices). But it’s worth it! These early cities are the centers of commerce. It might be too expensive for most people, but that’s okay. Those who benefit the most from being near the center of commerce are incentivized to move there. This first city in Ethereum 2.0 will likely be the DeFi shard. The city-like DeFi shard. Ah, the hustle and bustle of composability! (Source) That DeFi shard will be the place where the major DeFi protocols settle—those that benefit from high velocity and being connected to large liquidity pools for liquidations, flash loans, or whatever. Maybe there will be one major financial shard, like London, or two city shards with their own specializations, like New York City and Chicago. I expect if there is a second city shard, it will be for centralized exchange settlement, separated from DeFi and all of its chaos. City shards will be expensive and high-throughput, with primarily high-value transactions (otherwise the gas cost would be too prohibitive). But isn’t that awful? Wasn’t that what we were trying to avoid? Now normal people won’t be able to use the DeFi shard at all! Ah, but hold on. The other shards will not be empty. Most people will live in the outskirts of the cities. You don’t need to live in Manhattan to occasionally trek up there when you want to buy something exotic. But most of the time, you’ll be just fine living on another shard and making it into the metropolis when you really need to—the DeFi shard is only a few minutes’ cross-shard transaction away.  So where will most people live? I expect there will be two other kinds of shards: suburbs and farmlands. Suburbs are places where lots of people will live at relatively low cost, and have access to decent services—not a ton, but enough to get by for most of their needs. If you want to do something fancy, like get a flash loan to refinance a multi-million dollar Maker vault into a recursively leveraged Compound position, then hey, you might have to take the train to the DeFi shard to do that. But if you want to do something simple at the local corner store, like swap some ETH for DAI or buy some WBTC, that’ll be easy enough. Almost every ERC-20 will be cross-shard tokenized and available in the suburbs, and there will be local MMs for the most popular tokens and simple use cases. And like in real suburbs, most suburban shards will look pretty much the same. Suburbs will see medium-throughput, medium-value transactions. It will be economical for most people to just park their assets here and live out their blockchain lives in middle-class tranquility. The blockchain ‘burbs. For us normies. (Source) Finally, there are the farmland shards. These are the rural areas that are empty of people. If you are a blockchain game that is mostly doing its own thing and doesn’t immediately need to interoperate with other assets, you can just settle all your game actions directly onto a farmland shard. Or if you’re a weather app just dumping a bunch of data on-chain, you’d rather do it in an unpopulated area, because why not? It’s not like that shard is being used for anything important.  Ah, perfect for dumping my homomorphically encrypted supply chain data! (Source) If there are pollutive activities that are uneconomical in cities or suburbs, take it to the boonies. There are no DeFi services or tokens to displace anyway. Out here, no one is all that bothered. Farmland shards allow for high-throughput, low-value transactions to your heart’s content. Blockchain Urban Planning This vision of DeFi in Ethereum 2.0, if true, tells us two things. First, yes, there will be congested shards on Ethereum 2.0! And the most congested shards will be the highest value parts of DeFi that benefit from composability. Nevertheless, DeFi will also expand cross-shard so it can provide some ancillary services in suburb shards, akin to the local branch of a national bank.  But sharding doesn’t mean that activity is uniformly spread across shards. That’s not only impossible—it’s economically stupid. Let high-value enterprises move into the cities, let boring families move to the suburbs, and let farmlands do their thing far away from the valuable real estate. Heterogeneity = economic efficiency. (Source) (This also gives you a sense why programmatically load balancing contracts across shards is unwise! We should assume that protocols and contract deployers are making rational choices about where to live. Uprooting a business from a city center and transplanting it onto farmland to “load balance the city” would be a disastrous mistake.) You can think of sharding as offering a similar vision to interoperability as Cosmos or Polkadot. Many different blockchains, each specialized for certain economic equilibria, with a superhighway connecting them all. Except in Ethereum 2.0’s case, all those shards will speak the same language, share the same tooling, and benefit from the immense community that Ethereum has already garnered. Ethereum 2.0 is a big and challenging vision. It carries a lot of execution risk. But at this point, I don’t think it’s possible for Ethereum to lose its status as DeFi’s largest city. It’s already the Wall Street of crypto, and it doesn’t look like there are any serious contenders to challenge its dominance.  In the meantime, will we have to pin our scaling hopes on layer 2? I see these as shopping malls built on top of Ethereum. They’ll be an improvement, but it’s likely they won’t be enough. Impatient builders may instead construct makeshift suburbs and farmland around Ethereum 1.0, via bridges with other blockchains. In other words, if Ethereum 2.0 takes too long, outsource your minor cities to another blockchain like Serum is doing, or wait for the Cosmos/Polkadot interoperability story to materialize.  Will DeFi wait for Ethereum 2.0, or will the germ just spread wherever it can?  For now, one thing is clear: DeFi is going to be too big for Ethereum as it currently exists today. Where it grows from here, only time will tell. This piece was originally published on Bankless.

Imagine a college friend reached out to you and said, “Hey, I have a business idea. I’m going to run a market making bot. I’ll always quote a price no matter who’s asking, and for my pricing algorithm I’ll use x * y = k. That’s pretty much it. Want to invest?” You’d run away. Well, turns out your friend just described Uniswap. Uniswap is the world’s simplest on-chain market making operation. Seemingly from nowhere, it has exploded in volume in the last year, crowning itself the world’s largest “DEX” by volume. If you haven’t paid close attention to what’s happening in DeFi in the last year, you’re probably wondering: what is going on here? Uniswap v2 volume. Credit: Uniswap.info (If you’re already familiar with Uniswap and AMMs, skip ahead to the section titled “The Cambrian AMM Explosion.”) For the uninitiated: Uniswap is an automated market maker (AMM). You can think of an AMM as a primitive robotic market maker that is always willing to quote prices between two assets according to a simple pricing algorithm. For Uniswap, it prices the two assets so that the number of units it holds of each asset, multiplied together, is always equal to a fixed constant. That’s a bit of a mouthful: if Uniswap owns some units of token x and some units of token y, it prices any trade so that the final quantities of x and y it owns, multiplied together, are equal to a fixed constant, k. This is formalized as the constant product equation: x * y = k. This might strike you as a weird and arbitrary way to price two assets. Why would maintaining some fixed multiple between your units of inventory ensure that you quote the right price? Uniswap by example Let’s say we fund a Uniswap pool with 50 apples (a) and 50 bananas (b), so anyone is free to pay apples for bananas or bananas for apples. Let’s assume the exchange rate between apples and bananas is exactly 1:1 on their primary market. Because the Uniswap pool holds 50 of each fruit, the constant product rule gives us a * b = 2500—for any trade, Uniswap must maintain the invariant that our inventory of fruit, multiplied together, equals 2500. So let’s say a customer comes to our Uniswap pool to buy an apple. How many bananas will she need to pay? If she buys an apple, our pool will be left with 49 apples, but 49 * b has to still equal 2500. Solving for b, we get 51.02 total bananas. Since we already have 50 bananas in inventory, we’ll need 1.02 extra bananas for that apple (we’ll allow fractional bananas in this universe), so the price we have to quote her is 1.02 bananas / apple for 1 apple. Note that this is close to the natural price of 1:1! Because it’s a small order, there is only a little slippage. But what if the order is larger? You can interpret the slope at each point as the marginal exchange rate. If she wants to buy 10 apples, Uniswap would charge her 12.5 bananas for a unit price of 1.25 bananas / apple for 10 apples. And if she wanted a huge order of 25 apples—half of all the apples in inventory—the unit price would be 2 bananas / apple! (You can intuit this because if one side of the pool halves, the other side needs to double.) The important thing to realize is that Uniswap cannot deviate from this pricing curve. If someone wants to buy some apples and later someone else wants to buy some bananas, Uniswap will sweep back and forth through this pricing curve, wherever demand carries it. Uniswap sweeping back and forth through its pricing curve after a series of trades. Now here’s the kicker: if the true exchange rate between apples and bananas is 1:1, then after the first customer purchases 10 apples, our Uniswap pool will be left with 40 apples and 62.5 bananas. If an arbitrageur then steps in and buys 12.5 bananas, returning the pool back to its original state, Uniswap would charge them a unit price of only 0.8 apples / banana. Uniswap would underprice the bananas! It’s as though our algorithm now realizes it’s heavy on bananas, so it prices bananas cheap to attract apples and rebalance its inventory. Uniswap is constantly performing this dance — slightly moving off the real exchange rate, then sashaying back in line thanks to arbitrageurs. Impermanent Loss in a Nutshell This should give you a sense for how Uniswap pricing works. But this still begs the question — is Uniswap good at what it does? Does this thing actually generate profits? After all, any market maker can quote prices, but it’s another thing to make money. The answer is: it depends! Specifically, it depends on a concept known as impermanent loss. Here’s how it works. Uniswap charges a small fee for every trade (currently 0.3%). This is in addition to the nominal price. So if apples and bananas always and forever trade at 1:1, these fees will simply accumulate over time as the market maker sweeps back and forth across the exchange rate. Compared to the baseline of just holding those 50 apples and bananas, the Uniswap pool will end up with more fruit at the end, thanks to all the fees. But what if the real exchange rate between apples and bananas suddenly changes? Say a drone strike takes out a banana farm, and now there’s a massive banana shortage. Bananas are like gold now. The exchange rate soars to 5 apples : 1 banana. What happens on Uniswap? The very next second, an arbitrageur swoops in to pick off the cheaply priced bananas in your Uniswap pool. They size their trade so that they purchase every banana that’s priced below the new exchange rate of 5:1. That means they’ll need to move the curve until it satisfies the equation: 5b * b = 2500. Running the math out, they’d purchase 27.64 bananas for a grand total of 61.80 apples. This comes out to an average price of 2.2 apples : 1 banana, way under market, netting the equivalent of 76.4 free apples. And where does that profit come from? Of course, it comes at the expense of the pool! And indeed, if you do the accounting, you’ll see that the Uniswap pool is now down exactly 76.4 apples worth of value compared to someone who’d held the original 50 apples and 50 bananas. Uniswap sold off its bananas too cheaply, because it had no idea bananas had become so valuable in the real world. This phenomenon is known as impermanent loss. Whenever the exchange rate moves, this manifests as arbitrageurs sniping cheap assets until the pool is correctly priced. (These losses are “impermanent” because if the true exchange rate later reverts back to 1:1, then now it’s like you never lost that money to begin with. It’s a dumb name, but oh well.) Pools make money through fees, and they lose money via impermanent loss. It’s all a function of demand and price divergence — demand works for you, and price divergence works against you. This is Uniswap in a nutshell. You can go a lot deeper of course, but this is enough background for you to understand what’s happening in this space. Since its launch in 2018, Uniswap has taken DeFi by storm. This is especially amazing given that the original version of Uniswap was only about 300 lines of code! (AMMs themselves have a long lineage, but constant product market makers are a relatively recent invention.) Uniswap is completely permissionless and can be funded by anyone. It doesn’t even need an oracle. In retrospect, it’s incredibly elegant, one of the simplest possible products you could have invented, and yet it arose seemingly from nowhere to dominate DeFi. The Cambrian AMM Explosion Since Uniswap’s rise, there has been an explosion of innovation in AMMs. A legion of Uniswap descendants have emerged, each with its own specialized features. Uniswap, Balancer, and Curve trading volume. Source: Dune Analytics Though they all inherited the core design of Uniswap, they each come with their own specialized pricing function. Take Curve, which uses a mixture of constant product and constant sum, or Balancer, whose multi-asset pricing function is defined by a multi-dimensional surface. There are even shifted curves that can run out of inventory, like the ones Foundation uses to sell limited edition goods. The Stableswap curve (blue), used in Curve. Source: Curve whitepaper Different curves are better suited for certain assets, as they embed different assumptions about the price relationship between the assets being quoted. You can see in the chart above that the Stableswap curve (blue) approximates a line most of the time, meaning that in most of its trading range, the two stablecoins will be priced very close to each other. Constant product is a decent starting place if you don’t know anything about the two assets, but if we know the two assets are stablecoins and they are probably going to be worth around the same, then the Stableswap curve will produce more competitive pricing. Of course, there are infinitely many specific curves an AMM could adopt for pricing. We can abstract over all of these different pricing functions and call the whole category CFMMs: constant function market makers. Seeing the growth in CFMM volume, it’s tempting to assume that they are going to take over the world — that in the future, all on-chain liquidity will be provided by CFMMs. But not so fast! CFMMs are dominating today. But in order to get a clear sense of how DeFi evolves from here, we need to understand when CFMMs thrive and when they do poorly. The Correlation Spectrum Let’s stick to Uniswap, since it’s the simplest CFMM to analyze. Let’s say you want to be a Uniswap LP (liquidity provider) in the ETH/DAI pool. By funding this pool, there are two simultaneous things you have to believe for being an LP to be better than just holding onto your original funds: The ratio in value between ETH and DAI will not change too much (if it does, that will manifest as impermanent loss) Lots of fees will be paid in this pool To the extent that the pool exhibits impermanent loss, the fees need to more than make up for it. Note that for a pair that includes a stablecoin, to the extent that you’re bullish on ETH appreciating, you’re also assuming that there will be a lot of impermanent loss! The general principle is this: the Uniswap thesis works best when the two assets are mean-reverting. Think a pool like USDC/DAI, or WBTC/TBTC — these are assets that should exhibit minimal impermanent loss and will purely accrue fees over time. Note that impermanent loss is not merely a question of volatility (actually, highly volatile mean-reverting pairs are great, because they’ll produce lots of trading fees). We can accordingly draw a hierarchy of the most profitable Uniswap pools, all other things equal. Mean-reverting pairs are obvious. Correlated pairs often move together, so Uniswap won’t exhibit as much impermanent loss there. Uncorrelated pairs like ETH/DAI are rough, but sometimes the fees can make up for it. And then there are the inverse correlated pairs: these are absolutely awful for Uniswap. Imagine someone on a prediction market going long Trump, long Biden, and putting both longs in a Uniswap pool. By definition, eventually one of these two assets will be worth $1 and the other will be worth $0. At the end of the pool, an LP will have nothing but impermanent loss! (Prediction markets always stop trading before the markets resolve, but outcomes are often decided well before the market actually resolves.) So Uniswap works really well for certain pairs and terribly for others. But it’s hard not to notice that almost all of the top Uniswap pools so far have been profitable! In fact, even the ETH/DAI pool has been profitable since inception. Uniswap returns for ETH/DAI pool (vs holding 50/50 ETH/DAI). Source: ZumZoom Analytics This demands explanation. Despite their flaws, CFMMs have been impressively profitable market makers. How is this possible? To answer this question, it pays to understand a bit about how market makers work. Market making in a nutshell Market makers are in the business of providing liquidity to a market. There are three primary ways market makers make money: designated market making arrangements (traditionally paid by asset issuers), fee rebates (traditionally paid by an exchange), and by pocketing a spread when they’re making a market (what Uniswap does). You see, all market making is a battle against two kinds of order flow: informed flow, and uninformed flow. Say you’re quoting the BTC/USD market, and a fat BTC sell order arrives. You have to ask yourself: is this just someone looking for liquidity, or does this person know something I don’t? If this counterparty just realized that a PlusToken cache moved, and hence selling pressure is incoming, then you’re about to trade some perfectly good USD for some not so good BTC. On the other hand, if this is some rando selling because they need to pay their rent, then it doesn’t mean anything in particular and you should charge them a small spread. As a market maker, you make money on the uninformed flow. Uninformed flow is random — at any given day, someone is buying, someone is selling, and at the end of the day it cancels out. If you charge each of them the spread, you’ll make money in the long run. (This phenomenon is why market makers will pay for order flow from Robinhood, which is mostly uninformed retail flow.) So a market maker’s principal job is to differentiate between informed and uninformed flow. The more likely the flow is informed, the higher the spread you need to charge. If the flow is definitely informed, then you should pull your bids entirely, because you’ll pretty much always lose money if informed flow is willing to trade against you. (Another way to think about this: uninformed flow is willing to pay above true value for an asset — that’s your spread. Informed flow is only willing to pay below the true value of an asset, so when you trade against them, you’re actually the one who’s mispricing the trade. These orders know something you don’t.) The very same principle applies to Uniswap. Some people are trading on Uniswap because they randomly want to swap some ETH for DAI today. This is your uninformed retail flow, the random walk of trading activity that just produces fees. This is awesome. Then you have the arbitrageurs: they are your informed flow. They are picking off mispriced pools. In a sense, they are performing work for Uniswap by bringing its prices back in line. But in another sense, they are transferring money from liquidity providers to themselves. For any market maker to make money, they need to maximize the ratio of uninformed retail flow to arbitrageur flow. But Uniswap can’t tell the difference between the two! Uniswap has no idea if an order is dumb retail money or an arbitrageur. It just obediently quotes x * y = k, no matter what the market conditions. So if there’s a new player in town that offers better pricing than Uniswap, like Curve or Balancer, you should expect retail flow to migrate to whatever service offers them better pricing. Given Uniswap’s pricing model and fixed fees (0.3% on each trade), it’s hard to see it competing on the most competitive pools — Curve is both more optimized for stablecoins and charges 0.04% on each trade. Over time, if Uniswap pools get outcompeted on slippage, they will be left with majority arbitrageur flow. Retail flow is fickle, but arbitrage opportunities continually arise as the market moves around. This failure to compete on pricing is not just bad — its badness gets amplified. Uniswap has a network effect around liquidity on the way up, but it’s also reflexive on the way down. As Curve starts to eat the stablecoin-specific volume, the DAI/USDC pair on Uniswap will start to lose LPs, which will in turn make the pricing worse, which will attract even less volume, further disincentivizing LPs, and so on. So goes the way of network effects — it’s a rocket on the way up, but on the way down it incinerates on re-entry. Of course, these arguments apply no less to Balancer and Curve. It will be difficult for each of them to maintain fees once they get undercut by a market maker with better pricing and lower fees. Inevitably, this will result in a race to the bottom on fees and massive margin compression. (Which is exactly what happens to normal market makers! It’s a super competitive business!) But that still doesn’t explain: why are all of the CFMMs growing like crazy? Why are CFMMs winning? Let’s take stablecoins. CFMMs are clearly going to win this vertical. Imagine a big traditional market maker like Jump Trading were to start market making stablecoins on DeFi tomorrow. First they’d need to do a lot of upfront integration work, then to continue operating they’d need to continually pay their traders, maintain their trading software, and pay for office space. They’d have significant fixed costs and operating costs. Curve, meanwhile, has no costs at all. Once the contracts are deployed, it operates all on its own. (Even the computing cost, the gas fees, is all paid by end users!) And what is Jump doing when quoting USDC/USDT that’s so much more complicated than what Curve is doing? Stablecoin market making is largely inventory management. There’s not as much fancy ML or proprietary knowledge that goes into it, so if Curve does 80% as well as Jump there, that’s probably good enough. But ETH/DAI is a much more complex market. When Uniswap is quoting a price, it isn’t looking at exchange order books, modeling liquidity, or looking at historical volatility like Jump would — it’s just closing its eyes and shouting x * y = k! Compared to normal market makers, Uniswap has the sophistication of a refrigerator. But so long as normal market makers are not on DeFi, Uniswap will monopolize the market because it has zero startup costs and zero operating expense. Here’s another way to think about it: Uniswap is the first scrappy merchant to set up shop in this new marketplace called DeFi. Even with all its flaws, Uniswap is being served up a virtual monopoly. When you have a monopoly, you are getting all of the retail flow. And if the ratio between retail flow and arbitrageur flow is what principally determines the profitability of Uniswap, no wonder Uniswap is raking it in! But once the retail flow starts going elsewhere, this cycle is likely to end. LPs will start to suffer and withdraw liquidity. But this is only half of the explanation. Remember: long before we had Uniswap, we had tons of DEXes! Uniswap has decimated order book-based DEXes like IDEX or 0x. What explains why Uniswap beat out all the order book model exchanges? From Order Books to AMMs I believe there are four reasons why Uniswap beat out order book exchanges. First, Uniswap is extremely simple. This means there is low complexity, low surface area for hacks, and low integration costs. Not to mention, it has low gas costs! This really matters when you’re implementing all your trades on top of the equivalent of a decentralized graphing calculator. This is not a small point. Once next generation high-throughput blockchains arrive, I suspect the order book model will eventually dominate, as it does in the normal financial world. But will it be dominant on Ethereum 1.0? The extraordinary constraints of Ethereum 1.0 select for simplicity. When you can’t do complex things, you have to do the best simple thing. Uniswap is a pretty good simple thing. Second, Uniswap has a very small regulatory surface. (This is the same reason why Bram Cohen believes Bittorrent succeeded.) Uniswap is trivially decentralized and requires no off-chain inputs. Compared to order book DEXes that have to tiptoe around the perception of operating an exchange, Uniswap is free to innovate as a pure financial utility. Third, it’s extremely easy to provide liquidity to Uniswap. The one-click “set it and forget it” LP experience is a lot easier than getting active market makers to provide liquidity on an order book exchange, especially before DeFi attracts serious volume. This is critical, because much of the liquidity on Uniswap is provided by a small set of beneficent whales. These whales are not as sensitive to returns, so the one-click experience on Uniswap makes it painless for them to participate. Crypto designers have a bad habit of ignoring mental transaction costs and assuming market participants are infinitely diligent. Uniswap made liquidity provision dead simple, and that has paid off. The last reason why Uniswap has been so successful is the ease of creating incentivized pools. In an incentivized pool, the creator of a pool airdrops tokens onto liquidity providers, juicing their LP returns above the standard Uniswap returns. This phenomenon has also been termed “liquidity farming.” Some of Uniswap’s highest volume pools have been incentivized via airdrops, including AMPL, sETH, and JRT. For Balancer and Curve, all of their pools are currently incentivized with their own native token. Recall that one of the three ways that traditional market makers make money is through designated market making agreements, paid by the asset issuer. In a sense, an incentivized pool is a designated market maker agreement, translated for DeFi: an asset issuer pays an AMM to provide liquidity for their pair, with the payment delivered via token airdrop. But there’s an additional dimension to incentivized pools. They have allowed CFMMs to serve as more than mere market makers: they now double as marketing and distribution tools for token projects. Via incentivized pools, CFMMs create a sybil-resistant way to distribute tokens to speculators who want to accumulate the token, while simultaneously bootstrapping a liquid initial market. It also gives purchasers something to do with the token—don’t just turn it around and sell it, deposit it and get some yield! You could call this poor man’s staking. It’s a powerful marketing flywheel for an early token project, and I expect this to become integrated into the token go-to-market playbook. These factors go a long way toward explaining why Uniswap has been so successful. (I haven’t touched on “Initial DeFi Offerings,” but that’s a topic for another day.) That said, I don’t believe Uniswap’s success will last forever. If the constraints of Ethereum 1.0 created the conditions for CFMMs to dominate, then Ethereum 2.0 and layer 2 systems will enable more complex markets to flourish. Furthermore, DeFi’s star has been rising, and as mass users and volumes arrive, they will attract serious market makers. Over time, I expect this to cause Uniswap’s market share to contract. Five years from now, what role will CFMMs play in DeFi? In 2025, I don’t expect CFMMs the way they look today to be the dominant way people trade anymore. In the history of technology, transitions like this are common. In the early days of the Internet, web portals like Yahoo were the first affordance to take off on the Web. The constrained environment of the early Web was perfectly suited to being organized by hand-crafted directories. These portals grew like crazy as mainstream users started coming online! But we now know portals were a temporary stepping stone on the path to organizing the Internet’s information. The original Yahoo homepage and the original Google homepage What are CFMMs a stepping stone to? Will something replace it, or will CFMMs evolve alongside DeFi? In my next post, entitled Unbundling Uniswap, I’ll try to answer this question. Massive thanks to Hasu, Ivan Bogatyy, Ashwin Ramachandran, Kevin Hu, Tom Schmidt, and Mia Deng for their comments and feedback on this piece. Disclosure: Dragonfly Capital does not hold a position in any of the assets listed in this article aside from ETH.

If you’ve spent any time at all on crypto Twitter, you’re familiar with the web3 narrative. It goes like this: in the beginning, the web was “truly decentralized.” Against all odds, the World Wide Web won against the corporatist designs of companies like Microsoft, and cyberspace became the territory of hobbyists and hackers. The Internet was henceforth enshrined as a neutral platform. And any publisher, no matter how small or powerless, was free to set up shop in their own corner of the Web. But eventually, this decentralized Eden fell from grace. Or so the story goes. Now in Web 2.0, 93% of searches happen through Google, 64% of browsers use Chrome, and 79% of social advertising dollars go to Facebook. A handful of companies now effectively control cyberspace. Web3 advocates see public blockchains as the catalyst to reverse this trend. They want to put power back into the hands of users and replace Google and Facebook with open platforms—perhaps platforms that are owned collectively by their users, operated as public commons. Some version of this story has been sold to The Economist, WSJ, Gartner, and pretty much all of the tech press. I believe this story, this decentralization fairy tale, is predicated on an error. It’s the same error that underlies most utopian projects. Let me ask you this: why did Satoshi choose to make Bitcoin decentralized? Actually, it’s a trick question. Satoshi didn’t have a choice. Bitcoin had to be decentralized, or else it wouldn’t have worked. Before Bitcoin, every previous attempt to create Internet-native money either went bankrupt or was forcibly shut down by the government (see DigiCash, E-gold, or Liberty Reserve). So Satoshi made Bitcoin decentralized. He made it use proof-of-work mining to achieve permissionless consensus. He built in a P2P networking model so the network would be decentralized. And, eventually, he disappeared from the project entirely, so it would have no ostensible leader. He did this so Bitcoin could survive and have a chance of fulfilling his vision of permissioness decentralized money. So here we are today. Bitcoin is a $100B+ currency, and it has spawned a renaissance of hundreds of cryptonetworks, all trying to innovate in digital finance. And now, invoking the spirit of Satoshi, they all argue and bicker about which of them are the most decentralized. “Look how centralized your mining pools are!” “You’re one to talk with your block size, you shitcoiner.” “Well we have no pre-mine so we’re the real decentralized ones.” What’s going on here? Why are they doing this? In this article, I want to suggest: maybe we should stop worrying so much about decentralization. I know this is possibly the least popular position I could take in crypto, but before you reach for your pitchfork, hear me out. I think by the end of this piece, you’ll understand where I’m coming from. (And hopefully elect not to make me a human sacrifice.) (Note: I recorded an audio version of this article if you prefer listening.) Maxwell’s Bitcoin Daemon Entertain a thought experiment. Imagine a parallel universe where your experience of Bitcoin was all an illusion. All of your direct experiences of Bitcoin were the same—it ran the same software, you clicked the same buttons, your UTXOs showed up on block explorers, all the command line interactions were the same. But there’s no decentralized network, there’s no P2P anything, there’s no actual decentralized consensus. Every Bitcoin transaction just runs on one giant Postgres database run by some dude in Canada. (If you’ve actually read low-level Bitcoin code, then suspend your disbelief here for a second.) All of the miners, the consensus, the hash rate explorers, they’re all just pinging this guy’s server. Whenever someone mines a block, they send it to the Canadian guy, and he inserts the block into his database and forwards it to everyone. Every external feature of the system looks exactly the same! The monetary policy, the block time, the scarcity, all of it. We still have a block size debate, we still have Twitter trolls, we still have Craig Wright, and we still have an inexplicable link between Bitcoiners and carnivorism. It’s just not “decentralized.” That part is a mirage. How would that world be different? What actual facts about the Bitcoin system would be different from the Bitcoin we know today? What features does Bitcoin have in our world that it doesn’t have in this thought experiment? Think carefully about this. Here’s the answer: almost none. It’s just as scarce, just as hard, just as much “better than gold.” The only material difference is one of risk: that maybe someday the Canadian police could kick down this guy’s door and make him turn off Bitcoin. That would kill Bitcoin. That cannot be allowed to happen. That’s why Bitcoin is decentralized. It’s decentralized to survive attempts at censorship, manipulation, or shutdown. But other than that, Bitcoin’s decentralization doesn’t actually do anything. Of course, it’s important for its image and its narrative—if it were not decentralized, at this point we would not see it as legitimate. But all of the material features of the system would basically be the same. Thankfully, there’s no Canadian guy who controls Bitcoin. No one can turn Bitcoin off, and that’s great. But this perspective reveals something important about decentralization. Satoshi made Bitcoin decentralized to solve a specific problem: that previous forms of Internet money kept getting shut down. A decentralized form of money is resilient to insolvency, attack, or censorship. But decentralization wasn’t itself the point. It was just a means to an end. The point was to make a form of Internet money that worked! To Satoshi, decentralization was valuable insofar as it mitigated some other fundamental risk: censorship, platform security, corruption, etc. It’s the properties decentralization gives us that we care about, not decentralization itself. You cannot compete on being more decentralized As a crypto VC, I often hear from projects that claim they’re going to be “X, but decentralized.” Usually, this is the telltale sign of a bad pitch. Here’s the problem with it: decentralization is a global, emergent property. These properties are almost impossible to compete on. There’s a simple framework for thinking about the properties of a network that I first learned from Nathan Wilcox. There are two axes: a property can be either global or local, and it can be either direct or emergent. Credit: Tony Sheng Q1: local and direct properties. Think the local weather. It’s local to your city, and everyone in your city feels it, so it’s direct. People frequently choose which city to live in based on local and direct properties like the weather. Q2: local and emergent. Think the voter turnout in your city. People in your city know what the voter turnout is, and it’s good for this number to be high, but nobody actually feels it directly. Even though people care in an abstract sense about civic engagement, it’s hard for cities to compete on having better voter turnout. Q3: global and direct. Think global warming. Everyone in the world feels global warming directly, to differing degrees. But it’s hard for people to coordinate around solving the problem. That said, everyone feels it and everyone responds to its consequences. Q4: global and emergent. These are the most insidious properties; they apply to everyone, but nobody experiences them directly. An example would be something like “privacy.” Not the kind of “your neighbors can see through your window” privacy, but more like “multi-billion dollar companies have lots of data on you, which is weird and uncomfortable, even though nothing obviously bad seems to happen because of it.” And here is the problem. Decentralization is in the last category: it’s global, and indirect. Nobody feels it. You can feel latency, you can feel transaction fees, but networks ostensibly feel the same whether they’re centralized or decentralized. If the decentralization of your network drops, how would your users even know? As a general rule, it’s almost impossible for products to compete on the basis of global, emergent value propositions such as decentralization. Now, you might counter: “This is not about competition between products, Haseeb! This is about building a better Internet!” Fine! Go build a better Internet by yourself in your own personal Mastodon server. But that’s not enough for you—you want the world to join you. And rightly so! If you want that, you need to compete for the world’s attention, and you must compete on the merits. Decentralization in this context is not an advantage; it is a handicap. So be it. You can still win, if decentralization actually lets you do things you couldn’t otherwise do. This is why Bitcoin won despite being a decentralized network. It enabled something genuinely new: the permissionless transfer of uncensorable money. And Bitcoin has proved its value by being alive and well today, more than 10 years later, having successfully evolved past its unseemly adolescence (Mt. Gox, The Silk Road, darknet markets). Bitcoin survived because it is decentralized. But let’s be more specific. Many advocates claim that it’s the developers who will choose this new world. It’s the developers who are fed up with the walled gardens of the modern Internet. It’s the developers who’ll propel us into the decentralized future. Okay. Let’s look closely at that. We know developers today have a tough time building on decentralized blockchains: they’re slow, expensive, hard to use, and blockchains don’t have that many users yet. But the decentralization advocates will counter: don’t you know the Twitter API story? Twitter originally had an open API, but then when they shut it down, all of the entrepreneurs who were building on them had the rug ripped out from under them. Entrepreneurs don’t want to use APIs owned by someone else! That’s why web3 will win. But here’s the problem: developers don’t care about “decentralization” either. When a developer is evaluating whether to use Linux, npm, React, or Twilio, they don’t give a damn whether they’re decentralized or not. Developers care about risk. They want to minimize technical risk. They want to minimize the risk of their APIs dying on them. But they also want to minimize the risk that their users migrate away from the platform (or never show up to begin with); they care about the risk that the underlying tech breaks; they care about the risk that the tooling degrades or never improves, and so on. Risk is a multidimensional vector. Decentralization mitigates some risks, but not others. I guarantee you that developers today are more comfortable building on what’s left of Twitter’s APIs than they are building on top of public blockchains. Twitter has 38M accounts regularly using their APIs, while total Dapp users are still well below 1M. And to be clear, decentralization lowers some risks! The risk of censorship or shutdown are lower in a decentralized system. But are these really the primary risks I care about as a developer, rather than uptime, cost, or user churn? It depends on what I’m building! And what risks does decentralization increase? What does it do to my P99 response time, or what’s the chance that fees spike on the network so my users go elsewhere? Is that set of trade offs worth it for me as a developer? Look, I’m the first to celebrate the fields that crypto has disrupted so far. Crypto has brilliantly used its censorship-resistance to attack money and decentralize banking and finance. Brilliant! What do people hate more than banks? But the web3 story says: nevermind all that. Instead, we should try to decentralize Uber and Airbnb, you know, two of the most beloved products in the world that just got started upending stagnant, decades-old pre-technological industries. And Google, you say? You mean one of the most trusted brands in the US? Sure, let’s try to re-implement the most difficult computer science and data problems imaginable on Ethereum, the technological equivalent of a graphing calculator. Decentralization is valuable when it lets you do new things fundamentally better, not old things fundamentally worse. Web3 advocates are trying to pick a fight with the most beloved products in the world while handicapping themselves with decentralized architectures. If you want to win a fist fight, you probably shouldn’t choose the strongest guy in the room, especially when you’ve got one hand tied behind your back. Innovate against products that suck. There are no shortage of them in this world. You’ll win if—and only if—decentralization is a genuine advantage. But is it really decentralized? It’s vacuous to ask whether something is “really decentralized.” I wish this question would go away. Let me give you two examples that illustrate why invoking the D-word is so unenlightening. Decentralized Finance (DeFi) is commonly claimed to be more secure because it’s “decentralized.” By this they mean its code is implemented in smart contracts directly on a public blockchain. Any normal programmer would retort: wait, why would it be secure just because it’s written in code? And of course, nothing about DeFi inherently provides security! In fact, a single bug in these programs could wipe out all of the money inside. Just look at the 0x hack, where an attacker could have stolen all of the money in the system! Then of course there is the DAO hack, the Bancor hack, the bZx attacks—history is littered with examples like this. There is nothing at all inherent about DeFi that makes it secure. Security starts with audited, open-sourced code that is written with best practices and, ideally, formally verified. But the number one thing that makes something secure is just being battle-tested with a lot of value at stake for a long time. Just the same as with centralized systems. Or let’s take another problem that is close to my heart: the oracle problem. People lose their common sense when it comes to the oracle problem, so it’s a good place to reality-test. Put simply, the oracle problem asks: how can a blockchain learn about things that happened outside of it? By definition, someone has to report that information to the blockchain, but who do we trust to report that data, and how do we know the data is correct? Framed this way, the “oracle problem” is a question even a child can understand: how do we know someone is telling us the truth? Let’s take Maker’s V1 oracle system. It essentially consisted of 20 addresses, most of which were anonymous, pushing prices on-chain. The oracle reported the median of all of these 20 prices. You might be tempted to ask “is that decentralized?” This is the wrong question. The right question to ask is: what are the risks of believing what this oracle tells us? What is the cost to manipulate the oracle? Whose reputations are involved? What has been the value at stake so far, and how long has the system functioned correctly? Whether it is decentralized or not is irrelevant to what we actually care about, especially if censorship is not the principal risk to the system. Take a step back for a second. How is the oracle problem solved in the normal world? When someone wants to know the result of a sports game, what do they do? They probably check ESPN. How centralized of them! And why do they trust ESPN’s scores? What complex crypto-economic game is ESPN playing such that we are comfortable trusting them? One answer might be: well, if ESPN publishes an incorrect score, someone can sue them for damages. ESPN’s bank account can be appropriated by the legal system, so that’s the incentive for ESPN to behave honestly. Thus, we have good oracles thanks to the threat of litigation against ESPN. This analysis is tempting, but it’s not quite right. What do you think people would do for on-chain oracles if ESPN started publishing game results onto Ethereum? I’ll tell you: people would just use the ESPN scores. They’d use them instead of Chainlink or Augur or any of these other supposedly decentralized oracles, because they’d trust ESPN’s scores. This would be true even if ESPN expressly disavowed any legal liability for those scores! Why? Why would people trust ESPN even though it’s not decentralized? (Saying it out loud, it suddenly sounds like a stupid question.) Everyone knows why we trust ESPN’s scores: because of reputation. The value of ESPN’s reputation is so great that we understand ESPN wouldn’t jeopardize it. It transcends anything as simple as “they have X dollars at stake, but if they corrupt the oracle they could make Y.” In some sense, ESPN’s reputation backs every score they ever post. They have the same X dollars at stake for the entire lifetime of their business. You could think of this as somehow cross-margining all of their claims with all of the money they will ever make! You can’t do that with staking or bonds or any of the other craziness that people demand in crypto-economic games. Reputations are precisely how iterated games enable long-term value creation. Without reputations, there wouldn’t be enough capital in the world for us all to trust each other. So what of Maker’s oracle system? Why do so many products in DeFi use it? I don’t think it’s because it’s the “most decentralized.” I think the real answer is simple: reputation. People trust Maker’s reputation. Of course, they also all know that technically, 15 individuals could collude and run off with the money! (And just as true, a single developer at ESPN could probably post a fabricated game score.) But I think people deep down intuitively understand that Maker—the brand, the DAO—has a reputation to keep up, no differently than ESPN does. And that reputation, in some way that’s hard to quantify, backs every price it ever posts on-chain. In some abstract sense, the Maker system has much more economic value behind its oracle than a naive system that requires bonds and slashing. If we accept the notion that DAOs can be like companies, why wouldn’t we be willing to consider that DAOs can have reputations worth protecting? Now, were MakerDAO a monopolist, we intuitively understand that its reputation would carry less weight. But MakerDAO leaves its front doors open to exit through global settlement. If MakerDAO messes up or is manipulated, its users won’t come back. Many DeFi projects have chosen the Maker oracles despite their flaws. And to be clear, I don’t think Maker’s oracles are anywhere near the optimal oracle design. But they work! And developers intuitively understand why the Maker oracles are trustworthy. Many researchers would consider it anathema to make such an imprecise security claim. If it’s not quantitative, if it’s not “X times Y = Z,” then it’s not proper cryptoeconomics. I’ll say this: I don’t give a damn if your oracle is decentralized. I care if your oracle works under the threat model I care about. Both Chainlink and Augur have failed pretty badly in the past, despite being more decentralized than Maker’s oracle. I don’t think the Maker oracle is perfect. But it’s a lot better than most of what we see today. Decentralization is not a binary But here’s another problem with asking whether something is “truly decentralized”: decentralization is not a yes-or-no question. If you need a network that will survive targeted attacks by three-letter agencies, then probably even Bitcoin isn’t good enough. But most people don’t need that. Only you know how much decentralization you need, and any more decentralization than that probably isn’t doing anything. Understand, at the margin, decentralization does not linearly reduce risk. It’s more like an S-curve. The first little bit of decentralization doesn’t really accomplish anything. Take Napster for example—Napster was kind of decentralized, in that it didn’t store files on their own servers. But Napster acted as the search index that let people discover other people’s files. So if someone shut down the Napster servers (as happened in 2001), they basically shut down everything. All the little P2P elements of the Napster design were basically window dressing, because the whole system could be trivially foreclosed from the top. Your early attempts to decentralize don’t accomplish anything until you’re decentralized enough to not be censored. It’s like trying to make a barrel waterproof—the first little bit of sealant doesn’t do anything until you actually plug every hole. At that point, you hit the elbow of the decentralization curve, where suddenly all the work you’re putting in makes a big observable difference to your shutdown risk. Then, after you climb up the S, decentralizing the governance, the token ownership, the admin hooks, you hit a plateau where the system is basically censorship-resistant. You can invest more into distributing the hash rate further, or adding more nodes to the P2P system, or mitigating selfish mining or whatever, but for the most part, any change at the margin doesn’t actually change the properties of the system that much, for anyone. None of those systems can be taken down by script kiddies, and probably all of them can be taken down by a motivated nation state. Most of the arguments about decentralization at this end of the spectrum are just point-scoring. Where do you think your favorite project is on this S-curve? I’d argue that most of the large decentralized networks are closer to the plateau than most people like to admit. Bitcoin is more decentralized today than Ethereum, certainly! Unlike Bitcoin, Ethereum’s inventor is still around to steward the project, and it has frequent planned upgrades. But on the spectrum of risk, Bitcoin is actually not that much further along. Both Bitcoin and Ethereum can be destroyed by nation states, and neither can be destroyed by organized actors on the Internet. All I’m saying here is that there are diminishing returns to decentralization. This is obvious marginal analysis, but people seldom apply this to the concept of decentralization itself. Hence why we get neverending series of papers and blog posts sneering at how blockchains’ P2P networks and governance aren’t truly decentralized. It’s also possible that protocol risks don’t always decrease with decentralization! Decentralizing too fast also can introduce new risks that didn’t previously exist. I’ve never seen a centralized server that had a 51% attack, or a frontrunning vulnerability, or a fee sniping attack. And of course, you should not underestimate the power of responding quickly to a bug by shutting off your system. Centralized systems can much more effectively respond to threats and organize around technical leaders. I’m reminded of how the computing industry rallied around its leadership in the wake of the Spectre and Meltdown bugs. In the face of industry-shaking vulnerabilities, swat teams across Intel, Microsoft, and Linux worked on patches while carrying out an industry-wide disclosure embargo. And in retrospect, it worked pretty well! This would have been much harder in a truly decentralized regime. Angela Walch, a law professor at St. Mary’s University, argues in Deconstructing Decentralization that a “genuinely decentralized” project could not have secrets like this. In her words: “secrets reveal centralization.” “The bug fixes, secret developer meetings, and mining pool concentration […] all reveal sites of concentrated—rather than diffuse—power. Yet in uncritically describing blockchain systems as decentralized, we skip over all of that.” She’s absolutely right on her premises! (Although I reject the binary centralized-decentralized distinction.) But I arrive at a different conclusion: what this tells us is that the optimal equilibrium for a project is not currently “100% decentralized.” Climbing further up that S-curve yields diminishing returns, and the juice isn’t worth the squeeze yet. That all having been said, there are many networks that failed to make it all the way through the decentralization S-curve. IOTA comes to mind for me; I’m sure you have your own favorite shitcoin. If you need to cross this chasm but fail, then decentralization really does matter. But the biggest risk to many of these networks is not that their governance is too centralized; it’s that their governance is too incompetent. Sure, I want the governance of my blockchain to eventually be decentralized! But if you give me the choice, I’ll take world-class centralized governance over crappy decentralized governance any day of the week. Beyond decentralized purity culture Despite all this, crypto communities love to point at each other and claim their competitors are “not really decentralized.” In a way it’s a perfect attack, because anything can always be more decentralized. It’s the original sin that every project carries. It transmutes decentralization into a virtue of purity, a universal moral failing, a ritual of self-flagellation. But this decentralization purity culture is not just exhausting—it’s counterproductive. I know I’m poking a bit of a hornet’s nest here. So let me be clear. Bitcoin would never have become what it is today, were it not decentralized. There is no other path to creating Internet-native digital gold. But I don’t want to see the best minds of my generation obsessing over this single dimension and lose sight of the most important problems to solve. Before we worry about decentralization, let’s worry about building things worth decentralizing in the first place. Let’s not forget, no one actually wants this stuff yet! No one knows what problems it will actually solve! It’s all still weird and complicated and impossible to use! I agree with Jesse Walden on this point: projects ought to progressively decentralize as they figure out product market fit—that is, once they figure out what’s actually valuable to build. But for most everything in this space, product market fit is still a long way away. Until then, I think we can obsess a little less about being perfectly decentralized. Our focus should be on innovating and building better infrastructure for the digital economy. That’s the real goal, if you ask me. Decentralization is merely, at times, the means to that end.

By Haseeb Qureshi and Ashwin Ramachandran It was August 2017. The price of Ether was near an all time high, the Ethereum blockchain was exploding with usage, and the chain was buckling under the ever increasing demand. Researchers and developers were frantically searching for new scalability solutions. At blockchain conferences around the world, developers debated scaling proposals. The Ethereum community was desperate for a solution. In the middle of this frenzy the first version of the Plasma paper was released, promising a layer-2 scaling solution that could handle “nearly all financial computation worldwide.” TechCrunch reporting on Plasma Fast forward to 2020. Ethereum is as slow as ever, and yet it has survived all the so-called Ethereum killers. Ethereum 2.0’s launch date keeps receding further into the future, and Plasma seems to have disappeared entirely with many development groups shuttering operations. And yet, new solutions such as optimistic and ZK rollup are being hailed as the best scaling solutions. But memory of Plasma seems to have vanished without a trace. So who killed Plasma? Let’s go back to what it was like in early 2017. Ethereum had just gone mainstream for the first time, and there was limitless optimism about what would soon be possible. It was claimed that all valuable assets would soon be tokenized. Meetups in San Francisco were standing room only, and crowds materialized whenever Ethereum was mentioned. But Ethereum wasn’t scaling. In the middle of this craze, Vitalik Buterin and Joseph Poon published a paper, where they introduced a new layer-2 scalability solution called Plasma. Vitalik and Joseph Poon introduce Plasma at a meetup in San Francisco Plasma claimed to allow Ethereum to scale to Visa-level transaction volumes, and its bold claims triggered a wave of developer and community excitement. Soon after, the Ethereum research community rallied around Plasma as the salvation to Ethereum’s scaling woes. But what exactly was Plasma, and why didn’t it end up fulfilling its promises? How does Plasma work? The original Plasma paper described a mechanism for constructing a MapReduce “tree of blockchains”. Each node in the tree would represent a unique blockchain that was connected to its parent, and all of these blockchains were arranged in a massive hierarchy. This initial specification, however, was vague and complex. Soon after its release, Vitalik simplified the spec in a new paper appropriately named MVP (Minimal Viable Plasma). The Plasma “Tree of Blockchains” MVP proposed a stripped-down version of Plasma: a simple UTXO based sidechain that would be safe under data unavailability. But what is a sidechain? And what does it mean for data to be unavailable? Before we delve into Plasma, let’s walk through what these terms mean. A sidechain is simply a blockchain that is attached to another blockchain. Sidechains can be operated in many different ways, such as by a trusted third-party, a federation, or a consensus algorithm. For example, Blockstream participates in a federated sidechain on the Bitcoin network called Liquid. Liquid allows for higher transaction throughput, which it achieves due to a tradeoff in its trust model. Users must trust the federation not to collude and steal funds. The chain operators in this context are the various members of the Liquid federation, such as Blockstream the company. Visualization of sidechain transfers (exemplified by Liquid). Credit: Georgios Konstantopoulos A sidechain is attached to a larger blockchain (like Bitcoin) via a two-way peg. Users can deposit funds on the sidechain by sending them to a particular address or smart contract on the main chain. This is referred to as a peg-in transaction. To withdraw funds, users can perform the same operation on the sidechain to retrieve their funds on the main chain. This is referred to as a peg-out transaction. But how does this relate to Plasma? As we saw in the example above, moving funds out of a sidechain requires one critical component: trust. Users must trust the operators of the sidechain not to abscond with funds. But isn’t the main feature of blockchains trustlessness? What if users want to interact with a sidechain without trusting its operators? This is precisely the problem Plasma was created to solve. Plasma was designed to minimize the trust required of sidechain operators. That is, Plasma prevents funds from being stolen even if operators (or a consensus majority) misbehave. But even if operators can’t outright steal funds, sidechains have another problem. What if the sidechain operators publish a block header, but refuse to publish the underlying transaction data? That would prevent anyone from verifying the correctness of the sidechain. This concept is known as data unavailability. Plasma attempted to keep users safe even if operators withheld transaction data — in the event that an operator refuses to release data, all users would still be able to retrieve their funds and exit the sidechain. Plasma made big promises about its security and scalability. It’s no surprise then that during the bull run of 2017, it was widely believed that Plasma would solve Ethereum’s scaling problems. But as the market sobered up in 2018 and the blockchain hype collapsed, a more realistic picture of Plasma began to crystalize. When it came to real-world deployments, Plasma posed more problems than solutions. The first problem was that each user had to monitor and verify all transactions on the Plasma MVP chain to detect and exit in the case of malicious operator behavior. Transaction verification is expensive, however, and this monitoring requirement added significant overhead to participating in the Plasma chain. Researchers also realized that it’s difficult for users to exit a Plasma chain. When a user attempts to withdraw funds from a Plasma MVP chain, they must submit an exit transaction and then wait a set period of time. This is known as the challenge period. At any time during the challenge period, any user can challenge another user’s exit by providing a proof that the exit is invalid (such as that they’re minting fake coins or stealing someone else’s coins). Thus, all exits can only be processed after the challenge period is over, which takes up to 1 week in some proposals. But it gets worse. Remember, even if an operator withholds data, we want users to be able to withdraw their funds from the Plasma chain. MVP handled this in the following way: if Plasma transaction data was withheld, each user needed to individually exit their own money based on the Plasma chain’s last valid state. (Note: to avoid a malicious operator frontrunning honest users, exits are prioritized in order of how long ago they last transacted.) Growth of Ethereum storage. Credit: Alexey Akhunov In the worst case, if all users needed to exit a Plasma chain, the entire valid state of the chain would have to be posted on the Ethereum mainnet within a single challenge period. Given that Plasma chains can grow arbitrarily large, and that Ethereum blocks are already near capacity, it would be almost impossible to dump an entire Plasma chain onto the Ethereum mainnet. Thus, any stampede for the exits would almost certainly congest Ethereum itself. This is known as the mass exit problem. As prices began collapsing in 2018, Ethereum followers started to realize that Plasma MVP wouldn’t be the silver bullet scaling solution they’d hoped for. There was simply no way to overcome its weaknesses. Plasma MVP was a dead end. All the while, Ethereum continued to struggle under its transaction load, and Ethereum 2.0 was still many years away. The next generation of Plasma In mid-2018, as prices continued to crash, Ethereum’s research community continued their attempts to improve on Plasma, iterating on the Plasma MVP design. The new version they came up with was termed Plasma Cash. According to Vitalik, who was one of its main designers, Plasma Cash would allow for arbitrarily high transactions per second and solve the problems that plagued its predecessor. Some even claimed that this new design would achieve hundreds of thousands of transactions per second. First, let’s remember the issues with Plasma MVP. In the case of operator misbehavior, there was a mass-exit problem Users had to wait an entire challenge period before withdrawing Users had to monitor all transactions on the Plasma chain Plasma Cash held one primary advantage over MVP: by using a different data model, Plasma Cash could avoid the mass exit problem entirely. In Plasma Cash, all coins are represented as non-fungible tokens (NFTs), which makes it much easier to prove ownership of a set of coins. Simply put, users are responsible for proving ownership over their own coins and no one else’s. As a result, users only need to monitor their own coins and not the entire Plasma chain. Plasma Cash also presented a new interactive challenge system that allowed users to easily withdraw funds in the case of operator misbehavior. Utilizing a new Merkle tree construction, known as a Sparse Merkle Tree, users could easily authenticate a coin’s history and ownership using inclusion proofs. In the case of operator misbehavior, a user would only need to post on-chain proof that they currently owned the coin (consisting of the 2 most recent transactions and their corresponding inclusion proofs). However, Plasma Cash introduced a whole new set of problems. Primarily, malicious users or past owners of a coin could issue faulty withdrawal attempts. Because users were required to prove ownership of their own coins, it was up to these users to actually catch and challenge fraudulent withdrawals of their money. As a result, Plasma Cash, like Plasma MVP, required users to remain online at least once every two weeks to catch faulty withdrawals during their challenge periods. Additionally, to prove ownership of a coin, users would have to maintain that coin’s entire history and corresponding inclusion/exclusion proofs, leading to ever increasing storage requirements. By late 2018, the price of Ether had hit rock bottom, and the utopian crypto optimism had evaporated. Plasma Cash, while an improvement over MVP, was not the Visa-scale solution Ethereum was promised, and its MapReduce “tree of blockchains” was now little more than a pipe dream. Most companies developing clients for Plasma Cash halted work, and their implementations were archived in a half-finished state. The Ethereum community was in limbo. While new Plasma constructions continued to emerge and marginally improved on their predecessors, the Ethereum community failed to rally behind any of them. It seemed that Plasma was dead. Enter Rollups Just as confidence in layer-2 hit bottom, a GitHub repo named roll_up was made public by a pseudonymous user known as Barry Whitehat. This repo described a new type of layer-2 scaling solution: a Plasma-like construction with “bundled” up transactions, where instead of relying on operator trust, the correctness of the bundle could be attested to using an on-chain proof — a SNARK. This SNARK ensures it is impossible for an operator to post malicious or invalid transactions, and guarantees that all sidechain blocks are valid. Soon after, Vitalik released an improved version of Barry’s proposal he termed zk-Rollup. zk-Rollup became one of the highest ever viewed posts on Ethereum’s research forums. Vitalik’s proposal introduced a solution to prevent the data availability issues that plagued Plasma: posting side-chain transaction data on the Ethereum blockchain. Publishing transaction data as function arguments meant it could be verified at the time of publication and then thrown away (so that it did not bloat Ethereum’s storage). zk-Rollup could avoid Plasma’s exit games and challenge periods entirely without trading off affordability or security. With zk-Rollup, one could use novel cryptography to solve all of Plasma’s layer-2 scaling dilemmas in one fell swoop. Vitalik’s zk-Rollup post But zk-Rollup came with its own set of tradeoffs. Namely, validity proofs are computationally expensive to generate (details here). These zk-SNARKS are produced every block and can take upwards of 10 minutes to generate while costing up to 350,000 gas per verification (post Istanbul). For reference, that’s about 3.5% of an entire block (was 8% pre Istanbul). Additionally, it is currently not possible to deploy general smart contracts on zk-Rollup sidechains. Proposals are under development for specialized zero-knowledge VMs that would enable this, such as zkVM and ZEXE, but they still require lots of specialized knowledge to interact with them. For the most part, zk-Rollups limit general programmability. zk-Rollup visualization. Credit: Georgios Konstantopoulos By mid-2019, these new developments had re-energized the Ethereum research community. zk-Rollup seemed to solve many of the problems that had plagued the layer-2 narrative. Companies such as Matter Labs (one of our portfolio companies) and LoopRing began actively developing zk-Rollups, and both have testnet implementations live today. With optimizations, Matter Labs believes that it can achieve upwards of 2,000 TPS on its ZK Sync network. Additionally, Starkware (also a portfolio company) is building a variation on zk-Rollup they call StarkExchange. StarkExchange uses a STARK to prove the validity of sidechain transactions, but delegates the problem of data hosting off-chain (if the sidechain ever halts, exits are guaranteed through on-chain checkpointing). They are implementing a DEX in partnership with DeversiFi with this design and will be launching on mainnet in the near future. A dose of optimism But not everyone was pinning their hopes on zk-Rollups. One year after the release of the first zk-Rollup spec, John Adler and Mikerah introduced a design they called Merged Consensus. Merged Consensus enables off-chain consensus systems that are entirely verifiable on Ethereum without any fancy zero-knowledge cryptography. After its release, the Plasma Group released an extended version of the Merged Consensus design with the now well-known title: Optimistic Rollup. While zk-Rollup relies on zk-SNARKs to verify and finalize every block, Optimistic Rollups take a different approach: what if you just assumed every single block was valid? This works great in the happy path when everyone is playing nice, but we know operators can misbehave. So how does an Optimistic Rollup handle operator misbehavior? The “optimistic” answer is to use fraud proofs. A fraud proof is a computational proof that an operator performed an invalid action. If the operator posts an invalid state transition, anyone can submit a proof that the transition was invalid and revert those transactions (for a period of about ~1 week). Since these proofs are non-interactive, they can be sent by anyone: they don’t require users to monitor their own coins for security. Unlike zk-Rollups, however, Optimistic Rollups require 3–5x more transaction data to be posted on-chain (check out this post by StarkWare for details). This data primarily includes witnesses such as signature data (which are not required by zk-Rollups, since it verifies those in zero knowledge). In the best case, optimistic rollup transactions will never need to be verified except in the case of fraud-proof submissions. On-chain witness verification and posting is expensive, however, and developers have explored aggregate signature mechanisms that allow for inexpensive large-scale verification and reduced transaction data requirements. This optimization can increase the theoretical TPS of Optimistic Rollups from its current numbers of ~450 TPS all the way to potentially ~2,000 TPS. Optimistic Rollups offer a very different set of tradeoffs from zk-Rollups. They are less expensive (assuming that fraud challenges are rare), but they trade off by being less safe — in other words, it’s always possible that transactions can be incorrectly applied and later reverted. This safety window can be as long as an entire week. As a result, users cannot be allowed to exit the chain for that safety window (otherwise, they could run off with someone else’s funds). However, it’s possible to ameliorate these withdrawal issues by introducing a secondary market. A user could sell their exit rights to a third party liquidity provider in exchange for a small fee. (The liquidity provider would get paid for taking on the week-long illiquidity of the exit). This would allow for immediate exits from the rollup chain. While zk-Rollups would require programmers to understand complex constraint systems and advanced cryptography, Optimistic Rollups allow for general smart contract deployment (e.g Solidity) and execution. This means that smart contract-based protocols such as Uniswap can be built on top of Optimistic Rollup sidechains. The rollup family of solutions provide similar approaches to solving Plasma’s data availability issues and exit complexity, but all have the potential to far extend Plasma’s constructions. IDEX, for example, has built and deployed their own version of Optimistic Rollups and run a DEX on this construction. Similarly, Fuel labs has built a version of Optimistic Rollups that allows for UTXO style payments and ERC-20 token swaps. Plasma Group (now Optimism), recently announced their pivot to focus on Optimistic Rollups, and are aiming to offer general smart-contract capabilities on their platform (via their OVM construction). Everything that rises must converge Plasma was ultimately much more than just a protocol. In a time of irrational exuberance, Plasma was the story that Ethereum needed to believe in. But its claims of boundless scalability turned out to be, with the benefit of hindsight, technological hubris. Only in moving past Plasma have we been able to deeply appreciate the tradeoffs inherent in layer-2 scaling. As Ether prices have rebounded over the last year, so has optimism about Ethereum’s future. After nearly 3 years of searching for a secure, extensible, and robust scalability solution, the Ethereum research community has finally converged around rollups. Plasma and its cousins were noble first attempts, but a select group of innovators eventually created more realistic layer-2 designs that seem to have solved Plasma’s worst problems. Some Plasma focused research groups, such as the Plasma Group, have moved on to work on Optimistic Rollup solutions, but we believe the search for the final layer-2 scaling solution is just getting started. There are many contenders, and we expect the field to remain an active and exciting area of research and development. Thanks to Tom Schmidt, Georgios Konstantopoulos, and Ivan Bogatyy for reviewing drafts of this post. For more of our writing, follow us on Twitter at @ashwinrz and @hosseeb.