feat: Support all OP Stack components

[clabby]

Is your feature request related to a problem? Please describe. Currently, the alternative implementations of OP Stack components, apart from op-erigon and asterisc, cannot take advantage of the superchain registry. This creates a sharded collection of chain configurations, where components like op-reth, magi, hildr, op-besu, op-nethermind, cannon-rs, the Rust FPP, and whatever comes in the future that isn't written in Golang, cannot take advantage of this package.

Describe the solution you'd like Modularize the superchain registry such that it can be used by all OP Stack components, preparing for a future where our critical infrastructure is implemented in many more languages than just Go.

Ideally, this means defining a core implementation, preferably in a language such as C, C++, or Rust that is more friendly for interop, and then creating FFI bindings that enable several front-end APIs to be built for the library.

We currently need support for:

• Java
• Rust
• C#

Describe alternatives you've considered

1. Implement separate versions of the superchain-registry repository for each language that the OP Stack's core components are built upon. This would require a decent bit of duplicated code, increasing the possibility of divergent configuration between the implementations.
2. Create FFI bindings from the Go implementation. Go does not lend itself well towards being called via FFI, and Cgo is a bit horrendous to work with when the direction is <language> -> Go rather than Go -> <language>. It requires cbindgen to embed Go types and semantics into the C header, etc. Rather than doing this, we should choose a more FFI friendly language that is closer to C (or, even C/C++ itself) for the base implementation.

Additional context Modularizing the superchain registry will pay dividends in the future, offering a central, interoperable library for every OP Stack component to share the same configuration utilities.

[ajsutton]

Before diving into building sharable code, we should review how we approach configuration. It's usually better to have a well defined config file format so that each client can then parse it using its own code rather than needing to embed a shared library. I'm not sure of the details of why we've got specific go code in this repo and it may be the right option but we should evaluate the options for making config available to alternate clients and not just dive into building reusable code.

[protolambda]

I'm not sure of the details of why we've got specific go code in this repo

To have have a form that we can read and validate the configuration consistency of. E.g. address-format (checksums), completeness (missing references), and bytecode hashing are all tested with Go. And then it's better to expose the struct types publicly, so we do not have to duplicate them in the optimism monorepo or op-geth software.

---

This doesn't have to be repeated for every language. As long as the raw config files can be embedded into the destination program of choice, then we don't need complete bindings.

And these configs are not particularly performance-sensitive, we just need to keep the total data reasonably small (hence the bytecode deduplication and compression), to not blow up the binary size of op-stack applications.

One approach to configs for all languages might be to expose just minimal bindings that expose the config as embedded filesystem (i.e. just a simple read-function by filepath). That way we can do releases/versioning of native package, but don't have to opinionate bindings or create types for every language. This might be as simple as defining a package definition file, that then exposes the config files as importable data (like in JS).

Or alternatively, if the programming language of choice already can import a git repo efficiently and elegantly as dependency by git release tag, then we don't need any bindings for it at all.

[GrapeBaBa]

Which approaches will we choose?

[pegahcarter]

Can we add Solidity support here as well? It may be worth integrating the registry on the contract level.