Blockchain Fundamentals: Consensus, Cryptography, and Nodes – Advanced Technical Guide

Have you ever read that blockchain is "immutable" and "decentralized" and wondered how it actually works? It's not just for cryptocurrencies. Every day we see companies wanting to use this technology for traceability, smart contracts, or supply chain, but without understanding consensus and cryptography, they end up relying on prepackaged solutions that solve nothing. We, at Meteora Web, have built proprietary platforms and managed sensitive data: we know that security is not a label, it's a structure. In this guide we break down the three technical pillars of blockchain: how consensus is reached, how cryptography holds everything together, and what nodes actually do. No abstract theory – only code, commands, and concrete decisions.

Consensus: How a Distributed Network Trusts Itself

In a centralized system, a single server decides the truth. In a blockchain, there is no server: hundreds or thousands of nodes exist. Each holds a copy of the data. How do they agree on the correct ledger? Through a consensus mechanism. Without consensus, a single malicious node could falsify the history.

Proof of Work (PoW) – Energy as a Vote

The most well-known, used by Bitcoin. Nodes (miners) compete to solve a cryptographic puzzle: find a nonce such that the block hash starts with a certain number of zeros. The first solver proposes the block; others verify and add it to their chain. The probability of winning is proportional to the computational power spent.

Pros: Robust security, attacking costs more than attacking.

Cons: Enormous energy consumption, limited throughput (Bitcoin ~7 tx/s).

Try it now: Open a terminal and generate a hash with a target difficulty. Example in Python:

import hashlib
import time

def proof_of_work(block_data, difficulty=4):
    prefix = '0' * difficulty
    nonce = 0
    while True:
        data = f"{block_data}{nonce}".encode()
        hash_hex = hashlib.sha256(data).hexdigest()
        if hash_hex.startswith(prefix):
            return nonce, hash_hex
        nonce += 1

# Try with difficulty = 5 (will take a few seconds)
nonce, hash = proof_of_work("test_block", difficulty=5)
print(f"Nonce: {nonce}, Hash: {hash}")

Change the difficulty and see how time increases. This is the core of mining.

Proof of Stake (PoS) – Money as a Vote

Instead of wasting electricity, validators stake a certain amount of cryptocurrency. The algorithm pseudorandomly selects who proposes the next block, with probability proportional to stake (and often coin age). If a validator tries to cheat, they lose their stake (slashing).

Pros: Negligible energy, higher throughput (Ethereum now ~30 tx/s, much more with L2).

Cons: Risk of centralization for large stakers, economic complexity (finality, nothing at stake).

Try it now: Simulate a simple validator selection in Python:

import random

validators = {"Alice": 1000, "Bob": 500, "Charlie": 200}
total_stake = sum(validators.values())

def select_validator(stakes):
    # Random weighted by stake
    r = random.uniform(0, total_stake)
    cum = 0
    for val, stake in stakes.items():
        cum += stake
        if r < cum:
            return val
    return list(stakes.keys())[-1]

print("Selected validator:", select_validator(validators))

This is a basic model; real protocols (Casper, Tendermint) add voting rounds and slashing.

Other Consensus Mechanisms

• Delegated Proof of Stake (DPoS): Stakeholders elect a small set of delegates who produce blocks in rotation. Faster but less decentralized (EOS, TRON).
• Practical Byzantine Fault Tolerance (PBFT): Used in permissioned blockchains (Hyperledger Fabric). Nodes exchange messages in phases to reach consensus even with 1/3 malicious nodes.
• Proof of Authority (PoA): A set of known, verified validators (e.g., public authorities). Suitable for private networks.

Common mistake: Thinking all blockchains use PoW. The vast majority today use PoS or variants. Choose consensus based on your use case: for a private supply chain, PBFT or PoA are more efficient than PoW.

Cryptography: The Foundation of Trust Without Trust

Blockchain trusts mathematics, not people. Two cryptographic families are essential: hashing and asymmetric cryptography (public/private key). Without these, neither addresses nor digital signatures would exist.

Hashing: The Glue of Immutability

A hash function (SHA-256, BLAKE2) takes an input of any length and produces a fixed output (256 bits). Properties: deterministic, fast, preimage resistance, and avalanche effect (changing one bit changes the entire hash). In blockchain, each block contains the hash of the previous block: this chains them together. Modifying an old block would change all subsequent hashes, making the attack obvious.

Try it now: Verify the avalanche effect with this snippet:

import hashlib

def hash_hex(s):
    return hashlib.sha256(s.encode()).hexdigest()

print(hash_hex("Meteora Web"))
print(hash_hex("Meteora Web."))  # just one extra period

Compare the outputs: completely different.

Digital Signatures: Who Signed This Transaction?

