What the Heck is Athena?
Three Things #130: July 28, 2024
If you’ve been following this newsletter, you already know about the Athena project. I’ve talked about it a lot over the past few months. So why ask the most basic question about it? It seems silly, right? Athena is the new Spacemesh VM! What more is there to say?
Actually, there's a lot more to it, and this question is surprisingly tricky. People ask me about Athena all the time, and I’m still figuring out the best way to explain it. There are many moving parts and a lot of nuance. Athena is unlike anything that exists today, which makes it hard to explain and understand.
The docs describe Athena as “a modern blockchain operating system for running programs (a.k.a. smart contracts) in a manner that's performant, deterministic, and efficiently provable.” How does that sound as an answer? Is it complete? Satisfying? Let’s break it down and dive into the details.
Thing #1: Virtual Machine 🖲
"The limits of my language mean the limits of my world." – Ludwig Wittgenstein
The shortest possible definition is: Athena is the Spacemesh VM. More broadly, it's a VM designed to be modular and chain-agnostic, capable of running in multiple places, on various chains, at both L1 and L2.
But what does “VM” actually mean? This term is loaded, and even smart technical folks throw it around without fully understanding it. “VM” stands for “virtual machine,” but that's not specific enough. It can refer to different things, from the bottom to the top of a tech stack, or it can mean the entire stack.
At the base, there’s the instruction set, known as the ISA. When we call something like Wasm or Java a VM, we generally mean this: a low-level set of instructions, a bytecode format that programs compile into (this is called “targeting”). It's called a “virtual machine” because it’s a virtual set of machine instructions.
Above that is the machinery that executes the bytecode, also known as a VM. For Java, this is the JVM (“Java virtual machine”). For Wasm, it’s a Wasm compiler or interpreter like Wasmi or Wasmer. This layer is also called a VM because it standardizes and implements how a machine reads bytecode (or machine code). These bottom layers—the instruction set and the machine that reads those instructions—fit together like a ball and glove. They’re tightly coupled, so it makes sense to refer to the entire mechanism as a “virtual machine.”
So far, none of this involves blockchain! The blockchain bits are on top, including host functions that let a VM program interact with the blockchain to read balances, send coins, read and write state, etc. We lack a good term for this “glue” or “middleware,” so it usually gets lumped into the VM too. When we talk about the EVM, we mean the bytecode, the interpreter, and the machinery that lets EVM programs (smart contracts) do blockchain things.
The same goes for Athena. It’s the whole kit and caboodle, top to bottom. You could even use a circular definition: Athena is the code used to write smart contracts that target the Athena VM. Athena, as a programming language, is just Rust, but it includes libraries that simplify doing blockchain things in Rust. That’s Athena, too.
From this perspective, a better definition might be: Athena is a stack of tightly coupled technologies used to write, compile, and interpret smart contracts in Rust targeting the RV32IM RISC-V instruction set for use in Spacemesh and other blockchains. You could also add verbs like “test,” “deploy,” “debug,” “profile,” etc. One day Athena will do all these things too.
Thing #2: Architecture 📐
"Chaos is the score upon which reality is written." – Henry Miller
That’s already a lot, but everything described so far is pretty low-level. Athena is actually more than just a low-level VM, as we explained in the original announcement post. If Athena were only a low-level VM, it would serve as the sole execution environment for a layer one blockchain. This is what’s been built so far, and it’s exactly what the current phase of the Athena project is focused on: launching an Athena testnet. But if we stop here, Athena wouldn’t work in any other environment, including as a rollup. For that, we need to add a few more layers.
Athena is more than just the ability to write and run native RISC-V smart contracts using Rust. It’s more than the stack of technologies used to perform all those tasks. It’s also a novel architecture—a design for building a blockchain smart contract execution engine on top of those components. To understand where we’re going with Athena, it helps to understand where we’re coming from.
Historically, the infrastructure powering blockchain programmability has always been monolithic. This is true for Bitcoin, Ethereum, and nearly every other layer one blockchain running today. Each has a single execution environment hard-coded at the base layer. On Ethereum, you can run smart contracts compiled to EVM using EVM semantics, or you can go to another chain; there are no other options.
Interestingly, this wasn’t always the plan! I worked for years on a project called Ewasm, intended to introduce more modularity and flexibility to the Ethereum runtime. This would have allowed writing smart contracts in different languages and running different VMs on different Ethereum shards, all of which could communicate. Just as it doesn’t make sense for every program on all your devices to be written in the same language and run in the same environment, it doesn’t make sense for blockchains either. Different programming languages and execution environments are better suited to different types of applications.
Unfortunately, this was not to be for Ethereum, and this work didn’t make it into the core Ethereum roadmap. Ethereum decided to simplify things: instead of adding more execution environments at the base layer, the decision was made to push experimentation, modularity, and flexibility into L2 via rollups. There are advantages to this, but the big disadvantage is that applications deployed on rollups lose composability. They generally can’t communicate with each other, and when they do, it’s over unreliable, expensive, and slow bridges.
Athena is, among other things, a rollup. But it’s also the official Spacemesh VM. How can it be both? The answer is that it’s one of the first implementations of a new idea called a sovereign rollup. This means there’s only one rollup on the Spacemesh L1. That rollup is Athena, and Athena and its transactions have limited first-class support in the Spacemesh L1. Spacemesh miners sequence Athena transactions and adjudicate disputes.
Spacemesh will start with just one rollup, but there’s no reason it has to stay that way. Athena is built to be modular and includes something called the Athena Connector (Athcon) that sits between the chain and the VM. This means Athena can run in many places, on many chains, and at L1 or L2, but it also means any chain that supports Athena could run many different VMs. Athena is also this connector layer, meaning Spacemesh or other projects adopting Athena in the future could have many VMs and execution environments. Athena doesn’t yet support the ability for smart contracts written in one language, running on one VM, to communicate with those written in another language and running on another VM, but it’s designed and built to make this possible in the future.
To some extent, the original Ethereum vision, described above, lives on in projects like Arbitrum Stylus and Fluent, both of which have multiple runtimes and allow programs on these runtimes to communicate. Athena is another inheritor of this original Ethereum vision, and it’s also our goal to one day allow this sort of flexibility.
So, you could say that Athena represents a radically different vision for blockchain programmability, more in line with the original Ethereum roadmap before its pivot. There was merit in that vision, and it’s worth building!
Thing #3: Vision 🔮
"An idea that is not dangerous is unworthy of being called an idea at all." – Oscar Wilde
We’re making progress on defining Athena, but we’re not quite done yet. We’ve covered the low level and the high level. What remains is the big question: to what end? What difference does a new VM, a new programming stack, or a new rollup make to the world? On its own, very little. But the goal here is to empower developers to build cool stuff—and that cool stuff might just change the world.
The reality is, developing blockchain applications today is still too difficult. It requires learning new programming languages and paradigms, and acquiring an entirely new set of skills. That’s not all bad! Blockchain is a fundamentally different environment, with different constraints, risks, etc. By forcing developers to learn new languages and tools, you’re also forcing them to learn these new paradigms. What’s more, those new languages and tools can help protect developers from pitfalls. The high bar acts as a filter: only motivated, talented developers will acquire the necessary skills and build applications, reducing the risk of garbage code and applications that end up on chain and put users at risk.
Of course, there’s a tradeoff. Requiring developers to learn new languages, paradigms, and tools is a big ask. As I mentioned last week, there are only a few thousand full-time blockchain developers in the world. And that’s after ten years and many billions of dollars of investment. There are many reasons that number is so low, and I won’t claim that easier programmability will solve all of them, but it’s definitely a big barrier for many developers.
Speaking as a developer, we have two or three primary motivations. One is to learn and experiment with new technologies, since developers are technologists at heart. The more accessible and familiar the new technology, the better. Another is to build useful applications that are actually usable. Beyond the experimentation phase, that requires mature tools and infrastructure. Even today, too many blockchain applications still feel like toys—partly because the tooling and infrastructure aren’t mature enough.
Imagine if you could write blockchain applications using the programming language and tools you’re already used to. Imagine if designing, developing, testing, deploying, and running a blockchain application were as easy as doing the same for a web or desktop app. Actually, building non-blockchain applications is already too hard today, but building blockchain applications is even harder. This is the number one reason there are so few blockchain developers. We need to make it easier and more fun. Tens of millions of developers have invested a lot in learning an existing skillset and toolset, and we should let them use the skills they already have and the tools they’re already used to.
In short, this is all part of the Athena vision. Yes, Athena inherits many things from existing blockchains and their smart contract engines, including Bitcoin, EVM, Move, and Solana. Yes, Athena is a blockchain operating system and applications built on Athena will largely be run on blockchains. But the entire Athena stack of technologies and tools—all of the things outlined above—has been designed and engineered from the ground up with developer experience as the first and most important goal.
It’s still very early days for Athena and for Spacemesh programmability in general. Athena works, but you can’t do much with it yet. If you squint, you can just make out the outlines of where we’re going—and it’s pretty awesome. We’ve had this vision for a while, but until very recently I wasn’t sure we’d be able to pull it off. We’ve come far enough along that now I’m absolutely certain we can, and we will.
Athena will make blockchain programming fun again. Join us. Now is a great time to learn about the project and to contribute. We’re only days away from being able to build and run smart contracts on an Athena testnet. We’ll be releasing more information on this soon.