Manage multiaddrs between DKG and post-DKG

[CluEleSsUK]

When running an ADKG, we provide a multiaddr in the group file for other nodes to connect to us. This same multiaddr is filled into the keyshare.pub file created by the ADKG.

Most dcipher nodes are using this same multiaddr for operating their verifier nodes. This means, if we wish to run another DKG (using the same multiaddrs), they will have to turn off the verifier binary which could cause downtime.

Here are a few pros and cons of different ideas:

rewrite the config file multiaddrs before running a verifier
This is the most flexible, though relies on committee members typing things in correctly/reading the latest slack message/etc. A committee member forgetting to tell us a new multiaddr could cause downtime, and versions of configs get confusing fast.

allow output of a different "listening" port
This would allow committee members to define a "dkg hostname" and a "post-dkg hostname". It'd be convenient for the verifier use case, but in a future world we may want to run multiple binaries using the same keyshare.pub so this wouldn't solve the problem entirely.

multiplexing of libp2p connections
I'm not sure how possible this is, but if we could multiplex different libp2p connections/protocols/messages onto different hosts, everything would be solved. This is easy in HTTP land by just using different contexts, but I'm not sure it's so easy with libp2p

Open to other ideas

[CluEleSsUK]

another solution: One Binary To Rule Them All 💍

[azixus]

multiplexing of libp2p connections
this doesn't seem to be possible natively. we'd need to design some sort of proxy that uses libp2p and then uses some other communication protocol (or, well, a second libp2p layer) to send the messages to the internal nodes.

allow output of a different "listening" port
I think short term this is probably the way to go - we require two ports, one for upcoming DKGs, and one for onlyswaps.

A mid-term solution might be to run the rendezvous on our own nodes. It's essentially just a hub where nodes can register their peerid / addresses.

So if you end-up running DKG & onlyswaps on different nodes / ports, it should just be invisible, as long as our rendezvous node is stable. We wouldn't even need to have a list of addresses for onlyswaps, just a list of peer ids. Main disadvantage is that it's a centralized protocol.

Long-term, we should have a persistent service for networking (either separate, or as part of the dcipher daemon / binary). We already have the big building blocks implemented: topic-based messaging for multiplexing + libp2p. We need to add:

• message replays / fetch past messages
• allow to send / receive messages through a socket if we keep adkg separate,
• or we go for a single binary that runs various services (onlyswap), and accepts various commands (adkg)

[CluEleSsUK]

Would this imply a need for different peerids for DKG and verifier then? because even if we used a rendezevous server, presumably looking for the peerid in the group file could still end up routing partial signing requests to the DKG binary, and/or DKG packets to the verifier binary

[azixus]

In theory we can use the same peerid, but use different topics and the messages will just get ignored on the recipient side of things. It'll increase the network communication when both the DKG and onlyswaps are both running since subscriptions are only peerid based, but otherwise it should be the same.

[CluEleSsUK]

ahh I see, so each binary will pick up all the messages, but drop those not on the topic it cares about?
this seems like a reasonable tradeoff as our network traffic isn't crazy rn anyway

[azixus]

yeah, exactly