← Proposals / Blockchain Infrastructure

Blockchain Infrastructure

Commons Currency will be implemented on a blockchain-based ledger purpose-built for global scale and public sector use. The architecture leverages modern high-performance designs that achieve massive scalability natively—delivering a user experience anyone can use.

Design Philosophy

The Commons blockchain will leverage modern architectures that achieve massive scalability natively, delivering a user experience that anyone can use—without requiring users to bridge funds between layers or manage multiple wallets.

Users simply transact in Commons Units without ever thinking about technical complexity. Whether sending $5 to a friend or settling a billion-dollar inter-bank transfer, it's all the same seamless experience on one blockchain.

Modern High-Performance Architecture

Proven Approaches

Examples of architectures that achieve our performance goals:

• Flow's multi-role architecture: Separate nodes for consensus, computation, verification, and storage enable high throughput without fragmenting the user experience
• Aptos's parallel execution: Using Block-STM technology, Aptos achieves 160,000+ transactions per second on a single unified chain
• Sui's object-centric model: Parallel transaction processing for independent objects enables massive scalability

Key Techniques

• Parallel execution engines: Process independent transactions simultaneously rather than sequentially
• Pipelined architecture: Overlap consensus, execution, and verification stages for maximum throughput
• Efficient state management: Optimized data structures minimize storage and lookup overhead
• Fast finality: Sub-second confirmation times for all transactions

Consensus Mechanism

Byzantine Fault Tolerant Consensus

The blockchain uses a permissioned validator set comprised of member nations' nodes, with Byzantine Fault Tolerant consensus such as HotStuff or AptosBFT.

Key properties:

• Safety: No conflicting transactions can both be confirmed
• Liveness: System continues making progress even if some nodes are offline
• Finality: Once confirmed, transactions are irreversible (no forks or reorganizations)
• Fault tolerance: Can tolerate up to 1/3 of nodes behaving maliciously or failing

Consensus Protocol Details

HotStuff-style BFT implementation with optimizations:

• Three-phase commit: Prepare → Pre-commit → Commit (with leader rotation)
• Aggregated signatures: Use BLS signatures to reduce message complexity from O(n²) to O(n)
• Leader rotation: Automatic leader rotation each epoch (approximately 10 seconds) ensures no single nation controls block production
• Threshold signatures: 2/3 + 1 validators must sign for finality (≥134 out of 200 nations)
• View-change protocol: If leader fails, validators automatically elect new leader within 3 seconds
• Pipelined consensus: Multiple blocks in different stages simultaneously for maximum throughput

Design Targets

With approximately 200 nation-state validators, the system is designed to achieve:

• Throughput: High transaction capacity with room to scale as technology advances
• Latency: Sub-second transaction finality (targeting 300-500ms)
• Energy: Energy-efficient BFT consensus (no mining required)
• Scalability: Handle both retail payments and central bank settlements on one chain

Network Topology

• Full mesh: All validators maintain connections to all other validators for maximum fault tolerance
• Gossip protocol: Transactions propagate via efficient gossip (each node forwards to subset of peers)
• Geographic distribution: Validators distributed globally to minimize network latency
• Dedicated network: High-bandwidth connections between validator nodes (10+ Gbps recommended)

Block and Transaction Structure

Block Format

Each block in the Commons blockchain contains:

• Block header:
  • Block height (incremental number)
  • Timestamp (Unix epoch milliseconds)
  • Previous block hash (SHA-256)
  • State root hash (Merkle tree root of global state)
  • Transaction root hash (Merkle tree root of all transactions)
  • Proposer signature (nation that proposed this block)
  • Validator signatures (aggregated BLS signatures from 2/3+ validators)
• Transaction list: Ordered list of all transactions in this block (typically 1,000-10,000 per block)
• State changes: Summary of balance updates and state transitions

Transaction Types

The system supports multiple transaction types:

• Transfer: Send CU from one account to another (most common)
• Currency issuance: National government creates new CU (must be within quota)
• Tax collection: Government collects tax payment (destroys CU)
• Bond issuance: Government issues bond, receives CU from buyer
• Bond redemption: Bondholder redeems bond, receives CU from government
• Smart contract call: Invoke contract function (lending, voting, etc.)
• Governance vote: Validator submits vote on proposal
• Identity registration: Register proof-of-personhood credential

