hyperledger-labs / go-perun

🌔 Perun's Blockchain-Agnostic State Channels Framework in Go.
https://perun.network/
Apache License 2.0
55 stars 18 forks source link

GOB Encoding of core types #329

Open sebastianst opened 2 years ago

sebastianst commented 2 years ago

The stdlib gob package can be used to encode Go objects over the wire. While trying to use it for encoding some core types, like channel.State or channel.Params, it didn't work out of the box.

I identified two problems:

  1. If interfaces are to be sent over the wire, gob needs to be made aware of all possible implementations of those interfaces in advance using gob.Register. This is not the case for our implementations of wallet.Address, channel.Asset, channel.App, channel.Data or channel.Action, possibly others.
  2. gob gets confused by interfaces that include gob.GobDecoder, gob.GobEncoder or encoding.BinaryMarshaler, encoding.BinaryUnmarshaler. If gob sees an object that implements those interfaces, it takes those implementations for en/decoding, which makes sense. However, it then doesn't transport the type information with the encoding, so the decoding side doesn't know which object to create. I found a Google groups discussion on the topic and a SO post.

I made the following observations that, if implemented, would hopefully make it work:

  1. All concrete interface implementations in backends need to be registered using gob.Register, e.g. adding
    func init() {
    gob.Register((*Address)(nil))
    }

    to packages backend/{sim,ethereum}/wallet. Same for Assets, Apps etc. Make sure to use the correct type (pointer or no pointer) depending on what actually is used as the interface implementation (e.g. noApp is used as a non-pointer type).

  2. All interfaces used in structs that are to be encoded with gob need to remove the embeddings of gob.GobDecoder, gob.GobEncoder or encoding.BinaryMarshaler, encoding.BinaryUnmarshaler. Of course, the concrete implementations can still implement those interfaces, but it is important that the struct field interface types don't reference those, or gob gets confused and uses the methods before encoding the type information. One solution could be to have two interfaces, like
    
    type interface AssetGOB {
    // all functions except Binary(Unm|M)arshaler
    }

type interface Asset { AssetGOB encoding.BinaryMarshaler encoding.BinaryUnmarshaler }


and then require backends to implement `Asset` but use `AssetGOB` as the field type of assets in `Allocation` etc. The constructors like `NewAllocation` would still require `Asset` to make sure full `Asset` implementations are used but would then store the assets as `AssetGOB`s so that it can be used with `gob` encoding.

[This Go Playground example](https://go.dev/play/p/VNFyxE2WHQY) shows what happens if `gob.GobDecoder, gob.GobEncoder` is part of an interface (rename `Duck` to `DuckS` in the two lines mentioned in `main` to see the problem).