Skip to content
This repository was archived by the owner on Oct 14, 2022. It is now read-only.
This repository was archived by the owner on Oct 14, 2022. It is now read-only.

Block Propagation - Parallel Propagation #228

Description

@octavonce

In a scalable blockchain, arguably one of the most important aspects is the block propagation rate. Without an efficient block propagation mechanism, scalability cannot be achieved.

We initially intended to use Graphene as the block propagation mechanism as its aim is to solve one of the pain points of block propagation: transmitting less block data.

Problems with Graphene

The issue with Graphene is that it delivers what it promises under specific conditions that usually don't happen in practice i.e. peer's mempools being synchronised. Without this, Graphene performs worse than the classic propagation mechanism found in Bitcoin. This is because of the RTT incurred in recovery.

Another issue with Graphene, or rather with the classic propagation mechanism which Graphene inherited, is that propagation does not happen in parallel. When a block is initially propagated, peers must download the whole block, validate it and then propagate it further. This creates an intrinsic bottleneck when packets hop from one peer to another. The aim of Graphene is to optimise this bottleneck but it does not remove it.

Alternatives

There is only one other mechanism designed to remove the hop bottleneck is called FIBRE. It works by not waiting for block validation before propagating the raw block data. While this opens a DDOS vector, in practice it provides a much better throughput.

Purple Parallel Propagation - PPP

As such, we propose an alternative mechanism based on tried and tested methods. While not directly inspired by it, this method could be described as an extension of FIBRE and allows blocks to be propagated in parallel at a much faster rate while minimising the DDOS vector found in FIBRE.

The main inspiration behind PPP is the Bittorrent protocol and works as follows:

  • A block's transaction data will be a maximum of 2mb in size.
  • The transaction data is split into 256kb chunks, or pieces.
  • The block's header contains an 8byte hash of each piece.
  • Each piece is further divided into 16kb sub-pieces.
  • After receiving a block header, peers request missing pieces, prioritising the first piece of the block.
  • A peer will propagate a piece even if it doesn't have the rest of the block pieces.
  • When a peer receives the first piece in a block, it validates the root hash and the transactions in it.
  • Nodes will have 8 main peers and around 50-80 peers from which they download block data.
  • Nodes use a choking algorithm on peers from which they download block data.

While this mechanism still has room for improvement it bring several benefits:

  • Blocks are propagated in parallel.
  • A single peer's poor connectivity does not affect the rest of the network.
  • A much higher throughput.
  • No need for CTOR.
  • Almost no round-trips.

Metadata

Metadata

Assignees

No one assigned

    Labels

    d-hardAn issue of hard difficultyfeatureA feature to be implemented

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions