Blockchain Technical Evolution and Core System Architecture

These cryptographic primitives form the foundational trust layer of blockchain systems, but their application in distributed ledger design introduces unique engineering tradeoffs that define the performance and security profile of every major chain. For instance, Bitcoin’s choice to apply double SHA-256 hashing to both block headers and transaction IDs is not arbitrary: a single SHA-256 hash is vulnerable to length extension attacks, where an adversary can append arbitrary data to an input and compute a valid hash without knowing the original input. By hashing twice, Bitcoin eliminates this attack vector with minimal computational overhead, a design decision validated by 15 years of uninterrupted mainnet operation. Similarly, the selection of the secp256k1 elliptic curve for Bitcoin’s ECDSA signature scheme over the widely used NIST P-256 curve stems from a deliberate effort to avoid potential NSA backdoors in standardized curves, a concern that remains relevant for permissionless systems where trust minimization is a core requirement.

The structure of the distributed ledger itself is a direct product of these cryptographic choices, with two dominant models emerging to solve the double-spend problem: the Unspent Transaction Output (UTXO) model used by Bitcoin and its derivatives, and the account-based model popularized by Ethereum and EVM-compatible chains. To illustrate the practical difference between these models, consider a 0.5 BTC transfer from Alice to Bob on Bitcoin: Alice’s wallet first selects a set of unspent UTXOs she controls (e.g., a 1 BTC UTXO from a prior transaction), creates a new transaction that spends this input, and generates two new outputs: 0.5 BTC assigned to Bob’s public key hash, and 0.499 BTC assigned to a new change address controlled by Alice (the 0.001 BTC difference is paid as a transaction fee to the miner). Every output in this transaction is a new, independent UTXO that can only be spent in a future transaction with a valid signature from the recipient’s private key. This design enforces a strict, immutable ledger of value transfers, but introduces complexity for stateful applications: a smart contract on Bitcoin cannot natively track a user’s balance without building a custom UTXO indexing layer. In contrast, Ethereum’s account model stores user balances directly in the global state trie: when Alice sends 0.5 ETH to Bob, the state trie is updated to deduct 0.5 ETH (plus gas fees) from Alice’s account and credit 0.5 ETH to Bob’s account, with no intermediate UTXO objects. This design simplifies state queries and enables complex smart contract logic, but introduces new attack vectors such as reentrancy, where a malicious contract can recursively call a vulnerable contract’s withdrawal function before the state is updated to reflect the balance deduction.

The efficiency of Merkle trees in both models cannot be overstated: a Merkle proof for a transaction in a block containing 1 million transactions requires only 20 hash values (log₂(1,000,000) ≈ 20) to verify inclusion, regardless of block size. This property enables light clients to validate transactions without downloading the full blockchain: a Bitcoin SPV (Simplified Payment Verification) client only needs to store block headers (80 bytes per block, ~10 GB total for 15 years of Bitcoin history) and request Merkle proofs from full nodes to confirm a transaction is included in a block. For enterprise use cases where data privacy is a requirement, variants of Merkle trees such as the Patricia Merkle Trie (used by Ethereum) enable efficient verification of specific state entries without exposing the full state: a supply chain application can prove that a specific batch of goods was marked as "shipped" in the ledger without revealing the details of other shipments in the same block.

<!-- 纸书：表1-1 UTXO与账户模型核心特性对比 --> | 特性 | UTXO模型（比特币） | 账户模型（以太坊） | |---------------------|-------------------------------------------|-------------------------------------------| | 状态存储 | 无全局状态，仅存储未花费输出 | 全局状态树存储所有账户余额和合约状态 | | 并行验证能力 | 高，UTXO之间无依赖，可并行验证 | 低，交易之间存在状态依赖，需顺序执行 | | 智能合约支持 | 有限，需通过脚本实现复杂逻辑 | 原生支持图灵完备智能合约 | | 隐私性 | 较高，每笔交易生成新UTXO，地址可轮换 | 较低，所有交易关联永久公开的账户地址 | | 状态查询效率 | 低，需遍历UTXO集计算余额 | 高，直接查询状态树即可获取余额 | <!-- 电子版：侧边栏提示：为什么UTXO模型的并行验证能力更高？因为每个UTXO都是独立的，没有状态依赖，矿工可以同时验证多笔交易的输入是否有效，而账户模型的交易需要按顺序执行，因为后一笔交易可能依赖前一笔的状态变更。 --> <!-- Markdown：#UTXO模型 #账户模型 #状态存储 -->

The peer-to-peer (P2P) networking layer is the often-overlooked infrastructure that enables blockchain’s decentralized operation, with design choices that directly impact transaction propagation speed, network resilience, and attack resistance. Bitcoin’s original P2P protocol uses a flood-and-forward gossip mechanism with built-in anti-DoS protections: when a node receives a new transaction, it first validates the transaction’s signature, checks that the input UTXOs are unspent, and confirms the transaction fee meets the minimum relay threshold before forwarding it to its 8-125 adjacent peers. To prevent broadcast storms, nodes maintain a recent transaction inventory (inv) cache and only forward transactions they have not previously seen, with a time-to-live (TTL) of 3 hops to limit unnecessary network traffic. As of 2024, a typical Bitcoin transaction propagates to 90% of the network’s 15,000 full nodes in under 2 seconds, a speed that is sufficient for Bitcoin’s 10-minute block time but inadequate for high-throughput use cases.

Modern blockchains have adopted more sophisticated networking stacks to address these limitations. Ethereum’s DevP2P protocol separates node discovery (via a Kademlia DHT for peer routing) from transaction/block propagation, while newer chains like Solana and Sui use libp2p, a modular networking library that supports multiplexed connections, NAT traversal, and encrypted transport by default. These improvements reduce propagation latency to under 500ms for most transactions, enabling sub-second block finality. However, P2P networks remain vulnerable to eclipse attacks, where an adversary controls all of a target node’s peer connections and feeds it false blockchain state to double-spend or censor transactions. Bitcoin mitigates this risk via an "address bucket" strategy: new nodes connect to peers across 8 distinct /24 IP subnets to ensure they receive a diverse view of the network, while Ethereum’s node discovery protocol uses UDP hole punching to establish direct connections with peers outside the target’s local network, making it far harder for an attacker to isolate a node.

The classification of blockchain architectures into public, private, and consortium chains is not merely a semantic distinction, but a reflection of fundamental tradeoffs in trust, permissioning, and performance. Public permissionless chains like Bitcoin and Ethereum allow any participant to join the network, submit transactions, and run a full node without approval, with security derived from the economic incentives of a large, decentralized set of validators. This design maximizes censorship resistance and trust minimization, but comes at the cost of low throughput: Bitcoin processes a maximum of 7 transactions per second (TPS) due to its 1 MB block size and 10-minute block time, while Ethereum’s pre-merge PoW chain processed ~15 TPS. Private permissioned chains, by contrast, restrict network access to a single organization, with validators operated by trusted internal nodes. This design eliminates the need for Sybil resistance mechanisms (since all validators are known) and enables TPS in the tens of thousands, but sacrifices the decentralization and censorship resistance that make public chains valuable for open use cases. Consortium chains occupy the middle ground, with access restricted t