-
Notifications
You must be signed in to change notification settings - Fork 88
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 <22031682+acerone85@users.noreply.github.com>
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 <XgreenX9999@gmail.com>
@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 :)
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]