Commonware: the Anti-Framework
Today’s blockchain stack is designed to be a jack of all trades, but master of none.
Modeled after virtual machines (VM) and kernels, it exposes a balanced interface through a one-size-fits-all framework instead of molding to the needs of any specific application.
We built a new kind of stack for those spending their time working around this interface rather than leveraging it. With the support of Haun Ventures, Dragonfly Capital, and an experienced group of angels, we are excited to unveil Commonware: the Anti-Framework.
Outgrowing the Virtual Machine
Increasingly, the best builders spend their time working against the general-purpose abstractions provided by today’s blockchain stacks.
Whether incorporating sidecars and relayers to augment them or breaking them altogether with a fork, using these interfaces to transform a crypto app into a great app rapidly veers off the “happy path” with only a few moderate feature requests:
-
Building an exchange and need to offer dedicated transaction gossip for market makers and power traders?
-
Launching a game and need to order transactions in a certain way to deter manipulation?
-
Generating tons of application data for a social network and want to employ a CDN to distribute data?
-
Shipping payments and need to modify the block format to make it easier for a user to verify their payment went through?
-
Simplifying onchain interactions and need to replace a user’s address with a native username?
Much of what leading developers are building today isn’t unlocked with “more framework,” it is solved with less. Instead of building around more of the same blockspace, they want to ship insightful customizations that make sense for their users (and don’t for yours).
Drop the Framework. Its' Cleaner.
We think blockchain applications should be designed differently. Rather than prioritizing standardization and balanced performance across all applications, specialization should be our guide. We think the best developers can build better blockchain applications when they can pick-and-choose the right primitives for the right functions.
Over the last few months, we built a new type of “blockchain stack” designed from the ground up for those who aren’t getting what they need from the frameworks available today. This stack has no explicit layers. No specific security assumption. It is neither monolithic nor modular. There is no hardcoded block format, state layout, definition of finality, mempool policy, execution rules, nor fee metering.
What we do provide is an open collection of “state-of-the-art” primitives that, while designed to work well together, can be rearranged, augmented, and even rebuilt (without forking everything). We call this growing collection of primitives “commonware”.
Just like there are no specific features an application must have, there is no specific set of primitives that must be used to create an application. You can build from scratch or even inject these primitives into an existing blockchain.
Commonware: Now Including Consensus
How far along are we? In early August, we released p2p::authenticated to provide authenticated and encrypted communication directly between public keys. In late August, we released cryptography::bls12381 (with DKG and Resharing Support) to unlock verifiable randomness, connectivity, and trusted access for users. In late September, we released runtime::deterministic to provide a foundation to deterministically test and optimize any primitive (internal or external). Today, we are excited to share our biggest release yet: consensus::simplex (our first consensus primitive).
consensus::simplex provides Byzantine Fault Tolerant (BFT) agreement via a new construction inspired by Simplex Consensus. Unlike other “off-the-shelf” consensus implementations, consensus::simplex is refreshingly minimal. It delivers simple agreement over opaque “blobs”. Functions that have historically motivated developers to create forks, like block broadcast and state sync, are abstracted as interfaces that can be externally implemented. Here are a few nice features:
-
Fast Blocks and Optimal Finalization Latency: Generate a new block after 2 network hops (propose -> notarize ->) and finalize a block after 3 network hops (propose -> notarize -> finalize ->) with authenticated multicast (implemented by p2p::authenticated). With an average network latency between participants of ~150ms, this would mean ~300ms block times and ~450ms finality. Faster network? It moves faster.
-
Unrestricted Execution: Deploy an existing execution environment (like reth) or develop something from scratch with your own blocks, transactions, and whatever else you come up with. Consensus runs over opaque hashes rather than some prescribed block format you must comply with.
-
Externalized Uptime and Fault Proofs: Track and slash validators defined on another blockchain (like an AVS). Determine how and when validators are rewarded for participating in consensus.
-
Decoupled Broadcast and Mempool: Scale throughput with custom logic to propagate application data before, during, and after consensus. Use a proprietary algorithm or even employ the cloud.
To maintain reliability, we run consensus::simplex through a suite of deterministic simulations on every commit. This suite enforces correct behavior during mock network partitions, Byzantine faults, slow/lossy link performance, and cluster-wide unclean shutdown. With deterministic simulation, we can guarantee each simulation covers novel interactions (never running the same order of concurrent events) and yet fully-reproducible, even in a step-by-step debugger. As a result of this focus on testing, consensus::simplex has >90% coverage.
You can see what it looks like to build with consensus::simplex in examples::log, p2p::authenticated in examples::chat, and cryptography::bls12381 in examples::vrf.
Accelerating Development: $9M Fundraise
We’re excited to share that Haun Ventures and Dragonfly Capital are co-leading a $9M investment in Commonware to accelerate our work and to equip us to better support the developers who leverage it.
We are also fortunate to have the support of an experienced group of friends, mentors, and builders pushing the limit of what’s possible onchain:
Going from 0 to 1 isn’t the same as going from 1 to 100. What makes it easy to deploy onchain at the start isn’t the same thing that allows you to push the frontier next.
That’s what commonware is for.
Let’s Build Something Together
If you can’t build what you want onchain, reach out to us at partners@commonware.xyz. We’re looking for 3 ambitious teams to collaborate with that want to leverage commonware to build unique applications across a variety of security configurations (L0, L1, L2, restaked security, or somewhere between).