Transaction Structure

Each transaction contains:

• Nonce: Sequential number to prevent replay attacks
• Sender: Public key or account identifier
• Recipient: Destination account (or contract address)
• Amount: CU to transfer (128-bit integer for precision)
• Transaction type: Enum indicating operation
• Payload: Additional data (e.g., contract parameters)
• Gas limit: Maximum computation allowed
• Signature: EdDSA or ECDSA signature proving authorization

Transaction Processing Pipeline

1. Submission: User submits signed transaction to any node
2. Validation: Node checks signature, nonce, balance, gas limit
3. Mempool: Valid transactions enter memory pool awaiting inclusion
4. Ordering: Block proposer selects transactions (priority fee + fairness)
5. Parallel execution: Independent transactions execute simultaneously
6. State commitment: Updated state root computed via Merkle tree
7. Consensus: Block + state changes sent to validators for signing
8. Finality: After 2/3+ validators sign, block is committed (irreversible)

State Machine and Storage

Global State Structure

The blockchain maintains a global state represented as a Merkle Patricia Trie (similar to Ethereum) containing:

• Account balances: Every account's CU balance
• Contract storage: Smart contract state variables
• National quotas: Remaining issuance capacity for each nation
• Bond registry: All outstanding bonds and their terms
• Identity registry: Proof-of-personhood records
• Governance state: Active proposals, voting records

State Transitions

The state machine is deterministic: Given state S and transaction T, all validators compute identical next state S'.

State transition function: S' = StateTransition(S, T)

• If transaction is valid → state updates, transaction succeeds
• If transaction is invalid → state unchanged, transaction fails (but may still be recorded with error)
• All validators execute identical logic to ensure consensus on state

Storage Architecture

