Block
Batch of transactions appended to the blockchain.
A block is an ordered package of transactions and consensus data added to a blockchain. Each valid block references an earlier block, allowing nodes to reconstruct a shared history and current state. Block contents and production rules differ by network, but every node can independently check whether a proposed block follows its protocol.
The block header usually contains compact verification information. Bitcoin includes the previous block hash, a Merkle root committing to transactions, time, difficulty target, and proof-of-work nonce. Ethereum includes commitments to transactions, receipts, and resulting state, along with validator and gas information. These commitments let software detect any change to included data without placing every detail in the header.
A block producer selects transactions, orders them, and proposes a block. Bitcoin miners compete with proof of work, while proof-of-stake systems choose validators under their own consensus rules. Limited block space creates a fee market. Users who offer more competitive fees may receive faster inclusion, although block builders also consider transaction validity, dependencies, and potential MEV.
Blocks matter because they turn pending requests into recorded blockchain activity. A token transfer, contract call, or exchange deposit usually remains unconfirmed until included. Applications then wait for additional confirmations or protocol finality based on the value and risk involved. A displayed transaction status should distinguish pending, included, finalized, failed, and replaced states.
Inclusion does not always mean success. On smart contract networks, a transaction can be inside a valid block but revert during execution, consuming a fee without completing the intended action. A block explorer shows status, gas used, logs, and position. Users should verify the chain, block number, and transaction hash when investigating a payment or application error.
Competing blocks can briefly appear because information takes time to travel. Consensus rules determine which history becomes canonical, potentially reorganizing recent blocks. Finality mechanisms reduce or formally close this uncertainty. Developers should not rely on timestamps as precise clocks, assume blocks arrive at fixed intervals, or act on one confirmation for high-value transfers without assessing the network. A block is a verifiable unit of shared history, not an automatic guarantee that every contained action is permanent or successful.
Frequently asked questions
- A block commonly contains ordered transactions plus metadata needed for verification, such as a reference to its parent, timestamp, transaction commitment, and consensus information. Exact contents vary by network. Ethereum blocks include state and receipt roots, gas data, and validator fields, while Bitcoin blocks include a Merkle root, proof-of-work target data, and a coinbase transaction.
- Block timing depends on consensus design. Bitcoin targets an average of about ten minutes, but individual intervals vary. Ethereum uses twelve-second slots, although a slot can be missed. Faster block production can improve responsiveness while increasing propagation and reorganization challenges. Applications should use network-specific finality guidance instead of assuming one block means permanent settlement.
- Yes. A blockchain reorganization occurs when nodes replace recently accepted blocks with a competing valid chain or branch. Short reorgs can result from network timing, while deeper ones may indicate an attack or serious disruption. Transactions removed from a block may return to the pending pool or disappear. More confirmations generally reduce risk, depending on consensus and finality.