docs: update the virtual group concept (#22)

part1.md

@@ -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, 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
@@ -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 chooses 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.

part3.md

@@ -326,19 +326,18 @@ $$ 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 workflows 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 Groups, it can submit a
+  `CompleteStorageProviderExit` transaction to retrieve the staked BNB.
 
 ## 17 Storage MetaData Models