Apply suggestions from code review

Co-authored-by: sandreim <54316454+sandreim@users.noreply.github.com>
paritytech · Dec 28, 2021 · d06335b · d06335b
1 parent 9a3dc98
commit d06335b
Show file tree

Hide file tree

Showing 2 changed files with 4 additions and 4 deletions.
diff --git a/roadmap/implementers-guide/src/node/utility/candidate-validation.md b/roadmap/implementers-guide/src/node/utility/candidate-validation.md
@@ -12,11 +12,11 @@ Output: Validation result via the provided response side-channel.
 
 ## Functionality
 
-This subsystem answers two categories of requests: one validates candidates and the other is for PVF pre-checking. 
+This subsystem groups the requests it handles in two categories:  *candidate validation* and *PVF pre-checking*. 
 
-The first category can be further subdivided on two request types: one which draws out validation data from the state, and another which accepts all validation data exhaustively. There are three possible outputs of validation: either the candidate is valid, the candidate is invalid, or an internal error occurred. Whatever the end result is, it will be returned on the response channel to the requestor.
+The first category can be further subdivided in two request types: one which draws out validation data from the state, and another which accepts all validation data exhaustively. Validation returns three possible outcomes on the response channel: the candidate is valid, the candidate is invalid, or an internal error occurred. 
 
-Parachain candidates are validated against their validation function: A piece of Wasm code that is describes the state-transition of the parachain. Validation function execution is not metered. This means that an execution which is an infinite loop or simply takes too long must be forcibly exited by some other means. For this reason, we recommend dispatching candidate validation to be done on subprocesses which can be killed if they time-out.
+Parachain candidates are validated against their validation function: A piece of Wasm code that describes the state-transition of the parachain. Validation function execution is not metered. This means that an execution which is an infinite loop or simply takes too long must be forcibly exited by some other means. For this reason, we recommend dispatching candidate validation to be done on subprocesses which can be killed if they time-out.
 
 Upon receiving a validation request, the first thing the candidate validation subsystem should do is make sure it has all the necessary parameters to the validation function. These are:
   * The Validation Function itself.

diff --git a/roadmap/implementers-guide/src/runtime-api/pvf-prechecking.md b/roadmap/implementers-guide/src/runtime-api/pvf-prechecking.md
@@ -13,7 +13,7 @@ fn pvfs_require_precheck() -> Vec<ValidationCodeHash>;
 ```
 
 The second runtime API is needed to submit the judgement for a PVF, whether it is approved or not.
-The process voting process is based on unsigned transactions. The [`PvfCheckStatement`](../types/pvf-prechecking.md) is circulated through the network via gossip similar to a normal transaction. At some point the validator
+The voting process uses unsigned transactions. The [`PvfCheckStatement`](../types/pvf-prechecking.md) is circulated through the network via gossip similar to a normal transaction. At some point the validator
 will include the statement in the block, where it will be processed by the runtime. If that was the
 last vote before gaining the super-majority, this PVF will not be returned by `pvfs_require_precheck` anymore.