feat: virtual group and sp exit

[fynnss]

Description

In the previous design, the operator addresses of storage providers were directly stored in BucketInfo and ObjectInfo, resulting in a significant amount of metadata modification when a storage provider exited. To address this issue, we propose the concept of virtual groups. A virtual group consists of a primary storage provider and several secondary storage providers. Each object is associated with a virtual group, limiting the range of secondary storage providers for storing object replica data. This design offers several benefits. Firstly, it provides better support for bucket migration and storage provider exit, reducing the number of transactions required. Secondly, it reduces the size of metadata stored on the blockchain for both buckets and objects.

However, this proposal will have a huge impact on various existing modules and processes. The key changes are listed as follows:

• A new additional module called Virtual Group Module, is responsible for managing all the virtual groups.
• A new data location indexing format for object and storage provider
• A new staking rule based on storage size for a storage provider
• A new stream payment path based on a virtual group payment account

Virtual Group Module

We will introduce a new module to manage all virtual groups. The number of storage providers in each virtual group is determined by the redundancy policy. E.g If our redundancy policy specifies a full replica and a 4+2 erasure coding (EC) replica tree, so every virtual group should have one primary sp and six secondary sp.

Terminology

Global Virtual Group (GVG): A global virtual group consists of one primary SP (SP) and multiple secondary SPs.
Local Virtual Group(LVG): Each bucket maintains a mapping from the local group ID to the global group ID. j(e.g 3 ➝ 001960583).
Virtual Group Family(VGF): Each primary storage provider can create multiple virtual group families, with each family containing several global virtual groups. Each family serves a limited number of buckets. Once the store size exceeds a specified threshold, the family will no longer allow to serve more buckets.

Relationships

Local virtual groups are linked to their corresponding buckets, and each object needs to store the ID information of the local virtual group. Each local virtual group must correspond to one and only one global virtual group.

In order to avoid all the data of a primary SP being transferred to one SP within a short period of time, we introduce the concept of "family". 

A family can contain multiple GVG that the same SP creates. A bucket can only be served by the GVGs that are in the same family, cross family GVG is not allowed within one bucket. Once the total storage size of a family exceeds 64TB(TBD), the GVG inside the family can not server new buckets, the SP has to create a new family. By introducing family , the primary SP can exit at family level without breaking the one bucket, one primary SP rule.

[Need confirm] When all GVGs within a family become unavailable and it's not possible to create new GVGs and add them to the family, how to handle this situation?

Staking

We introduce a new staking rule based on storage size. The minimum required staking tokens can be calculated using the formula storage_staking_price * stored_size . The storage providers have the option to pre-stake tokens for upcoming storage if needed.

All staking tokens will be managed by the Virtual Group Module account. Only during deletion or swapping out, the storage providers can get these staking tokens back. In the event of a storage provider's forced exit, these tokens will be forfeited and used to reward those storage providers which take over these GVG.

SP Exit

1. The Storage Provider (SP1), initiates the exit process by submitting a StorageProviderExit transaction to the blockchain.
2. The SP1 or its successor SP must then repeatedly call SwapOut to remove itself from all Global Virtual Groups (GVGs).

• For the primary SP, the swap-out process occurs at the family level to ensure there are no conflicts with other SPs within the GVG.
• For secondary SPs, the swap-out happens at the GVG level and must also avoid conflicts with the primary SP.

3. Once the SP1 has successfully completed the swap-out process from all GVGs, it can submit a CompleteStorageProviderExit transaction to retrieve the staked tokens.

Bucket Migration

1. The user submits a bucket migration transaction with the signature of the new primary SP.
2. The new SP starts receiving full data from the old primary SP or from secondary SPs.
3. The new SP distributes data among the secondary SPs according to his new GVPs. (more details required...)
4. The new SP submit a bucket seal transaction on-chain along with all the aggregate signature from new secondary SPs.
5. The on-chain module will:

• Unbind the old LVG and GVG mapping, and build a new mapping relationship.
• Settle the payment stream between LVG, GVF, and SPs.

6. During the migration period, the user can not upload files to this bucket.
7. During the migration period, the old SP should still serve the query request.

Rationale

This solution can significantly reduce the amount of meta data modifications when the service provider (SP) exits or during bucket migration.

Example

NA

Changes

Notable changes:

• NA

[unclezoro]

Is it possible that a streamrecord is STREAM_ACCOUNT_STATUS_ACTIVE and still ExistsAutoResumeRecord?

[forcodedancing]

no, when the stream is changed to active, the related AutoResumeRecord will be deleted.

[unclezoro]

If this is the case, why dont we use the status of stream record to replace the ExistsAutoResumeRecord condition here?