Rollups host mode or alternatives

Technical Vision Forum
1

Context

In the current landscape, multiple core units maintain the development tools DApp developers use.
One of those tools is the host mode in the Rollups node. This mode allows the DApp developer to run their DApp directly on their machine instead of using the Cartesi machine. The host mode is the entry point for many DApp developers as a way to avoid dealing with RISCV compilation. This mode also facilitates development because it shortens the edit-compile-execute loop and allows the usage of debuggers.

Problem

The host mode doesn’t fit in the new architecture of the rollups node. So, it will be deprecated soon. Regardless of the new solution, someone should be working on replacing it if we believe it is a problem worth solving.

2

Milton propose Nonodo, so this conversation is unrolling there I presume…

3

Nonodo is here. But I do think we could use this thread to propose alternatives or link to other alternative propositions.

4

Running the application code on the host is very welcome.

There are a lot of ways to do that. The following illustrates the dev workflow I suggest:

  1. wrap the application code around a test case. Or if the developer doesn’t want to or doesn’t know how to use a test framework write a main program that calls application code.

  2. write frontend components that does not involve remote requests.

  3. write local mocks. Write a graphql mock for the frontend (using existing graphql tools for that). Inject inputs in the Cartesi machine using the CLI.

  4. only then, write a new dev specific node.

1 Like
5

Hi everyone, maybe not a replacement but here goes a suggestion for a complementary tool

Introduction to Cartesi through interaction with existing dApp: Cartesi Playground

Cartesi playground is a solution that would serve as an interactive platform aiming to teach devs how each of the important features of the Cartesi Rollups Framework works. Ideally it would be deployed on a testnet like Sepolia for ease of use and so that the user doesn’t even need any setup on it’s personal computer.

The dApp would present itself to the user as a web interface with a mix of interactive actions through simple buttons and docs. An idea could be that the buttons through which the user interacts have the names of the functions themselves. This dApp could have different chapters for different depths of understanding.

The first interaction for example could be as simple as calls for the advance and inspect methods so the user can test inputs and outputs from the hello world or echo functions dapps. Along with the answers it is shown to the user what function was run in the backend and exactly what is being created on the request body and the flow of the transactions. This way the user will understand how to prepare its inputs. Same for inspect calls, explaining what it did, what was the output it generated and how it arrived as a response for them.

We would need chapters for other features as well explaining them, such as messaging/bridging.

The idea behind that is the user will be able to understand how to interact with a dApp and even be able to integrate it to their own dApp just for testing and having a solid understanding through experience how everything works.

We could make it more or less gamified, like https://cryptozombies.io/ or even take inspiration from Swift Playgrounds - Apple Developer

There are a lot of possibilities there. Even the user sending his own code to the dApp to test some simple function would be an interesting way to interact that would take down the first barrier of “How do I code for this?”.

4 Likes
6

I like this a lot, although it is true that it is a complementary thing, as you said

7

Its a very good complementary tool, Joao! Btw do you think that could be used composed with Nonodo? A complete playground

Key here is a workflow on concepts that ends with the user facing its first full small test dApp enjoying the convenience provided by Sunodo

8

I don’t see why not. They are technically complementary - even if both, in their own way, help newcomers to first approach how things work and experiment

2 Likes
9

This is really a cool idea, but I think it should be built step by step in different tools packaged together with good tutorials/documentation.

For example, if nonodo solves 90% of the pain, then we can think whats the next missing tool and do it. If we think of composable tools instead of a monolithic playground we can minimize the work needed to help developers as opposed to think about a integrated solution from the get go.

But I agree that the end goal is a playground where its easy for developers to experiment with minimal startup cost.

1 Like
10

I like this idea, what better way to get started than a playground?
We need to come up with a good implementation plan to do this the right way.

1 Like
11

I agree with Pedro´s approach to shorter sprints delivering modules that can be already used, tested with feedback to not only guide further development but also improve the module itself. Moreover, I think the best way of creating such tools is with the first “customer” in mind. Max´s group is doubling down on games so why not create this tool thinking and oriented to game-builders? @joao-garcia @PayalPatel @carlofragni @milton-cartesi

1 Like
12

Here at calindra, we developed the Ame super app platform. It handles the compilation of the micro-frontend (we call it “mini-apps” ) directly on the server. To accomplish this, we synchronize the local developer files with the server side, facilitating efficient editing. As developers make changes to their local files, we sync and compile. I believe this approach could be an excellent solution for addressing our current challenge.

To synchronize local files with the server, we use an http post. In “dev mode” we could enable an endpoint to handle incoming file updates.

1 Like
13

I personally do not think we should limit such tools, or gear this towards a specific type project. Seeing we aim the ecosystem to flourish with a range of use cases even outside the gaming domain this can be a generic tool for everyone regardless of the project type.

I believe the concept of playground would serve to be a easy way to test things and be guided along the way. I do like Pedro’s approach to this, as this would help us understand any gaps and fill those gaps with some complementary tools.

14

Thanks for sharing this @fabio.oshiro this sounds interesting. Aside from the technical elements involved for this, how do you see this fitting with nonodo, or would be this independent? I mention this because nonodo is one of the host mode alternatives being discussed.

15

I also dont think we should limit, but having a starting point is always a very good way to have a clear milestone to achieve. For me having an initial vertical in mind serves for this purpose, thoughts?

16

I totally agree that gaming is a prime vertical for Cartesi DApps. That being said, maybe the first killer Cartesi DApp comes in the gaming vertical, but maybe it doesn’t.

If the initial goal of the playground is to teach devs how to use each of the important features of the Cartesi Rollups framework, wouldn’t it make sense to build a first core iteration that is use-case agnostic?

I’m way out of my league on this from a technical standpoint, but would it be possible to create a core playground that is use-case agnostic, and to then iterate and add customizations that might further aid devs who are seeking to build in specific verticals?

To me (layperson alert), one of the keys for any broadly applicable convenience tool should be that it is inviting to all DApp developers. If the tool in its core iteration is oriented solely to game builders, I fear we’d be unnecessarily limiting its attractiveness and impact to the broader DApp builder community.

2 Likes
17

I agree. I’d rather have a full implementation of such playground going through every feature we can in the most agnostic manner possible first. Everything else is a plus.

3 Likes