chore: fix typos (#968)

chore: fix typos

CHANGES.md

@@ -101,7 +101,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 ### Fixes
 
 - Fixed underflow in the modexp gas calculation by [@guidovranken]. ([#883])
-- Prevented subtraction underflow in th xcc module by [@guidovranken]. ([#888])
+- Prevented subtraction underflow in the xcc module by [@guidovranken]. ([#888])
 - Fixed balance and gas overflows in the xcc module by [@guidovranken]. ([#889])
 
 ### Changes
@@ -287,7 +287,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ### Fixes
 
-- Use ibig implemenation of modexp by [@birchmd]. ([#778])
+- Use ibig implementation of modexp by [@birchmd]. ([#778])
 
 [#778]: https://github.com/aurora-is-near/aurora-engine/pull/778
 
@@ -504,9 +504,9 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 ### Changes
 
 - Performance improvements by [@birchmd] and [@matklad]; the engine should now consume much less NEAR gas: ([#427]) ([#438]) ([#439]) ([#445]) ([#446])
-- Security improvment: only Engine contract owner can use the `deploy_upgrade` method by [@birchmd]. ([#410])
+- Security improvement: only Engine contract owner can use the `deploy_upgrade` method by [@birchmd]. ([#410])
 - Bug fix: Engine now returns the error message in the case of a revert during an EVM contract deploy, previously it would always return an address (even when the deploy failed) by [@birchmd]. ([#424])
-- Security improvment: Engine will no longer accept EVM transactions without a chain ID as part of their signature by [@birchmd]. This should have no impact on users as all modern Ethereum tooling includes the chain ID. ([#432])
+- Security improvement: Engine will no longer accept EVM transactions without a chain ID as part of their signature by [@birchmd]. This should have no impact on users as all modern Ethereum tooling includes the chain ID. ([#432])
 - Improvements to code quality by [@mrLSD]: ([#386]) ([#387])
 - Improvements and additions to internal tests and benchmarks by [@birchmd]: ([#408]) ([#415]) ([#429])
 
@@ -592,7 +592,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ### Added
 
-- Public method for computing Aurora blockhash at a given hight by [@birchmd]. ([#303](https://github.com/aurora-is-near/aurora-engine/pull/303))
+- Public method for computing Aurora blockhash at a given height by [@birchmd]. ([#303](https://github.com/aurora-is-near/aurora-engine/pull/303))
 
 ### Changed
 

README.md

@@ -141,7 +141,7 @@ The following tasks are available to clean up the workspace:
 
 Additionally, there is also but not included in the `clean` task:
 
-- `sweep`: sweeps the set amount of days in the ENV, default at 30 days.
+- `sweep`: sweeps the set amount of days in the ENV, default to 30 days.
 
 For example, the following command will clean everything. `profile` is not 
 required:
@@ -154,5 +154,5 @@ cargo make clean
 
 ## License
 **aurora-engine** has multiple licenses:
-* All crates except `engine-test` has **CCO-1.0** license
+* All crates except `engine-test` have **CCO-1.0** license
 * `engine-test` has **GPL-v3** license

doc/benchmarks.md

@@ -13,13 +13,13 @@ A final quantity of interest is the wall-clock time to execute a transaction.
 This is less important for us as a smart contract on NEAR, but is reasonably important for the NEAR runtime itself.
 At a high level, the NEAR runtime attempts to maintain the invariant that 1000 Tgas worth of computation can be completed in 1 second (regardless of which operations happen within this 1000 Tgas).
 This arises from the [1000 Tgas gas limit](https://github.com/near/nearcore/blob/9a41274ddef3616ab195b24a207389c5ad5c7f5a/nearcore/res/genesis_config.json#L20) per block and the [1 second block time](https://github.com/near/nearcore/blob/9a41274ddef3616ab195b24a207389c5ad5c7f5a/nearcore/res/genesis_config.json#L238).
-Moreover, the runtime wants the there to be a linear relationship between gas usage and time taken to complete the computation.
+Moreover, the runtime wants a linear relationship between gas usage and time taken to complete the computation.
 Obviously wall-clock time is not a stable metric as it varies according to the hardware and other details of the system running the test.
 This means in reality the NEAR runtime measures gas costs by counting CPU instructions, with the assumption this has a rough correlation with wall-clock time.
 For us, we measure wall-clock time because it is simpler and we do not need extreme precision the same way the runtime itself does.
 The primary goal of these wall-clock measurements is simply to check the runtime's assumptions about the linear relationship between gas used and wall-clock time, and how much gas can be consumed in 1 second.
 
-## How to do we measure these things?
+## How do we measure these things?
 
 NEAR gas is measured by [importing the NEAR runtime as a library](https://github.com/aurora-is-near/aurora-engine/blob/0fe4f0506866bd8813b270760864d22723925962/engine-tests/Cargo.toml#L34-L35), and executing our engine contract inside it.
 There a [simple profiling structure](https://github.com/near/nearcore/blob/9a41274ddef3616ab195b24a207389c5ad5c7f5a/core/primitives-core/src/profile.rs#L49) that is returned by the runtime which breaks down how much NEAR gas was used by each host function which we also use.
@@ -64,7 +64,7 @@ make mainnet-test-build && cargo test --features mainnet-test uniswap
 ```
 
 The adding liquidity operation consumes around 500k EVM gas, and around 165 NEAR Tgas.
-With an EVM gas limit of 15 million on Ethereum. this means around 30 such operations could fit in one block.
+With an EVM gas limit of 15 million on Ethereum. This means around 30 such operations could fit in one block.
 30 such operations on Aurora would cost nearly 5000 Tgas, the equivalent of 5 blocks.
 Therefore, for this benchmark we aim to have it cost 1/5th the amount of NEAR gas it does presently.