feat(cli): add espresso-reader

[endersonmaia]

You can test this with:

pnpm build --filter @cartesi/cli
alias cartesi-dev=$PWD/apps/cli/dist/index.js
cartesi-dev create --branch=prerelease/sdk-12 --template=go my-go-dapp-v2 
cd my-go-dapp-v2
cartesi-dev build
cartesi-dev rollups start --services espresso,graphql
cartesi-dev rollups deploy

The rollups-espresso-reader endpoints should be available at:

• http://localhost:8080/espresso/reader/nonce
• http://localhost:8080/espresso/reader/submit

[changeset-bot]

🦋 Changeset detected

Latest commit: 79f7ac7

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@cartesi/cli	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

Coverage Report for ./apps/cli

Status	Category	Percentage	Covered / Total
🔵	Lines	27.46%	293 / 1067
🔵	Statements	27.41%	298 / 1087
🔵	Functions	27.27%	51 / 187
🔵	Branches	25.74%	121 / 470

File Coverage

No changed files found.

Generated in workflow #387 for commit 79f7ac7 by the Vitest Coverage Report Action

[miltonjonat]

Instructions fixing typos :)

pnpm build --filter @cartesi/cli
alias cartesi-dev=$PWD/apps/cli/bin/run.js
cartesi-dev create --branch=prerelease/sdk-12 --template=go my-go-dapp-v2 
cd my-go-dapp-v2
cartesi-dev build
cartesi-dev run --enable-espresso

[miltonjonat]

I couldn't access the espresso endpoint on http://localhost:8080/espresso, only directly on http://localhost:8770. Is that expected?

[endersonmaia]

I couldn't access the espresso endpoint on http://localhost:8080/espresso, only directly on http://localhost:8770. Is that expected?

It's missing some instructions. We expose 4 espresso API endpoints via names PATHs, they are:

• http://localhost:8080/espresso/sequencer
• http://localhost:8080/espresso/builder
• http://localhost:8080/espresso/prover
• http://localhost:8080/espresso/dev

So if you wanna call the /v0/status/block-height you should call

curl http://localhost:8080/espresso/sequencer/v0/status/block-height

[miltonjonat]

The rollups-espresso-reader does a weird thing: it publishes two endpoints /nonce and /submit on a port configurable with env ESPRESSO_SERVICE_ENDPOINT (default I think is 8080). We'd need to expose these too.

[endersonmaia]

What do you think about this format?

• /espresso/reader/nonce
• /espresso/reader/submit

If the developer interaction if gonna be focused on those endpoints, we could even hide everything from espresso-dev-node and only publish those at /espresso/submit and /espresso/nonce, also.

[endersonmaia]

@miltonjonat I sent a fixup where you can access those endpoints at:

• http://localhost:8080/espresso/reader/nonce
• http://localhost:8080/espresso/reader/submit

Please, let me know if it works!

[miltonjonat]

So, these endpoints are currently conveniences for the Espresso integration, and strictly speaking they could (or should?) be part of another component separate from the reader itself. So, no, I wouldn't use "reader" there.

Frankly, I think it's also quite odd to put it under "espresso" in this context, because that "espresso" there is meant to be the (local) Espresso Network, while these are endpoints on the Node itself.

Tbh, the idea here was also that the Node would provide /nonce and /submit functionalities as something more universal (i.e., to also be used when integrated with Avail, Celestia, etc). And that clients wouldn't even know which alt-DA was being used by the app/node.

TL;DR, I'd use http://localhost:8080/nonce and http://localhost:8080/submit directly; or we could come up with a nice namespace for convenience endpoints of this kind (maybe http://localhost:8080/tx/nonce?)

[tuler]

I understand there is no unified way to send a transaction. anvil expects ethereum transactions as specified by eth_sendTransaction, espresso expects a transaction object, avail has its own spec.

So having a single /nonce and /submit at the root of the service, regardless the configured DA, with various formats will be extremely confusing.

[miltonjonat]

So, one path what would be very adherent to the current architecture would be something like L2tx, leading to http://localhost:8080/L2tx/nonce and http://localhost:8080/L2tx/submit (I suggested tx above, but I admit that L2tx would be more precise)

[tuler]

How are you going to use a single format for DAs with different requirements?
I.e. how do you define the namespace in case of Espresso?

[miltonjonat]

