Skip to content
This repository has been archived by the owner on Jun 11, 2024. It is now read-only.

Latest commit

 

History

History
168 lines (111 loc) · 10.4 KB

lip-0060.md

File metadata and controls

168 lines (111 loc) · 10.4 KB
Raw
LIP: 0060
Title: Update genesis block schema and processing
Author: Iker Alustiza <[email protected]>
        Rishi Mittal <[email protected] >
Discussions-To: https://research.lisk.com/t/update-genesis-block-schema-and-processing/325
Status: Active
Type: Standards Track
Created: 2021-10-08
Updated: 2024-01-04
Requires: 0040, 0058, 0055

Abstract

This LIP adapts the specifications of the genesis block for blockchains created with Lisk SDK introduced in LIP 0034 to the requirements and characteristics of the new state model introduced in LIP 0040. It does so by following the general block format and processing introduced in LIP 0055.

Copyright

This LIP is licensed under the Creative Commons Zero 1.0 Universal.

Motivation

LIP 0034 introduced a block asset schema that allows to directly specify an initial state for blockchains created with Lisk SDK. However, with the specification of the Lisk interoperability solution and the new state model it introduces, it is necessary to redefine and update the format and processing of a genesis block for blockchains created with Lisk SDK.

Rationale

Usage of assets property of the block

The new genesis block format and processing is specified with the rationale of having a compact and self-contained way of initializing a blockchain in the Lisk ecosystem. With this in mind, this LIP defines a genesis block format and processing based on the specifications given in LIP 0055. In particular, the assets property contains the necessary information to initialize the state of the blockchain. Each element in the assets array contains the information necessary to set the state store for a given module. Hence, each module should define the format and processing logic for this information in the genesis block.

Processing of the genesis block

Another distinctive specification of the genesis block is its processing. The blockchain starts with an empty key-value store and in particular, all module stores are initially empty. As part of the genesis block processing modules can add key-value entries to their module store to initialize their state. They should also check the consistency of their state independently and against information provided by other modules. Also, before this is done, the framework layer has to validate the block header and the block format itself. Hence, this LIP defines steps specific to the processing of the genesis block: a step to initialize the state store per each module and the second step to verify this initial state. In particular the processing of the genesis block happens in the steps described in the sections below.

Figure 1: A schematic depiction of the steps of the processing of the genesis block.

Static validation

The genesis block has to go through initial static checks to ensure that the serialized object follows the general structure of a block. Also, certain properties of the block header are checked at this stage. All of these checks are stateless since the state of the blockchain is yet to be initialized. The key differences as compared to the validation for the rest of the blocks in a blockchain are that there is no specific size limit for the genesis block object and that the genesis block should not contain any transaction.

Before application processing

In this stage the consensus domain can initialize its store.

Genesis state initialization

At this stage, the genesis state initialization logic for all registered modules is executed. For this purpose, registered modules can specify processing logic considering the information in their corresponding entry of the assets property. Typically, modules will perform format and data consistency checks on their corresponding entry in assets and then initialize their state according to the data provided in it. However, modules should not call protocol logic of other modules as the state of the respective module may not be initialized.

Genesis state finalization

At this stage, the genesis state finalization logic for all registered modules is executed. As part of the genesis state finalization logic modules may call exposed functions from other modules to cross-check the state information integrity and/or complete their own state information. Once this step is completed, there should be a valid initial state ready for a blockchain to process state transitions implied by the next block.

After application processing

Block header properties, which require accessing the state store after all state transitions implied by the genesis block have been executed, are verified. Moreover, the consensus domain can define further logic that is executed in this step.

Block storage

The genesis block is persisted into the same database as other blocks.

Specification

In this section, we specify the schema for the genesis block and its validity and execution rules.

Constant

Name Type Value Description
EMPTY_HASH bytes SHA-256("") Hash of empty bytes.

Processing stages of the genesis block, block assets, and block header

As introduced in the Rationale section, the processing of the genesis block is performed in the following stages:

  • Static validation: The stateless checks that ensure the structure of the genesis block are performed. Also, the properties in the block header that do not require access to the state store are checked. These checks are defined in the sections below.
  • Before application processing: In this stage the consensus domain can initialize its store.
  • Genesis state initialization: The genesis state initialization logic for the registered modules is executed.
  • Genesis state finalization: The genesis state finalization logic for the registered modules is executed.
  • After application processing: The block header properties that require access to the state store are verified as specified below.
  • Block storage: The block is persisted into the database.

Genesis block

JSON schema

The genesis block schema is the same as the one defined in LIP 0055.

Validation

The genesis block is validated in the static validation stage as follows:

  • Static validation:
    • Check that the transactions property is set to its default value, i.e., empty array.

Block ID

The genesis block ID is computed in the same way as for any other block.

Assets property of the genesis block

JSON schema

The asset schema is the same as defined in LIP 0055.

Validation

The block assets property is validated as follows:

  • Static validation of the genesis block:
    • Each module can insert at most one entry in the block assets. Hence, check that each entry has a distinct module property. Note that in contrast to the block processing in LIP 0055, for the genesis block there is no limitation on the size of the data property.
    • Check that the entries are sorted by lexicographical order of module.
  • Genesis state initialization:
    • Check that each entry in the assets array has module corresponding to a module registered in the chain.
    • The individual entries are checked by the respective modules.

Header of the genesis block

JSON schema

The genesis block header schema is the same as the one for a block header of any other block defined in LIP 0055 .

Validation

The block header is processed as follows:

  • Static validation:
    • Check that the block header follows the block header schema.
    • The value b.header.version can be any uint32 integer.
    • The value of b.header.transactionRoot is equal to EMPTY_HASH.
    • The value b.header.assetRoot is validated as specified in LIP 0055.
    • The value b.header.timestamp is Unix time in seconds and can be any value in the uint32 range.
    • The value b.header.height can be any value in the uint32 range.
    • The value b.header.previousBlockID can be any 32-byte value.
    • The value of b.header.generatorAddress is equal to the constant zero address EMPTY_ADDRESS = 0x0000000000000000000000000000000000000000.
    • The value of b.header.maxHeightPrevoted is equal to b.header.height.
    • The value of b.header.impliesMaxPrevotes is equal to True.
    • The value b.header.maxHeightGenerated is equal to 0.
    • The value of b.header.aggregateCommit.height is b.header.height.
    • The value of b.header.aggregateCommit.signature is empty bytes.
    • The value of b.header.aggregateCommit.aggregationBits is empty bytes.
    • The value of b.header.signature is empty bytes.
  • After application processing:
    • Verify the stateRoot, eventRoot and validatorsHash properties as specified in LIP 0055.

Backwards Compatibility

This LIP defines a new block schema and processing, but does not imply a hardfork of Lisk Mainnet.

Reference Implementation