Three Things #30: August 14, 2022
A few things that have changed
I wrote last week about three things that haven’t changed since I joined Spacemesh a few years ago. Of course, the blockchain ecosystem hasn’t been stagnant these past few years—quite the contrary! This week, I want to consider a few big things that have changed.
Thing #1: How I Learned to Stop Worrying and Love the MEV
Blockchain, cryptocurrency, Web3, and smart contract narratives evolve over time: peer to peer electronic cash, seizure-resistant store of value, hard money, world computer, unstoppable applications, DeFi, and NFTs, DAOs, you name it. Most of these themes come and go, rise and then rapidly fall in popularity and awareness. As a result, I tend to reflexively write off new ideas and trends as passing fads (since most are). It’s rare for a theme to emerge and monotonically grow in importance. MEV is one such topic, and while it’s a phenomenon that’s only recently been understood (we didn’t even have the language to talk about it a couple of years ago), it’s already clear that it’s big, that it’s growing in size and importance, and that it’ll be around for a very long time.
MEV stands for miner extractable value (or, more generically, “maximum extractable value”) and is a generalization of the way in which miners (and other classes of block producers such as proof of stake validators), which get the exclusive privilege of selecting and ordering transactions in the blocks they propose, are able to extract value in this process. The first and most obvious example of MEV is front running, where the miner inserts their own transaction in front of someone else’s—for instance, to arbitrage someone else’s trade. The idea is as old as finance itself but it’s taken on added salience and importance in a world of mempools, dark forests, and unencrypted transactions, where everyone can see what everyone else is doing and block producers are in a unique position to profit from this information. In a world where data is power and money itself, and data about financial transactions is especially valuable, the ability to insert oneself into and alter the flow of transactions is worth quite a lot. And that’s just the tip of the iceberg. There are far more sophisticated MEV strategies than front running, and MEV strategies are growing more sophisticated and beginning to cross into multiple domains other than Ethereum.
MEV is one of those things that, once seen, you cannot unsee, and you start to see it everywhere. While it’s gotten a lot of attention in the Ethereum ecosystem and has even influenced the design of the Ethereum protocol itself, even most crypto insiders probably aren’t aware of it yet, and people that are aware of it probably don’t realize its scale and what a big deal it is. MEV is the most interesting, important aspect of blockchains and cryptocurrency that the world hasn’t figured out yet.
It’s essential for protocol designers to understand MEV and to grapple with its implications. I think a lot about what MEV means for Spacemesh. We probably cannot prevent it entirely: indeed, for this reason, the approach being taken in the Ethereum ecosystem is to embrace it and be open about it so as many people as possible can participate and profit from it. But there are certainly things that can be done at the protocol level to mitigate its effects, such as imposing a fair ordering on transactions, or separating block builders from block proposers, and to make it as easy as possible for everyone to participate.
But there’s another side to MEV: I think that, once you’ve internalized it and understood that you cannot wish it away, it opens many doors and reveals new possibilities. One is the idea of “smart transactions” (yes, you read that right), transactions that aren’t dumb data blobs but are rather applications in their own right that willingly participate in the MEV searching and bundling process and play a more interactive role. I first came upon this idea in this recent talk by Vlad Zamfir and while it’s not very fleshed out, it has potential and I think we should continue to explore it. Another idea I’ve been playing with is settling on extremely simple transaction filtering and sorting at the protocol level, i.e., in our node software, and outsourcing more complex filtering and sorting schemes—such as deduplication of more complex transactions, supporting more complex, nonlinear nonce schemes, atomic batching of transactions, etc.—to MEV searchers, formally adopting them and carving out a niche for them in the protocol.
For now we’re mostly doing the Simplest Possible Thing™ wherever we can in Spacemesh, since we already have a lot of added complexity in our consensus and cooperative mining protocols. But MEV is an area that I’m actively watching and studying, and I’m sure we’ve only begun to see the impact it’ll have on both the social and technical aspects of blockchain and cryptocurrency.
For more: Read this foundational paper and this introductory article, and check out Flashbots for lots more on the topic.
Thing #2: Modularity
A few years ago, all blockchains were architected the same way: monolithically. A single component (the full node) was responsible for consensus, block production, data availability, execution, and everything in between. Around this time the first glimpses of a modular future were just starting to appear in projects like turbo-geth (now Erigon), Ewasm, and EVMC, which allowed components like the database and VM in go-ethereum to be swapped for alternative implementations and designs. Shortly thereafter, Flashbots released pluggable tools to take advantage of MEV as described above.
Fast-forward a few years and, while Bitcoin, Ethereum, and most other major blockchains are indeed still monolithic, a new architecture has begun to seriously take hold. This has been led by tons of work being done on rollups (which provide execution, but rely on another layer one blockchain for consensus, data availability, and settlement) and by the post-Merge Ethereum roadmap, which pivoted to embrace modularity by splitting validation across two clients, an execution client and a consensus client. The Merge is tentatively scheduled to take place in about a month, after which Ethereum will be the first truly modular blockchain in production. Celestia and many other projects have emerged to take advantage of this trend, which is sure to continue.
As I discussed in the talk I did at ETHDenver on modularity, this trend is positive and makes perfect sense. Modularity brings a host of benefits, among them flexibility, performance improvements, easier testing and maintainability, and the holy grail of blockchains, scalability. It’s simply unrealistic to expect that a monolithic, general-purpose system like Ethereum’s original design would ever be able to scale as much as a modular system with individual components designed and purpose-built to be the very best at consensus, execution, or data availability. The evolution of all advanced technologies proceeds in the same direction, from simplistic, early, monolithic prototypes to highly dynamic, advanced, customizable, flexible, modular designs. It’s the only way to handle large, growing complexity. This is true for things as diverse as architecture, automobiles, typewriters, CPUs, and, of course, software.
Modularity is not without tradeoffs, of course. There’s some inevitable loss of efficiency at the boundaries due to impedance mismatch. APIs tend to ossify, making some forms of innovation more difficult. It can make testing harder, due to the potentially large number of permutations and combinations of components, and can lead to reduced stability. And, most relevant for blockchains, it can make governance and decision-making more difficult, and it can make it more difficult to establish and understand complex trust boundaries (e.g., whose gets punished when a transaction gets stuck in limbo, where the data is available but it cannot be executed?).
What does this mean for Spacemesh? We’re not launching with any modular components. But we’ve tried to design and build the system in such a way that it can be made more modular in future, and can be made to work with existing modular components. For example, we’re designing a VM with the simplest possible API so that, in theory, you could run a Spacemesh network using Wasm, RISC-V, EVM, or even Move under the hood. With any luck, bytecode from other blockchains might even be compatible with Spacemesh (this is something that will take some time to figure out). As another example, we’re decoupling consensus from execution as much as possible so that these roles (miner and validator) may be separated in the future, or execution may be outsourced to diverse rollups.
The blockchain space is evolving rapidly and it’s challenging to design and build towards a moving target, but I’m proud of our design and I’m confident that it will stand the test of time. Modularity is an important part of ensuring that!
For more: Watch this talk and read the many articles on modular blockchain in this blog that it references to better understand the idea and where it stands today.
Thing #3: EVM is King
There’s a phenomenon that plays out from time to time, where a suboptimal technology becomes the dominant standard not on its technical merits but for unrelated reasons such as having a head start or good marketing. The most famous example of this is probably VHS, which defeated Betamax in the eighties despite the fact that the latter was clearly a better technology. In computer science the most notorious example is JavaScript, which is such a crappy programming language that it can’t even do basic math correctly (not to mention comparisons), and is the most popular language in the world despite being far from loved.
The same trend is playing out in blockchain VMs, the engines that execute smart contract code on blockchains like Ethereum. EVM (the Ethereum virtual machine) has a bunch of warts and strange, suboptimal design choices, such as the 256-bit word size, which makes even the simplest math computation relatively slow and expensive. It’s hard to debug and test and even harder to audit or formally analyze. It came totally out of the blue and was designed by a motley crew of mostly VM amateurs, without the benefit of big corporate backers or committees of experts. It doesn’t plug into any existing tooling, and it’s tightly coupled to a new programming language (Solidity) that literally no one knew a few years ago, which isn’t very easy to learn, and which has many quirks in its own right. In spite of all of these shortcomings, EVM has indisputably emerged as the clear winner in the blockchain VM space, against rivals including Wasm and RISC-V, which don’t share most of these shortcomings.
I spent two years working on a replacement for EVM called Ewasm, based on the standard known as WebAssembly, or Wasm for short, that was emerging at that time. Wasm was designed by world class experts in VM and programming language design and backed by major companies like Google and Mozilla to be a platform-agnostic VM and language, and support was added years ago to allow it to run in every major web browser. Best of all, it was designed to run at near-native speeds, i.e., orders of magnitude faster than EVM. Ewasm was designed to address many of the shortcomings of EVM and Solidity and the plan at the time was for Ewasm to replace EVM around the time Ethereum migrated to proof of stake.
EVM is the worst of all smart contract engines, except for all the others that have been tried from time to time. And yet, fast forward a few years and EVM has taken over the blockchain world. It’s the little smart contract engine that could, and it keeps chugging along. Over the past few years, important blockchain projects have tried other standards. While Wasm was effectively dropped from the canonical Ethereum roadmap (in favor of continuing to support EVM, and rollups), NEAR and Polkadot did both launch with Wasm engines that allow users to write smart contracts in familiar, popular languages such as JavaScript and Rust (rather than learn Solidity). Solana, Tezos, Stacks, and other chains launched with custom-designed languages and VMs. Most recently, Move has emerged as a strong challenger to EVM, and is being included in multiple high profile project launches. At the same time, projects like Avalanche have instead chosen to double down on EVM, and even projects that didn’t initially align with EVM have begun adding support.
For now, EVM is lightyears ahead of the competition and it’s time to acknowledge that. That’s not to say that we shouldn’t experiment with other engines, or that another engine couldn’t still come along and dethrone EVM. Move, in particular, might over time present a real threat to EVM, though the chance of this happening falls every day. The reasons for EVM’s dominance are clear, and common once a standard emerges: developers don’t want to learn new languages and they don’t want to rewrite code. For better or for worse, an ecosystem of tools such as compilers, debuggers, optimizers, security analysis tools, etc. has emerged around Solidity and EVM, as has an ecosystem of auditors. Good luck getting your code audited if it’s written in an obscure language running on a VM no one has ever heard of.
We tend not to debate or even think much about long-established standards. No one (other than CPU designers) talks about whether x86 is a good thing, and (whether you believe in Web2 or Web3) it’s silly at this point to suggest that the Web should be architected in something other than JavaScript or one of its derivatives. Someday smart contracts will achieve a similar degree of boringness, and someday cross-chain standards might emerge that would allow a smart contract written and compiled on one chain to run on another, but that day is far away and in the meantime there will continue to be a lot of churn as different projects experiment with different VMs and languages.
Network effects are real and standards are important. In software there are rarely more than two or three dominant standards: look at mobile phones, the browser wars, processor architecture, operating systems, etc. There will be more than one winner, but not many more, and you’d be foolish not to recognize the power and reach of EVM. Whether EVM ultimately wins or not, it has already had a massive impact on the design of blockchains, VMs, smart contracts—and, dare I say it, computation itself.
For more: The only way to gain any meaningful appreciation for EVM (or any other standard) is to write and deploy a smart contract. Try doing this on Ethereum, and on at least one other blockchain using a different language/VM. What was easier or harder, better or worse about the two?