poldercast 4th layer: bottle in the sea

[NicolasDP]

This ticket describes the design of the 4th layer of the p2p discovery protocol of the network.

Bottle in the sea

The name self descriptif of the intent (and also of the limitations) of the 4th layer. A stake pool that enables the 4th layer will broadcast a special message on the network and will hope that other stake pools will find it and be able to read the content of message.

The content of the message will be the stake pool id and the updated IP address to contact that stake pool.

privacy concerns and mitigations

It is important to keep the privacy of the stake pool as much as possible. Here we consider 2 risks for a stake pool and the following mitigations:

• non stake pool, outsider of the protocol, will know the IP address of the stake pool and will be able to DoS or disrupt the stake pool. In order to prevent this the message is encrypted for a limited number of stake pools only. See below about the cryptographic protocol implemented for this;
• other stake pools could team against a specific stake pool to disrupt or disrupt the stake pool network. If this would happen, the stake pool could disable the 4th module and would not propagate its location in the bottle.

Overview

The idea is rather simple. A stake pool will gossip its location (IP/FQDN address) to the network. The content of the message (the location) is encrypted with shared asymmetric encryption to a list of stake pools. This message is then gossiped through the p2p network, hoping it finds a way to the expected stake pools. These stake pools can then decrypt the message and retrieve the other stake pool location for their 4th layer and connect to this node.

technical aspect and steps to build

There are some missing bits to implement in order to allow such thing to go through the network.

Shared asymmetric encryption with the VRF Public Key

• add shared asymmetric encryption with the VRF Pub Key [bottle in the sea]: add shared asymmetric encryption chain-libs#310

The stake pools we wish to contact are already all present in the ledger. They all published the necessary cryptographic material. We can use this in order to know exactly which stake pools we wish to contact.

new network end point

• add a new gRPC message for encrypted data to be gossiped; [bottle in the sea]: add grpc message and subscription chain-libs#311

There is going to be a need for some research for this, in order to allow backward compatibility and or add a separate command message on gRPC to allow for the custom gossips.

Message content

From the node side it's rather simple. To gossip the location:

1. select a number of stake pool ids and VRF public keys;
2. encrypt current location and stake pool id for these stake pools;
3. broadcast
4. hope selected stake pools receive the message

Upon receiving a gossip:

1. attempt to decrypt the message;
2. if does not decrypt go to 4
3. if decrypted, add the address in the 4th layer
4. store the gossip in a LRU Cache;
5. propagate the gossip

4th custom layer

Implement and add to the topology the 4th layer

It will require:

• a new module with its own runtime to drive the 4th layer operations: [bottle in the sea]: the layer driver #1979
• a new Poldercast Layer to populate the p2p view [bottle in the sea]: the 4th layer #1978

Configuration wise:

• enable the layer, we want to be able to say : no this node does not want to participate to this;
• have a blacklist of pool ids, to prevent sending a message to these pools;

[consuman]

Very cool idea!

One positive effect of an approach like this might be helping pools that were not ideally positioned, (eg. not in Asia/EU/US) to propagate their blocks better, when purposely connected to other pools like this. I like the idea of a human controlled additional layer and I think, better connected pools will also be better for the whole noetwork, since they all share their good connection to randomly connected pools.