Config: Add contract impl addresses & versions to config toml #525
Conversation
vdamle
force-pushed
the
vinod/impl-addresses
branch
from
1749565
to
97c63f2
Compare
vdamle
changed the title
vdamle
force-pushed
the
vinod/impl-addresses
branch
2 times, most recently
from
35ba4db
to
63f10e4
Compare
| anchor_state_registry = { version = "1.0.0" } | ||
| delayed_weth = { version = "1.0.0" } | ||
| dispute_game_factory = { version = "1.0.0" } | ||
| fault_dispute_game = { version = "1.2.0" } | ||
| permissioned_dispute_game = { version = "1.2.0" } | ||
| mips = { version = "1.0.1" } | ||
| preimage_oracle = { version = "1.0.0" } |
There was a problem hiding this comment.
For FP contracts:
- OptimismPortal2, DisputeGameFactory, and DelayedWETH have shared implementations for all chains, so should have an address here
- PreimageOracle and MIPS are singletons (one, non-proxied instance for all chains). Therefore these probably should be at the superchain level with SuperchainConfig and ProtocolVersions
- Anchor state registry, fault dispute game permissioned dispute game: we know what semver to expect, but each one has a unique address per chain (i.e. these contracts cannot be reused)
There was a problem hiding this comment.
Anchor state registry, fault dispute game permissioned dispute game: we know what semver to expect, but each one has a unique address per chain (i.e. these contracts cannot be reused)
Retained only semvers, dropped addresses.
PreimageOracle and MIPS are singletons (one, non-proxied instance for all chains). Therefore these probably should be at the superchain level with SuperchainConfig and ProtocolVersions
@mds1 It appears that the contract addresses for MIPS and PreimageOracle are different for v1.4.0 and v1.6.0. As is, there is no way to disambiguate contract addresses at the superchain level for different releases. Should we keep these addresses in standard-versions.toml so we have the ability to store an address per release?
There was a problem hiding this comment.
Should we keep these addresses in
standard-versions.tomlso we have the ability to store an address per release?
Yea this seems like a good solution. I would just suggest that we have some way to differentiate the implementations from the singletons, e.g. maybe in the toml we use [contract_tag."op-contracts/v1.4.0".implementations] and [contract_tag."op-contracts/v1.4.0".singletons], or you can add a third key like { version ="foo", address = "bar", kind = <"implementation"|"singleton">
… config toml * store and expose the contract implementation addresses & versions for each contracts release. this is intended to be used by internal/external components such as validation code within superchain-registry, op-stack-manager, monorepo upgrade tool etc. The intent is to persist a single source of truth for the implementation addresses. * the addresses are stored in `superchain.toml` as a map of the contracts release tag as a string to the implementation contract addresses * Initial addresses/versions are recorded for v1.3.0/MCP L1 contracts release
* contract implemetnation addresses now live with contract versions in validation * Instead of two separate files/sections, they are now specified as a `VersionedContract` which is a pre-existing construct in SCR.
moved `op_contracts_release` from superchain.toml to `validation/standard/standard-config.toml`
vdamle
force-pushed
the
vinod/impl-addresses
branch
from
7c01f50
to
fff17a2
Compare
| dispute_game_factory = "1.0.0" | ||
| fault_dispute_game = "1.2.0" | ||
| permissioned_dispute_game = "1.2.0" | ||
| standard_release = "op-contracts/v1.4.0" |
There was a problem hiding this comment.
Ideally, we should be able to run just validate "*" on this branch and have it pass.
I think updating this to "op-contracts/v1.6.0" may be important for that.
* update standard release * make a more useful diff * update go mod --------- Co-authored-by: Vinod Damle <[email protected]>
…ess` in standard contract versions (#587) * VersionedContract has optional implementation_address and address fields * use pointers
(updated 9/9/24)
validation/standard/standard-versions.tomlper contracts release tagsuperchain.tomlasop_contracts_release. Any external consumer should be able to read that tag and look for address/version information under that tag invalidation/standard/standard-versions.tomlv1.3.0/MCP&v1.4.0L1 contracts release.This description is updated per discussion below on the originally created draft PR.
Addresses: #520