Sending EIP-712 Transactions

[fabiooshiro]

Hey everyone,

We’re considering how to structure a command for sending EIP-712 transactions and would love some input.

The process includes:

1. Retrieving the nonce (/nonce endpoint).
2. Building the EIP-712 message.
3. Signing the transaction.
4. Submitting the transaction (/submit endpoint).

This applies to both Espresso and Paio + Avail, which follow the same API structure.

Possible Approaches:

• cartesi send A general send command with an option to specify EIP-712 format.
• cartesi <context> send A subcommand that provides additional context before sending, such as cartesi l2 send.
• Other suggestions?

[sandhilt]

I like this flexibility; EIP-712 could be a great suggestion.

[tuler]

Signing a EIP-712 structure, and sending a transaction are two independent actions.
It doesn't mean a send subcommand can exist for sending a different transaction, but the destination is more relevant for the subcommand context than the EIP-712 building and signing process.

[tuler]

Just as an analogy, take a look at cast wallet sign.
It's under the wallet command. Not a send operation.

[fabiooshiro]

In our case, we are considering executing the full process:

1. Retrieve the nonce.
2. Build the EIP-712 message.
3. Sign the transaction.
4. Send the transaction to the /submit endpoint.

The nonce is important for us...

[tuler]

Are you talking about espresso sequencer? Please provide context in the original post.
What endpoint?

[fabiooshiro]

/nonce and /submit

Yes, for Espresso and Paio + Avail

[tuler]

/nonce and /submit

Yes, for Espresso and Paio + Avail

Does espresso and paio + avail follow the exact same /nonce and /submit API?

[fabiooshiro]

Yes the same API

[fabiooshiro]

Probably something like cartesi l2 send is the best option

[fabiooshiro]

Something like aws cli
aws <service> <commands>
aws s3 ls

[fabiooshiro]

Today we have:

cartesi send
? Select send sub-command
  Send DApp address input to the application.
  Send ERC-20 deposit to the application.
  Send ERC-721 deposit to the application.
  Send ether deposit to the application.
❯ Send generic input to the application.
Sends generics inputs to the application, optionally in interactive mode.

Could be:

cartesi send
? Select send sub-command
  Send DApp address input to the application.
  Send ERC-20 deposit to the application.
  Send ERC-721 deposit to the application.
  Send ether deposit to the application.
  Send generic input to the application.
❯ Send L2 input to the application.

[tuler]

Currently every type of input is a subcommand of cartesi send.
The cartesi send command itself is another command that interactively allows the selection of one of the subcommands.

Consider also the future adoption of cartesi coprocessor, and a possible impact, with two possibilities:

• move all rollups related inputs to cartesi rollups send [subcommand].
• or simply the addition of a new send subcommand for coprocessor.

Even though coprocessor might be a different case, because the user develops a custom smart contract, which then sends an input to the coprocessor task issuer. We don't want to replicate what cast already provides, and we probably better off just driving the user to use cast.

Coming back to "L2" inputs, it's not very clear to me if sending a transaction to espresso or paio is equivalent to the current structure of the send subcommands. Because it looks to me more like a destination, not an input type or structure.

It looks more to me like sending a generic input, and then choosing the destination, which is either the InputBox L1 contract, or a sequencer.

[fabiooshiro]

It looks more to me like sending a generic input, and then choosing the destination, which is either the InputBox L1 contract, or a sequencer.

I agree, how about:

cartesi send
? Select send sub-command
  Send DApp address input to the application.
  Send ERC-20 deposit to the application.
  Send ERC-721 deposit to the application.
  Send ether deposit to the application.
  Send generic L1 input to the application.
❯ Send generic L2 input to the application.

[tuler]

How about:

cartesi send generic [--sequencer evm|espresso]

[fabiooshiro]

Nice!

[fabiooshiro]

For the client side, it does not matter whether it is Espresso or Paio, as the /submit endpoint receives the same payload.

How about:
cartesi send generic [--sequencer evm|l2]

[fabiooshiro]

I wrote a draft following the --sequencer evm|paio|espresso.
I have a question: how can I get the http://<host>:<port>?
https://github.com/cartesi/cli/pull/176/files#diff-b11d41edf88ae12622645be8879cc024f02289065340bbd8b9db1cbf83b568c3R10

[tuler]

You would have to ask for the address to send

[fabiooshiro]

The command line already asks for the address...
Im reusing the same code structure

[tuler]

Well, in case of sequencer !== evm, the address should not default to anvil, as you are not sending to anvil, but to the sequencer. Not there is also a chain-id parameter.

[miltonjonat]

Hi folks. I think there is some confusion here.

The user is not sending the input to a specific sequencer. He doesn't need to care if this will go to Espresso or Paio, only that the input will be submitted to an L2 endpoint that may act as a gateway to forward it to wherever is appropriate (usually some sequencer like Espresso or Paio).
So it's more like the old send is "tx submitted to the base chain (L1)" (most rollups call this "forced inclusion"), while the new send option is "tx submitted to the L2 network" (this is so common/trivial for most rollups that I don't know if they have a name for this, I call it "L2 tx").
Moreover, in our particular implementation, the L1 tx uses Ethereum JSON-RPC, while the L2 tx's currently use an EIP-712 signed message.

I'd use one of these options:

1. cartesi send generic [--type L1|L2]
2. cartesi send generic [--format evm|eip712] (or [--format jsonrpc|eip712])

For (1), I admit I'm not very fond of "type", which is too abstract. Maybe something like "layer", "network", "destination" or something like that could work better. But atm I think I still prefer "type" over those :P

[miltonjonat]

As a curiosity, which may be related: is there a cartesi send command that uses account abstraction? Does that make sense? (sorry for my ignorance)
It just crossed my mind that maybe that would be a 3rd format? i.e., if we use the --format option suggested above, maybe we could have [--format evm|eip712|erc4337]?

[miltonjonat]

Thinking more about this, I'm leaning more towards --format. It is in theory possible to implement a full Ethereum-compatible JSON-RPC layer on the Node, so that people could use regular Ethereum clients to send tx's directly to the L2 rollup. If that ever happens, then you would be able to send an L2 tx using --format evm and pointing to the Node's RPC endpoint, instead of the base layer's RPC endpoint.

[tuler]

There is no send for ERC-4337 operations. From the application backend perspective there is no difference of a generic input that comes from ERC-4337 (other than the fact that the sender is a smart account).

I think the utility of the cartesi send commands are overrated. They are just quick shortcuts that could otherwise be executed directly through cast, or cast + curl. And in general developers should move ASAP to their application frontends.

[tuler]

I haven't seen the term "format" in this context, but I have seen the term "type", as in transaction types (for ethereum).

But ERC-4337 and these paio thing are not transactions. Sometimes they are called meta-transactions, and ERC-4337 call them UserOps.