Feat: Rollups v2 support

[brunomenezes]

Summary

Code changes to support both rollup contracts v1 and v2 (currently available only for devnet and Sepolia).

Changes:

• Added new property to the Application model to be queryable based on rollups version without the need to check the factory address (Depending on the query, it means no join).
• Added new handlers for ApplicationCreated and InputAdded events.
• The existing handler for OwnershipTransferred was updated to deal with both v1 and v2 events instead of adding a new one, as the topic hash for both contracts is the same. After looking at the generated code from ABI, I believe both handlers would be called sequentially, deeming a new handler unnecessary. PS: I assume it will be picked as the topic matches. There are at least three apps created on Sepolia, but none emitted the event.
• The config function was updated, adding the addresses for v2, including v2 information when it is supported in the network (currently only Devnet and Sepolia).
• Updated logic for preloading application address to include v2 factory.
• Preloaded content was also bumped for Mainnet and Sepolia.

Events

// CartesiApplication
OwnershipTransferred: event("0x8be0079c531659141344cd1fd0a4f28419497f9722a3daafe3b4186f6b6457e0", "OwnershipTransferred(address,address)", {"previousOwner": indexed(p.address), "newOwner": indexed(p.address)}),

// CartesiDApp
OwnershipTransferred: event("0x8be0079c531659141344cd1fd0a4f28419497f9722a3daafe3b4186f6b6457e0", "OwnershipTransferred(address,address)", {"previousOwner": indexed(p.address), "newOwner": indexed(p.address)}),

[brunomenezes]

Hey @tuler, could you confirm my bullet point 3 about the OwnershipTransferred? Because as for this handler is always about the topic comparison I believe having two handlers even though using the events generated by different ABIs, it would still have one Log go through the v1 handler then the new-handler doing unnecessary operations.

[endersonmaia]

When testing this at cartesi/cli#172 In get the following error:

squid_processor-1  | node:internal/modules/cjs/loader:1031
squid_processor-1  |   throw err;
squid_processor-1  |   ^
squid_processor-1  |
squid_processor-1  | Error: Cannot find module '@subsquid/evm-codec'
squid_processor-1  | Require stack:
squid_processor-1  | - /squid/lib/abi/CartesiDAppFactory.js
squid_processor-1  | - /squid/lib/handlers/ApplicationCreated.js
squid_processor-1  | - /squid/lib/handlers/EventHandler.js
squid_processor-1  | - /squid/lib/main.js
squid_processor-1  |     at Function.Module._resolveFilename (node:internal/modules/cjs/loader:1028:15)
squid_processor-1  |     at Function.Module._load (node:internal/modules/cjs/loader:873:27)
squid_processor-1  |     at Module.require (node:internal/modules/cjs/loader:1100:19)
squid_processor-1  |     at require (node:internal/modules/cjs/helpers:119:18)
squid_processor-1  |     at Object.<anonymous> (/squid/lib/abi/CartesiDAppFactory.js:27:24)
squid_processor-1  |     at Module._compile (node:internal/modules/cjs/loader:1198:14)
squid_processor-1  |     at Object.Module._extensions..js (node:internal/modules/cjs/loader:1252:10)
squid_processor-1  |     at Module.load (node:internal/modules/cjs/loader:1076:32)
squid_processor-1  |     at Function.Module._load (node:internal/modules/cjs/loader:911:12)
squid_processor-1  |     at Module.require (node:internal/modules/cjs/loader:1100:19) {
squid_processor-1  |   code: 'MODULE_NOT_FOUND',
squid_processor-1  |   requireStack: [
squid_processor-1  |     '/squid/lib/abi/CartesiDAppFactory.js',
squid_processor-1  |     '/squid/lib/handlers/ApplicationCreated.js',
squid_processor-1  |     '/squid/lib/handlers/EventHandler.js',
squid_processor-1  |     '/squid/lib/main.js'
squid_processor-1  |   ]
squid_processor-1  | }
squid_processor-1 exited with code 1

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub ↗.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	@​cartesi/​rollups@​2.0.0-rc.17

View full report ↗

[brunomenezes]

When testing this at cartesi/cli#172 In get the following error:

