Skip to content

Commit

Permalink
update the virtual group concept
Browse files Browse the repository at this point in the history
  • Loading branch information
unclezoro committed Aug 1, 2023
1 parent 9ad2bf6 commit 8e0cb64
Show file tree
Hide file tree
Showing 2 changed files with 37 additions and 15 deletions.
28 changes: 26 additions & 2 deletions part1.md
Original file line number Diff line number Diff line change
Expand Up @@ -417,7 +417,31 @@ software they use must specify the primary SP. Primary SP should be used
as the only SP to download the data. Users can change the primary SP for
their objects later if they are not satisfied with their service.

#### 5.2.2 Data Redundancy
#### 5.2.2 Virtual Group and Virtual Family

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. 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.

A Virtual Family consists of several Virtual Groups that share the same primary storage provider.
A Virtual Family has limited storage capacity. When the number of Virtual Groups in a Virtual Family reaches its limit,
a new Virtual Family needs to be created.

#### 5.2.3 Staking For Storage

Primary SP must stake BNB for the Virtual Group it creates before it can provide storage services.
The minimum required staking tokens can be calculated bt the following formula:
`storage_staking_price * stored_size.`

Storage providers can choose to pre-stake tokens for future storage if necessary.
The excessive staked BNB can be retrieved anytime.

If a storage provider force exit, the staking will be slashed as a reward to storage providers who
take over the Virtual Group.

#### 5.2.4 Data Redundancy

After the users issue a "write" request, Primary SP should respond to
the client upload request to accept the user upload, chop the object
Expand Down Expand Up @@ -497,7 +521,7 @@ matches the object's metadata by comparing the checksum of the object on
Greenfield chain and the checksum of the payload data; If it matches the
primary SP will sign the "uploaded" confirmation to the users;

c. The primary SP syncs with secondary SPs to set up the data redundancy,
c. The primary SP choose a Virtual Group and syncs with secondary SPs inside the group to set up the data redundancy,
and then it signs a "Seal" transaction with the finalized metadata for storage.
If the primary SP determines that it doesn't want to store the file due to
whatever reason, it can also "SealReject" the request.
Expand Down
24 changes: 11 additions & 13 deletions part3.md
Original file line number Diff line number Diff line change
Expand Up @@ -326,19 +326,17 @@ $$ data challenge reserves = (1 - \frac{1}{SP Number + 1}) * Maximum Percent $$

Data availability challenge will be covered in the later section.

#### 16.3.4 Remove Storage Provider

Anyone can submit a proposal to remove a storage provider if the
storage provider doesn't provide a good service or prefers to stop
service. The current active validators can vote on this proposal. Once this
proposal is passed, the SP will be restricted from accepting new object-storing
requests, but still has the obligation to serve query requests. Other
SPs or the data owners should start requesting to move the data off
this "to-be-removed" SP. The "to-be-removed" SP has to facilitate the data
moving so that it can get the full deposit back and avoid further slash.
Actually, even if it chooses to not cooperate, the data can be recovered from
the other SPs. After all the data has been migrated, this "to-be-removed" SP
can withdraw all its deposit, and this SP would be removed.
#### 16.3.4 Storage Provider Exit

Storage providers can freely decide to exit, but SPs must complete a graceful exit to ensure no users are affected,
otherwise, part of staked BNB from the SP will be slashed. Below are the key workflow about how SP exit:
- The Storage Provider (SP1), initiates the exit process by submitting a `StorageProviderExit` transaction to the blockchain.
- The SP1 or its successor SP must then repeatedly call `SwapOut` to remove itself from all Virtual Groups.
- For the primary SP, the swap-out process occurs at the family level to ensure there are no conflicts with other SPs
within the Virtual Group.
- For secondary SPs, the swap-out happens at the Virtual Group level and must also avoid conflicts with the primary SP.
- Once the SP1 has successfully completed the swap-out process from all Virtual Group, it can submit a
`CompleteStorageProviderExit` transaction to retrieve the staked BNB.

## 17 Storage MetaData Models

Expand Down

0 comments on commit 8e0cb64

Please sign in to comment.