ULedgerNET Consensus Mechanism
Overview
ULedgerNET employs a Council-Based Byzantine Fault Tolerant (BFT) consensus mechanism. This design provides immediate finality, deterministic leader election, and resilience against Byzantine failures up to ⅓ of participating nodes.
Consensus Model
Council Structure
The consensus is managed by a council of authorized nodes that participate in block production and validation.
Key Properties
| Property | Value | Description |
|---|---|---|
| Consensus Threshold | 66.67% (⅔) | Required votes for block finalization |
| Minimum Council Size | 3 nodes | Minimum for Byzantine fault tolerance |
| Fault Tolerance | f < n/3 | Can tolerate up to ⅓ malicious nodes |
| Finality | Immediate | No probabilistic confirmation required |
Three-Phase Voting Protocol
ULedgerNET uses a three-phase commit protocol to achieve consensus:
Phase Details
Phase 1: PreVote
Validation Checks:
- Block hash integrity
- Valid leader signature
- Correct block height
- Valid Merkle proof
- ZK proof verification
Phase 2: PreCommit
Phase 3: Commit
Leader Election
Deterministic Selection
The leader for each voting round is selected deterministically based on:
- Previous block hash
- Block height
- Current round number
Leader Rotation
Properties:
- Unpredictable more than one block ahead (depends on block hash)
- Deterministic given the same inputs
- Rotates on round timeout for liveness
Timeout and Recovery
Timeout Mechanism
Recovery Scenarios
| Scenario | Recovery Action |
|---|---|
| Leader Offline | Round timeout → New leader election |
| Network Partition | Continue with available ⅔ majority |
| Malicious Leader | Votes rejected → Round timeout |
| Slow Network | Configurable timeout duration |
Vote Structure
Each vote in the protocol contains:
Vote Validation
-
Structural Validation
- Voter is in council
- Correct vote stage
- Matching round number
- Valid block height
-
Cryptographic Validation
- Signature verification using voter's public key
- Message integrity check
Consensus Flow Diagram
Council Management
Joining the Council
Leaving the Council
Performance Considerations
Optimizations
- Vote Batching: Pending votes are queued and processed in batches
- Proposal Buffer: Future proposals are buffered for out-of-order delivery
- Parallel Validation: Block validation happens concurrently across council
Scalability
| Council Size | Consensus Messages | Latency Impact |
|---|---|---|
| 3 nodes | ~6 per block | Baseline |
| 5 nodes | ~10 per block | +10-20% |
| 10 nodes | ~20 per block | +30-50% |
| 20+ nodes | ~40+ per block | Consider sharding |
Next: Cross-Merkleization