Posted Blockchain

Crypto-Atlas

Crypto Fundamentals

Hash Functions

A hash function converts arbitrary input data into a fixed-size digest.

1
2
3
"hello"
↓ hash
2cf24dba...

Important properties:

  • The same input always produces the same hash.
  • A tiny input change produces a very different hash.
  • Recovering the original input from the hash should be computationally infeasible.
  • Finding two different inputs with the same hash should be extremely difficult.

Blockchains use hashes for transaction IDs, block linking, Merkle trees, and data integrity.

Public / Private Keys

Public/private key pairs come from asymmetric cryptography.

1
2
3
4
5
Private Key
    ↓ derive
Public Key
    ↓ derive
Address

In blockchain systems, keys are mainly used for digital signatures rather than encrypting transaction data.

1
2
Private Key → sign
Public Key  → verify

The private key must remain secret. Whoever controls it can authorize transactions from the corresponding account.

Digital Signatures

A digital signature proves that a transaction or message was authorized by the holder of a private key without exposing that key.

1
2
3
4
5
Transaction
+
Private Key
↓
Signature

Other participants can cryptographically verify the signature.

1
2
3
4
5
6
7
Transaction
+
Signature
+
Public Key
↓
Valid / Invalid

Digital signatures provide authorization and authenticity, not secrecy: transaction data itself is generally public.

Addresses

An address is a public on-chain identifier derived from cryptographic key material.

Conceptually:

1
2
3
Private Key
→ Public Key
→ Address

An address is not the same as a public key.

It is mainly used as an identifier:

1
2
3
4
address → account
address → asset ownership
address → transaction destination
address → permissions

For example:

1
2
from: 0xAlice...
to:   0xBob...

The address itself normally does not perform cryptographic authorization; keys and signatures do.

An address also does not necessarily represent one unique human. One person can control many addresses, and an address may represent a smart contract rather than a user.

Wallets

A wallet manages cryptographic keys and signs blockchain operations.

It does not literally store cryptocurrency.

1
2
3
4
5
6
7
8
Blockchain
└── records ownership / balances / state

Wallet
├── manages private keys
├── derives addresses
├── signs transactions
└── reads blockchain state

The wallet is therefore mainly an interface for controlling blockchain accounts.

Seed Phrases

A seed phrase is a human-readable backup from which a wallet can derive many private keys and addresses.

1
2
3
4
5
6
7
8
9
Seed Phrase
↓
Master Key
↓
Private Keys
↓
Public Keys
↓
Addresses

One seed phrase may control many accounts.

Anyone who obtains the seed phrase can usually recreate the wallet and control those accounts.

Merkle Trees

A Merkle tree combines many pieces of data into a single root hash.

For four transactions:

1
2
3
4
5
6
7
       Merkle Root
       /         \
    H12           H34
   /   \         /   \
 H1     H2     H3     H4
 |      |      |      |
Tx1    Tx2    Tx3    Tx4

Where:

1
2
3
H1  = hash(Tx1)
H12 = hash(H1 + H2)
Root = hash(H12 + H34)

The Merkle root acts as a compact cryptographic commitment to the entire dataset.

A major benefit is that a node can prove that one item belongs to a large dataset without sending the entire dataset.

1
2
3
4
5
6
7
Tx2
+
H1
+
H34
↓
recompute Merkle Root

If the calculated root matches the expected root, the transaction’s inclusion can be verified.

Transactions

A transaction is a cryptographically signed instruction submitted to a blockchain.

It may represent actions such as:

  • transferring assets;
  • calling application logic;
  • changing blockchain state.

Typical flow:

1
2
3
4
5
6
7
8
create transaction
→ sign with private key
→ send to a node
→ validate
→ wait as pending
→ included in a block
→ executed
→ confirmed / finalized

A valid signature proves authorization, but transaction validity may also depend on protocol rules and current blockchain state.

Blockchain Basics

Blocks

A block contains a batch of transactions plus protocol metadata.

Conceptually:

1
2
3
4
5
Block
├── transactions
├── previous block reference
├── cryptographic commitments
└── protocol metadata

Blocks form an ordered blockchain history:

1
2
3
4
5
Block 100
   ↓
Block 101
   ↓
Block 102

Each block is cryptographically connected to earlier blockchain data, making historical modification detectable.

Nodes

A node is a computer running blockchain software and participating in the peer-to-peer network.

