Sumeragi Consensus

Technical Documentation

This documentation covers the Sumeragi consensus algorithm used in Hyperledger Iroha and SORA v3. Iroha Documentation

Sumeragi Consensus

Sumeragi is the Byzantine Fault Tolerant (BFT) consensus algorithm used in Hyperledger Iroha. Named after the imperial lineage of Japan, Sumeragi provides deterministic finality with high performance, making it ideal for enterprise blockchain deployments and the SORA v3 network.

What is BFT Consensus?

BFT consensus allows a distributed network to reach agreement even when some participants behave maliciously or fail unexpectedly.

The Byzantine Generals Problem

The classic thought experiment:

Several generals must coordinate an attack. They can only communicate via messengers who might be traitors. How can they reach reliable agreement?

BFT algorithms solve this by tolerating up to f faulty nodes in a network of 3f + 1 total nodes:

Total Nodes	Max Faulty Nodes	Required Honest
4	1	3
7	2	5
10	3	7
100	33	67

---

How Sumeragi Works

Consensus Rounds

Sumeragi operates in rounds, each producing one block:

Round N:
┌─────────────────────────────────────────────────────┐
│  1. Leader     2. Propose    3. Vote    4. Commit  │
│  Selection  →   Block     →   Phase  →   Block     │
└─────────────────────────────────────────────────────┘

Leader Selection

Each round has a designated leader who proposes blocks:

1. Deterministic ordering — Peers are sorted by cryptographic hash
2. Round-robin rotation — Leader changes each round
3. Predictable — All peers know who leads each round

Round 1: Peer A leads
Round 2: Peer B leads
Round 3: Peer C leads
Round 4: Peer D leads
Round 5: Peer A leads (cycle repeats)

Voting Topology

Sumeragi uses a specific topology for vote propagation:

Voting Set

The first 2f + 1 peers in the sorted order form the voting set:

• Required for block commitment
• Must all sign the block
• Remaining peers are observing proxies

Proxy Tail

Peers outside the voting set form the proxy tail:

• Receive blocks after commitment
• Participate in view changes
• May enter voting set if leaders fail

---

Consensus Phases

Phase 1: Block Proposal

The leader creates a block:

// Pseudocode for block creation
fn create_block(transactions: Vec<Transaction>) -> Block {
    Block {
        height: current_height + 1,
        previous_hash: last_block.hash(),
        transactions,
        timestamp: now(),
        leader_signature: sign(block_hash),
    }
}

Phase 2: Vote Collection

Voting peers validate and sign:

1. Validate transactions — Check permissions and signatures
2. Verify block structure — Hash chains, timestamps
3. Sign block hash — Add signature to block
4. Forward to next peer — Chain voting pattern

Leader → Peer 1 → Peer 2 → ... → Peer 2f → Commit
           ↓          ↓              ↓
         Sign       Sign           Sign

Phase 3: Commitment

When 2f + 1 signatures are collected:

1. Block is committed to storage
2. Broadcast to proxy tail
3. State changes are applied
4. Next round begins

Tip

Sumeragi provides instant finality. Once committed, blocks cannot be reverted or reorganized.

---

View Changes

When a leader fails or acts maliciously, the network performs a view change:

Failure Detection

• Timeout — Leader doesn’t propose in time
• Invalid block — Proposal fails validation
• Byzantine behavior — Conflicting proposals detected

View Change Protocol

1. Peer detects failure
2. Broadcasts ViewChange message
3. Collects 2f + 1 ViewChange messages
4. New leader takes over
5. Round continues with new leader

Leader Replacement

The view change promotes the next peer in line:

Original: A (leader) → B → C → D
After VC: B (leader) → C → D → A*
                              *moved to end

---

Performance Characteristics

Latency

Sumeragi achieves low latency through:

Factor	Optimization
Network hops	Linear voting chain
Signature aggregation	Batch verification
Block pipeline	Parallel execution

Typical latency: 1-3 seconds for finality

Throughput

Performance depends on:

• Network bandwidth between peers
• Transaction complexity
• Number of voting peers

Benchmarks on modern hardware:

Scenario	Transactions/Second
Simple transfers	10,000+
Complex WASM	1,000+
Mixed workload	5,000+

---

Sumeragi vs Other Consensus

vs Proof of Work (Bitcoin)

Aspect	Sumeragi	PoW
Finality	Instant	Probabilistic
Energy	Minimal	Massive
Throughput	High	Low
Decentralization	Permissioned	Open

vs Tendermint/PBFT

Aspect	Sumeragi	Tendermint
Communication	Linear	All-to-all
Complexity	O(n)	O(n²)
View changes	Simple	Complex
Implementation	Rust	Go

vs GRANDPA (Polkadot)

Aspect	Sumeragi	GRANDPA
Block production	Integrated	Separate (BABE)
Finality	Per-block	Batch
Latency	1-3s	12-60s
Use case	Enterprise	Public chain

---

Security Properties

Safety

Sumeragi guarantees safety as long as less than 1/3 of peers are Byzantine:

• No forks — Only one valid chain exists
• No double-spending — Transactions are ordered
• No rollbacks — Committed blocks are permanent

Liveness

The network continues producing blocks if:

• 2f + 1 peers are online and honest
• Network partitions eventually heal
• View changes recover from failures

Caution

If more than 1/3 of peers are Byzantine, safety may be compromised. SORA v3 uses economic incentives (staking) to make attacks costly.

---

Sumeragi in SORA v3

Validator Selection

SORA v3 validators are selected through:

1. Staking — VAL tokens locked as collateral
2. Reputation — Historical performance
3. Governance — Parliament approval for major validators

Economic Security

Mechanism	Purpose
Staking	Collateral for honest behavior
Slashing	Penalty for Byzantine actions
Rewards	Incentive for participation
Unbonding	Delay prevents quick exit after attack

Integration with Governance

The SORA Parliament can:

• Adjust validator set
• Modify consensus parameters
• Respond to security incidents
• Upgrade the consensus protocol

---

Implementation Details

Rust Implementation

Sumeragi is implemented in Rust for:

• Memory safety without garbage collection
• High performance
• Compile-time guarantees
• Excellent concurrency support

Key Data Structures

pub struct Block {
    pub header: BlockHeader,
    pub transactions: Vec<Transaction>,
    pub signatures: Vec<Signature>,
}

pub struct BlockHeader {
    pub height: u64,
    pub previous_block_hash: Hash,
    pub transactions_hash: Hash,
    pub timestamp: u128,
    pub view_change_index: u32,
}

Configuration

{
  "sumeragi": {
    "block_time_ms": 2000,
    "commit_time_ms": 4000,
    "max_transactions_in_block": 512,
    "actor_channel_capacity": 100
  }
}

---

Further Reading

Iroha Overview

Understanding the full Iroha framework

Smart Contracts

WASM and ISI contract development

SORA v3

Next-gen SORA infrastructure

Official Docs

Hyperledger Iroha documentation