Constantinople

For a thousand years, the world's richest trade route ran through a single city. But Constantinople didn't grow rich moving cargo; it grew rich counting it. Throughput on a ledger is only worth something once you can read it back.

Enter Constantinople: a payments-focused blockchain built entirely on Commonware Library primitives pushing ~70k TPS with fully authenticated state on 50 16vCPU instances (c8g.4xlarge) in us-east-1 and us-west-2. Alongside it, Exoware, the indexing layer that turns that firehose of state into something you can actually query and verify.

From button click to a confirmation backed by the finalized chain, the clip above takes under a second. What matters isn't just the speed, or that a transaction landed; it's where it was verified. Every step runs in the browser, with no trusted intermediary and no RPC to take on faith.

First, the client verifies the BLS12-381 threshold certificate over the finalized block, confirming that a supermajority of the validator set agreed on that view. Next, it pulls the block header itself and checks that the block's commitment matches the one the certificate signed. Finally, it verifies an inclusion proof placing the user's transaction under the block's global transaction root, the same root consensus committed to. Only then does the UI mark the transaction confirmed. That is full light-client verification, from a consensus certificate all the way down to a single transaction, running on the same device that signed it with a WebAuthn passkey.

And nothing signs on the user's behalf. Validators verify the raw WebAuthn payload natively, as a first-class transaction signature: the assertion is a secp256r1 signature whose challenge is the transaction digest itself, so the passkey signs the exact transaction it authorizes. A relayer forwards that signed transaction on to the next leader, but it only moves bytes: it holds no keys, cannot re-sign or rewrite the transaction, and cannot forge one. There is no bundler, paymaster, or account-abstraction layer translating passkeys into transactions on a user's behalf. The transaction the user signs is exactly the transaction the chain verifies.

Architecture

Component	Primitive
Consensus	simplex (with the BLS12-381 threshold scheme) + erasure-coded broadcast
P2P	authenticated::discovery
Storage	qmdb (qmdb::any + qmdb::keyless::CompactDb variants)
Execution	glue::stateful (with ed25519 and secp256r1/WebAuthn accounts)

Every layer is a commonware primitive: no external frameworks, no opaque glue code stitching them together. Well, almost no glue.

commonware-glue

commonware-glue's first primitive, stateful, is a reusable high-throughput base layer for stateful applications: bring a state transition function (STF) and it hands you simplex consensus, QMDB storage, pending state trees, crash recovery, and trustless state sync underneath it. Constantinople is just one such STF. Everything below the execution layer is shared, unmodified, reusable infrastructure.

Pending State Management

Through the new QMDB batch API, glue maintains a tree of pending state changes on top of the finalized chain, enabling safe computation of the state root in each block. When consensus finalizes a block, the branch of pending batches leading to it is persisted to disk and the rest are pruned.

State Sync

In addition, glue::stateful provides a route for trustless state synchronization, using the finalized chain as a source of truth for database roots and active operation ranges. As a refresher from "The Simplest Database You Need", QMDB variants are constructed over an append-only log of operations, maintaining an "inactivity floor" (before which, no operations are required to compute the current state). State sync is the process of fetching batches of operations spanning subsets of [inactivity_floor, database_size), along with range proofs to authenticate the received operations, in order to bootstrap the chain state. No rolling snapshots to maintain as a chain operator, and no execution required to get caught up to tip as a participant!

Deployment

On a live deployment with 50 validators and 2 secondary nodes (relayer, indexer) across us-west-2 and us-east-1, Constantinople achieves a throughput of ~70k TPS with a block time of ~250ms and finalization latency of ~385ms (p75). Every block is around 2.5MB in size, distributed across the network in erasure coded chunks by the proposer. To stress QMDB compaction in the worst case, each block deliberately updates ~2^14 existing accounts: every update supersedes a prior value, forcing the inactivity floor to climb and the database to compact aggressively. In total, the chain has 2^14 * 50 accounts.

Where does it all go?

As you can see, disk utilization on the indexer is growing rapidly - around 720GB per hour. The indexer in the above deployment is using Exoware's RocksDB-backed simulator, and maintaining this level of throughput for more than even a few hours would require complex auto-scaling, provisioning new disks several times a day, large compression routines, and more.

Stay tuned for Exoware's solution to this problem: store.

Run it yourself

Constantinople is open source on GitHub under Apache 2.0 and MIT. Try it yourself today by running:

            
git clone https://github.com/commonwarexyz/constantinople.git && cd constantinople

# Set up a local cluster with 4 validators and 1 indexing secondary.
cargo run --bin constantinople-deploy -- generate \
    --validators 4 \
    --indexer \
    --relayer \
    --spammer \
    --spammer-accounts 4096 \
    --spammer-accounts-jitter 0.1 \
    --output-dir ./local \
    local

# Run the `mprocs` command printed by the setup script to start the cluster.
            
        

For a more detailed guide on deploying a Constantinople cluster remotely, check out the remote deployment instructions.