-
Notifications
You must be signed in to change notification settings - Fork 165
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #75 from deltazxm/patch-1
All V1 sealed proof sector expansion to 540 days
- Loading branch information
Showing
2 changed files
with
114 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,112 @@ | ||
--- | ||
fip: "0014" | ||
title: Allow V1 proof sectors to be extended up to a maximum of 540 days | ||
author: deltazxm (@deltazxm), Neo Ge(@neogeweb3) | ||
discussions-to: https://github.com/filecoin-project/FIPs/issues/56 | ||
status: Draft | ||
type: Technical | ||
created: 2021-26-02 | ||
spec-sections: | ||
- section-systems.filecoin_mining.sector.lifecycle | ||
|
||
--- | ||
|
||
## 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](https://github.com/filecoin-project/FIPs/pull/75#issuecomment-789405523). | ||
|
||
## 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](https://semiengineering.com/big-trouble-at-3nm/) 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](https://www.quora.com/How-long-does-it-take-to-build-a-computer-chip-from-scratch). | ||
|
||
## 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](https://www.dvhardware.net/article72264.html) 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](https://github.com/filecoin-project/FIPs/pull/75#discussion_r586057806) and by @steven004 at [here](https://github.com/filecoin-project/FIPs/issues/56#issuecomment-785715308). 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 | ||
|
||
Set `SectorMaxLifetime` for v1 sectors to be 540 days | ||
|
||
```go | ||
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: | ||
|
||
```go | ||
if !CanExtendSealProofType(sector.SealProof) { | ||
rt.Abortf(exitcode.ErrForbidden, "cannot extend expiration for sector %v with unsupported seal type %v", | ||
sector.SectorNumber, sector.SealProof) | ||
} | ||
``` | ||
|
||
## Copyright | ||
|
||
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters