search

ethereum-optimism / superchain-registry

An index of chains which serves as the source of truth for who’s in the Superchain Ecosystem
MIT License
72 stars 72 forks source link

Clarify and improve superchain registry semver validations #289

Closed mds1 closed 2 months ago

mds1 commented 4 months ago

Originally from https://github.com/ethereum-optimism/superchain-registry/pull/248#discussion_r1606791275:

@mds1: I still don't (and never fully did) understand the difference between this and semver.yaml. In this notion doc we recently defined a mapping from op-contracts/vX.Y.Z release to the expected semvers for each contract. Ultimately, the verification we should be doing in the superchain registry is making sure a chain's contracts is on one of those op-contracts tags, as determined by the semvers (and bytecode validation, since a contract can lie about its semver).

So what exactly is supposed to be in each of these files that lists contract versions, in relation to the linked version definitions?

@geoknee: Thanks for raising this, I have also never really understood the role of this file. I think resolving this is very important, but somewhat outside the scope of this PR so if possible would prefer not to block on it.

The document you linked is very clear and I would be happy to overhaul the validation checks and declaration files have in the registry to match it.

Proposal:

  • semver.yaml -> standard-contract-versions.toml (or some better name), with now encodes the mapping from monorepo tags to a list of (contract,version) pairs as described in your doc. Lives next to the standard config toml files in the validation module, we no longer export that information from superchain.
  • validation check ensures each chain has a set of contract versions which exactly match 1:1 to at least one monorepo tag mapping entry in the above file. From what I can tell this can be just a dumb string equality check, since the versions are not true semantic versions and we won't do any true semantic version comparisons.
  • bytecode validation is something which is not yet in scope for the superchain registry checks but we are looking at pulling that in to scope.

The "implementations" yaml files are currently not referenced by any validation check in this repo. They are referenced in one place in op-chain-ops https://github.com/ethereum-optimism/optimism/blob/69bb36c9ba95705cc730d1e145501a510c448775/op-chain-ops/cmd/op-upgrade/main.go#L226-L246 . You might be better placed than me to suggest how we tidy that up, I would be infavour of reducing complexity if at all possible.

cc @tynes who might have insight into the original intent which would be useful for informing how to best clean this up

geoknee commented 3 months ago

https://drive.google.com/file/d/1TkQBztHfkZ4u7HD6YhM7zhiXMnzRDT_b/view

pegahcarter commented 2 months ago

@geoknee the drive file is private.

geoknee commented 2 months ago

Sorry @pegahcarter I put that link on before this issue was migrated to being public. If you're interested in the direction of travel on this issue, please check out this draft PR https://github.com/ethereum-optimism/superchain-registry/pull/297 .