If you’re still asking ‘Why do I even need to learn Blockchain security?’ No worries. I wrote this blog to answer exactly that. Give it a read, then come back and we’ll dive into Blockchain 101 together.

Now that you are here, let’s start by understanding what is Blockchain?

But wait, a bit of warning, there is way too much text in the entire blog - I tried putting some AI generated images (which make sense for the blog), but they also were not able to do much, so all the best!

What is a Blockchain?

At its simplest, a blockchain is a digital ledger, like a record book, but instead of sitting in one central database, it’s spread across thousands of computers in a network. Every entry (called a block) is chained to the one before it using cryptography, creating a chain that’s hard to tamper with.

Generally, The network of computers are decentralized, and this network decides what actions are included in the Blockchain (the record book), in addition to that, anything that happens in the Blockchain, happens when the majority network agree on it.

Now that we understand what a blockchain is, the next question is: How does this blockchain actually store information? That leads us to the fundamental building unit - the block.

Blocks and the Chain

What Does a Block Contain?

Like a cell is the smallest unit of the human body, a block is the smallest unit of a blockchain.

Each block usually contains:

  • Transactions – the actual data being recorded (e.g., sending coins, updating records).
  • Timestamp – when the block was created.
  • Nonce / Block Hash – the block’s own fingerprint and the special number used to generate it.
  • Previous Block Hash – the unique fingerprint till the block before it, which keeps the chain connected.

This previous block’s hash, help in creation of well-defined chain structure in the Blockchain and this structure also ensures that if any data inside changes, the hash changes completely - breaking the chain.

How Blocks Form a Chain?

Blocks aren’t just stacked randomly - they’re cryptographically linked. Each block contains the hash (fingerprint) of the one before it. This creates a chain where tampering with one block would break every block after it.

That’s what gives blockchains their immutability. Once a block is accepted by the network, changing its contents would require recalculating all the following blocks faster than the rest of the network - practically impossible.

Blocks are just containers. But what do they actually contain? The real action on a blockchain happens inside transactions - the instructions that change state. So let’s look at what a transaction really is.

3. Transactions

A transaction represents a state change - whether that’s transferring money, updating data, or executing smart contract logic.

At a high level, a transaction is simply: A signed instruction that tells the blockchain what to do (e.g., “send 1 ETH to this address” or “execute this smart contract function”).

A blockchain transaction is:

  • a change of state (like updating a record),
  • a transfer of value or data, and
  • a signed message that proves the sender authorized that action.

Now, the basic structure of different types of blockchains differ -

  • In Bitcoin, a transaction moves BTC from one set of outputs to another.
  • In Ethereum, a transaction can do much more - it can transfer ETH or execute arbitrary smart contract code (like swapping tokens, minting NFTs, interacting with DeFi protocols, etc.).

Structure of the Transaction

Although each blockchain structures its transactions slightly differently, every transaction has the following core elements:

  • Sender: The address that initiates the transaction and signs it.
  • Recipient: The address (or smart contract) receiving the value or data.
  • Digital Signature: A cryptographic proof that only the owner of the private key could have authorized the transaction.
  • Amount / Value: How much cryptocurrency is being transferred.
  • Fee: An incentive paid to miners or validators. Fees ensure the network isn’t spammed and that higher-fee transactions are processed faster.

Bitcoin vs Ethereum Transactions

Bitcoin Transactions - Simple Transfers

Bitcoin uses the UTXO (Unspent Transaction Output) model:

  • You spend previous outputs (like cash notes)
  • You create new outputs (including “change”)
  • There is no programmable logic
  • Scripts are intentionally limited
  • Fees are based on transaction size (bytes)

A Bitcoin transaction only moves BTC.

Example - Bitcoin Pizza Bitcoin Pizza Transaction Screenshot

Ethereum Transactions - Programmable Actions

Ethereum uses the account model:

  • An account has a balance
  • Sending ETH simply subtracts from the sender and adds to the receiver

But more importantly:

  • Ethereum transactions can execute arbitrary smart contract code.

Examples: Swapping tokens, Minting NFTs, Opening loans, Voting in DAOs, Deploying contracts, etc.

Ethereum transactions include a data field, which encodes:

  • the function to call
  • the arguments
  • extra context for the EVM

Fees are based on computational work (gas), not size.

Example - Ronin Bridge Hack Transaction Bitcoin Pizza Transaction Screenshot

Lifecycle of a Transaction

Every transaction follows a predictable lifecycle before it becomes part of the chain.

1. Creation

A wallet constructs a transaction with:

  • sender
  • recipient
  • amount
  • fee
  • optional data (Ethereum only)

Then the sender signs it with their private key.

2. Propagation

The signed transaction is broadcast to the peer-to-peer network. Nodes verify that it is valid and add it to their mempool (the pool of pending transactions).

3. Inclusion in a Block

Miners/validators pick transactions from the mempool. They:

  • order them
  • execute them (Ethereum)
  • verify signatures
  • add them to a block they are proposing Once the block is accepted, the transaction is considered confirmed.

4. Confirmations