Nodes may:

  • receive transactions;
  • validate transactions;
  • receive and validate blocks;
  • maintain blockchain state;
  • communicate with other nodes;
  • expose blockchain data through APIs.
1
2
3
4
5
Application
    ↓
Node
 ↙  ↓  ↘
Node Node Node

A node does not blindly trust a newly received block.

It can independently verify:

1
2
3
4
5
receive block
→ verify block rules
→ verify transactions
→ verify state transition
→ accept or reject

This independent verification is one of the key properties of blockchain systems.

Mempool

A mempool is a node’s temporary collection of valid pending transactions that have not yet been included in a block.

1
2
3
4
5
transaction submitted
→ node validates it
→ mempool
→ block producer selects it
→ block

There is not necessarily one global mempool.

Because transactions propagate through a peer-to-peer network, different nodes can temporarily have slightly different pending transaction sets.

This is why an application may show:

1
Pending...

after a user has already submitted a transaction.

Block Producers

A block producer is the participant responsible for proposing the next block.

It typically:

1
2
3
4
5
reads pending transactions
→ chooses transactions
→ orders them
→ builds candidate block
→ proposes block

The mechanism used to determine who becomes the block producer depends on the consensus system.

1
2
Proof of Work  → miner
Proof of Stake → selected validator

After a block is proposed, other nodes still independently validate it.

Consensus

Consensus is how independent participants converge on one canonical blockchain history without a central authority.

It needs to answer questions such as:

1
2
3
Is this block valid?
Which valid chain should nodes follow?
What is the current canonical state?

Consensus does not mean that nodes simply vote on whether each transaction looks acceptable.

First, each node can independently apply deterministic protocol rules:

1
2
3
4
5
6
7
same previous state
+
same transactions
+
same execution rules
=
same resulting state

Consensus becomes especially important when multiple valid candidate blocks or chains temporarily exist.

1
2
3
4
5
            Block A
           /
Previous Block
           \
            Block B

The consensus protocol defines how the network eventually converges on one canonical history.

Proof of Work

Proof of Work (PoW) uses computational work to determine who can produce a valid block.

In Bitcoin, miners repeatedly try different values until the block hash satisfies the network’s difficulty requirement.

1
2
3
4
5
6
7
8
9
candidate block
+
changing nonce
↓
hash
↓
does it satisfy difficulty?
    ├── no  → try again
    └── yes → valid PoW

This creates an important asymmetry:

1
2
finding valid Proof of Work → expensive
verifying Proof of Work     → cheap

The successful miner can propose the block, but other nodes independently verify both the Proof of Work and the block contents before accepting it.

PoW therefore helps:

  • select block producers;
  • make block production costly;
  • make rewriting blockchain history economically expensive.
1
2
Block Producer = role
Proof of Work  = one mechanism for selecting/securing that role

Proof of Stake

Proof of Stake (PoS) uses economic stake rather than computational mining to secure the network.

Participants lock assets to become validators.

1
2
3
4
stake assets
→ become validator
→ participate in block production / validation
→ earn rewards

Validators have economic value at risk.

1
2
3
4
5
6
honest participation
→ rewards

protocol violations
→ penalties
→ potentially slashing

The important distinction is:

1
2
PoW → security through computational cost
PoS → security through economic stake

Stake does not allow validators to arbitrarily decide whether transactions are valid. Transactions and blocks still need to follow deterministic protocol rules.

PoS Consensus

A simplified PoS flow looks like:

1
2
3
4
5
6
7
8
9
10
11
12
13
validator selected to propose block
↓
proposes candidate block
↓
other validators independently verify it
↓
validators attest to the valid chain
↓
protocol applies fork-choice rules
↓
network converges on canonical chain
↓
eventual finality

Consensus therefore combines several ideas:

1
2
3
4
5
6
7
validity rules
+
validator participation
+
fork-choice rules
+
finality rules

Finality

A transaction being included in a block does not always mean it is immediately irreversible.

Typical lifecycle:

1
2
3
4
5
submitted
→ pending
→ included
→ confirmed
→ finalized

Finality means the protocol considers that part of blockchain history effectively irreversible under its security assumptions.

Applications may use different confirmation thresholds depending on risk.

1
2
3
4
5
small UI update
→ may react after inclusion

high-value settlement
→ may wait for stronger finality

Transaction Fees

Blockchain computation and block space are limited resources, so transactions generally pay fees.

Fees serve several purposes:

  • compensate network participants;
  • prioritize access to limited block space;
  • discourage spam and resource abuse.

