DEV Community: Sakramen

Nodes and Networks: How Blockchains Actually Stay Decentralized

Sakramen — Mon, 10 Aug 2026 06:25:43 +0000

When someone says "Bitcoin has over 15,000 nodes worldwide," they mean 15,000+ independent computers are each running Bitcoin software and each maintaining their own full copy of the blockchain. No server owns the truth. Every node checks it for itself.

That single fact — every node independently verifies every transaction and block against protocol rules — is the reason blockchains don't need a central authority. If one node tries to cheat, the rest simply ignore it. There's no admin account to compromise because there's no admin.

Not All Nodes Do the Same Job

Full Node

Downloads and stores the entire blockchain, every block since genesis, and independently validates everything against consensus rules.

Highest security
~500 GB for Bitcoin
~1 TB for Ethereum

This is the backbone of network security. A full node doesn't trust anyone's summary of the chain; it recomputes validity itself.

Light Node (SPV)

Stores only block headers, not full transaction data. Uses Merkle proofs and relies on full nodes to verify transactions.

Low storage, ~50 MB
Trusts full nodes for verification
What most mobile wallets run

Mining/Validator Node

A full node that also participates in block creation. Miners (Proof of Work) solve computational puzzles; validators (Proof of Stake) stake cryptocurrency as collateral. Both earn rewards for securing the network.

Creates new blocks
Earns rewards
Requires specialized hardware (PoW) or capital at stake (PoS)

Archive Node

Everything a full node stores, plus historical state at every block height.

Complete history
~15+ TB for Ethereum
Used by explorers, analytics platforms, and enterprise tooling

Why Peer-to-Peer Instead of Client-Server

A traditional web service is client-server: your browser requests data from a company's servers. If those servers go down, the service is unavailable. That's a single point of failure by design.

Blockchain networks use peer-to-peer (P2P) architecture instead. Every participant is simultaneously a client and a server. Nodes connect directly to each other, typically maintaining 8-20 peer connections, and information spreads through the network like gossip: each node tells its peers, who tell their peers, until everyone has it.

How a Transaction Actually Propagates

You submit a transaction from your wallet. It goes to whichever node your wallet is connected to.
That node validates it: correct format, valid signature, sufficient balance. Invalid transactions get rejected right there.
If valid, the node broadcasts it to its 8-20 connected peers.
Each peer independently validates and rebroadcasts to its own peers. The transaction spreads exponentially.
Within seconds, the transaction has reached nodes worldwide and is sitting in mempools, waiting to be included in a block.

No central router coordinates this. It's just repeated local validation and rebroadcast, scaled across thousands of independent machines.

Why This Architecture Is Hard to Kill

Geographic distribution: nodes run on every continent, so a regional outage or disaster can't take the network down.
No single point of failure: even if 90% of nodes went offline, the remaining 10% could keep the network operating.
Censorship resistance: no central authority can block a transaction. If one node refuses to process it, thousands of others will.
Self-healing: nodes that go offline can rejoin later and automatically sync the blocks they missed from peers.

What It Takes to Run One Yourself

Requirement	Bitcoin Full Node	Ethereum Full Node
Storage	500+ GB SSD	1+ TB NVMe SSD
RAM	2+ GB	16+ GB
Internet	Unmetered, 50+ Mbps	Unmetered, 100+ Mbps
Initial Sync Time	1-7 days	2-14 days

Running your own full node gets you a few concrete things: your transactions aren't routed through someone else's infrastructure, you're verifying against your own copy of the rules instead of trusting a third party's node, and you're adding to the pool of validators that makes the network harder to disrupt.

Closing

The short version: nodes are computers running blockchain software, each holding a copy of the ledger. Full nodes validate everything independently; light nodes lean on full nodes for verification through Merkle proofs. There's no central server, connections are peer-to-peer, and data spreads by gossip. That combination is what makes these networks resilient and hard to censor.

Full lesson, free: https://neutralblock.com/learn/fundamentals/blockchain-fundamentals/nodes-and-networks