In the current design, the client/user does not inform any DA-specific parameters in the payload it submits. Whatever is required to submit to the alt-DA configured for the application should be given by DA-specific parameters defined upon deployment of the app, and stored as on-chain app configuration. The Node will fetch that from the application contract (it's currently defined as an ABI encoded method+parameters), and thus know how to handle tx submission when /submit is called.

[miltonjonat]

Coming back to this from the discussions on #171, I'm now thinking that a path that would make sense would be http://localhost:8080/eip712/nonce and http://localhost:8080/eip712/submit

What do you think?

[tuler]

EIP-712 is a typed structured data hashing and signing standard. I don't think it should be the name of the service.

[miltonjonat]

I tried it out, had some issues, and couldn't run in the end.

1. ./apps/cli/bin/run.js is not being generated by pnpm build
2. If I go to that directory and run pnpm build, it generates output in the dist folder. It seems to work if I use alias cartesi-dev=$PWD/apps/cli/dist/index.js; using cartesi-dev build works
3. cartesi-dev run --enable-espresso fails, with message service "espresso_reader_migration" didn't complete successfully: exit 1. Full log (with verbose): cartesi-dev.run.log.zip

[endersonmaia]

I tried it out, had some issues, and couldn't run in the end.

1. ./apps/cli/bin/run.js is not being generated by pnpm build
2. If I go to that directory and run pnpm build, it generates output in the dist folder. It seems to work if I use alias cartesi-dev=$PWD/apps/cli/dist/index.js; using cartesi-dev build works
3. cartesi-dev run --enable-espresso fails, with message service "espresso_reader_migration" didn't complete successfully: exit 1. Full log (with verbose): cartesi-dev.run.log.zip

The failure was error: migration failed: type "ethereum_address" does not exist.

The migration code doesn't mention the creation of this ethereum_address type.

https://github.com/cartesi/rollups-espresso-reader/blob/v0.2.1-node-20250128/internal/repository/postgres/schema/migrations/000001_espresso_db.up.sql

[miltonjonat]

That's part of the Node migration, which has to be executed before the Espresso Reader's one.
https://github.com/cartesi/rollups-node//blob/feature/new-build-20250128/internal/repository/postgres/schema/migrations/000001_create_initial_schema.up.sql#L4

[endersonmaia]

That's part of the Node migration, which has to be executed before the Espresso Reader's one. https://github.com/cartesi/rollups-node//blob/feature/new-build-20250128/internal/repository/postgres/schema/migrations/000001_create_initial_schema.up.sql#L4

Sent a fixup for that. 0fb7ac6

I'll have to rebase this on top of feature/cli-run-v2, it has a lot of braking changes, then I'll provide a cleaner commit history so we can go back to testing this again.

[miltonjonat]

@endersonmaia cool new instructions! I like the --services espresso,graphql thing.
Unfortunately, it didn't run: migrations failed again. It seems that the database is dying for some reason, even when running without any extra services.

• Log with both espresso and graphql services: start-espresso-graphql.log.gz
• Log with only espresso service: start-espresso.log.gz
• Log without any extra service: start-no-services.log.gz

[tuler]

• Log without any extra service: start-no-services.log.gz

Strange that it is reporting a database url as postgres://postgres:password@localhost:5432/rollupsdb?sslmode=disable, with database name as rollupsdb. It should be postgres.

Did you change any of that?

[miltonjonat]

• Log without any extra service: start-no-services.log.gz

Strange that it is reporting a database url as postgres://postgres:password@localhost:5432/rollupsdb?sslmode=disable, with database name as rollupsdb. It should be postgres.

Did you change any of that?

I didn't change anything, but AFAIK in Node v2 the database is always called rollupsdb (e.g., https://github.com/cartesi/rollups-node/blob/feature/new-build/Makefile#L82)
Btw, which Node branch/tag are you guys using? The Espresso Reader is currently on https://github.com/cartesi/rollups-node/releases/tag/v2.0.0-dev-20250128

[tuler]

Btw, which Node branch/tag are you guys using?

We are testing locally with branch feature/new-build while we wait for a tag.

[tuler]

AFAIK in Node v2 the database is always called `rollupsdb

We define the env var

cli/apps/cli/src/compose/rollups/default.env

Line 35 in 8c2ba89

CARTESI_DATABASE_CONNECTION="postgres://postgres:password@database:5432/postgres?sslmode=disable"

[miltonjonat]

Right.. maybe it's not going through, or not being respected by the Node code..?

[endersonmaia]

rollups-node v2 changed the ENV config from CARTESI_POSTGRES_ENDPOINT to CARTESI_DATABASE_CONNECTION

I'm already using CARTESI_ENDPOINT_CONNECTION where @tuler pointed out in his last comment.

For espresso-reader, I'm using CARTESI_POSTGRES_ENDPOINT still.

[endersonmaia]

@miltonjonat my suggestion is that you go to the cartesi/rollups-node local repository at the feature/new-build branch and run make image.

Then you'll have a cartesi/rollups-node:devel available locally and your tests may run just fine.

Let me know if anything changes.

[tuler]

Time to rebase this one.