Byzantine Consensus Assumption Mapping for Intermittently Connected Networks
A completed computer science study comparing Byzantine consensus families across timing, quorum, partition, authentication, membership, randomness, storage, and network-healing assumptions for intermittently connected networks.
Software compatibility
The released results use the frozen 2 September 2026 evidence catalogue, pinned Python packages, 20,000 uncertainty draws per protocol, and random seed 20260902. Changed evidence positions require a fresh validation run.
Project definition
Problem statement
Byzantine consensus protocols depend on specific timing, quorum, authentication, membership, randomness, storage, and recovery assumptions. Intermittent connectivity can remove the communication conditions needed for liveness even when store-and-forward transport eventually delivers messages.
The engineering problem is to map those assumptions clearly before selecting a protocol, while separating safety from liveness, transport availability from agreement, and literature-informed comparison from a claim that a deployed system is correct.
Project objectives
- Compare ten consensus and transport archetypes across eight governing assumption drivers.
- Apply hard gates for quorum intersection, partition safety, authentication, membership, and progress conditions.
- Evaluate scheduled space contacts, rural mobile mesh, disaster response, and intermittent edge federation.
- Compare nominal contact, delayed recovery, prolonged partition, and Byzantine relay evidence cases.
- Map fourteen validation criteria across eleven consensus engineering stages.
- Quantify evidence-position uncertainty with 20,000 fixed-seed draws per protocol.
Project structure
Project components
Protocol register
Compares PBFT, HotStuff, Tendermint, HoneyBadgerBFT, Narwhal and Tusk, Bullshark, Zeno, federated BFT, a synchronous baseline, and a signed-evidence DTN baseline.
Assumption-driver model
Tests synchrony, quorum reachability, partition behaviour, authentication, membership change, randomness, durable storage, and network healing.
Decision framework
Scores twelve declared evidence dimensions and rejects protocol-context combinations that fail governing safety or liveness gates.
Network-context analysis
Keeps scheduled contacts, disruption duration, topology, relay trust, and recovery conditions visible across four engineering contexts.
Workflow FMEA
Ranks 154 stage-criterion combinations from fault model and membership definition through implementation, recovery, and claims review.
Verification pipeline
Regenerates results, tests the model, validates the documents, audits dependencies, and reproduces the study in Docker.
Methodology
Project workflow
- 01Define the fault and timing model
State Byzantine fault bounds, timing assumptions, membership, authentication, topology, contact schedule, and required safety and liveness properties.
- 02Test quorum reachability
Check whether the required quorum can intersect and communicate during each declared network condition.
- 03Separate transport from consensus
Record what store-and-forward delivery provides and which agreement, ordering, finality, or freshness properties remain unproven.
- 04Run the comparison
Generate protocol, assumption, context, evidence-case, scenario, FMEA, crosswalk, uncertainty, and sensitivity results.
- 05Plan experiments
Translate retained assumptions into controlled topology, delay, loss, partition, adversary, membership, recovery, and workload tests.
Demonstration scenario
The retained study compares classical BFT, leader-based partially synchronous protocols, asynchronous and DAG families, federated trust, a synchronous baseline, and signed DTN evidence across four intermittent network settings. It shows why delayed delivery can preserve evidence without guaranteeing timely quorum progress or consensus finality.
Engineering
Tools and method
- Declared inputs
- Python data structures retain every protocol position, assumption link, network context, evidence case, hard gate, and interpretation boundary.
- Deterministic analysis
- NumPy and pandas generate all 1,280 protocol, assumption-driver, context, and evidence cells.
- Safety and liveness analysis
- Separate metrics preserve quorum intersection, partition safety, asynchronous liveness, responsiveness, finality, and recovery evidence.
- Uncertainty
- Fixed-seed Monte Carlo and one-factor sensitivity test stability of the literature-informed evidence positions.
- Evidence
- CSV, JSON, PNG, PDF, and Word files retain the full analysis, source catalogue, figures, and project report.
- Release verification
- Tests, linting, vulnerability audit, document QA, repository validation, and Docker verify the handover.
Testing
Evaluation
Evaluation measures
- Screening score and hard-gate result by protocol, assumption driver, network context, and evidence case
- Partition safety, asynchronous liveness, responsiveness, finality, membership, recovery, and store-and-forward positions
- Protocol reversals across balanced, partition-safety, disruption-tolerant, and low-complexity scenarios
- Severity-weighted validation gaps and workflow FMEA priorities
- Assurance requirement crosswalk by protocol
- Monte Carlo intervals and evidence-position sensitivity
Project boundaries
- All numerical inputs are literature-informed evidence positions rather than measurements from a deployed consensus network.
- The study does not implement, formally verify, or certify a named consensus protocol.
- Store-and-forward delivery does not itself provide agreement, ordering, finality, freshness, or quorum reachability.
- It does not claim production fault tolerance, latency, throughput, energy use, or universal protocol superiority.
- A receiving team must replace declared positions with topology-specific measurements, adversary tests, membership tests, recovery evidence, and independent formal review.
Included
- 01Complete Python source and declared study configuration
- 021,280 protocol, assumption-driver, network-context and evidence cases
- 03Ten Byzantine consensus and transport archetypes
- 04Four decision scenarios with explicit safety and liveness gates
- 05Fourteen validation criteria, a 154-cell workflow FMEA and a 130-cell assurance crosswalk
- 06Twelve generated figures and one attributed NASA literature figure
- 0792-page project report in PDF and editable Word formats
- 0815-page project and defence guide in PDF and editable Word formats
- 09Fifty annotated references with evidence boundaries and source matrix
- 10Automated tests, repository validation and Docker reproduction
Project record
No information is collected on this page.
- Permanent project ID
- GP-CS-0NALI6A
- Catalogued
- 21 Aug 2026
- Completed
- 02 Sept 2026
- Verified
- 02 Sept 2026
- Demonstration
- Included in repository
Handover
After purchase
- 01Payment is confirmed
The project is marked unavailable and cannot be purchased again.
- 02Repository access is granted
The buyer's submitted GitHub account receives access to the private repository.
- 03The purchase record is delivered
The certification sheet is prepared from the reviewed buyer details and sent privately by email.