SuperEx Educational Series: Understanding How Is a New Block Actually Created

#SuperEx #EducationalSeries #Block

Many people say “a blockchain keeps producing blocks,” as if the system automatically prints blocks in the background.

Reality is not that simple. A new block does not appear from nowhere. Someone must collect transactions, order them, execute them, calculate results, construct the block, broadcast it, and then other nodes must verify it. In plain English: a block is not just “generated.” It is homework that the whole network can check.

This article explains how a new block is actually created.

What Is a New Block?

A new block is the next valid batch of data attached to the current head of the chain.

It usually contains several things: parent block hash, transaction list, timestamp, block height, fee information, consensus-related data, and commitments to the resulting state after execution. In Ethereum, the execution payload includes transactions, state root, receipts root, transactions root, gas used, base fee, and more.

So a new block is not merely a “bundle of transactions.” It must answer: which block do I follow, which transactions do I include, what state results from executing them, and do I satisfy the chain’s consensus rules?

In one sentence: a new block is “a transaction batch + state result + consensus proof/signature + historical link.”

Why Do Blockchains Need Blocks?

If every transaction had to be confirmed individually by the whole network, coordination would be difficult. Blocks package transactions from a period of time into an ordered, result-producing, verifiable unit.

• Blocks give transactions order.
• Blocks create boundaries for state changes.
• Blocks allow nodes to synchronize history.
• Blocks let consensus judge whether this batch of transactions is valid.

That is why a blockchain is not just a stream of transactions. Blocks turn scattered transactions into verifiable history.

How Is a New Block Created?

First, transactions enter the transaction pool.

After users sign transactions, they send them to nodes through RPC. Nodes check signatures, nonces, balances, and gas parameters. If basically valid, the transactions enter the local mempool and are propagated.

Second, a block producer is selected.

Different chains choose block producers differently. Bitcoin uses proof-of-work, where miners compete to find a block hash below the difficulty target. Ethereum proof-of-stake randomly selects a validator as block proposer for each slot.

Third, the block producer selects transactions.

The producer chooses transactions from the pool, usually considering fees, gas limits, nonce order, executability, and MEV. Do not assume the first transaction in the pool always gets included first. Reality is less innocent.

Fourth, transactions are executed and state is calculated.

In Ethereum, the execution client executes transactions in order, runs the EVM, updates balances, nonces, contract storage, and produces a new state root and receipts root.

Fifth, the block is constructed.

The block includes parent block hash, transaction list, state root, receipt root, timestamp, gas information, and more. A Bitcoin block includes a coinbase transaction, normal transactions, Merkle root, nonce, difficulty target, and other header fields.

Sixth, the new block is broadcast.

The producer sends the block to the network. In Ethereum, the consensus client gossips the block through the consensus P2P network. In Bitcoin, once a miner finds valid proof-of-work, the completed block is broadcast to other nodes.

Seventh, other nodes verify it.

Other nodes do not simply trust the producer. They verify the parent block, transaction validity, state transition, block structure, and consensus rules. Only then do they attach the new block to their local chain.

Ethereum PoS Case

Ethereum now uses proof-of-stake. A full node usually includes an execution client and a consensus client. To participate in validation, it also needs a validator client.

The execution client handles the transaction pool, EVM execution, state management, and RPC. The consensus client handles consensus logic, block gossip, fork choice, and finality. Validators propose blocks and make attestations.

When a validator is selected as proposer for a slot, it requests transaction data from the execution client. The execution client selects transactions from the pool, executes them, and creates an execution payload. The consensus client places that payload into a beacon block and broadcasts it.

Other nodes receive the block, re-execute transactions, and check whether the state root matches. If it matches, their independently computed result agrees with the block’s claim. Validators then attest to the chain head they accept. With enough validator votes, the block gains stronger confirmation and eventually enters finalized history.

In plain words: an Ethereum block is not accepted just because one validator wrote it. It is proposed, executed, broadcast, re-verified, and voted on.

Bitcoin PoW Case

Bitcoin block creation is more like a global computation contest.

Miners select transactions from the mempool, create a coinbase transaction, organize transactions into a Merkle tree, and calculate the Merkle root. Then they construct a block header containing version, previous block hash, Merkle root, time, nBits, and nonce.

Then comes proof-of-work. Miners keep changing the nonce or extra nonce in the coinbase transaction and repeatedly hash the block header until they find a hash below the target threshold. There is no shortcut; it requires many attempts.

Once a valid hash is found, the miner broadcasts the full block. Other nodes check: does the proof-of-work meet difficulty, is the parent block correct, are transactions valid, is the coinbase reward valid, and does the Merkle root match? If so, they accept the block.

Bitcoin’s security comes from the fact that modifying history requires redoing the proof-of-work for that block and following blocks. The deeper a block is, the more expensive it is to rewrite.

What Is Inside a Block?

First, parent block hash.

It tells nodes which block this one follows. Without this link, there is no chain.

Second, transaction data.

A block contains a batch of transactions. Bitcoin organizes transaction hashes into a Merkle tree. Ethereum execution payloads include transaction lists and commit to them through a transactions root.

Third, state or execution result commitment.

Ethereum blocks include state root and receipts root to commit to post-execution state and receipts. Bitcoin does not have Ethereum-style state roots, but nodes update the UTXO set according to transactions.

Fourth, consensus-related information.

PoW chains include difficulty, nonce, and proof-of-work. PoS chains include validator signatures, attestations, checkpoints, and finality-related data.

