Skip to content

[Certora] earliest time spec with decreasetimelock#901

Open
lilCertora wants to merge 1 commit intomainfrom
certora/earliest-time-decrease-timelock
Open

[Certora] earliest time spec with decreasetimelock#901
lilCertora wants to merge 1 commit intomainfrom
certora/earliest-time-decrease-timelock

Conversation

@lilCertora
Copy link
Copy Markdown
Collaborator

Added extra comments in order to make understanding easier but we can remove them later

=> Verify earliestExecutionTimeIncreases for decreaseTimelock by bypassing the prover's msg.data-in-hooks limitation using the fallback pattern. Paths 1 (direct execution) and 2 (fresh submission) are formally verified; path 3 (remaining pending ops) holds by the argument that removing an element from a min can only increase it (due to code)


// The timelocked() function enforces block.timestamp >= executableAt[msg.data].
// The checker read execAtOfOp = vault.executableAt(msg.data) with the same msg.data.
// The prover can't link these reads across contracts, so we add the constraint explicitly.
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

curious to understand what this means, why can't it do that ? I had some verification jobs that were passing where values are taken from different contracts

Comment on lines +149 to +150
assert viaDirectAfter >= earliestBefore;
assert viaFreshAfter >= earliestBefore;
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If viaDecreaseAfter < earliestBefore, then we have earliestAfter < earliestBefore, which is what we want to show cannot happen.
So I think the argument why it's ok is that viaDecrease actually increases when decreaseTimelock is called, as explained here

Comment on lines +133 to +135
mathint viaDecreaseBefore = (timelockAfter < timelockBefore && execAtOfOp != 0)
? to_mathint(execAtOfOp) + to_mathint(timelockAfter)
: max_uint256;
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It could be lower than that though, because there could be other pending data of decreaseTimelock with different durations. I think that this page defines viaDecrease accurately. The definition of minDecreaseTimelock that is currently on main is wrong I think, and #903 fixes it

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you can reuse the EarliestTime.sol for that

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants