Deploy of espresso applications

[endersonmaia]

📚 Context

By default cartesi-rollups-cli app deploy will deploy an application with InputBox as Data Availability (DA), newer alpha versions of cartesi-rollups-cli supports deploying espresso applications, using InputBoxEspresso as DA.

cartesi rollups deploy should add this support so that developer can work with local espresso applications.

✔️ Solution

Expose a set of arguments targeting espresso applications.

• --espresso-block
• --espresso-namespace-id

📈 Subtasks

• implemente --espresso-* argumentys

🎯 Definition of Done

• cartesi rollups deploy command has `--espresso-*`` argument and its possible to deploy an espresso application

[tuler]

I don't think the cartesi-rollups-cli --data-availability option should be exposed as is to the cartesi rollups deploy command.
The Cartesi CLI operates at a different level, and should be more explicit about the DA options during deployment.
It then need to encode the DA information to be passed to the cartesi-rollups-cli correctly.

There are two types of data availability currently supported: InputBox and InputBoxAndEspresso.

In case of InputBox no extra argument for cartesi rollups deploy is necessary, as the InputBox address is the only required information.

In case of InputBoxAndEspresso we need to request the user the fromBlock and namespaceId.

/// @param fromBlock Height of first Espresso block to consider
/// @param namespaceId The Espresso namespace ID

These will probably be new options of cartesi rollups deploy: --espresso-block and --espresso-namespace-id

[endersonmaia]

These will probably be new options of cartesi rollups deploy: --espresso-block and --espresso-namespace-id

Do you think we should provide something like a --data-availability [inputbox, espresso, ...] (default: inputbox), or when any --espresso-* is provided we automatically define the EspressoInputBox under the hood and make both (--espresso-block and --espresso-namespace-id) required.

[tuler]

I think the --espresso-* options are enough to specify that the deployment is a espresso one.

[lynoferraz]

The espresso deployment could be simplified even more. Both --espresso-block and --espresso-namespace-id could be optional, with a default value for --espresso-namespace-id and for --espresso-block it can be fetched to get the current block height.
It that way it would need a new parameter to choose a espresso deployment

[fabiooshiro]

Default value for --espresso-namespace-id is "55555"

[tuler]

Shouldn’t each dapp have its own namespace id? I thought sharing the same id with multiple applications was a temporary hack. Otherwise the reader will read inputs for all applications using espresso even though it may have only a single application machine.

[fabiooshiro]

IMO It's totally fine for development purposes, just like using the default app address.

[miltonjonat]

IMO It's totally fine for development purposes, just like using the default app address.

Isn't the CLI deploy command what's commonly used for testnet and mainnet deployment?

[miltonjonat]

Shouldn’t each dapp have its own namespace id? I thought sharing the same id with multiple applications was a temporary hack. Otherwise the reader will read inputs for all applications using espresso even though it may have only a single application machine.

I just wouldn't call it a hack: it's more of a fallback if namespace collision occurs. And since Espresso uses a 32-bit id, it's hard to guarantee it won't occur.

[miltonjonat]

I have to admit that it is possible that at some point we'd want to have a single namespace for a bunch of Cartesi apps (e.g., if we have a Paio block builder getting sequential rights for a bunch of Cartesi apps). But, at the current stage, I think it makes more sense to treat each app as an independent namespace - exactly to avoid having all Cartesi Nodes downloading input data for all Cartesi Espresso apps (and even stuffing them inside the CM in case we need to prove stuff).

TL;DR: I don't think we should set a 55555 default namespace value for the CLI. Which doesn't mean we can't have a default namespace value for local development (cartesi rollups start) - but that's another command right?