From 02ec7079195a15dac0304b01ee5348a5548d67b7 Mon Sep 17 00:00:00 2001 From: Savely <136869149+savvar9991@users.noreply.github.com> Date: Wed, 1 Jan 2025 13:09:29 +1100 Subject: [PATCH 1/3] Update precompile.md --- documentation/src/crates/precompile.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/src/crates/precompile.md b/documentation/src/crates/precompile.md index 643ba75942..c01c6760a0 100644 --- a/documentation/src/crates/precompile.md +++ b/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: From d5edd7db56ffd5e1eae365ae4bde0382935cab3e Mon Sep 17 00:00:00 2001 From: Savely <136869149+savvar9991@users.noreply.github.com> Date: Wed, 1 Jan 2025 19:38:22 +1100 Subject: [PATCH 2/3] Update builder.md --- documentation/src/crates/revm/builder.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/documentation/src/crates/revm/builder.md b/documentation/src/crates/revm/builder.md index cd9888bd40..4600256fba 100644 --- a/documentation/src/crates/revm/builder.md +++ b/documentation/src/crates/revm/builder.md @@ -5,11 +5,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`. @@ -157,7 +157,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. From 4dfd39dfe3f70710d4c2dc93e63724527cefa141 Mon Sep 17 00:00:00 2001 From: Savely <136869149+savvar9991@users.noreply.github.com> Date: Wed, 1 Jan 2025 19:48:34 +1100 Subject: [PATCH 3/3] Update kzg.md --- documentation/src/crates/primitives/kzg.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/src/crates/primitives/kzg.md b/documentation/src/crates/primitives/kzg.md index 44ba715722..a9d6468597 100644 --- a/documentation/src/crates/primitives/kzg.md +++ b/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;