Rollups in Browser (RiB)

Technical Vision Forum Technical Evolution Plan
1

It has already been demonstrated that Cartesi Machines can be executed inside the browser (kudos to @edubart, who even got Doom running there!). With this capability, it becomes possible for a web app to feed inputs into a machine and then read back its outputs. These inputs could even be a DApp’s actual inputs (e.g., the ones added to its on-chain InputBox), making it possible for a web front-end to keep in sync with the DApp’s state without needing to fetch data from a Reader Node.

This approach, once baptized by @tuler as “Rollups in Browser” or “RiB”, could bring potential great benefits in terms of convenience and resource consumption. Namely, it would become possible to run applications without having to instantiate Reader Nodes!

One important caveat: in principle, this would only be viable for applications with relatively small Cartesi Machines, because there is a limit of 4MB for the browser WebAssembly environment. In any case, it could be a great solution for small applications, and particularly welcome for newcomers being onboarded (which would have an easier time not having to connect their web app to some Reader Node). Another thing to note is that this proposal is not suggesting there would be a full Reader Node running in the browser, with a GraphQL indexed database and everything! The web app would simply collect the outputs generated by the machine as they are generated, and process or store them as they wish.

RiB could also be an interesting way to scale inspects (state reads). Currently, DApp Reader Nodes need to serve inspect requests from all users of the DApp, but this approach would allow each user to generate the DApp’s state directly inside the browser in “near real-time”.

A final pragmatic note: it probably won’t be practical for the browser to sync an application starting from genesis. For that matter, the best approach would probably be to load the last finalized application state from somewhere like IPFS (preferably with Lambda), start up the machine in the browser with that state, and then sync only the inputs that were sent after that. From then on, the client could keep itself updated by feeding the inputs directly observed from L1 or the sequencer, with potential very low latency.

More details and previous discussion can be found in this Discord thread.

1 Like
2

One addition is that the implementation will probably have to deal with Web Workers, and run the CM outside of the browser UI thread, or the UI will freeze constantly. This will require usage of message passing between the main browser thread and the worker thread which talks to the Cartesi Machine.

3

In addition to what has been said, it is worth mentioning that running Cartesi Machine in the browser also brings all it can offer to the Web frontend, that is, a deterministic machine capable of running a full Linux OS with any programming language and common software stack.

Depending on the application, it can be useful to have a deterministic Linux machine running in the frontend, to pre-compute logic before submitting anything on-chain. This frontend machine doesn’t necessarily need to be the same machine running in the node backend, it can be much smaller and always starting from an initial state (like Lambda).

One example of use is computing the score of a complex game using floating-point arithmetic directly on the frontend while the user is playing in real-time. You just need a machine with the game logic, not the whole dapp backend, also the previous dapp state is not needed. I mentioned floating-point as an example because even in JavaScript or WASM floating-point arithmetic is non deterministic, but if you bring a small Cartesi Machine to your Web frontend then you can use floating-point fine.

1 Like
4

It´s a really cool idea that also opens up the possibility for scaling applications as it can offload a lot of computation from a Cartesi Rollup backend running inside a validator node. Using this feature the developer wouldn´t need to be super careful to implement deterministic code to match the expected results by the validator, the CM in the browser would ensure that automatically.

5

:exploding_head: That… is a really cool idea! Hadn’t thought of this possibility, it widens quite a bit the potential for this feature! Thanks!