Filecoin and Asymmetric Sealing

[ZenGround0]

This is a record of some ideas coming out of a conversation last week with several people, in particular @nicola and @lucaniz.

Most ideas follow directly from the PiE paper from 2019.

Today the filecoin network is a single payer that purchases arbitrary data through the block reward. Because it is purchasing arbitrary data it requires the data to be in a particular slowly encoded form, i.e. sealed, to prevent regeneration and outsourcing attacks. Furthermore its permissive purchasing requires an additional stronger property: symmetric encode and decode times, i.e. slow unseal. In general this is required to avoid the so called "seal stack" attack.

This works as follows, take raw data D and seal it S(D) = R. Now take R and seal again S(S(D)) = S(R) = R'. If unseal U is fast then you can prove space (i.e. PoSt) over both R and R' while only storing R'. The filecoin network will hence payout twice for one unit of storage.

With the FVM the network will allow the possibility of many payers with specialized purchasing policies. One of many interesting use cases is an external blockchain network purchasing storage of blockchain transactions or state for persistent storage. This data satisfies an interesting property: blockchain data D can be assumed to not be of the form S(D') for some D'. Data with this property is immune from seal stack attacks and can therefore be encoded under an asymmetric sealing scheme with a corresponding fast unsealing scheme (see PiE paper for a concrete construction). This means a new payer on the network that purchases such a restricted set of data could do so with the same security properties as the network today while enabling fast unsealing of this data.

Blockchain data is a nice example of data robust against seal stacking because some portion of the paying network would need to collude and/or network participants would need to give up some opportunity cost of processing legitimate transactions or committing legitimate state in order to pull off an attack against the data payer.

Additional trust assumptions could similarly be used to provide the guarantees needed to unlock fast unsealing in less restricted contexts. One possible example is to use a scheme like FIL+. FIL+ data by definition of the program should be useful and therefore not be of the form S(D') for some D'. Fraud detection would of course become more important as the power multiplier per fraudulent space would increase with the potential for seal stack now opened up.

[anorth]

Even without the property of being blockchain data, we could consider the possibility of an asymmetric PoRep being used to prove storage of data for a client, but with no block reward. Without the block reward subsidy, providers of such storage would presumably charge a higher price, but there might be some use cases where fast un-sealing would still make this attractive to some clients.