What's in a block? – Blocksmith

The so-called “crypto” ecosystem, beyond all marketing terminology, is fundamentally based on blockchain technology. For example, in the case of the Ethereum blockchain, thousands of computers (nodes) around the world run the same software, known as “Geth,” to validate a literal, digital chain of blocks. The foundational question that underpins all further thinking about blockchain is: What defines a block, and under what circumstances does a chain of blocks become a blockchain?

This article will provide a brief exploration of the composition of a block from a constraints perspective.

The Block

The most atomic parts of blockchains are so called blocks, ie the building blocks of a blockchain. The Block concept refers to digital objects, or entities, encapsulating a wide array of attributes and use cases. Depending of the blockchain solution they make possible, we can imagine that blocks are blockchain specific, ie. may contain some blockchain-specific enabling properties. Not all blockchains are equal, hence no all blocks either. But beyond any given originality, they must answer the basic needs of building a blockchain, both in terms of chain constitution and usage (performance). Therefore there are ground commonalities in block constitution regarding the various constraints they answer to ( or originate from ), core necessities found in about every block out there.

Why the block

Eventually, blockchain software records interactions, whether human or automated. This could be the recording of nightly Bitcoin transactions from wallet A to wallet B, or in the case of a Decentralized Autonomous Organization, the recording of voting processes, and so on. Any interaction with a blockchain essentially involves interacting with a network, which translates to some entity triggering network computation. We group the wide range of blockchain interaction use cases and types under the “transaction” umbrella, originally referring to who or what paid the network to perform the computation.

Block Fundamentals

The critical aspect of interaction with the blockchain is the intention to record a specific aspect of the blockchain itself, ie. capturing what is happening on the network. For example, “let’s record that wallet A sent 1 Bitcoin to wallet B.” The entity wishing to carry out this interaction proposes to the network to process its details, which includes its data. Consequently, the entity pays for network usage, which translates into fees paid to network processors, such as miners or stakers, to record the interaction. We refer to this record as a transaction or a form of processing. To align with the fundamental purpose of a blockchain, it means that the data processed by the “miner/validator” and submitted to the network must be:

Correct, representing what actually occurred.
Tamper-proof.
Contain sufficient information for verifying it’s correctness by anyone.

To achieve this, all blockchain software create pieces of data known as blocks. These blocks serve as objects of intention, effectively representing the subject matter of the transaction and are standardized for the specific blockchain execution ecosystem.

Block constraints

As mentioned above, there are several constraints that dictate the properties of a block. These blockchain constraints, beyond any improved software or product experience, inscribe themselves in the blockchain paradigm trilemma, which is Security, Decentralisation and Scalability. A brief overview:

Security: Blockchains are secure against tampering and fraud thanks to cryptographic hashing and consensus mechanisms.
Decentralization: Blockchains are effectively peer-to-peer networks, reducing the need for central authorities.
Scalability: The network’s ability to handle a large number of transactions or operations within a reasonable amount of time and cost. It’s about increasing the network’s capacity to meet growing demand.

Hence, the core constraints-makers of basic blocks constitution, necessary for any blockchain execution ecosystem ( or software handling blocks ) may be categorised as follow:

Constraints	Resulting Attributes Written on a Block
Block Size Limit	- Limited number of transactions

	- Compact transaction and block headers
Consensus Mechanism	- Transaction validation details

	- Miner or validator information (in some cases)

Time Stamping	- Timestamp of when the block was created
Cryptographic Hashing	- Transaction IDs
	- Previous block’s hash

	- Merkle tree root for transactions
Network Protocol	- Version number

Constraints	- Network-specific data

Let’s check them out one by one:

Block Size Limit: The size of the block is constrained to ensure that it can be rapidly propagated through the network and validated by nodes. As a result, there’s a limit on the number and size of transactions that can be included in a block. Examples:
- Bitcoin: Bitcoin blocks have a size limit of 1 megabyte (MB). This allows for a variable number of transactions to be included, depending on the size of each transaction, but it’s typically between 1,000 and 2,000 transactions per block. (Note: There has been a development known as SegWit (Segregated Witness) which effectively increases the block size limit to specific amounts).
- Ethereum: Ethereum doesn’t have a block “size” limit per se but uses a gas limit for each block to limit the computational work needed for transactions and smart contracts. The gas limit varies and is decided by the miners, but it’s often around 12-15 million gas per block. The number of transactions that can fit into an Ethereum block is determined by how complex each transaction is, as different transactions can consume different amounts of gas.
Consensus Mechanism: Depending on the consensus mechanism (e.g., Proof of Work, Proof of Stake, etc..), different types of data related to transaction validation and the creation of the block may be included. Examples:
- Bitcoin: Process: Mining. Miners collect transactions into a block and try to hash the block’s header so that it’s lower than some predefined difficulty target. The nonce value is updated with each attempt. Validation: Other nodes validate the new block by checking the PoW, i.e., whether the block’s hash is lower than the difficulty target. Consequent Block data attributes:
  - Previous Block Hash: A hash of the previous block in the blockchain to ensure the integrity and chronological order of the blockchain.
  - Nonce: A value that miners change to get a block hash that meets the difficulty target. It’s proof that they performed the necessary computational work.
  - Transaction Merkle Root: A single hash that represents all transactions in the block. It helps quickly verify whether a transaction is included in a block.
  - Timestamp: The time when the block was found.
  - Difficulty Target: Indicates the current difficulty level for mining a new block. The hash of the block must be below this target value for the block to be added to the blockchain.
