Skip to content

Conversation

@evanorti
Copy link
Contributor

WIP

Overview of Cosmos SDK architecture: Comet, ABCI, SDK

Copy link

@aljo242 aljo242 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

overall looks great - just left some nits


## Nodes and Daemons

A blockchain is made up of nodes, or participants in the blockchain network. Each node runs a daemon process (for example, `simd` for a chain built with SimApp) that includes both a CometBFT instance for consensus and networking, and a Cosmos SDK application for the state machine and execution logic. The daemon participates in networking, reaches consensus with other nodes, and executes transactions to update the application state.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will folks know what simd or SimApp are?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll make this clearer. Good suggestion


## CometBFT

CometBFT is a Byzantine Fault Tolerant consensus engine that provides fast, deterministic finality. It's used by Cosmos SDK blockchains to replicate the state machine across a decentralized network.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we link to something here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I'll link out in all of these sections

As the driver of block production, CometBFT controls when the Cosmos SDK application is invoked. It calls the application through ABCI at specific points during block production to validate transactions for the mempool (CheckTx), to construct or evaluate block proposals (PrepareProposal and ProcessProposal), to execute finalized blocks (FinalizeBlock), and to persist state (Commit). The SDK application responds to these calls but cannot initiate them. This means CometBFT, not the SDK application, determines the timing and cadence of block production and state transitions. This ABCI boundary also prevents application logic from influencing consensus.


```python
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this python?

Copy link
Contributor Author

@evanorti evanorti Jan 30, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, the syntax highlighter just adds some better color on the mintlify site if it's a python codeblock. Not necessary though.


### Block Lifecycle Methods

Modern Cosmos SDK applications (v0.50+) use ABCI 2.0, which provides several key methods that CometBFT calls at different points in the block lifecycle.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We probably should just not even mention older veersions of ABCI and assume this is the only paradigm that exists

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed

SDK v0.53 introduces **PreBlock** hooks, which run before BeginBlock. PreBlockers must be explicitly ordered using `SetOrderPreBlockers`. Some core modules (notably `x/auth`) require PreBlock execution; missing PreBlock wiring will cause runtime errors.
</Note>

{/* todo: talk about finality */}
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this for a follow up?

- **[Keepers](#keepers)**: providing interfaces for accessing module state while enforcing access control.
- **[app.go](#baseapp-and-appgo)**: serving as the composition root that wires everything together.

SDK v0.53 supports both manual wiring in app.go and declarative runtime-based wiring via `runtime.AppBuilder`, which reduces boilerplate and provides clear dependency graphs. Modern SDK chains typically use Governance v1, where proposals are submitted via `MsgSubmitProposal` containing executable messages.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I want us to remove all mentions of runtime.AppBuilder and depinject

Co-authored-by: Alex | Cosmos Labs <alex@cosmoslabs.io>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants