Seal and PoST security hardness discussion

[sternhenri]

This writeup should ultimately find a home elsewhere, but given this came up in a quick conversation with @jbenet and @ZenGround0 and may deserve a follow up conversation (not to mention corrections where I've mischaracterized things), I thought an issue the better place to start.

As a reminder (skip for a bit if you know), the Filecoin protocol relies on a few forms of consensus. We have:

• Storage Power Consensus (SPC), which guarantees that participants in a network agree on which miners contribute what power (in the form of pledged and sealed storage) to the network, and provably so.
• Expected Consensus (EC), which allows participants in a system to agree on a leader selection, given a certain distribution of power between participants (could be pledged storage in FIL, token ownership in a traditional PoS system, or hash rate in a bitcoin-like PoW system, etc.). EC can itself provide various guarantees, for FIL purposes, we look at two constructions:
  • EC running Secret Leader Election, it will output 1 leader on expectation with some local predictability (ie the winner(s) will know k round in advance that she/they will win the round)
  • EC running Single Secret Leader Election, it will output 1 leader with some local predictability (so yes, EC might output 1 leader at all times under this construction).

---

Great, now some thoughts related to Filecoin specifically (and maybe the space in general): 1) We claim that it is safer for miners to run Proofs of Space in between their pledge and their Seal, as that effectively commits their resources to the network (on the other hand it may negatively impact market dynamics), thereby increasing security from a 51% attack. 1) We claim that there are two levels of hardness to FIL security guarantees (illustration below)

• Soft security guarantee: ton-chain random sampling means that clients claiming the same stored data on two chains with PoSTs can be caught and slashed.
• Hard security guarantee: through Seals, using on-chain randomness, clients can only commit their space to one chain. In the diagram above, the squares represent proofs (of different striations/types), the single lines represent on-chain events (where clients interact), and the striped bars represent chain-produced randomness. The striped green vertical bar is a fork, after which we have two chains: the blue chain, and the green chain (forked from blue). Red arrows from the chain represent challenges sampled over time for the proofs.

1) We claim that hard FIL security (through Seals) may in fact be safer than BTC PoW. I think that last claim was based on ASIC development vs the storage market. @jbenet to confirm.

[sternhenri]

From a convo with @ZenGround0

• on 1. Now there is a cost for me to pledge but not seal. Makes market more liquid? Helps do more.
• on 2. Can't seal both with a different seed (unlike post) because you only have one disk.