Design and implement quorum balancing

[bpalaggi]

As a developer, I need to know what algorithm to follow for quorum assignment in order for the protocol to prevent censorship while being open.

Description

We can consider two degenerate cases for quorum balancing:

• When there is a single quorum with all nodes in it, safety is maximized, but so is communication overhead;
• When each node live in their own quorum, safety does not exists but there is no communication: a less degenerate version would be having a ring where every node belongs to two quorums, each with another node (or: two two nodes quorums).

The goal of quorum balancing is to produce a network graph with optimal safety & overhead. Note that the nodes that are quorum intersections are likely to be higher-staking nodes, as they have more to lose.

Example of rules:

• There is no quorum with < 3 nodes;
• There is no quorum with > 7 nodes;
• A quorum economic value must be >= 350,000 BOA;
• The top X (X=5?) stakers are placed in different quorums and used as 'seed';

Definition of done:

• A new validator is assigned a quorum immediately;
• Quorums get regularly shuffled (how often?);
• There is a sufficient (how much?) quorum intersection;
• Validators are distributed among quorums in an unpredictable manner;
• Validators are distributed among quorums in a fairly balanced way;
• Quorum distribution only depends on globally available state;

Tentative approach:

• Come up with a simple algorithm based on the example rules posted above;
• Build test case for working and non-working (byzantine) validators;
• Compute the economic penalty (low & high bounds) => If node A cheats, home much does it cost ? Is it aligned with the power this node has in the system ?;
• Optimize
• Repeat

[Geod24]

Depends on #209

[AndrejMitrovic]

- [ ] Validators are distributed among quorums in an unpredictable manner;

I think this sentence is not entirely correct. It should be predictable given another number X, which itself is unpredictable (and based on the preimage). So the algorithm to select the quorum is predictable, but its inputs are not predictable.

[AndrejMitrovic]

Quorums get regularly shuffled (how often?);

According to the yellow paper: Quorum balancing events happens once every 6 rounds.. So, every hour.

[AndrejMitrovic]

I would actually add that past performance of a validator should be taken into account when assigning quorums. For example:

The top X (X=5?) stakers are placed in different quorums and used as 'seed';

This could be gamed by a new player that spins up 5 new nodes and stakes more than the next 5 highest staked nodes. If we could incorporate the number N, where N is the number of times a node's public key participated in a finalized (accepted) vote for a block, then we could take into account the past performance of a node too. It should be a sort of "weight" to the algorithm.

[AndrejMitrovic]

Some research notes:

This post describes the new quorum config in Stellar, and also has a general overview of how quorums in Stellar work: https://medium.com/stellar-developers-blog/why-quorums-matter-and-how-stellar-approaches-them-547336c1275

The two PRs implementing semi-automatic quorum configuration and an "intersection-checker"
stellar/stellar-core#2125
stellar/stellar-core#2127

Here's a paper linked to from the blog post: https://arxiv.org/pdf/1902.06493.pdf. From the paper:

The Disjoint Quorums Problem answers the question whether a given instance of Federated
Byzantine Agreement System contains two quorums that have no nodes
in common. We show that this problem is NP-complete.

---

In our case we wouldn't mark any nodes as belong to an "organization" and the "quality" of the nodes would not be hardcoded, but instead we would just use the amount of stake as the marker of quality. After all, if a node misbehaves then it will get slashed, and its staked amount becomes lower (and therefore the "quality" of the node drops).

The blog post describes a commit we're not using yet (https://github.com/stellar/stellar-core/releases/tag/v11.2.0) which was released in June 28th 2019. We're using a commit from May 20th 2019.

It might be possible to reuse / adapt these Stellar routines (Config::generateQuorumSet / Config::generateQuorumSetHelper), if they don't depend on any Stellar-specific state. But we do have to take into account the random value and the quorum re-shuffling too.

---

Edit: Another useful article: https://www.stellar.org/developers-blog/intuitive-stellar-consensus-protocol

[AndrejMitrovic]

Currently the only part that is not fully implemented is:

• Quorums get regularly shuffled (how often?);

Right now the quorums only get reshuffled when the validator set changes (new enrollment, expired enrollment). But we may want to shuffle quorums regularly, for example every N blocks (N would be defined by the protocol).

However I think this will require more preimage support. In our unittests we have tests such as:

• Set validation cycle to 20
• Generate genesis
• Create 19 blocks
• Start the nodes

The nodes won't have any preimages on startup except the commitment in the enrollment in the genesis block. If we set the "periodic shuffle" N parameter to 10, then on boot-up the nodes would generate the quorums for block height 0 and then on block height 10. But it's not possible to test this right now because the preimages are missing for height 10, so this would lead to an assertion failure.