Blocks, chains, and hashing in Blockchain / Solidity - Deep Dive

Overview - Blocks, chains, and hashing

What is it?

Blocks, chains, and hashing are the core parts of a blockchain. A block is like a digital container that holds data, such as transactions. These blocks are linked together in a chain, where each block points to the one before it. Hashing is a way to create a unique digital fingerprint for each block, ensuring the data inside cannot be changed without detection.

Why it matters

This system exists to keep data safe and trustworthy without needing a central boss. Without blocks, chains, and hashing, digital records could be easily changed or faked, making it hard to trust online transactions or agreements. This technology helps build secure systems like cryptocurrencies, digital contracts, and more.

Where it fits

Before learning this, you should understand basic data structures like lists and the idea of cryptographic hashes. After this, you can explore how blockchain networks work, how consensus is reached, and how smart contracts operate.

Mental Model

Core Idea

A blockchain is a linked list of blocks secured by unique hashes that protect data integrity and order.

Think of it like...

Imagine a chain of locked boxes where each box has a label made from the contents of the previous box. If someone tries to change a box, the label on the next box won't match, showing the tampering.

Block 1 [Data + Hash 0]
  ↓
Block 2 [Data + Hash(Block 1)]
  ↓
Block 3 [Data + Hash(Block 2)]
  ↓
... (chain continues)

Build-Up - 6 Steps

1

Foundation

Understanding what a block is

Concept: A block is a container that stores data and a hash linking it to the previous block.

A block holds information like transactions or records. It also stores a special code called a hash, which is created from the block's data. This hash acts like a fingerprint, unique to that block's contents.

Result

You know that a block is not just data but also includes a unique identifier that depends on its contents.

Understanding that blocks contain both data and a unique hash is key to seeing how blockchains keep data secure and linked.

2

Foundation

What is hashing and why it matters

Concept: Hashing turns any data into a fixed-size string that uniquely represents that data.

Hashing uses math to create a short code from any input data. Even a tiny change in the data creates a very different hash. This makes hashes perfect for checking if data has changed.

Result

You can see how hashing helps detect changes in data quickly and reliably.

Knowing that hashes change completely with small data changes explains why they are perfect for securing blocks.

3

Intermediate

How blocks link to form a chain

🤔Before reading on: do you think blocks store the full previous block or just a summary? Commit to your answer.

Concept: Each block stores the hash of the previous block, linking them securely in order.

Instead of copying the whole previous block, each block stores only its hash. This creates a chain where changing one block breaks the chain because the next block's stored hash won't match anymore.

Result

You understand that the chain is secured by these hash links, making tampering obvious.

Recognizing that blocks link by hashes rather than full data shows how blockchains stay efficient and secure.

4

Intermediate

Why immutability comes from chaining

🤔Before reading on: do you think changing one block requires changing all later blocks? Commit to your answer.

Concept: Changing a block changes its hash, which breaks the chain unless all following blocks are updated.

If someone changes a block's data, its hash changes. The next block stores the old hash, so the chain breaks. To fix this, all later blocks must be recalculated, which is very hard in large chains.

Result

You see why blockchains are called immutable or unchangeable.

Understanding that chaining hashes creates a strong defense against tampering explains blockchain's trustworthiness.

5

Advanced

Role of nonce and proof-of-work

🤔Before reading on: do you think finding a valid hash is easy or requires effort? Commit to your answer.

Concept: Proof-of-work uses a special number called a nonce to find a hash that meets strict rules, making block creation costly.

Miners try different nonce values until the block's hash starts with a certain number of zeros. This takes many tries and time, proving work was done. It prevents attackers from easily changing blocks.

Result

You understand how proof-of-work secures the blockchain by making block creation hard.

Knowing that proof-of-work adds a cost to block creation explains how blockchains resist attacks.

6

Expert

Hash collisions and security limits

🤔Before reading on: do you think two different blocks can have the same hash? Commit to your answer.

Concept: Hash functions are designed to avoid collisions, but they are theoretically possible and must be considered in security.

A hash collision happens if two different inputs produce the same hash. Good hash functions make this extremely unlikely. However, if collisions occur, attackers could fake blocks. Blockchain designs choose strong hashes to minimize this risk.

Result

You realize that while hashing is very secure, it is not mathematically perfect, and security depends on hash strength.

Understanding hash collisions highlights the importance of choosing strong hash functions and staying updated with cryptographic advances.

Under the Hood

Internally, each block's hash is computed by running its data through a cryptographic hash function like SHA-256. This function produces a fixed-length output that changes drastically with any input change. The blockchain stores each block with its data, the previous block's hash, and a nonce for proof-of-work. When a new block is created, miners repeatedly change the nonce until the hash meets difficulty criteria. This process links blocks securely and makes tampering computationally expensive.

Why designed this way?

