-
Notifications
You must be signed in to change notification settings - Fork 5
[Consensus Attack] Posterior Corruption #17
Comments
This is a write up from a conversation with @sa8 and @ZenGround0 regarding Posterior Corruption and its feasibility on both EC and an SPC protocol. Conclusion Background In EC
The attack context is as follows: attacker A acquires C>50% of power expressed at round X (ie in power table at round X-L) and proceeds to rewrite history. We take K to be the randomness lookback, L to be the power table lookback (at which stake/power is sampled) and Y to be the number of rounds between every PoST. The attacker has full power over the contents of the blocks produced by corrupted miners (whose keys were purchased). For those, A can simply generate new tickets and new block signatures. However, this is not so for non-corrupted blocks. Given that each block depends on the blocks before it, by changing any content in corrupted blocks, the attacker will change the chain's structure altogether: by changing block content for corrupted keys, the attacker will render honest blocks invalid (since A is unable to republish them with an updated pointers to corrupted prior blocks, see b), thereby yielding different TipSets (or no TipSets) at "honest" rounds, and changing the ticket chain within K blocks of the first round within which the smallest ticket was honest. Thereafter, the attacker will be mining with C% of power, adding C% of its expect weight at each round. Given our use of VDFs (see a), this chain is unlikely to overtake the honest one. We see that VDF use (or a hard block delay) forces the attacker to mine blocks at the same rate as the honest chain, thereby making any overtake of the network (given partial ownership of total stake) unlikely. You could picture the attacker purchasing 100% of power from rounds X to X+K (that is the keys in the power table from X-L to X-L+K), thereby making sure A has full controller over all future tickets. In that case however A is constrained to only mining with those keys, which assuming power in the network (ie storage) increases over time would yield a lighter chain (thanks to our VDF use again a). Now, let's introduce c into our thinking. Filecoin relies on storage-based power after all. We start by noting that this means it is possible for total "stake" or power to drop in the network (i.e. storage goes offline) in Filecoin while it is not in traditional PoS. Assuming power drops in the network (ie total storage drops), A could run a successful attack in spite of the VDF, given our current weight function which includes a function of total power in the chain: the miner would have to select X to be peak power, and then use that to mine heavier average blocks than are currently being mined by the honest network, eventually overtaking it. On the flip-side, storage-backed stake is extremely beneficial: Edit : the above point is dubious. L should be equal to proving period... a bit of lag doesn't matter but making it smaller doesn't help much (could get lucky) |
@ZenGround0 @sa8 does this reflect our convo? Anything to add? |
Purchasing all power from round n to n + k, you would stop being able to run the attack after some time since the ticket chain would change (PoSTs would no longer be replayable). In the case of purchasing 100% of power in the network at a given time, the real mitigation really is weight function (and assumption that chain total power grows).
This is a weaker case for Posterior corruption resistance without VDFs than previously thought. But this attack assumes 100% of keys get sold (ie 0 honest miners), in which case the attack depends on total power on the chain not growing. |
I'll add that outside of PoST replays, I ignore any sort of timing based attacks based on disk reuse: eg. slow down the clock (which you can owning all the power, or 51% even) and generate proofs using the same disk over and over (or some dishonest amount of disk): this strategic set of disk I/Os would likely slow down consensus meaning you don't catch up to real chain... |
cc @whyrusleeping @bvohaska @nicola @mhammersley @lucaniz @porcuquine on the dependencies for some of this on how PoST randomness is sampled. |
@sternhenri: great write-up! I have a few questions, From the Background section could you add,
Rephrasing the attack a little bit, can you tell me if the following statements are true:Assuming,
An adversary should not be able to generate
With less formal wording, an attacker shouldn't be able to obtain stake or power by making deals in the present for blocks in the past, start generating new blocks that are in the past but include this acquired power, be able to catch up t the current block height, and convince miners that this new chain is valid. With this reasoning, attack quantification can be represented by quantifying,
|
I expect what you are saying is true, but I have a hard time understanding proposition 2, so I may be missing something. With regards to the quantification, I think it also depends on the chain state's evolution itself. |
Proposition 2 bounds the attack to an adversary who (1) can only compute in BPP and (2) can only perform a certain number of calculations bounded in time by f_time(lambda). |
Noted! THanks for explaining, then yes I am on the same page as you! |
No description provided.
The text was updated successfully, but these errors were encountered: