doc: Minor grammar fixes (#7922)

Fixes some minor grammar issues from #7918.

docs/architecture/gas_params/README.md

@@ -15,11 +15,11 @@ The [Gas Profile](./gas_profile.md) section goes into more details on how gas
 costs of a transaction are tracked in nearcore.
 
 The [runtime parameter estimator](./estimator.md) is a separate binary within
-the nearcore repository. It contains benchmarking-like code that is used to
-validate existing parameters values. Or when new features are added, new code
-has to be added there to estimate the safe values of new parameters. That
-section is for you if you want to add new features, such as a new pre-compiled
-method or other host functions.
+the nearcore repository. It contains benchmarking-like code used to validate
+existing parameters values. When implementing new features, code should be added
+there to estimate the safe values of the new parameters. This section is for you
+if you are adding new features such as a new pre-compiled method or other host
+functions.
 
 
 <!-- TODO: ## Action parameters-->

docs/architecture/gas_params/estimator.md

@@ -7,7 +7,7 @@ all users collude to make the system as slow as possible.
 
 This benchmarking suite is used check that the gas parameters defined in the
 protocol are correct. Correct in this context means, a chunk filled with 1 Pgas
-will only take 1 second to be applied. Or more generally, per 1 Tgas of
+will take at most 1 second to be applied. Or more generally, per 1 Tgas of
 execution, we spend no more than 1ms wall-clock time. 
 
 For now, nearcore timing is the only one that matters. Things will become more

docs/architecture/gas_params/gas_profile.md

@@ -1,11 +1,11 @@
 # Gas Profile
 
-The transaction runtime charges gas in various places around the code. But they
-all end up summaries inside an `ActionResult`. More specifically, the counters
-`gas_burnt` and `gas_used` and the `profile` field that keeps track of what the
-gas has been spent on.
+The transaction runtime charges gas in various places around the code. The
+charges end up as summaries inside an `ActionResult`. More specifically, the
+`gas_burnt` and `gas_used` counters track the total gas required and the
+`profile` field keeps track of what the gas was spent on.
 
-## Charing Gas
+## Charging Gas
 Generally speaking, gas is charged right before the computation that it pays for
 is executed. It has to be before to avoid cheap resource exhaustion attacks.
 Imagine the user has only 1 gas unit left but we start executing an expensive