HTTP transaction submit API

[HinsonSIDAN]

Description

Currently websocket is the only way to submit transaction to hydra node, while it works, it creates software overhead to client & toolings (e.g. sdks). Suggest to create a http tx submission API

Suggested solution

Suggested to create an API for http transaction submit with same behaviour as any L1 provider tx submission (like blockforst). Hydra specific suggestion:

• Return a txHash as response if the transaction is TxValid and accepted to the mempool
• Not exactly have to wait for snapshot confirm

Alternative

It is also possible to:

• Return a txHash as response if the transaction is TxValid + SnapshotConfirmed
• While it might not be commonplace for L1 provider as it takes long time to be included in blocks in general, it has much faster response on confirming in snapshot of hydra technically, so make this alternative possible

If that's evaluated to be also a good idea, suggest to provide both options:

• http tx submit, response on TxValid
• http tx submit, response on SnapshotConfirmed

So for different users, they can choose which one to use.

Additional context

No response

[ch1bo]

Sounds good, let's add some more specifics to this. For example using a previous ADR draft:

• Handle requests to POST /head/ledger/transactions like the NewTx command on the websocket

  • Require application/json request body containing the JSON encoded Transaction envelope
  • The handler blocks for a configurable maximum time until either of the following happens:
    • Respond with 400 Bad Request upon seeing a TxInvalid with the transaction and validation errors in the response body
    • Respond with 200 OK upon seeing the transaction in a SnapshotConfirmed with at least the snapshot number in the response body
    • Respond with 202 Accepted if only a TxValid but no SnapshotConfirmed was seen within the configurable time limit

• Add a --api-transaction-timeout 10s command line option that configures the maximum time to wait for a snapshot confirmed and before only yielding the Accepted response

@HinsonSIDAN Any opinions on verb, path and responses?

[HinsonSIDAN]

The spec looks pretty good. One quick question I have, what is the lowest possible time to configure at --api-transaction-timeout? For example, one use case we have is we want the 202 as long as there is TxValid. Should we just set it as 0s? Related question, can we set as ms but not s?

[ch1bo]

Both possible. If the "async variant" of only waiting on TxValid is major use case we can also make it more of a first class request. Maybe through a query parameter or so. By making it a timeout (which can be also 0.001s if you want) I thought we could encourage users to rely on the SnapshotConfirmed, for the TxValid alone is unsafe and cannot be considered "done".