Releases: ethereumjs/ethereumjs-monorepo
@ethereumjs/evm v10.0.0-rc.1
This is the first (and likely the last) round of RC releases for the upcoming breaking releases, following the alpha releases from October 2024 (see alpha release release notes for full/main change description). The releases are somewhat delayed (sorry for that), but final releases can now be expected very very soon, to be released once the Ethereum Pectra hardfork is scheduled for mainnet and all EIPs are fully finalized. Pectra will then also be the default hardfork setting for all EthereumJS libraries.
New Versioning Scheme
This breaking release round will come with a new versioning scheme (thanks to paulmillr for the suggestion), aligning the package numbers on breaking releases for all EthereumJS packages. This will make it easier to report bugs ("bug happened on EthereumJS version 10 releases"), reason about release series and make library compatibility more transparent and easier to grasp.
As a start we bump all major release versions to version 10, these RC releases are the first to be released with the new versioning scheme.
Native Node.js EventEmitter Replacement
We removed the last remaining internal Node.js utility dependency to make the packages more browser friendly and replace the native Node.js EventEmitter by using the eventemitter3 package as a replacement, see PR #3746.
The new package is meant to be more performant while remaining almost entirely API compatible with native Node.js event emitters.
If you directly import the Node.js event emitter, you need to switch your imports to:
import { EventEmitter } from 'events' // old
import { EventEmitter } from 'eventemitter3' // newThe new event emitter package also made it possible to remove/replace the separate async event emitter custom integration and use the new package here as well.
For listening to async EVM events like step or VM events like newContract or afterTx API slightly changed and it is now needed to take the resolve parameter in on listening and explicitly call at the end of the event handling:
evm.events.on('beforeMessage', (event) => {
console.log('synchronous listener to beforeMessage', event)
})
evm.events.on('afterMessage', (event, resolve) => {
console.log('asynchronous listener to beforeMessage', event)
// we need to call resolve() to avoid the event listener hanging
resolve?.()
})EthereumJS-wide Error Objects
We have done preparations to allow for handling specific error sub types in the future by introducing a monorepo-wide EthereumJSError error class in the @ethereumjs/util package, see PR #3879. This error is thrown for all error cases within the monorepo and can be specifically handled by comparing with instanceof EthereumJSError.
We will introduce a set of more specific sub error classes inheriting from this generic type in upcoming minor releases, and so keeping things fully backwards compatible. This will allow for a more specific and robust handling of errors thrown by EthereumJS libraries.
Verkle Updates (experimental)
- New method to generate a verkle execution witness, PR #3864
- Migrate verkle
AccessWitnessfrom StateManager to EVM (experimental), PR #3770 - Simplify/rename verkle access witness methods, PR #3830
- Verkle updates, PR #3832
Other Changes
@ethereumjs/ethash v10.0.0-rc.1
This is the first (and likely the last) round of RC releases for the upcoming breaking releases, following the alpha releases from October 2024 (see alpha release release notes for full/main change description). The releases are somewhat delayed (sorry for that), but final releases can now be expected very very soon, to be released once the Ethereum Pectra hardfork is scheduled for mainnet and all EIPs are fully finalized. Pectra will then also be the default hardfork setting for all EthereumJS libraries.
New Versioning Scheme
This breaking release round will come with a new versioning scheme (thanks to paulmillr for the suggestion), aligning the package numbers on breaking releases for all EthereumJS packages. This will make it easier to report bugs ("bug happened on EthereumJS version 10 releases"), reason about release series and make library compatibility more transparent and easier to grasp.
As a start we bump all major release versions to version 10, these RC releases are the first to be released with the new versioning scheme.
EthereumJS-wide Error Objects
We have done preparations to allow for handling specific error sub types in the future by introducing a monorepo-wide EthereumJSError error class in the @ethereumjs/util package, see PR #3879. This error is thrown for all error cases within the monorepo and can be specifically handled by comparing with instanceof EthereumJSError.
We will introduce a set of more specific sub error classes inheriting from this generic type in upcoming minor releases, and so keeping things fully backwards compatible. This will allow for a more specific and robust handling of errors thrown by EthereumJS libraries.
@ethereumjs/era v10.0.0-dev-rc.1
Initial development release
Features:
- Export history data as Era1
- Read Era1 files which store pre-merge execution layer block history in 8192 block increments (i.e. eras)
- Read Era files which store SSZ encoded signed beacon blocks by era (8192 blocks)
Note: This library is still experimental and the API might change along minor release versions!
@ethereumjs/devp2p v10.0.0-rc.1
This is the first (and likely the last) round of RC releases for the upcoming breaking releases, following the alpha releases from October 2024 (see alpha release release notes for full/main change description). The releases are somewhat delayed (sorry for that), but final releases can now be expected very very soon, to be released once the Ethereum Pectra hardfork is scheduled for mainnet and all EIPs are fully finalized. Pectra will then also be the default hardfork setting for all EthereumJS libraries.
New Versioning Scheme
This breaking release round will come with a new versioning scheme (thanks to paulmillr for the suggestion), aligning the package numbers on breaking releases for all EthereumJS packages. This will make it easier to report bugs ("bug happened on EthereumJS version 10 releases"), reason about release series and make library compatibility more transparent and easier to grasp.
As a start we bump all major release versions to version 10, these RC releases are the first to be released with the new versioning scheme.
Native Node.js EventEmitter Replacement
We removed the last remaining internal Node.js utility dependency to make the packages more browser friendly and replace the native Node.js EventEmitter by using the eventemitter3 package as a replacement, see PR #3746.
The new package is meant to be more performant while remaining almost entirely API compatible with native Node.js event emitters.
If you directly import the Node.js event emitter, you need to switch your imports to:
import { EventEmitter } from 'events' // old
import { EventEmitter } from 'eventemitter3' // newEthereumJS-wide Error Objects
We have done preparations to allow for handling specific error sub types in the future by introducing a monorepo-wide EthereumJSError error class in the @ethereumjs/util package, see PR #3879. This error is thrown for all error cases within the monorepo and can be specifically handled by comparing with instanceof EthereumJSError.
We will introduce a set of more specific sub error classes inheriting from this generic type in upcoming minor releases, and so keeping things fully backwards compatible. This will allow for a more specific and robust handling of errors thrown by EthereumJS libraries.
Other Changes
@ethereumjs/common v10.0.0-rc.1
This is the first (and likely the last) round of RC releases for the upcoming breaking releases, following the alpha releases from October 2024. The releases are somewhat delayed (sorry for that), but final releases can now be expected very very soon, to be released once the Ethereum Pectra hardfork is scheduled for mainnet and all EIPs are fully finalized. Pectra will then also be the default hardfork setting for all EthereumJS libraries.
New Versioning Scheme
This breaking release round will come with a new versioning scheme (thanks to paulmillr for the suggestion), aligning the package numbers on breaking releases for all EthereumJS packages. This will make it easier to report bugs ("bug happened on EthereumJS version 10 releases"), reason about release series and make library compatibility more transparent and easier to grasp.
As a start we bump all major release versions to version 10, these RC releases are the first to be released with the new versioning scheme.
Native Node.js EventEmitter Replacement
We removed the last remaining internal Node.js utility dependency to make the packages more browser friendly and replace the native Node.js EventEmitter by using the eventemitter3 package as a replacement, see PR #3746.
The new package is meant to be more performant while remaining almost entirely API compatible with native Node.js event emitters.
If you directly import the Node.js event emitter, you need to switch your imports to:
import { EventEmitter } from 'events' // old
import { EventEmitter } from 'eventemitter3' // newAll this might affect you if you listen to events emitted by the common.events EventEmitter instance, e.g. to detect hardfork changes.
Pectra Spec Updates
- Support for generalized EL requests coming with EIP-7685 introduction (devnet-4), PR #3706
- Add
requestsHashto genesis block/configuration, PR #3771 - Allow specifying eip-7840 blobSchedule via geth genesis, PR #3835
EthereumJS-wide Error Objects
We have done preparations to allow for handling specific error sub types in the future by introducing a monorepo-wide EthereumJSError error class in the @ethereumjs/util package, see PR #3879. This error is thrown for all error cases within the monorepo and can be specifically handled by comparing with instanceof EthereumJSError.
We will introduce a set of more specific sub error classes inheriting from this generic type in upcoming minor releases, and so keeping things fully backwards compatible. This will allow for a more specific and robust handling of errors thrown by EthereumJS libraries.
Other Changes
@ethereumjs/blockchain v10.0.0-rc.1
This is the first (and likely the last) round of RC releases for the upcoming breaking releases, following the alpha releases from October 2024 (see alpha release release notes for full/main change description). The releases are somewhat delayed (sorry for that), but final releases can now be expected very very soon, to be released once the Ethereum Pectra hardfork is scheduled for mainnet and all EIPs are fully finalized. Pectra will then also be the default hardfork setting for all EthereumJS libraries.
New Versioning Scheme
This breaking release round will come with a new versioning scheme (thanks to paulmillr for the suggestion), aligning the package numbers on breaking releases for all EthereumJS packages. This will make it easier to report bugs ("bug happened on EthereumJS version 10 releases"), reason about release series and make library compatibility more transparent and easier to grasp.
As a start we bump all major release versions to version 10, these RC releases are the first to be released with the new versioning scheme.
Native Node.js EventEmitter Replacement
We removed the last remaining internal Node.js utility dependency to make the packages more browser friendly and replace the native Node.js EventEmitter by using the eventemitter3 package as a replacement, see PR #3746.
The new package is meant to be more performant while remaining almost entirely API compatible with native Node.js event emitters.
If you directly import the Node.js event emitter, you need to switch your imports to:
import { EventEmitter } from 'events' // old
import { EventEmitter } from 'eventemitter3' // newAll this might affect you if you listen to events emitted by the blockchain.events EventEmitter instance.
Pectra Spec Updates
- Support for generalized EL requests coming with EIP-7685 introduction (devnet-4), PR #3706
- Add
requestsHashto genesis block/configuration, PR #3771
EthereumJS-wide Error Objects
We have done preparations to allow for handling specific error sub types in the future by introducing a monorepo-wide EthereumJSError error class in the @ethereumjs/util package, see PR #3879. This error is thrown for all error cases within the monorepo and can be specifically handled by comparing with instanceof EthereumJSError.
We will introduce a set of more specific sub error classes inheriting from this generic type in upcoming minor releases, and so keeping things fully backwards compatible. This will allow for a more specific and robust handling of errors thrown by EthereumJS libraries.
@ethereumjs/block v10.0.0-rc.1
This is the first (and likely the last) round of RC releases for the upcoming breaking releases, following the alpha releases from October 2024 (see alpha release release notes for full/main change description). The releases are somewhat delayed (sorry for that), but final releases can now be expected very very soon, to be released once the Ethereum Pectra hardfork is scheduled for mainnet and all EIPs are fully finalized. Pectra will then also be the default hardfork setting for all EthereumJS libraries.
New Versioning Scheme
This breaking release round will come with a new versioning scheme (thanks to paulmillr for the suggestion), aligning the package numbers on breaking releases for all EthereumJS packages. This will make it easier to report bugs ("bug happened on EthereumJS version 10 releases"), reason about release series and make library compatibility more transparent and easier to grasp.
As a start we bump all major release versions to version 10, these RC releases are the first to be released with the new versioning scheme.
Pectra Spec Updates
- Support for EIP-7691 Blob Throughput Increase, PR #3807
- Support for generalized EL requests coming with EIP-7685 introduction (devnet-4), PR #3706
- Fix the param resolution for excess gas and blob fee compute, PR #3841
EthereumJS-wide Error Objects
We have done preparations to allow for handling specific error sub types in the future by introducing a monorepo-wide EthereumJSError error class in the @ethereumjs/util package, see PR #3879. This error is thrown for all error cases within the monorepo and can be specifically handled by comparing with instanceof EthereumJSError.
We will introduce a set of more specific sub error classes inheriting from this generic type in upcoming minor releases, and so keeping things fully backwards compatible. This will allow for a more specific and robust handling of errors thrown by EthereumJS libraries.
@ethereumjs/binarytree v10.0.0-dev-rc.1
This is the first (and likely the last) round of RC releases for the upcoming breaking releases, following the alpha releases from October 2024 (see alpha release release notes for full/main change description). The releases are somewhat delayed (sorry for that), but final releases can now be expected very very soon, to be released once the Ethereum Pectra hardfork is scheduled for mainnet and all EIPs are fully finalized. Pectra will then also be the default hardfork setting for all EthereumJS libraries.
New Versioning Scheme
This breaking release round will come with a new versioning scheme (thanks to paulmillr for the suggestion), aligning the package numbers on breaking releases for all EthereumJS packages. This will make it easier to report bugs ("bug happened on EthereumJS version 10 releases"), reason about release series and make library compatibility more transparent and easier to grasp.
As a start we bump all major release versions to version 10, these RC releases are the first to be released with the new versioning scheme.
Note: This is the initial developer release of a binary tree package. While we also directly bump the binarytree package version for consistency reasons please be aware that this package is still in a very early stage and not production ready!
@ethereumjs/wallet v3.0.0-alpha.1
@ethereumjs/vm v9.0.0-alpha.1
This is a first round of alpha releases for our upcoming breaking release round with a focus on bundle size (tree shaking) and security (dependencies down + no WASM (by default)). Note that alpha releases are not meant to be fully API-stable yet and are for early testing only. This release series will be then followed by a beta release round where APIs are expected to be mostly stable. Final releases can then be expected for late October/early November 2024.
Renamings
Static Constructors
The static constructors for our library classes have been reworked to now be standalone methods (with a similar naming scheme). This allows for better tree shaking of unused constructor code (see PR #3618):
VM.create()->createVM
Core Procedural Methods
See: PR #3530
VM.runTx()->runTx()VM.runBlock()->runBlock()VM.buildBlock()->buildBlock()
Own VM Parameter Set
HF-sensitive parameters like historyStorageAddress were previously by design all provided by the @ethereumjs/common library. This meant that all parameter sets were shared among the libraries and libraries carried around a lot of unnecessary parameters.
With the Common refactoring from PR #3537 parameters now moved over to a dedicated params.ts file (exposed as e.g. paramsVM) within the parameter-using library and the library sets its own parameter set by internally calling a new Common method updateParams(). For shared Common instances parameter sets then accumulate as needed.
Beside having a lighter footprint this additionally allows for easier parameter customization. There is a new params constructor option which leverages this new possibility and where it becomes possible to provide a fully customized set of core library parameters.
New Common API
There is a new Common API for simplification and better tree shaking, see PR #3545. Change your Common initializations as follows (see Common release for more details):
// old
import { Chain, Common } from '@ethereumjs/common'
const common = new Common({ chain: Chain.Mainnet })
// new
import { Common, Mainnet } from '@ethereumjs/common'
const common = new Common({ chain: Mainnet })Pure JavaScript EVM (no default WASM)
This is the first EthereumJS VM release where we could realize a fully WASM-free version of the underlying EVM by default! 🤩 We were finally able to replace all crypto primitives which still relied on Web Assembly code with pure JavaScript/TypeScript pendants, thanks a lot to @paulmillr from Noble for the cooperation on this! ❤️
Together with a strong dependency reduction being accomplished along this release this opens up for new use cases for the JavaScript VM/EVM in more security sensitive contexts. The code of the EVM is now compact enough that it gets fully auditable (and we plan an EVM audit for 2025), see e.g. here for an EVM bundle snapshot including all dependencies!
See EVM release notes for a detailed breakdown of the changes!
Mega-EOF Support (experimental)
The underlying EVM now supports Mega-EOF in an experimental form! 🎉 See EVM release notes for more details.
EIP-7702 EOA Account Abstraction Support (experimental)
The VM now experimentally supports running EIP-7702 txs with runTx() (or runBlock()) and along transform an EOA into a smart contract for the period of one transaction and execute the respective bytecode, see PRs #3470, #3577 and #3581.
The following is an example on how to create an EIP-7702 tx (note that you need to replace the authorizationList parameters with real-world tx and signature values):
import { Common, Hardfork, Mainnet } from '@ethereumjs/common'
import { createEOACode7702Tx } from '@ethereumjs/tx'
import { type PrefixedHexString, createAddressFromPrivateKey, randomBytes } from '@ethereumjs/util'
const ones32 = `0x${'01'.repeat(32)}` as PrefixedHexString
const common = new Common({ chain: Mainnet, hardfork: Hardfork.Cancun, eips: [7702] })
const tx = createEOACode7702Tx(
{
authorizationList: [
{
chainId: '0x2',
address: `0x${'20'.repeat(20)}`,
nonce: '0x1',
yParity: '0x1',
r: ones32,
s: ones32,
},
],
to: createAddressFromPrivateKey(randomBytes(32)),
},
{ common },
)Removal of TTD Logic (live-Merge Transition Support)
Total terminal difficulty (TTD) logic related to fork switching has been removed from the libraries, see PRs #3518 and #3556. This means that a Merge-type live hardfork transition solely triggered by TTD is not supported anymore. It is still possible though to replay and deal with both pre- and post Merge HF blocks.
For this library this means:
- The
setHardforkoption forrunBlock()is simplified to only accept abooleanand noBigIntLikefor an eventual TD value anymore
Other Breaking Changes
- New default hardfork:
Shanghai->Cancun, see PR #3566 - VM is now by default initialized without state manager caches (tree shaking), PR #3601
- VM uses
EVMMockBlockchainas blockchain default (tree shaking), PR #3601
Other Changes
- Upgrade to TypeScript 5, PR #3607
- Node 22 support, PR #3669
- Implement
t8ntoolto use forexecution-spec-tests, PR #3603 - Upgrade
ethereum-cryptographyto v3, PR #3668 - Exit early on non-existing system contracts, PR #3614
- Add
allowNoBlobsoption toBlockBuilder.addTransaction(), PR #3603 - Exit early in
runBlock()if system contract has no code, PR #3603