Elliptic curve cryptography (ECDSA on secp256k1) generates a key pair: private (secret) and public (shared). The private key signs a hash of the transaction; anyone with the public key can verify the signature. This replaces handwritten signatures in a digital environment.

Practical example using the ecdsa library in Python:

from ecdsa import SigningKey, SECP256k1

# Generate private key
priv = SigningKey.generate(curve=SECP256k1)
pub = priv.verifying_key

# Message to sign
msg = b"Transaction: Alice -> Bob 10 BTC"
signature = priv.sign(msg)

# Verify
print(pub.verify(signature, msg))  # True

# If we modify the message:
msg_fake = b"Transaction: Alice -> Bob 1000 BTC"
print(pub.verify(signature, msg_fake))  # False

Common mistake: Storing private keys in plain text on repositories or unbacked servers. Lose the private key, lose control of assets. We see it too often: clients bring us compromised wallets because the key was in a .txt file.

Nodes: The Backbone of the Network

A node is a piece of software that runs the blockchain protocol, maintains a copy of the state, and communicates with other nodes. Not all nodes are equal.

Types of Nodes

• Full Node: Downloads and verifies every block and transaction since genesis. Maintains the entire blockchain. It is the security guarantor. Examples: Bitcoin Core, Geth (Ethereum).
• Light Node (SPV): Downloads only block headers (80 bytes each in Bitcoin) and verifies transactions of interest by requesting proofs from full nodes. Fewer resources, but trusts others for unverified data.
• Validator / Miner Node: In addition to being a full node, it produces blocks (mining or staking). Requires significant resources (for PoW: ASIC hardware; for PoS: large stake).
• Archival Node: Stores the complete transaction history, not just the current state. Useful for analysis, block explorers.

What Happens When You Start a Node?

When you install Bitcoin Core, it starts the initial sync: downloads and verifies every block since 2009. Today this can take days even on fast connections. Then it stays listening (port 8333) and propagates transactions and blocks. Configuration options:

• txindex=1 – enables searching for arbitrary transactions (requires extra disk space).
• prune=550 – reduces disk usage by deleting old blocks (pruned node mode, useful for testing).

Try it now (on a Linux VPS):

# Install Bitcoin Core (Ubuntu/Debian)
sudo apt update
sudo apt install bitcoin-core

# Start in testnet mode (does not affect mainnet)
bitcoind -testnet -daemon

# Check status
bitcoin-cli -testnet getblockchaininfo

# Create a test address
bitcoin-cli -testnet getnewaddress

Note: testnet only receives test coins (you can get them from faucets). Never use testnet for real transactions.

Node Ecosystem: Why You Should Run One

If you develop a dApp or smart contract, you cannot rely on a single centralized provider (like Infura). Risk: if Infura goes down, your app is dead. Better to have your own full node or use a load balancer across multiple nodes. We, at Meteora Web, when building Web3 solutions, prefer open-source stacks and our own nodes. We automate deployment with Docker and Ansible so we don't have to stay up at night.

Putting It All Together: A Fictitious Block

Here's how consensus, cryptography, and nodes connect in one minute:

1. A user creates a transaction (signed with their private key).
2. They send it to a node (full or light).
3. The node verifies the signature and that the sender has sufficient balance.
4. If valid, it propagates to peers.
5. Miner/validator nodes collect transactions into a block.
6. For PoW: they search for a nonce that satisfies the difficulty target. For PoS: a validator is selected.
7. The new block (containing the previous block hash, merkle root of transactions, timestamp, nonce) is propagated.
8. Other nodes verify: the hash is valid, all transactions are still valid, the nonce meets the target.
9. If approved, the block is added to the local chain and the cycle repeats.

Common mistake: Thinking blockchain is a database that keeps everything in RAM. Healthy nodes write to disk and periodically prune. The current state (UTXO set) is maintained in a LevelDB database, not the entire chain.

What to Do Next

Don't stop at theory. Here are 5 concrete actions to take today:

1. Install a testnet node of Bitcoin or Ethereum (Sepolia) on a €5/month VPS. Use it to test transactions, smart contracts, and understand sync times.
2. Write a simple consensus simulation in Python as shown above; then implement a chain with two nodes communicating via sockets.
3. Read the original Bitcoin whitepaper (bitcoin.pdf) – only 9 pages, but every sentence is dense.
4. Explore block headers with bitcoin-cli getblockheader on testnet. Look at the previousblockhash and merkleroot fields.
5. Read Ethereum's Proof of Stake documentation (Ethereum PoS docs) to understand practical differences from PoW.

And remember: blockchain is a tool, not a trend. We've integrated it into real projects for traceability and smart contracts; we've also discarded it when a traditional database would suffice. Choose based on the problem, not on the buzzword.