The exact fee mechanism depends on the blockchain.

Ethereum-specific gas mechanics are covered separately in the Ethereum section.

On-Chain vs Off-Chain

On-chain operations are recorded, executed, or verified by the blockchain.

Examples:

1
2
3
4
asset ownership
transfers
contract state
transaction history

On-chain operations inherit blockchain guarantees but tend to be slower and more expensive than traditional server/database operations.

Off-chain systems operate outside the blockchain.

Examples:

1
2
3
4
5
6
7
backend APIs
databases
caches
search
analytics
indexers
notifications

Most production Web3 applications combine both:

1
2
3
4
5
6
7
8
9
10
11
Blockchain
├── ownership
├── settlement
└── verifiable state

Off-Chain Systems
├── indexing
├── search
├── caching
├── notifications
└── application metadata

End-to-End Blockchain Flow

At a high level:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
User
↓
Wallet creates + signs transaction
↓
Node validates transaction
↓
Mempool
↓
Block Producer
↓
Candidate Block
↓
Other Nodes Validate
↓
Consensus
↓
Canonical Chain
↓
Finality

The major responsibilities are:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Private Key / Signature
→ Who authorized the transaction?

Address
→ Which account or destination is referenced?

Transaction Validation
→ Does the transaction obey blockchain rules?

Mempool
→ Where does a valid pending transaction wait?

Block Producer
→ Who proposes the next block?

Node Validation
→ Is the proposed block actually valid?

Consensus
→ Which valid blockchain history becomes canonical?

Finality
→ When is that history effectively irreversible?

Ethereum Basics

EOA vs Contract Accounts

Ethereum has two main account types:

  • EOA (Externally Owned Account): controlled by a private key.
  • Contract Account: controlled by smart contract code.
1
2
3
4
5
6
7
EOA
→ controlled by private key
→ can initiate transactions

Contract Account
→ controlled by code
→ executes when called

A contract account does not independently initiate transactions like an EOA. Its code runs when triggered by an external transaction or another contract.

EVM

The EVM (Ethereum Virtual Machine) is the execution environment that runs smart contract bytecode.

1
2
3
4
5
Solidity source
↓ compile
EVM bytecode
↓
EVM executes

Ethereum nodes execute the same contract code with the same input and previous state, allowing them to independently verify the resulting state.

1
2
3
4
5
6
7
same state
+
same transaction
+
same contract code
=
same result

This deterministic execution is a key part of Ethereum’s trust model.

Nonce

For an Ethereum EOA, the nonce is essentially the account’s transaction sequence number.

1
2
3
4
nonce 0
nonce 1
nonce 2
...

It helps:

  • preserve transaction ordering;
  • prevent replaying the same signed transaction;
  • identify the next valid transaction from an account.
1
2
3
4
5
6
7
Alice current nonce = 5

next transaction
→ nonce = 5

after execution
→ Alice nonce = 6

Bitcoin does not use this account-level nonce model.

Bitcoin instead uses the UTXO model.

UTXO

UTXO stands for Unspent Transaction Output.

Bitcoin tracks spendable outputs rather than maintaining a simple account balance.

1
2
3
4
5
6
Alice owns:

UTXO A = 2 BTC
UTXO B = 3 BTC

Balance = 5 BTC

To send 4 BTC:

1
2
3
4
5
6
Inputs:
2 BTC + 3 BTC

Outputs:
4 BTC → Bob
1 BTC → Alice (change)

The original UTXOs become spent, while the new outputs become new UTXOs.

1
2
3
4
5
Ethereum
→ account balance + nonce

Bitcoin
→ UTXO set

Because a spent UTXO cannot be spent again, Bitcoin does not need Ethereum’s account nonce mechanism for replay prevention.

Gas

Gas measures the computational resources consumed by Ethereum operations.

Different EVM operations consume different amounts of gas.

1
2
3
4
5
simple ETH transfer
→ relatively low gas

complex smart contract call
→ higher gas

A simplified fee model is:

1
2
3
transaction fee
≈
gas used × effective gas price

Gas serves two important purposes:

  • users pay for limited blockchain computation and block space;
  • contracts cannot execute unlimited computation for free.

Gas is not limited to smart contracts. Even a normal ETH transfer consumes gas.

Bitcoin also has transaction fees, but it does not use Ethereum-style gas accounting.

1
2
3
4
5
Bitcoin fee
≈ transaction size × fee rate

