For chains that use sequential nonces, can the construction API be used to offline-sign multiple transactions in parallel?
I’m imagining a case where you have many transactions to sign (using the same account), so you request the metadata for the first one, but then would you have to wait until the first tx is signed and broadcast before requesting the metadata for the next tx? If the API had no knowledge that the first nonce metadata was used, then it would continue to return the same nonce until a tx is broadcast.
A solution I can think of to solve this problem, would be an offline endpoint which could accept some previous metadata response and return the next sequential metadata.
this is a case where you have additional knowledge about the chain you’re using, beyond what’s specified in the Rosetta API. specifically, you’re saying you already know what data to pass as the metadata to the /construction/payloads endpoint. and that may indeed be valid as you describe for a specific chain that you’re working with.
in the more general case where you don’t know what metadata is needed, then all that’s required by the Rosetta spec is for it to work when you go through the preprocess->metadata->payloads workflow.
maybe a few other things to consider: does the construction implementation need any metadata other than the nonce, and can you provide those as well without calling out to the metadata endpoint
Thanks for the reply. I’m not sure it matters if I know what should be provided to the
/construction/payloads endpoint, as the point of Rosetta is to provide a generic interface so lets assume there are some metadata which are unknown.
It seems to me that Construction API callers should not be creating/modifying the metadata themselves, from reading comments by @patrick.ogrady: (here and here)
The metadata returned by
/construction/metadata is treated as opaque by the caller so putting information there will likely not be inspected nor modified (but could be used by
Modifying the metadata would be chain-specific and a Rosetta anti-pattern.
It may be the case that the API does not support this use-case yet, and I think some consideration should be put towards supporting it because it restricts high-volume transaction construction.
Hi @shrimalmadhur, @patrick.ogrady, apologies for the mention but do you have any thoughts on the above?