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

Expire transactions when TTL reached #1838

Closed
rvl opened this issue Jul 1, 2020 · 3 comments
Closed

Expire transactions when TTL reached #1838

rvl opened this issue Jul 1, 2020 · 3 comments
Assignees
Labels
Feature Mark a PR as adding a new feature, for auto-generated CHANGELOG

Comments

@rvl
Copy link
Contributor

rvl commented Jul 1, 2020

Context

ADP-93 Transaction scheduler

Introduce a time-to-live (TTL) value for transactions, stating that the transaction must be included in the blockchain before a certain slot and simply dropped otherwise.

Decision

  • TTL value is a number of slots, and hardcoded initially.
  • The Tx expiry slot is calculated when the transaction is created, and recorded in the DB with pending transactions.
  • Add a new TxStatus "Expired", which means that the TTL has been reached.
  • In the wallet layer, when applying blocks, check the expiry slot of pending transactions. Any expired transactions are removed from the pending set and marked with Expired state.
  • Tx expiry is not something that can be rolled back.

Acceptance Criteria

  • Transaction expiry must be the time when the transaction was created plus the TTL.
  • Transactions must not be still pending after their TTL has been reached.

Development

As above.

QA

  1. Integration tests are added in lib/core-integration/src/Test/Integration/Scenario/API/Shelley/Transactions.hs
    • TRANS_TTL_01
    • TRANS_TTL_02
    • TRANS_TTL_03
    • TRANS_TTL_04
    • TRANS_TTL_DELETE_01
@rvl rvl added this to the (ADP-93) Transaction scheduler milestone Jul 1, 2020
@rvl rvl self-assigned this Jul 1, 2020
@jonathanknowles
Copy link
Contributor

@rvl

Add a new transaction state "Expired", which means that the TTL has been reached.

Just to clarify, is the intention to represent this as an additional constructor on TxStatus (and corresponding DB field txMetaStatus)?

@rvl
Copy link
Contributor Author

rvl commented Jul 8, 2020

@jonathanknowles Yes, I think so, but after further digging this decision may change.

@rvl rvl added the Feature Mark a PR as adding a new feature, for auto-generated CHANGELOG label Sep 23, 2020
iohk-bors bot added a commit that referenced this issue Oct 9, 2020
1879: Add transaction expiry slot for pending transactions r=KtorZ a=rvl

### Issue Number

Relates to ADP-93 / #1838.

### Overview

- Adds expiry slot to pending transactions in order to implement transaction TTL.
- Expiry slot and time is reported in the transaction history.
- At the expiry slot, pending transactions are marked Expired.
- Default TTL of 7200 slots is still hard coded.


2227: Fix mainnet network parameters r=KtorZ a=rvl

### Issue Number

Relates to #2226.

### Overview

- Rearrange byron/shelley code a little.
- Updates hardcoded epoch length (slots not blocks) and active slot coefficient values for mainnet.
- Also updates slot length parameter.
- Also updates the _minFee a_ parameter - but I'm uncertain why the value was like that before.


Co-authored-by: Rodney Lorrimar <[email protected]>
@HeinrichApfelmus
Copy link
Contributor

This is a very old issue which has been implemented.

The design has changed compared to the issue description. The current design is that

  • Expired transactions can be rolled back, because they can actually still be included in the blockchain after a rollback.
  • The pending transactions are kept in a separate database table from the transactions that are in ledger.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature Mark a PR as adding a new feature, for auto-generated CHANGELOG
Projects
None yet
Development

No branches or pull requests

3 participants