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

feat(connector-besu): request param: wait for ledger tx receipt #685

Closed
petermetz opened this issue Mar 19, 2021 · 0 comments · Fixed by #701
Closed

feat(connector-besu): request param: wait for ledger tx receipt #685

petermetz opened this issue Mar 19, 2021 · 0 comments · Fixed by #701
Assignees
Labels
Besu enhancement New feature or request

Comments

@petermetz
Copy link
Contributor

Is your feature request related to a problem? Please describe.

Right now the transaction receipt that we return from the transaction runner endpoint is the local receipt of the node confirming the addition of the transaction to it's pool not the one that the ledger provides once the transaction has been added to a block for real.

The problem with that of course is that users will definitely want a way to have confirmation of the tx having gone through with the ledger, not just the tx pool.

Describe the solution you'd like

Need an optional parameter on the request body with a type of "object" that has members to describe how (if at all) Cactus should wait for the ledger confirmation. Should be able to express things such as:

  1. Do we want to wait for ledger confirmation or not?
  2. Do we want to wait for a certain number of blocks to be confirmed after the block where our transaction was? (useful for proof of work public ledgers where transaction finality is not guaranteed and the next best thing is to wait N number of additional block confirmations where the larger N the longer the wait but also the lower the probability of a fork erasing our transaction. (since we are not in control here, the next best thing we must do is to provide the caller with a choice so that they can decide on the right trade-off between wait time and fork risk)
  3. Timeout in milliseconds: A certain amount of time after which the request should return with a timeout error if there was no receipt obtained by then. The default for this timeout should be infinity e.g. we don't just give up on waiting for the tx to confirm without expliictly being asked by the user in advance to exhibit this behaviour.

Describe alternatives you've considered

Nothing, I'm pretty sure we need this.

Additional context

This was suggested by Shingo and Takuma earlier so thanks to them for bringing it up as a possible improvement.

cc: @takeutak @sfuji822 @hartm @jonathan-m-hamilton @AzaharaC @jordigiam @kikoncuo @jagpreetsinghsasan

@petermetz petermetz added the enhancement New feature or request label Mar 19, 2021
@petermetz petermetz self-assigned this Mar 19, 2021
@petermetz petermetz added the Besu label Mar 19, 2021
petermetz added a commit to petermetz/cacti that referenced this issue Mar 19, 2021
…ledger-cacti#685

This is work in progress
-----------------------------------

Fixes hyperledger-cacti#685

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz added a commit to petermetz/cacti that referenced this issue Mar 22, 2021
…ledger-cacti#685

Adds new parameters to the run transaction endpoint's request object
that allow the caller to specify a the consistency strategy
parameters that can define if the connector should wait for either:
1. the transaction to be confirmed only by the node's transaction pool
2. if at least the block containing the transaction should be mined
by the ledger
3. an N number of additional blocks should be confirmed by the ledger
in **addition** to the block that contained the transaction.

The parameters also allow to specify a timeout in milliseconds that
if unspecified defaults to the maximum safe integer that Javascript
can represent which for practical purposes we consider to be the
same as waiting until the heat death of the universe or infinity.

Fixes hyperledger-cacti#685

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz added a commit to petermetz/cacti that referenced this issue Mar 22, 2021
…ledger-cacti#685

Adds new parameters to the run transaction endpoint's request object
that allow the caller to specify a the consistency strategy
parameters that can define if the connector should wait for either:
1. the transaction to be confirmed only by the node's transaction pool
2. if at least the block containing the transaction should be mined
by the ledger
3. an N number of additional blocks should be confirmed by the ledger
in **addition** to the block that contained the transaction.

The parameters also allow to specify a timeout in milliseconds that
if unspecified defaults to the maximum safe integer that Javascript
can represent which for practical purposes we consider to be the
same as waiting until the heat death of the universe or infinity.

Fixes hyperledger-cacti#685

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz added a commit to petermetz/cacti that referenced this issue Mar 23, 2021
…ledger-cacti#685

Adds new parameters to the run transaction endpoint's request object
that allow the caller to specify a the consistency strategy
parameters that can define if the connector should wait for either:
1. the transaction to be confirmed only by the node's transaction pool
2. if at least the block containing the transaction should be mined
by the ledger
3. an N number of additional blocks should be confirmed by the ledger
in **addition** to the block that contained the transaction.

The parameters also allow to specify a timeout in milliseconds that
if unspecified defaults to the maximum safe integer that Javascript
can represent which for practical purposes we consider to be the
same as waiting until the heat death of the universe or infinity.

Fixes hyperledger-cacti#685

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz added a commit to petermetz/cacti that referenced this issue Mar 26, 2021
…ledger-cacti#685

Adds new parameters to the run transaction endpoint's request object
that allow the caller to specify a the consistency strategy
parameters that can define if the connector should wait for either:
1. the transaction to be confirmed only by the node's transaction pool
2. if at least the block containing the transaction should be mined
by the ledger
3. an N number of additional blocks should be confirmed by the ledger
in **addition** to the block that contained the transaction.

The parameters also allow to specify a timeout in milliseconds that
if unspecified defaults to the maximum safe integer that Javascript
can represent which for practical purposes we consider to be the
same as waiting until the heat death of the universe or infinity.

Fixes hyperledger-cacti#685

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz added a commit to petermetz/cacti that referenced this issue Mar 26, 2021
…ledger-cacti#685

Adds new parameters to the run transaction endpoint's request object
that allow the caller to specify a the consistency strategy
parameters that can define if the connector should wait for either:
1. the transaction to be confirmed only by the node's transaction pool
2. if at least the block containing the transaction should be mined
by the ledger
3. an N number of additional blocks should be confirmed by the ledger
in **addition** to the block that contained the transaction.

The parameters also allow to specify a timeout in milliseconds that
if unspecified defaults to the maximum safe integer that Javascript
can represent which for practical purposes we consider to be the
same as waiting until the heat death of the universe or infinity.

Fixes hyperledger-cacti#685

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz added a commit that referenced this issue Mar 26, 2021
Adds new parameters to the run transaction endpoint's request object
that allow the caller to specify a the consistency strategy
parameters that can define if the connector should wait for either:
1. the transaction to be confirmed only by the node's transaction pool
2. if at least the block containing the transaction should be mined
by the ledger
3. an N number of additional blocks should be confirmed by the ledger
in **addition** to the block that contained the transaction.

The parameters also allow to specify a timeout in milliseconds that
if unspecified defaults to the maximum safe integer that Javascript
can represent which for practical purposes we consider to be the
same as waiting until the heat death of the universe or infinity.

Fixes #685

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
jordigiam pushed a commit to kikoncuo/cactus that referenced this issue Apr 8, 2021
…ledger-cacti#685

Adds new parameters to the run transaction endpoint's request object
that allow the caller to specify a the consistency strategy
parameters that can define if the connector should wait for either:
1. the transaction to be confirmed only by the node's transaction pool
2. if at least the block containing the transaction should be mined
by the ledger
3. an N number of additional blocks should be confirmed by the ledger
in **addition** to the block that contained the transaction.

The parameters also allow to specify a timeout in milliseconds that
if unspecified defaults to the maximum safe integer that Javascript
can represent which for practical purposes we consider to be the
same as waiting until the heat death of the universe or infinity.

Fixes hyperledger-cacti#685

Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Besu enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant