Foundation: Byzantine Consensus Across the Network Stack

What Is This

Foundation is a project exploring Byzantine fault-tolerant consensus across heterogeneous network transports. The core algorithm is derived from BEAT — Byzantine, Efficient, Asynchronous, and Throughput-optimised consensus.

The premise: multiple nodes must agree on something, even if some of them are lying, broken, or actively adversarial. Foundation handles this without requiring synchronous timing assumptions — a significant property when your nodes are not on the same continent, the same network, or even operating under the same conditions.

Why Multiple Transports

Most distributed systems pick a transport and commit to it. Foundation does not.

The system routes across three transports simultaneously, each offering a different trade-off between performance and resilience:

Standard networking is fast. It is also filterable and blockable by any sufficiently motivated operator. Use it for performance. Do not rely on it alone for resilience.

Anonymising overlays provide strong isolation at the cost of latency. Useful for nodes operating in environments where reliability of standard routes cannot be guaranteed. The consensus protocol is designed to tolerate variable round-trip overhead.

Mesh routing layers are optimised for internal peer-to-peer traffic with different resilience properties and a different failure model to the above.

The combination gives the system a meaningful property: a node can participate in consensus regardless of which transports are available, and a disruption must affect all three simultaneously to partition the network.

Fault Tolerance in Practice

A Byzantine fault is not simply a crash. It is a node that behaves arbitrarily — sending different messages to different peers, delaying responses strategically, or actively attempting to subvert consensus. Named after the Byzantine Generals Problem, formalised by Lamport, Shostak, and Pease in 1982.

Classical BFT protocols (PBFT and its descendants) are synchronous or partially synchronous — they assume bounded message delays. This assumption does not hold under variable-latency routing, adversarial network conditions, or heterogeneous transport mixing.

Foundation’s consensus layer operates asynchronously. It makes no assumptions about when messages arrive. It tolerates up to ⌊(n−1)/3⌋ Byzantine nodes in a network of n — the theoretical maximum for asynchronous BFT.

CAP Theorem Considerations

Foundation sits firmly on the CP side of the CAP triangle by design. Under a network partition, it chooses consistency over availability — nodes will not make progress if they cannot achieve quorum. This is the correct trade-off for a system whose purpose is agreement.

The partition tolerance comes from the multi-transport architecture: partitions must be total (affecting all transports simultaneously) to halt the system.

Eventual Use Cases

This is v0. An introduction. The protocol and transport abstractions are the interesting parts right now. But the use cases are worth naming:

Consensus in trading systems — distributed agreement on order state or settlement without a trusted central counterparty
Family-scale secure storage — consensus-backed fault-tolerant file storage between a small number of trusted devices, none of which need to be online simultaneously
Event-driven coordination — reliable event ordering across distributed nodes where message delivery cannot be guaranteed

Current Status

Early implementation. The architecture is defined, transport abstractions are in place, and the consensus protocol is being integrated.

Future entries will cover the implementation specifics, transport trade-offs, and protocol mechanics in detail.

For now: the foundation is being laid.