In this post we will reffer at  Massa blockclique Multi-Staking Protection , if you did not know already  Massa use a multithreaded block graph allowing nodes to create blocks in parallel and process 10’000 transactions per second.

Blockclique Introduction

In Blockclique [1] as in other Proof-of-Stake blockchains, the computational cost of creating a block is negligible, which is different from Proof-of-Work blockchains. When a node is selected to produce a block in a slot, in practice it can thus create multiple blocks with different hashes for the same slot,while only one can be taken into account by other nodes in that slot. Double- or multi-staking is thus considered as a kind of flooding attack. Tezos [2], a Proof-of-Stake blockchain with a Nakamotolike consensus seems to have no particular protection against this attack other than an incentive mechanism with a double-staking punishment.

In a blockchain, if the attacker sends many different and incompatible blocks of the same slot to each node, the next block producer will choose one of them as parent, then produce and broadcast its block. This block producer thus helps in choosing one of the alternative attacker blocks. However, if no particular protection is taken, the attacker can still bloat the network by creating thousands or millions of valid blocks in all of its slots. This attack could make it harder for honest nodes to get to a consensus on the executed blocks, even more if the attacker has a large proportion of the block production power, say 30%.

Intuitively, there are three possible strategies to cope with this flooding attack:

• FIGHT: Wait for the next block producers to choose one of the alternative chains and ask for the
missing blocks. Repeat if the attacker reiterates. Ban nodes that send too many unsolicited
blocks for the same slot.
• IGNORE: Once at least two attacker blocks have been received for the same slot, consider all of
them invalid and consider that the attacker missed. Ban nodes that send too many unsolicited
blocks for the same slot.
• EQUIVALENT: Consider all alternative blocks of a same slot as the same equivalent block. Ban
nodes that send too many unsolicited blocks for the same slot.

While in blockchains, the FIGHT strategy might be sufficient to avoid consequences on liveness, it may not be for the parallel structure of Blockclique due to the numerous and parallel opportunities for the attacker to create incompatible blocks. The IGNORE strategy seems to be a bad idea: an attacker could trigger a finality fork by broadcasting a second block for a slot around the moment when the first one becomes final. Here we study the EQUIVALENT strategy for Blockclique.

The EQUIVALENT strategy in Blockclique

The goal of this strategy is to consider all blocks of the same slot as compatible and equivalent, such
that each node never needs to download more than one full valid block per slot (see Fig. 1).

Figure 1: Node selected for slot 8 published 2 distinct blocks for this slot, 8a and 8b. Block 10 points
to 8a and block 11 points to 8b. Node selected for slot 12 received all previous blocks, in the order
(8a, 8b, 9, 10, 11). There are no incompatibilities so only one clique. Transactions of 8a and 8b
won’t be processed when they become final, they can be included again in block 12 and processed
when 12 becomes final.

Graph Rules

The thread and grandpa rules are replaced by the following sequential validity rule and parallel incompatibility rule.

Sequential Validity Rule

B is valid if
All parents of B are in slots before the slot of B
Ancestors of B in a given thread are ancestors of the parent of B in that thread
All parents of B are mutually compatible
(1)

Parallel Incompatibility Rule

Let B1 and B2 be two parallel blocks (each one is not the ancestor of the other one). B1 and B2
are incompatible if and only if:

t(B1) − t(B2)| ≥ t0
or B1 is incompatible with an ancestor of B2
or B2 is incompatible with an ancestor of B1
(2)
where t(B) is the timestamp of block B.

Notes:

• Inside a thread, the difference with the thread incompatibility rule is that here multistaked blocks in a same slot are compatible (unless they inherit incompatibilities, e.g. if they have a
different parent).
• Across threads, this rule is stronger than the GPI rule: GPI-incompatible blocks are incompatible with this rule, but there are other cases where GPI-compatible blocks are incompatible
here. In particular, it is not longer possible to publish valid blocks in a given thread that is lagging behind other threads due to block misses.
TODO: examples: TI different slots, TI same slot, GPI incompatible, GPI compatible but PIR incompatible.

Incompatibilities of multistaked blocks

Multistaked blocks can be incompatible in the following cases:

• Two blocks in a same slot S are incompatible if they reference two different blocks in a same
previous slot S
0 with t(S
0
) ≤ t(S) − t0.
• Two blocks in a same slot S are incompatible if one of them has an older parent in a given thread than the other one.
Each incompatible multistaked block leads to a new clique with maximal or close to maximal fitness. To avoid this, we add the following rule which avoid computation of parallel incompatibilities:
• Two blocks of a same slot are parents of one another if they have the same parent in their thread.
Notes:
• With this rule, the processing of a multistaked block in a slot S can change the incompatibilities of other blocks in S, so we have to recompute the incompatibilities of all blocks when we process
a new multistaked block, and when multistaked blocks becomes final.

Read all post downloading the pdf