CartesiScan Third Iteration

[brunomenezes]

📄 Context

The node-rollups v2 introduces the json-rpc endpoint and initiates the deprecation of the graphQL API. It could be a matter of simply replacing the GraphQL parts we implemented with the new json-rpc, but that would not be a significant future-proof change. Mainly with the addition of DAs (e.g., Espresso Sequencer), it became clear to me last year (2024) that it would create holes, and the L1 would not have enough information, as some pieces of data would go to another place, even though deposits would still pass through the InputBox.

This new iteration requires a clean mindset without comparing or trying to adapt how we do things today in terms of architecture, i.e. Indexing L1 pieces together with a UI offering off-chain reads. We would be more integrated and trusting in the interface provided by the Cartesi Rollups Node API.

At a high-level view, in terms of reads, we would solely consume data from the node to provide information about applications, inputs, outputs, etc. (i.e., we would not have an indexer). That means the entry point is the user providing the URL to that API, which allows the user to explore what is available in the node they have or trust. Providing all supported networks in one place.

For the writing (Send Transaction), minor changes would be required, as this is the usual communication with the blockchain directly.

I was inspecting the OpenRPC Playground pointing to node-rollups (v2.0.0-alpha.6) and there are a few information pieces not available.

Following that line, I need to exchange information with whatever node the user decides to plug before even start operations.

Here is the information I would request:

1. What is the chain ID the node is configured with?
2. What is the rollups-contracts version the node is using?

Could we have an RPC method to exchange information about the node? e.g. cartesi_getRollupNodeConfig (whatever the name is, as far as I can have the information above).

For the point 1. I noticed that cartesi_getInput or cartesi_listInputs contains the chain_id in the decoded_data, but this assumes there is already at least one input; it may not have, and it is not the complete picture for our case.

This information gives me the power to vet the node at the very start, with enough information and solid ground to decide whether it is supported or not.

For a visual, the diagram below illustrates our current position and my desired destination.

Details

 

High-level Diagram (Click to Expand)

[brunomenezes]

@tuler, I want to start this discussion here also for recording, as the node is still releasing alphas. I think it is the best moment for requests. I am not able to mention Victor Fusco here, so I will send that link to him.

UPDATE: Also upgrade the openRPC playground link to v2.0.0-alpha.6.

[vfusco]

@brunomenezes I don't think it would be a good approach to share the config on the API for many reasons (Object interface stability, multiple configurations, may contain sensitive data etc). But I guess we could add cartesi_getChainId and cartesi_getNodeVersion.

[brunomenezes]

@brunomenezes I don't think it would be a good approach to share the config on the API for many reasons (Object interface stability, multiple configurations, may contain sensitive data etc). But I guess we could add cartesi_getChainId and cartesi_getNodeVersion.

Oh! When I said config (a convoluted word), I meant the bare minimum to vet and work with a node. These methods would work, as I can batch call with ID to handle the response.

I'm guessing the cartesi_getChainId would return a numerical value (e.g. 10, 1, 11155111, 13370, etc)

What would be the return for cartesi_getNodeVersion?

@vfusco, when you say multiple configurations, what do you mean by that? I know the node can run multiple applications, but in terms of a chain (e.g Mainnet), the node only runs looking into that network, meaning all the applications are also from that same network, right?

[tuler]

I don't think it would be a good approach to share the config on the API, …, may contain sensitive data etc)

I think it makes sense, basic information without any sensitive data.

OP Stack has such API.

[tuler]

One thing that I think will be necessary is a sort parameter for the collections. Inputs and epochs for example will typically be listed in descending order.

[brunomenezes]

One thing that I think will be necessary is a sort parameter for the collections. Inputs and epochs for example will typically be listed in descending order.

Good catch!
As a client, we usually want to always be displaying the latest and navigate to past events as necessary. So, as an example, we are currently sorting by TIMESTAMP_DESC in graphQL lingo. I notice that most objects returned by the API methods have a created_at that could be a good candidate for the sorting key. The default being descending rather than ascending would be ideal.

[tuler]

created_at that could be a good candidate for the sorting key

Default should be the by index ascending, and control with some sort parameter.

[brunomenezes]

created_at that could be a good candidate for the sorting key

Default should be the by index ascending, and control with some sort parameter.

Humm index? I see that the e.g. cartesi_listInputs application parameter is required. So I can't ask give me the latest 10 inputs independent of App address. I see that the only method I can ask that broader question is to the cartesi_listApplications, the other pieces are filtered by the application

[vfusco]

@brunomenezes , cartesi_getChainId and cartesi_getNodeVersion are already on next/2.0. Sort and positional arguments will come on later PRs.