From bd6c62d46009f586a661d3e1c797f84bb8cfb59a Mon Sep 17 00:00:00 2001 From: Steven Li Date: Sun, 25 Jun 2023 16:43:36 +0800 Subject: [PATCH 1/9] Create fip-xxxx-move-partitions.md --- FIPS/fip-xxxx-move-partitions.md | 82 ++++++++++++++++++++++++++++++++ 1 file changed, 82 insertions(+) create mode 100644 FIPS/fip-xxxx-move-partitions.md diff --git a/FIPS/fip-xxxx-move-partitions.md b/FIPS/fip-xxxx-move-partitions.md new file mode 100644 index 00000000..f7c19721 --- /dev/null +++ b/FIPS/fip-xxxx-move-partitions.md @@ -0,0 +1,82 @@ +--- +fip: "" +title: Allow SPs to move partitions between deadlines +author: Steven Li (@steven004), Alan Xu (@zhiqiangxu), Mike Li (@hunjixin), Alex North (@anorth), Nickle (@nickle) +discussions-to: https://github.com/filecoin-project/FIPs/discussions/735 +status: Draft +type: Technical (Core) +category: Core +created: 2023-06-25 +--- + +## Summary +Add a new method for Miner actor to allow SPs to move a partition of sectors from one deadline to another, so that an SP could have control over their WindowedPoSt schedule. + +## Abstract +In _WindowPoSt_ every 24-hour period is called a _“proving period”_ and is broken down into a series of 30min, non-overlapping _deadlines_, making a total of 48 deadlines within any given 24-hour proving period. Each sector is assigned to one of these deadlines when proven to the chain by the network, grouped in partitions. The WindowPoSt of a particular partitions in a deadline has to be done in that particular 30min period every 24 hours. + +This proposal is to add a method `MovePartitions` to move all sectors in one or more partitions from one deadline to another to allow SPs control the WindowPoSt time slot for sectors. + +## Change Motivation +When a Storage Provider (SP) maintains storage for Filecoin network, they often encounter various challenges such as system performance degradation, network issues, facility maintenance, and even changes in data center location. While dealing with these challenges, SPs require greater flexibility in controlling the period to prove the data integrity to the chain, while still adhering to the rule of proving once every 24 hours. + +By implementing this proposal, several advantages can be realized: + +- Creation of user-defined maintenance windows: SPs can create designated periods for maintenance activities without the risk of losing power. +- Definition of free hours for better duty roster: SPs can allocate specific hours of the day as free hours, enabling them to optimize their duty roster. This can be achieved by moving partitions out of those hours. +- Cost savings for large SPs on WindowPoSt hardware: Balancing the number of partitions across all the deadlines allows large SPs to optimize their hardware usage and reduce WindowPoSt hardware costs. +- Relieving access stress on storage nodes: In scenarios where an excessive number of partitions are concentrated within a single deadline on specific storage nodes, redistributing some partitions to other deadlines can help alleviate access stress and improve overall performance. +- Possibility of partition compaction: By moving partitions from different deadlines into a single deadline, it becomes possible to compact partitions that were originally distributed across multiple deadlines. + +## Specification +We propose adding the following method to the built-in `Miner` Actor. + +``` golang +// Moves sectors in partitions in one deadline to another +// Returns false if failed +// Any non-zero exit code must also be interpreted as a failure of moving +func (a Actor) MovePartitions(rt Runtime, params *MovePartitionsParams) *abi.EmptyValue +``` + +The params to this method indicate the partitions, their original deadline and destination deadline. +``` rust +type MovePartitionsParams struct { + OrigDeadline uint64 + DestDeadline uint64 + Partitions bitfield.BitField +} +``` + +To adhere to the requirement of conducting a _WindowPoSt_ every 24 hours, the `MovePartitions` function only permits the movement of partitions to a `DestDeadline` whose next proving period is scheduled to occur within 24 hours after the `OrigDeadline`'s last proving period. If the `DestDeadline` falls outside of this time frame, it will fail. This restriction ensures that the sector's period aligns with the required _WindowPoSt_ interval. + +## Design Rationale +The primary objective is to introduce a straightforward mechanism for implementing flexible proving period settings for Storage Providers (SPs). Additionally, there is a consideration to offer greater flexibility by allowing the movement of any selected sectors from one deadline to another. This would enable an SP to align the expiration of sectors within a single partition. However, this approach poses certain risks, such as the potential increase in the cost of managing the bitfield due to non-sequential sector IDs. Moreover, the technical complexity involved in understanding the cost calculation may lead to unnecessary difficulties for SP operators. + +## Backwards Compatibility +This proposal introduced a new method to the built-in actors, which needs a network upgrade, but otherwise breaks no backwards compatibility + +## Test Cases +Proposed test cases include: +‒ that the `MovePartitions` can be successful when moving one partition from a deadline to another which proving period is in 24 hours after the partition's last proving period; +‒ that the `MovePartitions` would fail when moving one partition from a deadline to another which proving period is beyond 24 hours after the partition's last proving period; +‒ that the `MovePartitions` can be successful when moving multiple partitions from a deadline to another which proving period is in 24 hours after partitions' last proving period; +‒ that the `MovePartitions` would fail when moving multiple partitions from a deadline to another which proving period is beyond 24 hours after partitions' last proving period; +‒ that the _WindowedPoSt_ works as normal in the `DestDeadline` for partitions moved from its `OrigDeadline`; +‒ that the `CompactPartitions` works as normal for the new moved-in partitions and existing partitions in the `DestDeadline` + +## Security Considerations +This proposal is to provide more flexibility for SPs to have full control of proving period of _WindowPoSt_ for partitions. In the design, we still ask the SPs to follow the basic rule that one partition should have one proof every 24 hours, so there is no compromise in this regard. + +There might be a concern that overall _WindowPoSt_ messages in the network might imbalance over the 48 proving periods due to adjustments by SPs. Considering _WindowPoSt_ only takes about 10% of the whole network bandwidth, and the network is decentralized, it should not be a problem, in addition, this mechanism actually provide a way for SPs to move proving period to avoid a expected congestion period. + +## Incentive Considerations +This FIP does not effect incentives in itself and is of only flexibility providing without any impact on economic factors. + +## Product Considerations +There is no any impact on Filecoin ecosystem application or platforms. + +## Implementation +An implementation can be provided after further discussion of the proposal. + +## Copyright +Copyright and related rights waived vis [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 8ec472c2228d82a96dd35df19c035c8d2f7c21d6 Mon Sep 17 00:00:00 2001 From: Steven Li Date: Fri, 30 Jun 2023 09:50:07 +0800 Subject: [PATCH 2/9] Added the implementation reference. --- FIPS/fip-xxxx-move-partitions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/FIPS/fip-xxxx-move-partitions.md b/FIPS/fip-xxxx-move-partitions.md index f7c19721..9f8d2568 100644 --- a/FIPS/fip-xxxx-move-partitions.md +++ b/FIPS/fip-xxxx-move-partitions.md @@ -76,7 +76,7 @@ This FIP does not effect incentives in itself and is of only flexibility providi There is no any impact on Filecoin ecosystem application or platforms. ## Implementation -An implementation can be provided after further discussion of the proposal. +These changes have been implemented in [this PR](https://github.com/filecoin-project/builtin-actors/pull/1326). ## Copyright Copyright and related rights waived vis [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From ac14d20959261dd53aa92f7b5f7e84db088e6490 Mon Sep 17 00:00:00 2001 From: Steven Li Date: Tue, 1 Aug 2023 10:14:09 +0800 Subject: [PATCH 3/9] Correct Name Co-authored-by: Jiaying Wang <42981373+jennijuju@users.noreply.github.com> --- FIPS/fip-xxxx-move-partitions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/FIPS/fip-xxxx-move-partitions.md b/FIPS/fip-xxxx-move-partitions.md index 9f8d2568..b054278b 100644 --- a/FIPS/fip-xxxx-move-partitions.md +++ b/FIPS/fip-xxxx-move-partitions.md @@ -1,7 +1,7 @@ --- fip: "" title: Allow SPs to move partitions between deadlines -author: Steven Li (@steven004), Alan Xu (@zhiqiangxu), Mike Li (@hunjixin), Alex North (@anorth), Nickle (@nickle) +author: Steven Li (@steven004), Alan Xu (@zhiqiangxu), Mike Li (@hunjixin), Alex North (@anorth), Nicola (@nicola) discussions-to: https://github.com/filecoin-project/FIPs/discussions/735 status: Draft type: Technical (Core) From 6461a6ed4a7e3c3f361f0a225a8c201104b717f1 Mon Sep 17 00:00:00 2001 From: Steven Li Date: Tue, 1 Aug 2023 10:16:42 +0800 Subject: [PATCH 4/9] Update FIPS/fip-xxxx-move-partitions.md Co-authored-by: Jiaying Wang <42981373+jennijuju@users.noreply.github.com> --- FIPS/fip-xxxx-move-partitions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/FIPS/fip-xxxx-move-partitions.md b/FIPS/fip-xxxx-move-partitions.md index b054278b..66977d1b 100644 --- a/FIPS/fip-xxxx-move-partitions.md +++ b/FIPS/fip-xxxx-move-partitions.md @@ -23,7 +23,7 @@ When a Storage Provider (SP) maintains storage for Filecoin network, they often By implementing this proposal, several advantages can be realized: - Creation of user-defined maintenance windows: SPs can create designated periods for maintenance activities without the risk of losing power. -- Definition of free hours for better duty roster: SPs can allocate specific hours of the day as free hours, enabling them to optimize their duty roster. This can be achieved by moving partitions out of those hours. +- Set hours of operation for SP infrastructure maintainers: SPs can schedule all WindowPoSts during hours of operation to optimize the maintenance operation resources/on-call schedules. - Cost savings for large SPs on WindowPoSt hardware: Balancing the number of partitions across all the deadlines allows large SPs to optimize their hardware usage and reduce WindowPoSt hardware costs. - Relieving access stress on storage nodes: In scenarios where an excessive number of partitions are concentrated within a single deadline on specific storage nodes, redistributing some partitions to other deadlines can help alleviate access stress and improve overall performance. - Possibility of partition compaction: By moving partitions from different deadlines into a single deadline, it becomes possible to compact partitions that were originally distributed across multiple deadlines. From b5590083e87456d8520b0604074f42bf03e98726 Mon Sep 17 00:00:00 2001 From: Steven Li Date: Tue, 1 Aug 2023 15:01:10 +0800 Subject: [PATCH 5/9] Revised to accommodate Jennifer's comments. --- FIPS/fip-xxxx-move-partitions.md | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/FIPS/fip-xxxx-move-partitions.md b/FIPS/fip-xxxx-move-partitions.md index 66977d1b..a5f2482c 100644 --- a/FIPS/fip-xxxx-move-partitions.md +++ b/FIPS/fip-xxxx-move-partitions.md @@ -25,8 +25,8 @@ By implementing this proposal, several advantages can be realized: - Creation of user-defined maintenance windows: SPs can create designated periods for maintenance activities without the risk of losing power. - Set hours of operation for SP infrastructure maintainers: SPs can schedule all WindowPoSts during hours of operation to optimize the maintenance operation resources/on-call schedules. - Cost savings for large SPs on WindowPoSt hardware: Balancing the number of partitions across all the deadlines allows large SPs to optimize their hardware usage and reduce WindowPoSt hardware costs. -- Relieving access stress on storage nodes: In scenarios where an excessive number of partitions are concentrated within a single deadline on specific storage nodes, redistributing some partitions to other deadlines can help alleviate access stress and improve overall performance. -- Possibility of partition compaction: By moving partitions from different deadlines into a single deadline, it becomes possible to compact partitions that were originally distributed across multiple deadlines. +- Relieving access stress on storage nodes: In scenarios where numerous partitions need complete WindowedPoSt within a short period and their sectors located in a specific storage node in a distributed storage system, the excessive read requests in that period can overload the node and degrade its performance. Moving some partitions to other deadlines helps achieve a more balanced workload. +- Increasing possibility of compacting partition: By moving partitions from different deadlines into a single deadline, it becomes possible to compact partitions that were originally distributed across multiple deadlines. ## Specification We propose adding the following method to the built-in `Miner` Actor. @@ -50,7 +50,13 @@ type MovePartitionsParams struct { To adhere to the requirement of conducting a _WindowPoSt_ every 24 hours, the `MovePartitions` function only permits the movement of partitions to a `DestDeadline` whose next proving period is scheduled to occur within 24 hours after the `OrigDeadline`'s last proving period. If the `DestDeadline` falls outside of this time frame, it will fail. This restriction ensures that the sector's period aligns with the required _WindowPoSt_ interval. ## Design Rationale -The primary objective is to introduce a straightforward mechanism for implementing flexible proving period settings for Storage Providers (SPs). Additionally, there is a consideration to offer greater flexibility by allowing the movement of any selected sectors from one deadline to another. This would enable an SP to align the expiration of sectors within a single partition. However, this approach poses certain risks, such as the potential increase in the cost of managing the bitfield due to non-sequential sector IDs. Moreover, the technical complexity involved in understanding the cost calculation may lead to unnecessary difficulties for SP operators. +The main goal of this proposal is to introduce a straightforward mechanism for enabling flexible proving period scheduling for Storage Providers (SPs). `MovePartitions` means all sectors in the particular partitions are all together moved from the original deadline to the destination deadline if it executed successfully. + +Another aspect to consider is the possibility of allowing the movement of selected sectors from one deadline to another, which would enable Storage Providers (SPs) to align the expiration of sectors within a single partition. However, this approach comes with certain risks, such as potential cost increases in managing the bitfield due to non-sequential sector IDs, leading to unexpected gas usage. Moreover, the technical complexity involved in understanding the gas calculation could create unnecessary difficulties for SP operators. Additionally, implementing this feature introduces a significant level of complexity to the system. + +This proposal does not currently adopt the second aspect to ennsure a more straightforward and manageable implementation, leaving the movement of selected sectors for future study. + + ## Backwards Compatibility This proposal introduced a new method to the built-in actors, which needs a network upgrade, but otherwise breaks no backwards compatibility From 1831d2eb9ef63699cecd1250172d1d374da0c273 Mon Sep 17 00:00:00 2001 From: Steven Li Date: Thu, 3 Aug 2023 14:21:11 +0800 Subject: [PATCH 6/9] More constraints and rules added in specification section --- FIPS/fip-xxxx-move-partitions.md | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/FIPS/fip-xxxx-move-partitions.md b/FIPS/fip-xxxx-move-partitions.md index a5f2482c..684e3b15 100644 --- a/FIPS/fip-xxxx-move-partitions.md +++ b/FIPS/fip-xxxx-move-partitions.md @@ -29,7 +29,9 @@ By implementing this proposal, several advantages can be realized: - Increasing possibility of compacting partition: By moving partitions from different deadlines into a single deadline, it becomes possible to compact partitions that were originally distributed across multiple deadlines. ## Specification -We propose adding the following method to the built-in `Miner` Actor. +We propose the addition of a new method to the built-in `Miner` Actor, called `MovePartitions`, which allows Storage Providers (Miners) to move sectors within partitions from one deadline to another. + +### Method Signature and Parameters ``` golang // Moves sectors in partitions in one deadline to another @@ -47,7 +49,14 @@ type MovePartitionsParams struct { } ``` -To adhere to the requirement of conducting a _WindowPoSt_ every 24 hours, the `MovePartitions` function only permits the movement of partitions to a `DestDeadline` whose next proving period is scheduled to occur within 24 hours after the `OrigDeadline`'s last proving period. If the `DestDeadline` falls outside of this time frame, it will fail. This restriction ensures that the sector's period aligns with the required _WindowPoSt_ interval. +### Constraits and Rules + +1. To adhere to the requirement of conducting a _WindowPoSt_ every 24 hours, the `MovePartitions` function only permits the movement of partitions to a `DestDeadline` whose next proving period is scheduled to occur within 24 hours after the `OrigDeadline`'s last proving period. If the `DestDeadline` falls outside of this time frame, it will fail. This restriction ensures that the sector's period aligns with the required _WindowPoSt_ interval. +2. Partitions cannot be moved to or from a deadline during its challenge window or immediately before it, matching existing mutability constraints. +3. A partition containing faulty or unproven sectors cannot be moved. +4. The partitions are moved as a whole, without any compaction. +5. An empty partition is left behind in the source deadline after the move. This ensures that partition indices do not change. +6. If the original deadline falls within its optimistic WindowPoSt challenge window, the previously submitted WindowPoSt is validated during the MovePartitions method's execution. This validation helps to demonstrate the correctness of the previously submitted WindowPoSt data. ## Design Rationale The main goal of this proposal is to introduce a straightforward mechanism for enabling flexible proving period scheduling for Storage Providers (SPs). `MovePartitions` means all sectors in the particular partitions are all together moved from the original deadline to the destination deadline if it executed successfully. From 259ff7c48c025af57017bcf4256afbc15a01ca8e Mon Sep 17 00:00:00 2001 From: Steven Li Date: Wed, 9 Aug 2023 14:32:59 +0800 Subject: [PATCH 7/9] constraints (word correction) --- FIPS/fip-xxxx-move-partitions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/FIPS/fip-xxxx-move-partitions.md b/FIPS/fip-xxxx-move-partitions.md index 684e3b15..df7e41c9 100644 --- a/FIPS/fip-xxxx-move-partitions.md +++ b/FIPS/fip-xxxx-move-partitions.md @@ -49,7 +49,7 @@ type MovePartitionsParams struct { } ``` -### Constraits and Rules +### Constraints and Rules 1. To adhere to the requirement of conducting a _WindowPoSt_ every 24 hours, the `MovePartitions` function only permits the movement of partitions to a `DestDeadline` whose next proving period is scheduled to occur within 24 hours after the `OrigDeadline`'s last proving period. If the `DestDeadline` falls outside of this time frame, it will fail. This restriction ensures that the sector's period aligns with the required _WindowPoSt_ interval. 2. Partitions cannot be moved to or from a deadline during its challenge window or immediately before it, matching existing mutability constraints. From 937650c2fc0956a541cff37cd09cf0b7108866a8 Mon Sep 17 00:00:00 2001 From: Steven Li Date: Mon, 14 Aug 2023 09:17:40 +0800 Subject: [PATCH 8/9] FIP number 0070 is assigned. --- FIPS/{fip-xxxx-move-partitions.md => fip-0070.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename FIPS/{fip-xxxx-move-partitions.md => fip-0070.md} (99%) diff --git a/FIPS/fip-xxxx-move-partitions.md b/FIPS/fip-0070.md similarity index 99% rename from FIPS/fip-xxxx-move-partitions.md rename to FIPS/fip-0070.md index df7e41c9..0686578e 100644 --- a/FIPS/fip-xxxx-move-partitions.md +++ b/FIPS/fip-0070.md @@ -1,5 +1,5 @@ --- -fip: "" +fip: "FIP-0070" title: Allow SPs to move partitions between deadlines author: Steven Li (@steven004), Alan Xu (@zhiqiangxu), Mike Li (@hunjixin), Alex North (@anorth), Nicola (@nicola) discussions-to: https://github.com/filecoin-project/FIPs/discussions/735 From 230e3bfc9cd60012de79cd69ac02670d5dbfdc45 Mon Sep 17 00:00:00 2001 From: Steven Li Date: Mon, 14 Aug 2023 09:22:19 +0800 Subject: [PATCH 9/9] Update README.md to accommodate FIP-0070 --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 2aaab65d..bc26844f 100644 --- a/README.md +++ b/README.md @@ -101,3 +101,4 @@ This improvement protocol helps achieve that objective for all members of the Fi |[0060](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0060.md) | Set market deal maintenance interval to 30 days | FIP |Jakub Sztandera (@Kubuxu), @Zenground0, Alex North (@anorth)| Final | |[0061](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0061.md) | WindowPoSt Grindability Fix | FIP |@cryptonemo @Kubuxu @DrPeterVanNostrand @Nicola @porcuquine @vmx @arajasek| Final | |[0062](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0062.md) | Fallback Method Handler for the Multisig Actor | FIP |JDimitris Vyzovitis (@vyzo), Raúl Kripalani (@raulk)| Final | +|[0070](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0070.md) | Allow SPs to move partitions between deadlines | FIP |Steven Li (@steven004), Alan Xu (@zhiqiangxu), Mike Li (@hunjixin), Alex North (@anorth), Nicola (@nicola)| Draft |