Fifth, fees and rewards.

Why do block producers participate? Because incentives exist. Bitcoin miners receive block subsidy and transaction fees. Ethereum validators receive priority fees and protocol rewards, while dishonest behavior can be penalized.

Who Decides Which Transactions Get Included?

Short answer: the block producer has major influence, but cannot do whatever they want.

A block producer can choose transactions, order them, or skip some of them. It usually prioritizes transactions with higher fees, executable conditions, or better economic value. In Ethereum, block building may also involve builders, relays, and MEV-Boost-like infrastructure.

But a producer cannot include invalid transactions or claim an incorrect state and expect the network to accept it. Other nodes verify. You can choose the menu, but you cannot sell a stone as steak and expect everyone to pay.

What Happens If Two Blocks Appear at the Same Time?

This can happen. Decentralized networks have propagation delays. Two producers may propose different blocks almost at the same time.

In PoW, nodes usually accept the valid block they see first. Later, if another branch gains more accumulated work, nodes switch to the heavier chain. The abandoned block becomes stale.

In PoS, consensus clients use fork choice rules and validator attestations to decide the head of the chain. Eventually, the branch with enough consensus support becomes part of the canonical chain.

So “a new block is created” does not mean “it is instantly permanent.” It still needs propagation, verification, and consensus support.

A Simple Case

Suppose Alice, Bob, and Carol all send transactions within the same minute. Alice transfers USDT, Bob swaps tokens, and Carol mints an NFT.

These transactions enter mempools across nodes. The Ethereum proposer for the current slot is selected and asks the execution client to prepare transactions. The execution client selects a batch from the pool and executes them in order.

Alice’s USDT contract storage updates. Bob’s swap changes pool reserves and balances. Carol’s mint changes ownership data in the NFT contract. After execution, a new state root is produced.

The proposer places the transactions and execution result into a new block and broadcasts it. Other nodes receive it and re-execute. If their computed state root matches, they accept the block. Validators then vote, the block receives confirmation, and it moves toward finality.

From the user’s view, these are three transactions.
From the chain’s view, one new block moves global state one step forward.

Common Misunderstandings

The first misunderstanding: a new block is just miners or validators randomly packaging transactions.

Wrong. Block producers have selection power, but blocks must satisfy protocol rules. Invalid blocks are rejected by nodes.

The second misunderstanding: once a transaction enters a block, it can never change.

Not always. Shortly after inclusion, a block may still be affected by reorgs. Confirmation and finality strengthen over time. High-value use cases usually wait for more confirmations.

The third misunderstanding: all nodes create blocks.

No. Many nodes only verify and sync. Blocks are created by producers selected or successful under the consensus mechanism. The value of normal full nodes is verification, not production.

The fourth misunderstanding: blocks only store transactions, not results.

Not accurate. Ethereum blocks include commitments to execution results, such as state root and receipts root. A block may not store the full global state, but it commits to the resulting state.

Risks and Design Questions

The first risk is transaction ordering. Block producers can influence transaction order, creating MEV, front-running, and sandwich risks. A transaction’s position matters, not only whether it is included.

The second risk is block propagation. If a new block propagates too slowly, other producers may build on an older head, increasing temporary forks. Network efficiency affects chain stability.

The third risk is centralization. If block building, mining pools, validators, RPCs, or builders become too concentrated, a small group may influence inclusion, ordering, and user experience.

The fourth risk is invalid block risk. If client implementations contain bugs, nodes may disagree on the same block. This is why client diversity, clear specifications, and testing are important.

The fifth risk is user misunderstanding. Users often mix up pending, included, confirmed, and finalized. Understanding block creation reduces a lot of on-chain anxiety.

Conclusion

Creating a new block is not simply stuffing transactions into a box.

It starts from the transaction pool. A block producer selects transactions, executes them, calculates resulting state, builds the block header and data structure, satisfies consensus rules, broadcasts the block, and other nodes verify it again.

• In Bitcoin, new blocks come from miners finding valid proof-of-work.
• In Ethereum, new blocks come from selected validators proposing blocks through cooperation between execution and consensus layers.

The mechanisms differ, but the common point is: blocks must be verifiable, history must be linked, and state must be recalculable.

In plain words: a new block is not just a new message on-chain. It is a state update package accepted by the network. It connects to the past, includes transactions, calculates results, and moves the chain forward by one step. A blockchain is a chain because blocks are created, verified, and linked one by one.

About SuperEx

As the world’s first Web3-powered cryptocurrency exchange, SuperEx has remained committed to building the Web3 ecosystem. Over the years, it has introduced a comprehensive range of products and services, including SuperEx DAO, SuperEx Web3 Wallet, Super Start, SuperEx P2P, SuperEx Stock Markets, SuperEx Copy Trading, SuperEx Earn, and SuperEx DAO Academy, creating a full-spectrum ecosystem that spans every major sector of Web3.

Today, SuperEx serves over 10 million users, with a social media community of more than 600,000 followers across 166 countries and regions worldwide. The platform supports 1,000+ cryptocurrencies for both spot and futures trading. Seamlessly integrated with Super Wallet, SuperEx provides decentralized asset custody while combining the trading efficiency of a centralized exchange (CEX) with the security of a decentralized exchange (DEX).

Click to register SuperEx
Click to download the SuperEx APP
Click to enter SuperEx CMC
Click to enter SuperEx DAO Academy — Space