Support for "stacked" proposals that have incrementing nonces

[mds1]

Often times we need to schedule multiple tasks to be executed around the same time, and this requires careful, error-prone nonce coordination to ensure tasks are executed in the right sequence, and the right nonces are hardcoded. Additionally, there is no easy way to have a task automatically simulate all prior dependent tasks.

This issue needs some thought on the best way to implement. A rough idea is that a config file or .env file lists the names of all dependent tasks. A CI check ensures that these tasks are imported in the solidity script and executed before this task is simulated. The solidity script's execution must be conditional based on the preceeding task statuses, i.e. if it's DRAFT it should be executed, but if it's EXECUTED then we do not want to re-execute it

This dependency list can be used to infer the required nonces to avoid needing to hardcode them

[sebastianst]

Stacked Tasks

I have some ideas how to improve this.

• We remove all prefixes like base-, ink- etc from tasks.
• We use the lexicographic ordering of task folder names as the canonical order in which they are executed
  • This also allows us to slide in a task in between existing once, without having to renumber all following.
• Instead of manually adding individual tasks to CI, we have one smart CI task that
  • for each tasks folder(eth, sep), it creates an lexicographically ordered list of all tasks
  • it iterates from the start over all tasks and finds the first non-EXECUTED (could just parse from the README as a start)
  • all future tasks are executed one after another as a stack
  • this works by requiring tasks to adhere to the convention that they either have a SignFromJson.s.sol or NestedSignFromJson.s.sol file, and the affected Safes could be parsed from the .env file
• the just sign and just simulate steps would reuse the same logic to determine Safe accounts and nonces

Safe Config

We could also improve how an individual task specifies some inputs like the Safes it uses. This could be more robust than how we currently define them in .env files. E.g. in each tasks main dir (eth etc), we could have a config like safes.toml that defines a list of safes with aliases, e.g.

[safes.l1poa]
desc = "Superchain L1 ProxyAdminOwner"
address = "0x5a0Aae59D09fccBdDb6C6CcEB07B7279367C3d2A"
owners = ["fus", "scs"]

[safes.fus]
desc = "Foundation Upgrade Safe"
address="0x847B5c174615B1B7fDF770882256e2D3E95b9D92"

[safes.scs]
desc = "Security Council Safe"
address="0xc2819DC788505Aac350142A7A707BF9D03E3Bd03"

Then in each individual task folder, we could have a task.toml file that defines some metadata about the task, e.g.

type = "nested"
executer = "l1poa"

and then the smart per-L1 stacked task executor can use this metadata to calculate determine nonces etc.

[blmalone]

Closed: https://github.com/ethereum-optimism/superchain-ops/issues/447 as it looks like a duplicate of this task.

[Ethnical]

I have finished a preversion that would need to be slighty adapted for the new templating system -> https://github.com/ethereum-optimism/superchain-ops/pull/611

[blmalone]

Great suggestions in this issue. @Ethnical, I haven’t had a chance to fully review your PR yet.

I wanted to put some thoughts down on how I might see this working with the new system (I like Seb’s suggestion about lexicographical ordering of task names).

I was thinking the config.toml file of each new task could have a new TOML table [dependsOn]. Under this, we would include a key called task with the name of the task that must be simulated first (if it hasn’t been executed yet). This would be recursive if that task also depends on another, then that will be simulated before all of them.

This approach allows for more granularity and clearer descriptions of our “stacked” tasks. It’s also more robust against task developers incorrectly naming a task.

e.g.

[Ethnical]

Oh interesting. Just we need to take in consideration simple usage also for tasks creator to make sure they can still simulated the stacked sequence in the CI easy and add the task easy.

[blmalone]

Closing, implemented in this PR: https://github.com/ethereum-optimism/superchain-ops/pull/819