Update 2024-05-09-project-update.markdown

Demote headings

_posts/2024-05-09-project-update.markdown

@@ -8,12 +8,12 @@ categories: athena update
 It’s been a couple of months since we announced the Athena project and a month since the last update. I’ve spent the past few weeks doing research into best practices and the state of the art in blockchain VM and zkVM design, tooling, programming language design, etc. across a number of ecosystems including EVM, Move, Solana, Bitcoin, NEAR, and Cairo (I previously wrote a little bit about some of the [initial experimentation](https://rettig.substack.com/p/blockchain-devex-battle)). I want to take the opportunity to update the community about how the Athena project is going: what has and has not changed from the goals and plans we originally announced, what’s been done, what we’re working on right now, and where we go from here.
 
 
-# Goals
+## Goals
 
 We previously shared [eight goals](https://spacemesh.io/blog/introducing-athena/) for Athena: incentive compatibility and security, simplicity, decentralization, scalability, ZK compatibility, avoiding vendor lockin, developer experience, and developer safety. I want to zoom in on a subset of those goals that I’m especially focused on right now and discuss some of the tradeoffs among them, and to add one new goal.
 
 
-## Developer Experience
+### Developer Experience
 
 It’s difficult to measure developer experience since it’s by definition highly subjective. As one common example, some developers prefer frameworks, languages, and tools that are [highly opinionated](https://hackernoon.com/opinionated-or-not-choosing-the-right-framework-for-the-job-6x1u2ga0) and reduce the number of decisions they make; others prefer more degrees of freedom at the cost of higher complexity and more security risks. There’s no one-size-fits-all solution for all developers, teams, and use cases. Our goal as infrastructure designers and developers is therefore to pick a reasonable compromise and to build a system that allows both kinds of experiences to be built on top, to the extent possible.
 
@@ -24,7 +24,7 @@ The blockchain technical community is big and important, but it’s not as big o
 The plan is still for Athena smart contracts to be written in idiomatic, standard Rust, to include at least partial support for the Rust standard library, to be compiled using mainline Rust and a mainline LLVM target, and to support all existing LLVM tooling including compiler, debugger, optimizations, etc.
 
 
-## Performance
+### Performance
 
 Performance wasn’t on the original list of goals but it’s sort of implied under “scalability.” There are several dimensions to performance and ensuring that Athena is as performant as possible imposes several constraints on its design space. For one thing the target bytecode should as small as possible so that Athena programs don’t impose an undue storage burden on Spacemesh L1 miners. It should also be possible to compile programs using [`no-std`](https://docs.rust-embedded.org/book/intro/no-std.html) to product artifacts that are as small as possible.
 
@@ -33,7 +33,7 @@ Recall that Athena programs need to run in two different but related contexts: i
 While it’s not possible to perfectly and completely optimize for both of these competing goals simultaneously, we still think RISC-V is an excellent choice and serves both execution paths well. RISC-V is a simple, performant, well-designed instruction set that performs well compared to alternatives including Wasm and Solana rBPF. We need to do some additional benchmarking but the reports we’ve seen from others are [promising](https://github.com/koute/polkavm/blob/master/BENCHMARKS.md). In particular to optimize the direct execution path, RISC-V is a good choice because the instruction set is simple, is based on an actual hardware ISA (unlike Wasm), and by carefully choosing the RISC-V subset we support (in particular, a recent “embedded” variant that uses only 16 registers) we can expect very good performance. It should be possible to compile Athena code to RISC-V bytecode, to perform some initial optimizations (a process that happens offchain), and then to store the result on chain. Executors will subsequently take this RISC-V bytecode, promote it to native code and execute it at near-native speed.
 
 
-## Succinctness
+### Succinctness
 
 But that’s not all! Today there’s not [one](https://github.com/risc0/risc0), not [two](https://github.com/succinctlabs/sp1), but in fact [three](https://github.com/a16z/jolt) independent tools that support efficiently generating succinct proofs (i.e., ZK proofs) for vanilla RISC-V code (and others that [look promising](https://github.com/NilFoundation/zkLLVM)). These tools are at varying degrees of maturity but they’re maturing rapidly; we’ve tested them and studied their code and believe that they’ll work well for our use case. The fact that these projects are open source, that each is designed and implemented independently and that each is based on a different circuit design is reassuring.
 
@@ -42,7 +42,7 @@ While we’re not primarily focused on succinctness or proving efficiency at thi
 While it’s possible to prove the execution of Ethereum transactions using these tools (and they’ve produced [proofs](https://github.com/risc0/zeth) of [concept](https://github.com/succinctlabs/sp1-reth) to this effect), doing so is inherently inefficient since it effectively requires writing a _separate_ Ethereum execution client, compiling that client to RISC-V, and then running it inside the ZK circuit (which means EVM smart contract code is running inside a VM that’s running inside a zkVM—yes, you read that correctly). This leads to one of the **boldest, most novel goals of Athena: to produce smart contract program code that can be run _natively_ inside a RISC-V execution circuit**, i.e., without adding an extra layer of indirection. As far as we’re aware Athena is the first ever attempt to do this and it should make proving Athena execution at least two orders of magnitude faster and cheaper than doing the equivalent with EVM.
 
 
-## Platform Independence
+### Platform Independence
 
 It’s just as important to speak to the paths not taken. We took a good, long look at two ecosystems in particular: Move and Cairo. Both have a lot going for them and I have many good things to say about both. Starkware recently open sourced both the [current Cairo prover](https://github.com/starkware-libs/stone-prover) as well as an exciting, [next-generation prover](https://github.com/starkware-libs/stwo) based on a novel technology known as [Circle STARKs](https://eprint.iacr.org/2024/278). Cairo has matured rapidly from an [obscure domain-specific ZK language](https://perama-v.github.io/cairo/examples/first_application/) to something that looks and feels a lot [like modern Rust](https://www.cairo-lang.org/cairo-v2-6-0-is-out/). In fact, Cairo now looks quite a bit like Move and I doubt that’s an accident. In my estimation the Move language and VM are mature and exceptionally well-designed. Move addresses many of the shortcomings of EVM. The syntax for writing smart contracts in Move is concise and intuitive. The [resource and ownership model](https://move-language.github.io/move/structs-and-resources.html) (inspired by Rust itself) makes a lot of sense and, in particular, it means that common smart contract patterns can be expressed in code that’s an [order of magnitude simpler](https://medium.com/@kklas/smart-contract-development-move-vs-rust-4d8f84754a8f) than, say, in Solana.
 
@@ -53,7 +53,7 @@ On top of these issues, platform independence and avoiding vendor lockin are big
 By contrast, Rust, LLVM, and RISC-V are universal standards, as universal as you can get in computing. We can confidently build Athena in the Rust ecosystem and know that we won’t be left holding anyone’s bags in the future.
 
 
-## Compartmentalization
+### Compartmentalization
 
 Something quickly became obvious while doing this research: with respect to our plans and goals for Athena and the tools we’ll use to achieve them, we’re standing on the shoulders of giants in a very big way. In particular, building something like Athena even two or three years ago would’ve cost $100M and required a huge team including compiler and programming language experts, cryptographers and ZK experts, protocol designers and mechanism design experts, etc. We have some of this expertise on our team but not all of it, and Spacemesh has nowhere near that many resources at its disposal. Nevertheless Athena is achievable today due to some massive breakthroughs and advances, and thanks to wonders of open source software and research. In particular ZK technology has made enormous advances in recent years and the emergence of the abovementioned tools that allow proving RISC-V code efficiently using a general-purpose circuit is a key enabling technology. (AI tools that have helped me get up to speed on a lot of these topics also feel like a superpower and deserve our gratitude!)
 
@@ -62,7 +62,7 @@ Given these limitations it’s as important to define what Athena is _not_ as wh
 We will rely on existing code and ideas as much as possible in the design and engineering process for Athena in order to limit its complexity, and we’ll give credit where credit is due for ideas and code that we utilize!
 
 
-# What’s Been Done So Far
+## What’s Been Done So Far
 
 The deterministic VM, programmability, embedded computing, and zero knowledge space is big, much bigger than I anticipated when I began this research. The first few weeks of research were exciting but also exhausting because every day I learned about three new tools I needed to study and the list of topics to explore kept getting longer and longer. It took a few weeks but I did finally get through the entire queue. I want to share a snapshot of what I explored, what I learned, and trends that I see.
 
@@ -75,27 +75,27 @@ In the VM space more generally I studied the Solana VM, the Move VM (Diem, Aptos
 There are two important outcomes from all of this preliminary work. First, I can say with confidence that there’s nothing out there that ticks all of the boxes that Athena does (a developer-friendly VM based on a modern, non-domain specific programming language and toolchain that runs at near-native speeds and also natively targets an efficient zkVM). Second, I still believe that our proposed design is the best choice. In other words, I stand by everything we said in our previous [Athena announcement](https://spacemesh.io/blog/introducing-athena/).
 
 
-# Stages
+## Stages
 
 Athena is obviously a large, ambitious project. As I indicated at the top of this post the preliminary research phase is now complete and it’s time to start the next phase, which involves developing a proof of concept implementation. Ongoing work will proceed in four mostly independent, mostly parallelizable stages.
 
 
-## Low Level Design
+### Low Level Design
 
 Basically everything I wrote above is low level design. This includes programming language and SDK design, core architecture including word size and register count, choice of instruction set and syscall regime including IO, bytecode artifact format, compiler and linker toolchain, and how to handle cross-contract calls/the call stack. It includes precompiles. It includes the strategy for compilation, interpretation (if appropriate), and execution more generally including verification of smart contract code and gas metering. It includes benchmarking all of these things.
 
 
-## High Level Design
+### High Level Design
 
 The high level design builds upon the low level design but also allows abstraction and “black boxing” of the low level VM. It includes the design of the account model, how code and state are stored and updated, and how they’re permissioned. This is likely to include concepts like account abstraction and resources.
 
 
-## Mechanism Design
+### Mechanism Design
 
 The mechanism design is basically the design of the rollup-like architecture that powers Athena. It includes each of the [Athena roles](https://spacemesh.io/blog/introducing-athena/)—relay, miner, executor, prover—and the incentives and game theory that ensures that the entire system runs in a secure and efficient fashion.
 
 
-## Succinctness
+### Succinctness
 
 Succinctness involves the “ZK rollup” design that Athena will transition to over time. It involves questions including which proving system we use, how to parameterize the various tradeoffs involved in proving (required compute and memory, proving time, proof size), and how to handle edge cases like what happens if a proof is missing or after a reorg.