A block represents the atomic unit of a blockchain. The block in Kowala is the collection of relevant pieces of information - block header - together with information corresponding to transactions and the consensus election - block body.
Note that there are several hashes of the root nodes of trie structures in the block header. The purpose of this construction is to make the protocol light-client friendly in as many ways as possible. Example: TxHash hash allows an efficient and secure verification of the transactions that compose the block.
|Number||Number of ancestor blocks. The genesis block has a number of zero|
|Parent Hash||Hash of the previous block's header ("parent block")|
|Coinbase||Account registered by the validator(proposer) who's responsible for the block creation|
|Root||Hash of the root node of the state trie, after all transactions are executed and finalisations applied|
|TxHash||Hash of the root node of the trie structure populated with the transactions of the block|
|ReceiptHash||Hash of the root node of the trie structure populated with the receipts of each transaction that compose the block|
|Extra||Extra - an arbitrary byte array containing data relevant to this block|
|ValidatorsHash||Hash of the current set of validators for the current block|
|Time||Time at the block inception|
|Bloom||The bloom filter(space-efficient probabilistic data structure) for the logs of the block|
|Gas Limit||current limit of gas expenditure per block|
|Gas Used||Total gas used in transactions in this block|
Number, is particularly important for the sync operations - we rely on it to know if synchronisations are necessary. The number assumes more relevance in proof-of-stake compared to proof-of-work because the last one relies on difficulty, which means that there isn't block finality and the blockchain can fork. (https://github.com/kowala-tech/kcoin/blob/master/kusd/sync.go#L165)
Root, is especially important for the block validation. Example: As soon as non-validator nodes receive the block, they need to process the block, and the state root that results from the various state changes during the block processing must match the received root hash to make sure that we end up with the same state in the nodes across the network - https://github.com/kowala-tech/kUSD/blob/master/core/block_validator.go#L94.
TxHash, allows an efficient and secure verification of the transactions that compose the block.
In pratical terms, the Extra field, has been used for example during Ethereum's dao hard fork to allow fast/light syncers to correctly pick the side they want and is also used in the clique consensus (currently not available in this codebase) to include a signature. Kowala is not using this field at the moment but it can be useful in the future.
Time Kowala is currently using this value to synchronise the validators upon a new election round.
Bloom, allows anyone to efficiently search the blockchain for certain transactions (or watch new blocks for certain transactions). Example:
User who wants to know every single transfer of some specific ERC20 token. Checking the to address of all transactions ever as well as the data of that transaction, to see if calls transfer on this contract would take forever! Instead, because the ERC20 specification shoot of a log for every transfer, you can just search the blockchain for these logs!
GasLimit - defines the maximum amount of gas (computational effort) that all the trasactions included in the block can consume. Its purpose is to keep block propagation and processing time low. Note that this value in bitcoin is constant but it's variable in Ethereum.
GasUsed - The fact that the block can handle a certain limit does not mean that we will have enough transactions to fill the block.
The block body contains the set of transactions that were mined and consensus related elements.