filecoin-project / consensus

Filecoin consensus work
Other
42 stars 5 forks source link

Impact of removing VDF from EC #16

Closed sternhenri closed 5 years ago

sternhenri commented 5 years ago

This seeks to tackle the broader question of EC security should VDFs fail. It is related to:

We believe sans VDF, EC falls back to other protocol security (like SW), but this deserves further examination. VDFs failing opens up risk on three fronts:

  1. Miners rushing the protocol
  2. Simulation attacks and grinding
  3. Posterior corruption becomes more feasible (but not fully feasible, see #17)

Expected Consensus (EC) research currently assumes that a secure VDF will be available for use in ticket-generation. Specifically, tickets that are included in every new block are generated from past tickets by running them through a VDF and a VRF.

Fuller description is tracked here -- internal to FIL research team for now given a few non-security logistical issues discussed.

To try and quantify the cost of failure a bit, we have:

I -- advantage from speedup for an attacker, releasing multiple blocks before others release any (or fewer).

The idea here is to gain an advantage over other miners by propagating blocks faster. In the case where the attacker wins the next block, they can mine early thereby robbing other miners of their potential wins (note that this would have to be often enough for people to forego the weight of a larger tipset in a given round for more rounds).

The higher attacker power, the lower the speedup required for an attack to be successful. At higher speedups, the attacker can have farther reach in releasing sets of blocks mined over multiple rounds.

Now some data:

Say with a block time of 30 seconds, a_max of 1.5 means the attacker can run the VDF in 20 seconds. With 2, we have 15 seconds.

So this is a bit hand-wavy, but I would say by a_max=2 we start to be in trouble for any attacker power (in terms of storage), where the attacker can win twice in a row and release both rounds before an honest miner releases one. This is not a crazy assumption: an attacker with 30% power would win twice with 9% probability...

We should aim for [1.5, 2] AMax.

II -Simulation attack.

a - posterior corruption

I think any advantage there has us dead in the water since the attacker has potentially infinite time to catch up, however I believe the storage part of PoST saves us here (issue to come).

b - grinding

With that said no VDFs opens up a lot of miner power in terms of an attacker being able to try out multiple runs of K rounds to decide which TipSets to form, and increases adversary power/their ability to selfish mine.

whyrusleeping commented 5 years ago

@sternhenri quick note, not responding fully yet, but we will be very happy if we can get an ASIC with an Amax of 10. 1.5-2 is borderline impossible.

sternhenri commented 5 years ago

Understood! Thank you. I will think about what this means for us.

On Tue, Apr 16 2019 at 21:05, < notifications@github.com > wrote:

@sternhenri ( https://github.com/sternhenri ) quick note, not responding fully yet, but we will be very happy if we can get an ASIC with an Amax of

  1. 1.5-2 is borderline impossible.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub ( https://github.com/filecoin-project/consensus/issues/16#issuecomment-483928948 ) , or mute the thread ( https://github.com/notifications/unsubscribe-auth/ADNBaxzZ5SrZBhiG3Ae7FrILQqgVkQY4ks5vhp1ygaJpZM4aMGWB ).

sternhenri commented 5 years ago

A couple more thoughts from a conversation with @sa8.

Removing VDF must be safe-ish under certain conditions:

1) So do we lose liveness?

2) How big a deal is this grinding? A very very big deal. The lookback makes it actually seem worst since it's that much more straightforward to simulate ahead and decide how to time attacks based on future winning blocks (that can now be released instantly). However, in reality, it's not deeply worst than without the lookback I think.

Mitigants:

2) What about posterior corruption?

3) And rushing the protocol?

sternhenri commented 5 years ago

Added thoughts on issues around lookback w/w.o. VDF.

The issue with no VDF, or a broken VDF (functionally equivalent) is that a miner can run block withholding.

Specifically, the user can withhold a block, knowing that they will win the next one, and then release both at once.

This is made much easier with a lookback parameter, since the attacker will know the next k blocks.

With no VDF, knowing (ie a lookback) doesn't change that much since the attacker can just simulate (prop time >> compute time); however with a VDF present, you can no longer simulate so knowing is key to running the attack or not.

Block withholding attack with perfect predictive power (point is to get an advantage, not break).

So this maybe is an argument against lookback rather than any other point. Though it doesn't much matter if VDFs break.

sternhenri commented 5 years ago

downsides of penalizing wt on null: