Block Information

Overview

Block

A single element of a blockchain that cryptographically binds a set of extrinsic data (the "body") to a "header". Blocks are arranged into a tree through parent pointers (implemented as a hash of the parent)

A block is composed of a header and an array of extrinsics. The header contains a block height, parent hash, extrinsics root, state root, and digest.

Light Client

A light client is a type of blockchain node that does not store the chain state or produce (author) blocks. It encapsulates basic capabilities for verifying cryptographic primitives and exposes an RPC (remote procedure call) server to allow blockchain users to interact with the blockchain network.

Full Client

A node that is able to synchronize a blockchain in a maximally secure manner through execution (and thus verification) of all logic. Full clients stand in contrast to light clients.

Description

Extrinsic

An extrinsic is a piece of information that comes from outside the chain and is included in a block. Extrinsics fall into three categories: inherents, signed transactions, and unsigned transactions.

Inherents

• Inherents are pieces of information that are not signed and only inserted into a block by the block author. They are not gossiped on the network or stored in the transaction queue.

• The author of the block may insert a timestamp inherent into the block. There is no way to prove that a timestamp is true as the way the desire to send funds is proved with a signature. Rather, validators accept or reject the block based on how reasonable the other validators find the timestamp, which may mean it is within some acceptable range of their own system clocks.

Signed transactions

• Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on the chain.

• Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam.

Unsigned transactions

• Unsigned transactions contain no signature and nobody is to pay a fee.

• Unsigned transactions also lack a nonce, making replay protection difficult. A few transactions warrant using the unsigned variant, but they will require some form of spam prevention based on a custom implementation of signed extension, which can exist on unsigned transactions.

Header

A structure that is used to aggregate pieces of (primarily cryptographic) information that summarize a block. This information is used by all clients, however, light-clients use this to get a minimally-secure but very efficient synchronization of the chain. The header contains the following components:

Digest: An extensible field of the block header that encodes information needed by several actors in a blockchain network including, light clients for chain synchronization, consensus engines for block verification, and the runtime itself in the case of pre-runtime digests.

State: In a blockchain, the state refers to the cryptographically secure data that persists between blocks and can be used to create new blocks as part of the state transition function. In Glitch-based blockchains, the state is stored in a trie, a data structure that supports the efficient creation of incremental digests. This trie is exposed to the runtime as a simple key/value map where both keys and values can be arbitrary byte arrays.

Block height: The order number of the block

Parent height: The hash value of the node parent

Extrinsics root: The extrinsics root is a cryptographic digest of this series. This serves two purposes. First, it prevents any alterations to the series of extrinsics after the header has been built and distributed. Second, it provides a means of allowing light clients to succinctly verify that any given extrinsic did indeed exist in a block given only knowledge of the header.