Each new block added on top increases the number of confirmations. The more confirmations:

  • the harder it is to reverse
  • the more “final” the transaction becomes

This is why exchanges require 1–6 confirmations depending on the asset.

Transaction Journey

Now, that we know what a transaction is - let’s disect it a bit. A transaction always has a sender and a receiver. But what exactly is a sender? What kind of “accounts” live on a blockchain?

4. Accounts and Access Mediums

So far, we’ve talked about transactions as instructions that change the blockchain’s state.

But every transaction needs:

  • someone to send it
  • somewhere to send it to
  • and some way to authorize it

That’s where accounts and access mediums come in.

4.1 Types of Accounts

On Ethereum (and most account-based blockchains), there are two main types of accounts:

  • Externally Owned Accounts (EOAs)
  • Contract Accounts (Smart Contracts)

They look similar on-chain (both are just addresses), but they behave very differently.

Externally Owned Accounts (EOAs)

These are the “normal” user accounts - the ones controlled by people (or bots).

Characteristics:

  • Controlled by a private key (can be a security concern if lost - account takeover)
  • Have:
    • an address
    • a balance a nonce (number of transactions sent)
  • Can:
    • initiate transactions
    • send ETH
    • call smart contracts

EOAs do not contain code. They are just “wallets” with keys and balances. If you have a MetaMask wallet, Phantom, Rabby, Ledger, etc., you are using an EOA.

Contract Accounts (Smart Contracts)

Contract accounts are programs that live on the blockchain.

Characteristics:

  • Have an address
  • Have a balance
  • Store code (smart contract logic)
  • Store state (variables in storage)
  • Cannot initiate transactions on their own
  • They only run when:
    • an EOA calls them, or
    • another contract calls them during execution

Examples of contract accounts: ERC-20 tokens, DeFi protocols (Uniswap, Aave, etc.), NFT contracts, DAO voting contracts, etc.

Think of a contract account as a bot: It never starts anything on its own, but when you send it a transaction, it follows its programmed rules exactly. It’s programmed, which also brings in vulnerabilities related to source code. (might write a blog sometime later on this)

4.2 Access Mediums

Knowing what an account is is one thing. But how do humans actually interact with these accounts?

We don’t manually craft raw transactions in hex (well… most people don’t). We use wallets and keys.

Wallets

A wallet is not an account.

It’s a tool (software or hardware) that manages your keys and helps you sign transactions.

There are two broad categories:

  • Hot Wallet

    • Connected to the internet
    • Examples: MetaMask, Rabby, Trust Wallet, Phantom
    • Pros: Easy to use, Great for daily DeFi / NFT / dApp activity
    • Cons: Larger attack surface (malware, phishing, website injection, approvals, etc.)

  • Cold Wallet

    • Kept offline most of the time
    • Examples: Ledger, Trezor, air-gapped devices, paper wallets
    • Pros: Much harder to hack remotely
    • Cons: Less convenient, If you mismanage the seed phrase or device, recovery can be painful or impossible

Custodial vs non-custodial

