New Block Header and Block Asset Schema

Hello everyone,

I would like to propose a new LIP for the roadmap objective “Update block header format.” This LIP covers all changes to the block header schema and block asset schema introduced by several other LIPs.

I’m looking forward to your feedback.

Here is the complete LIP draft:

LIP: <LIP number>
Title: New Block Header and Block Asset Schema
Author: Andreas Kendziorra <andreas.kendziorra@lightcurve.io>
Type: Standards Track
Created: <YYYY-MM-DD>
Updated: <YYYY-MM-DD>
Requires: State model and state root, Introduce a certificate generation mechanism, Add BLS and forging public key to validator account

Abstract

This LIP introduces changes to the block header and block asset schema that are required by several other LIPs.

Copyright

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

Motivation

The State model and state root LIP, the Add BLS and forging public key to validator account LIP and the Introduce a certificate generation mechanism LIP introduce new properties that need to be contained in a block header or its asset property. This LIP intends to specify all required updates to the corresponding schemas in one place.

Rationale

This LIP introduces the following new block header properties:

  • stateRoot: The root of the sparse Merkle tree that is computed from the state of the blockchain. See the State model and state root LIP to see why it needs to be included in a block header.
  • generatorAddress: The address of the block forger. It replaces the generatorPublicKey property. See the Add BLS and forging public key to validator account LIP for more details.
  • validatorsHash: A commitment to the set of active validators at the next height. A certificate derived from a block contains this property, and its purpose is to attest the set of active validators for the next block. See also the chain of trust section of the Introduce a certificate generation mechanism LIP for more details.

Moreover, the following property is added to the block asset schema:

  • aggregateCommits: It contains an aggregate signature for a certificate for a certain block height. Based on this, any node can create a certificate for the corresponding height. See the Introduce a certificate generation mechanism LIP for more details.

Specification

New Block Header Schema

The block header schema is extended by the properties stateRoot and validatorsHash. Moreover, the generatorPublicKey is replaced by generatorAddress. The new schema looks as follows:

blockHeaderSchema = {
  "type": "object",
  "properties": {
    "version": {
      "dataType": "uint32",
      "fieldNumber": 1
    },
    "timestamp": {
      "dataType": "uint32",
      "fieldNumber": 2
    },
    "height": {
      "dataType": "uint32",
      "fieldNumber": 3
    },
    "previousBlockID": {
      "dataType": "bytes",
      "fieldNumber": 4
    },
    "transactionRoot": {
      "dataType": "bytes",
      "fieldNumber": 5
    },
    "generatorAddress": {
      "dataType": "bytes",
      "fieldNumber": 6
    },
    "reward": {
      "dataType": "uint64",
      "fieldNumber": 7
    },
    "stateRoot": {
      "dataType": "bytes",
      "fieldNumber": 8
    },
    "validatorsHash": {
      "dataType": "bytes",
      "fieldNumber": 9
    },
    "asset": {
      "dataType": "bytes",
      "fieldNumber": 10
    },
    "signature": {
      "dataType": "bytes",
      "fieldNumber": 11
    }
  },
  "required": [
    "version",
    "timestamp",
    "height",
    "previousBlockID",
    "transactionRoot",
    "generatorAddress",
    "reward",
    "asset",
    "stateRoot",
    "validatorsHash"
  ]
}

New Block Asset Schema

The block asset schema is extended by the property aggregateCommit. This property is of type object and its schema is defined in the Introduce a certificate generation mechanism LIP. The new block asset schema looks as follows:

blockAssetSchema = {
  "type": "object",
  "properties": {
    "maxHeightPreviouslyForged": {
      "dataType": "uint32",
      "fieldNumber": 1
    },
    "maxHeightPrevoted": {
      "dataType": "uint32",
      "fieldNumber": 2
    },
    "seedReveal": {
      "dataType": "bytes",
      "fieldNumber": 3
    },
    "aggregateCommit": {
      "type": "object",
      "properties": {
        "height": {
          "dataType": "uint32",
          "fieldNumber": 1
        },
        "aggregationBits": {
          "dataType": "bytes",
          "fieldNumber": 2
        },
        "signature": {
          "dataType": "bytes",
          "fieldNumber": 3
        }
      },
      "required": [
        "height",
        "aggregationBits",
        "signature"
      ],
      "fieldNumber": 4
    }
  },
  "required": [
    "maxHeightPreviouslyForged",
    "maxHeightPrevoted",
    "seedReveal",
    "aggregateCommit"
  ]
}

Computation of validatorsHash

The value of validatorsHash for height h is computed by taking the SHA-256 hash of the serialized validators object for height h according to the schema validatorsSchema defined below. The validators object for height h has the following properties:

  • keys: The BLS public keys of the active validators at height h in lexicographical order.
  • weights: The corresponding weights for the public keys in keys at height h.
  • certificateThreshold: The certificate threshold at height h.
validatorsSchema = {
  "type": "object",
  "properties": {
    "keys": {
      "type": "array",
      "fieldNumber": 1,
      "items": {
        "dataType": "bytes"
      }
    },
    "weights": {
      "type": "array",
      "fieldNumber": 2,
      "items": {
        "dataType": "uint64"
      }
    },
    "certificateThreshold": {
      "dataType": "uint64",
      "fieldNumber": 3
    }
  },
  "required": [
    "keys",
    "weights",
    "certificateThreshold"
  ]
}

New Validity Rules

A block b must fulfill the following new rules in order to be valid:

  • b.header.generatorAddress must have a length of 20 bytes.
  • There must be a validator account validatorAccount corresponding to b.header.generatorAddress.
  • validatorAccount must be the validator account that is assigned to the block slot corresponding to b.header.timestamp.
  • b.header.signature must be a valid signature with regard to the forging key of validatorAccount.
  • b.header.validatorsHash must be the validators hash for height b.header.height+1. The weights and certificate threshold must also be the ones for height b.header.height+1.
  • b.header.stateRoot must be the root of the state tree after processing b.
  • validateAggregateCommit(b) must return true.

Block Version

The block version value needs to be incremented. That means, for a block b according to this protocol, the value of b.header.version must be equal to the value of a block of the previous protocol plus one.

Backwards Compatibility

This LIP results in a hard fork as nodes following the proposed protocol will reject blocks according to the previous protocol, and nodes following the previous protocol will reject blocks according to the proposed protocol.

2 Likes