TLDR

Today we’re announcing the high level design of the new Spacemesh VM, known as Athena. Athena is a novel rollup architecture and execution environment for Spacemesh that will allow Spacemesh to scale to handle an arbitrarily large transaction throughput without overly burdening existing L1 miners or compromising decentralization. Athena is also a VM and toolchain that will allow developers to write applications in Rust and deploy them to Spacemesh. Existing Spacemesh L1 miners play a central role in sequencing Athena transactions, providing extremely high censorship resistance guarantees, while offloading the work of running the Athena VM to a network of specialized nodes that are responsible for bundling Athena transactions and submitting them to L1 miners and for maintaining Athena state. The Athena VM is built on RISC-V and Athena will run as an optimistic rollup for now, but will be built with full zero knowledge support and will eventually transition to a ZK rollup. Importantly, Athena will be fully permissionless and decentralized from inception.

Background

We’ve been working on a Spacemesh VM since 2018. Over the years we’ve experimented with a number of designs, and we even built a working VM based on WebAssembly (Wasm), but we tabled it because the blockchain VM landscape had evolved so rapidly. We’ve gone back and forth on the question of whether or not to pursue EVM compatibility, and in addition to EVM and Wasm we’ve taken a close look at other options including Move, eBPF and the Solana VM, and RISC-V. We’ve also spent a lot of time researching and debating related questions such as the tradeoffs between optimistic and ZK rollups.

We made the difficult but in retrospect correct decision to launch the Spacemesh mainnet last year without a VM, but we did ship Spacemesh with a novel account design featuring in-protocol support for account abstraction and reusable “templates” (i.e., smart contracts) that was a product of our VM research. This was a first step towards what we’ve always intended for Spacemesh: that it have a full, robust VM that developers can use to build anything they can imagine.

Since genesis we’ve primarily been occupied with improving the efficiency and security of the protocol, and with keeping the network healthy in spite of a rapidly growing number of miners, but in the background the research team continued to research and explore various VM designs. We wrote about some of our design goals a few months ago, including that L1 miners play a role in sequencing VM transactions but not need to run the full VM, in order to ensure scalability.

The research team recently met face to face and held a summit with the goal of finalizing the high level VM design so that we could begin working on the details. We’re excited to announce that we achieved that goal. What follows is the agreed upon high level design along with some open questions, next steps, and the answers to some more obvious questions.

Goals

We have several important, ambitious goals for the Spacemesh VM, and we believe that this candidate design satisfies all of them.

• Incentive compatibility and security: these are cornerstones of everything we do at Spacemesh. It’s critical that all actors involved in sequencing, executing, and proving transactions be able to do so in an incentive compatible fashion and it’s important that we keep the VM relatively simple to minimize the surface area for bugs and exploits.
• Simplicity: beyond security considerations, we want to begin with the simplest possible VM design so that we can ship a prototype as soon as possible, in months not years.
• Decentralization: this is another cornerstone of the Spacemesh project and protocol. We’re totally unsatisfied with the centralized nature of the rollup ecosystem today. It’s essential that our VM be permissionless and that we avoid centralized points of failure from the beginning.
• Scalability: it’s essential that L1 miners need not run every Athena transaction in order to make sure that the system can scale to handling an arbitrarily large transaction throughput. We also want to put in place sustainable economics that limit state growth.
• ZK compatibility: while the system doesn’t need to be provable in zero knowledge today, it’s essential that we ensure future compatibility and be able to transition to a ZK design in the future as ZK proofs get smaller and cheaper to generate and verify.
• Avoiding vendor lockin: as much as possible we want to maintain control over the entire VM stack. We don’t want to rely on complex third party tools that we didn’t write and can’t easily maintain, and we don’t want to couple ourselves too tightly to a rapidly evolving third party standard.
• Developer experience: ultimately the goal of the Spacemesh VM is to empower developers to build great software. Writing applications on Spacemesh should be fun and ergonomic. As much as possible, developers should be able to use their favorite existing languages and tools and not have to learn an entirely new stack.
• Developer safety: we want it to be as easy as possible for developers to build exciting applications on Spacemesh while avoiding many of the pitfalls and footguns that are prevalent in blockchain programming.

Architecture

The best way to understand the Athena design is through its three roles: Relay, Miner, and Executor. It’s important to understand that, like the Spacemesh protocol today, all of these roles are permissionless from the beginning: anyone is free to run a Relay, a Miner, an Executor, or even all three.

