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.