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
In the following, we describe all block properties in more detail.
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.
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.
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
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).
The block header is generated by the block forger after the block payload. It is composed of the properties detailed in subsections below.
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.
The ID of another block. This property is used to identify the parent block, the block on which this block is built.
The default height for the genesis block is
For every other blocks, it is the height of the parent block plus one.
The reward received by the delegate who generated the block. The value of the reward is described in the section Rewards and fees.
The signature of the block.
This signature has to be generated by the private key associated to
This signature scheme is described in the Appendix.
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
generatorPublicKeyforged 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
seedRevealproperty of the last block they forged. See LIP 0022 for more details.
The block ID is obtained by hashing the serialized block header.
Delegates receive a reward for generating a block. The amount of reward depends on the block height according to the table shown below:
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.
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.
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
initDelegatesare the forging delegates. Afterwards, the forging delegates are selected as defined in the section Consensus Algorithm.
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
All other properties have certain default values that are defined in LIP 0034.