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

Suggestion: improved proposal ops #140

Open
pegahcarter opened this issue Apr 16, 2024 · 3 comments
Open

Suggestion: improved proposal ops #140

pegahcarter opened this issue Apr 16, 2024 · 3 comments

Comments

@pegahcarter
Copy link

I propose using a framework like forge-proposal-simulator to standardize how proposals are generated.

@mds1
Copy link
Contributor

mds1 commented Apr 16, 2024

Thanks for the suggestion! Can you expand on your vision here a bit more? We have some ideas for how to improve tooling in this repo, but it's mainly around safety checks around state changes, for example running various assertions about the state diff in a _postCheck method. See here for an example.

I'm not too familiar with forge-proposal-simulator, but it seems to basically use a similar approach with the _validate method?

@ElliotFriedman
Copy link
Contributor

The Forge Proposal Simulator is designed to help eliminate bugs in governance proposals. It does this in two ways:

  1. Explicitly ask the developer to write validations tailored to each proposal, which adds safety checks and lets you know the actions that were run made the expected state changes.
  2. Allows you to wire together the governance proposals into the integration tests. Let's say optimism has a huge integration test suite just for the smart contracts in another repo, which I would imagine to be the case. With a little bit of work connecting this framework to your integration tests, now all governance proposals will run against your integration test suite. Say there is a bug caused by a change in a governance proposal where some part of the smart contract system on L1, or L2 will not work after the proposal passes. If an integration test existed for that behavior, you would be able to catch this bug in the governance proposal before it goes live.

To properly integrate this tool and get the full benefits, you would likely need to move your governance proposal creation to the repo where the smart contracts and integration test suite lives, but I'm sure there's other ways around this if you don't want to move things around too much.

In most smart contract protocols today, governance proposals and deployment scripts are some of the least audited parts of the codebase because they are expected to be secure, or not do anything incorrectly. These assumptions often turn out to be wrong, so we built this tool to help solve this pain point and hopefully get rid of bugs that could be easily caught with checks and a run against the existing integration test suite post proposal.

The main benefit you would get from day 1 using this tool is there would not be a need to write a JSON file that specifies all targets, calls, parameters, and values. Instead, you could write the proposal straight in readable Solidity, which would then be extracted into calls for the multisig wallet to make via multicall. This is what a proposal would look like from an example in our docs:
Screenshot 2024-04-24 at 10 00 03 AM
You just write the proposal in plain solidity, and then the tool extracts the calldata, pranks as the multisig, and applies the state changes. It includes support for Gnosis Safes, Openzeppelin Timelock Controllers and Governor Bravo/Timelock DAO combinations. Once you've generated a multisig proposal, and run everything locally, all tests and validations pass, it provides a convenient calldata logging functionality, which you can then take, and paste straight into the Gnosis Safe UI.

You can learn more about Forge Proposal Simulator in the docs, reading the code, or reach out directly and I can walk you through things.

@ElliotFriedman
Copy link
Contributor

Another benefit is you could consolidate and make your addresses system easier to use https://github.com/ethereum-optimism/superchain-ops/blob/main/tasks/sep/metal-001-MCP-L1/SignFromJson.s.sol#L396-L404

Instead would look more like this addresses.getAddress("ADDRESS_NAME").

https://docs.soliditylabs.io/forge-proposal-simulator/guides/multisig-proposal#setting-up-the-addresses-json

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

No branches or pull requests

3 participants