- Ethereum: Process: Staking (in PoS): Validators are chosen to create a new block based on the number of coins they hold and are willing to “stake” as collateral.
  - Previous Block Hash: Similar to Bitcoin, it ensures integrity and sequencing order.
  - Nonce: Similar to Bitcoin, but Ethereum also uses it for the account’s transaction count to prevent double-spending and replay attacks.
  - Slot: The slot to which the block belongs.
  - Proposer Index: ID of the validator proposing the block.
  - Parent Root: Hash of the preceding block.
  - State Root: Root hash of the state object.
Time Stamping: Every block is timestamped to indicate when it was created. This is essential for maintaining the order of blocks and transactions. Examples:
- Bitcoin (Proof of Work) Timestamp: Description: Indicates when the block was mined. Format: UNIX timestamp, representing the number of seconds elapsed since January 1, 1970 (UTC). Precision: Accurate to the nearest second. Usage: Helps in adjusting the difficulty level of mining to ensure blocks are added at an approximate interval. Previous Block Hash: Usage: A cryptographic hash of the header of the previous block. Ensures chronological order by linking blocks in a time-sequential manner.
- Ethereum 2.0 (Proof of Stake) Specific - Epochs and Slots: Time is divided into epochs and slots. Slots are intervals during which a block can be proposed, and an epoch consists of a fixed number of slots. Usage: Introduces regularity in the block proposal and validation process, ensuring that there’s a systematic mechanism for adding blocks over time.
Cryptographic Hashing: Blocks include cryptographic hashes (alphanumeric string acts as a digital fingerprint for the entity) of the transactions included, the previous block’s hash, and often a Merkle tree root to efficiently summarise the transactions. Examples:
- Bitcoin (Proof of Work): SHA-256: Bitcoin typically uses the SHA-256 (Secure Hash Algorithm 256-bit) cryptographic hash function to create block hashes.
  - Block Hash: Each block’s header is hashed to produce a unique block hash.The hash includes information like the previous block’s hash, the Merkle root, and other data from the block header.
  - Merkle Root: Imaging a collection of transactions within a block being hashed into pairs and then hashed again until there is a single hash left, the Merkle root. This is included in the block header.
- Ethereum (Proof of Stake): Ethash (in Ethereum 1.0) to Keccak (in Ethereum 2.0):
  - Block Hash: Similar to Bitcoin, Ethereum also includes a block hash, a unique identifier produced by hashing the block header.
  - Merkle Trees and Patricia Trees: Ethereum uses complex data structures like Patricia Trees in addition to Merkle Trees to store state and transaction data efficiently.

note: Beyond the block properties themselves, both network uses cryptographic solutions for various parts of their execution protocol, such as Proof of Work and target difficulties, BLS Signatures for aggregation, RANDAO for randomness, etc.

Network Protocol Constraints: Depending on the specific blockchain network and its protocol, additional data, and attributes might be required to be included in the block to ensure compatibility and functionality within the network. Examples:
- Bitcoin: Version: Indicates the protocol version to ensure that all blocks are consistent with the current protocol rules and expectations. Difficulty Target: A specific value that a block’s hash must be below to be considered valid; it adjusts to ensure the consistent timing of block generation. Timestamp: Though not a constraint, it’s a property written in the block that ensures blocks are mined in chronological order and supports the adjustment of mining difficulty over time.
- Ethereum 2.0: Slot Number: Indicates the specific slot for which the block is proposed, ensuring order and timing in the PoS consensus mechanism. Parent Root: The hash of the parent block, ensuring that blocks are created in a chronological sequence. State Root: A hash of the blockchain state after the block’s transactions have been processed, ensuring consistency and integrity of the blockchain state. Version or Graffiti Field (depending on implementation): Include versionning information or a field for validators to include custom messages; it’s part of ensuring consistency and/or tracking validator activity.

The Block layout

A block typically consists of two main parts: The block header and the block body. Each part serves a distinct function and contains specific types of information.

Block Header: The block header acts like the “identity card” of the block, provided by essential metadata about the entity, most of the above discussed properties.It contains information essential for the blockchain’s integrity, operation and continuity of the blockchain, but it does not include the actual transaction details.

Block Body: Houses the actual transaction data and potentially additional elements like receipts and logs. It represents the actual content or payload that the blockchain is meant to secure and maintain.

Let’s keep it simple! Congratulation is you read this to the end. We hope this article brings a little clarity over blockchain blocks anatomy and their various common constituting properties.

Blockchains are designed by engineering and product teams with specific preferences or use case paradigms in mind, such as performance-first or decentralization-first, among others. These teams develop the software that runs on the blockchain network, which is the software unanimously run by network nodes and responsible for consensus and execution. They also define the structure of the blocks that this software has to process. By examining various blockchains in the market and the structure of their blocks, you can gain insight into the priorities of their software design.

Next article: The functions of the blockchain software itself.
Stay tuned for our next blog post!