Refers to the physical and logical layout of the network's hardware and software components.

• Node Distribution: The number of independent, physical servers (nodes) running the protocol software. A higher, globally distributed count increases resilience.
• Client Diversity: The use of multiple, independently developed software implementations (e.g., Geth, Erigon, Nethermind for Ethereum) to prevent a single bug from taking down the network.
• Redundancy: Every full node maintains a complete copy of the ledger, eliminating single points of data failure.

Concerns the control over the protocol's rules and its future development.

• Governance Models: How upgrade decisions are made, ranging from off-chain social consensus (Bitcoin, Ethereum) to on-chain token voting (DAO-based protocols).
• Development Teams: Multiple independent core development teams reduce reliance on a single entity. Ethereum's development is led by the Ethereum Foundation but includes ConsenSys, Nethermind, and others.
• Forkability: The ability for the community to reject proposed changes by continuing the original chain, as seen with Ethereum Classic.

Defines the structure and unity of the system's data and state.

• Monolithic vs. Modular: A monolithic blockchain (like early Ethereum) handles execution, settlement, and data availability on one layer. Modular designs (like Ethereum with rollups) separate these functions.
• Data Availability: Ensuring block data is published and accessible so anyone can verify the chain's state. Dedicated data availability layers (e.g., Celestia, EigenDA) address this.
• Atomic Composability: The ability for transactions and smart contracts across the system to interact seamlessly as a single logical machine.

Focuses on the distribution of value and financial incentives within the network.

• Token Distribution: How the native token is initially allocated and subsequently held. Widespread distribution is preferable to concentrated ownership.
• Mining/Staking Power: In Proof-of-Work, the hash rate should not be controlled by a few pools. In Proof-of-Stake, staked tokens should be distributed among many validators.
• MEV (Maximal Extractable Value): The profit validators can extract by reordering transactions. Solutions like MEV-Boost on Ethereum aim to democratize access to this value.

The network's ability to process transactions from any participant without interference.

• Permissionless Validation: Anyone can run a node to validate transactions without needing approval from an authority.
• Transaction Inclusion: Validators or miners should not be able to reliably block transactions from specific addresses. Techniques like commit-reveal schemes or encrypted mempools can enhance this.
• Regulatory Resilience: A key measure is the Liveness Assumption—the network continues to produce blocks even if a subset of actors is forced to censor.

A critical yet often overlooked principle that underpins network health.

• Execution Clients: As of 2024, Ethereum's mainnet execution layer uses Geth (~84%), Nethermind (~10%), Besu (~5%), and Erigon (~1%). The goal is a more even distribution.
• Consensus Clients: Diversity here is stronger, with Prysm, Lighthouse, Teku, and Nimbus all holding significant share.
• RPC Providers: Over-reliance on centralized RPC endpoints (like Infura or Alchemy) creates a central point of failure. The push is towards self-hosted nodes or decentralized alternatives.

The Gini Coefficient quantifies inequality in resource distribution among participants. A score of 0 represents perfect equality; a score of 1 represents maximum inequality.

• Lorenz Curve is the graphical representation, plotting the cumulative share of participants against the cumulative share of the resource.
• In blockchain, this measures the distribution of tokens, staking power, or block production rewards. A more decentralized network will have a Gini Coefficient closer to 0, showing a less concentrated distribution of key resources.

This assesses how decision-making power is distributed. Key metrics include:

• Proposal Power: Number and distribution of unique addresses submitting successful governance proposals.
• Voting Power: Concentration of voting tokens (e.g., how many entities hold the majority of DAO voting power). Use the Nakamoto Coefficient here.
• Participation Rate: Percentage of eligible tokens that vote on proposals.
• Delegate Distribution: In delegated systems like Compound or Uniswap, analyze the concentration of votes among top delegates.

Physical and infrastructural distribution prevents single points of failure.

• Geographic Decentralization: Mapping the physical locations of node operators and validators across countries and jurisdictions. Concentration in one country creates regulatory risk.
• Network Topology: Analyzing how nodes are interconnected. An ideal mesh network where nodes connect to many peers is more resilient than a hub-and-spoke model reliant on a few large nodes. Tools like eth-netstats or libp2p monitoring can visualize this.

Measures control over the core protocol rules and codebase.

• Code Repository Commits: Analyze the number of unique, significant contributors to the core repository over time.
• Decision-Making Process: Is there a formal, on-chain governance process (e.g., Polkadot, Cosmos), or do core developers have informal "benevolent dictator" control?
• Upgrade Keys: For networks with upgradeable smart contracts (like many L2s), who holds the administrative keys? The goal is to move from multi-sigs to immutable contracts or time-locked DAO control.

The core challenge of balancing three key properties: decentralization, security, and scalability. A network can typically optimize for only two at the expense of the third.

• Ethereum historically prioritized decentralization and security, leading to high gas fees.
• Solana and other high-throughput chains increase scalability and security by using fewer, more powerful validators, which reduces decentralization.
• Layer 2 solutions like Optimism and Arbitrum attempt to resolve this by moving computation off-chain while inheriting Ethereum's security.

Decentralized decision-making is slow and complex. Achieving consensus on protocol upgrades without a central authority can lead to forks and fragmentation.

• Bitcoin upgrades require near-unanimous miner support, leading to slow evolution (e.g., the SegWit activation).
• Ethereum uses off-chain social consensus and on-chain governance for its improvement proposals (EIPs).
• DAO-based governance (e.g., Uniswap, Compound) can suffer from voter apathy, where a small number of large token holders control outcomes.

Fully decentralized networks with thousands of nodes must synchronize state, which inherently limits transaction speed and capacity compared to centralized systems.

• Bitcoin processes ~7 transactions per second (TPS).
• Ethereum (pre-merge) handled ~15-30 TPS.
• Centralized payment systems like Visa can process over 65,000 TPS. This performance gap is a direct trade-off for censorship resistance and distributed trust.

Decentralized networks using Proof of Work or Proof of Stake have probabilistic finality. Transactions are never 100% irreversible, creating a trade-off between security assurance and settlement speed.

• Bitcoin recommends waiting for 6 block confirmations (~1 hour) for high-value transactions, as the probability of a reorganization decreases exponentially.
• Networks with faster block times (e.g., Solana at 400ms) have a higher risk of chain reorganizations, requiring different security assumptions.
• Finality gadgets (like Ethereum's Casper-FFG) are used to provide stronger guarantees.

To participate in validation, nodes must store and process the entire blockchain state. This creates high hardware requirements that can centralize node operation.

• The Ethereum full node requirement is over 1 TB of SSD storage, limiting who can run a node.
• Solutions like data availability sampling (used by Celestia and Ethereum Proto-Danksharding) aim to keep node requirements low while scaling data capacity.
• If storage costs become prohibitive, the network risks becoming validated by only a few wealthy entities.

Decentralization shifts responsibility and risk to the end-user, creating significant UX friction compared to web2 applications.

• Users must manage private keys and seed phrases with no recovery service.
• Transaction fees (gas) are unpredictable and require native tokens.
• Interacting with smart contracts directly exposes users to irreversible errors and scams.
• This complexity is a major barrier to mainstream adoption, pushing some applications to adopt more centralized custodial models for ease of use.