-
Notifications
You must be signed in to change notification settings - Fork 94
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
Add expiration policy #871
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
About time we added the expiration :) Both maturity and expiration are important for predicate writing.
We might want to beef up the tests around da_compression.rs to cover policy compression/decompression, as right now it is only testing randomly generated txs without any policies. cc @Dentosal |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Co-authored-by: Andrea Cerone <[email protected]>
let rng = &mut StdRng::seed_from_u64(2322u64); | ||
|
||
// Given | ||
const EXPIRATION: BlockHeight = BlockHeight::new(2); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
const EXPIRATION: BlockHeight = BlockHeight::new(2); | |
const EXPIRATION: BlockHeight = BlockHeight::new(1); |
to clearly show that transactions expire only when the current block height is higher than the specified expiry block (if the match, the transaction is still ok).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the record, I'd also add a similar test fn transaction__execution__doesn_not_work_after_expiration()
and use, for example:
const EXPIRATION: BlockHeight = BlockHeight::new(9);
const BLOCK_HEIGHT: BlockHeight = BlockHeight::new(10);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added a new test to test the current height. However it seems that for maturiy we only test correct case here (failed cases are test elsewhere) but I tried to make one here but finalize_checked
is panicking on error.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can also update the into_ready
function to verify the expiration policy as well. Because this function exists to verify stuff that can change after verification.
@@ -358,6 +361,10 @@ where | |||
Err(ValidityError::TransactionMaturity)?; | |||
} | |||
|
|||
if tx.expiration() < block_height { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dmihal @bajpai244 What do we expect when tx.expiration == block_height
? Should it fail or should it pass?
Co-authored-by: Green Baneling <[email protected]>
@xgreenx Do we agree that if I add it to the |
#593 VM PR : FuelLabs/fuel-vm#871 ### Before requesting review - [x] I have reviewed the code myself ### After merging, notify other teams [Add or remove entries as needed] - [ ] [Rust SDK](https://github.com/FuelLabs/fuels-rs/) - [ ] [Sway compiler](https://github.com/FuelLabs/sway/) - [ ] [Platform documentation](https://github.com/FuelLabs/devrel-requests/issues/new?assignees=&labels=new+request&projects=&template=NEW-REQUEST.yml&title=%5BRequest%5D%3A+) (for out-of-organization contributors, the person merging the PR will do this) - [ ] Someone else?
|
let result = tx.check(block_height, &test_params()); | ||
|
||
// Then | ||
assert_eq!(Err(ValidityError::TransactionExpiration), result); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we check the happy and sad paths for script
and create
, but not for blob
, upgrade
, and upload
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It follows the same pattern as the others policies, the correct cas is only tested in valid_cases.rs
file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we should take the existing coverage as cannon. I think we should cover happy and sad for all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okeyyyy, added :)
## Linked Issues/PRs Spec PR : FuelLabs/fuel-specs#616 VM PR : FuelLabs/fuel-vm#871 ## Description This PR use the new policy `expiration` in transaction pool to prune transactions when they are expired to prevent them to be included in a block. Also verification is added when executing transaction in the executor. ## Checklist - [x] Breaking changes are clearly marked as such in the PR description and changelog - [x] New behavior is reflected in tests - [x] [The specification](https://github.com/FuelLabs/fuel-specs/) matches the implemented behavior (link update PR if changes are needed) ### Before requesting review - [x] I have reviewed the code myself - [x] I have created follow-up issues caused by this PR and linked them here ### After merging, notify other teams [Add or remove entries as needed] - [ ] [Rust SDK](https://github.com/FuelLabs/fuels-rs/) - [ ] [Sway compiler](https://github.com/FuelLabs/sway/) - [ ] [Platform documentation](https://github.com/FuelLabs/devrel-requests/issues/new?assignees=&labels=new+request&projects=&template=NEW-REQUEST.yml&title=%5BRequest%5D%3A+) (for out-of-organization contributors, the person merging the PR will do this) - [ ] Someone else? --------- Co-authored-by: acerone85 <[email protected]> Co-authored-by: Andrea Cerone <[email protected]>
FuelLabs/fuel-specs#593
Spec PR : FuelLabs/fuel-specs#616
Checklist
Before requesting review
After merging, notify other teams
[Add or remove entries as needed]