Runtime and SDK images

[tuler]

📚 Context

The cartesi-machine and cartesi-rollups-node are moving to a distribution based on debian packages and brew or macports. In the future the CLI will also be able to move to that direction and use host dependencies and not rely so much on docker for its execution. This particular goal is tracked by issue #72

For now we maintain a cartesi/sdk docker image that contains every component needed to run local Cartesi development environment. Another reason for this image is to make sure the correct compatible versions are chosen for the system to work. That environment currently includes the following:

1. cartesi-machine
2. cartesi-rollups-node
3. cartesi-rollups-graphql
4. cartesi-rollups-espresso-reader
5. cartesi-rollups-contracts (dump + info)
6. genext2fs
7. crane
8. anvil
9. alto (ERC-4337 bundler)
10. mock-verifying-paymaster (ERC-4337 paymaster)
11. migrate (for database migrations)

The items from 1 to 4 above are the ones used in a production (testnet or mainnet) environment.
The items from 5 to 11 are only used by a local development environment.

I suggest we split the SDK image, which is already very bloated into 2 images, 1 for production runtime (which we will use in fly.io), and another for development (which can start from the production runtime).

✔️ Solution

Refactor the Dockerfile to have a stage for the production image and a stage for the sdk image.
Change the CI to produce both. They can follow the same version number, for simplicity.

One discussion, what should we call both images?
Some options:

Runtime	SDK
cartesi/rollups	cartesi/sdk
cartesi/rollups-node	cartesi/sdk
cartesi/rollups	cartesi/rollups-dev
cartesi/rollups-runtime	cartesi/sdk
cartesi/rollups-runtime	cartesi/rollups-sdk

Consider also on the back of your mind what will happen when we integrate coprocessor.

📈 Subtasks

• refactor Dockerfile
• change CI

🎯 Definition of Done

• Two different images published to Docker Hub

[tuler]

My vote goes to

cartesi/rollups
cartesi/rollups-sdk (FROM cartesi/rollups)
cartesi/rollups-database (FROM postgres)

[fabiooshiro]

@tuler I’m not sure if this will help, but on the nonodo side, we just download the binary on the fly as needed
Eg. Anvil and paio decoder

[fabiooshiro]

even the compiled version of nonodo, the JS detects the architecture and downloads the correct binary, right @sandhilt ?

[tuler]

We use Docker, which manages the download part for us, in the correct architecture, by using pull.

Not using Docker is another topic. And when we get there we will use proper package managers for host binaries, like apt-get, homebrew or macports. npm packages are not designed to be wrappers for native binaries (other than the case of native code node bindings).

[endersonmaia]

For now, the following names were used:

• cartesi/sdk
• cartesi/rollups-runtime
• cartesi/rollups-database