Dynamic struct tags to support different chain specifications

karalabe / ssz

Opinionated 0-alloc SSZ codec for Go

https://github.com/ethereum/consensus-specs/blob/dev/ssz/simple-serialize.md

BSD 3-Clause "New" or "Revised" License

40 stars 8 forks source link

Dynamic struct tags to support different chain specifications #23

Open pinebit opened 3 months ago

pinebit commented 3 months ago

For some chains like Gnosis, different field specs are defined (example). A notable example is

Withdrawals   []*Withdrawal ssz-max:"16"`

which has ssz-max=16 for Ethereum networks and ssz-max=8 for Gnosis (yet there are other differences). This changes serialization and hashing results, which makes derived products not supporting chains other than Ethereum.

Is there a workaround for such the specific chains (Gnosis)? The only viable option as it seems is to build two/three/more copies of objects (structs) having different struct attributes..

Other projects (Lodestar, Teku..) do support this. Here is how the above example is handled by Teku: https://github.com/Consensys/teku/blob/777c9dc7bbaa2f563e870b5fa277e48472e234ae/ethereum/spec/src/main/java/tech/pegasys/teku/spec/datastructures/execution/versions/capella/ExecutionPayloadSchemaCapella.java#L104

itsdevbear commented 3 months ago

Imo, this should be done via the codec / fork stuff, so it can be defined at runtime.

karalabe commented 3 months ago

I'll think about this a bit. One gut reaction is that why would you want to share data structures between gnosis and non-gnosis chains if they are "structurally different"? I mean the generated code/encoding will need to be different, so the only advantage is having a single source definition. Not per say bad, but it's a use case I haven't considered yet.

karalabe commented 3 months ago

Hmm, the linked Java code seems to be the literal encoder. You could do the same thing with this ssz lib if you wrote your own DefineSSZ method instead of generating one from Go tags; switching on some chain spec param manually. Supporting variables inside the generator seems a bit of a can of worms.

@itsdevbear's idea with forks will probably not work as in this case you'd want to have a different code within the same fork across different networks. Again, I could perhaps expand the fork support with other dimensionality, but I'm afraid that even like this it's getting a bit messy and should only be used for monolith types.

My gut reaction is that you have two workarounds:

Define two separate types and generate the code for them
Have a single type but manually write the DefineSSZ

Whilst neither is the "best", I'm trying to figure out the monoliths first, so it might take a while until I hit this issue. Will keep the issue open nonetheless, but don't expect a quick resolution apart of the two workarounds. :D