Monolithic Rollups Node

Over the past two years, the Cartesi Rollups node evolved organically as we understood its requirements. Some design decisions made a lot of sense in the past, but now it is time to re-evaluate them. In particular, the node evolved as multiple microservices developed by different people. This division of labor allowed multiple teams to work on it simultaneously but made the node a non-cohesive software. For instance, running a node has always been challenging; even today, with Sunodo, the complexity is hidden but still there. Moreover, the fractured node design makes it very cumbersome to implement new features, such as improving data availability.

In this post, I want to share my vision that we should rewrite the node as a more uncomplicated monolithic application. This simplification would make it much easier for anyone to understand the code base and for the node unit to work on new features. As a side effect, running the monolithic node will be much easier because it will be a single application instead of multiple ones. I also expect a monolithic node to be much more reliable because there are fewer moving parts.

There is a general concern about the scalability of monolithic applications. Monolithic applications generally don’t scale infinitely like micro-services because they are not designed to do so. However, even though the current node has several microservers, it also doesn’t scale. So, moving to a monolithic architecture won’t be a software performance regression. Moreover, we should avoid the temptation of premature optimization. We still don’t have hundreds of Cartesi applications running on production, so we shouldn’t worry about this use case for now.

Once we have a simple and easy-to-understand code base, we will be better positioned to adapt it to fit our needs, regardless of what they will be.

3 Likes

Thanks for the write-up, very clear!

Great proposal, this indeed looks like would bring great simplifications to the node.

I like this direction that the node is taking.

Pushing more into that direction, I would also look forward to the day we can maybe run a node without Docker, from a single binary plus a few files. Like in the first days of Bitcoin, anyone could run a Bitcoin “node” just downloading its binaries, without needing Docker. Not sure if this will be ever possible though, I don’t have in mind all components that are needed. I think going away from Docker opens the door for anyone to run a node on more platforms (like Windows, mobile phones) and makes the setup easier, increasing the adoption of node runners and decentralization.

1 Like

The monolithic architecture is essential to implement new features in the node, such as the dehashing device. Implementing this kind of feature in the Rust node would require an order of magnitude more effort; in the end, it would be slower than just implementing the feature in the new architecture.

In the 1.3 release of the rollups node, we are adding the Go supervisor feature, which will act as an interface that hides the internal node architecture. With this interface, we will be able to start the movement to the monolith node while we still use some components of the old node.