Monorepo: Apply suggestions from code review

Co-authored-by: Gabriel Rocheleau <contact@rockwaterweb.com> Co-authored-by: acolytec3 <17355484+acolytec3@users.noreply.github.com>
ethereumjs · Jun 30, 2022 · 5d37247 · 5d37247
1 parent af9d371
commit 5d37247
Show file tree

Hide file tree

Showing 7 changed files with 12 additions and 13 deletions.
diff --git a/packages/blockchain/CHANGELOG.md b/packages/blockchain/CHANGELOG.md
@@ -94,7 +94,7 @@ The file structure of the package has been reworked and aligned with other libra
 
 The internal Level DB code has been reworked to now be based and work with the latest Level [v8.0.0](https://github.com/Level/level/releases/tag/v8.0.0) major Level DB release, see PR [#1949](https://github.com/ethereumjs/ethereumjs-monorepo/pull/1949). This allows to use ES6-style `import` syntax to import the `Level` instance and allows for better typing when working with Level DB.
 
-Because the usage of `level` and `memory-level` there are now 3 different possible instances of `abstract-level`, all with a consistent interface due to `abstract-level`. These instances are `classic-level`, `browser-level` and `memory-level`. This now makes it a lot easier to use the package in browsers without polyfills for `level`. For some context it is worth to mention that the `level` package itself is starting with the v8 release just a proxy for these other packages and has no functionality itself.
+Because the usage of `level` and `memory-level` there are now 3 different possible instances of `abstract-level`, all with a consistent interface due to `abstract-level`. These instances are `classic-level`, `browser-level` and `memory-level`. This now makes it a lot easier to use the package in browsers without polyfills for `level`. For some context it is worth to mention that starting with the v8 release, the `level` package is just a proxy for these other packages and has no functionality itself.
 
 ## 5.5.2 - 2022-03-15
 

diff --git a/packages/devp2p/CHANGELOG.md b/packages/devp2p/CHANGELOG.md
@@ -40,7 +40,7 @@ Along with the breaking releases we have therefore deactivated both of these opt
 
 - Removed Node.js specific `assert` usage, PR [#1924](https://github.com/ethereumjs/ethereumjs-monorepo/pull/1924)
 - Deduplicated `keccak` and `secp256k1` library usage in favor of `ethereum-cryptography`, Noble crypto library uses, PR [#1947](https://github.com/ethereumjs/ethereumjs-monorepo/pull/1947)
-- Replaced `hi-base32` dependency with `@scure/base` from @paulmillr (Noble crypto library author), PR [#1947](https://github.com/ethereumjs/ethereumjs-monorepo/pull/1947)
+- Replaced `hi-base32` dependency with `@scure/base` from [@paulmillr](https://github.com/paulmillr) (Noble crypto library author), PR [#1947](https://github.com/ethereumjs/ethereumjs-monorepo/pull/1947)
 
 ## 4.2.2 - 2022-04-29
 

diff --git a/packages/ethash/CHANGELOG.md b/packages/ethash/CHANGELOG.md
@@ -40,7 +40,7 @@ Along with the breaking releases we have therefore deactivated both of these opt
 
 The internal Level DB code has been reworked to now be based and work with the latest Level [v8.0.0](https://github.com/Level/level/releases/tag/v8.0.0) major Level DB release, see PR [#1949](https://github.com/ethereumjs/ethereumjs-monorepo/pull/1949). This allows to use ES6-style `import` syntax to import the `Level` instance and allows for better typing when working with Level DB.
 
-Because the usage of `level` and `memory-level` there are now 3 different possible instances of `abstract-level`, all with a consistent interface due to `abstract-level`. These instances are `classic-level`, `browser-level` and `memory-level`. This now makes it a lot easier to use the package in browsers without polyfills for `level`. For some context it is worth to mention that the `level` package itself is starting with the v8 release just a proxy for these other packages and has no functionality itself.
+Because of the upgrade, any `level` implementation compliant with the `abstract-level` interface can be use, including `classic-level`, `browser-level` and `memory-level`. This now makes it a lot easier to use the package in browsers without polyfills for `level`. For some context it is worth to mention that the `level` package itself is starting with the v8 release just a proxy for these other packages and has no functionality itself.
 
 ## 1.1.0 - 2021-09-24
 

diff --git a/packages/evm/CHANGELOG.md b/packages/evm/CHANGELOG.md
@@ -30,15 +30,15 @@ npm i @ethereumjs/evm
 
 The new EVM package extracts the bytecode execution logic and leaves the handling of the outer environment like setting up some pre-state, processing txs and blocks, generating receipts and paying miners (on a PoW chain) to the outer package.
 
-This makes up for a cleaner separation of concerns, generally the new packages comes a lot closer to being a pure bytecode execution Ethereum Virtual Machine (EVM) implementation than before and will allow for new ways of both customizing and adopting the inner EVM as well as providing an alternative environmental context and customize on the outer processing by adopting the outer VM package.
+This makes for a cleaner separation of concerns and generally brings the the new packages a lot closer to being a pure bytecode execution Ethereum Virtual Machine (EVM) implementation than before.  This will allow for new ways of both customizing and adopting the inner EVM as well as providing an alternative environmental context and customize on the outer processing used in the outer VM package.
 
 ### EVM, EEI and State
 
 The EVM now provides interfaces for the `EVM` itself and for the `EEI`, the environmental interface which allows for the EVM to request external data like a blockhash for the respective `BLOCKHASH` opcode. The EEI is intended as "bridge" between the EVM, the VM, and the StateManager. It is now possible to import a new EVM and EEI into the VM, as long as these implement the provided interfaces. 
 
 Almost all environment related variables are extracted from EEI and are now in EVM. The environment provides information to the EVM about the code, the remaining gas left, etc. The only environment-related variables left in EEI are the warmed addresses and storage slots, and also keeps track of which accounts are touched (to cleanup later if these are "empty" after running a transaction).
 
-The EEI is created once, not each time when a transaction is ran in the VM, VM access to `StateManager` is now all done using the EEI.
+The EEI is created once, not each time when a transaction is ran in the VM. The VM's access to the `StateManager` is now all done through the EEI.
 
 Internally, in the EVM, the `Env` environment variable is used to track any variables which do not change during a call frame, for instance the `code`, the `caller`, etc. The `RunState` is used to track anything which can change during the execution, such as the remaining gas, the selfdestruct lists, the stack, the program counter, etc.
 
@@ -74,7 +74,7 @@ This comes with a substantial increase in overall EVM performance, we will provi
 
 ### EIP-3074 Authcall Support
 
-The EVM now comes with experimental support for [EIP-3074](https://eips.ethereum.org/EIPS/eip-3074) introducing two new opcodes `Auth` and `Authcall` to allow externally owned accounts to delegate control to a contract, see PRs [#1788](https://github.com/ethereumjs/ethereumjs-monorepo/pull/1788) and [#1867]([#1788](https://github.com/ethereumjs/ethereumjs-monorepo/pull/1788)).
+The EVM now comes with experimental support for [EIP-3074](https://eips.ethereum.org/EIPS/eip-3074) introducing two new opcodes `Auth` and `Authcall` to allow externally owned accounts to delegate control to a contract, see PRs [#1788](https://github.com/ethereumjs/ethereumjs-monorepo/pull/1788) and [#1867](https://github.com/ethereumjs/ethereumjs-monorepo/pull/1867).
 
 ### Disabled esModuleInterop and allowSyntheticDefaultImports TypeScript Compiler Options
 
@@ -87,7 +87,7 @@ Along with the breaking releases we have therefore deactivated both of these opt
 ### Other Changes
 
 - The EVM is now fully typed. Before, the `AsyncEventEmitter` did not have an interface, therefore TypeScript internally casts it as `any`. It also provides types for the available events
-- TransientStorage is now part of EVM and not of EEI
+- TransientStorage (EIP-1153) is now part of EVM and not of EEI
 - Renamed `gasUsed` to `executionGasUsed` as part of `ExecResult`
 
 ## 5.9.1 - 2022-06-02

diff --git a/packages/statemanager/CHANGELOG.md b/packages/statemanager/CHANGELOG.md
@@ -28,7 +28,7 @@ npm i @ethereumjs/statemanager
 
 The `@ethereumjs/vm` package still has this package added as a dependency and it is automatically integrated. The `StateManager` provides a high-level interface to an underlying state storage solution. This is classically a `Trie` (in our case: an `@ethereumjs/trie`) instance, but can also be something else, e.g. a plain database, an underlying RPC connection or a Verkle Tree in the future.
 
-The extraction of this module allows to easier customize a `StateManager` and provide or use own implementations in the future. It now also gets possible to use the `StateManager` standalone for high-level state access in a non-VM context.
+The extraction of this module allows to easier customize a `StateManager` and provide or use your own implementations in the future. It is now also possible to use the `StateManager` standalone for high-level state access in a non-VM context.
 
 A `StateManager` must adhere to a predefined interface `StateManager` and implement a certain set of state access methods like `getAccount()`, `putContractCode()`,... Such an implementation is then guaranteed to work e.g. in the `@ethereumjs/vm` implementation.
 
@@ -55,9 +55,9 @@ Other Changes:
 
 - New partial parent interface `StateAccess` with just the access focused functionality
 
-So overall the `StateManager` interface got a lot leaner requesting fewer methods to be implemented which should make an implementation and/or adoption a lot easier.
+So overall the `StateManager` interface got a lot leaner requiring fewer methods to be implemented which should make an implementation and/or adoption a lot easier.
 
-The `StateManager` package ships with a Trie-based `StateManager` implementation extending from a `BaseStateManager` which might be a suitable starting point for own implementations. This will very much depend on the specific needs though.
+The `StateManager` package ships with a Trie-based `StateManager` implementation extending from a `BaseStateManager` which might be a suitable starting point for your own implementations. This will very much depend on the specific needs though.
 
 ### BigInt Introduction / ES2020 Build Target
 

diff --git a/packages/trie/CHANGELOG.md b/packages/trie/CHANGELOG.md
@@ -75,7 +75,7 @@ If no `db` option is provided an in-memory [memory-level](https://github.com/Lev
 
 Along with the DB interface extraction the internal Level DB code has been reworked to now be based and work with the latest Level [v8.0.0](https://github.com/Level/level/releases/tag/v8.0.0) major Level DB release. This allows to use ES6-style `import` syntax to import the `Level` instance and allows for better typing when working with Level DB.
 
-Because the usage of `level` and `memory-level` there are now 3 different possible instances of `abstract-level`, all with a consistent interface due to `abstract-level`. These instances are `classic-level`, `browser-level` and `memory-level`. This now makes it a lot easier to use the package in browsers without polyfills for `level`. For some context it is worth to mention that the `level` package itself is starting with the v8 release just a proxy for these other packages and has no functionality itself.
+Because of the upgrade, any `level` implementation compliant with the `abstract-level` interface can be use, including `classic-level`, `browser-level` and `memory-level`. This now makes it a lot easier to use the package in browsers without polyfills for `level`. For some context it is worth to mention that the `level` package itself is starting with the v8 release just a proxy for these other packages and has no functionality itself.
 
 ### API Changes
 

diff --git a/packages/vm/CHANGELOG.md b/packages/vm/CHANGELOG.md
@@ -26,7 +26,6 @@ The EVM package extracts the inner core, the Ethereum Virtual Machine (EVM) resp
 
 The StateManager extracts the high-level state access interface, see PR [#1817](https://github.com/ethereumjs/ethereumjs-monorepo/pull/1817). Both can now directly be passed in to the `VM` package along instantiation or are otherwise instantiated as default versions with default values being set.
 
-
 The EVM related options now moved over to the EVM package directly, namely:
 
 - `allowUnlimitedContractSize`
@@ -38,7 +37,7 @@ Both the `runCall()` and `runCode()` API methods also moved over to the `evm` pa
 - `vm.evm.runCall()`
 - `vm.evm.runCode()`
 
-The VM provides an implementation for the `EEI` interface from the `EVM` package which can be used by the EVM to request environmental data for bytecode processing. It is now also possible to provide a custom EEI by a respective constructor option.
+The VM provides an implementation for the `EEI` interface from the `EVM` package which can be used by the EVM to request environmental data for bytecode processing. It is now also possible to provide a custom EEI by a corresponding constructor option.
 
 ### London Hardfork Default