Peers Communication

Peers communication serves a vital function within the Lisk network. The peering mechanisms provide the required architecture to facilitate network consensus, block propagation and transaction propagation.

System Headers

Within the Lisk network system headers are used to identify full nodes and provide a basic set of information about the software running on the system. During peers communications these headers are added to all messages sent between peers.

The following JSON object is generated from system data for this purpose and will be broadcast to the network during all communications:


Broadhash Consensus

Broadhash consensus serves a vital function for the Lisk network in order to prevent forks. In the DPoS system, delegates are assigned slots based on timestamp and will attempt to forge a block when the system designates that delegate slot as ready. Broadhash consensus ensures that a majority of available peers agree that it is acceptable to forge.

Broadhash is established as an aggregated rolling hash of the past five blocks present in the database. All peers with the same blocks will produce the same broadhash and propagate that information via the system headers described in section 8.1.

Block Propagation

Block propagation serves a vital function within the Lisk network. Blocks are made in a decentralized fashion and must be sent to all nodes found on the network in order to establish consensus. When a block is generated, it is broadcast to peers which broadcast that block to other peers. Without block propagation, the system would grind to a halt and the blockchain would cease to be functional.

Broadcast Queue

The broadcast queue serves a fundamental role for the Lisk network. Transactions must move from one node to all other nodes in order to be included in blocks. The broadcast queue works by grabbing up to 25 transactions from the transactions pool and aggregating them into a bundle. This bundle is then broadcast to the network on an interval, which is currently specified as every 5 seconds. In addition to broadcasting the object, the bundle is given a relay limit to prevent over broadcasting of data. In the current implementation the relay limit is set as 2, which means every bundle will be broadcast once from the originating node, and twice more from receiving nodes.

Transaction Pool

The transaction pool provides the Lisk network a very robust solution for preserving unconfirmed transactions that have overflowed into the next block. As mentioned in section 6, each block may only include 25 transactions and the transaction pool allows for up to 5.000 transactions to remain queued for the next block(s). The transaction pool could be thought of as a memory pool keeping transactions ready until they are signed into a block.

The second usage of the transaction pool is to provide a mechanism for propagating transactions. When a node prepares a transaction bundle, that node draws up to 25 transactions from the pool and performs validation on those transactions. These transactions are then broadcast to other nodes in a bundled JSON object. This can be represented as an array of objects of every transaction type listed in section 5

In order to keep the transaction pool tidy, all transactions are given a time to live. This time to live is defined as 10800 seconds, or 1080 blocks.

The final use for the transaction pool is to house transactions with pending signatures. These transactions with pending signatures following the same model as unconfirmed transactions. This way multisignature transactions that are isolated as incomplete within the transaction pool. Like unconfirmed transactions, these transactions will expire out of the pool based on the lifetime specified when the transaction is first generated.

What's next?