squid_processor-1  | node:internal/modules/cjs/loader:1031
squid_processor-1  |   throw err;
squid_processor-1  |   ^
squid_processor-1  |
squid_processor-1  | Error: Cannot find module '@subsquid/evm-codec'
squid_processor-1  |     at Module.require (node:internal/modules/cjs/loader:1100:19) {
squid_processor-1  |   code: 'MODULE_NOT_FOUND',
squid_processor-1  |   requireStack: [
squid_processor-1  |     '/squid/lib/abi/CartesiDAppFactory.js',
squid_processor-1  |     '/squid/lib/handlers/ApplicationCreated.js',
squid_processor-1  |     '/squid/lib/handlers/EventHandler.js',
squid_processor-1  |     '/squid/lib/main.js'
squid_processor-1  |   ]
squid_processor-1  | }
squid_processor-1 exited with code 1

A new package was generated. Something changed from previous builds when using the npm ci --production, it is purging the evm-codec. So I am explicitly adding not just evm-codec but also evm-abi, which is also very likely to have the same problem.

@endersonmaia you can pull the latest image.

[endersonmaia]

@brunomenezes sorry for the late response, U just executed with latest image, and I see no error in the logs

But after deploying an application and sending some inputs, I still can't see them in the WebUI, but I think it's a work in progress, right ?

[brunomenezes]

@brunomenezes sorry for the late response, U just executed with latest image, and I see no error in the logs

But after deploying an application and sending some inputs, I still can't see them in the WebUI, but I think it's a work in progress, right ?

Hey @endersonmaia, if you are seeing the events been indexed in the logs (apps created, input added and etc) by using the latest ui rollups-v2 branch you should see the content in the rollups-explorer-ui. I use the comet-app as my test dapp after migrating to node-v2 + espresso.

What do you see in the API and UI app logs?

[endersonmaia]

I think I found the problem, squid_processor is pointing to 31337 chainId when it should be pointing to 13370.

