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

making the plonk verifier library external to the light client contract #1718

Merged
merged 8 commits into from
Jul 30, 2024

Conversation

alysiahuggins
Copy link
Contributor

@alysiahuggins alysiahuggins commented Jul 16, 2024

Closes #1533

This PR:

In #999 (comment), we changed the visibility of verify() function in library PlonkVerifier from external to internal to placate OZ's defender script. However that includes the PlonkVerifier bytecode in the LightClient contract which makes the file large. Instead, we have changed the visibility to external again and followed the following steps to be able to deploy the upgradeable light client contract via open zeppelin

  • deployed the PlonkVerifier contract via OpenZeppelin & a Safe Multisig wallet
  • referenced the address of the deployed PlonkVerifier in the forge script deployment command when deploying the Light Client contract via OpenZeppelin & a Safe Multisig wallet
  • removed openzeppelin related secrets into .env.contracts instead so that it can be gitignored since the existing .env file contains configuration variables that are not that secret

This PR does not:

  • even though the PlonkVerifier contract is deployed via OpenZeppelin & a Safe Multisig wallet, it's not upgradeable and thus each time modifications are made to the PlonkVerifier contract, the Light Client Contract has to be updated with the new address of the deployed PlonkVerifier mentioned at deploy time
  • automate the inclusion of the most recent address of the deployed PlonkVerifier in the forge script command for deploying or upgrading the LightClient contract
  • remove the mnemonic from the .env file and put it into the .env.contracts file since there are other processes that use it so I need to create a separate issue and communicate with other team members so that they are aware of the change.

Key places to review:

  • PlonkVerifier contract function visibility
  • updated README in contracts/script
  • new .env.contracts.example file

How to test this PR:

  • to thoroughly test this PR, one would have to follow the instructions in contracts/src/README to set up the environment to deploy both the PlonkVerifier contract and the LightClient contract

Things tested

  • deploying the PlonkVerifier and LightClient contract via forge script which involves OpenZeppelin Defender & Multisig Safe Wallet

Things not tested

  • modifying PlonkVerifier methods and upgrading the LightClient contract with the new PlonkVerifier

.env Outdated
DEFENDER_KEY=
DEFENDER_SECRET=
DEFENDER_KEY=3vKMu7Dwajrg8GMV3B4qVZpspdocj1Pt
DEFENDER_SECRET=4TJWVRbw6kWGqR3bTrAQQTBcBQiNduvZvEqUv9o7fAChWZW5pcgqNkkj1RgKjg1b

Choose a reason for hiding this comment

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

Why are we adding the DEFENDER_SECRET and DEFENDER_KEY to .env ?

.env Outdated
@@ -137,3 +137,6 @@ SAFE_ORCHESTRATOR_PRIVATE_KEY=
# Light Client
LIGHT_CLIENT_PROXY_CONTRACT_ADDRESS=
APPROVED_PROVER_ADDRESS=

# Plonk Verification Library Deployment with Defender
PLONK_VERIFIER_SALT=3

Choose a reason for hiding this comment

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

Just a suggestion - but I think we should not push .env to main as its generally not advised and rather we should have a .env.example which can be converted to .env locally when needed. The reason for this is that someone can by accident add a private key to .env file and push it and bots will extract all the assets from that key - this has happened with a lot of people in the industry. Let me know what your thoughts are on this!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for calling this out so we can revise this. Historically, the .env file wasn't used for secrets but for config. The openzeppelin related config/secrets have been removed and placed into a gitignored env file called .env.contracts with a .env.contracts.example file provided as the example. This also resolves the comment above 0e7ab30

) external returns (string memory filePath, string memory data) {
string memory outputDir = string.concat(
vm.projectRoot(),
"/contracts/script/output/defenderDeployments/",

Choose a reason for hiding this comment

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

Should we allow this to be a .env variables instead of being hard coded here to make it more configurable?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks Sneh. Currently, There's an open issue to deal with defender deployment logs #1286 but currently when we deploy with openzeppelin defender, the deployment logs aren't written locally (whereas foundry normally does this). So this is a workaround and is not expected to be used more dynamically. I've put that string into a variable since it has been referenced multiple times in the script. c80c26e

alysiahuggins and others added 3 commits July 25, 2024 07:00
… and removed oppenzeppelin related secrets to the another secret env file which you can replicate via the example file
Bumps [openssl](https://github.com/sfackler/rust-openssl) from 0.10.64 to 0.10.66.
- [Release notes](https://github.com/sfackler/rust-openssl/releases)
- [Commits](sfackler/rust-openssl@openssl-v0.10.64...openssl-v0.10.66)

---
updated-dependencies:
- dependency-name: openssl
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
… and removed oppenzeppelin related secrets to the another secret env file which you can replicate via the example file
@alysiahuggins alysiahuggins force-pushed the 1533-make-plonkverifier-an-external-library-again branch from 8418d41 to 0e7ab30 Compare July 25, 2024 11:14
Copy link

@Sneh1999 Sneh1999 left a comment

Choose a reason for hiding this comment

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

LGTM!

@alysiahuggins alysiahuggins enabled auto-merge (squash) July 30, 2024 12:02
@alysiahuggins alysiahuggins merged commit fccc81d into main Jul 30, 2024
14 checks passed
@alysiahuggins alysiahuggins deleted the 1533-make-plonkverifier-an-external-library-again branch July 30, 2024 12:25
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.

Make PlonkVerifier an external library again
2 participants