-
Notifications
You must be signed in to change notification settings - Fork 68
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
I01 validate state history upon initialization #2092
base: main
Are you sure you want to change the base?
I01 validate state history upon initialization #2092
Conversation
contracts/src/LightClient.sol
Outdated
// Whereas blockCommRoot can be zero, if we use special value zero to denote empty tree. | ||
// feeLedgerComm can be zero, if we optionally support fee ledger yet. | ||
// The viewNum and blockHeight in the genesis state must be zero to indicate that this is | ||
// the |
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.
This comment block is strangely formatted.
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.
if ( | ||
_genesis.viewNum != 0 || _genesis.blockHeight != 0 | ||
|| BN254.ScalarField.unwrap(_genesisStakeTableState.blsKeyComm) == 0 | ||
|| BN254.ScalarField.unwrap(_genesisStakeTableState.schnorrKeyComm) == 0 | ||
|| BN254.ScalarField.unwrap(_genesisStakeTableState.amountComm) == 0 | ||
|| _genesisStakeTableState.threshold == 0 | ||
|| _genesisStakeTableState.threshold == 0 || _stateHistoryRetentionPeriod < 1 hours |
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.
Can we define a constant for the minimum period of 1 hours
and then use that here and in setstateHistoryRetentionPeriod
?
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.
sure, we can define a constant. Historically, I've been trying to minimize the use of constants in upgradeable contracts to avoid storage layout issues (even though it's stored in the contract's bytecode, if the same variable is no longer a constant in a future version of the contract, it would mess up the storage layout). However, since we use the inheritance pattern for handling upgrades, we shouldn't run into that issue. Will proceed
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.
we spoke offline and agreed not to set a constant since constants can't be upgraded and this constant is one that does have the possibility of changing. Instead, extra comments were added to ensure that developers and users are aware of the min state history retention period 58f43df
… hour and update script to perform permissionedProver validation correctly
Closes #2072
This PR:
This PR does not:
Key places to review:
initializeState
methodHow to test this PR:
forge test --match-test test_revertWhen_InvalidStateHistoryRetentionPeriodOnSetUp
Things tested