All V1 sealed proof sector expansion to 540 days

[deltazxm]

V1 seal proof sectors extension

[jennijuju]

Thank you for submitting the FIP! In the motivation section, you mentioned some security concern and stated that those aren’t harmful to the network, please elaborate more and include some data to support that statement in the security consideration. Please also include product considerations before we can assign an FIP number to this proposal and move forward.

[kaptinlin]

I do not recommend merge this proposal. This will bring insecurity to the network. And many v1 sectors are free sectors of SP1.

[deltazxm]

I do not recommend merge this proposal. This will bring insecurity to the network. And many v1 sectors are free sectors of SP1.

After 2020-10-15 sectors are not free.

[momack2]

There are actually significant security considerations for v1 vs v1.1 sectors (which is why the network upgraded to v1.1 sectors in the first place). Can you clarify how this proposal will upgrade v1 sectors to ensure they are as secure as v1.1 sectors to make them eligible for extension?

[neogeweb3]

I think what @deltazxm was trying to say is to extend v1 proof sector lifecycle instead of upgrading v1 to v1.1. I will quote @deltazxm below "Only sectors sealed prior to November 24th, 2020 have the issue, it's not financially beneficial for anyone to develop specific chips to hack these sectors. Sectors sealed prior to November 24th, 2020 have different lengths of the lifecycle (180/360/540 days), if lifecycle extension is not approved, at least we expect some fairness on this. In another word, change all the lifecycle to 540 days, then let them die after that. "

[steven004]

@deltazxm I agree with @neogeweb3 to achieve some fairness on lifetime limitation and also consider the security concern.
Could this be changed to "Limit maximum lifetime for security concern, instead of disabling extension". This should apply to all versions, in the future too.

This will make code cleaner and fairer to all miners. For current supported two proof types, V1 and V1.1; We can define the following parameters in file https://github.com/filecoin-project/specs-actors/blob/master/actors/builtin/sector.go, please notice that we set 540 days for V1 and 5 years for V1.1

const EpochsInFiveYears = stabi.ChainEpoch(5 * EpochsInYear)
const EpochIn540Days = stabi.ChainEpoch(EpochsInYear + EpochsInYear/2)

var SealProofPolicies = map[stabi.RegisteredSealProof]*SealProofPolicy{
	stabi.RegisteredSealProof_StackedDrg2KiBV1: {
		SectorMaxLifetime: EpochIn540Days,
	},
	stabi.RegisteredSealProof_StackedDrg8MiBV1: {
		SectorMaxLifetime: EpochIn540Days,
	},
	stabi.RegisteredSealProof_StackedDrg512MiBV1: {
		SectorMaxLifetime: EpochIn540Days,
	},
	stabi.RegisteredSealProof_StackedDrg32GiBV1: {
		SectorMaxLifetime: EpochIn540Days,
	},
	stabi.RegisteredSealProof_StackedDrg64GiBV1: {
		SectorMaxLifetime: EpochIn540Days,
	},

	stabi.RegisteredSealProof_StackedDrg2KiBV1_1: {
		SectorMaxLifetime: EpochsInFiveYears,
	},
	stabi.RegisteredSealProof_StackedDrg8MiBV1_1: {
		SectorMaxLifetime: EpochsInFiveYears,
	},
	stabi.RegisteredSealProof_StackedDrg512MiBV1_1: {
		SectorMaxLifetime: EpochsInFiveYears,
	},
	stabi.RegisteredSealProof_StackedDrg32GiBV1_1: {
		SectorMaxLifetime: EpochsInFiveYears,
	},
	stabi.RegisteredSealProof_StackedDrg64GiBV1_1: {
		SectorMaxLifetime: EpochsInFiveYears,
	},
}

And remove the following condition in ExtendSectorExpiration method:

if !CanExtendSealProofType(sector.SealProof) {
		rt.Abortf(exitcode.ErrForbidden, "cannot extend expiration for sector %v with unsupported seal type %v",
		sector.SectorNumber, sector.SealProof)
}

which is not needed any more.

[deltazxm]

@deltazxm I agree with @neogeweb3 to achieve some fairness on lifetime limitation and also consider the security concern.
Could this be changed to "Limit maximum lifetime for security concern, instead of disabling extension". This should apply to all versions, in the future too.

This will make code cleaner and fairer to all miners. For current supported two proof types, V1 and V1.1; We can define the following parameters in file https://github.com/filecoin-project/specs-actors/blob/master/actors/builtin/sector.go, please notice that we set 540 days for V1 and 5 years for V1.1

const EpochsInFiveYears = stabi.ChainEpoch(5 * EpochsInYear)
const EpochIn540Days = stabi.ChainEpoch(EpochsInYear + EpochsInYear/2)