This design was created to solve the problem of trust in decentralized systems without a central authority. Linking blocks by hashes ensures data integrity and order. Proof-of-work was chosen to prevent easy rewriting of history by requiring computational effort. Alternatives like proof-of-stake exist but proof-of-work was the first practical solution, balancing security and decentralization.

┌─────────────┐      ┌─────────────┐      ┌─────────────┐
│ Block 1     │─────▶│ Block 2     │─────▶│ Block 3     │
│ Data       │      │ Data       │      │ Data       │
│ Hash 0     │      │ Hash(Block 1)│      │ Hash(Block 2)│
│ Nonce      │      │ Nonce      │      │ Nonce      │
└─────────────┘      └─────────────┘      └─────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does changing one block require recalculating all previous blocks? Commit yes or no.

Common Belief: If you change a block, you only need to fix that block's hash.

Reality: Changing one block changes its hash, which breaks the next block's stored hash, so all following blocks must be recalculated.

Why it matters: Ignoring this leads to underestimating the security of blockchains and how hard it is to tamper with data.

Quick: Is hashing reversible to get original data? Commit yes or no.

Common Belief: You can reverse a hash to find the original data.

Reality: Hashes are one-way functions; you cannot get the original data from the hash.

Why it matters: Believing hashes are reversible risks exposing sensitive data or misunderstanding blockchain privacy.

Quick: Can two different blocks have the same hash? Commit yes or no.

Common Belief: Hash collisions never happen, so hashes are always unique.

Reality: While extremely rare, collisions are theoretically possible, so strong hash functions are essential.

Why it matters: Ignoring collision risks can lead to security vulnerabilities if weak hashes are used.

Quick: Does proof-of-work guarantee instant block creation? Commit yes or no.

Common Belief: Proof-of-work makes block creation fast and easy.

Reality: Proof-of-work is intentionally slow and requires many attempts to find a valid hash.

Why it matters: Misunderstanding this can cause wrong expectations about blockchain speed and scalability.

Expert Zone

1

The nonce is not stored in the previous block but only in the current block to vary the hash output during mining.

2

The difficulty of proof-of-work adjusts over time to keep block creation at a steady rate despite changes in total mining power.

3

Some blockchains use different hash functions or combine multiple hashes to improve security and performance.

When NOT to use

This approach is not suitable when fast transaction speed and low energy use are priorities. Alternatives like proof-of-stake or permissioned blockchains offer faster and more energy-efficient consensus methods.

Production Patterns

In real systems, blocks include Merkle trees to efficiently summarize many transactions, and chains use checkpoints or pruning to manage size. Hashing is combined with digital signatures to verify transaction authenticity.

Connections

Linked lists (data structures)

Blocks form a linked list where each node points to the previous one via a hash.

Understanding linked lists helps grasp how blocks connect in order and why changing one affects the chain.

Cryptographic hash functions (cryptography)

Hashing in blockchains uses cryptographic hash functions to secure data.

Knowing cryptographic hash properties explains why blockchains are tamper-resistant and secure.

Supply chain management (logistics)

Both use chained records to track items and ensure authenticity over time.

Seeing blockchain like a digital supply chain record helps understand its role in trust and traceability.

Common Pitfalls

#1 Trying to store the entire previous block inside the current block.

Wrong approach:

Block {
data: [...],
previousBlock: { full block data }
}

Correct approach:

Block {
data: [...],
previousHash: 'abc123...'
}

Root cause:

Misunderstanding that only the hash of the previous block is needed to link blocks efficiently.

#2 Assuming hashes can be reversed to get original data.

Wrong approach:

originalData = reverseHash(block.hash)

Correct approach:

// Hashes are one-way; store original data separately and verify by hashing again.

Root cause:

Confusing hash functions with encryption or reversible encoding.

#3 Ignoring the need for proof-of-work or consensus in block creation.

Wrong approach:

Add new block immediately without mining or validation.

Correct approach:

Perform proof-of-work by finding nonce so hash meets difficulty before adding block.

Root cause:

Not understanding that consensus mechanisms secure the blockchain against attacks.

Key Takeaways

Blocks store data and a unique hash that depends on their contents, linking them securely.

Hashing creates a fixed-size fingerprint that changes completely if data changes, ensuring integrity.

Blocks link by storing the previous block's hash, forming a chain that is tamper-evident.

Proof-of-work adds computational effort to block creation, making tampering costly and securing the chain.

While hashing is very secure, understanding its limits like possible collisions is important for blockchain safety.

Practice

1. What is the main purpose of a hash in a blockchain block?

easy

A. To create a unique fingerprint of the block's data

B. To store the block's timestamp

C. To list all transactions in the block

D. To connect the block to the internet

Solution

1. Step 1: Understand what a hash does

   A hash is a unique code generated from the block's data, like a fingerprint.

2. Step 2: Identify the purpose of the hash in blockchain

   The hash ensures the block's data cannot be changed without detection.

3. Final Answer:

   To create a unique fingerprint of the block's data -> Option A

