Orga: A Rust State Machine Engine

Hello, world!

We're Turbofish - a small team of Rust hackers in Austin, TX building next-gen decentralized systems like Nomic.

We're craftsmen. The joy of engineering things right motivates us as much as the finished product. So, in this blog post, I'm excited to share some detail about how we work, and one of our more behind-the-scenes projects, Orga.

You may already know this if you're on this blog, but we're founders and core contributors to the Nomic Bitcoin Sidechain. We believe Bitcoin is the reserve currency of the internet, and Nomic aims to bring Bitcoin to the rest of DeFi via Cosmos and the IBC protocol.

What you may not know, however, is that Nomic is built on a custom state machine engine that's been in development since 2018, Orga.

A priori, building a custom blockchain stack and a Bitcoin bridge seems a lot harder than just building the bridge. So, why build a custom stack instead of using existing tools?

Why we built Orga

During our work in the early days of Cosmos, back before the Cosmos SDK had even been named, we developed LotionJS: a JavaScript framework for writing blockchains with minimal friction. Our heuristic for Lotion: "It should feel like writing an Express app."

We formed strong opinions about how to write blockchain apps. The Cosmos SDK then matured into a solid piece of software, but it was too late for us; we'd been spoiled.

We wrote the first version of Nomic in JavaScript, but quickly felt the growing pains of the language and the framework, both in terms of performance and of managing complexity. We'd nailed "easy," without quite nailing "simple" or "composable".

Merk

Our focus shifted to improving performance, so we began to rewrite just our custom Merkle KV store, Merk, in Rust. More specifically, we built a high-performance Merkle AVL tree on top of RocksDB (Facebook's fork of LevelDB).

Merk has now grown to offer the best performance in the industry, even offering from 2x to 20x better throughput than Jellyfish Merkle Tree (the storage engine used in Aptos, and currently thought of as the fastest Merkle tree available).

The storage layer is the most critical part of optimizing transaction throughput on a blockchain since every transaction creates reads and writes, meaning chains built on our stack have the potential for extremely high throughput.

You can learn more about Merk here. Keep an eye out for further posts on Merk and Merkle trees in more detail, and open-source some benchmark code for people to reproduce the results we teased here.

Cliche as it sounds by now: building Merk naturally became the start of our "rewrite it all in Rust" journey.

Orga

So, we developed Orga: a Tendermint-based state machine engine with a focus on composability, expressiveness, and performance. Our golden rule: "It should feel like vanilla Rust."

The result is very clean and succinct code, especially when compared to Cosmos SDK. Comparable functionality can be built with an average of 10x fewer lines of code, meaning less complexity, fewer bugs, and faster development cycles. All this without any tradeoffs since the result is a significant performance increase.

We value bottom-up design. We don't want to just build our programs down to the language, we also want to build our languages up to our problem domain.

To make this possible, we have created well-designed abstractions and we leverage the same construct as the seasoned LISP programmer: macros, which have been refined by dogfooding with Nomic for multiple years.

Here's a little taste:

use orga::prelude::*;

#[orga]
pub struct Counter {
    counts: Map<u8, u32>,
}

#[orga]
impl Counter {
    #[call]
    pub fn increment(&mut self, index: u8, n: u32) -> Result<()> {
        let count = self.counts.get_mut(index)??;
        count += n;
    }

    #[query]
    pub fn count(&self, index: u8) -> Result<Option<u32>> {
        self.counts.get(index)
    }

}

I'm not sure why you'd need a Globally-Distributed Instant-Finality Byzantine Fault-Tolerant Number Counting Application, but if you did, here's the whole thing. Just add validators.

Orga also features an advanced RPC system (calls and queries) which lets you build business/on-chain logic once, then reuse those types/methods on the client-side. So no extra code has to be written for clients, all data and logic are available to clients by default (also automatically generates and verifies proofs for all of this functionality, so that the data can be served by any node in a decentralized way).

In future blog posts, we'll talk more about the core ideas in Orga. It took a lot of exploration to find what we consider to be close to the global optimum in the design of the core concepts. We'll also share more thoughts on how we intend to push performance and scalability to the limit as we implement concurrent transaction processing and improve our store throughput (which is already extremely high).

Zooming out a bit: could we have built a Bitcoin bridge faster using existing tools? Probably. But it wouldn't be the kind of bridge we're building; it would've required compromises on complexity and scalability. We're inspired by Bitcoin to build something that'll stand the test of time.

We've invested a huge amount of effort into our tools and recently reached the inflection point where it's starting to pay off. I think you'll soon start to feel the love and craftsmanship leak out around the edges of everything we build, including Nomic and our future projects.

We’d love to hear your thoughts on Orga, as we continue to build. And if you’re good at Rust, we’re hiring!