Umotu Consensus Architecture

Overview

Umotu implements a hybrid consensus architecture that combines:

• L1 Consensus Layer: CometBFT (Tendermint) provides Byzantine Fault Tolerant consensus for block production
• On-chain Validator Registry: Ethereum smart contracts manage validator registration, staking, and slashing
• Optimistic Block Validation: Blocks are assumed valid unless challenged within a dispute window
• Fraud Proof System: Anyone can challenge invalid blocks with cryptographic proofs and earn rewards
• Mobile Finality: Smartphones participate in attestation through BLS signature aggregation

Optimistic Block Validation

Umotu uses an optimistic rollup-style approach: blocks are accepted immediately and assumed valid unless challenged. This enables fast finality while maintaining cryptographic security.

How It Works

1. Block Proposed (t=0): Validator proposes a new block to CometBFT
2. Immediate Acceptance: Block enters the canonical chain immediately
3. Challenge Window Opens: 20-second window where anyone can dispute the block
4. Finalization:
   • If unchallenged → Block finalizes at t=20s
   • If challenged → Interactive dispute resolution begins

Fraud Proof System

Every block includes three cryptographic commitments that enable fraud proofs:

1. Trace Root (Execution Proof)

A Merkle root of the complete execution trace — every EVM opcode, stack state, memory modification, and gas consumption.

curl -X POST $RPC_URL -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"umotu_getTraceRoot","params":["latest"]}'

curl -X POST $RPC_URL -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"umotu_getTraceSlice","params":["0x1234","0x0","0x10"]}'

2. State Root (World State Proof)

Standard Ethereum state root using Merkle Patricia Trie. Accessible via eth_getProof and umotu_getStateRoot.

3. DA Commitment (Data Availability Proof)

Erasure-coded commitment using Reed-Solomon encoding (xor-parity) to ensure block data remains available even if some nodes go offline.

curl -X POST $RPC_URL -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"umotu_getDACommitment","params":["latest"]}'

Returns commitment, scheme (xor-erasure-v1), chunk parameters (k, n, size), and DA provider URLs.

Interactive Dispute Resolution

When a challenger believes a block is invalid, they can initiate a fraud proof game through the on-chain TraceDispute contract.

Bisection Protocol

Disputes use binary search to narrow the disagreement to a single EVM opcode:

1. Challenger: "Block X has invalid trace root"
2. Proposer: "My trace is correct"
3. Binary Search: Agree on first 50%? 25%? 12.5%?
4. Single Step: Disagree on single opcode (e.g., step 12,547)
5. On-Chain Verification: StepVerifier contract validates the opcode execution
6. Resolution:
   • Invalid step → Proposer slashed 25%, Challenger rewarded
   • Valid step → Challenger penalized

Supported Opcodes

The StepVerifier contract validates:

• Arithmetic: ADD, SUB, MUL, DIV, MOD, ADDMOD, MULMOD
• Stack: DUP1-2, SWAP1-2, POP, PUSH1-32
• Bitwise: AND, OR, XOR, NOT
• Comparison: EQ, LT, GT, SLT, SGT, ISZERO
• Memory: MLOAD, MSTORE (with per-step memory commitments)

Economic Security

Slashing for Invalid Blocks

Validators who propose invalid blocks face severe penalties:

• Slash Amount: 25% of bonded stake (configurable)
• Fault Type: ValidatorRegistry.Fault.InvalidBlock
• Challenger Reward: Portion of slashed funds
• Automatic Execution: DisputeSlashHook triggers slashing when dispute resolves

Incentive Alignment

With a 20 ETH bond and 25% slash:

• Cost to attack: 5 ETH (immediate loss)
• Typical MEV gain: <0.1 ETH per block
• Economic deterrent: Cost to attack >>> potential gain

Finality Tracking

ABCI exposes real-time finality events so applications can react to block finalization or invalidation.

WebSocket

const ws = new WebSocket('ws://node:8080/ws/finality');
ws.onmessage = (msg) => {
  const event = JSON.parse(msg.data);
  // { height, valid, blockHash, traceRoot, stateRoot, proposer, challenger }
};

Server-Sent Events (SSE)

curl -N http://node:8080/sse/finality
# data: {"height":123,"valid":true,"blockHash":"0x..."}

RPC Method

curl -X POST $RPC_URL -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"umotu_getFinalizedHead","params":[]}'

Batch JSON-RPC

Umotu supports batch JSON-RPC requests per the JSON-RPC 2.0 specification. Send multiple calls in a single HTTP request to reduce latency.

Example: Fetch Block + Trace + DA

curl -X POST $RPC_URL -H 'content-type: application/json' \
  -d '[
    {"jsonrpc":"2.0","id":"block","method":"eth_getBlockByNumber","params":["0x1234",true]},
    {"jsonrpc":"2.0","id":"trace","method":"umotu_getTraceRoot","params":["0x1234"]},
    {"jsonrpc":"2.0","id":"da","method":"umotu_getDACommitment","params":["0x1234"]}
  ]' | jq .

Batch Behavior

• Order Preserved: Responses returned in same order as requests
• Parallel Execution: Requests processed concurrently where possible
• Independent Errors: One failed request doesn't abort the batch
• Rate Limiting: Batch counts as single request, but heavy methods are evaluated individually

Use Cases

• Fetch multiple blocks in parallel
• Get trace + state + DA commitment atomically
• Poll contract states efficiently
• Reduce HTTP overhead for high-throughput apps

Why This Matters

• Accountable Validators: Every block can be cryptographically proven correct or incorrect. Validators cannot produce invalid blocks without being slashed.
• Permissionless Challenges: Anyone can challenge a block — no special permissions needed. If you can prove a block is invalid, you earn the slashing reward.
• Fast Finality with Safety: Optimistic acceptance enables sub-second confirmations, while the challenge window provides cryptographic safety guarantees.
• Transparent Execution: Every opcode, state change, and data commitment is verifiable on-chain or via RPC.

Learn More

For comprehensive technical details, see:

• JSON-RPC Reference — Complete RPC method documentation
• GitHub Repository — Source code and technical specs
• Network Guide — Run your own node