Skip to content

Node Implementation - Blocks

Part of work in progress Living Whitepaper

This page is part of the Living Whitepaper revisions currently underway to replace the original static whitepaper. These efforts include the Protocol Design and Node Implementation sections of the docs, which will cover and expand on details and topics covered in the original whitepaper.

See the bottom of the page for related whitepaper sections and other related details. Some of the sections and headers on this page may be in draft form or just suggestions/framework for later consideration. If you are interested in helping with revisions please connect with us on the #documentation channel on our Discord server.

Block publishing and propagation

Nodes use a modified gossip protocol for message distribution that enables quick distribution of blocks and votes across the network while distributing the load required to propagate messages across multiple nodes rather than each node having to respond to requests from every other node. Prioritization of messages are focused on the Principal Representative nodes that make up the core consensus mechanism where they receive blocks and votes directly from other nodes and then messages are spread to the rest of the network via gossiping.

Blocks are initially broadcast and propagated across the network to different types of nodes based on the blocks status. Some basic rules are listed below:

  • Nodes initially publish new blocks on the live network to all Principal Representatives they can connect to and a subset of Non Principal Representative nodes.
  • When a node processes a new block that is not a known fork, or is a known fork and the block becomes the new winner on an election, nodes will republish that block to sqrt(peers).

On average, this gossiping results in blocks arriving multiple times at each node. To help reduce node resource usage, there are duplicate block filters in place to prevent reprocessing of the same blocks.