Roles

Relay

Most users interact with Athena through a node known as a Relay. A Relay is simply an actor that maintains both an L1 and an Athena account, and that relays Athena transactions to L1 Miners on behalf of users. The Relay is necessary because we don’t want Athena users to be required to maintain funds in both an Athena account and a separate L1 account; users who prefer to do so may bypass Relays entirely, or may themselves operate a Relay.

Athena transactions include two gas payments, both paid using Athena funds: one, paid to Relays, covers the L1 storage cost and the other, paid to Executors, covers the execution cost. Users discover and connect to Relays over RPC connections. They submit transactions to Relays and can perform other basic actions with them, such as checking their account balance. There’s a separate mempool of Athena transactions and Relays gossip these transactions to one another and maintain this mempool. Relays in turn collect Athena transactions into bundles, pay L1 gas on behalf of those Athena transactions, and submit those bundles to L1 Miners. Note that just as there are many Miners that participate in the construction of each Spacemesh L1 block today, many Relays will participate in the bundling of Athena transactions into a given block, ensuring that Athena is as decentralized as the Spacemesh L1. Note also that any user with L1 funds may bypass Relays entirely and submit their own transactions to L1 Miners—or, indeed, operate a Relay and bundle their own transactions with others’ transactions—which ensures that Athena has the same censorship resistance guarantees that the Spacemesh L1 has.

Miner

L1 Miners receive Athena transaction bundles from Relays and, along with non-Athena, L1 transactions, collectively assemble them into an L1 block. Unlike in existing rollup designs, Spacemesh L1 Miners have some degree of visibility into Athena transactions at this stage. They don’t ordinarily run the Athena VM and thus don’t have access to Athena state, but they can nevertheless deduplicate Athena transactions (if a transaction was included in more than one bundle) and sort them by sender (as they do with L1 transactions).

Executor

Executors are the actors responsible for maintaining Athena state (you can think of them as Athena validators, but we prefer the term Executor). They read the set of Athena transactions for a given layer, execute those transactions inside the Athena VM, calculate the new Athena state, and then generate and sign an attestation including the new state root post-execution. Read on to understand the role that Executors play in maintaining the Athena optimistic rollup.

Optimistic

While the goal is to eventually transition to a ZK-based design, for now Athena will run as an optimistic rollup. Executors must post a large stake denominated in L1 $SMH and if they attest incorrectly anyone is free to submit a fraud proof to this effect. While L1 Miners don’t maintain Athena state and don’t ordinarily run the Athena VM, they do adjudicate in case of a dispute. Submitting a fraud proof requires a payment to L1 Miners to cover the cost associated with adjudicating the transaction or block in question. If the adjudication is resolved in the challenger’s favor, the challenger gets this payment back along with a portion of the stake of the malfeasant Executor.

ZK

The goal is to eventually transition Athena fully to a ZK-based rollup design where validity proofs are generated for each block and the challenge-response protocol is no longer necessary. However, this transition will require that ZK technology develop beyond where it is today: in particular, we hope and expect that the cost of generating and verifying proofs will continue to fall to the point where we can launch a truly decentralized ZK rollup infrastructure that ordinary home users can participate in.

In the meantime Athena will use recursive ZK proofs to compress history. This will make it much easier to sync a node from scratch. Rather than needing to download and independently verify every transaction and state transition since genesis, new users will be able to download a single, recursive proof from a recent “checkpoint” that proves the validity of the entire chain up to that point, and will only need to sync and independently verify transactions from that point forward. This history compression isn’t on the “critical path” so ZK work won’t block progress on the rest of the VM.

RISC-V

The underlying Athena VM will be based on RISC-V, a global instruction set standard that’s seeing rapid adoption among blockchains and other projects. RISC-V strikes an excellent balance among several of the goals laid out above. It’s fully open source and permissively licensed, preventing vendor lockin. Its core has been stable for several years, giving us confidence that a VM built on RISC-V today will stand the test of time. It’s a simple, efficient instruction set that will run at near native speed on a variety of systems.

Most importantly, RISC-V is fully integrated into the LLVM compiler toolchain. This means that Athena smart contracts can be written in any LLVM-compatible language starting with Rust. It also means that developers can continue to use the tools they’re familiar with when designing, writing, compiling, debugging, testing, and analyzing Athena smart contracts. What’s more, through the RISC Zero framework, RISC-V code can be proven efficiently in zero knowledge, ensuring future compatibility with the transition to a ZK rollup.

