Block

A block is a collection of transactions and contains the hash of the previous block in the chain. This links the blocks together (a chain), since the hash is encrypted from the block data. This prevents fraud because any change in any previous block will invalidate all subsequent blocks, and all hashes will change, and everyone running the blockchain will notice.

Prerequisite

Blocks is a very beginner-friendly theme. To help you better understand this page, we recommend that you first read Accounts, Transactions and our Introduction to Hash Ahead.

Why are there blocks?

To ensure that all participants on the Hash Ahead network stay in sync and agree on the exact history of transactions, we divide transactions into blocks. This means that dozens (or even hundreds) of transactions are committed, agreed upon, and synchronized at the same time.

By committing at intervals, all network participants have enough time to reach consensus: even though transaction requests occur dozens of times per second, blocks on Hash Ahead are created and committed every twenty seconds.

How blocks work

To preserve transaction history, blocks are strictly ordered (each new block created contains a reference to its parent block), and transactions within a block are also strictly ordered. With rare exceptions, at any given time, all participants on the network agree on the exact number and history of blocks, and are working to batch current active transaction requests to the next block.

After a validator builds a block on the network, the block is propagated throughout the network; all nodes add the block to the end of their blockchain and pick a new validator to create the next block. Currently, the exact block building process and submission/consensus process is dictated by Hash Ahead's "Delegated Proof of Stake" protocol.

Delegated Proof of Stake Protocol

Delegated Proof of Stake means：

• The verification node must pledge 100,000 HAH to the deposit contract as collateral to prevent bad behavior. This helps secure the network, as some or even all staked amounts will be destroyed if dishonest activity occurs and can be proven.

• In each slot (20 second intervals), a validator is randomly selected as the block proposer. They package and execute transactions, and then determine a new "state". They wrap this information into a block and send it to other validators.

• Other validators who learned of the new block execute the transactions contained in the block again, making sure they agree with the proposed changes to the global state. Assuming the block is valid, validators add the block to their respective databases.

• If a validator learns that there are two conflicting blocks in the same slot, they use their fork selection algorithm to choose the one with the most staked HAH support.

More on Delegated Proof of Stake

What does a block contain?

A block contains a lot of information. The top level of a block contains the following fields:

slot: the time slot to which the block belongs
proposer_index: ID of the validator who proposed the block
parent_root: the hash of the previous block
state_root: the root hash of the state object
body: an object containing some fields, defined as follows

The body of a block contains some own fields:

randao_reveal: the value used to select the next block proposer
eth1_data: Information about the deposit contract
graffiti: Arbitrary data used to mark blocks
proposer_slashings: list of validators that will be slashed
attester_slashings: list of validators that will be slashed
attestations: a list of certifications that support the current block
deposits: list of new deposits deposited into the deposit contract
voluntary_exits: list of validators who will exit the network
sync_aggregate: subset of validators used to serve light clients
execution_payload: the transaction sent by the execution client

attestations field contains a list of all authentications in the block. Authentication has its own data type, which contains multiple pieces of data. Each certification includes:

aggregation_bits: list of validators participating in this certification
data: a container with multiple subfields
signature: the aggregated signature of all attesting verifiers

The data field in attestation contains the following:

slot: time slot involved in authentication
index: the index of the proof verifier
beacon_block_root: the root hash of the beacon chain block containing this object
source: last reasonable checkpoint
target: the latest time period boundary block

Executing the transaction in execution_payload updates the global state. All clients re-execute the transaction in execution_payload to ensure that the new state matches the state in the state_root field of the new block. This is how a client can tell if a new block is valid and safe to add to its blockchain. The execution payload itself is an object with several fields. There is also an execution_payload_header that contains important summary information about the execution data. These data structures are organized as follows:

execution_payload_header Contains the following fields:

parent_hash: the hash of the parent block
fee_recipient: the account address to receive the transaction fee
state_root: the root hash of the global state after applying the changes in this block
receipts_root: Hash of the transaction receipt tree
logs_bloom: data structure containing event logs
prev_randao: The value used when randomly selecting validators
block_number: the number of the current block
gas_limit: the maximum amount of gas allowed in this block
gas_used: the amount of gas actually used by this block
timestamp: block time
extra_data: any additional data as raw bytes
base_fee_per_gas: the value of the base fee
block_hash: hash of the execution block
transactions_root: the root hash of the transactions in the payload

execution_payload itself contains the following fields (these are the same as the header fields, except that instead of the transaction's root hash it contains the actual transaction list):

parent_hash: the hash of the parent block
fee_recipient: the account address to receive the transaction fee
state_root: the root hash of the global state after applying the changes in this block
receipts_root: Hash of the transaction receipt tree
logs_bloom: data structure containing event logs
prev_randao: The value used when randomly selecting validators
block_number: the number of the current block
gas_limit: the maximum amount of gas allowed in this block
gas_used: the amount of gas actually used by this block
timestamp: block time
extra_data: any additional data as raw bytes
base_fee_per_gas: the value of the base fee
block_hash: hash of the execution block
transactions: list of transactions to execute

Block time

The block time refers to the time interval between two blocks. In Hash Ahead, time is divided into units every 20 seconds, called "slots". Within each slot, a single validator is chosen to propose a block. Assuming all validators are online and fully operational, there will be one block generated per slot, meaning a block time of 20 seconds.

Block size

One last important note is that the size of the block itself is bounded. Each chunk can be up to 2MB in size. The size of all transactions in a block must be below the block size limit. This is important because it ensures that blocks cannot grow arbitrarily large. If blocks can be expanded arbitrarily, due to space and speed requirements, full nodes with poor performance will gradually be unable to keep up with the network. The larger the blocks, the more computing power it will take to process them in time for the next slot. This is an element of centralization that can be counteracted by limiting the block size.

\