Regenerated genesis bug

[blmalone]

Discoverd in this pr, we found that the regenerated genesis contains storage allocations that have zero as the value field. This causes the genesis allocs test to fail because op-deployer doesn't do this, nor should it.

[geoknee]

I'm a bit confused by this change. AFAICT this is not a bug in the validation code, but possibly a bug in the genesis creation code itself. Seems weird to "fix" it here -- wouldn't this risk a valid genesis allocs (valid by our working definition, that it was generated using standard tooling invocations at a specified commit in the monorepo) failing validation (because it would have the the zeros which are now removed from the expectation).

[mds1]

The key point is that for slots that are not set in genesis, the default storage value is zero. So two genesis files, where one omits zero valued slots and one explicitly sets them, are equivalent.

Therefore I think the ideal fix is for the superchain registry to normalize both the provided genesis and the generated genesis before diffing them, by removing all slots where the value being set in storage is zero. This way it doesn't matter whether or not the provided and generated genesis files have these no-op keys being set, since both versions are equivalent

In op-deployer, we do this same normalization when generating genesis. But you are right that this diff might cause genesis files generated by other scripts that don't normalize to fail. So we could extend this PR to normalize both genesis files to be more robust

[geoknee]

@mds1 agreed, Blaine and I just reached the same conclusion :-)

[bitwiseguy]

Should we remove empty storage slots in the version of the genesis file that gets stored in the repo? Might save us some bytes