Purple Teaming: Closing the Loop Between Attack and Detection

Sakramen — Sun, 09 Aug 2026 16:25:35 +0000

The Problem With Traditional Red Team Reports

A standard red team engagement works like this: the offensive team operates covertly, tries to achieve objectives without being caught, and delivers a report at the end summarizing what worked. The blue team reads it, maybe weeks or months later, and has to reverse-engineer exactly which detection failed and why.

Meanwhile blue teams often write detection rules in isolation, without ever confirming those rules actually fire against a real execution of the technique they're meant to catch. Two teams, two blind spots, no feedback loop.

Purple teaming is the fix: red and blue work together, in real time, so that every attack execution is immediately paired with a detection check.

A Concrete Example: DCSync

Say the red team executes a DCSync attack against Active Directory, which abuses domain replication to pull password hashes.

In a traditional engagement, the report just says "DCSync was successful." In a purple team exercise, the blue team is watching the SIEM, EDR, and domain controller logs while the attack runs. If nothing alerts, both teams stop and figure out why immediately. Two common causes:

The SIEM has no rule for DsGetNCChanges replication requests originating from a non-domain-controller host.
The relevant Windows event (Event ID 4662) isn't even being collected.

The blue team writes and deploys the detection rule on the spot. The red team re-executes the exact same attack to confirm the new rule fires with an alert an analyst could actually act on. That's the whole point: verified, not assumed.

MITRE ATT&CK as the Shared Language

Purple teaming needs a common vocabulary so both teams are testing and measuring the same thing. MITRE ATT&CK provides that: a catalog of adversary techniques organized under tactical objectives like initial access, execution, persistence, privilege escalation, defense evasion, credential access, discovery, lateral movement, collection, exfiltration, and command and control.

Teams use ATT&CK to pick which techniques to test in a given session, track what's covered across the matrix over time, and prioritize based on techniques known to be used by threat actors relevant to their industry.

Exercise Structure

A purple team exercise generally follows six steps:

Scope and prioritize — pick ATT&CK techniques based on threat intel for your industry. You can't test everything in one sitting.
Baseline detection — document what rules, log sources, and response procedures already exist for each chosen technique, before anything is executed.
Execute and observe — red runs each technique while blue watches every detection layer: SIEM, EDR, NDR, firewall logs. Both sides document what happened.
Analyze gaps — for each technique, determine if it was detected, at which layer, how long it took, and whether the alert gave an analyst enough context to investigate.
Remediate and retest — build or tune detections for the gaps found, then re-run the attack to confirm the fix works with acceptable fidelity.
Document and track — log everything in an ATT&CK coverage heatmap. This becomes an ongoing detection maturity scorecard.

Atomic Red Team

Atomic Red Team is an open-source library of small, focused test scripts, each mapped to a specific ATT&CK technique. An "atomic test" does one thing: dump LSASS memory, create a scheduled task for persistence, run DNS tunneling, and so on.

They're designed to be safe to run in production with proper authorization, which makes them the practical building blocks of a purple team exercise. Instead of designing a custom attack script for every technique, teams pull an atomic test off the shelf and work through the ATT&CK matrix systematically.

Metrics That Matter

Metric	Description	Target
Detection Coverage	% of tested ATT&CK techniques with working detections	Increase each quarter
Mean Time to Detect	Average time from attack execution to alert generation	Under 5 minutes for priority techniques
Alert Fidelity	True positive vs. false positive ratio per rule	Above 80% true positive rate
Response Completeness	Whether runbooks cover all investigation/containment steps	Full coverage for top 50 techniques

These give you something a narrative pentest report doesn't: a trackable scorecard of detection maturity over time, not just a snapshot of what one red team happened to bypass on one particular day.

Why It's Worth Adopting

Purple teaming turns security testing from a periodic, adversarial exercise into an ongoing, collaborative one. Instead of finding out three months later that a technique slipped through, you find out immediately, fix it immediately, and verify the fix immediately.

The full lesson, with the complete exercise framework and metrics breakdown, is free here: Purple Teaming