• State database: Key-value store (RocksDB or similar) for current state (100s of GB)
• Block storage: Append-only log of all blocks (growing ~1-10 TB/year depending on usage)
• Archive nodes: Full historical state at every block height (multiple petabytes)
• State snapshots: Periodic checkpoints allow fast sync without replaying entire history
• State pruning: Old state can be pruned after checkpoint (light nodes don't need full history)

Cryptographic Primitives

Digital Signatures

• User transactions: EdDSA (Ed25519) for fast verification and small signatures (64 bytes)
• Validator signatures: BLS signatures for efficient aggregation (combine 134 signatures into one)
• National keys: Hardware security modules (HSMs) protect validator signing keys
• Key rotation: Nations can rotate keys with governance approval

Hashing

• Block hashes: SHA-256 (industry standard, quantum-resistant with larger keys)
• Merkle trees: SHA-256 for transaction and state commitments
• Account addresses: Derived from public key via SHA-256 + RIPEMD-160

Zero-Knowledge Cryptography

• Shielded transactions: zk-SNARKs (e.g., Groth16 or PLONK) enable private transfers
• Selective disclosure: Users prove facts about their account without revealing all data
• Identity privacy: Prove personhood without revealing identity
• Creditworthiness proofs: Prove loan eligibility without revealing full financial history

Public but Governed Ledger

The blockchain will be publicly auditable—meaning anyone can inspect transactions and the state of accounts (with appropriate privacy measures). However, unlike permissionless networks (Bitcoin/Ethereum) where anyone can validate, Commons uses a permissioned validator set comprised of member nations' nodes.

This hybrid approach ensures both openness and controlled governance.

Who Can Participate

• Validators: Only member nation nodes (one per country)
• Users: Anyone can create wallets and transact
• Observers: Anyone can run read-only nodes to verify the blockchain
• Developers: Anyone can build applications on top of Commons
• Auditors: Researchers, journalists, regulators can analyze on-chain data

Smart Contract Platform

The platform supports smart contracts to enable the financial use cases needed (lending, bonds, trade rebalancing, etc.).

Core System Contracts

• Governance contracts: Voting, parameter adjustments, proposal management
• Clearing union contracts: Trade imbalance rules, automatic surplus recycling
• Identity contracts: Proof-of-personhood registry, credential verification
• Financial contracts: Lending protocols, bond issuance, payment channels

Security & Auditability

• Open source: All core contracts publicly auditable
• Formal verification: Mathematical proofs of contract correctness
• Regular audits: Independent security reviews by multiple firms
• Bug bounties: Financial incentives for responsible disclosure
• Upgrade mechanisms: Democratic assembly can upgrade contracts with supermajority vote

Flexibility

Smart contracts introduce flexibility: new financial instruments or rules can be added by governance without replacing the entire system, just by deploying/upgrading contracts (subject to voting approval).

Transparency & Auditability

A crucial advantage of using blockchain is that all transactions and monetary operations are recorded indelibly, creating a public audit trail.

What's Transparent

• Currency issuance: Every new CU created is visible
• National accounts: Government balances and transactions
• Trade flows: Aggregate cross-border movements
• Rebalancing operations: Surplus recycling and deficit support
• Governance votes: All assembly decisions permanently recorded
• Smart contract code: All system logic open source and auditable

What's Private

To maintain privacy (see Privacy & Security):

• Individual user accounts can use shielded transactions
• Personal financial details protected by zero-knowledge proofs
• Only aggregate statistics visible, not individual transaction details

Audit Tools

Built-in explorers and dashboards provide:

• National balance summaries
• Total supply and circulation metrics
• Trade balance indicators
• Governance activity logs
• Network health statistics
• Historical trend analysis

Interoperability

The Commons ledger will be designed to interoperate with existing financial infrastructure and other blockchains.

Integration Points

• Banking APIs: Allow banks and payment providers to interface with Commons (submit transactions, check balances)
• CBDC bridges: Connect with national Central Bank Digital Currencies
• Cross-chain protocols: Secure bridges to other major blockchains (subject to governance approval)
• Legacy systems: SWIFT-compatible messaging for transition period
• Forex integration: Market makers can provide CU exchange services

Controlled Bridging

All cross-chain bridges must be:

• Approved by governance assembly
• Audited for security vulnerabilities
• Monitored for illicit flows
• Rate-limited to prevent systemic risk

Scalability Architecture

Parallel Transaction Execution

Block-STM (Software Transactional Memory) approach:

• Optimistic execution: Transactions execute in parallel speculatively
• Conflict detection: System detects when two transactions modify same state
• Re-execution: Conflicting transactions re-execute with correct ordering
• Deterministic finality: Despite parallelism, final state is deterministic and identical across all validators

State Sharding (Future)

While initially a single chain, the architecture can evolve to support sharding:

• Account sharding: Partition accounts across shards by address prefix
• Cross-shard communication: Atomic transactions spanning multiple shards
• Beacon chain: Coordination layer managing shard committees
• Dynamic rebalancing: Hot shards can split, cold shards can merge

Resource Metering (Gas Model)

• Computation cost: Each operation has gas cost (e.g., 1 gas per addition, 100 gas per signature verification)
• Storage cost: Writing data costs gas proportional to bytes stored
• Network cost: Transaction size contributes to gas cost
• Gas price: Set by governance (may be zero for basic transfers, non-zero for complex contracts)
• Prevents DoS: Gas limits prevent infinite loops or resource exhaustion attacks

Network Security & Attack Resistance

Consensus Layer Security

• Byzantine tolerance: Up to 66 out of 200 nations could be malicious/offline without compromising safety
• No double-spend: Once finalized, transactions cannot be reversed (no forks)
• Censorship resistance: Leader rotation prevents single nation from blocking transactions
• Accountability: All validator signatures recorded; malicious behavior is provable and punishable

Network Layer Security

• DDoS protection: Rate limiting, IP reputation, connection limits
• Eclipse attack prevention: Validators maintain connections to multiple geographically distributed peers
• Sybil resistance: Validators are known nation-states (no anonymous validator registration)
• Encrypted communication: TLS 1.3+ for all validator-to-validator communication

Smart Contract Security

• Formal verification: Core system contracts mathematically proven correct
• Audits: Multiple independent security firms review all protocol contracts
• Bug bounties: Large rewards ($100k-$1M+) for critical vulnerability discovery
• Time-locked upgrades: Contract upgrades have mandatory delay period for community review
• Circuit breakers: Emergency pause mechanisms for detected exploits

Network Upgrades & Governance Execution

Protocol Upgrade Process

1. Proposal: Technical specification published (e.g., "Upgrade consensus from HotStuff to Jolteon")
2. Discussion: 30-day minimum review period for technical community
3. Voting: Nations vote via on-chain governance (requires 2/3 supermajority)
4. Implementation: If approved, upgrade deployed to testnet first
5. Testing: Minimum 60 days of testnet operation
6. Activation: Coordinated mainnet upgrade at predetermined block height
7. Monitoring: Post-upgrade monitoring for issues, rollback capability if critical bugs found

Hard Fork vs Soft Fork

• Soft fork: Backward-compatible changes (old nodes still work) - requires simple majority
• Hard fork: Breaking changes (all validators must upgrade) - requires 2/3 supermajority
• Coordinated deployment: Unlike public blockchains, upgrades are coordinated (no contentious forks)

Emergency Procedures

• Critical bug discovered: Emergency multisig (e.g., 10 of 15 largest nations) can pause system
• Incident response: Technical committee investigates, proposes fix
• Expedited voting: 7-day emergency vote period (still requires 2/3 approval)
• Post-mortem: Public report on incident, lessons learned, prevention measures

Node Operations

National Validator Nodes

Each member nation runs validator infrastructure:

• Hardware requirements: Enterprise-grade servers (32+ cores, 256GB+ RAM, fast NVMe SSD storage, 10+ Gbps network)
• Energy consumption: 50-150 watts per node (similar to running a small server)
• Redundancy: Primary + backup nodes in different data centers for high availability
• Security: Hardware security modules (HSMs) for key storage, physical security, network isolation
• Monitoring: 24/7 operations center with automated alerts for performance degradation
• Disaster recovery: Regular backups, documented recovery procedures, tested annually

Observer Nodes

Anyone can run read-only observer nodes to:

• Verify blockchain state independently
• Serve blockchain data to applications (wallets, exchanges, analytics)
• Monitor for anomalies or policy violations
• Provide redundancy and geographical distribution
• Research and analysis (academics, journalists, civil society)

Node Software

• Open source: All node software publicly available on GitHub
• Multiple implementations: Encourage diverse client implementations (e.g., Rust, Go, Java) to avoid monoculture bugs
• Automated testing: Continuous integration with thousands of test cases
• Fuzzing: Automated fuzzing to discover edge cases and vulnerabilities
• Documentation: Comprehensive developer docs, API references, deployment guides

Technology Stack Flexibility

The architecture could be built on proven blockchain frameworks that support BFT consensus and smart contracts:

• Cosmos SDK: Modular framework with Tendermint consensus
• Substrate: Polkadot's flexible blockchain builder
• Hyperledger Besu: Enterprise-focused Ethereum client
• Custom implementation: Purpose-built for Commons' specific needs

The governance assembly will decide based on technical evaluations, with priority given to:

• Proven security track record
• Strong developer community
• Customization flexibility
• Performance characteristics
• Ability to implement one-nation-one-vote consensus

Summary: Technical Excellence Serving Human Needs

The blockchain infrastructure is designed to be invisible to users while providing the transparency, security, and scalability needed for a global monetary system.

Core Technical Achievements

• ✓ User-friendly: One seamless chain, no bridging complexity—users never think about the underlying tech
• ✓ High performance: Parallel execution engine + BFT consensus designed for millions of daily transactions with sub-second finality
• ✓ Energy efficient: BFT consensus consuming ~10-30 kW total (vs Bitcoin's 150+ TWh annually)
• ✓ Democratic: One nation, one validator, equal consensus weight—no wealth-based voting
• ✓ Byzantine fault tolerant: System remains secure even if 1/3 of nations are malicious or offline
• ✓ Deterministic finality: No forks, no reorganizations—transactions are irreversible once committed
• ✓ Transparent: All national monetary operations visible on-chain; individual privacy via zero-knowledge proofs
• ✓ Formally verified: Core system contracts mathematically proven correct
• ✓ Auditable: Anyone can run observer nodes, analyze on-chain data, verify system integrity
• ✓ Flexible: Smart contracts and on-chain governance enable evolution without system replacement
• ✓ Secure: Multiple layers of security from cryptography to network to consensus to application
• ✓ Resilient: No single point of failure; geographically distributed; disaster recovery procedures

Technical Innovation Serving Social Good

The architecture leverages cutting-edge blockchain research—parallel execution, BFT consensus, zero-knowledge cryptography, formal verification—not for speculation or hype, but to rebuild global finance on a foundation of transparency, fairness, and democratic control.

Every technical decision serves the mission: to create a monetary system that serves humanity, not profits from it.