Commonware unveils ‘anti-framework’ for optimized blockchain development

Building an application or a rollup today isn’t difficult. Whether it’s the OP Stack or Arbitrum Orbit, there are a variety of blockchain technology frameworks to choose from.

These tech stacks are tremendously useful for builders to go to market quickly, but they’re also constraining in practice. 

Crypto is still a young industry, and businesses seek increasingly differentiated architectures to suit their unique use cases.

As such, most applications do not fit into an existing technology stack framework. For instance, an application builder may want to change what happens in a block, or introduce custom cryptography, rather than being tied to the rules of how an L1 blockchain’s state is governed.

So developers frequently fork and customize to get what they need. Cosmos’ CometBFT consensus layer (itself a fork of Tendermint Core) for instance, is one of the most frequently forked consensus mechanisms by projects such as Sei, Celestia, dYdX, Penumbra and more.

For a thousand chains or dapps to bloom, builders want even more modularity than simply choosing between data availability layers or consensus mechanisms. That’s the bet middleware blockchain infrastructure platform Commonware is making.

Commonware is an open-source “anti-framework” set of primitives that developers can use to build and reassemble their applications without resorting to a complicated fork.

Led by a $9 million fundraise backed by Haun Ventures and Dragonfly Capital, Commonware wants to break the existing “one-size-fits-all” mold that comes with today’s technology stacks.

“Frameworks today like the Cosmos SDK and CometBFT is open and flexible in a few specific ways, but I argue that you get stuck eventually,” said Commonware founder Patrick O’Grady. “You have to redo and fork and rebuild a lot of stuff, and builders end up spending too much time dealing with the abstractions rather than focusing on the product.”

Existing frameworks prescribe a standard way to build an app. In contrast, Commonware does not tie developers into any specific security configurations, hardcoded block formats, mempool policies or execution rules.

Developers building with Commonware can custom design their own mempool configurations, or introduce their own execution environments, rather than having to comply with prescribed block formats. On the consensus layer, they can determine how validators are rewarded.

“We want builders to be able to use Commonware to couple their existing applications with their own custom capabilities,” O’Grady said. “Developers shouldn’t have to decide which ecosystem’s religion they want to be part of first, then build their application as a second step.” 

For that reason, Commonware’s set of architectural primitives is best thought of as an optimized, architectural way to build in Web3.

One such primitive is the consensus::simplex, a minimalistic consensus primitive that provides Byzantine Fault Tolerant (BFT) agreements.

For Commonware chains to communicate with one another, the team plans to incorporate an optional threshold signature primitive into its consensus construction.

The threshold signature would enable any chain to generate a static public key and verify outputs from other chains, thereby enabling efficient point-to-point communication without chains sharing any similar overlapping trust assumptions.

Commonware is not striving to create another “chain of chains” architecture such as the OP Superchain, which binds you into preset execution rules, O’Grady explains. It further extends the modular evolution of blockchains that Ethereum’s rollup-centric roadmap kickstarted and augments existing virtual machines, rather than completely replacing them.

For more, tap into the Bell Curve podcast with Commonware.

---

Get the news in your inbox. Explore Blockworks newsletters:

• The Breakdown: Decoding crypto and the markets. Daily.
• 0xResearch: Alpha in your inbox. Think like an analyst.