Core Concepts

To understand how FastSet works, it helps to look at the fundamental concepts that shape the protocol. These ideas which include validators, node state, ordering, concurrency, and weak independence, provide the foundation for everything else you will read in this documentation.

Validators and their role

FastSet is run by a network of validators.

A validator is a node that receives claims from clients, checks whether those claims are valid, and applies them to its local copy of the system state.

Unlike a blockchain, there is no leader and no voting round to agree on the order of transactions. Validators work independently. Each validator makes its own decisions about the order in which it applies claims, provided that claims from the same account are kept in the order they were issued.

This independence is possible because FastSet is designed around weak independence, a property that ensures that even when validators process the same claims in different orders, the final state will be identical.

Node state and replication

Every validator keeps a complete copy of the system state. This state records everything that has been settled on the network, from balances of tokens to the data associated with clients and the global protocol state.

When new claims arrive, validators apply them locally to update their state. Because validators are not required to synchronize their work, it is normal for their states to diverge temporarily while claims are being processed.

Once all validators have processed the same set of claims, the states converge again. This eventual agreement without constant communication is a core strength of FastSet.

In contrast, a blockchain system enforces a single, strict sequence of transactions. Validators in a blockchain spend most of their time waiting for consensus about the next block, while FastSet validators are able to move ahead on their own, processing claims as they come in.

Ordering and concurrency

FastSet does not impose a global order on all claims. Instead, it follows two simple rules. First, claims that originate from the same account must be applied in the order they were created. This prevents an account from issuing two conflicting claims at the same time, such as trying to spend the same balance twice. Second, claims that come from different accounts can be processed in any order. The order may vary from one validator to another, depending on how those claims arrive, but this does not cause any conflict.

This relaxation of global ordering is what makes FastSet different. Two validators may apply the same set of claims in different sequences, and even interleave them.

For example, one validator might see claims arrive in the order A1, B1, A2, B2, while another might see B1, A1, B2, A2. Instead of forcing them into the same sequence, FastSet allows them to proceed in parallel. You can understand more about this here.

Convergence without coordination

Weak independence guarantees that this parallelism does not break the system. If all the claims involved are weakly independent, then the final state after applying all of them will be the same, no matter which order was used. This means validators can operate without constant coordination, yet still converge on a single shared outcome once they have processed the same claims.

What results from this model is a system that supports massive throughput without sacrificing determinism. Validators avoid the bottleneck of block production and the overhead of global consensus protocols, but they do not lose correctness.

Why these concepts matter

The combination of independent validators, local state replication, minimal ordering rules, and weak independence, is what makes FastSet capable of handling the volume and speed of modern decentralized applications.

These core concepts remove the trade-off between consistency and performance that has defined blockchain-based systems for over a decade. In FastSet, consistency emerges naturally from the way claims are structured and processed.

In the next section, you will see how these concepts come together in detail, with formal definitions and examples of weak independence. That section shows why this property is powerful enough to ensure that, no matter how validators interleave claims, the network ends up in a single consistent state.