Even defining the envs like this, it's not working.

            CHAIN_ID: ${CHAIN_ID:-13370}
            RPC_URL_13370: ${RPC_URL:-http://anvil:8545}
            BLOCK_CONFIRMATIONS_13370: 0

What am I missing?

I couldn't find any docs about this environment variables, I'd be glad if you could point me where I can find this.

[endersonmaia]

🤦 In was looking the wrong repository for this environment variables, I just found it

[endersonmaia]

squid_processor-1  | {"level":3,"time":1744293193205,"ns":"sqd:startup","msg":"Could not find valid chains defined on CHAIN_IDS env var, defaulting to 313
37"}
squid_processor-1  | {"level":2,"time":1744293193208,"ns":"sqd:startup","msg":"Starting processor for chain 31337"}

I think the chain id 13370 is not supported yet, right?

CHAIN_IDS="13370"
RPC_URL_13370=http://anvil:8545
BLOCK_CONFIRMATIONS_13370=0

[tuler]

I think the chain id 13370 is not supported yet, right?

Have you tried to pass these variables to the docker container? It should work.

CHAIN_ID 13370
RPC_ENDPOINT http://anvil:8545/

ps: endpoint above is internal to our docker compose network

[endersonmaia]

CHAIN_ID 13370
RPC_ENDPOINT http://anvil:8545/

It doesn't work, I still get the following error message:

{"level":3,"time":1744303461570,"ns":"sqd:startup","msg":"Could not find valid chains defined on CHAIN_IDS env var, defaulting to 31337"}

I used CHAIN_ID, CHAIN_IDS but it doesn't work.

[brunomenezes]

🤦 In was looking the wrong repository for this environment variables, I just found it

Glad you found it.

Have you tried to pass these variables to the docker container? It should work.

CHAIN_ID 13370
RPC_ENDPOINT http://anvil:8545/

ps: endpoint above is internal to our docker compose network

What container would that configuration go to the rollups-explorer-api? That will not work. We only work with what is described in the README in this repository. The CHAIN_IDS are to set the configuration. What could be done not sure if will work is

CHAIN_IDS="31337"
RPC_URL_31337="http://anvil:8545"

I mentioned about that 13370 not being supported in your PR/cli#172.

I have a few questions:

• Why 13370 rather than 31337?
• Is it still Anvil or something else?
• Which cartesi/rollups version are you guys using/being-affected-by? Currently, this branch uses @cartesi/rollups@2.0.0-rc.10. I am not sure if any contract changed (that development was "done" in December)

cc: @endersonmaia , @tuler

[endersonmaia]

Since rollups-contracts-2.0.0-rc.17 started using canon and its chainid is 13370

[brunomenezes]

@endersonmaia,
I added support for the Cannon(13370) configuration for both UI and API. So refresh the built images below

ghcr.io/cartesi/rollups-explore:pr-269
ghcr.io/cartesi/rollups-explorer-api:pr-52

[endersonmaia]

I updated the images, now I can see logs stating it's connected to the right chainId but still can't get the aplications being indexed nor inputs.

squid_processor-1  | {"level":2,"time":1744393767883,"ns":"sqd:commands","msg":"PROCESS:PROD"}
squid_processor-1  | {"level":2,"time":1744393771243,"ns":"sqd:startup","msg":"Starting processor for chain 13370"}
squid_processor-1  | {"level":2,"time":1744393771576,"ns":"sqd:processor","msg":"processing blocks from 22"}
squid_processor-1  | {"level":2,"time":1744393771577,"ns":"sqd:processor","msg":"using chain RPC data source"}
squid_processor-1  | {"level":2,"time":1744393771823,"ns":"sqd:processor","msg":"prometheus metrics are served at port 3000"}

[tuler]

Starting block is set to 22. I think it can be set to 1. Worth testing.

[endersonmaia]

defined the GENSIS_BLOCK_13370=1, it logged it started from block 1 but behavior is the same, still without application nor inputs.

squid_processor-1  | {"level":2,"time":1744395402196,"ns":"sqd:commands","msg":"PROCESS:PROD"}
squid_processor-1  | {"level":2,"time":1744395405527,"ns":"sqd:startup","msg":"Starting processor for chain 13370"}
squid_processor-1  | {"level":2,"time":1744395405901,"ns":"sqd:processor","msg":"processing blocks from 1"}

[brunomenezes]

defined the GENSIS_BLOCK_13370=1, it logged it started from block 1 but behavior is the same, still without application nor inputs.

squid_processor-1  | {"level":2,"time":1744395402196,"ns":"sqd:commands","msg":"PROCESS:PROD"}
squid_processor-1  | {"level":2,"time":1744395405527,"ns":"sqd:startup","msg":"Starting processor for chain 13370"}
squid_processor-1  | {"level":2,"time":1744395405901,"ns":"sqd:processor","msg":"processing blocks from 1"}

Could you confirm the ApplicationFactory e o InputBox address ?

The addresses used in this branch were extracted from @cartesi/rollups@2.0.0-rc.10 export/abi/sepolia.json as usually the address are the same through out deployments.

ApplicationFactory: 0x1d4CfBD2622d802A07CeB4C3401Bbb455c9dbdC3
InputBox: 0x593E5BCf894D6829Dd26D0810DA7F064406aebB6

@tuler, I checked out the latest rc.17 on npm and it is just a /out folder without information about the deployment address. So, I did not upgrade here. Any guidance as the deployment information changed would be very much appreciated if that is the case moving forward.

[tuler]

@tuler, I checked out the latest rc.17 on npm and it is just a /out folder without information about the deployment address.

rc.17 use cannon for deployment.
https://usecannon.com/packages/cartesi-rollups/2.0.0-rc.17/13370-main

To retrieve information you need to use cannon and execute the commands explained in the page above.

cannon inspect cartesi-rollups:2.0.0-rc.17 --write-deployments ./deployment

Most likely that will be part of your project build pipeline. Install @usecannon/cli and a dev dependency.

[endersonmaia]

Now it's working. :)

[brunomenezes]

Now it's working. :)

@endersonmaia also refresh the UI docker image. It was updated yesterday, now it included the new v2 contract addresses. important when sending a transaction e.g. InputBox::addInput

ghcr.io/cartesi/rollups-explore:pr-269