Spacemesh will develop a Rust SDK to enable the development of Athena smart contracts. It will include a set of basic library functions to perform on chain actions such as reading and writing contract state, checking an account’s balance, sending coins, etc. Developers will be able to deploy RISC-V compiled contract code written in any LLVM-compatible language to Athena.

Tradeoffs

This proposed Athena design amounts to a robust, scalable VM stack built on top of the Spacemesh L1 chain and core consensus mechanisms. As discussed above it will allow smart contract developers to develop Athena smart contracts using their favorite language and tooling, and it will allow these contracts to be efficiently and securely executed by the entire Athena network. It will also allow all smart contract execution to be proven efficiently in zero knowledge, ensuring future compatibility with a full transition to a ZK rollup architecture.

The main downside to the proposed design is a lack of compatibility with existing blockchain smart contract languages and tooling, including those targeting the EVM ecosystem. It won’t initially be possible to compile and run existing, EVM-based smart contract code written in languages like Solidity on Spacemesh and Athena, and EVM-based tools like Metamask, foundry, and hardhat won’t immediately work out of the box with Spacemesh and Athena.

However, we believe this downside is more than offset by the fact that Athena will be compatible with the existing LLVM toolchain and with popular IDEs, compilers, debuggers, static analyzers, etc. and by the performance gains that will be achievable over VMs like EVM. What’s more, we do expect to achieve a high degree of EVM compatibility in the future as tools like solang continue to mature and Solidity/EVM are more tightly integrated into the LLVM pipeline.

Open Questions

This article presents the high level Athena design. There are many outstanding questions that we’ll continue to work through over the coming weeks and months. Some of the bigger questions are:

• What’s the exact challenge-response protocol for handling fraud proofs in the optimistic rollup design?
• How large is the L1 stake for Executors? How much is this stake slashed in case of a successful challenge, and what happens to the slashed funds?
• What does the Athena account model look like? Does it use the same type of account abstraction as the Spacemesh L1? Does it use an EVM-like accounts model, a Move-like resource-based model, a Miden-like actor model, or something else? How does it enforce these constraints in the VM?
• What’s the exact bytecode format and how is it executed?
• How do we achieve parallelization in execution of Athena transactions?
• How does Athena meter smart contract code, and how does the system ensure that all deployed contract code correctly enforces metering and other constraints?
• What’s the API for the Athena smart contract SDK in Rust?

If any of these questions are interesting, we encourage you to get involved! See the Contributing section, below.

Next Steps

The Spacemesh team will work on answering these questions and others that arise over the coming days. Our first goal is to release a more complete, top-to-bottom spec with answers to the above questions. After that, the next milestone will be a proof of concept implementation running on a testnet along with some sample Athena smart contracts. Watch our blog, X account, Discord, and other official channels for more information as it becomes available.

Contributing

Like everything we build at Spacemesh, Athena will be designed and built in the open and we welcome community contributions at every step of the process. Are you a smart contract developer interested in developing applications on top of Spacemesh? Let us know what sort of language and VM features you’d like to see! Are you a programming language or VM expert, or a systems engineer interested in helping design and build Athena? Let us know!

We expect to open up more public resources on Github in the near future as the project develops. For now, we encourage you to join the #athena-svm channel on our public Discord and join the conversation there.

FAQ

• Why call it Athena?

Athena is the ancient Greek goddess of craft, wisdom, and warfare. We picked the name Athena in honor of the city where the design was first conceived.

• Where can I learn more about Athena?

We expect to release more information soon. For more information on the thought process and design decisions that went into Athena, see this article.

• Will Athena be EVM compatible? Will I be able to deploy applications written in Solidity to Athena?

Not initially. However, we expect to achieve a high degree of EVM compatibility over time. In the future it should be possible to compile and run smart contracts written in Solidity to Athena with few or no changes. This is not our priority at the moment but we encourage interested community members to begin working on this as soon as a full Athena spec is available.

The decision about whether or not to pursue EVM compatibility is not an easy one and we’ve thought long and hard about it. In the end, we decided not to pursue it at this point so as to maximize other degrees of freedom including allowing developers to write smart contracts in familiar languages like Rust, to use familiar tooling like the Rust toolchain, to maximize performance and enable optimizations like parallelization, and to maximize ZK compatibility.

