Explore: better ways to distribute new blocks

[erwin1]

Current situation:

When a new block is added, this procedure is followed:

• every connected peer will receive the block directly from the node publishing it

Problems with this:

• it doesn't scale well
• if a node is not connected directly to the build node, e.g. connected to another (build)node, it won't receive the new block (see diagram below)
• it might flood the network too much, why do all nodes need to be up-to-date all the time?
• if a node is offline/unreachable during a publication, it will miss out.

Proposed solution:

• Explore better ways to broadcast new blocks
• Maybe only build nodes should receive all the blocks immediately, regular nodes could simply work trigger based
• this trigger could be something periodic and/or when a user interacts with the node e.g. when pulling an artifact or when inspecting the log

[efrisch]

One recommendation from the libp2p team was implementing the ping protocol. Which is more of a heartbeat in libp2p. From here, "The ping protocol is a simple liveness check that peers can use to quickly see if another peer is online."

[efrisch]

Sorry, for this ticket, I meant graphsync should be investigated.

[betarelease]

Moving this to 0.2.2 since this is not going to be releasable in 2 weeks.

[erwin1]

It was discussed and decided to do this in several iterations:

1. one authorized node - many regular nodes: Replace the current block broadcast in the Blockchain Service with gossipsub #1345
2. one authorized node - many regular nodes: Keep blocks/logs up-to-date even if node missed out on new block messages #1346
3. a few authorized nodes - many regular nodes: Make sure this mechanism also works when there are multiple authorized nodes (simple consensus)
4. Multiple authorized/multiple regular nodes: Add real consensus mechanism

[betarelease]

Is this exploration done now? @efrisch