var SealProofPolicies = map[stabi.RegisteredSealProof]*SealProofPolicy{
	stabi.RegisteredSealProof_StackedDrg2KiBV1: {
		SectorMaxLifetime: EpochIn540Days,
	},
	stabi.RegisteredSealProof_StackedDrg8MiBV1: {
		SectorMaxLifetime: EpochIn540Days,
	},
	stabi.RegisteredSealProof_StackedDrg512MiBV1: {
		SectorMaxLifetime: EpochIn540Days,
	},
	stabi.RegisteredSealProof_StackedDrg32GiBV1: {
		SectorMaxLifetime: EpochIn540Days,
	},
	stabi.RegisteredSealProof_StackedDrg64GiBV1: {
		SectorMaxLifetime: EpochIn540Days,
	},

	stabi.RegisteredSealProof_StackedDrg2KiBV1_1: {
		SectorMaxLifetime: EpochsInFiveYears,
	},
	stabi.RegisteredSealProof_StackedDrg8MiBV1_1: {
		SectorMaxLifetime: EpochsInFiveYears,
	},
	stabi.RegisteredSealProof_StackedDrg512MiBV1_1: {
		SectorMaxLifetime: EpochsInFiveYears,
	},
	stabi.RegisteredSealProof_StackedDrg32GiBV1_1: {
		SectorMaxLifetime: EpochsInFiveYears,
	},
	stabi.RegisteredSealProof_StackedDrg64GiBV1_1: {
		SectorMaxLifetime: EpochsInFiveYears,
	},
}

And remove the following condition in ExtendSectorExpiration method:

if !CanExtendSealProofType(sector.SealProof) {
		rt.Abortf(exitcode.ErrForbidden, "cannot extend expiration for sector %v with unsupported seal type %v",
		sector.SectorNumber, sector.SealProof)
}

which is not needed any more.

thanks @steven004.I will modify the FIP according to your suggestion

[Fatman13]

Hello, @deltazxm, I compiled security consideration section for product considerations per @jennijuju's request. Please feel free to take a look. Thank you!

Simple Summary

Allow V1 proof sectors to be extended up to a maximum of 540 days.

Abstract

Allow sectors sealed using V1 proof before network upgrade of v1.2.0 on Nov 27th, 2020 to be extended up to a maximum of 540 days including the days that they have already been active.

Change Motivation

While every encryption/proof created ever by human beings has security issues, V1 proof is now being challenged with unrealistically high standard of security concerns. This fip advocates that V1 proof sectors should be treated equally just like any other sectors.

Specification

Key changes proposed by @steven004 could be found here.

Design Rationale

The design is quite straight forward. Suggestions are welcome.

Backwards Compatibility

TODO: Test cases for an implementation are mandatory for FIPs that are affecting consensus changes. Other FIPs can choose to include links to test cases if applicable.

Security Considerations

Security concerns from the community boils down to @nicola's following comment.

There is a risk that a year+ from now, with highly pipelined custom hardware (less likely to be software - but not impossible), one may able to avoid storing 100% of the sector and still succeed at WindowPoSt.**

As we come closer to these sectors' expiration (most are a ~year from now), depending on (1) what percentage of power these sectors sum up to, (2) what is the state of the art of ASICs and Proof of Space software, the community should decide what to do with those sectors.

I would not recommend to allow for sector extension right now.

Cost of designing custom hardware (ASICs)

From data aggregated by semiengineering, the design cost alone of developing a cutting edge chip could amount to ~$540M which is equivalent to the revenue of running a 120Pib node for 3 years given the current network parameters.

Time for development of custom hardware (ASICs)

It is estimated that manufacturing a chip from scratch could take 1 to 2 years.

Securing production of custom hardware (ASICs)

There are mainly two options someone could get their chip design produced, namely from TSMC or Samsung. Attackers will be competing with all smart devices manufacturers for "production cap". Months of waiting time is the norm given how the market is craving smart devices nowadays.

Incentives of attackers

Under the circumstances mentioned above, there wouldn't be any incentives for attackers to invest huge amount of time and money just to fake a discontinued proof.

Additionally, the concern is addressed by @neogeweb3 at here and by @steven004 at here. In short, the general consensus is that it is not economically viable that attacker could develop custom hardware using tech that is a year+ from now.

Incentive Considerations

Majority of the people who sealed sectors using V1 proof for 180 days will now most likely to extend them to 540 days.

Product Considerations

This fip protects interests of miners who have contributed to filecoin's growth since mainnet launch.

Implementation

#75 (comment)

Copyright

Copyright and related rights waived via CC0.