The Cartesi Rollups Node only works for a single DApp. So, if a node runner (e.g., sunodo) wants to run multiple DApps simultaneously, it must start and manage multiple nodes. Starting multiple nodes at a container level requires significant effort, and the implementation will be tied to an orchestration framework (Kubernetes). Moreover, we are already facing some problems with this approach: Share transaction manager accross Rollups Nodes - #5 by gligneul.eth.
Proposed solution
The Rollups Node should handle multiple DApps simultaneously, with a management API to add and remove DApps during runtime. Then, instead of managing containers at the Kubernetes level, the Node will manage lightweight nodes inside its container. We can do this in small steps, starting from the current node implementation. Nonetheless, this requires significant effort from the Node Unit.
I’m a big supporter of this. It’s crutial for sunodo, not only to greatly reduce costs but also to actually make it work with a single wallet and Authority for all dapps.
Im also a big supported on this initiative reducing costs on Sunodo side is paramount
Simple question that came to my mind: In the quorum mode, dApps running inside a single Node will have to use all the same validators choice? I mean In validator A we have 1,2,3 dApps while on validator B the 2,3,6 dApp and validator C the 1,2,6?
It will be one validator per node. So, If you want to use a quorum, you must run multiple nodes. A node can support DApps with or without quorums at the same time. It should also be possible to run DApps for different quorums inside the same node.
For the node, it does not make a difference if its a Quorum consensus or an Authority. The difference is that in the Authority the claim will be accepted as soon as the validator adds it. In the quorum the claim will be accepted when the majority of validators for that DApp post the same claim.
it does not make a difference if its a Quorum consensus or an Authority
But the configuration of the node is different (the address of the IConsensus).
So we have to see how to be able to configure that per DApp in the same multi-dapp node. This is not planned as of now.
Multi-dapp nodes as part of a deeper change in how Cartesi applications work
Hi guys. While dealing with Node v2 APIs for the Espresso integration effort, I started to think that the changes brought by the multi-dapp node do not relate only to the APIs used by clients to query information, but also potentially to the very philosophy around how Cartesi apps work, and what a “Cartesi L2” (or L3) means.
I confess I originally considered this feature to be only about enabling better node operator infrastructure, as discussed above, but now I believe it to be part of something quite more impactful.
With multi-dapp nodes, application clients no longer connect to the app back-end via an app-specific node. Instead, they connect to a more “global” node (for a given base layer), which would be running a subset of the Cartesi apps deployed to that base layer. In this context, it starts to make sense to have the concept of a “Cartesi network” for each base layer, in which app execution is somehow spread around existing nodes.
As such, I believe that the relationship between application code and the node to which the app is deployed becomes less obvious, which has its own consequences. Today, front-end clients normally come configured with the URL of the app-specific node that is running its back-end. If back-ends are spread around a network of nodes, then it may be important to devise a mechanism to allow client requests to be routed to an appropriate node, as suggested by @pedro.argento in his Vision Forum entry “Node Marketplace”. It would probably also make sense for nodes operators to be able to add apps on demand: that same Vision Forum entry also proposes a way for nodes to be signalled about which apps are worth running.
PS: signalling promising apps to run is also proposed by the Vision Forum entry “Appchain attention economics”, which is focused on incentive mechanisms for validation nodes (as opposed to reader nodes). So, for validator nodes it should probably also make sense to be able to add apps on demand.