FastSet Protocol

FastSet is a distributed protocol for parallel claim settlement. In short, it allows a set of clients to settle verifiable claims consistently, using a set of validators. Clients broadcast their claims to all validators. Validators validate the received claims and replicate the system state based on the order in which they receive the claims. The FastSet validators do not need to communicate with each other, nor directly achieve consensus on any values, orders, blocks, or computations. More specifically, in FastSet, we achieve strong eventual consensus due to the weak independence on claims we require.

In the previous section, you learned about what types of claims one can settle in FastSet and how to express them, but also about weak independence, the property we require claims to satisfy, and which allows FastSet to process them in any order, which facilitates decentralization and scalability. In this section, we will focus on the inner workings of FastSet.

Figure 1 below depicts the participants and steps of the protocol. In the following, we’ll discuss each in more detail.

Figure 1: FastSet protocol.

Participants

Clients

A client is any account or address holder who can make claims. Clients can be more than individual users; they can be apps (such as contracts, web2, or games), L1s, L2s, micro-chains, AI agents, service providers, oracles, provers (such as mathematical or zero-knowledge), verifiers (such as execution, semantics, and/or zero-knowledge proof based), etc.

Each client possesses a key pair consisting of a private signature key sk and its corresponding public verification key pk. The private key is used to sign messages

⟨msg⟩_sk

while the public key is used to publicly verify the authenticity of the signatures. Similarly to blockchains, the public key of a client also serves as its public account number, or its address.

Validators

Validators are responsible for processing the claims made by the clients, while at the same time maintaining consistency in the global knowledge about the overall system, or, more specifically, in the global state of the system.

Validators maintain a local copy of the global state, which they update independently based on the side effects of the claims they process. Due to the eventual consistency consensus we achieve in FastSet, local states of validators may temporarily diverge when processing the same set of claims. However, by the time they process the entire claim set, their states converge to the same final state, achieving determinism.

For example, for a payment system, validators keep balances of all tokens and additional data/state of all clients, global state of the entire protocol, like the set of all the claims that were settled, etc.

Verifiers

Verifiers are clients that verify the claims and their proofs issued by other clients.

Proxy

The proxy acts as a helper in the protocol. It can be a client (the sender of the original message containing the claim sequence, or a different client such as a beneficiary or a verifier or a service provider), a validator, or any combination of these.

The proxy is responsible for two services: broadcasting messages to validators and aggregating signatures (#{sig1 , sig2 , ...}).

Steps

1

Claim

Client A signs a sequence of claims c₁ c₂ ... c_k and sends the signature m = <c₁ c₂ ... c_k,T>_A to the proxy.

2

Verify

The set of verifiers T requested by the client verifies the message m and signs it individually <m>t1, <m>t2, … <m>tl.

3

Validate

The proxy receives the signatures from the verifiers and computes an aggregated signature <m>_#T, which it sends to the validators.

4

Sign

Validators validate the signature by checking that the signatures are valid and the quorum specified by the client has been reached. Then they send their responses <m>_v to the proxy.

5

Confirm

As more validators sign the message, a collection of their signatures continues to grow and eventually forms a quorum.

Once the required quorum is met, the proxy issues the certificate <m>_#.

Technically, at this stage, the claim settlement request is final in the sense that it cannot be cancelled.

6

Pre-settle

Upon receipt of <m>_#, each VSL validator checks the signature and the quorum # of the settlement certificate.

7

Settle

Each VSL validator settles the claim and updates its internal state.