Blocks

The diagram below illustrates the structure and properties of blocks in the Lisk protocol. A block is composed of a header and an array of transactions, where every transaction follows the schema described in the Transactions section. Similar to transactions, the block header contains an asset property which may differ depending on the value of the version property. In the following, we describe all block properties in more detail.

block

Block time

In the Lisk protocol, time is divided into slots of 10 seconds. This interval is called a block slot and at most one block can be added to the blockchain during each slot. The length of a block slot is also called the block time.

Block forgers

During each block slot, one delegate account has the right to add a new block to the blockchain. This delegate will select valid transactions from their transaction pool and use them to create the block payload. The delegate will then generate the block header and sign it with their private key. The block is then propagated over the network. When receiving blocks, nodes will verify that the block is signed by the appropriate delegate.

Block payload

The block payload is an array of transactions. The transactions in the payload are considered as included in the blockchain once the block has been added to the blockchain. The Merkle tree root of this array is computed and included in the block header in the transactionRoot property.

When updating the account state with a block, the transactions in the payload are applied sequentially in the order they are given in the payload. This order is also used to assert the validity of the payload. Indeed, transactions have to be valid with respect to the blockchain state obtained by applying all previous blocks and all previous transactions in the payload.

In the Lisk protocol, the payload size is limited to 15 KiB (15 x 1024 bytes).

Block header

The block header is generated by the block forger after the block payload. It is composed of the properties detailed in subsections below.

version

The version of the block represents the version of the protocol used by this block.

timestamp

A Unix timestamp of when the block is created by the block producer. This timestamp is used to determine for which block slot the block is created.

previousBlock

The ID of another block. This property is used to identify the parent block, the block on which this block is built.

height

The default height for the genesis block is 0. For every other blocks, it is the height of the parent block plus one.

transactionRoot

The Merkle root of the payload.

generatorPublicKey

The public key of the delegate who generated the block.

reward

The reward received by the delegate who generated the block. The value of the reward is described in the section Rewards and fees.

signature

The signature of the block. This signature has to be generated by the private key associated to generatorPublicKey. This signature scheme is described in the Appendix.

asset

This property is used to store information regarding the chain that is not necessarily present on all chains created with the SDK. By default, the block asset for a block with version equal to 1 contains the three properties below:

  • maxHeightPreviouslyForged: The maximum height at which the public key in generatorPublicKey forged a block, see Consensus votes on blocks and fork choice rule for more details.

  • maxHeightPrevoted: The maximum height on the chain which has received 68 prevotes, see Consensus votes on blocks and fork choice rule for more details.

  • seedReveal: A pseudo random value used for generating on-chain randomness. To receive the full block reward, the hash of this value has to be the value the forging delegate included in the seedReveal property of the last block they forged. See LIP 0022 for more details.

Block ID

The block ID is obtained by hashing the serialized block header.

Rewards and fees

Delegates receive a reward for generating a block. The amount of reward depends on the block height according to the table shown below:

Heights

Reward

From 1,451,520 to 4,451,519

5 × 108

From 4,451,520 to 7,451,519

4 × 108

From 7,451,520 to 10,451,519

3 × 108

From 10,451,520 to 13,451,519

2 × 108

From 13,451,520 onwards

1 × 108

In Lisk Mainnet this corresponds to rewards of 5 LSK, 4 LSK, 3 LSK, 2 LSK and 1 LSK.

Fees

Transactions also include fees. The unburned part of the fee is added together with the block reward to the balance of the delegate forging the block. This is done after all transactions in the payload have been applied. It should be noted that a delegate cannot receive and spend the reward in the same block.

Reduced block reward

The table above shows the default block reward values. However, the Lisk protocol defines specific situations related to the Lisk-BFT protocol or the commit-reveal scheme in which the block reward is lower.

Projected token supply

Blockchains following the Lisk protocol do not have a bounded token supply. For every block forged, the amount of available tokens increases. This increase is obtained by subtracting the burned fees from the block reward.

Genesis block

The first block of the blockchain, the genesis block, has version 0 and a different asset property than the block described above. More specifically, the block asset of the genesis block contains the following three properties:

  • accounts: The value for this property is an array of accounts following the schema defined in LIP 0030. It can be used to define the desired initial distribution of tokens when starting a new blockchain.

  • initDelegates: The value for this property is an array of delegate addresses. This array must contain at least one value and not more values than the length of a round. It defines the forging delegates for a bootstrap period during which users can register delegates and start voting.

  • initRounds: The value of this property is an integer that is at least 3. It defines the number of rounds that the delegates given in initDelegates are the forging delegates. Afterwards, the forging delegates are selected as defined in the section Consensus Algorithm.

Additionally, the timestamp value should be the Unix time in seconds that is supposed to be the starting time of the blockchain, previousBlockID should be the the SHA-256 (Secure Hash Algorithm 256), hash of the empty string and the value of height is supposed to be 0. All other properties have certain default values that are defined in LIP 0034.