More granular checking of addresses.json so we don't have to update the scr submodule as often.

[blmalone]

An approach here could be to further narrow the comparison. Instead of hashing the whole file. We could check if specific chain ids (that we care about) have changed compared to our local copy. Alternatively, maybe we just look for new system config addresses? We'd still need updates in that case, but then it will change a bit less frequently.

See the check superchain-registry job in circle ci: https://github.com/ethereum-optimism/superchain-ops/blob/main/.circleci/config.yml#L145

The SuperchainAddressRegistry.sol does discovery onchain. Perhaps we can limit the changes to only the seed addresses that it needs?

[ajsutton]

If you want to be sure superchain-registry is up to date, why not just have the build process checkout the latest version instead of using a submodule? It does mean that builds aren't reproducible because superchain-registry updates are pulled in even without a change to this git repo but that may be the right trade off for superchain-ops given we want to compare them to latest data before they execute and drop them from CI once they are executed anyway.

[blmalone]

Closing as implemented here: https://github.com/ethereum-optimism/superchain-ops/pull/1024