Consensus Pipeline

DBFT Full Consensus Flow

Full protocol pipeline from transaction submission to finality and execution in SEVM. Click a stage to expand details.

Transaction Reception

Client Submission · Local Validation

Entry point of the system transactions arrive at any validator without a central entrypoint. No leader node.

1.1 Client Submission

Users send TX to any validator. Peer-to-peer submission, no central entrypoint, no leader node.

1.2 Local Validation

Each node locally checks: signature, nonce, balance, gas limit, format. TX goes to local mempool.

output: validated_tx_pool[node_i]

validated txs

Leaderless Proposals

Independent Batching · Parallel Broadcast

Key difference vs PBFT, no leader. Each validator independently creates a batch and broadcasts it in parallel to the others.

2.1 Independent Batching

Each validator independently creates its own batch of transactions. No global mempool, no central batcher, no leader.

batch_i = {tx1, tx2, tx3...}

2.2 Parallel Broadcasting

Each node broadcasts its batch to other validators in parallel, without central coordination.

{ batch_1, batch_2, batch_3 ... batch_n }

all batches

Set Byzantine Agreement

Merging · Multi-round Exchange · Superblock

The heart of the DBFT protocol. SBA operates not on a single value but on a set of proposals, union of proposals. Multi-round exchange leads to a deterministic superblock.

3.1 Proposal Merging

Node aggregates all received batches into one merged set. Not choosing one proposal, set aggregation.

Merged_Set = ∪(batch_1 ... batch_n)

3.2 Multi-round Exchange

Nodes exchange: set hashes, signatures, confirmations. Goal: agreement on the same set of data by all participants.

Round 1: exchange proposals
Round 2: exchange hashes
Round 3: exchange confirmations

3.3 Superblock Creation

From the agreed set, each node creates an identical superblock through deterministic TX ordering.

Superblock = deterministic_order(Merged_Set)

superblock

Threshold Agreement

2/3 Quorum · Safety Guarantee

Necessary condition for progress a 2/3 supermajority of validators must sign the superblock hash. Guarantees the safety property.

4.1 2/3 Validator Quorum

At least 2/3 of validators sign the superblock hash. Tolerance: up to 1/3 Byzantine nodes. System works correctly when n ≥ 3f+1.

>= 2/3 validators sign(superblock_hash)

4.2 Safety Guarantee

If quorum reached: safety property satisfied, no possibility of conflicting blocks, no forks at any block height.

commit cert

Finality

Immediate Finalisation · Zero Forking

Finality is immediate and deterministic. First block inclusion = terminal state. No probability, no reorgs, no competing chain.

5.1 Immediate Finalisation

Immediate finality, no further confirmations, no probability. First inclusion = final state.

5.2 Zero Forking

No alternative state exists, no competing chain exists, no reorg exists. One block per height always.

→ final state achieved

final block

Execution (SEVM Layer)

State Transitions · Gas Accounting

The finalised superblock goes to the Secure EVM (SEVM), deterministic transaction execution and state root update. No race condition.

6.1 State Transitions

The superblock is executed by SEVM on the current state root. Result: new state root n+1. Every node gets the same result.

state_root_n+1 = apply(superblock, state_root_n)

6.2 Gas Accounting

Deterministic gas accounting. Full consistency between execution layer and consensus layer. No race condition in EVM execution.

// Full pipeline — canonical sequence

TX Submit↓ Local Validation↓ Independent Batching↓ Parallel Broadcast↓ Proposal Merging↓ Multi-round Exchange↓ Set Byzantine Agreement↓ Superblock Creation↓ 2/3 Threshold↓ Immediate Finality↓ Zero Fork State↓ SEVM Execution↓ State Transition + Gas

Comparative Advantages

DBFT vs classical consensus protocols

PBFT

✗leader bottleneck

✗view change complexity

✗communication explosion O(n²)

✗single proposer

✓DBFT: no leader bottleneck

✓DBFT: reduced overhead

✓DBFT: parallel proposals

PoS / Tendermint

✗probabilistic leader selection

✗chain splits possible

✗proposer centralization

✗MEV exploitation

✓DBFT: no probabilistic selection

✓DBFT: no chain splits

✓DBFT: deterministic consensus

Proof of Work

✗massive energy waste

✗probabilistic finality

✗long confirmation times

✗51% attack surface

✓DBFT: energy efficient

✓DBFT: instant finality

✓DBFT: f < n/3 tolerance