fix comment

part1.md

@@ -521,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 choose a Virtual Group and syncs with secondary SPs inside the group 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

@@ -329,13 +329,13 @@ Data availability challenge will be covered in the later section.
 #### 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:
+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 Group, it can submit a 
+- 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