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.