• Is Athena a Layer two?

Not exactly, for a couple of reasons. For one thing, unlike blockchains like Ethereum, Spacemesh does not have a fully expressive VM at layer one. This is by design, and the idea is that Athena will function as Spacemesh’s primary VM. What’s more, unlike typical L2 rollup designs, the Spacemesh L1 miners play a central role in managing Athena as described above. Athena therefore doesn’t fit neatly into the typical L1-L2 dichotomy; we prefer to think of it as “L1.5.”

• Will Athena allow cross-contract calls? How will it protect against reentrancy and other common bugs?

We’re still figuring this out, and the final answer to these questions will depend upon details like the account model. We do aim to have cross-contract calls and to make them as safe as possible against known issues like reentrancy.

• How will Athena perform gas metering?

We’re still figuring this out, too. It’s likely that, at least in the beginning, Athena RISC-V contract code will be interpreted, and that the interpreter will enforce gas metering. This isn’t the most performant option but it’s simpler and safer than alternatives, which we can explore in future.

• How fast will Athena produce blocks? Will Athena allow faster block times?

Due to the central role played by L1 miners in Athena, Athena blocks will be produced at the same speed as L1 mainnet blocks, i.e., every five minutes. It’s our intention eventually to build a rollup on top of Athena that produces blocks much more quickly, probably with a subsecond block time.

• What language will Athena smart contracts be written in?

While Athena contracts can be written in any language that plugs into the LLVM toolchain, in the beginning we intend to support Rust with a Rust SDK. In future we intend to add support for languages including C and TypeScript, and intrepid developers are welcome to begin working on these as soon as Athena is released (but will have to do so initially without the support of Spacemesh tooling).

• What will be the native asset of Athena?

The native asset of the Athena chain will be $SMH, the same as Spacemesh L1. Users will be able to trustlessly bridge $SMH into and out of Athena using special transactions, and the two will be entirely fungible. Gas in Athena will be paid using Athena $SMH, and Athena-only users will not need to maintain gas or coins on Spacemesh L1.

• When will you launch Athena?

We aim to release Athena to mainnet within a year. We’ll have a test version working sooner than this.

• If I use Spacemesh today, what does this mean for me?

It depends on your use case. If you’re just using the $SMH coin, nothing will change and there’s no required action on your part. If you’re a miner or a developer, read on.

• If I mine Spacemesh today, what does this mean for me?

Nothing is changing today or anytime soon and there’s no required action on your part. Once Athena launches, you should consider whether you want to also run an Athena relay or executor, which will require a small effort on your part and should also increase your revenue. We’ll share more information on this as the project develops.

• If I develop or operate infrastructure or applications (e.g., wallet, explorer, exchange) on Spacemesh today, what does this mean for me?

If you’re a software developer or you operate applications on Spacemesh, or if you intend to, you should pay close attention to the Athena project because you’ll probably be building on Athena in the near future. We’d love to hear what you think! Come chat with us on the #athena channel on our Discord.

• Will Spacemesh support multiple rollups?

Yes! For now Athena will be Spacemesh’s one “enshrined” rollup and execution environment. However, we expect to develop additional rollups on top of Athena, which may feature things like faster block times and native EVM compatibility. We may also consider adding other “enshrined” rollup layers/execution environments like Athena to the Spacemesh L1 in future. More importantly Athena will feature a fully expressive, Turing complete VM so developers can build any type of application on top of it, including other rollups.

• How are assets moved into and out of Athena?

There will be special transaction types that allow this. Moving coins into Athena will involve sending L1 coins using a special transaction that specifies the Athena recipient address; coins will then be minted to the recipient inside Athena. Moving coins out of Athena will involve provably burning them in Athena, at which point they’ll be released on the L1.

• How will Athena support bridges and cross-chain interoperability?

Athena will ship with a native Spacemesh L1 bridge as described above. We’re exploring options for bridges that would link Athena to other blockchain ecosystems such as Ethereum, Solana, and Cosmos. Athena will feature a fully expressive VM so many types of bridges are possible, but the details will depend upon the VM design. We’re also considering integrating Athena into shared sequencers to establish atomic composability with other rollups. If you’re interested in working on any of these things, please talk to us.