Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sending EIP-712 Transactions #171

Open
fabiooshiro opened this issue Mar 6, 2025 · 25 comments
Open

Sending EIP-712 Transactions #171

fabiooshiro opened this issue Mar 6, 2025 · 25 comments
Labels

Comments

@fabiooshiro
Copy link

fabiooshiro commented Mar 6, 2025

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
Copy link

sandhilt commented Mar 6, 2025

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

@tuler
Copy link
Member

tuler commented Mar 6, 2025

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
Copy link
Member

tuler commented Mar 6, 2025

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

@fabiooshiro
Copy link
Author

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
Copy link
Member

tuler commented Mar 6, 2025

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

@fabiooshiro
Copy link
Author

/nonce and /submit

Yes, for Espresso and Paio + Avail

@tuler
Copy link
Member

tuler commented Mar 6, 2025

/nonce and /submit

Yes, for Espresso and Paio + Avail

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

@fabiooshiro
Copy link
Author

Yes the same API

@fabiooshiro
Copy link
Author

Probably something like cartesi l2 send is the best option

@fabiooshiro
Copy link
Author

fabiooshiro commented Mar 11, 2025

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

@fabiooshiro
Copy link
Author

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
Copy link
Member

tuler commented Mar 11, 2025

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
Copy link
Author

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
Copy link
Member

tuler commented Mar 11, 2025

How about:

cartesi send generic [--sequencer evm|espresso]

@fabiooshiro
Copy link
Author

Nice!

@fabiooshiro
Copy link
Author

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
Copy link
Author

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
Copy link
Member

tuler commented Mar 13, 2025

You would have to ask for the address to send

@fabiooshiro
Copy link
Author

fabiooshiro commented Mar 13, 2025

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

@tuler
Copy link
Member

tuler commented Mar 13, 2025

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
Copy link

miltonjonat commented Mar 13, 2025

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
Copy link

miltonjonat commented Mar 13, 2025

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
Copy link

miltonjonat commented Mar 13, 2025

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
Copy link
Member

tuler commented Mar 13, 2025

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
Copy link
Member

tuler commented Mar 13, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants