fix: Documentation Corrections and Clarifications (#1962)

* Update precompile.md

* Update builder.md

* Update kzg.md

Author: savvar9991

documentation/src/crates/precompile.md

@@ -3,7 +3,7 @@
 The `precompile` crate contains the implementation of the Ethereum precompile opcodes in the EVM.
 Precompiles are a shortcut to execute a function implemented by the EVM itself, rather than an actual contract.
 Precompiled contracts are essentially predefined smart contracts on Ethereum, residing at hardcoded addresses and used for computationally heavy operations that are cheaper when implemented this way.
-There are 6 precompiles implemented in REVM, and they are: `blake2`, `bn128` curve, `identity`, `secp256k1`, `modexp`, and `sha256` and `ripemd160` hash functions.
+There are 7 precompiles implemented in REVM, and they are: `blake2`, `bn128` curve, `identity`, `secp256k1`, `modexp`, and `sha256` and `ripemd160` hash functions.
 
 ### Modules:
 

documentation/src/crates/primitives/kzg.md

@@ -1,6 +1,6 @@
 # KZG 
 
-With the introduction of [EIP4844](https://eips.ethereum.org/EIPS/eip-4844), this use of blobs for a more efficient short term storage is employed, the validity of this blob stored in the consensus layer is verified using the `Point Evaluation` pre-compile, a fancy way of verifying that and evaluation at a given point of a committed polynomial is valid, in a much more bigger scale, implies that `Data is Available`.
+With the introduction of [EIP4844](https://eips.ethereum.org/EIPS/eip-4844), this use of blobs for a more efficient short term storage is employed, the validity of this blob stored in the consensus layer is verified using the `Point Evaluation` pre-compile, a fancy way of verifying that and evaluation at a given point of a committed polynomial is valid, on a much bigger scale, implies that `Data is Available`.
 
 This module houses;
 

documentation/src/crates/revm/builder.md

@@ -4,11 +4,11 @@ The builder creates or modifies the EVM and applies different handlers.
 It allows setting external context and registering handler custom logic.
 
 The revm `Evm` consists of `Context` and `Handler`.
-`Context` is additionally split between `EvmContext` (contains generic `Database`) and `External` context (generic without restrain).
+`Context` is additionally split between `EvmContext` (contains generic `Database`) and `External` context (generic without restraint).
 Read [evm](./evm.md) for more information on the internals.
 
 The `Builder` ties dependencies between generic `Database`, `External` context and `Spec`.
-It allows handle registers to be added that implement logic on those generics.
+It allows handler registers to be added that implement logic on those generics.
 As they are interconnected, setting `Database` or `ExternalContext` resets handle registers, so builder stages are introduced to mitigate those misuses.
 
 Simple example of using `EvmBuilder`:
@@ -28,7 +28,7 @@ There are two builder stages that are used to mitigate potential misuse of the b
 - `SetGenericStage`: Initial stage that allows setting the database and external context.
 - `HandlerStage`: Allows setting the handler registers but is explicit about setting new generic type as it will void the handler registers.
 
-Functions from one stage are just renamed functions from other stage, it is made so that user is more aware of what underlying function does.
+Functions from one stage are just renamed functions from other stage, it is made so that the user is more aware of what underlying function does.
 For example, in `SettingDbStage` we have `with_db` function while in `HandlerStage` we have `reset_handler_with_db`, both of them set the database but the latter also resets the handler.
 There are multiple functions that are common to both stages such as `build`.
 
@@ -164,7 +164,7 @@ fn main() {
 ## Appending handler registers
 
 Handler registers are simple functions that allow modifying the `Handler` logic by replacing the handler functions.
-They are used to add custom logic to the evm execution but as they are free to modify the `Handler` in any form they want.
+They are used to add custom logic to the evm execution but they are free to modify the `Handler` in any form they want.
 There may be conflicts if handlers that override the same function are added.
 
 The most common use case for adding new logic to `Handler` is `Inspector` that is used to inspect the execution of the evm.