Skip to content
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

Merged
merged 6 commits into from
Jul 24, 2024

Conversation

alysiahuggins
Copy link
Contributor

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:

  • the updated script and tests

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

  • Deploying the LC with this script DeployLightClient.s.sol script
  • Upgrading the LC with the UpgradeSameLightClient.s.sol script
  • An upgrade to the current Light Client that's being updated by provers happened live with @Ancient123

@zacshowa zacshowa self-requested a review July 23, 2024 20:34
Copy link
Member

@zacshowa zacshowa left a 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;
Copy link
Member

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.

Copy link
Contributor Author

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!

Copy link
Contributor Author

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.

@alysiahuggins alysiahuggins merged commit cd9ae47 into main Jul 24, 2024
14 checks passed
@alysiahuggins alysiahuggins deleted the lc_upgrade branch July 24, 2024 15:43
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.

modify upgrade scripts for non-multisig, non-openzeppelin-defender deployments
2 participants