Seaport Gossip support

[Evalir]

Motivation

Recently Opensea released Seaport Gossip, a P2P network for sharing Seaport orders.

I wanted to build my own rust client for it as a toy project, but saw the conversation in the Discord about rather upstreaming these changes to Quay. I'd love to help if possible, and so I'd like to know if there have been any discussions / efforts related to this, or if ti's entirely out of scope for the repo. If we wanna proceed, we could use this issue to track the changes needed.

[0xAlcibiades]

Let's do it. Any proposal on where to start?

[0xAlcibiades]

So it does seem like this makes sense, we could add a quay-gossip binary which acts as a client for the seaport gossip network.

[Evalir]

Alright, so after stubbing some things, here's the tasks. It's not 100% exhaustive as many of the seaport gossip functionalities in the reference implementation are still unfinished/unclear:

• [ ] Tests (for each module, and integration tests, ideally set up a seaport gossip JS node and a quay gossip node)
• [ ] Add SSZ encoding/decoding for types, and add missing (mostly protocol-specific) types. We might have to modify existing types or we could just create new ones. We might have to add new types if the JSON encoding they use is different to our types as well.
• [x] Add the ability for the node to add bootstrap peers
• [x] Implement protocol messages in the SeaportGossipBehaviour:
  • [x] GetOrders
  • [x] Orders
  • [x] GetOrderHashes
  • [x] OrderHashes
  • [x] GetOrderCount
  • [x] OrderCount
  • [x] OrderCount
  • [x] GetCriteria
  • [x] Criteria
• [ ] Implement Seaport's message ID fn (https://github.com/ProjectOpenSea/seaport-gossip/blob/main/src/util/serialize.ts#L18-L29)
• [ ] Gossipsub event encoding/decoding (https://github.com/ProjectOpenSea/seaport-gossip/blob/9f50fcf9bdd039e8058449e9dab0fcef4c077b17/src/util/serialize.ts#L100-L109)
• [ ] Metrics
• [ ] Track Seaport's DHT integration/implementation and mirror changes on Quay
• [ ] Validation (already tracked at #27)

[0xAlcibiades]

@Evalir about SSZ, most types should already exist https://lighthouse-docs.sigmaprime.io/ssz/index.html

About JSON encoding, I don't know that our gossip node needs to worry about json, as we have the server to perform any database queries. Is there some other reason why it'll need to encode/decode json? Everything over the wire should be SSZ.

[Evalir]

Right, i meant ssz encoding/decoding for the seaport types we currently have, using ssz_derive.

For JSON encoding, i'm just still unsure if they encode the types into a different json structure—and if so then we'd need new types for that intermediate structure.

[0xAlcibiades]

I don't think they are using any json once it's in the network, so shouldn't be a concern.