-
Notifications
You must be signed in to change notification settings - Fork 87
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
modify upgrade scripts for non-multisig, non-openzeppelin-defender deployments #1705
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.
Code looks good to me with a first glance. I have one clarifying question but nothing that I think should block merging as the tests are passing locally for me.
bool public permissionedProverEnabled; | ||
|
||
/// @notice an array to store the L1 Block Heights where the finalizedState was updated | ||
uint256[] public stateUpdateBlockNumbers; |
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.
Would it be better to have this as uint128[]
? I'm not 100% sure how solidity lays out memory under the hood but we could potentially half the size of every element in this array if we are okay with the max value of an entry being (2^128) -1.
However, I also recognize this is a test file and gas costs might not be a factor here.
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.
yea it would be advantageous to allocate less bits to this! I'll change to uint64, thanks!
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.
actually looking at this again, since we're unsure about the future block sizes and this stores l1 blocks, sticking with uint256[]
might be best.
Closes #1704
This PR:
The existing script UpgradeLightClient.s.sol was created only for testing purposes for the demo LightClientV2. However, since the current LightClient contract has been deployed without OpenZeppelin Defender & without a multisig wallet, we need to maintain upgrade scripts for the current light client deployment.
Key places to review:
How to test this PR:
just sol-test
To run tests specific to upgrades run
forge test --match-contract LightClientUpgradeSameContractTest --ffi -vvv
and
forge test --match-contract LightClientUpgradeToV2Test --ffi -vvv
Things tested
DeployLightClient.s.sol
scriptUpgradeSameLightClient.s.sol
script