All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog (modification: no type change headlines) and this project adheres to Semantic Versioning.
- Upgrade to TypeScript 5, PR #3607
- Node 22 support, PR #3669
- Upgrade
ethereum-cryptographyto v3, PR #3668
Maintenance release with downstream dependency updates, see PR #3527
Maintenance release with downstream dependency updates, see PR #3297
Maintenance release with dependency updates, see PR #3261
- Performance: Cache often used BigInt constants, PR #3050
Final release version from the breaking release round from Summer 2023 on the EthereumJS libraries, thanks to the whole team for this amazing accomplishment! ❤️ 🥳
See RC1 release notes for the main change description.
This is the release candidate (RC1) for the upcoming breaking releases on the various EthereumJS libraries. The associated release notes below are the main source of information on the changeset, also for the upcoming final releases, where we'll just provide change addition summaries + references to these RC1 notes.
At time of the RC1 releases there is/was no plan for a second RC round and breaking releases following relatively shorty (2-3 weeks) after the RC1 round. Things may change though depending on the feedback we'll receive.
This round of breaking releases brings the EthereumJS libraries to the browser. Finally! 🤩
While you could use our libraries in the browser libraries before, there had been caveats.
WE HAVE ELIMINATED ALL OF THEM.
The largest two undertakings: First: we have rewritten all (half) of our API and eliminated the usage of Node.js specific Buffer all over the place and have rewritten with using Uint8Array byte objects. Second: we went through our whole stack, rewrote imports and exports, replaced and updated dependencies all over and are now able to provide a hybrid CommonJS/ESM build, for all libraries. Both of these things are huge.
Together with some few other modifications this now allows to run each (maybe adding an asterisk for client and devp2p) of our libraries directly in the browser - more or less without any modifications - see the examples/browser.html file in each package folder for an easy to set up example.
This is generally a big thing for Ethereum cause this brings the full Ethereum Execution Layer (EL) protocol stack to the browser in an easy accessible way for developers, for the first time ever! 🎉
This will allow for easy-to-setup browser applications both around the existing as well as the upcoming Ethereum EL protocol stack in the future. 🏄🏾♂️ We are beyond excitement to see what you guys will be building with this for "Browser-Ethereum". 🤓
Browser is not the only thing though why this release round is exciting: default Shanghai hardfork, full Cancun support, significantly smaller bundle sizes for various libraries, new database abstractions, a simpler to use EVM, API clean-ups throughout the whole stack. These are just the most prominent additional things here to mention which will make the developer heart beat a bit faster hopefully when you are scanning to the vast release notes for every of the 15 (!) releases! 🧑🏽💻
So: jump right in and enjoy. We can't wait to hear your feedback and see if you agree that these releases are as good as we think they are. 🙂 ❤️
The EthereumJS Team
We now provide both a CommonJS and an ESM build for all our libraries. 🥳 This transition was a huge undertaking and should make the usage of our libraries in the browser a lot more straight-forward, see PR #2685, #2783, #2786, #2764, #2804 and #2809 (and others). We rewrote the whole set of imports and exports within the libraries, updated or completely removed a lot of dependencies along the way and removed the usage of all native Node.js primitives (like https or util).
There are now two different build directories in our dist folder, being dist/cjs for the CommonJS and dist/esm for the ESM build. That means that direct imports (which you generally should try to avoid, rather open an issue on your import needs), need an update within your code (do a dist or the like code search).
Both builds have respective separate entrypoints in the distributed package.json file.
A CommonJS import of our libraries can then be done like this:
const { Chain, Common } = require('@ethereumjs/common')
const common = new Common({ chain: Chain.Mainnet })And this is how an ESM import looks like:
import { Chain, Common } from '@ethereumjs/common'
const common = new Common({ chain: Chain.Mainnet })Using ESM will give you additional advantages over CJS beyond browser usage like static code analysis / Tree Shaking which CJS can not provide.
Side note: along this transition we also rewrote our whole test suite (yes!!!) to now work with Vitest instead of Tape.
With these releases we remove all Node.js specific Buffer usages from our libraries and replace these with Uint8Array representations, which are available both in Node.js and the browser (Buffer is a subclass of Uint8Array). While this is a big step towards interoperability and browser compatibility of our libraries, this is also one of the most invasive operations we have ever done, see the huge changeset from PR #2566 and #2607. 😋
We nevertheless think this is very much worth it and we tried to make transition work as easy as possible.
For this library you should check if you use one of the following constructors, methods, constants or types and do a search and update input and/or output values or general usages and add conversion methods if necessary:
Ethash.mkcache(cacheSize: number, seed: Uint8Array)
Ethash.calcDatasetItem(i: number): Uint8Array
Ethash.run(val: Uint8Array, nonce: Uint8Array, fullSize?: number)
Ethash.cacheHash()
Ethash.headerHash(rawHeader: Uint8Array[])
Ethash.getMiner()
Ethash.verifyPOW(block: Block)We have converted existing Buffer conversion methods to Uint8Array conversion methods in the @ethereumjs/util bytes module, see the respective README section for guidance.
The mixed usage of prefixed and unprefixed hex strings is a constant source of errors in byte-handling code bases.
We have therefore decided to go "prefixed" by default, see PR #2830 and #2845.
The hexToBytes and bytesToHex methods, also similar methods like intToHex, now take 0x-prefixed hex strings as input and output prefixed strings. The corresponding unprefixed methods are marked as deprecated and usage should be avoided.
Please therefore check you code base on updating and ensure that values you are passing to constructors and methods are prefixed with a 0x.
- Support for
Node.js 16has been removed (minimal version:Node.js 18), PR #2859 - Breaking: Changes in the database layer usage, PR #2669
- Fix handling of nested uint8Arrays in JSON in DB, PR #2666
- Update ethereum-cryptography from 1.2 to 2.0 (switch from noble-secp256k1 to noble-curves), PR #2641
- Bump
@ethereumjs/util@chainsafe/sszdependency to 0.11.1 (no WASM, native SHA-256 implementation, ES2019 compatible, explicit imports), PRs #2622, #2564 and #2656
- Pinned
@ethereumjs/util@chainsafe/sszdependency tov0.9.4due to ES2021 features used inv0.10.+causing compatibility issues, PR #2555 - Fixed
kzgimports in@ethereumjs/tx, PR #2552
DEPRECATED: Release is deprecated due to broken dependencies, please update to the subsequent bugfix release version.
Maintenance release with dependency updates, PR #2521
Maintenance release with dependency updates, PR #2445
- Updated
@ethereumjs/blockdependency version tov4.0.1
Final release - tada 🎉 - of a wider breaking release round on the EthereumJS monorepo libraries, see the Beta 1 release notes for the main long change set description as well as the Beta 2, Beta 3 and Release Candidate (RC) 1 release notes for notes on some additional changes (CHANGELOG).
- Internal refactor: removed ambiguous boolean checks within conditional clauses, PR #2253
Release candidate 1 for the upcoming breaking release round on the EthereumJS monorepo libraries, see the Beta 1 release notes for the main long change set description as well as the Beta 2 and 3 release notes for notes on some additional changes (CHANGELOG).
- Added
enginefield topackage.jsonlimiting Node versions to v14 or higher, PR #2164 - Replaced
nyc(code coverage) configurations withc8configurations, PR #2192 - Code formats improvements by adding various new linting rules, see Issue #1935
Beta 3 release for the upcoming breaking release round on the EthereumJS monorepo libraries, see the Beta 1 release notes for the main long change set description as well as the Beta 2 release notes for notes on some additional changes (CHANGELOG).
Since the Merge HF is getting close we have decided to directly jump on the Merge HF (before: Istanbul) as default in the underlying @ethereumjs/common library and skip the London default HF as we initially intended to set (see Beta 1 CHANGELOG), see PR #2087.
This change should not directly affect this library but might be relevant since it is not recommended to use different Common library versions between the different EthereumJS libraries.
Beta 2 release for the upcoming breaking release round on the EthereumJS monorepo libraries, see the Beta 1 release notes (CHANGELOG) for the main change set description.
The change with the biggest effect on UX since the last Beta 1 releases is for sure that we have removed default exports all across the monorepo, see PR #2018, we even now added a new linting rule that completely disallows using.
Default exports were a common source of error and confusion when using our libraries in a CommonJS context, leading to issues like Issue #978.
Now every import is a named import and we think the long term benefits will very much outweigh the one-time hassle of some import adoptions.
Since our @ethereumjs/common library is used all across our libraries for chain and HF instantiation this will likely be the one being the most prevalent regarding the need for some import updates.
So Common import and usage is changing from:
import Common, { Chain, Hardfork } from '@ethereumjs/common'
const common = new Common({ chain: Chain.Mainnet, hardfork: Hardfork.Merge })to:
import { Common, Chain, Hardfork } from '@ethereumjs/common'
const common = new Common({ chain: Chain.Mainnet, hardfork: Hardfork.Merge })The main Ethash class import has been updated, so import changes from:
import Ethash from '@ethereumjs/ethash'to:
import { Ethash } from '@ethereumjs/ethash'- Added
ESLintstrict boolean expressions linting rule, PR #2030
This release is part of a larger breaking release round where all EthereumJS monorepo libraries (VM, Tx, Trie, other) get major version upgrades. This round of releases has been prepared for a long time and we are really pleased with and proud of the result, thanks to all team members and contributors who worked so hard and made this possible! 🙂 ❤️
We have gotten rid of a lot of technical debt and inconsistencies and removed unused functionality, renamed methods, improved on the API and on TypeScript typing, to name a few of the more local type of refactoring changes. There are also broader structural changes like a full transition to native JavaScript BigInt values as well as various somewhat deep-reaching refactorings, both within a single package as well as some reaching beyond the scope of a single package. Also two completely new packages - @ethereumjs/evm (in addition to the existing @ethereumjs/vm package) and @ethereumjs/statemanager - have been created, leading to a more modular Ethereum JavaScript VM.
We are very much confident that users of the libraries will greatly benefit from the changes being introduced. However - along the upgrade process - these releases require some extra attention and care since the changeset is both so big and deep reaching. We highly recommend to closely read the release notes, we have done our best to create a full picture on the changes with some special emphasis on delicate code and API parts and give some explicit guidance on how to upgrade and where problems might arise!
So, enjoy the releases (this is a first round of Beta releases, with final releases following a couple of weeks after if things go well)! 🎉
The EthereumJS Team
With this round of breaking releases the whole EthereumJS library stack removes the BN.js library and switches to use native JavaScript BigInt values for large-number operations and interactions.
This makes the libraries more secure and robust (no more BN.js v4 vs v5 incompatibilities) and generally comes with substantial performance gains for the large-number-arithmetic-intense parts of the libraries (particularly the VM).
To allow for BigInt support our build target has been updated to ES2020. We feel that some still remaining browser compatibility issues on the edges (old Safari versions e.g.) are justified by the substantial gains this step brings along.
See #1671 and #1771 for the core BigInt transition PRs.
The above TypeScript options provide some semantic sugar like allowing to write an import like import React from "react" instead of import * as React from "react", see esModuleInterop and allowSyntheticDefaultImports docs for some details.
While this is convenient, it deviates from the ESM specification and forces downstream users into using these options, which might not be desirable, see this TypeScript Semver docs section for some more detailed argumentation.
Along with the breaking releases we have therefore deactivated both of these options and you might therefore need to adapt some import statements accordingly. Note that you still can activate these options in your bundle and/or transpilation pipeline (but now you also have the option not to, which you didn't have before).
The internal Level DB code has been reworked to now be based and work with the latest Level v8.0.0 major Level DB release, see PR #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 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.
There is now a new simple CPU miner added to the Ethash package which can be used for testing purposes.
See the following example on how to use the new Miner class:
import { Block } from '@ethereumjs/block'
import Ethash from '@ethereumjs/ethash'
import Common from '@ethereumjs/common'
import { BN } from 'ethereumjs-util'
const level = require('level-mem')
const cacheDB = level()
const block = Block.fromBlockData({
header: {
difficulty: new BN(100),
number: new BN(1),
},
})
const e = new Ethash(cacheDB)
const miner = e.getMiner(block.header)
const solution = await miner.iterate(-1) // iterate until solution is foundSource files from the src folder are now included in the distribution build, see PR #1301. This allows for a better debugging experience in debug tools like Chrome DevTools by having working source map references to the original sources available for inspection.
Attention! This new version is part of a series of EthereumJS releases all moving to a new scoped package name format. In this case the library is renamed as follows:
ethashjs->@ethereumjs/ethash
Please update your library references accordingly or install with:
npm i @ethereumjs/ethashThe Ethash library has been promisified and callbacks have been removed along PR #833 and preceding PR #779.
Old API:
ethash.verifyPOW(validblock, (result) => {
console.log(result)
})New API:
const result = await ethash.verifyPOW(validBlock)
console.log(result) // => trueSee Ethash README for a complete example.
We significantly updated our internal tool and CI setup along the work on PR #913 with an update to ESLint from TSLint for code linting and formatting and the introduction of a new build setup.
Packages now target ES2017 for Node.js builds (the main entrypoint from package.json) and introduce a separate ES5 build distributed along using the browser directive as an entrypoint, see PR #921. This will result in performance benefits for Node.js consumers, see here for a related discussion.
This is the first release candidate towards a final library release, see beta.1 release notes for an overview on the full changes since the last publicly released version.
No changes since beta.1 release.
Attention! This new version is part of a series of EthereumJS releases all moving to a new scoped package name format. In this case the library is renamed as follows:
ethashjs->@ethereumjs/ethash
Please update your library references accordingly or install with:
npm i @ethereumjs/ethashThe Ethash library has been promisified and callbacks have been removed along
PR #833 and preceding PR
#779.
Old API:
ethash.verifyPOW(validblock, (result) => {
console.log(result)
})New API:
const result = await ethash.verifyPOW(validBlock)
console.log(result) // => trueSee Ethash README
for a complete example.
We significantly updated our internal tool and CI setup along the work on
PR #913 with an update to ESLint from TSLint
for code linting and formatting and the introduction of a new build setup.
Packages now target ES2017 for Node.js builds (the main entrypoint from package.json) and introduce
a separate ES5 build distributed along using the browser directive as an entrypoint, see
PR #921. This will result
in performance benefits for Node.js consumers, see here for a related discussion.
0.0.8 - 2020-05-27
This is a maintenance release with dependency updates, CI improvements, and some code modernization.
Changes from PR #23:
- Upgraded CI from travis to GH Actions
- Node versions tested updated from [4, 5] to [10, 12, 13, 14]
- Upgraded dev deps (ethereumjs-block, nyc, standard)
- Added
ethash_tests.jsonto test dir and removes ethereumjs-testing dep - Use single imports for ethereumjs-util, upgrades to v7.0.2
- Modernizes buffer init syntax
Further/preceding dependency updates in PR #19, PR #11, PR #8 and PR #7