This is about who controls the private keys.

  • Custodial Wallets

    • Exchange or service controls the keys (Binance, Coinbase, centralized wallets)
    • It’s basically “Not your keys, not your coins”
    • Pros: Easier for beginners, Can sometimes recover access via KYC / support.
    • Cons: You depend on the company’s security, If they get hacked, go insolvent, or freeze withdrawals - your funds are at risk.

  • Non-Custodial Wallets

    • You control the keys
    • Examples: MetaMask, Ledger, most browser wallets
    • Pros: Full control over your assets
    • Cons: Full responsibility - lose the seed = lose the funds :(

Now we know who interacts with the blockchain and how they sign transactions. But each interaction costs computational effort. So how does the network measure and charge for that effort? This leads us to the idea of gas.

5. Gas and Ether

Blockchains like Ethereum act as global computers. To keep them running fairly and safely, every action has a cost - measured as gas, and paid using Ether (ETH).

Gas as Computational Metering

Every operation a transaction performs has an associated gas cost:

  • Simple ETH transfer → cheap
  • Contract interaction → more gas
  • Storage writes → very expensive

Gas ensures that heavy computations pay more, preventing abuse and protecting the network from spam and infinite loops.

Gas is the unit of work. ETH is the currency you use to pay for that work.

Your transaction fee is: Gas Used × Gas Price

Validators earn these fees as rewards for including your transaction in a block.

Then, there are concepts of -

  • Gas Limit - the maximum gas you’re willing to allow the transaction to spend
  • Gas Price / Max Fee - how much you’ll pay per gas unit
  • Priority Fee - optional tip to validators to speed up inclusion

If the gas limit is too low, the transaction fails - and you still pay for the gas it used.

Now the question arises, why does Gas exsits? It ensures

  • Spam protection - attacks become expensive
  • Fair resource usage - complex transactions pay more
  • Network safety - prevents infinite loops
  • Validator incentives - fees reward those who secure the chain

Gas helps us understand costs, but how do we actually see what happened on-chain? Every transaction and every block is publicly visible - if you know where to look. Enter blockchain explorers.

Gas explains how the blockchain measures and prices computation. But to understand how transactions actually move through the system, we need to look under the hood at the peer-to-peer network itself.

6. Network Architecture

Blockchains don’t rely on a central server (I mean some do, but we will talk about it later). Instead, they run on a peer-to-peer (P2P) network - a distributed web of independent machines (nodes) that all share data directly with one another.

Every node connects to multiple peers. There’s no hierarchy, no master node. Each node:

  • maintains connections
  • shares what it knows
  • receives what others know

This creates a resilient, decentralized network where no single machine is in control.

Nodes learn about each other the same way rumors spread in a group:

  • a node tells its neighbors something
  • those neighbors tell their neighbors
  • and the information quickly spreads across the entire network

This mechanism is called the gossip protocol, which is how nodes discover peers, broadcast new blocks, and share new transactions.

When a wallet broadcasts a transaction:

  • the connected node verifies it
  • shares it with peers
  • they forward it to their peers
  • eventually every node learns about it

Blocks propagate the same way. This ensures the entire network stays synchronized.

The network only moves data around. But who processes that data? For that, we need to understand the different components inside a blockchain node.

7. Node Architecture

But inside an Ethereum node, there are actually three different roles working together:

  • Execution Client – runs the code
  • Consensus Client – agrees on the chain
  • Validator – participates in block proposals & attestations (if staked)

Let’s break them down.

7.1 Execution Client

The execution client is the part of the node that actually runs the EVM, processes transactions, and updates the state.

Ethereum used to be “one big client” (Geth, etc.), but after the Merge it’s conceptually split into:

  • Execution client: Geth, Nethermind, Besu, Erigon
  • Consensus client: Prysm, Lighthouse, Teku, Nimbus, Lodestar

When your transaction hits a node:

The execution client:

  • checks the signature
  • checks the nonce
  • checks sender balance and gas
  • simulates execution of the transaction

It then:

  • applies state changes (balances, storage, logs)
  • updates the local state database

If the consensus client says: “This block is part of the canonical chain”, the execution client’s state becomes the current truth for that node.

In case of smart contract runs, it can:

  • read/write its own storage
  • call other contracts
  • emit events/logs
  • transfer ETH

It cannot:

  • access off-chain data directly
  • generate true randomness (needs oracles)

The execution client tracks all this in a huge state trie (a Merkle-Patricia tree of accounts and storage). At any block, the node knows:

  • each address → balance, nonce, code, storage root
  • each contract → its code and storage values

7.2 Consensus Client

(before going ahead - read “Consensus in Blockchain")

The consensus client doesn’t care about what contracts do in detail - it cares about which blocks are valid and in what order.

What it does?

  • connects to the consensus network (validators, other consensus clients)
  • runs the consensus protocol (Proof of Stake in Ethereum)
  • decides which chain is the canonical one
  • handles finality and fork choice

In a live network, blocks can:

  • arrive late
  • be conflicting
  • form temporary forks

The consensus client uses the consensus rules to answer: “Which chain of blocks is the one we all agree on?”

7.3 Validators

It’s a PoS concept. For PoW we call them miners.

Validators are special nodes (or node roles) that:

  • propose new blocks
  • attest (vote) on blocks
  • stake ETH and get rewarded or slashed

You can run a full node without being a validator (no staking, just verifying) or a validator node that uses both an execution and consensus client, plus validator keys.

To become a validator on Ethereum, you stake 32 ETH per validator key and run an execution client, a consensus client, a validator client (handles keys and duties).

Validators do two main things:

  • Propose blocks

    • occasionally, you are chosen to propose the next block for a given slot
    • you assemble transactions (from mempool), build a block, broadcast it

  • Attest to others’ blocks

    • in most slots, you just vote on the block you see as correct
    • your vote helps the network agree on the canonical chain

And for all this work, validators earn rewards, yay! And these rewards are for being online, making correct attestations and proposing valid blocks.

The rewards can be slashed as well for, double proposing (two blocks for same slot), double voting (attesting to conflicting chains), surrounding votes (attesting in a way that undermines finality) or being offline too often (slow leak, not slash, but still penalized).

11. Conclusion

In this blog, we broke down a blockchain into its core moving parts:

  • Transactions - how state changes are requested
  • Accounts - who sends and receives those changes
  • Gas & Ether - how computation is measured and paid for
  • Network Architecture - how data spreads across thousands of nodes
  • Node Architecture - how execution and consensus components process and validate that data

Together, these create a decentralized system where anyone can interact, and everyone can verify.

A transaction is created → shared across the network → verified → ordered → executed → and finally applied to the global state.

Each layer plays a specific role, and only when combined do we get a secure, transparent, and trustless blockchain.

We stopped just before two major topics:

  • Consensus - how nodes agree on a single version of the truth
  • Blockchain Layers - how blockchains scale, interoperate, and evolve

These deserve their own deep dives, and they will be the focus of the next blogs, and this one is getting to big on its own and too text heavy. So yeah!

Thank you for reading, feel free to reach out @0xCardinal if you have any questions or concern. Happy to chat!