Comparing Single Binary vs. Separate Binaries Approaches for Rollups using Cosmos SDK: Pros and Cons

[smuu]

In this discussion, we explore the pros and cons of two approaches for building and running a rollup using Cosmos SDK: the single binary approach and the separate binaries approach. This discussion aims to gather feedback, opinions, and additional pros and cons without making an initial judgment on either approach.
In the single binary approach, the Rollkit and Cosmos SDK components are integrated into one executable, providing an all-in-one solution. In the separate binaries approach, the Rollkit and Cosmos SDK components are built and run as separate executables, adhering to a microservices design. This discussion aims to compare the pros and cons of both approaches for Rollups using Cosmos SDK.

• Single Binary Approach
  • Pros
  • Cons
• Separate Binaries Approach
  • Pros
  • Cons
    

Single Binary Approach

Pros

1. Easy Installation & Configuration: Users only need to install and configure a single binary, reducing complexity and making it easier for non-technical users to get started.
2. Consistent Performance: A single binary allows for a more predictable performance without communication overhead between separate components.
3. On-demand Operation: The Cosmos SDK app can be started and stopped on-demand, potentially saving resources when not in use (e.g., for light nodes).
4. Debugging & Development: Debugging and development are more straightforward as there is only one binary to work with.

Cons

1. Monolithic Architecture: A single binary approach leads to a more monolithic architecture, making it more challenging to maintain and scale in the long term.
2. Limited Flexibility: The single binary setup offers less flexibility for users wanting to use different components or customize their setup.

Separate Binaries Approach

Pros

1. Modular Components: Separating the binaries allows for a more modular design, making it easier to maintain and update individual components. It enables the usage of alternative implementations of components.
2. Flexibility: Users can choose different components and customize their setup according to their needs.
3. Microservice Design: Adheres to the microservice design principles, allowing for better scalability and maintainability in the long term.
4. Consistent setup: Setting up a Cosmos SDK app is similar to setting up an execution environment, potentially making it easier for developers to learn and understand.

Cons

1. Communication Overhead: With separate binaries, communication overhead is introduced, leading to potential performance degradation.
2. More Complex Installation & Configuration: Users must install and configure multiple components, which can be more complex and time-consuming.
3. Always Running: The Cosmos SDK app is always running, consuming minimal resources even when not in use.

Please share your thoughts and opinions on these two approaches and their corresponding pros and cons. Feel free to comment on this discussion if you have any additional pros or cons. We want to ensure that we comprehensively understand the trade-offs involved in each approach before making a decision.

[Wondertan]

Monolithic Architecture: A single binary approach leads to a more monolithic architecture, making it more challenging to maintain and scale in the long term.

A single binary approach does not necessarily lead to monolithic architecture. If the architecture has separated boundaries/interfaces between modules/components, it can be run both as a single binary or as a set of binaries via RPC. Well-designed micro-service architecture can be a single binary or multiple of them independently of web2 or web3 context.

Limited Flexibility: The single binary setup offers less flexibility for users wanting to use different components or customize their setup.

Same here. The modular software architecture provides proper defaults while giving developers the ability to choose non-default components depending on their needs or even custom implementations.

However, when we talk about CosmosSDK and Rollkit we don't have(yet?) the described architecture and it might make sense to run Cosmos App and Rollkit separately.

[Wondertan]

Stumbled upon https://twitter.com/kelseyhightower/status/1654141882631331841?s=46&t=F0TNL33Oz9ZO5uFySG1Yow today, which is highly related

[Bidon15]

I would say that Rollup teams should not rely on vanilla running binaries within a host machine and opt for proper containerisation & orchestration tool. A single binary design is much better UX for vanilla and really fast. However, we need to think of long-term deployment + running (testnets are a good example) processes.

imho, from dev UX wise, running separately can point rollup devs to focus more on their rollup

[MSevey]

From a rollup framework perspective, I think it will be hard to maintain a single binary.

The idea of rollkit being that you can plug and play various execution layers, settlement layers, DA layers, etc, trying to build a single binary for that feels like there will be lots of headaches around maintaining build tooling.

I think we should stick with multiple binaries for now for rollkit until we have several examples of different chains to understand the implications of trying to build a single binary.

Note that this is separate from the discussion of single vs multiple binaries for celestia node and app.

[nashqueue]

Currently, we have a single binary for (Rollkit + ComsosSDK),. The discussion is about splitting it into Cosmos SDK app + rollkit node, not about combining it.

[MSevey]

ah, I misunderstood the prompt.

Do we have examples of other projects that have separate binaries for the cosmos sdk app?

I think we are too early to make a clear cut decision one way or another tbh. While we have a single binary now, we have a pretty modular software architecture so I don't see use falling into the monolith architecture problem in the foreseeable future.

[nashqueue]

If we want to use rust applications that connect through ABCI then we need to have 2 separate binaries.

• cwd uses https://crates.io/crates/tendermint-abci for example
• penumbra uses https://github.com/penumbra-zone/tower-abci

Both talk through a port with each other.