Ethereum fee
≈ gas used × gas price

Bitcoin primarily charges for block space, while Ethereum also explicitly meters computation.

Transactions ( Ethereum )

An Ethereum transaction is a signed instruction sent from an EOA.

It may:

  • transfer ETH;
  • call a smart contract;
  • deploy a smart contract.

Conceptually:

1
2
3
4
5
6
7
Transaction
├── to
├── value
├── data
├── nonce
├── gas settings
└── signature

The sender is cryptographically derived/verified from the transaction signature rather than simply trusted from a user-provided from field.

For a contract call, the data field contains encoded information describing which function to execute and what arguments to pass.

1
2
3
4
5
EOA
↓ signed transaction
Contract Address
↓
function + arguments encoded in data

Smart Contracts

A smart contract is deterministic code stored and executed on the blockchain.

It can be thought of as shared application logic whose execution can be independently verified by network participants.

1
2
3
4
5
transaction
→ contract code executes
→ state transition produced
→ other nodes verify the same execution
→ consensus accepts canonical state

The trust does not come from trusting one application server.

Instead, it comes from:

1
2
3
4
5
6
7
shared contract code
+
deterministic execution
+
independent verification
+
blockchain consensus

For example, an escrow contract could enforce:

1
2
3
4
5
6
7
Buyer deposits ETH
↓
contract holds funds
↓
agreed condition is satisfied
↓
contract allows Seller to receive funds

Every validating node applies the same rules.

Smart contracts can:

  • store persistent state;
  • transfer assets;
  • enforce application rules;
  • call other contracts;
  • emit events.

Events / Logs

Smart contracts can emit events during execution.

1
2
3
4
5
event Transfer(
    address from,
    address to,
    uint256 amount
);

These become transaction logs:

1
2
3
4
Smart Contract
→ emit event
→ transaction receipt / logs
→ frontend / backend / indexer reads them

Events are commonly used for:

  • token transfers;
  • order creation;
  • ownership changes;
  • application indexing;
  • notifications.

Events are especially useful because applications can observe what happened without repeatedly scanning all contract storage.

Storage / Memory / Calldata

Solidity uses different data locations depending on how long the data should live and how it is used.

Example:

1
2
3
4
5
6
7
8
9
10
11
contract UserRegistry {
    string public ownerName; // storage

    function updateName(
        string calldata newName
    ) external {
        string memory temp = newName;

        ownerName = temp;
    }
}

Storage

storage is persistent blockchain state.

1
string public ownerName;

If:

1
ownerName = "Alice";

then the value survives after the transaction finishes.

1
2
3
4
5
Block N
ownerName = Alice

Block N+1
ownerName = Alice

A useful analogy:

1
storage ≈ database

Changing storage is relatively expensive because the resulting state must be persisted by the blockchain.

Memory

memory contains temporary data used during one EVM execution.

1
string memory temp = newName;
1
2
3
4
5
function starts
→ memory created
→ temp used
→ function ends
→ memory discarded

A useful analogy:

1
memory ≈ local variables / temporary RAM

Calldata

calldata contains read-only input passed into an external contract call.

1
2
3
function updateName(
    string calldata newName
) external

If a frontend calls:

1
contract.updateName("Bob")

the function selector and "Bob" are encoded into transaction/call data.

1
2
3
4
Frontend
→ contract.updateName("Bob")
→ encoded calldata
→ EVM

A useful analogy:

1
calldata ≈ request body / function arguments

So the practical mental model is:

1
2
3
4
5
6
7
8
9
10
11
Storage
= persistent blockchain state
≈ database

Memory
= temporary execution data
≈ local variables

Calldata
= read-only external input
≈ request body

Ethereum Transaction Execution Flow

Putting everything together:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
EOA
↓
create transaction
↓
include nonce + gas + to + value + data
↓
sign with private key
↓
broadcast to network
↓
transaction included in block
↓
EVM executes transaction
↓
contract state may change
↓
events / logs may be emitted
↓
nodes verify resulting state
↓
new canonical Ethereum state

A useful summary:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
EOA
→ who initiates the transaction?

Nonce
→ which transaction in this account's sequence?

Gas
→ how much computation/resource usage is allowed and paid for?

EVM
→ where contract code executes?

Smart Contract
→ what deterministic application logic runs?

Storage
→ what persistent state changes?

Events
→ what observable logs are emitted?

Comments

Follow
×