Consider service nodes as homogenous and dynamically select them for keygen and signing

[josephawallace]

Description

The participating service nodes of a keygen or signature function are selected by the client. Up to this point, that party of nodes was considered the owner of the key. However, with the upcoming changes to authorization, they resource owners will be specified in an access control policy. Therefore, there is no reason for a client to make the decision on what nodes will perform the actual work of computing a new key or signature, since that is inconsequential. Seeing that the service nodes do not need to distinguish themselves, they should be selected dynamically, as appropriate.

Todo

• Remove the need to specify service nodes in keygen and signing
• Introduce a way for nodes to select each other

[josephawallace]

How do you handle the difficulty in distinguishing clients, bootstraps, and service peers?

• Don't—just dial random peers and if one doesn't support the protocol, move to the next
• Keep a local (perhaps refreshing) datastore of peers that support certain protocols
• Use pid, err := client.Host.Peerstore().FirstSupportedProtocol(peerId, protocols.KeygenPId) to determine whether a peer supports a protocol (in this example keygen). You can do this for all peers in a peer store to get the list of service peers. From there, the peers can be selected randomly.

[josephawallace]

How do you keep track of which service nodes hold which keys?

• Keep a shared database between the nodes that hold network information that can be retrieved by the clients. This will include which service nodes were responsible for creating which keys (and hence where the keys are stored).
• Keep a pubsub channel for nodes to listen to. Request details sent to a node should be published to the channel so any nodes needed to fulfill the request will be able to respond. They will know that they should participate based on what they have in their local databases. If they input something wrong for TSS, there should (need to confirm) be an error and the bad nodes will be listed as culprits.
• The client will dynamically select the service nodes and include the designated party in the args. The nodes will each store the party details with the key save. The ID for the key will be specified by the client when making the request. Consider a central database for keyIDs and the like.

[josephawallace]

Peer-side KV store will map: publicKey ---> keygenSaveData Client-side KV store will map: keyName ---> publicKey (assigned by user) / publicKey ---> metadata (returned from keygen)

Therefore, on signing, you only need to specify the key name. The client will retrieve the the public key, then the metadata (which contains the party of nodes) and form a complete request. The main work here is getting the data to be returned from a keygen protocol and saving it properly with the client.

The client should send the requests over streams - ended up that I don't want to use pubsub channels because every node gets blue-balled when they have to check their databases just to see that they don't have the key.