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.

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.

Flash loans have been the center of attention lately. Recently two hackers used flash loans to attack the margin trading protocol bZx, first in a $350K attack and later in a $600K copycat attack. These attacks were, in a word, magnificent. In each attack, a penniless attacker instantaneously borrowed hundreds of thousands of dollars of ETH, threaded it through a chain of vulnerable on-chain protocols, extracted hundreds of thousands of dollars in stolen assets, and then paid back their massive ETH loans. All of this happened in an instant—that is, in a single Ethereum transaction. Cover art by Carmine Infantino We don’t know who these attackers were or where they came from. Both started with basically nothing and walked away with hundreds of thousands of dollars in value. Neither left any traces to identify themselves. In the wake of these attacks, I’ve been thinking a lot about flash loans and their implications for the security of DeFi. I think this is worth thinking through in public. In short: I believe flash loans are a big security threat. But flash loans are not going away, and we need to think carefully about the impact they will have for DeFi security going forward. What is a flash loan? The concept of a flash loan was first termed by Max Wolff, the creator of Marble Protocol in 2018. Marble marketed itself as a “smart contract bank,” and its product was a simple, yet brilliant DeFi innovation: zero-risk loans via a smart contract. How can a loan have zero risk? Traditional lenders take on two forms of risk. The first is default risk: if the borrower runs off with the money, that obviously sucks. But the second risk to a lender is illiquidity risk: if a lender lends out too many of their assets at the wrong times, or doesn’t receive timely repayments, the lender may be unexpectedly illiquid and not be able to meet their own obligations. Flash loans mitigate both risks. A flash loan basically works like this: I will lend you as much money as you want for this single transaction. But, by the end of this transaction, you must pay me at least as much as I lent you. If you are unable to do that, I will automatically roll back your transaction! (Yep, smart contracts can do that.) Simply put, your flash loan is atomic: if you fail to pay back the loan, the whole thing gets reverted as though the loan never happened. Something like this could only exist on blockchains. You could not do flash loans on, say, BitMEX. This is because smart contract platforms process transactions one at a time, so everything that happens in a transaction is executed serially as a batch operation. You can think of this as your transaction “freezing time” while it’s executing. A centralized exchange, on the other hand, can have race conditions such that a leg of your order fails to fill. On the blockchain, you’re guaranteed that all of your code runs one line after the next. So let’s think about the economics here for a second. Traditional lenders are compensated for two things: the risk they’re taking on (default risk and illiquidity risk), and for the opportunity cost of the capital they’re lending out (e.g., if I can get 2% interest elsewhere on that capital, the borrower must pay me more than the risk-free 2%). Flash loans are different. Flash loans literally have no risk and no opportunity cost! This is because the borrower “froze time” for the duration of their flash loan, so in anyone else’s eyes, the system’s capital was never at risk and never encumbered, therefore it could not have earned interest elsewhere (i.e., it did not have an opportunity cost). This means, in a sense, there’s no cost to being a flash lender. This is deeply counterintuitive. So how much should a flash loan cost at equilibrium? Basically, flash loans should be free. Or more properly, a small enough fee to amortize the cost of including the extra 3 lines of code to make an asset flash-lendable. interface Lender { function goWild() external; } contract FlashERC20 is ERC20 { using SafeMath for uint256; function flash(uint256 amount) external { balances[msg.sender] = balances[msg.sender].add(amount); Lender(msg.sender).goWild(); balances[msg.sender] = balances[msg.sender].sub(amount); } } h/t Remco Bloemen Flash loans cannot charge interest in the traditional sense, because the loan is active for zero time (any APR * 0 = 0). And of course, if flash lenders charged higher rates, they’d quickly be outcompeted by other flash lending pools that charged lower rates. Flash lending makes capital a true commodity. This race to the bottom inevitably results in zero fees or a tiny nominal fee. dYdX currently charges 0 fees for flash lending. AAVE, on the other hand, charges 0.09% on the principal for flash loans. I suspect this is not sustainable, and indeed, some in their community have called for slashing fees to 0. (Note that neither of the attacks we saw used AAVE as their flash lending pool.) What are flash loans useful for? Flash loans were originally marketed on the premise that they’d primarily be used for arbitrage. Marble’s breakout announcement claimed: “With flash lending, a trader can borrow from the Marble bank, buy a token on one DEX, sell the token on another DEX for a higher price, repay the bank, and pocket the arbitrage profit all in a single atomic transaction.” And it’s true — by volume, most of the flash loans we’ve seen so far have been used for this kind of arbitrage. Flash loan usage on AAVE. Credit: AAVE But volumes have been tiny. AAVE has originated barely over $10K of borrows since inception. This is miniscule compared to the arbitrage and liquidations market on DeFi. This is because most arbitrage is performed by competitive arbitrageurs running sophisticated bots. They engage in on-chain priority gas auctions and use gas tokens to optimize transaction fees. It’s a very competitive market — these guys are perfectly happy to keep some tokens on their balance sheet to optimize their earnings. On the other hand, borrowing on AAVE costs about 80K gas and charges 0.09% of the principal — a steep price to pay for an arbitrageur competing over tiny margins. In fact, in most AAVE arbitrages, the borrower ended up paying more in fees to the lending pool than they took home. In the long run, arbitrageurs are unlikely to use flash loans except in special circumstances. But flash loans have other more compelling use cases in DeFi. One example is refinancing loans. For example, say I have a Maker vault (CDP) with $100 of ETH locked in it, and I drew a loan of 40 DAI from it—so I’ve got a $60 net position minus my debt. Now say I want to refinance into Compound for a better interest rate. Normally I’d need to go out and repurchase that 40 DAI to close out my CDP, which requires some up-front capital. Instead, I can flash borrow 40 DAI, close out the $100 CDP, deposit $60 of my unlocked ETH into Compound, convert the other $40 of ETH back into DAI through Uniswap, and use that to repay the flash loan. Boom, atomic 0-capital refinancing. That’s pretty magical! It’s a great example of money legos™ at work. 1x.ag actually built a margin trading aggregator that automates this kind of thing using flash loans. But as cool as flash loans can be, the bZx attackers showed us that they aren’t just fun and games. Flash attacks have big security implications I’ve increasingly come to believe that what flash loans really unlock are flash attacks — capital-intensive attacks funded by flash loans. We saw the first glimpses of this in the recent bZx hacks, and I suspect that’s only the the tip of the spear. There are two main reasons why flash loans are especially attractive to attackers. Many attacks require lots of up-front capital (such as oracle manipulation attacks). If you’re earning a positive ROI on $10M of ETH, it’s probably not arbitrage — you’re likely up to some nonsense. Flash loans minimize taint for attackers. If I have an idea of how to manipulate an oracle with $10M of Ether, even if I own that much Ether, I might not want to risk it with my own capital. My ETH will get tainted, exchanges might reject my deposits, and it will be hard to launder. It’s risky! But if I take out a flash loan for $10M, then who cares? It’s all upside. It’s not like the collateral pool of dYdX will be considered tainted because that’s where my loan came from — the taint on dYdX just sort of evaporates. You might not like that exchange blacklisting is part of the blockchain security model today. It’s quite squishy and centralized. But it’s an important reality that informs the calculus behind these attacks. In the Bitcoin white paper, Satoshi famously claimed that Bitcoin is secure from attack because: “[The attacker] ought to find it more profitable to play by the rules […] than to undermine the system and validity of his own wealth.” With flash loans, attackers no longer need to have any skin in the game. Flash loans materially change the risks for an attacker. And remember, flash loans can stack! Subject to the gas limit, you could literally aggregate every flash loanable pool in a single transaction (upwards of $50M) and bring all that capital thundering down onto a single vulnerable contract. It’s a $50M battering ram that now anyone can slam into any on-chain pinata, so long as money comes out. This is scary. Now, of course, you shouldn’t be able to attack a protocol by just having a lot of money. If the DeFi stack is as secure as it’s claimed to be, all this shouldn’t be a problem — what kind of protocol isn’t secure against a rich whale? Not accounting for that is just negligence, you might say. And yet we acknowledge that Ethereum itself can be 51% attacked for less than $200K/hr**. That’s not that much money! If Ethereum’s own security model is basically built around capital constraints, why are we so quick to scoff at DeFi applications that can be successfully attacked for $10M? (** To be clear, I don’t believe these numbers—the figure conveniently ignores slippage and the dearth of supply—plus consensus-layer security and application-layer security are different beasts. But you get the point.) So how can you mitigate against flash attacks? Say I’m a DeFi protocol and I want to avoid getting flash attacked. The natural question might be — can I detect whether the user interacting with me is using a flash loan? The simple answer is: no. The EVM doesn’t let you read storage from any other contract. Thus, if you want to know what’s going on in another contract, it’s on that contract to tell you. So if you wanted to know whether a flash loan contract was actively being used, you’d have to ask the contract directly. Today many of the lending protocols don’t respond to such queries (and there’s no way to enforce that a flash lender does in general). Plus even if you tried to check, any such query could easily be misdirected using a proxy contract, or by chaining across flash lending pools. It’s simply not possible to tell in general whether a depositor is using a flash loan. Take that in for a second. If someone is knocking on your contract’s front door with $10M, it’s impossible to tell whether it’s their own money or not. So what real options do we have to protect against flash attacks? There are a few approaches we could consider. Convince flash lending pools to stop offering this service. Ha, just kidding. It’s crypto, you guys! In all seriousness, trying to get lending pools to stop offering flash lending is like trying to stop noise pollution—it’s a classic tragedy of the commons. It’s in every protocol’s individual interest to offer flash loans, and there are legitimate reasons why their users want this functionality. So we can safely dismiss this. Flash loans aren’t going away. Force critical transactions to span two blocks. Remember, flash loans allow you to borrow capital within the span of a single transaction. If you require a capital-intensive transaction spans two blocks, then the user must take out their loan for at least two blocks, defeating any flash attacks. (Note: for this to work, the user has to have their value locked up between the two blocks, preventing them from repaying the loan. If you don’t think through the design correctly, a user could just flash attack in both blocks.) Obviously this comes at a steep UX tradeoff: it means that transactions will no longer be synchronous. It sucks for users, and it’s a tough bullet to bite. Many developers bemoan asynchronous smart contract operations, such as interacting with layer 2 or cross-shard communication in Ethereum 2.0. Ironically, asynchrony actually makes these systems secure against flash attacks, since you cannot traverse a shard or a layer 2 in a single atomic transaction. This means no flash attacks across ETH 2.0 shards or against DEXes on layer 2. Request on-chain proofs that a user’s prior balance wasn’t altered by a flash loan. We could defeat flash attacks if there were some way to detect what a user’s real balance was — that is, what their balance was before they took out the loan. There’s no way to do that natively in the EVM, but you can sort of hack it. Here’s what you do: before a user interacts with your protocol, you demand a Merkle proof that demonstrates that at the end of the previous block, they had enough balance to account for the capital they’re currently using. You’d need to keep track of this for each user in each block. (Credit to Ari Juels for outlining this approach to me.) This kind of works. Of course, it has some gnarly problems: verifying these on-chain proofs is incredibly expensive on-chain, and no user in their right mind wants to generate them and pay the gas fees for this whole thing. Plus, users might have changed their balance earlier in the same block for perfectly legitimate reasons. So while theoretically it has some merit, it’s not a practical solution. None of these three solutions I’ve proposed are particularly promising. I’m convinced that there is no good general defense against flash attacks. But there are two specific applications that do have specific mitigations against flash attacks: market-based price oracles and governance tokens. For market-based price oracles like Uniswap or OasisDEX, flash attacks make it so you cannot under any circumstances use the current mid-market price as an oracle. It’s child’s play for an attacker to move the mid-market price within a single transaction and manufacture a flash crash, corrupting the price oracle. The best solution here is to use a weighted average of the last X blocks either via a TWAP or VWAP. Uniswap v2 will offer this natively. There’s also Polaris, a generalized approach for offering moving averages for DeFi protocols. Ironically, this Polaris was also built by Max Wolff, the original creator of Marble. (Polaris is now abandoned, but much credit for Max for seeing around that corner.) On-chain governance is its own can of worms. On-chain governance is usually determined by the coin-weighted voting among holders of the governance token. But if those governance tokens are in a flash lending pool, then any attacker can scoop up a giant pile of coins and bash on any outcome they want. Of course, most governance protocols require those coins to be locked up for the voting period, which defeats flash attacks. But some forms of voting don’t require this, such as carbon votes, or Maker’s executive contract. With flash attacks now on the table, these forms of voting should be considered completely broken. Ideally, it’d be great if governance tokens weren’t flash loanable at all. But this isn’t up to you as an issuer — it’s up to the market. Thus, all governance actions should require lockups to prevent against flash attacks. Compound’s new COMP token goes a step further by time-weighting all protocol votes, weakening even regular loan attacks against their governance token. More broadly, all governance tokens must have timelocks. A timelock enforces that all governance decisions must wait a period of time before they go live (for Compound’s timelock, it’s 2 days). This allows the system to recover from any unanticipated governance attacks. Even though MKR isn’t yet flash borrowable in bulk, MakerDAO was recently called out for being vulnerable to this sort of attack. It recently implemented a 24 hour timelock, closing this attack vector. What does all of this mean for the long term? I believe the bZx attacks changed things. This will not be the last flash attack. The second bZx attack was the first copycat, and I suspect it will set off a wave of attacks in the coming months. Now thousands of clever teenagers from the remotest parts of the world are poking at all these DeFi legos, examining them under a microscope, trying to discover if there is some way they can pull off a flash attack. If they manage to exploit a vulnerability, they too could make a few hundred thousand dollars — a life-changing sum in most parts of the world. Some people claim that flash attacks don’t change anything because these attacks were always possible if the attacker was well-capitalized. That’s both correct and incredibly incorrect. Most whales don’t know how to hack smart contracts, and most brilliant attackers don’t have millions of dollars lying around. Now anyone can rent a $50M wrecking ball for pennies. This changes the way every building needs to be constructed from now on. After the bZx hacks, being hit by a flash attack will be as embarrassing as getting hit by re-entrancy after the DAO hack: you will get no sympathy. You should have known better. Lastly, these episodes have gotten me thinking about an old concept in crypto: miner-extractable value. Miner-extractable value is the total value that miners can extract from a blockchain system. This includes block rewards and fees, but it also includes more mischievous forms of value extraction, such as reordering transactions or inserting rogue transactions into a block. At bottom, you should think of all of these flash attacks as single transactions in the mempool that make tons of money. For example, the second bZx attack resulted in $645K profit in ETH in a single transaction. If you’re a miner and you’re about to start mining a new block, imagine looking at the previous block’s transactions and saying to yourself… “wait, what? Why am I about to try to mine a new block for ~$500, when that last block contains $645K of profit in it??” Instead of extending the chain, it’d be in your interest to go back and try to rewrite history such that you werethe flash attacker instead. Think about it: that transaction alone was worth more than 4 hours worth of honestly mined Ethereum blocks! This is isomorphic to having a special super-block that contains 1000x the normal block reward — just as you expect, the rational result of such a super-block should be a dogpile of miners competing to orphan the tip of the chain and steal that block for themselves. Artist’s visualization of a miner dogpile. Credit: AP Photo/Denis Poroy At equilibrium, all flash attacks should ultimately be extracted by miners. (Note that they should also end up stealing all on-chain arbitrage and liquidations.) This will, ironically, serve as a deterrent against flash attacks, since it will leave attackers unable to monetize their discoveries of these vulnerabilities. Perhaps eventually miners will start soliciting attack code through private channels and pay the would-be attacker a finder’s fee. Technically, this could be done trustlessly using zero-knowledge proofs. (Weird to think about, right?) But that’s all pretty sci-fi for now. Miners obviously aren’t doing this today. Why aren’t they? Tons of reasons. It’s hard, it’s a lot of work, the EVM sucks to simulate, it’s risky, there would be bugs that would result in lost funds or orphaned blocks, it’d cause an uproar and the rogue mining pool might have a PR crisis and be branded an “enemy of Ethereum.” For now miners would lose more in business, R&D, and orphaned blocks than they’d gain by trying to do this. That’s true today. It won’t be true forever. This lends yet another motivation for Ethereum to hurry up and transition to Ethereum 2.0. DeFi on Ethereum, while always entertaining, is absolutely and irrevocably broken. DeFi is not stable on a PoW chain, because all high-value transactions are subject to miner reappropriation (also known as time bandit attacks). For these systems to work at scale, you need finality—the inability for miners to rewrite confirmed blocks. This will protect transactions in previous blocks from getting reappropriated. Plus if DeFi protocols exist on separate Ethereum 2.0 shards, they won’t be vulnerable to flash attacks. In my estimation, flash attacks give us a small but useful reminder that it’s early days. We’re still far from having sustainable architecture for building the financial system of the future. For now, flash loans will be the new normal. Maybe in the long run, all assets on Ethereum will be available for flash loans: all of the collateral held by exchanges, all the collateral in Uniswap, maybe all ERC-20s themselves. Who knows—it’s only a few lines of code.

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.