| fip | title | author | discussions-to | status | type | category | created | spec-sections |
|---|---|---|---|---|---|---|---|---|
0051 |
Synchronous Consistent Block Broadcast for EC Security |
Guy Goren <[email protected]>, Alfonso de la Rocha <[email protected]> |
Draft |
Technical |
Core |
2022-11-07 |
Modifies client behaviour (in particular the miners) to verify that the sender is not equivocating before accepting a block.
Currently, a block is accepted if it is received before the cutoff time and is the first from its sender in the epoch. Blocks that are received after the cutoff time are ignored. This mechanism enables an attacker to exploit the cutoff in order to send equivocating blocks (i.e., different blocks in the same epoch, with the same "winning ticket") to different miners, causing miners to build upon different tipsets and, hence, damaging the progress of the honest chain.
This proposal suggests a simple fix to the above. A recipient waits a predefined time (e.g. 6 seconds) between receiving a block and accepting it. If, during this time, the recipient detects equivocation, it does not accept the block. By waiting, the recipient can be practically certain that a sender's equivocation will be suppressed since by this time (practically) all other miners would also hear of the block via gossip.
A security analysis shows that, given the current "best effort" broadcast combined with the cutoff time, an attacker with
The following pseudocode describes the consistent broadcast verification algorithm at a high level. Notice that the proposed change affects only the Filecoin miner as a receiver of a tipset; sending (and gossiping) a block remains unchanged. Delta is a tunable parameter which corresponds to the assumed upper bound on gossip delay (originating from an honest node). The protocol also uses block_set, a dictionary where a key is a tuple <round, winning_ticket> and a value is a set of blocks (for efficiency, blocks could be represented by their hashes).
Delta = 6 seconds # time for gossip to reach all
Upon receiving block B=<source, round, winning_ticket> do:
propagate B acording to the gossip protocol;
if B is valid:
if not block_set[round, winning_ticket]:
block_set[round, winning_ticket] = {};
block_set[round, winning_ticket].add(B); # can use hash of B
if len(block_set[round, winning_ticket])>1:
return # detected equivoqation
wait Delta; # wait the gossip time to ensure reach
if len(block_set[round, winning_ticket])==1:
return B
Garbage collection is handled orthogonally: block_set[round, winning_ticket] can be deleted after
The design goal is to introduce a simple change without severe repercussion to other functionalities of the systems. This means approaching the core of the matter (the mechanism that enable equivocation). This allows for orthogonal changes in the incentive design mechanism, since the change does not tie them together.
The ConsensusLab team explored potential mitigation strategies and narrowed down the list for the following possible strategies: (for more details see this document)
-
Removing tipsets (in expectation) from EC, effectivelly boiling down the protocol to an almost longest-chain protocol instead of a longest-tipset protocol. By removing tipsets and having a more similar design to traditional blockchains (i.e., one block per epoch in expectation) the problem is mitigated.
👍 Simple to implement -- changing the expected number of blocks from 5 to 1.
👍 Easier to analyse theoretically -- trivially follows the existing literature on Proof-of-Stake blockchains.
👎 Damages the expected settelment times in the simple case. I.e., it takes longer (more epochs) to achieve 99% settlement certainty against the simple block witholding attack.
👎 The impact of a change would be substantial and very possibly negatively percieved by the community. Changing the number of blocks per epoch affects the miners economic calculations directly and is very visible to miners and the entire ecosystem. This is a very negative point about this option.
👎 Requires a Filecoin upgrade. Might split the blockchain between adopting miners and not-yet adopting miners.
-
Adding an asynchronous consistent broadcast layer. By adding a Consistent broadcast (C-BCast) the attacker can no longer equivocate. This solves the problem at its core.
👍 Strikes at the core of the issue --- the equivocation of the attacker, by making a very targetted and specific consensus change.
👍 Arguably easier to be accepted by miners. They feel no meaningful difference (same number of expected blocks, same payments, etc.), the change is behind the scenes only.
👍 Does not depend on timing assumptions.
👎 Requires a Filecoin upgrade. A miner that adopts the change cannot receive blocks from miners that didn't adopt the change.
-
Adding a synchronous consistent BCast layer (with the 6 second
magic number).👍 Strikes at the core of the issue --- the equivocation of the attacker, by making a very targetted and specific consensus change.
👍 Arguably easier to be accepted by miners. They feel no meaningful difference (same number of expected blocks, same payments, etc.), the change is behind the scenes only.
👍 Does not require a fork.
👎 Depends on timing assumptions. That is, gossip propagation within 6 seconds.
Considering the trade-offs, the ConsensusLab team would like to propose the use of synchronous consistent broadcast as the mitigation strategy (i.e., the last of the three proposed mitigations). The benefits of easy adoption due to only "behind the scence changes" and no Filecoin-upgrade required, outweigh the shortcomings (timing assumptions). Moreover, even if the timing assumptions are violated, the consistency degrades gracefully (that is, a slightly longer than expected gossip delay would lead to only a small amount of equivocating blocks being accepted rather than to a "cliff phenomenon" where all equivocating blocks are accepted). Also, using the synchronous approach does not require significant changes to the underlying broadcast protocol, which is already well tested and has built-in failure detecting mechnisms.
The proposal does not introduce backward compatibility issues. A miner that adopted the change will still accept blocks from honest non-adopting miners, and non-adopting miners will still accept blocks from adopting miners. The system's security will improve monotonically with the share of adopting miners.
The following tests need to be done:
- Demonstrating the attack on the current system (with naive BCast)
- We have the implementation of the basic attack (for each round independently).
- No tests in testground were performed.
- Showing the same attack after the implementation of Consistent BCast
- We have the implementation of an upgraded lotus client (incorporates consistent BCast).
- We have the implementation of an attacking node (same as before).
- No test in testground was performed.
- Showing the performance of the improved protocol in normal test cases
- We have the implementation of an upgraded lotus client (incorporates consistent BCast).
- Possibly run a few upgraded miners on mainnet for a while showing that they function correctly. This is possible since the fix does not break consensus.
Replacing the naive best-effort broadcast with consistent broadcast improves considerably the security of Filecoin. There is the risk of using the synchronous approach which relies on timing assumptions (in cases of extreme network asynchrony, in which case the modified protocol would not be worse in terms in security than the current protocol). However, the benefits of the synchronous approach outweigh the risks.
Regarding liveness, we do not forsee problems due to the added delay prior to acceptance. This is because 1) assuming a worst-case propagation delay of 6 secondes, any cutoff
The proposal is intentionally decoupled from incentive considerations. It is neither dependent on them, nor does it limit changes to incentive mechanisms.
A question may arise: isn't equivocation slashable in Filecoin, and therfore should not concern us? Equivocating is indeed slashable, however, there are 2 issues regarding slashing as a solution. tl;dr: 1) conceptually, it is dangerous to rely on rationality that is based only on internal incentives. 2) Slashing/Blacklisting does not solve the problem.
- Assuming rationality of the attacker implies that we know their incentives (typically assumed that those incentives are just to maximize their internal profits in Filecoin). In practice, we don't really know the attacker incentives. For example, since performing this attack would severely damage Filecoin's credibility, an attacker that "rationally" gains extra Filecoins from the attack might, actually, lose due to Filecoin's collapse. On the other hand, an attacker that externally benefits from a Filecoin collapse (e.g. short trading) might not care about the slashing. Thus, it is dangerous to rely on rationality that is based only on internal incentives.
- Slashing/Blacklisting does not solve the problem. In Filecoin, an attacker can spread their power (storage) over multiple identities. For example, a 20% attacker can have as much as
$3.6\times10^5$ different identities. Since these identities seem independent to all but the attacker, slashing will only affect the individual identity that equivocated at that epoch. Therefore, the attacker can sacrifice (w.h.p.) one identity per epoch. And even after attacking for ~1000 epochs the attacker will only sacrifice less than 0.03% of her resources.
By mitigating attack on Filecoin, the proposal improves the resilience of the system. The proposal does not require any operational changes (besides adopting the protocol update) from the users.
filecoin-project/lotus#9858 brings consistent broadcast, as specified above, to lotus master
Copyright and related rights waived via CC0.