Blockchain Network Design Space

Five groups of network design decisions

Design decisions when designing a blockchain network can be organized into five groups¹:

Full Node Decisions

Three decisions:

• Mapping between full node and participants: Who has the right to have a full node?
  • One-to-many: one full node serving many participants. This is the case with many early day blockchain applications.
  • One-to-one: one full node for each participant.
  • Many-to-one: each participant has many full nodes, for instance when they want different internal groups of the participant to interact with the blockchain and maintain their own record.
  • Public: open space, any one can have their node
• Deployment of full nodes: Where do those full node exist?
  • Same cloud: all full nodes exist in the same cloud
  • Multiple clouds: full nodes spread across different cloud service or infrastructure
  • Hybrid clouds: half public, half private cloud
  • Networked computers: full nodes running on bare machines. Commonly found in fog and edge situation in blockchain.
• Mining distribution: Who has the right for those full nodes?
  • All
  • One
  • M-out-of-N
  • Public

Lightweight Node Decisions

Two decisions:

• Number of lightweight nodes
  • Context dependent
• Lightweight node deployment
  • Context dependent

Remote Node Decisions

Remember that remote nodes are wallets and other kind of client-side libraries such as Web3js to interact with the full nodes.

Two decisions:

• Mapping between remote node and participants
  • One-to-many: one remote node serving multiple participants
  • One-to-one: each participant has one remote node
  • Many-to-one
  • Public
• Deployment of remote nodes
  • Standalone
  • Embedded in application

Network Interface Decisions

Two decisions, governing how remote nodes would interface with the blockchain network.

• Interface Type:
  • RPC API
  • IPC
  • API
  • Serverless Functions
• Interface Deployment
  • Standalone
  • Embedded in full node
  • Embedded in lightweight node

Node Communication Decisions

These decisions govern how blockchain clients interact with each other

Two decisions:

• Peer communication protocol type
  • Gossip-based
  • Unicast
• Node discovery
  • Static peer list
  • Dynamic via gossip protocols
  • Dynamic via registries

Three groups of protocol design decisions

State-Machine

Decisions in this group concern with how the state-machine for executing transactions are designed.

Four decisions:

• State Model
  • UTXO
  • Account
  • Key-value
• Smart Contract Model
  • Non
  • On-chain
  • Installed
• Virtual Machine
  • EVM
  • JVM
  • Docker
• Validator
  • None
  • Uniqueness
  • Syntax-only
  • Semantic

Consensus

This decision concerns with how the state-machines deployed on different blockchain nodes are synchronized.

One decision:

• Consensus Protocol
  • Byzantine Fault and Sybil Tolerant
  • Byzantine Fault Tolerant
  • Crash-tolerant

Enterprise Extensions

This decision concerns with enterprise extensions beyond the basics of blockchain networks.

Three decisions:

• Identity Model
  • None
  • X.509 Certificate
• Authentication and Authorization
  • None
  • Digital Certificate
• Privacy Preserving
  • None
  • State Segmentation
  • Private Channel