@ethereumjs/tx v4.0.0-beta.1
Pre-release
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
London Hardfork Default
In this release the underlying @ethereumjs/common version is updated to v3 which sets the default HF to London (before: Istanbul).
This means that a Transaction object instantiated without providing an explicit Common is using London as the default hardfork as well and behavior of the library changes according to up-to-London HF rules.
If you want to prevent these kind of implicit HF switches in the future it is likely a good practice to just always do your upper-level library instantiations with a Common instance setting an explicit HF, e.g.:
import Common, { Chain, Hardfork } from '@ethereumjs/common'
const common = new Common({ chain: Chain.Mainnet, hardfork: Hardfork.Merge })
const tx = Transaction.fromTxData({
// Provide your tx data here or use default values
}, { common })BigInt Introduction / ES2020 Build Target
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.
Disabled esModuleInterop and allowSyntheticDefaultImports TypeScript Compiler Options
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 these options which might not be desirable, see this TypeScript Semver docs section for some more detailed argumentation.
Along the breaking releases we have therefore deactivated both of these options and you might therefore need to adopt some import statements accordingly. Note that you still have got the possibility to activate these options in your bundle and/or transpilation pipeline (but now you also have the option to not do which you didn't have before).
BigInt-Related API Changes
All transaction data input which have been previously taken in as BNLike (see Util library) - like gasPrice or nonce - are now taken in as BigIntLike and internally stored as a BigInt.
Have a look at your object instantiations on how you do things and if you need to update.
The following method signatures have been changed along the update and need some attention:
getBaseFee(): bigintgetDataFee(): bigintgetUpfrontCost(): bigint
API Method/Getter Removals
Additionally the following deprecated methods/getters have been removed from the API, see PR #1742:
get transactionType()get senderR()(alias forr)get senderS()(alias for s)get yParity()(alias for v)tx.fromRlpSerializedTx()TransactionFactory.getTransactionClass()
Reduced Bundle Size (MB -> KB)
The bundle size of the library has been dramatically reduced going down from MBs to KBs due to a reworked genesis code handling throughout the library stack in PR #1916 allowing the Common library to now ship without the bundled (large) genesis state definitions (especially for mainnet).
RLP Changes
If you are dealing with RLP encoded data and use the EthereumJS RLP library for decoding, please note that RLP library also got a major update and has been renamed along the way from rlp to a namespaced @ethereumjs/rlp, see RLP v4.0.0-beta.1 (and following) release notes in the CHANGELOG.
If you are updating from v2 you will likely also stumble upon the fact that with v3 RLP replaces Buffers as input and output values in favor of Uint8Arrays for improved performance and greater compatibility with browsers.
New conversion functions have also been added to the @ethereumjs/util library, see RLP docs on how to use and do the conversion.