4. Quick Check:

   Hash = Unique fingerprint [OK]

Hint: Hash = unique code for block data [OK]

Common Mistakes:

• Confusing hash with timestamp
• Thinking hash stores transactions
• Believing hash connects to internet

2. Which of the following is the correct way to represent a block's hash in code?

easy

A. hash = block_data + SHA256

B. hash = SHA256(block_data)

C. hash = SHA256(block_data + hash)

D. hash = block_data.hash()

Solution

1. Step 1: Recognize the correct hash function usage

   SHA256 is a common hash function applied to block data to get the hash.

2. Step 2: Check each option for correct syntax

   hash = SHA256(block_data) correctly applies SHA256 to block_data. Others misuse the function or syntax.

3. Final Answer:

   hash = SHA256(block_data) -> Option B

4. Quick Check:

   Correct hash function call = hash = SHA256(block_data) [OK]

Hint: Hash function called with data inside parentheses [OK]

Common Mistakes:

• Adding hash function as string instead of calling it
• Using incorrect syntax for hash function
• Confusing method call with variable

3. Consider this simplified Python code for creating a blockchain block hash:

import hashlib
block_data = 'Block 1 data'
hash_object = hashlib.sha256(block_data.encode())
block_hash = hash_object.hexdigest()
print(block_hash)

What will be the output type of block_hash?

medium

A. integer

B. bytes

C. string

D. list

Solution

1. Step 1: Understand hashlib.sha256 and hexdigest()

   hashlib.sha256 returns a hash object; hexdigest() converts it to a hex string.

2. Step 2: Identify the output type of hexdigest()

   hexdigest() returns a string representing the hash in hexadecimal form.

3. Final Answer:

   string -> Option C

4. Quick Check:

   hexdigest() output = string [OK]

Hint: hexdigest() returns string, digest() returns bytes [OK]

Common Mistakes:

• Thinking hexdigest() returns bytes
• Confusing output with integer or list
• Ignoring .encode() usage

4. The following code tries to link blocks in a chain by storing the previous block's hash. What is the error?

class Block:
    def __init__(self, data, prev_hash):
        self.data = data
        self.prev_hash = prev_hash

block1 = Block('First block', None)
block2 = Block('Second block', block1.hash)

medium

A. block1.hash is not defined before use

B. prev_hash should be a list, not a single value

C. None cannot be used as prev_hash

D. block2 data should be a number, not string

Solution

1. Step 1: Check block1 attributes

   block1 has data and prev_hash but no attribute named 'hash'.

2. Step 2: Identify usage of undefined attribute

   block2 tries to use block1.hash which does not exist, causing an error.

3. Final Answer:

   block1.hash is not defined before use -> Option A

4. Quick Check:

   Accessing undefined attribute = block1.hash is not defined before use [OK]

Hint: Check if attribute exists before using it [OK]

Common Mistakes:

• Assuming hash attribute exists by default
• Confusing prev_hash type requirements
• Thinking data type causes error

5. You want to create a simple blockchain where each block stores its own hash and the previous block's hash. Which code snippet correctly computes and links the hashes for two blocks?

hard

A. import hashlib

class Block:
def __init__(self, data, prev_hash):
self.data = data
self.prev_hash = prev_hash
self.hash = hashlib.sha256(data.encode()).hexdigest()

block1 = Block('Block 1', '0')
block2 = Block('Block 2', block1.hash)

B. import hashlib

class Block:
def __init__(self, data):
self.data = data
self.hash = hashlib.sha256(data.encode()).hexdigest()

block1 = Block('Block 1')
block2 = Block('Block 2')
block2.prev_hash = block1.hash

C. class Block:
def __init__(self, data, prev_hash):
self.data = data
self.prev_hash = prev_hash
self.hash = data + prev_hash

block1 = Block('Block 1', '0')
block2 = Block('Block 2', block1.hash)

D. import hashlib

class Block:
def __init__(self, data, prev_hash):
self.data = data
self.prev_hash = prev_hash
self.hash = hashlib.sha256((data + prev_hash).encode()).hexdigest()

block1 = Block('Block 1', '0')
block2 = Block('Block 2', block1.hash)

Solution

1. Step 1: Check hash calculation includes previous hash

   The correct implementation computes the hash from both data and prev_hash: self.hash = hashlib.sha256((data + prev_hash).encode()).hexdigest(), ensuring secure linking.

2. Step 2: Verify other options

   B: prev_hash set after hash computation (hash ignores prev_hash); C: no hashing, just concatenation; D: hash ignores prev_hash.

3. Final Answer:

   self.hash = hashlib.sha256((data + prev_hash).encode()).hexdigest() -> Option D

4. Quick Check:

   Hash(data + prev_hash) [OK]

Hint: Hash must include previous hash to link blocks [OK]

Common Mistakes:

• Not including prev_hash in hash calculation
• Assigning prev_hash after block creation
• Using plain concatenation without hashing